[Python-Dev] RELEASED Python 3.0rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team and the Python community, I am happy to announce the third and last planned release candidate for Python 3.0. This is a release candidate, so while it is not quite suitable for production environments, we strongly encourage you to download and test this release on your software. We expect only critical bugs to be fixed between now and the final release, currently planned for 03- Dec-2008. If you find things broken or incorrect, please submit bug reports at http://bugs.python.org Please read the RELNOTES file in the distribution for important details about this release. For more information and downloadable distributions, see the Python 3.0 website: http://www.python.org/download/releases/3.0/ See PEP 361 for release schedule details: http://www.python.org/dev/peps/pep-0361/ Enjoy, - -Barry Barry Warsaw [EMAIL PROTECTED] Python 2.6/3.0 Release Manager (on behalf of the entire python-dev team) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSSbOhHEjvBPtnXfVAQLzBwP/dS2j4XhZMNdb28TG3ZblkSmlPS4IU20U Vvq85inUkJ6idwKZBqa6brrD1hbqrl4UjKZh4/ppzhIwsJtFMlMiqnkHVrvIYFBG Yg+pQdO5HQzrw9K04aTdtNiKTiiJNIkqWdQQUd573XBFODRAIaq0qwk9C24kXeZM e3xNgNRxfmY= =TvxY -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (11/14/08 - 11/21/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2194 open (+35) / 14007 closed (+18) / 16201 total (+53) Open issues with patches: 728 Average duration of open issues: 712 days. Median duration of open issues: 2043 days. Open Issues Breakdown open 2177 (+35) pending17 ( +0) Issues Created Or Reopened (56) ___ Tkinter binding involving Control-spacebar raises unicode error 11/18/08 http://bugs.python.org/issue1028reopened ocean-city patch Byte/string inconsistencies between different dbm modules11/21/08 http://bugs.python.org/issue3799reopened brett.cannon patch, needs review type of UserList instance returns class instead of instance 11/14/08 CLOSED http://bugs.python.org/issue4326created chafporte Patch: simplify complex constant assignment statements 11/14/08 http://bugs.python.org/issue4327created novalis_dt patch "Ã " in u"foo" raises a misleading error 11/15/08 http://bugs.python.org/issue4328created ezio.melotti base64 does not properly handle unicode strings 11/15/08 http://bugs.python.org/issue4329created mbecker wsgiref.validate doesn't accept arguments to readline11/16/08 CLOSED http://bugs.python.org/issue4330created ianb Can't use _functools.partial() created function as method11/16/08 http://bugs.python.org/issue4331created ssadler asyncore.file_dispatcher does not use dup()'ed fd11/17/08 CLOSED http://bugs.python.org/issue4332created christianbecke patch Reworked Dialog.py 11/17/08 http://bugs.python.org/issue4333created gpolo patch Mac Build Script is broken for 2.6 release 11/17/08 CLOSED http://bugs.python.org/issue4334created ngift inspect.getsourcelines ignores last line in module 11/17/08 http://bugs.python.org/issue4335created RafeSacks Fix performance issues in xmlrpclib 11/17/08 http://bugs.python.org/issue4336created krisvale patch, patch, easy Iteration over a map object with list() 11/17/08 CLOSED http://bugs.python.org/issue4337created jmfauth TypeError (bytes/str) in distutils command "upload" 11/17/08 CLOSED http://bugs.python.org/issue4338created hagen patch Fix set-like dictview doc11/17/08 CLOSED http://bugs.python.org/issue4339created tjreedy xmlrpc.client - default 'SlowParser' not defined 11/17/08 http://bugs.python.org/issue4340created mwatkins Update __hash__ doc 11/17/08 CLOSED http://bugs.python.org/issue4341created tjreedy (Tkinter) Please backport these 11/18/08 http://bugs.python.org/issue4342created gpolo New function in Tkinter.py: setup_master
Re: [Python-Dev] [Python-3000] 2.6.1 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 19, 2008, at 3:19 PM, Terry Reedy wrote: Let's try this for 3.0rc4 then. The current release is rc2. Skipping rc3 would confuse people'-) Yeah, my calendar was wrong, but the PEP (and more importantly... code!) was right :). There is no rc4! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSScZWXEjvBPtnXfVAQKpQAQAi9Q8rfgcCVXmQ2tIqaiAVKOQHDPQdfhF lyDWHg+6i2EGrbs0Jju5GB9YML1yNga3X85zfQSedu6mgpA4dV6NvW988N3Wp4oG ztDGT7yLxwYe4Wy606FF6lxSlXSvXQRLc/Nf1qgn8dDGskQKO2LZ+fUHW0BIWDBN RFAuZqzdWQY= =9Z8w -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding zipfile and directory execution to What's New for Python 2.6.1?
A trick we added to 2.6 that users seem to not notice is that it is now possible to execute zipfiles and directories from the command line by including a __main__.py module (that module will then be executed, but more importantly, the zipfile or directory name will be added to the beginning of sys.path so related modules can be found easily). I went looking for this in the 2.6 What's New and couldn't find anything about it (certainly not in the most obvious section - the one that describes the other changes to the interpreter command line options and environment variables). Did I just miss something? Or should more on this be added to the What's New for 2.6.1? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding zipfile and directory execution to What's New for Python 2.6.1?
On Fri, Nov 21, 2008 at 5:52 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > A trick we added to 2.6 that users seem to not notice is that it is now > possible to execute zipfiles and directories from the command line by > including a __main__.py module (that module will then be executed, but > more importantly, the zipfile or directory name will be added to the > beginning of sys.path so related modules can be found easily). > > I went looking for this in the 2.6 What's New and couldn't find anything > about it (certainly not in the most obvious section - the one that > describes the other changes to the interpreter command line options and > environment variables). > > Did I just miss something? Or should more on this be added to the What's > New for 2.6.1? Feel free to add it! There were so many new things in 2.6, that we were bound to miss a few things. > > Cheers, > Nick. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] format specification mini-language docs...
Ok, now I'm implementing __format__ support for IronPython. The format spec
mini-language docs say that a presentation type of None is the same as 'g' for
floating point / decimal values. But these two formats seem to differ based
upon how they handle whole numbers:
>>> 2.0.__format__('')
'2.0'
>>> 2.0.__format__('g')
'2'
The docs also say that 'g' prints it as fixed point unless the number is too
large. But the fixed point format differs from what 'f' would print. I guess
it didn't say they'd both print it as fixed point w/ a precision of 6 or
anything but it seems a little unclear.
>>> 2.0.__format__('g')
'2'
>>> 2.0.__format__('f')
'2.00'
Finally providing any sign character seems to cause +1.0#INF and friends to be
returned instead of inf as is documented:
>>> 10e667.__format__('+')
'+1.0#INF'
>>> 10e667.__format__('')
'inf'
Are these just doc bugs? The inf issue is the only one that seems particularly
weird to me.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 3.0rc3
On Sat, Nov 22, 2008 at 1:06 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Python development team and the Python community, I am > happy to announce the third and last planned release candidate for Python > 3.0. Whoohoo! :) Great works guys! --JamesMills -- -- -- "Problems are solved by method" ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] format specification mini-language docs...
Dino Viehland wrote:
Ok, now I'm implementing __format__ support for IronPython. The format spec mini-language docs say that a presentation type of None is the same as 'g' for floating point / decimal values.
Awesome! Thanks for doing this.
>But these two formats seem to differ based upon how they handle whole
numbers:
2.0.__format__('')
'2.0'
2.0.__format__('g')
'2'
I think the docs are wrong. For floats, the PEP
(http://www.python.org/dev/peps/pep-3101/) says:
'' (None) - similar to 'g', except that it prints at least one digit
after the decimal point.
The docs also say that 'g' prints it as fixed point unless the number is too
large. But the fixed point format differs from what 'f' would print. I guess
it didn't say they'd both print it as fixed point w/ a precision of 6 or
anything but it seems a little unclear.
2.0.__format__('g')
'2'
2.0.__format__('f')
'2.00'
This is to be compatible with %-formatting:
$ ./python
Python 2.7a0 (trunk:67325, Nov 21 2008, 20:35:33)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '%f %g' % (2.0, 2.0)
'2.00 2'
Finally providing any sign character seems to cause +1.0#INF and friends to be
returned instead of inf as is documented:
10e667.__format__('+')
'+1.0#INF'
10e667.__format__('')
'inf'
Yes, that does seem odd. Let me look at it a bit and I'll comment on it,
hopefully this weekend. I have a pending fix for 2.7/3.1 to make inf
handling more consistent across platforms, it might take care of this
case, too.
Are these just doc bugs? The inf issue is the only one that seems particularly
weird to me.
Agreed.
Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 4195: Can't execute packages with -m in Python 2.6/3.0
Unless this is considered a regression... On Tue, Nov 18, 2008 at 12:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I think it crosses the line. > > On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> I need a release manager call on whether or not the proposed resolution >> of this issue goes beyond what is acceptable for a bug fix in 2.6.1. >> >> Short version: >> - Python 2.5 allowed packages to be executed with -m, but in a broken way >> - I disabled the broken way for 2.6, but didn't provide a replacement >> - The patch attached to 4195 once again allows execution of packages >> with -m, but in a clean way similar to the way directories and zipfiles >> can now be executed >> - I would like to commit that patch for 3.0/2.6.1, but I'm concerned >> that it crosses the "no new features" line >> >> Long version: >> >> There was a bug in python 2.5 that allowed a package name to be passed >> to the -m switch or runpy.run_module() and it would mostly work. >> >> However, the 'mostly' was due to the fact that doing this put the >> internal import machinery into a slightly inconsistent state: the >> interpreter was running code from inside a package, but that package >> wasn't actually present in sys.modules. This could lead to assorted hard >> to trace import-related weirdness, similar to what you can get when >> executing a file from inside a package by name. You would often get away >> with it, but good luck figuring out what is happening if things go wrong >> (and you aren't already an expert on Python import mechanics). >> >> Since the ability to execute packages wasn't intentional, I added the >> missing check to block it explicitly in 2.6 (but left it alone for 2.5). >> It seemed like a really niche feature, so I didn't figure out a clean >> replacement for it at the time. >> >> Benjamin noticed this change earlier in the 2.6 release cycle, I pointed >> out it was a deliberate change, and that's the way it stayed until after >> 2.6 was released. >> >> After the release, Andi Vajda (from the JCC project [1]) contacted me, >> and together we worked out a better implementation of package support >> for the -m switch (and runpy.run_module) [2] by extending the >> __main__.py approach used to support direct execution of zipfiles and >> directories [3]. >> >> That's what I would like to add, since it nicely complements the ability >> to execute zipfiles and directories, while also restoring the ability to >> pass a package name to the -m switch (but in a way that keeps the import >> machinery in a consistent state). >> >> Cheers, >> Nick. >> >> [1] http://pypi.python.org/pypi/JCC >> >> [2] http://bugs.python.org/issue4195 (package execution with -m) >> [3] http://bugs.python.org/issue1739468 (zipfile execution) >> >> -- >> Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia >> --- >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com > -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 4195: Can't execute packages with -m in Python 2.6/3.0
I don't think that removing an unintentional and subtly broken feature is a regression. On Fri, Nov 21, 2008 at 7:04 PM, Lisandro Dalcin <[EMAIL PROTECTED]> wrote: > Unless this is considered a regression... > > On Tue, Nov 18, 2008 at 12:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> I think it crosses the line. >> >> On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >>> I need a release manager call on whether or not the proposed resolution >>> of this issue goes beyond what is acceptable for a bug fix in 2.6.1. >>> >>> Short version: >>> - Python 2.5 allowed packages to be executed with -m, but in a broken way >>> - I disabled the broken way for 2.6, but didn't provide a replacement >>> - The patch attached to 4195 once again allows execution of packages >>> with -m, but in a clean way similar to the way directories and zipfiles >>> can now be executed >>> - I would like to commit that patch for 3.0/2.6.1, but I'm concerned >>> that it crosses the "no new features" line >>> >>> Long version: >>> >>> There was a bug in python 2.5 that allowed a package name to be passed >>> to the -m switch or runpy.run_module() and it would mostly work. >>> >>> However, the 'mostly' was due to the fact that doing this put the >>> internal import machinery into a slightly inconsistent state: the >>> interpreter was running code from inside a package, but that package >>> wasn't actually present in sys.modules. This could lead to assorted hard >>> to trace import-related weirdness, similar to what you can get when >>> executing a file from inside a package by name. You would often get away >>> with it, but good luck figuring out what is happening if things go wrong >>> (and you aren't already an expert on Python import mechanics). >>> >>> Since the ability to execute packages wasn't intentional, I added the >>> missing check to block it explicitly in 2.6 (but left it alone for 2.5). >>> It seemed like a really niche feature, so I didn't figure out a clean >>> replacement for it at the time. >>> >>> Benjamin noticed this change earlier in the 2.6 release cycle, I pointed >>> out it was a deliberate change, and that's the way it stayed until after >>> 2.6 was released. >>> >>> After the release, Andi Vajda (from the JCC project [1]) contacted me, >>> and together we worked out a better implementation of package support >>> for the -m switch (and runpy.run_module) [2] by extending the >>> __main__.py approach used to support direct execution of zipfiles and >>> directories [3]. >>> >>> That's what I would like to add, since it nicely complements the ability >>> to execute zipfiles and directories, while also restoring the ability to >>> pass a package name to the -m switch (but in a way that keeps the import >>> machinery in a consistent state). >>> >>> Cheers, >>> Nick. >>> >>> [1] http://pypi.python.org/pypi/JCC >>> >>> [2] http://bugs.python.org/issue4195 (package execution with -m) >>> [3] http://bugs.python.org/issue1739468 (zipfile execution) >>> >>> -- >>> Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia >>> --- >>> ___ >>> Python-Dev mailing list >>> [email protected] >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> http://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com >> > > > > -- > Lisandro Dalcín > --- > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 4195: Can't execute packages with -m inPython 2.6/3.0
In concur that it is not a regression (esp for Py2.6). OTOH, it would be nice to have -m run as expected. It seems reasonable to me to get this working for 3.0. Raymond - Original Message - From: "Guido van Rossum" <[EMAIL PROTECTED]> To: "Lisandro Dalcin" <[EMAIL PROTECTED]> Cc: "Nick Coghlan" <[EMAIL PROTECTED]>; "Python Dev" Sent: Friday, November 21, 2008 7:16 PM Subject: Re: [Python-Dev] Issue 4195: Can't execute packages with -m inPython 2.6/3.0 I don't think that removing an unintentional and subtly broken feature is a regression. On Fri, Nov 21, 2008 at 7:04 PM, Lisandro Dalcin <[EMAIL PROTECTED]> wrote: Unless this is considered a regression... On Tue, Nov 18, 2008 at 12:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: I think it crosses the line. On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: I need a release manager call on whether or not the proposed resolution of this issue goes beyond what is acceptable for a bug fix in 2.6.1. Short version: - Python 2.5 allowed packages to be executed with -m, but in a broken way - I disabled the broken way for 2.6, but didn't provide a replacement - The patch attached to 4195 once again allows execution of packages with -m, but in a clean way similar to the way directories and zipfiles can now be executed - I would like to commit that patch for 3.0/2.6.1, but I'm concerned that it crosses the "no new features" line Long version: There was a bug in python 2.5 that allowed a package name to be passed to the -m switch or runpy.run_module() and it would mostly work. However, the 'mostly' was due to the fact that doing this put the internal import machinery into a slightly inconsistent state: the interpreter was running code from inside a package, but that package wasn't actually present in sys.modules. This could lead to assorted hard to trace import-related weirdness, similar to what you can get when executing a file from inside a package by name. You would often get away with it, but good luck figuring out what is happening if things go wrong (and you aren't already an expert on Python import mechanics). Since the ability to execute packages wasn't intentional, I added the missing check to block it explicitly in 2.6 (but left it alone for 2.5). It seemed like a really niche feature, so I didn't figure out a clean replacement for it at the time. Benjamin noticed this change earlier in the 2.6 release cycle, I pointed out it was a deliberate change, and that's the way it stayed until after 2.6 was released. After the release, Andi Vajda (from the JCC project [1]) contacted me, and together we worked out a better implementation of package support for the -m switch (and runpy.run_module) [2] by extending the __main__.py approach used to support direct execution of zipfiles and directories [3]. That's what I would like to add, since it nicely complements the ability to execute zipfiles and directories, while also restoring the ability to pass a package name to the -m switch (but in a way that keeps the import machinery in a consistent state). Cheers, Nick. [1] http://pypi.python.org/pypi/JCC [2] http://bugs.python.org/issue4195 (package execution with -m) [3] http://bugs.python.org/issue1739468 (zipfile execution) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
