[Python-Dev] Returned mail: Data format error
Your message was not delivered due to the following reason: Your message could not be delivered because the destination computer was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 7 days: Mail server 190.102.237.222 is not responding. The following recipients could not receive this message: Please reply to [EMAIL PROTECTED] if you feel this message to be in error. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Existence of pythonNN.zip in sys.path
Hi, I am the author of cx_Freeze which creates "frozen" executables from Python scripts. To this point I have been using frozen modules (compiled C) but this has the side effect of bundling parts of Python with a cx_Freeze release -- and this has bitten me on a number of occasions when newer versions of Python use slightly incompatible modules. :-) By scanning the code I discovered that Python automatically searches on startup /lib/pythonNN.zip where NN is replaced by the major and minor version that is being executed. Using this would allow me to ensure that bootstrap modules are not bundled with cx_Freeze but acquired from the distribution that is actually using it -- thereby eliminating the hassle noted above. I have tested this approach and found it works flawlessly. There is, however, no documentation that I can find for the contents of sys.path -- the documentation simply says that it is an installation default and doesn't specify what that default is. So my question is: can I safely make use of this "feature"? It has remained in place since at least Python 2.6 but I don't want to assume anything. Please advise! Thanks. Anthony ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Existence of pythonNN.zip in sys.path
On Mon, May 5, 2014 at 3:50 PM, Paul Moore wrote: > On 5 May 2014 22:32, Anthony Tuininga wrote: > > So my question is: can I safely make use of this "feature"? It has > remained > > in place since at least Python 2.6 but I don't want to assume anything. > > Please advise! Thanks. > > I believe this is a 100% supported feature of Python (since 2.6, as > you mention). Some of the zip import/run features have unfortunately > been underdocumented, and I suspect that this is simply one of those. > > Paul > That's great news. Thanks! Anthony ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Existence of pythonNN.zip in sys.path
Thanks. I think I can live with that restriction. :-) I do not read/write to the same zip file in the same process. Anthony On Mon, May 5, 2014 at 4:10 PM, Gregory P. Smith wrote: > > On Mon, May 5, 2014 at 2:52 PM, Anthony Tuininga < > [email protected]> wrote: > >> On Mon, May 5, 2014 at 3:50 PM, Paul Moore wrote: >> >>> On 5 May 2014 22:32, Anthony Tuininga >>> wrote: >>> > So my question is: can I safely make use of this "feature"? It has >>> remained >>> > in place since at least Python 2.6 but I don't want to assume anything. >>> > Please advise! Thanks. >>> >>> I believe this is a 100% supported feature of Python (since 2.6, as >>> you mention). Some of the zip import/run features have unfortunately >>> been underdocumented, and I suspect that this is simply one of those. >>> >>> Paul >>> >> >> That's great news. Thanks! >> >> Anthony >> > > There is at least one caveat to using a .zip file for the standard > library: http://bugs.python.org/issue19081 > > Never change the .zip file in use by a running process. > > -gps > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Existence of pythonNN.zip in sys.path
On Mon, May 5, 2014 at 4:16 PM, Nick Coghlan wrote: > > On 6 May 2014 07:51, "Paul Moore" wrote: > > > > On 5 May 2014 22:32, Anthony Tuininga > wrote: > > > So my question is: can I safely make use of this "feature"? It has > remained > > > in place since at least Python 2.6 but I don't want to assume anything. > > > Please advise! Thanks. > > > > I believe this is a 100% supported feature of Python (since 2.6, as > > you mention). Some of the zip import/run features have unfortunately > > been underdocumented, and I suspect that this is simply one of those. > > sys.path initialisation in general is woefully underspecified and > thoroughly confusing :( > > Fixing that is actually one of the motivating forces behind the proposed > startup improvements in PEP 432. > > Cheers, > Nick. > Thanks for the link. I would tend to agree with your assessment. :-) I've had to delve into the startup code a number of times to make cx_Freeze behave itself so any help here would be much appreciated! Anthony ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Suggestion About Python Syntax
I love the Python scripting language, but there’s something that would make it much better. Almost every other programming language uses curly braces to enclose blocks of code and semicolons after the lines of code. That means that: 1. You can have as much white space as you want. 2. You don’t need to worry about indentation, and you can indent whenever you want. I hope that you consider these issues and fix them in Python 4 (if you ever make it). Sincerely, Anthony, age 10. -- mmm# ## m mm mm#mm # mmmmm m mm m m # # #" ###" # #" "# #" # "m m" #mm# # ### # # # # # #m# ## # #"mm # # "#m#" # # "# m" "" ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [python-committers] PEP 563 and Python 3.10.
While I have not been involved in the release process for like 15 years or more, I would like to point out that breaking changes mean the distros are less likely to ship them, and be less likely to trust updates. Trying to get RH &c to stop shipping 1.5.2 was a huge effort. Always, any time when you might need to break compat it's a huge risk. On Wed, 21 Apr 2021, 4:58 am Thomas Wouters, wrote: > > (Starting a new thread so as not to derail any of the ongoing discussions.) > > Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP > 563 (postponed evaluation of annotations) becoming the default. The > Steering Council has considered the issue carefully, along with many of the > proposed alternatives and solutions, and we’ve decided that at this point, > we simply can’t risk the compatibility breakage of PEP 563. We need to roll > back the change that made stringified annotations the default, at least for > 3.10. (Pablo is already working on this.) > > To be clear, we are not reverting PEP 563 itself. The future import will > keep working like it did since Python 3.7. We’re delaying making PEP 563 > string-based annotations the default until Python 3.11. This will give us > time to find a solution that works for everyone (or to find a feasible > upgrade path for users who currently rely on evaluated annotations). Some > considerations that led us to this decision: > > - PEP 563’s default change is clearly too disruptive to downstream users > and third-party libraries to happen right now. We can’t risk breaking even > a small subset of the FastAPI/pydantic users, not to mention other uses of > evaluated type annotations that we’re not aware of yet. > - PEP 563 provides no warning to users of the feature it’s disabling. > Without that, we can’t expect users to be aware of the upcoming breakage. > The lack of a warning was by design, and made sense in a world where type > annotations were only consumed by static type checkers --- but that’s not > actually the situation we’re in. There are clearly existing real-world, > run-time uses of type annotations that would be adversely affected by this > change. > - Originally, PEP 563 was scheduled to take effect in Python 4, and this > changed recently (after the discussion in the Language Summit of 2020). > It's possible that third-party libraries and users didn’t plan to react in > the current time frame as they were not aware of this change in timing. > - There isn’t enough time to properly discuss PEP 649 or any of the > alternatives before the beta 1 deadline, and we really need to make sure we > don’t compound errors here. We need to look for a long term solution, > which isn’t possible while still maintaining the release deadlines of > Python 3.10. That means we’re also deferring PEP 649 to Python 3.11. > > In the Steering Council’s unanimous opinion, rolling back the default flip > for stringified annotations in Python 3.10 is the least disruptive of all > the options. > > We need to continue discussing the issue and potential solutions, since > this merely postpones the problem until 3.11. (For the record, postponing > the change further is not off the table, either, for example if the final > decision is to treat evaluated annotations as a deprecated feature, with > warnings on use.) > > For what it’s worth, the SC is also considering what we can do to reduce > the odds of something like this happening again, but that’s a separate > consideration, and a multi-faceted one at that. > > For the Steering Council, > Thomas. > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! > ___ > python-committers mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ULSWULZIBTYQ5GRBTLRQGNKQ525S7WJC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Looking for review on small argparse patch
As argparse seems to not have a current maintainer, I'm hoping a volunteer could review this small patch to the argparse module. I posted the PR nearly a month ago and have not received any feedback yet: https://github.com/python/cpython/pull/3027 bpo link: https://bugs.python.org/issue26510 Thanks in advance, Anthony ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?
I strongly urge another release candidate. But then, I am not doing the work, so take that advice for what it is... On Oct 14, 2009 10:18 AM, "Barry Warsaw" wrote: On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: >> I always thought that the idea of a release ... No, but let's do one anyway! So, we can either make Sunday's release rc2 and do the final release one week later, or I can try to get an rc2 out in the next day or two, with a final release mid-next week. Thoughts? -Barry ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK FREEZE for 2.5b2, tomorrow Tuesday 11th, 00:00 UTC
The trunk is frozen from 00:00 UTC Tuesday the 11th of July. This is in about 16 hours or so time. As usual, unless you're a member of the release team, please don't checkin past that time until I send an email that the release is done. Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
On Tuesday 11 July 2006 06:16, Raymond Hettinger wrote: > FWIW, I think this patch should go in. The benefits are > obvious and real. Yep. I'm going to check it in, unless someone else beats me to it in the next couple of hours before the b2 freeze. > But, the imagined costs of a new feature > during beta are illusory. This, I cannot agree with. The costs and risks of just continuing to add new features all through the release process are high. The chances of us releasing a broken Python increases dramatically. Then we have to do emergency bugfix releases. And I'm sorry, but the release process is not something that's zero work. Sure, it's zero work _for_ _you_ , but not for Martin, Fred and myself. > In this case, practicality beats pedantry. I don't think trying to produce the most stable and bugfree Python possible could in _anyway_ be considered "pedantry", and it makes me quite grumpy to have it described in that way. > For the users, it > is a net win if this goes in. In the case of this feature, that's true. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Missing" 2.5 feature
On Tuesday 11 July 2006 06:52, Tim Peters wrote: > > I don't think trying to produce the most stable and bugfree > > Python possible could in _anyway_ be considered "pedantry", and > > it makes me quite grumpy to have it described in that way. > > He meant that "no new features", while a useful guideline, can be > counterproductive if followed slavishly. I'm not taking a slavish "no new features" line. I _am_ saying that any new features, post beta, require a good justification and a clear understanding of the risks that are added by the new code. In this case, the tradeoff is fine. Simply saying code is very low risk isn't enough - there also has to be a positive reason for the code going in. The ability to debug deadlocks is a good thing, and the clincher (once I sat and thought about it a bit) is that there is _already_ a module out there that attempts to do this, albeit in a buggy fashion. This is pretty clear indication that there is a demand for the feature. Similarly, the PyErr_WarnEx() is _probably_ a good thing to add in, because otherwise we can't do anything about the struct warning. But that really will have to wait until post-beta2 at this point. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Subject: RELEASED Python 2.5 (beta 2)
On behalf of the Python development team and the Python community, I'm happy to announce the second BETA release of Python 2.5. This is an *beta* release of Python 2.5. As such, it is not suitable for a production environment. It is being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 2.5 might impact you. If you find things broken or incorrect, please log a bug on Sourceforge. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows installers) are available from the 2.5 website: http://www.python.org/2.5/ A Universal Mac OSX Installer will be available shortly - in the meantime, Mac users can build from the source tarballs. Since the first beta, a large number of bug fixes have been made to Python 2.5 - see the release notes (available from the 2.5 webpage) for the full details. There has been one very small new feature added - the sys._current_frames() function was added. This is extremely useful for tracking down deadlocks and related problems - a similar technique is already used in the popular DeadlockDebugger extension for Zope. It is not possible to do this sort of debugging from outside the Python core safely and robustly, which is why we've snuck this in after the feature freeze. As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The plan is for this to be the final beta release. We should now move to one or more release candidates, leading to a 2.5 final release early August. PEP 356 includes the schedule and will be updated as the schedule evolves. At this point, any testing you can do would be greatly, greatly appreciated. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref and ctypes. In addition, a new profiling module "cProfile" was added. Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgplW1DKoGpz0.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK is UNFROZEN.
beta2 is done, so trunk is unfrozen. Remember, we're still in feature freeze, so new features need approval before being committed. Thanks! Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Minor: Unix icons for 2.5?
There's an open PEP-356 issue for "update the icons to the newer shinier ones" for Unix. As far as I can see, there's the 14x15 GIF images used for Idle and the documentation. Note that for me at least, idle comes up without an icon _anyway_. Are there any others I missed? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] get for lists and tuples?
On Wednesday 12 July 2006 03:39, Georg Brandl wrote: > > Anyway, I'm just testing the waters. If it's not heresy then I'd > > like to do what I can to make it happen. > > IMO there's almost no chance this can go into 2.5. "almost"? I'll go you one better. No way at all will it be in 2.5. And I'd be a firm -1 on adding in to 2.6 as well. It encourages bad coding. You shouldn't be searching lists and tuples like that unless you know what you're doing. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt
On Wednesday 12 July 2006 07:16, Martin v. Löwis wrote:
> Stefan Rank wrote:
> > I suggest to add (after 2.5 I assume) one of the following to the
> > beginning of urllib.quote to either fail early and consistently
> > on unicode arguments and improve the error message::
> >
> >if isinstance(s, unicode):
> >raise TypeError("quote needs a byte string argument, not
> > unicode," " use `argument.encode('utf-8')` first.")
> >
> > or to do The Right Thing (tm), which is utf-8 encoding::
>
> The right thing to do is IRIs. This is more complicated than
> encoding the Unicode string as UTF-8, though: for the host part of
> the URL, you have to encode it with IDNA (and there are additional
> complicated rules in place, e.g. when the Unicode string already
> contains %).
>
> Contributions are welcome, as long as they fix this entire issue
> "for good" (i.e. in all URL-processing code, and considering all
> relevant RFCs).
For 2.5, should we at least detect that it's unicode and raise a
useful error?
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] changing time.strftime() to accept 0s (was: User's complaints)
Making strftime accept 0s is fine to be checked in, since it's a regression (an understandable one, but what the hell). Making it accept less than 9 items and have useful defaults should wait for 2.6 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Long options support
On Wednesday 12 July 2006 21:55, Georg Brandl wrote: > >> Should we accept at least the very common options "--help" and > >> "--version" in 2.5? > > > > Guido pronounced on this in May > > Late it comes, but here is a patch for getopt.c implementing > this pronouncement. I think there's no need to wait for 2.6 with > it, or is there? Check it in. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] User's complaints
On Thursday 13 July 2006 14:46, Guido van Rossum wrote: > Thanks for confirming memory! So it was an intentional regression; > "bugs happen" doesn't apply in this case. And an unfortunate > regression at that -- not because one guy writes a silly blog entry > about it, but because it breaks real code -- undocumented be > damned. > > Are we going to fix it, without allowing those crashes again? I already said "yes" for 2.5. Brett, can you work up a patch? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
FWIW, I tend to run a few project(*) test suites when doing minor releases (2.x.y), just to make sure I don't break things. For major releases, it's a fair bit more work - something like Twisted or Zope3 play at such a low level with the Python interfaces that there's nearly always breakages or massive warning dumps (from memory, zope.interface uses 'with' as an argument name, a lot). The "community buildbot" idea is a good one, although it should just be possible to write something for buildbot that checks out and builds the latest Python SVN, then installs it to a temporary location, then adds that location to the front of the path. Then each project could just add a "Python SVN buildbot" to their exists bbot install. Anthony (*) Typically includes Zope3 and Twisted, because I have these just lying around. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 06:05, Barry Warsaw wrote: > This really is an excellent point and makes me think that we may > want to consider elaborating on the Python release cycle to include > a gamma phase or a longer release candidate cycle. OT1H I think > there will always be people or projects that won't try anything > until the gold release, and that if we've broken anything in their > code we simply won't know it until after that, no matter how > diligent we are. OTOH, a more formal gamma phase would allow us to > say "absolutely no changes are allowed now unless it's to fix > backward compatibility". No more sneaking in new sys functions or > types module constants during the gamma phase. alpha 1: April 5, 2006 [completed] alpha 2: April 27, 2006 [completed] beta 1: June 20, 2006 [completed] beta 2: July 11, 2006 [completed] rc 1:August 1, 2006 [planned] final: August 8, 2006 [planned] Four months would seem to me to be quite long enough as a release cycle. Extending it means far more work for everyone - either we have special checkin rules for the trunk for a longer period of time (requiring extra monitoring by people like myself and Neal), or we branch earlier, requiring double commits to the trunk and the branch for bugfixes. I also strongly doubt that making a longer "release candidate" cycle would lead to any significant additional testing by end-users. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 17:00, Fredrik Lundh wrote: > because they don't want to waste time and effort on testing against > releases that are not necessarily a close approximation of the full > release? testing takes time, and time can be used for many > different things. Oddly enough, so does release management. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 16:39, Neal Norwitz wrote: > Remember I also tried to push for more features to go in early? > That would have given more time for external testing. Still > features are coming in. Python developers weren't happy about > having to get things in earlier. I don't see a practical way to > implement what you propose (see Anthony's comments). Following up on this point: Given the number of "just-this-one-more-thing-please" we've _already_ had since the b1 feature freeze, do you really except that 90 days of feature freeze is feasible? And if there's not going to be a feature freeze, there's hardly any point to people doing testing until there _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1. Oops. 2.5b9 added a new feature that broke my code, but I didn't test with that. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Friday 14 July 2006 22:45, Jeremy Hylton wrote: > Maybe the basic question is right, but the emphasis needs to be > changed. If we had a rule that said the final release was 90 days > after the last submission that wasn't to fix a regression, we'd ask > "Is this feature important enough to warrant delaying the release > until three months from now?" I'm not sure what I think, but it > doesn't seem like an implausible policy. I really really doubt that this would work. There's always pressure for "just one more feature" - and as the release drags on, this would increase, not decrease. Note that dragging the release process out has it's own costs, as mentioned previously - either the trunk is in some sort of near-frozen state for an extended period, or else we end up in the double-applying-bugfixes state by forking much earlier. This approach would also make it extremely difficult to plan for releases. I know that my free time varies across the course of the year, and I need _some_ sort of plan for when the release will happen so I can make sure I have the time free to spend on it. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On Monday 17 July 2006 20:27, Andrew MacIntyre wrote: > On the face of it, it seems to me that branching a new major > release at the 1st beta would be one way of managing this. The > trunk is not frozen for an extended period, and any "features" and > bug fixes could probably be backported from the trunk on clearance > from the RE with no more pain than is currently endured. > > One down side would be the possibility of a loss in emphasis in > finishing the job on the release to be. I'm sure there are > others... The major one is the doubling of the workload for bugfixes. SVN is better than CVS, but it's still not great when it comes to backporting fixes between branches. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Which version of distutils to ship with Python 2.5?
On Thursday 27 July 2006 16:40, Martin v. Löwis wrote: > Collin Winter wrote: > > Is it intentional that Python 2.5 is (currently) shipping with > > distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and > > 2.4.3) shipped with distutils 2.4.1? Judging from my own tests, > > distutils 2.4.1 fixed several bugs that some of my test suites > > depend on (the fixes, not the bugs ; ). > > Are these bugs not fixed in the distutils that shipped with Python > 2.5b2? > > In any case, I bumped the version number to 2.5, according to the > policy discussed in > Could this not simply use the Python version number directly, instead? Separate version numbers only make sense if the package is separately distributed - and even then, something like Barry's setup for the email package could keep that version number out of the Python trunk. Fiddly little version numbers scattered throughout the standard library == pain. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On Friday 28 July 2006 15:32, Raymond Hettinger wrote: > I suggest that there be a third beta release and that we then wait > just a bit before going final. > > The bugs that were found and fixed in the first two beta releases > suggest that Py2.5 is not yet as stable as we would like. Over the > next few days, I'll try to run it on as much third-party code as > possible. That would have detected the recently surfaced grammar > error a little bit earlier (the one where "for x, in listOfTuples" > would not unpack). > > The release process itself is going well but I don't think the > pervasive AST changes have been fully shaken-out yet. I've been thinking the same thing, too. A quick chat to Neal says that he also agrees. There's still a lot more bugs popping up than I'm really comfortable with. I guess this is inevitable - there's a lot of new stuff in 2.5. Does anyone disagree with making the next release beta3? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK FREEZE 2006-07-03, 00:00 UTC for 2.5b3
The trunk is FROZEN from 00:00 UTC/GMT on 03 July 2006. That's in about 12 hours from now. This is for the third (and final, hopefully!) beta of 2.5. Please help the release team out by not making checkins on the trunk after that time until I send out an email that the release is done. Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.5 (beta 3)
On behalf of the Python development team and the Python community, I'm happy to announce the third BETA release of Python 2.5. This is an *beta* release of Python 2.5. As such, it is not suitable for a production environment. It is being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 2.5 might impact you. If you find things broken or incorrect, please log a bug on Sourceforge. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ There's been over 50 fixes since the second beta. This large number of changes meant we felt more comfortable cutting a third beta release, rather than charging ahead to the release candidate. As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The plan is that this will be the final beta release (no, really, this time for sure (probably)). We should now move to one or more release candidates, leading to a 2.5 final release early August. PEP 356 includes the schedule and will be updated as the schedule evolves. At this point, any testing you can do would be greatly, greatly appreciated. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref and ctypes. In addition, a new profiling module "cProfile" was added. Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpgyj51XmlUG.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK is UNFROZEN
The trunk is unfrozen now. Sorry about the delay - combination of a laptop motherboard replacement and a DSL provider with a network that was .. ahem... slightly slow. I'm still planning to branch at 2.5c1, the next release. That then opens the trunk up for all the bad craziness that's planned for 2.6. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows 2.5 build: use OpenSSL for hashlib [bug 1535502]
I'm nervous about this change being made at this stage of the release process. It seems to me to have a chance of causing breakages - admittedly a small chance, but one that's higher than I'd like. I'd also like to make sure that the PCBuild8 directory is updated at the same time - with the recent disappearance of the previous free MS compiler version, I think this will become more important over the 18 months or so of Python 2.5's life. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type of range object members
On Tuesday 15 August 2006 14:14, Guido van Rossum wrote: > > They don't have to come from a python int, they can come from a > > long.I guess range_new would have to be changed to the 'n' > > conversion code instead of 'l' to do the proper conversion. > > Similarly, rangeiter_next will need to use PyInt_FromSsize_t . > > Feel free to submit a patch for Python 2.6. I expect the 2.5 release > managers to reject this on the basis of being a new feature. Absolutely correct. At this point in the release process, there's going to be a massive resistance to changes. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no remaining issues blocking 2.5 release
On Tuesday 15 August 2006 14:31, Neal Norwitz wrote: > I just updated the PEP to remove all references to issues blocking > release of 2.5. > I don't know of any. I haven't heard of any issues with the fixes > that have been checked in. > > If you have issues, respond ASAP! The release candidate is planned to > be cut this Thursday/Friday. There are only a few more days before > code freeze. A branch will be made when the release candidate is cut. More information here: I plan to branch release25-maint on Thursday morning, as the first step in the release process for 2.5c1. This will be done after the repository is updated to identify itself as '2.5c1'. Once this is done, I plan on doing all further 2.5 releases from the release25-maint branch. I will no longer care about the trunk's stability :-) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no remaining issues blocking 2.5 release
I really don't care any more about this. My initial concern (and why I requested the change) was that there are no more official separate distutils releases. I don't see how keeping a bunch of version numbers in the stdlib that just track the main version number is a sane use of developer time - particularly when it's only being used for someone's private releases. If you're cutting releases out of the stdlib, it seems to me that the maintenance load should be on you (where 'you' is 'anyone doing something like this', not MAL specifically ) I'd also like to see idle's separate version number go away and have it start using the Python version number - maybe as of 2.6? This would then also mean we could pull idle's separate NEWS file into the master NEWS file. Right now, the "release notes" on the webpage miss all IDLE release notes, since it's just the main NEWS file. Since it's provoked so many complaints, change it back if you want. I won't be bothering to check that it's correct from now on, nor will I be updating it. Any user complaints will be ignored, and an incorrect version number will not be considered a reason for a bugfix release. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] no remaining issues blocking 2.5 release
On Tuesday 15 August 2006 22:57, Thomas Heller wrote: > What is the policy for documentation changes? Am I allowed to check in > changes/additions to the ctypes docs without release manager permission > after the release candidate is out? I'l always make sure that the html > docs can be built. So long as you don't break anything, doc changes are fine. Remember that post RC1 you'll need to checkin to both release25-maint and trunk. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE patches - bugfix or not?
On Wednesday 16 August 2006 06:19, Jim Jewett wrote: > I just uploaded a series of IDLE patches, but I'm not quite sure how > to classify them on the feature/bugfix scale now that the last beta is > out. > > >From most to least buggish: > > python.org/sf/1540892 -- honor the new quit() behavior. On the other > hand, it was documented that this didn't work in IDLE, and it is > *possible* that someone was counting on this. This seems like a sensible thing to add. > python.org/sf/1540851 -- with is now a blockopener, and should be > counted as such -- I *think* this one would be safe, but I know that > changing a parser can be surprising, and I suppose it *could* wait > until with no longer requires a future statement. If this can be done safely, it should be done. Preferably before RC1, so that we have time to fix any issues it shows up. > python.org/sf/1540874 -- broken shortcut keys. On windows, only one > entry per menu can be reached with the same shortcut letter, so > advertising others is just an attractive nuisance. I'm not sure that > other systems wouldn't be able to use the hidden shortcuts. Tough call. I guess it depends on the other systems - I will try this on Linux at least, and see if it works there. If it's broken everywhere, then changing it would seem the least offensive choice. > python.org/sf/1540869 -- GUI fix. The current code puts in a > separator using a magic number (and has XXX comments about it.) This > changes the magic number so that the separator is more visible, but > I'm not sure the old behavior rose to a bug, or that it wasn't > platform dependent. Let's leave this one for 2.6. > python.org/sf/1540849 -- except too broad. I wouldn't suggest > applying this late in the release cycle, except that it seems sort of > like the memory errors that are still being patched. I'd be concerned that this might cause other obscure behaviour changes, and so I'd prefer to leave this to 2.6. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK FREEZE for 2.5c1, 00:00 UTC, Thursday 17th August
Ok, here we go... I'm declaring the TRUNK FROZEN as of 00:00 UTC on Thursday the 17th of August. This is in about 22 hours time. At this time, I'll be cutting the release25-maint branch and 2.5c1 (and all future 2.5 releases) will be from that branch. I'll send another email once the release is done - at that point, the trunk is then available for 2.6 checkins. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [wwwsearch-general] 2.5: recently introduced sgmllib regexp bug hangs Python
On Thursday 17 August 2006 12:13, John J Lee wrote: > On Thu, 17 Aug 2006, John J Lee wrote: > [...] > > > If nobody has time to fix this, perhaps rev 47154 should be reverted? > > I should have put it more strongly: I think it *should* in fact be > reverted if nobody has time to fix it before the release candidate / final > release of 2.5. The revision in question is the most recent commit to > sgmllib.py and certainly appears completely localised to that module. > And a hung interpreter is worse than failing to parse some HTML, IMHO. Well, it's a bit late for the release candidate :-) but I agree - if it can't be fixed before 2.5 final, it should be reverted. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
The release candidate is done - we creep ever closer to 2.5 final. Hoooray! All future 2.5 releases (including 2.5 final!) will now be done from the new release25-maint trunk (svn+ssh://[EMAIL PROTECTED]/python/branches/release25-maint) - so any changes you want to see after 2.5c1 and before 2.5 final will need to be applied to that branch as well as to the trunk. >From now until the final release, I think we should say no checkins to the release25-maint branch without either myself or Neal signing off on it - for safety's sake, I'd recommend you email either the list here, or if you have to send private email, send it to both of us. If this policy offends you, please reply and let me know what you'd prefer. Right now, I don't really care about the trunk - although if you break the buildbot, I'm sure Neal will be very cranky at you :-) Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.5 (release candidate 1)
On behalf of the Python development team and the Python community, I'm happy to announce the first RELEASE CANDIDATE of Python 2.5. This is not yet the final release - it is not suitable for production use. It is being released to solicit feedback and hopefully expose bugs, as well as allowing you to determine how changes in 2.5 might impact you. As a release candidate, this is one of your last chances to test the new code in 2.5 before the final release. *Please* try this release out and let us know about any problems you find. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The plan now is to let the release candidate shake out any last-minute bugs in Python 2.5, leading to a 2.5 final release in early September. PEP 356 includes the schedule and will be updated as the schedule evolves. At this point, any testing you can do would be greatly, greatly appreciated. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref, uuid and ctypes. In addition, a new profiling module cProfile was added. Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpC2XcpH5jvO.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
On Friday 18 August 2006 00:47, Martin v. Löwis wrote: > Anthony Baxter schrieb: > > Right now, I don't really care about the trunk - although if you break > > the buildbot [...] > > Thanks for reminding me. I just added a buildbot builder for the 2.5 > branch (actually, the builder was already there, but I connected it > with the web server), so you can now see the status of the 2.5 branch > at > > http://www.python.org/dev/buildbot/2.5/ You beat me to it by a couple of minutes - I'd added the entry to the master.cfg file but hadn't updated the apache config yet. Anthoiny -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined
Fixing docs is fine - please checkin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid tests failing on Windows
On Friday 18 August 2006 06:06, Martin v. Löwis wrote: > Georg Brandl schrieb: > >> Can somebody please fix that? If not, should we remove the uuid module > >> as being immature? > > > > Patch #1541863 supposedly solves this. > > Ah, good. I think it should go in. Sounds fine to me. Making buildbot less red == goodness. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How does this help? Re: [Python-checkins] r51366 - python/trunk/Lib/idlelib/NEWS.txt python/trunk/Lib/idlelib/idlever.py
On Saturday 19 August 2006 06:24, Jim Jewett wrote: > This makes things more consistent for today, but does it really ease > maintenance? > > Why not just change it to: > > from sys import version as IDLE_VERSION > > so that it can be ignored from now on? After the fuss about changing distutils' version number? :-) I'd very much like to do this, but I figured this was a good first step. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] One-line fix for urllib2 regression
On Saturday 19 August 2006 15:28, Georg Brandl wrote: > John J Lee wrote: > > Revision 50842 made a change to an undocumented interface of urllib2 that > > I'm sure will break real code. > > > > Patch 1542948 reverts the part of that commit that applied to urllib2, > > and adds a one-line fix in its place that addresses the problem that > > 50842 fixed. > > > > Details are on the patch tracker: > > > > http://python.org/sf/1542948 > > > > > > Can somebody commit this for 2.5? > > As the committer of the original patch, I have reviewed it and I'm for it. I agree with Neal's comment - this needs tests to make sure it doesn't break again. It's OK to apply it with the tests. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gcc 4.2 exposes signed integer overflows
On Sunday 27 August 2006 05:06, Jack Howarth wrote: >I discovered that gcc 4.2 exposes a flaw with > signed integer overflows in python. This bug and the > necessary fix has been discussed in detail on the gcc > mailing list. I have filed a detailed bug report and > the recommended patch proposed by the gcc developers. > This problem should be addressed BEFORE python 2.5 is > released. The bug report is... > > [ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows > > in the python sourceforge bug tracker. Thanks in advance > for attempting to fix this before Python 2.5 is released. > Jack Regardless of whether we consider gcc's behaviour to be correct or not, I do agree we need a fix for this in 2.5 final. That should also be backported to release24-maint for the 2.4.4 release, and maybe release23-maint, as Barry recently started talking about cutting a 2.3.6. Can I nominate Tim, with his terrifying knowledge of C compiler esoterica, as the person to pick the best fix? Thanks, Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gcc 4.2 exposes signed integer overflows
On Wednesday 30 August 2006 08:57, Tim Peters wrote: > Speaking of which, I saw no feedback on the proposed patch in > > http://mail.python.org/pipermail/python-dev/2006-August/068502.html > > so I'll just check that in tomorrow. Fine with me! thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gcc 4.2 exposes signed integer overflows
On Wednesday 30 August 2006 08:57, Tim Peters wrote: > Speaking of which, I saw no feedback on the proposed patch in > > http://mail.python.org/pipermail/python-dev/2006-August/068502.html > > so I'll just check that in tomorrow. This should also be backported to release24-maint and release23-maint. Let me know if you can't do the backport... -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A test suite for unittest
At this point, I'd say the documentation patches should go in - the other patches are probably appropriate for 2.5.1. I only want to accept critical patches between now and 2.5 final. Thanks for the patches (and particularly for the unittest! woo!) Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
On Sunday 03 September 2006 03:11, Raymond Hettinger wrote: > [Neal] > > > Please review the patch and make a comment. I did a diff between HEAD > > and 2.4 and am fine with this going in once you are happy. > > I fixed a couple of documentation nits in rev 51688. > The patch is ready-to-go. > Nick, please go ahead and backport. I think this is suitable for 2.5. I'm thinking, though, that we need a second release candidate, given the number of changes since rc1. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals, threads, blocking C functions
On Saturday 02 September 2006 22:10, Gustavo Carneiro wrote: > According to [1], all python needs to do to avoid this problem is > block all signals in all but the main thread; then we can guarantee > signal handlers are always called from the main thread, and pygtk > doesn't need a timeout. > But I would really prefer the first alternative, as it could be > fixed within python 2.5; no need to wait for 2.6. Assuming "the first alternative" is the "just block all signals in all but the main thread" option, there is absolutely no chance of this going into 2.5. Signals and threads combined are an complete *nightmare* of platform-specific behaviour. I'm -1000 on trying to change this code now, _after_ the first release candidate. To say that "that path lies madness" is like saying "Pacific Ocean large, wet, full of fish". -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals, threads, blocking C functions
On Tuesday 05 September 2006 00:05, Nick Maclaren wrote: > Anthony Baxter isn't exaggerating the problem, despite what you may > think from his posting. If the SF bugtracker had a better search interface, you could see why I have such a bleak view of this area of Python. What's there now *mostly* works (I exclude freakshows like certain versions of HP/UX, AIX, SCO and the like). It took a hell of a lot of effort to get it to this point. threads + signals == tears. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals, threads, blocking C functions
On Tuesday 05 September 2006 00:52, Gustavo Carneiro wrote: > 3. Signals can be delivered to any thread, let's assume (because > of point #1 and not others not mentioned) that we have no control over > which threads receive which signals, might as well be random for all > we know; Note that some Unix variants only deliver signals to the main thread (or so the manpages allege, anyway). Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
On Friday 08 September 2006 02:56, Kristján V. Jónsson wrote: > Hello All. > I just added patch 1552880 to sourceforge. It is a patch for 2.6 (and 2.5) > which allows unicode paths in sys.path and uses the unicode file api on > windows. This is tried and tested on 2.5, and backported to 2.3 and is > currently running on clients in china and esewhere. It is minimally > intrusive to the inporting mechanism, at the cost of some string conversion > overhead (to utf8 and then back to unicode). As this can't be considered a bugfix (that I can see), I'd be against it being checked into 2.5. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
On Friday 08 September 2006 18:24, Steve Holden wrote: > > As this can't be considered a bugfix (that I can see), I'd be against it > > being checked into 2.5. > > Are you suggesting that Python's inability to correctly handle Unicode > path elements isn't a bug? Or simply that this inability isn't currently > described in a bug report on Sourceforge? I'm suggesting that adding the ability to handle unicode paths is a *new* *feature*. If people actually want to see 2.5 final ever released, they're going to have to accept that "oh, but just this _one_ _more_ _thing_" is not going to fly. We're _well_ past beta1, where new features should have been added. At this point, we have to cut another release candidate. This is far too much to add during the release candidate stage. > I agree it's a relatively large patch for a release candidate but if > prudence suggests deferring it, it should be a *definite* for 2.5.1 and > subsequent releases. Possibly. I remain unconvinced. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
On Friday 08 September 2006 19:19, Steve Holden wrote: > But it *is* a desirable, albeit new, feature, so I'm surprised that you > don't appear to perceive it as such for a downstream release. Point releases (2.x.1 and suchlike) are absolutely not for new features. They're for bugfixes, only. It's possible that this could be considered a bugfix, but as I said right now I'm dubious. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BRANCH FREEZE: release25-maint, 00:00UTC 12 September 2006
Ok, I haven't heard back from Martin, but I'm going to hope he's OK with tomorrow as a release date for 2.5rc2. If he's not, we'll try for the day after. In any case, I'm going to declare the release25-maint branch FROZEN as at 00:00 UTC on the 12th. That's about 12 hours from now. This is for 2.5rc2. Once this is out, I'd like to see as close to zero changes as possible for the next week or so until 2.5 final is released. My god, it's getting so close... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime's strftime implementation: by design or bug
Please log a bug - this is probably something suitable for fixing in 2.5.1. At the very least, if it's going to be limited to 127 characters, it should check that and raise a more suitable exception. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.5 (release candidate 2)
On behalf of the Python development team and the Python community, I'm happy to announce the second RELEASE CANDIDATE of Python 2.5. After the first release candidate a number of new bugfixes have been applied to the Python 2.5 code. In the interests of making 2.5 the best release possible, we've decided to put out a second (and hopefully last) release candidate. We plan for a 2.5 final in a week's time. This is not yet the final release - it is not suitable for production use. It is being released to solicit feedback and hopefully expose bugs, as well as allowing you to determine how changes in 2.5 might impact you. As a release candidate, this is one of your last chances to test the new code in 2.5 before the final release. *Please* try this release out and let us know about any problems you find. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref, uuid and ctypes. In addition, a new profiling module "cProfile" was added. Enjoy this new release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] release is done, but release25-maint branch remains near-frozen
Ok - we're looking at a final release in 7 days time. I really, really, really don't want to have to cut an rc3, so unless it's a seriously critical brown-paper-bag bug, let's hold off on the checkins. Documentation, I don't mind so much - particularly any formatting errors. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Before 2.5 - More signed integer overflows
On Saturday 16 September 2006 21:11, Armin Rigo wrote: > Hi all, > > There are more cases of signed integer overflows in the CPython source > code base... > > That's on a 64-bits machine: > > [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 > abs(-sys.maxint-1) == -sys.maxint-1 > Humpf! Looks like one person or two need to do a quick last-minute > review of all places trying to deal with -sys.maxint-1, and replace them > all with the "official" fix from Tim [SF 1545668]. Ick. We're now less than 24 hours from the scheduled release date for 2.5 final. There seems to be a couple of approaches here: 1. Someone (it won't be me, I'm flat out with work and paperwriting today) reviews the code and fixes it 2. We leave it for a 2.5.1. I'm expecting (based on the number of bugs found and fixed during the release cycle) that we'll probably need a 2.5.1 in about 3 months. 3. We delay the release until it's fixed. I'm strongly leaning towards (2) at this point. (1) would probably require another release candidate, while (3) would result in another release candidate and massive amount of sobbing from a lot of people (including me). -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BRANCH FREEZE/IMMINENT RELEASE: Python 2.5 (final). 2006-09-19, 00:00UTC
Ok, time to bring down the hammer. The release25-maint branch is absolutely frozen to everyone but the release team from 00:00UTC, Tuesday 19th September. That's just under 20 hours from now. This is for Python 2.5 FINAL, so anyone who breaks this release will make me very, very sad. Based on the last few releases, I'd expect the release process to take around 18 hours (timezones are a swine). Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.5 (FINAL)
It's been nearly 20 months since the last major release of Python (2.4), and 5 months since the first alpha release of this cycle, so I'm absolutely thrilled to be able to say: On behalf of the Python development team and the Python community, I'm happy to announce the FINAL release of Python 2.5. This is a *production* release of Python 2.5. Yes, that's right, it's finally here. Python 2.5 is probably the most significant new release of Python since 2.2, way back in the dark ages of 2001. There's been a wide variety of changes and additions, both user-visible and underneath the hood. In addition, we've switched to SVN for development and now use Buildbot to do continuous testing of the Python codebase. Much more information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the new features of Python 2.5 are conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce coroutine functionality, and a brand new AST-based compiler implementation underneath the hood. There's a variety of smaller new features as well. New to the standard library are hashlib, ElementTree, sqlite3, wsgiref, uuid and ctypes. As well, a new higher-performance profiling module (cProfile) was added. Extra-special thanks on behalf of the entire Python community should go out to Neal Norwitz, who's done absolutely sterling work in shepherding Python 2.5 through to it's final release. Enjoy this new release, (and Woo-HOO! It's done!) Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpA8ImA53iae.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] release25-maint branch - please keep frozen for a day or two more.
Could people please treat the release25-maint branch as frozen for a day or two, just in case we have to cut an ohmygodnononokillme release? Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] release25-maint is UNFROZEN
Ok - it's been 48 hours, and I've not seen any brown-paper-bag bugs, so I'm declaring the 2.5 maintenance branch open for business. As specified in PEP-006, this is a maintenance branch only suitable for bug fixes. No functionality changes should be checked in without discussion and agreement on python-dev first. Thanks to everyone for helping make 2.5 happen. It's been a long slog there, but I think we can all be proud of the result. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] AST structure and maintenance branches
I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to compile() get the same guarantee in maintenance branches as the bytecode format - that is, unless it's absolutely necessary, we'll keep it the same. Otherwise anyone trying to write tools to manipulate the AST is in for a massive world of hurt. Anyone have any problems with this, or can it be added to PEP 6? Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.4.4c1 October 11, 2.4.4 final October 18
The plan for 2.4.4 is to have a release candidate on October 11th, and a final release on October 18th. This is very likely to be the last ever 2.4 release, after which 2.4.4 joins 2.3.5 and earlier in the old folks home, where it can live out it's remaining life with dignity and respect. If you know of any backports that should go in, please make sure you get them done before the 11th. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST structure and maintenance branches
On Friday 29 September 2006 00:30, Jeremy Hylton wrote: > On 9/23/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > > I'd like to propose that the AST format returned by passing PyCF_ONLY_AST > > to compile() get the same guarantee in maintenance branches as the > > bytecode format - that is, unless it's absolutely necessary, we'll keep > > it the same. Otherwise anyone trying to write tools to manipulate the AST > > is in for a massive world of hurt. > > > > Anyone have any problems with this, or can it be added to PEP 6? > > It's possible we should poll developers of other Python > implementations and find out if anyone has objections to supporting > this AST format. But in principle, it sounds like a good idea to me. I think it's extremely likely that the AST format will change over time - with major releases. I'd just like to guarantee that we won't mess with it other than that. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BRANCH FREEZE, release24-maint for 2.4.4c1. 00:00UTC, 11 October 2006
The release24-maint branch is frozen for the 2.4.4c1 release from 00:00UTC on the 11th of October. That's about 7 hours from now. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.3.6 for the unicode buffer overrun
I've had a couple of queries about whether PSF-2006-001 merits a 2.3.6. Personally, I lean towards "no" - 2.4 was nearly two years ago now. But I'm open to other opinions - I guess people see the phrase "buffer overrun" and they get scared. Plus once 2.4.4 final is out next week, I'll have cut 12 releases since March. Assuming a 2.5.1 before March (very likely) that'll be 14 releases in 12 months. 16 releases in 12 months would just about make me go crazy. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.4.4, release candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.4 (release candidate 1). Python 2.4.4 is a bug-fix release. While Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.4. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 80 bugs squished in this release, including a number found by the Coverity and Klocwork static analysis tools. We'd like to offer our thanks to both these companies for making this available for open source projects. * Python 2.4.4 contains a fix for PSF-2006-001, a buffer overrun * * in repr() of unicode strings in wide unicode (UCS-4) builds. * * See http://www.python.org/news/security/PSF-2006-001/ for more. * Assuming no major problems crop up, a final release of Python 2.4.4 will follow in about a week's time. This will be the last planned release in the Python 2.4 series - future maintenance releases will be in the 2.5 line. For more information on Python 2.4.4, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.4/ Highlights of this new release include: - Bug fixes. According to the release notes, at least 80 have been fixed. - A fix for PSF-2006-001, a bug in repr() for unicode strings on UCS-4 (wide unicode) builds. Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy this release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpzcYkwpfnHG.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Thursday 12 October 2006 18:18, Fredrik Lundh wrote: > Anthony Baxter wrote: > > 16 releases in 12 months would just about make me go crazy. > > is there any way we could further automate or otherwise streamline or > distribute the release process ? It's already pretty heavily automated (see welease.py in the SVN sandbox). The killer problem is pyramid (the system for the website). Here's (roughly) a breakdown of the workload: - Update the 10 or so files that need the date and version number (about 3m) - Run welease.py, select the branch, enter the version number, press 4 buttons, one after the other. It complains and stops if something goes wrong. (elapsed time about 5-10m, actual "work" time < 30s) - Wait for the Mac/Win/Doc builders (elapsed, 6-12h, depending on timezones, actual "work" time 0s) - Sign binaries and put in place on website (maybe 2m work, plus 5-10m to scp up to dinsdale) - Update webpages (between 30m and an hour, depending on how much I have to fight with pyramid. I still need to go update the old release pages putting the warnings on them, so there's probably another hour of work today) I've mentioned this on pydotorg enough times, I don't feel I can continue to complain about it (because I can't offer the time to make it better) but pyramid is *not* *good* from my point of view. The older system with Makefiles, ht2html and rsync took maybe 1/4 to 1/3 as long. > ideally, releasing (earlier release + well-defined patch set) should be > fairly trivial, compared to releasing (new release from trunk). what do > we have to do to make it easier to handle that case? Mostly it is easy for me, with the one huge caveat. As far as I know, the Mac build is a single command to run for Ronald, and the Doc build similarly for Fred. I don't know what Martin has to do for the Windows build. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 06:25, Barry Warsaw wrote: > On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote: > > Mostly it is easy for me, with the one huge caveat. As far as I > > know, the Mac > > build is a single command to run for Ronald, and the Doc build > > similarly for > > Fred. I don't know what Martin has to do for the Windows build. > > Why can't we get buildbot to do most or all of this? At work, we > have buildbot slaves that post installers to a share after successful > checkout, build, and test on all our supported platforms. Speaking for myself, I'd rather do it by hand, if it's not a lot of work (which it isn't) - I don't like the idea of "official" releases just being an automated thing. If you're instead just talking about daily builds, maybe, but we'd need to have some new way to do versioning for these. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5 performance
On Friday 13 October 2006 07:00, Martin v. Löwis wrote: > Kristján V. Jónsson schrieb: > > This is an improvement of another 3.5 %. > > In all, we have a performance increase of more than 10%. > > Granted, this is from a single set of runs, but I think we should start > > considering to make PCBuild8 a "supported" build. > > What do you mean by that? That Python 2.5.1 should be compiled with > VC 2005? Something else (if so, what)? I don't think we should switch the "official" compiler for a point release. I'm happy to say something like "we make the PCbuild8 environment a supported compiler", which means we need, at a bare minimum, a buildbot slave for that compiler/platform. Kristján, is this something you can offer? Without a buildbot for that compiler, I don't think we can claim it's supported. There's plenty of platforms we "support" which don't have buildslaves, but they're all variants of Unix - I'm happy that they are all mostly[1] sane. Anthony [1] Offer void on some versions of HP/UX, Irix, AIX -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 05:30, Georg Brandl wrote: > I'm I the only one who feels that the website is a big workflow problem? Assuming you meant "Am I", then I absolutely agree with you. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 07:34, Barry Warsaw wrote: > > i'm not volunteering to setup an automated system for this but i've > > got good ideas how to do it if i ever find time or someone wants to > > chat offline. :( > > I wish I had the cycles to volunteer to help out implementing this. :( Well, regardless of anything else, without someone doing it, it's not going to happen. I don't have the time to spend doing this. Right now, the amount of work this would save me is minimal, so I also have little or no incentive to do it. The thing that does take the time is the website - fixing that is a major investment of time, which I also don't have. Yes, had I spent the probably 20+ hours I've spent doing website stuff I could have made it a bit better, but that's what I know _now_ :) -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 12:56, Steve Holden wrote: > The real problem is the more or less complete lack of incremental > rebuild, which does make site generation time-consuming. That's _part_ of it. There's other issues. For instance, there's probably 4 places where the "list of releases" is stored. Every time I do a release, I need to update all of these. If it's a new release, I also have to update the apache config for the /X.Y.Z redirect (anyone who thinks a default URL of www.python.org/download/releases/X.Y.Z is a good idea needs to quit drinking before lunchtime ) Creating a new release area, or hell, even a new page, is a whole pile of fiddly files. These still don't make sense to me - I end up copying an existing page each time, then reading through them looking for the relevant pieces of text. Personally, I can mostly deal with the reST now, although it still trips me up on a regular basis. YAML as well is just way more complexity - I don't understand the syntax, but it appears to offer massively more than we actually use. > The advantage of pyramid implementation was the regularisation of the > site data. Sure - and hopefully if we go down another path we can get that out. > To retain the advantages of source control this might mean using scripts > to generate database content from SVN-controlled data files. Or > something [waves hands vaguely and steps back hopefully]. The other thing to watch out for is that I (or whoever) can still do local work on a bunch of different files, then check it in all in one hit once it's done and checked. This was an issue I had with the various wiki-based proposals, I haven't seen many wikis that allow this. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why spawnvp not implemented on Windows?
On Friday 13 October 2006 10:46, Alexey Borzenkov wrote: > But the fact that I have to use similar code anywhere I need to use > spawnlp is not fair. Notice that _spawnvpe is simply a clone of > _execvpe from os.py, maybe if the problem is new API in c source, this > approach could be used in os.py? Oddly, "fair" isn't a constraint in PEP-0006. Backwards and forwards compatibility between all point releases in a major release is. Adding it to os.py rather than C code doesn't make a difference. > P.S. Although it's a bit stretching, one might also say that > implementing spawn*p* on windows is not actually a new feature, and > rather is a bugfix for misfeature. Why every other platform can > benefit from spawn*p* and only Windows can't? This just makes > os.spawn*p* useless: it becomes unreliable and can't be used in > portable code at all. "One" might say that. I wouldn't. It stays out until 2.6. Sorry Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
> For reference, here's my effbot.org release procedure: > > 1) upload the distribution files one by one, as soon as they're > available. all links and stuff will appear automatically > > 2) update the associated description text through the web, when > necessary, as an HTML fragment. click "save" to publish. > > 3) mail out an announcement when everything looks good. > > Maybe I should offer Anthony to do the releases via effbot.org instead? First off - I'm not going to be posting 10M or 16M files through a web-browser. That's insane :-) The bit of the website that's dealing with the actual files is not the tricky bit - I have a dinky little python script that generates the download table. The problems are with the other bits of the pages. I keep thinking "next release, I'll automate it further", but never have time on the day. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 16:59, Fredrik Lundh wrote: > yeah, but *you* are doing it. if the server did that, Martin and > other trusted contributors could upload the files as soon as they're > available, instead of first transferring them to you, and then waiting > for you to find yet another precious time slot to spend on this release. Sure - I get that. There's a couple of reasons for me doing it. First is gpg signing the release files, which has to happen on my local machine. There's also the variation in who actually builds the releases; at least one of the Mac builds was done by Bob I. But there could be ways around this. I don't want to have to ensure every builder has scp, and I'd also prefer for it to all "go live" at once. A while back, the Mac installer would follow up "some time" after the Windows and source builds. Every release, I'd get emails saying "where's the mac build?!" > > The problems are with the other bits of the pages. I keep thinking "next > > release, I'll automate it further", but never have time on the day. > > that's why you have to have an overall infrastructure that lets you make > incremental tweaks to the tool chain, so things can get a little better > all the time. Pyramid obviously isn't such a system. I can't disagree with this. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Friday 13 October 2006 20:35, Bob Ippolito wrote: > With most consumer connections it's a lot faster to download than to > upload. Perhaps it would save you a few minutes if the contributors > uploaded directly to the destination (or to some other fast server) > and you could download and sign it, rather than having to scp it back > up somewhere from your home connection. I actually pull them down to both dinsdale and home, then verify they're the same with SHA and MD5 before signing, and uploading the keys. The only thing I upload directly are the keys and the source tarballs. > Given any Mac OS X 10.4 machine, the builds could happen > automatically. Apple could probably provide one if someone asked. They > did it for Twisted. Or maybe the Twisted folks could appropriate part > of that machine's time to also build Python. We have one, macteagle. For some reason builds fail on it right now - Ronald might be able to supply more details as to why. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Sunday 15 October 2006 21:23, Steve Holden wrote: > Martin v. Löwis wrote: > > Steve Holden schrieb: > >>>>The other thing to watch out for is that I (or whoever) can still do > >>>> local work on a bunch of different files > >>> > >>>the point of my previous post is that you *shouldn't* have to edit a > >>>bunch of different files to make a new release. > >> > >>Indeed. I seem to remember suggesting a while ago on pydotorg that > >>whatever replaces pyramid should cater to groups such as the release > >>team by allowing everything necessary to be generated from a simple set > >>of data that wouldn't be difficult to maintain. Anthony has enough on > >>his plate without having to fight the web server too ... > > > > There is always some sort of text that accompanies a release. That has > > to be edited to be correct; a machine can't do that. > > OK. > > ^everything^the content structure and many of the files^ If you compare the various pieces that make up the release pages, you'll see that much of it is boilerplate, true. There's two cases worth mentioning: First release of a new series (2.4.4c1, 2.5a1). This involves making the new directory and all the little fiddly files. In practice, this is done by recursively copying the previous release and removing the .ssh directories so that it can be re-added. I then go through and update the files. Subsequent release. This is still largely a manual process - I search for all the references to the previous release, update them, then read through it for missed bits. I then update the text bits that need to be changed. There's all sorts of minor variations there - for instance, often in a non-final release, we don't have an unpacked version of the documentation (but sometimes we do, wah). The killer bits for me are all the other places. For instance, updating the sidebar menu quicklinks for 2.4.4 to 2.5. There's just too many files, and the structure of pyramid's files still doesn't make sense to me. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.utime on directories: bug fix or new feature?
On Sunday 15 October 2006 23:35, Aahz wrote: > On Sun, Oct 15, 2006, "Martin v. L?wis" wrote: > > Should I backport the patch to 2.5, as it is a bug that you can modify > > the time stamps of regular files but not directories? Or should I > > not backport as it is a new feature that you can now adjust the time > > stamps of a directory, and couldn't before? > > My vote is that it's a bugfix but should be treated as a new feature and > rejected for 2.5, based on the standard argument about capabilities and > the problems with bugfix releases having new capabilities. Since it wasn't possible in earlier than 2.5 either, I'd say it's on the edge of being a bugfix. Let's be conservative and not backport it, since it's also a pretty marginal feature. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Tuesday 17 October 2006 18:54, Fredrik Lundh wrote: > Martin v. L�wis wrote: > > In 2.3.6, there wouldn't just be that change, but also a few other > > changes that have been collected, some relevant for Windows as well > > why not just do a "2.3.5+security" source release, and leave the rest to > the downstream maintainers? I think we'd need to renumber it to 2.3.6 at least, otherwise there's the problem of distinguishing between the two. I'd _hope_ that all the downstreams will have picked up the patch (if you know of someone who hasn't, let me know and I'll kick them for you if it would help). But I'm certainly thinking if there's a 2.3.6, it's going to be 2.3.5 with the email fix and the unicode repr() fix, and that's it. No windows or Mac binaries - they'll be pointed to the perfectly fine 2.3.5 binary installers. And no, I'm not doing another 2.2 release :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.6 for the unicode buffer overrun
On Tuesday 17 October 2006 19:09, Fredrik Lundh wrote: > > But I'm certainly thinking if there's a 2.3.6, it's going to be 2.3.5 > > with the email fix and the unicode repr() fix, and that's it. > > sounds good to me. how much work would that be, and if you're willing to > coordinate, is there anything we can do to help? Less than a normal release, since I'm not going to worry about changing the docs, the windows installers or the mac installers. I'll look at it next week, once 2.4.4 final is done. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BRANCH FREEZE release24-maint, Wed 18th Oct, 00:00UTC
I'm declaring the branch frozen for 2.4.4 final from 00:00 UTC (that's about 8 hours from now). The release will either be Wednesday 18th or Thursday 19th. There's a blocking bug http://www.python.org/sf/1578513 - I've attached a patch for it, if someone with autoconf knowledge wants to review that it can be checked in. It _should_ be good, and probably needs to be applied to release25-maint and the trunk as well. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] svn.python.org down
On Wednesday 18 October 2006 00:59, Grig Gheorghiu wrote: > FYI -- can't do svn checkouts/updates from the trunk at this point. > > starting svn operation > svn update --revision HEAD > in dir /home/twistbot/pybot/trunk.gheorghiu-x86/build (timeout 1200 secs) > svn: PROPFIND request failed on '/projects/python/trunk' > svn: PROPFIND of '/projects/python/trunk': could not connect to server > (http://svn.python.org) It works for me. Can you connect to port 22 on svn.python.org? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] svn.python.org down
Ah - the svn-apache server was down. I've restarted it. We should probably put some monitoring/restarting in place for those servers - if someone wants to volunteer a script I'll add it to cron, or I'll write it myself when I get a chance. (I was testing with svn+ssh, it was the http version that was down) Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.4.4, Final.
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.4 (FINAL). Python 2.4.4 is a bug-fix release. While Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.4. This is the final planned release from the Python 2.4 series. Future maintenance releases will be in the 2.5 series, beginning with 2.5.1. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 80 bugs squished in this release, including a number found by the Coverity and Klocwork static analysis tools. We'd like to offer our thanks to both these firms for making this available for open source projects. * Python 2.4.4 contains a fix for PSF-2006-001, a buffer overrun * * in repr() of unicode strings in wide unicode (UCS-4) builds. * * See http://www.python.org/news/security/PSF-2006-001/ for more. * There's only been one small change since the release candidate - a fix to "configure" to repair cross-compiling of Python under Unix. For more information on Python 2.4.4, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.4 Highlights of this new release include: - Bug fixes. According to the release notes, at least 80 have been fixed. This includes a fix for PSF-2006-001, a bug in repr() for unicode strings on UCS-4 (wide unicode) builds. Enjoy this release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpHQFKzDQCYF.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] state of the maintenance branches
OK - 2.4.4 is done. With that, the release24-maint branch moves into dignified old age, where we get to mostly ignore it, yay! Unless you really feel like it, I don't think there's much point to making the effort to backport fixes to this branch. Any future releases from that branch will be of the serious security flaw only variety, and are almost certainly only going to have those critical patches applied. Either this weekend or next week I'll cut a 2.3.6 off the release23-maint branch. As previously discussed, this will be a source-only release - I don't envisage making documentation packages or binaries for it. Although should we maybe have new doc packages with the newer version number, just to prevent confusion? Fred? What do you think? I don't think there's any need to do this for 2.3.6c1, but maybe for 2.3.6 final? For 2.3.6, it's just 2.3.5 plus the email fix and the PSF-2006-001 fix. As I feared, I've had a couple of people asking for a 2.3.6. Oh well. Only one person has (jokingly) suggested a new 2.2 release. That ain't going to happen :-) I don't even want to _think_ about 2.5.1 right now. I can't see us doing this before December at the earliest, and preferably early in 2007. As far as I can see so far, the generator+threads nasty that's popped up isn't going to affect so many people that it needs a rushed out 2.5.1 to cover it - although this may change as the problem and solution becomes better understood. Anyway, all of the above is open to disagreement or other opinions - if you have them, let me know. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PSF Infrastructure has chosen Roundup as the issue tracker for Python development
Thanks to the folks involved in this prcocess - I'm looking forward to getting the hell away from SF's bug tracker. :-) Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.3.6, release candidate 1
On behalf of the Python development team and the Python community, I'm announcing the release of Python 2.3.6 (release candidate 1). Python 2.3.6 is a security bug-fix release. While Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.3. Unlike the recently released 2.4.4, this release only contains a small handful of security-related bugfixes. See the website for more. * Python 2.3.6 contains a fix for PSF-2006-001, a buffer overrun * in repr() of unicode strings in wide unicode (UCS-4) builds. * See http://www.python.org/news/security/PSF-2006-001/ for more. This is a **source only** release. The Windows and Mac binaries of 2.3.5 were built with UCS-2 unicode, and are therefore not vulnerable to the problem outlined in PSF-2006-001. The PCRE fix is for a long-deprecated module (you should use the 're' module instead) and the email fix can be obtained by downloading the standalone version of the email package. Most vendors who ship Python should have already released a patched version of 2.3.5 with the above fixes, this release is for people who need or want to build their own release, but don't want to mess around with patch or svn. Assuming no major problems crop up, a final release of Python 2.3.6 will follow in about a week's time. Python 2.3.6 will complete python.org's response to PSF-2006-001. If you're still on Python 2.2 for some reason and need to work with UCS-4 unicode strings, please obtain the patch from the PSF-2006-001 security advisory page. Python 2.4.4 and Python 2.5 have both already been released and contain the fix for this security problem. For more information on Python 2.3.6, including download links for source archives, release notes, and known issues, please see: http://www.python.org/2.3.6 Highlights of this new release include: - A fix for PSF-2006-001, a bug in repr() for unicode strings on UCS-4 (wide unicode) builds. - Two other, less critical, security fixes. Enjoy this release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgp4EtX0NCP6g.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r52482 - in python/branches/release25-maint: Lib/urllib.py Lib/urllib2.py Misc/NEWS
On Saturday 28 October 2006 03:13, andrew.kuchling wrote: > 2.4 backport candidate, probably. FWIW, I'm not planning on doing any more "collect all the bugfixes" releases of 2.4. It's now in the same category as 2.3 - that is, only really serious bugs (in particular, security related bugs) will get a new release, and then only with the serious bugfixes applied. One active maintenance branch is quite enough to deal with, IMHO. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] build bots, log output
On Saturday 28 October 2006 23:39, Georg Brandl wrote: > Hi, > > I wonder if it's possible that the build bot notification mails that go > to python-checkins include the last 10-15 lines from the log. This would > make it much easier to decide whether a buildbot failure is an old, > esoteric one (e.g. A better solution (awaiting sufficient round-tuits) would be to add an option to regrtest that's used by the buildslaves that uses particularly markup around success/fail indications. The buildmaster can pick those up, and keep track of existing pass/fails. Then it could send an email only when one changes. We might also add a daily or every couple of days reminder saying "The following tests are failing on the following platforms, and have been for X days now". Buildmaster code is on dinsdale, in (I think) ~buildbot. It's also in SVN. This solution doesn't require changes to the buildslave code at all - only to the buildmaster and to regrtest. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.3.6, FINAL
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.3.6 (FINAL). Python 2.3.6 is a security bug-fix release. While Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.3. Unlike the recently released 2.4.4, this release only contains a small handful of security-related bugfixes. See the website for more. * Python 2.3.6 contains a fix for PSF-2006-001, a buffer overrun * in repr() of unicode strings in wide unicode (UCS-4) builds. * See http://www.python.org/news/security/PSF-2006-001/ for more. This is a **source only** release. The Windows and Mac binaries of 2.3.5 were built with UCS-2 unicode, and are therefore not vulnerable to the problem outlined in PSF-2006-001. The PCRE fix is for a long-deprecated module (you should use the 're' module instead) and the email fix can be obtained by downloading the standalone version of the email package. Most vendors who ship Python should have already released a patched version of 2.3.5 with the above fixes, this release is for people who need or want to build their own release, but don't want to mess around with patch or svn. There have been no changes (apart from the version number) since the release candidate of 2.3.6. Python 2.3.6 will complete python.org's response to PSF-2006-001. If you're still on Python 2.2 for some reason and need to work with UCS-4 unicode strings, please obtain the patch from the PSF-2006-001 security advisory page. Python 2.4.4 and Python 2.5 have both already been released and contain the fix for this security problem. For more information on Python 2.3.6, including download links for source archives, release notes, and known issues, please see: http://www.python.org/2.3.6 Highlights of this new release include: - A fix for PSF-2006-001, a bug in repr() for unicode strings on UCS-4 (wide unicode) builds. - Two other, less critical, security fixes. Enjoy this release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgp2oqjSXQGoY.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __dir__, part 2
On Tuesday 07 November 2006 19:00, Guido van Rossum wrote: > No objection on targetting 2.6 if other developers agree. Seems this > is well under way. good work! Sounds fine to me! Less magic under the hood is less magic, and that's always a good thing. The use case for it seems completely appropriate, too. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using SCons for cross-compilation
On Thursday 09 November 2006 16:30, Martin v. Löwis wrote: > Patch #841454 takes a stab at cross-compilation > (for MingW32 on a Linux system, in this case), > and proposes to use SCons instead of setup.py > to compile extension modules. Usage of SCons > would be restricted to cross-compilation (for > the moment). > > What do you think? So we'd now have 3 places to update when things change (setup.py, PCbuild area, SCons)? How does this deal with the problems that autoconf has with cross-compilation? It would seem to me that just fixing the extension module building is a tiny part of the problem... or am I missing something? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS
On Friday 10 November 2006 01:01, A.M. Kuchling wrote: > On Thu, Nov 09, 2006 at 02:51:15PM +0100, andrew.kuchling wrote: > > Author: andrew.kuchling > > Date: Thu Nov 9 14:51:14 2006 > > New Revision: 52692 > > > > [Patch #1514544 by David Watson] use fsync() to ensure data is really on > > disk > > Should I backport this change to 2.5.1? Con: The patch adds two new > internal functions, _sync_flush() and _sync_close(), so it's an > internal API change. Pro: it's a patch that should reduce chances of > data loss, which is important to people processing mailboxes. > > Because it fixes a small chance of potential data loss and the new > functions are prefixed with _, my personal inclination would be to > backport this change. Looking at the patch, the functions are pretty clearly internal implementation details. I'm happy for it to go into release25-maint (particularly because the consequences of the bug are so dire). Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r52692 - in python/trunk: Lib/mailbox.py Misc/NEWS
On Friday 10 November 2006 13:45, A.M. Kuchling wrote: > OK, I'll backport it; thanks! > > (It's not fixing a frequent data-loss problem -- the patch just > assures that when flush() or close() returns, data is more likely to > have been written to disk and be safe after a subsequent system > crash.) Sure - it's a potential bug waiting to happen, though. And it's not a fun one :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
