[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 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 -- python-committ...@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committ...@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ULSWULZIBTYQ5GRBTLRQGNKQ525S7WJC/ Code of Conduct: http://python.org/psf/codeofconduct/
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 ba...@python.org 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 python-committ...@python.org http://mail.python.org/mailman/listinfo/python-committers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 - 3000 code transition?
I'm planning on re-presenting it at the local google office in the next couple of weeks. I might try and arrange for it to be recorded and put online. At the moment we seem to have a real lack of concrete information for people about the transition. If I had time (ha! HA!) I'd try to turn the slides into a series of articles. Right now, there's the What's New In Python 3.0, and the PEPs. The former isn't complete yet (obviously) and isn't all that detailed. The latter is a whole pile of text, some relevant and some not so much. Anthony On Wed, Aug 13, 2008 at 10:09 PM, Trent Nelson [EMAIL PROTECTED] wrote: (*) slides: http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf Hilarious! Seems like that would have been a riot of a session to attend. (I'm kicking myself for attending some other uninteresting talk when yours was on.) Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 - 3000 code transition?
Last time I looked at it, the C API wasn't nailed down yet. That's why I passed over it entirely for my tutorial. The only advice I was able to give was that if your extension is just a wrapper around existing C code, you might be better off rewriting it using ctypes. That way it should work on both 2.6 and 3.0. This doesn't work for PyCXX, of course :-( On Fri, Jul 25, 2008 at 8:33 AM, Barry Scott [EMAIL PROTECTED] wrote: On Jul 21, 2008, at 22:37, Lennart Regebro wrote: On Mon, Jul 21, 2008 at 20:16, Brett Cannon [EMAIL PROTECTED] wrote: But waiting until all the betas have gone out totally defeats the purpose of the betas! I agree. Writing an actual *guide* can wait, but documenting the differences with code examples is a work that can start now, and I agree that it would be great if this would start now. But writing a guide might not be a good idea until we know what the changes are, and if the API is changing quickly now we don't. :-) I'm working on getting a version of PyCXX working with Python 3.0. The lack of any docs outside of the header files is making this a slow process. I think its a mistake to expect a serious beta test of extensions when you have no guide to the changes in the C API. If you had a guide then diff it between releases would be a guide to what need fixing up going from beta to beta to rc. Oh and I'm not going to try and make a version of PyCXX that works on 2.x and 3.x as the changes are too fundamental. Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anthony%40interlink.com.au ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 - 3000 code transition?
As a data point, I just presented a tutorial here at OSCON on Python 3 Porting, and had a number of people asking about C API changes. I punted for my talk (*) because things are still in flux. Plus I only had 3 hours. I did suggest that if your extension is just glue to a C library, you should consider using ctypes. So yes, collecting this information, even if it's just in a wiki page, would be a good and popular thing. Anthony (*) slides: http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf On Mon, Jul 21, 2008 at 2:37 PM, Lennart Regebro [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 20:16, Brett Cannon [EMAIL PROTECTED] wrote: But waiting until all the betas have gone out totally defeats the purpose of the betas! I agree. Writing an actual *guide* can wait, but documenting the differences with code examples is a work that can start now, and I agree that it would be great if this would start now. But writing a guide might not be a good idea until we know what the changes are, and if the API is changing quickly now we don't. :-) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anthony%40interlink.com.au ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] summaries not arriving
On Monday 10 September 2007, Paul Dubois wrote: As a small boy I once knew wrote, I must not use bad words. (:- It's OK to use them about Barry, though, surely? *wave* Hi Barry. -- Anthony Baxter, ekit. [EMAIL PROTECTED] (03) 9674 7015 Level 3 The Teahouse, 28 Clarendon St, Sth Melbourne Australia 3205 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alpha/Tru64 buildbot and SSL compile
On Tuesday 11 September 2007, Martin v. Löwis wrote: The Alpha/Tru64 buildbot seems to be having difficulty compiling the _ssl.c file. Looks like missing header files. Anyone know what the configuration of OpenSSL on that machine is like? Neal Norwitz and Ralf Grosse-Kunstleve have access to that machine. Neal's on leave all this month, I believe. -- Anthony Baxter, ekit. [EMAIL PROTECTED] (03) 9674 7015 Level 3 The Teahouse, 28 Clarendon St, Sth Melbourne Australia 3205 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need Survey Answers from Core Developers
On Saturday 19 May 2007, [EMAIL PROTECTED] wrote: Jeff 1) How is the project governed? How does the community make Jeffdecisions on what goes into a release? Consensus (most of the time) and GvR pronouncements for significant changes. There are situations where Guido has simply pronounced when the community seemed unable to settle on one solution. Decorators come to mind. Plus of course there's the minor detail of features needing to be implemented. If no-one steps up to complete something, it can just get deferred. See PEP 356's list of deferred features. Jeff 2) Does the language have a formal defined release plan? JeffI know Zope 3's release plan, every six months, but not that of JeffPython. Is there a requirement to push a release out the door Jeffevery N months, as some projects do, or is each release Jeffseparately negotiated with developers around a planned set Jeffof features? PEP 6? PEP 101? PEP 102? There is no hard-and-fast time schedule. I believe minor releases leave the station approximately every 18-24 months, micro releases roughly every six months. The goal is to have a major release (I consider 2.5, 2.6 c to be major, and 2.5.1, 2.5.2 c minor - this is how it's always been, afaik) when they're done. Typically this is around 18-24 months. There's not (yet?) a formal release plan for the minor/bugfix releases, but they've been every 6 months since late 2003. Obviously, if a major bug is found then a release happens sooner. Jeff 3) Some crude idea of how many new major and minor features were Jeffadded in the last release? Yes, I know this is difficult -- the Jeffidea it so get some measure of the evolution/stability of cPython Jeffre features. Jython and IronPython are probably changing rapidly Jeff-- cPython, not such much. We don't break down major or minor features, but according to the What's New In Python 2.5 doc: A search through the SVN change logs finds there were 353 patches applied and 458 bugs fixed between Python 2.4 and 2.5. (Both figures are likely to be underestimates.) The distinction between major and minor feature is pretty arbitrary, obviously. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
On Thursday 17 May 2007, Aahz wrote: On Wed, May 16, 2007, Josiah Carlson wrote: I'm not sure how effective the question/answer stuff is, but a bit of javascript seems to be a good idea. Just for the record (and to few people's surprise, I'm sure), I am entirely opposed to any use of JavaScript. What about flash, instead, then? /ducks -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
On Saturday 12 May 2007, [EMAIL PROTECTED] wrote: Since there is (generally?) an attempt to make one last bug fix release of the previous version after the next major version is released, should that be mentioned? To make it concrete, I believe shortly after 2.5.0 was released the final bug fix release of 2.4 (2.4.4?) was released. Correct. Note that this is only something that's been in place while I've been doing it. The current standard for how we do releases is just something I made up as I went along, including - regular 6-monthly bugfix releases - only one maintenance branch (most recent) for the bugfix releases - the last bugfix release of the previous release after a new major release. I'm OK with these being formalised - but any additional requirements I'd like to discuss first :-) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] best practices stdlib: purging xrange
I'd like to suggest that we remove all (or nearly all) uses of xrange from the stdlib. A quick scan shows that most of the usage of it is unnecessary. With it going away in 3.0, and it being informally deprecated anyway, it seems like a good thing to go away where possible. Any objections? Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5 branch unfrozen
Ok, things seem to be OK. So the release25-maint branch is unfrozen. Go crazy. Well, a little bit crazy. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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.1, FINAL
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.1 (FINAL) This is the first bugfix release of Python 2.5. Python 2.5 is now in bugfix-only mode; no new features are being added. According to the release notes, over 150 bugs and patches have been addressed since Python 2.5, including a fair number in the new AST compiler (an internal implementation detail of the Python interpreter). This is a production release of Python, and should be a painless upgrade from 2.5. Since the release candidate, we have backed out a couple of small changes that caused 2.5.1 to behave differently to 2.5. See the release notes for more. For more information on Python 2.5.1, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.1/ Highlights of this new release include: Bug fixes. According to the release notes, at least 150 have been fixed. Highlights of the previous major Python release (2.5) are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Anthony Anthony Baxter [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) pgpIqpS4BdDy1.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] my 2.5 checkins
On Saturday 14 April 2007 10:07, Kristján Valur Jónsson wrote: Hello all. I made two checkins to the 25 maintainance branch before Martin kindly pointed out to me that it is frozen. These are quite simple fixes to real crashes I have experienced. The fix in frameobject.c will be necessary if you work with opcodes 128, which we routinely do at CCP J. Security through opcode randomization Anyway, just let me know if you like me to roll them back. I really, really, really don't want to cut another release candidate. These fixes don't strike me as critical enough to need that - and I'm not happy to do the release and just hope. I'll roll them all back. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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.1 release candidate
On Wednesday 11 April 2007 07:07, Martin v. Löwis wrote: Raymond Hettinger schrieb: It looks like the release candidate has been held-up for a bit. If it is going to stay held-up for a few days, can we unfreeze it so some bugfixes can go in (fixing the +0/-0 problem, eliminating some segfaults, and fixing some exception code)? No, the release binaries are all produced, and just await upload. Apologies for the delay in the uploading - some stuff came up over the Easter break, and then the website wouldn't rebuild (David and Andrew fixed the latter, yay!) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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 Survey on Defect Management Practices in Free/Open Source Software
On Wednesday 04 April 2007 14:44, Anu Gupta DCSA wrote: Dear Python Contributors, I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study on practices and problems of defect management in various Free/Open Source Software projects. The Just a random aside - is anyone else getting increasingly annoyed by these mass-mailed out survey requests from students? I must get a several a week now. This one was at least personally addressed (well, to Python Contributors), which is a step ahead of most of them. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] branch is frozen for release of 2.5.1c1 (and 2.5.1)
Please stay out of the 2.5 branch unless you're one of the release team - I'm cutting 2.5.1c1 at the moment. There will be a 2.5.1 final next week, assuming all goes well. If you have an urgent bugfix you need in, please post here and get someone to approve it before the checkin! Thanks, Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Standard Image and Sound classes (was: SoC proposal: multimedia library)
On Tuesday 27 March 2007 11:03, Lino Mastrodomenico wrote: 2007/3/26, Pete Shinners [EMAIL PROTECTED]: My main question is what is the image and sound container passed back to Python? This single thing along would be worth a SoC if it could be implemented across all libraries. Will your image objects be transferrable to PIL, Pygame, PyOpengl, Numpy, Pythonmagick, Pycairo, wxPython, etc? It would be best if this could avoid the fromstring/tostring mojo that always requires and extra copy of the data for each transfer. I agree. I withdrew my original multimedia library idea and submitted a proposal for the creation of two standard Image and Sound classes. Ideally you'd hook this into the standard library's existing sound file handling modules. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5.1, buildbots and my availability
I'm moving house today and tomorrow, and don't expect to have internet access connected up at home til sometime next week. In the meantime, if there's urgent 2.5.1 related issues, bear with me, as I'll only be on email during the working day. cc Neal (hi Neal :) is the best bet. Also, the cygwin and ubuntu/icc buildbots will be offline in the interim - I'll be unplugging them this afternoon to move them. I can still cut the 2.5.1 release - can always do it during the day, even if the stupid ISP takes longer than I expect to connect up the net. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On Friday 16 March 2007 07:57, [EMAIL PROTECTED] wrote: Common parlance for the parts of a version number is: major.minor.micro See: http://twistedmatrix.com/documents/current/api/twisted.python.ver sions.Version.html#__init__ Changing this terminology about Python releases to be more consistent with other projects would be a a subtle, but good shift towards a generally better attitude of the expectations of minor releases. I disagree entirely. Python has major releases, and bugfix releases. At the moment, the major releases are of the form 2.x, and bugfix 2.x.y. Trying to say that 2.4-2.5 is a minor release is just nonsensical. That suggests that very little new language development would go on, at all. Now, you might be arguing that in fact very little should go on (I know some people have argued this, I can't remember if you were one of these). My standard response to this is that people who really feel like this are welcome to pick a release, say, 2.3, and take on the process of backporting the relevant bugfixes back to that release, and cutting new releases, c. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On Thursday 15 March 2007 08:54, Martin v. Löwis wrote: The bug fix may also break existing applications. Hence it cannot go into 2.5.1 but has to wait for 2.6. Steering clear of the rest of the discussion, I'd just like to give a hearty +1 for this not going into 2.5.x in any way shape or form. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backports of standard library modules
:) is that, when I go to the downloads page for Python 2.3, in addition to downloading Python, I could download all the compatible libraries which were included in later versions as a single installable file. When 2.6 comes out, this extras package would be upgraded to include any new modules in 2.6. Not a lot of fun for people who live on the bleeding edge, but very useful for people who are stuck with an older version for political or other reasons. If you, or someone else, is willing to do the work to do this, I don't think anyone would mind. There is (as Martin also stated) zero chance that I will do this additional work. It scratches no itches for me, and has the potential to add an enormous amount to my workload of doing a new release. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] version-specific PYTHONPATH env var
What do people think about the idea of a version-specific PYTHONPATH environment variable? Something like PYTHON25PATH or the like. Reason I ask is that on our production systems, we have a couple of versions of Python being used by different systems. Yes, yes, in a perfect world they'd be all updated at the same time, sure. There's occasionally issues with the PYTHONPATH being pointed at something like .../lib/python2.4/site-packages or the like, and then have issues when python2.3 or some other different version is run. If we allowed people to optionally specify a more specific version this problem would go away. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 20:24, Martin v. Löwis wrote: It might be that individuals get designated maintainers: Guido maintains list and tuple, Tim maintaines dict, Raymond maintains set, I maintain configure.in. However, I doubt that would work in practice. That approach would simply give us many many single points of failure. For instance, you're maintaining a particular module but at the time an important bug/patch comes up, you're off on holidays, or busy, or the like. Sure, you could say this person is primary, and this person is backup but hell, there's a lot of different components that make up Python. That would be a maintenance and management nightmare. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary: rejection of 'dynamic attribute' syntax
On Thursday 15 February 2007 21:48, Steve Holden wrote: Greg Ewing wrote: Steve Holden wrote: A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing. Oh, great. Now we're going to have to run our benchmarks in a temperature-controlled oven... ... with the fan running at constant speed :) Unless the fans are perfectly balanced, small changes in gravity are going to affect the rate at which they spin. So I guess the position of the moon will affect it :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Wrapping up 'dynamic attribute' discussion
On Friday 16 February 2007 09:08, Ben North wrote: Instead of new syntax, a new wrapper class was proposed, with the following specification / conceptual implementation suggested by Martin Loewis: ...snip... This was considered a cleaner and more elegant solution to the original problem. The decision was made that the present PEP did not meet the burden of proof for the introduction of new syntax, a view which had been put forward by some from the beginning of the discussion. The wrapper class idea was left open as a possibility for a future PEP. A good first step would be to contribute something like this to the Python Cookbook, if it isn't already there. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of dynamic attribute access discussion
On Wednesday 14 February 2007 07:39, Aahz wrote: My point is that I suspect that general objects are not used much with getattr/setattr. Does anyone have evidence counter to that? I think that evidence should be provided before this goes much further; perhaps all that's needed is education and documentation. Ok. I just spent a little time looking in the top level of the stdlib. I count 102 uses of 2-arg getattr. Here's what getattr() is used for: Putting aside all of the stuff that does introspection of objects (pydoc, cgitb, copy, c - I don't care that these have a slightly more verbose spelling, since writing this sort of introspection tool is hardly a common thing to do throughout a codebase) there's really only three use cases: - Cheap inheritence, ala def __getattr__(self, attr): return getattr(self.socket, attr) - Method lookup by name - as I suspected, this is the #1 use case. - Looking things up in modules - you're generally only going to do a small amount of this, once per module. The other uses of it make up a fairly small handful - and looking at them, there's better ways to do some of them. setattr is even less used. Most uses of it are for copying the attributes of one object en masse to another object. This can be encapsulated in a quickie function to do the work. So based on this quick survey, I _strongly_ question the need for the new syntax. New syntax should need to vault vastly higher hurdles before getting into Python - it's just not possible to write code that's backwards compatible once you add it. I just don't see that this comes even close. We're already looking at a big discontinuity with 2.x - 3.x in terms of compatibility, I think adding another for 2.5-2.6, for what I consider a marginal use case is VERY BAD. Something like the attrview (or attrdict, the name I'd use) _can_ be done in a backwards compatible way, where people can distribute a workalike with their code. I doubt I'd use it, either, but it's there for people who need it. I again ask for examples of other compelling uses that wouldn't be better solved by using a dictionary with keys rather than an object with attributes. Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of dynamic attribute access discussion
On Wednesday 14 February 2007 03:03, Guido van Rossum wrote: Not to me -- magic objects are harder to grok than magic syntax; the magic syntax gives you a more direct hint that something unusual is going on than a magic object. Also, Nick's examples show (conceptual) aliasing problems: after x = attrview(y), both x and y refer to the same object, but use a different notation to access it. Just touching on this - I meant to earlier. I'm really unsure why this is a problem. We already have similar cases, for instance dict.keys()/values()/items(). The globals() and locals() builtins also provide an alternate view with different notation to access it. Since you're creating the view explicitly, I really don't see the problem - any more than say, creating a set from a list, or a dict from a list, or the like. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
On Tuesday 13 February 2007 10:10, Ben North wrote: (Gently wandering off-topic, but: do people use proportional fonts for coding? Doesn't it cause general awkwardness for indentation, especially relevant for python?) The killer problem with backticks (to pick the syntax that currently causes this problem the most) is with webpages and with printed books with code. Sure, everyone can pick a font for coding that they can read, but that's not the only way you read code. This is my issue with the foo.(bar) syntax. The period is far far too small and easy to miss. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python/Python-ast.c need to be checked in?
On Monday 12 February 2007 13:57, Brett Cannon wrote: On 2/11/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/11/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Actually, the regenerating should happen immediately after commit, as this bumps the revision number of the asdl file. This means you have to make two commits per AST grammar change: one to change the grammar, and the other to update the regenerated file. Is this documented somewhere? It wouldn't hurt if there was a pointer to that documentation right next to the line in Python-ast.c that gets modified by the regeneration. (I've been wondering about this a few times myself.) Don't think so. How about this for wording for the file's documentation? /* File automatically generated by %s. This module must be committed separately from each AST grammar change; the __version__ number is set to the revision number of the commit containing the grammar change. */ Note that the welease.py script that builds the releases does a touch on the relevant files to make sure that make gets the build right. We had bugs opened at one point because the timestamps meant you needed a python interpreter to build python. I'm not _too_ stressed if the svn isn't always perfect in this regard - the number of people who are checking out svn to build their very first python interpreter would be low, I'd think. Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
I have to say that I'm not that impressed by either the 1-arg or 2-arg versions. Someone coming across this syntax for the first time will not have any hints as to what it means - and worse, it looks like a syntax error to me. -1 from me. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
On Tuesday 23 January 2007 22:27, Tim Peters wrote: Which is why I don't want binary or decimal floats to support infix % as a spelling in P3K. I don't believe floating mod is heavily used, and if so there's scant need for a one-character spelling -- and if there's a method or function name to look up in the docs, a user can read about what they're getting. While I agree with this, my only slight concern is that under 2.x (int/int)%(int) will work, while it will fail under 3.x, because int/int will return a float. Eh - we can always make 2.6 warn about the floatobject's __mod__ function being called if the -W py3k option is on, that gets us part of the way there. And if we have a -3 option or the like that also turns on maximum 3.x compat, that will enable true division, producing the warning. Like I said, it's only a slight concern... -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntax misfeature (exception)
On Sunday 21 January 2007 05:17, Josiah Carlson wrote: Neal Becker [EMAIL PROTECTED] wrote: [snip] It's not a question, it's a critique. I believe this is a misfeature since it's so easy to make this mistake. And it is going away with Py3k. Making it go away for Python 2.6 would either allow for two syntaxes to do the same thing, or would require everyone to change their except clauses. Neither is very desireable (especially if writing code for 2.6 makes it not work for 2.5). Note that we do plan to add except a as b to 2.6 - we're just not ripping out the old way of doing it. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The bytes type
On Wednesday 17 January 2007 05:52, James Y Knight wrote: Yes, this is it. As a refinement: if the New Way can easily be backported to 2.5, Um - 2.5 is _done_. Released. In maintenance mode. New features will not be getting backported to a 2.5.x release. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Warning for 2.6 and greater
On Friday 12 January 2007 19:19, Martin v. Löwis wrote: Georg Brandl schrieb: It has always been planned that in those cases that allow it, the new way to do it will be introduced in a 2.x release too, and the old way removed only in 3.x. What does that mean for the example James gave: if dict.items is going to be an iterator in 3.0, what 2.x version can make it return an iterator, when it currently returns a list? There simply can't be a 2.x version that *introduces* the new way, as it is not merely a new API, but a changed API. There's a couple of ways I see it - we could add a -3 command line flag to enable 3.x compat, or maybe a from __future__ statement. Although the latter would be a global thing, which is different to how all existing from __future__s work, so probably not good. I don't see a path forward that doesn't involve something painful, so long as 3.0 is going to be the clean break. As I mentioned, though, I'd like as far as possible to make it so that 2.6 (with a flag) can be at least vaguely compatible with 3.0. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Warning for 2.6 and greater
On Friday 12 January 2007 21:42, [EMAIL PROTECTED] wrote: If the plan is to provide a smooth transition, it would help a lot to have this plan of foward and backward compatibility documented somewhere very public. It's hard to find information on Py3K right now, even if you know your way around the universe of PEPs. I'd like to see this happen, too - however, there's no way I can even think about it until after LCA next week. First of all, of course, we need to get agreement on the preferred way forward. FWIW, I also agree with James that Python 3 shouldn't even be released until the 2.x series has reached parity with its feature set. However, if there's continuity in the version numbers instead of the release dates, I can at least explain to Twisted users that we will _pretend_ they are released in the order of their versions. I'm not sure what parity with it's feature set means. I think there's going to be some 3.0isms that just cannot be done sanely in 2.x - for instance, the new I/O subsystem. But I do hope that it's _possible_ to work in a version of the language that works in both 2.6+ and 3.0+, even if under the hood there are differences. For instance, if we did except foo as bar for 2.6, it might not auto-clean-up the exception object when it drops out of the except: block. I put up www.python.org/sf/1633807 a short time ago that deals with one of the big concerns I had - print vs print() (it was also as a learning exercise to figure out if it was possible, and how it might work). Something similar could probably be done for exec(). I suspect the problem cases are going to be things like the dictionary code - your idea (in another email) of trying to look up globals would probably cause a horrible performance issue, but it may be possible to do _something_ clever. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Warning for 2.6 and greater
On Thursday 11 January 2007 07:48, Thomas Wouters wrote: They serve a different purpose, and it isn't taking any time away from me (or Anthony, I can confidently guess) working on 2to3. Correct. Note that checking for something like dict.has_key is going to be far far more reliable from inside the interpreter. Heck, one of the PEP-3xxx's actually calls for doing this. I'm all for helping people to prepare for 3.0, since I don't want to see it languish in Perl 6 country. At the same time I agree with Raymond that migration to 3.0 can't be allowed to place obstacles in the way of 2.X users. They shouldn't be penalised for using 2.X, particularly if they are new to the language, otherwise we will run the risk of adversely affecting the Python adoption rate - which I hope no reader of this list wants. So, why not a new warning category: MigrationWarning? I believe Anthony suggested Py3KDeprecationWarning or such. I don't think the name really matters. Correct. In addition, please read what I posted - these warnings are off by default, and won't go through the warnings mechanism at all unless you specify the command line flag. I've had a number of people say that this is something they would really, really like to see - the idea is both to let people migrate more easily, and provide reassurance that it won't be that bad to migrate! -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Warning for 2.6 and greater
On Thursday 11 January 2007 06:32, Georg Brandl wrote: I guess there are quite a few people who won't start moving to Python 3.0 with 2.6, or even when 3.1 is out, as long as their program works fine with the 2.x line. There's no need to punish them with extra overhead. Checking a single C global int is hardly going to make a huge impact at all. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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-3000] Warning for 2.6 and greater
cc'ing python-dev - followups should probably go there, rather than the p3yk list. So here's my latest plan: - Add a Py3KDeprecationWarning, as a subclass of DeprecationWarning (or maybe just of Warning) - Add a -W py3k shortcut, which is the same as -W once:Py3kDeprecationWarning - Add a C int (as in previous patch) that is also set to 1 if the command line flag is specified. This is because there's no easy or quick way to check that a warning has been set - and calling into the warnings code is expensive, even if the C code warnings module is done. We can revisit this if the C version of warnings grows some extra features to make this less awful. For 2.6, we make a single -t (mixing tabs and spaces) the default, and maybe add -T to suppress this. DeprecationWarning for 2.6: - `foo` (backticks) - input() The following are the list of things that get Py3kDeprecationWarnings (so far): integer division - make -Q warn the default when -W py3k specified coerce() - going away apply() - going away intern() - moving to sys (we should also move it to sys, and make intern() - call sys.intern()) file.xreadlines() - going away dict.has_key() - use 'in dict' - use != (aka MakeBarryCryDeprecationWarning) __(get|set|del)slice__ __coerce__ - gone __(div|idiv|rdiv)__ - no replacement? __nonzero__ - we should add __bool__ to 2.6, and then warn people. Not sure we can rename the nb_nonzero slot, though. For the various __foo__ slots, it might be nice to warn when they're defined, rather than used, but I've not looked into how hard this would be to do, or whether it would still work with .pyc files and the like. On the other hand, warning on use might also let us pick up when C code modules use the same functions. There's other changes that are probably too hard to warn about, because there's not an easy replacement - the exec and print statements come to mind here. Comments? What else should get warnings? Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] kill the cbsoutdoor.co.uk autoresponder
On Friday 05 January 2007 17:40, Gregory P. Smith wrote: Whoever is subscribed to python-dev with a broken corporate autoresponder that sends everyone who posts to the list this useless response multiple times please unsubscribe yourself. Its highly annoying and entirely useless since its not even identifying the list subscriber(s) deserving the blame. Can you determine the original email domain from the Received headers, perhaps? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for python SIP and MGCP stacks
On Wednesday 27 December 2006 12:15, Jenny Zhao (zhzhao) wrote: Hi Python developers, I am using python to write a testing tools, currently this tool only supports skinny protocol. I am planning to add SIP and MGCP support as well, wondering if you have written these protocol stacks before which can be leveraged from. This should go to python-list@python.org (aka comp.lang.python), not this list. This list is for development _of_ python, not development _in_ python. Thanks, Anthony ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible platforms to drop in 2.6
On Sunday 24 December 2006 00:19, Andrew MacIntyre wrote: Of course, if the project management decide that even the EMX support should be removed from the official tree - so be it; I will just have to maintain the port outside the official tree. I feel that so long as there's an active maintainer for a port, it can and should stay. It's the older systems where we have no maintainer and no way to check if it's still working that are the problem. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LSB: Selection of a Python version
On Tuesday 05 December 2006 17:30, Martin v. Löwis wrote: People at the meeting specifically said whether security patches would still be applied to older releases, and for how many older releases. Linux distributors are hesitant to make commitments to maintain a software package if they know that their upstream source doesn't provide security patches anymore. I agree we should have a written policy. At the moment, my policy is this: normal bugfixes for 2.5 critical crasher bugfix releases for 2.5 and 2.4 security bugfix releases for 2.5, 2.4, and 2.3. I'm planning on dropping 2.3 from this list sometime next year. After that, I guess we can produce officially blessed patches or something. I think we should come up with a policy for dealing with security patches (there haven't been that many in the past, anyway); I believe users (i.e. vendors in this case) would be happy with the procedure we followed for 2.3: just produce a source release integrating the security patches; no need for binary releases (as they will produce binaries themselves). Depends - while 2.4 is officially retired now, if a security bugfix that affects windows/OS X comes up, I think we should still cut binary releases. So I think a public statement that we will support 2.4 with security patches for a while longer (and perhaps with security patches *only*) would be a good thing - independent of the LSB, actually. Well, I don't know what sort of public statement you want to issue, but will this do? (Wearing my release manager hat) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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 and the Linux Standard Base (LSB)
On Tuesday 28 November 2006 23:19, Robin Bryce wrote: python2.4 profile (pstats) etc, was removed due to licensing issues rather than FHS. Should not be an issue for python2.5 but what, in general, can a vendor do except break python if their licensing policy cant accommodate all of pythons batteries ? That's a historical case, and as far as I know, unique. I can't imagine we'd accept any new standard library contributions (no matter how compelling) without the proper licensing work being done. python2.4 distutils is excluded by default. This totally blows in my view but I appreciate this one is a minefield of vendor packaging politics. It has to be legitimate for Python / setuptools too provide packaging infrastructure and conventions that are viable on more than linux. Is it unreasonable for a particular vendor to decide that, on their platform, the will disable Python's packaging conventions ? Is there any way to keep the peace on this one ? I still have no idea why this was one - I was also one of the people who jumped up and down asking Debian/Ubuntu to fix this idiotic decision. Personally, I consider any distributions that break the standard library into non-required pieces to be shipping a _broken_ Python. As someone who writes and releases software, this is a complete pain. I can't tell you how many times through the years I'd get user complaints because they didn't get distutils installed as part of the standard library. (The only other packaging thing like this that I'm aware of is python-minimal in Ubuntu. This is done for installation purposes and wacky dependency issues that occur when a fair chunk of the O/S is actually written in Python. It's worth noting that the entirety of the Python stdlib is a required package, so it doesn't cause issues.) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Passing floats to file.seek
On Sunday 12 November 2006 22:09, Fredrik Lundh wrote: Martin v. Löwis wrote: Patch #1067760 deals with passing of float values to file.seek; the original version tries to fix the current implementation by converting floats to long long, rather than plain C long (thus supporting files larger than 2GiB). b) if not, should Python 2.6 just deprecate such usage, or outright reject it? Python 2.5 silently accepts (and truncates) a float that's within range, so a warning sounds like the right thing to do for 2.6. note that read I agree that a warning seems best. If someone (for whatever reason) is flinging floats around where they actually meant to have ints, going straight to an error from silently truncating and accepting it seems a little bit harsh. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 wink -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 wink) 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
