[RELEASED] Python 3.2.6, Python 3.3.6

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the release of Python 3.2.6 and 3.3.6.  Both are security-fix releases,
which are provided source-only on python.org.

The list of security-related issues fixed in the releases is given in
the changelogs:

https://hg.python.org/cpython/raw-file/v3.2.6/Misc/NEWS
https://hg.python.org/cpython/raw-file/v3.3.6/Misc/NEWS

To download the releases visit one of:

https://www.python.org/downloads/release/python-326/
https://www.python.org/downloads/release/python-336/

These are production versions, please report any bugs to

 http://bugs.python.org/

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlQ6L/cACgkQN9GcIYhpnLBxIwCeLqjXeIOxGA2vkjbkN5Ic6j2u
7WcAoKgFaB4drMX5ZOVUJ4VLyNTcfycN
=KLlw
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.6rc1, Python 3.3.6rc1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the release of Python 3.2.6rc1 and 3.3.6rc1.  Both are release candidates
for security-fix releases, which are provide source-only on python.org.

The list of security-related issues fixed in the releases is given in
the changelogs:

https://hg.python.org/cpython/raw-file/v3.2.6rc1/Misc/NEWS
https://hg.python.org/cpython/raw-file/v3.3.6rc1/Misc/NEWS

To download the pre-releases visit one of:

https://www.python.org/downloads/release/python-326rc1/
https://www.python.org/downloads/release/python-336rc1/

These are pre-releases, please report any bugs to

 http://bugs.python.org/

The final releases are scheduled one week from now.

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlQv9GsACgkQN9GcIYhpnLC93gCfVm74lhOysPYCO0fy9/l5LUfJ
bUYAn2u1EygfsPw2oa4CSoj5t0TYUJq7
=HnOK
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.5

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm very happy to announce
the release of Python 3.3.5.

Python 3.3.5 includes fixes for these important issues:

* a 3.3.4 regression in zipimport (see http://bugs.python.org/issue20621)
* a 3.3.4 regression executing scripts with a coding declared and Windows
  newlines (see http://bugs.python.org/issue20731)
* potential DOS using compression codecs in bytes.decode() (see
  http://bugs.python.org/issue19619 and http://bugs.python.org/issue20404)

and also fixes quite a few other bugs.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  In total, almost 500 API items
are new or improved in Python 3.3.  For a more extensive list of
changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.5 visit:

http://www.python.org/downloads/release/python-335/


This is a production release, please report any bugs to

 http://bugs.python.org/

The final release is scheduled one week from now.


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlMcRNEACgkQN9GcIYhpnLAVqACeMoOOuuNX5iP6at9zbIZDnkqK
idwAoKb2FxAJlirhs2BmdESEaQiqBDJd
=smeC
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.5 release candidate 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the release of Python 3.3.5, release candidate 2.

Python 3.3.5 includes a fix for a regression in zipimport in 3.3.4
(see http://bugs.python.org/issue20621) and a few other bugs.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  In total, almost 500 API items
are new or improved in Python 3.3.  For a more extensive list of
changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.5 visit:

http://www.python.org/download/releases/3.3.5/


This is a preview release, please report any bugs to

 http://bugs.python.org/

The final release is scheduled one week from now.


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlMUUKoACgkQN9GcIYhpnLD5OACfTpRkcM9aXUx2XbiXoZtIgSE7
BqwAnjwpAuqc9lKJ0O3XOw5qDvDPYsNb
=EGuB
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.5 release candidate 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the release of Python 3.3.5, release candidate 1.

Python 3.3.5 includes a fix for a regression in zipimport in 3.3.4
(see http://bugs.python.org/issue20621) and a few other bugs.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  In total, almost 500 API items
are new or improved in Python 3.3.  For a more extensive list of
changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.5 visit:

http://www.python.org/download/releases/3.3.5/


This is a preview release, please report any bugs to

 http://bugs.python.org/

The final release is scheduled one week from now.


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlMKIPEACgkQN9GcIYhpnLCjXACfQwbC/eD/lhKAZ+XCwTwYPVWj
GMwAnjWkbdk7hqsKoh12EiagpGApEPSA
=2BCx
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.4

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm very happy to announce
the release of Python 3.3.4.

Python 3.3.4 includes several security fixes and over 120 bug fixes
compared to the Python 3.3.3 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this
release fixes an issue that could cause previous versions of Python to
crash when typing in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  In total, almost 500 API items
are new or improved in Python 3.3.  For a more extensive list of
changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.4 visit:

http://www.python.org/download/releases/3.3.4/


This is a production release, please report any bugs to

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlL5PMwACgkQN9GcIYhpnLCv4wCePNVqwsOYCHdJBix2bKk4PNpK
GBoAnRML2x6obCssnUJe5xwuUZYw8ZSY
=+/Nz
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.4 release candidate 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm reasonably happy to announce the
Python 3.3.4 release candidate 1.

Python 3.3.4 includes several security fixes and over 120 bug fixes compared to
the Python 3.3.3 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
in Python 3.3.  For a more extensive list of changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

and for the detailed changelog of 3.3.4, see

http://docs.python.org/3.3/whatsnew/changelog.html

To download Python 3.3.4 rc1 visit:

http://www.python.org/download/releases/3.3.4/

This is a preview release, please report any bugs to

 http://bugs.python.org/

The final version is scheduled to be released in two weeks' time, on or about
the 10th of February.

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlLmDI4ACgkQN9GcIYhpnLAr6wCePRbHF80k5goV4RUDBA5FfkwF
rLUAnRg0RpL/b6apv+Dt2/sgnUd3hTPA
=Z4Ss
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.3 final

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm very happy to announce
the release of Python 3.3.3.

Python 3.3.3 includes several security fixes and over 150 bug fixes
compared to the Python 3.3.2 release. Importantly, a security bug in
CGIHTTPServer was fixed [1]. Thank you to those who tested the 3.3.3
release candidate!

This release fully supports OS X 10.9 Mavericks.  In particular, this
release fixes an issue that could cause previous versions of Python to
crash when typing in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  In total, almost 500 API items
are new or improved in Python 3.3.  For a more extensive list of
changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.3 rc2 visit:

http://www.python.org/download/releases/3.3.3/


This is a production release, please report any bugs to

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)


[1] http://bugs.python.org/issue19435
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlKLDGYACgkQN9GcIYhpnLCjewCfQ+EJHpzGzIyTvYOrYmsRmnbv
n40AniVM0UuQWpPrlCu349fu7Edt+d4+
=WSIj
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Self-defence

[Georg Brandl]

Am 17.11.2013 18:33, schrieb Mark Lawrence:

>> This is a last-ditch request, and not one I particularly expect to
>> succeed, but I honestly can't stand to watch this happen to python-list
>> for very much longer, and am very close to unsubscribing after six years
>> as an admittedly not very active member.
>>
>>   -[]z.
>>
> 
> I entirely agree with the sentiments expressed above.  Would the Python 
> Software Foundation (I assume?) please take whatever steps it can to 
> prevent Nikos posting here?  This is justified on the grounds of today's 
> behaviour alone.  Add in previous days when perhaps 95% of the bandwidth 
> has been taken up by his posts and I know it's time to say enough is enough.

As another lurking member, I can only say this:

Folks, it's your decision to let this matter die.  As long as python-list is
coupled to Usenet, there will be little to no barrier to posting, and the
only way to get rid of trolls is to ignore them.

Let the barrage of posts continue for a few more days; if he doesn't get
replies he will get fed up eventually.

cheers,
Georg

-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.3 release candidate 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm quite happy to announce the
Python 3.3.3 release candidate 2.

Python 3.3.3 includes several security fixes and over 150 bug fixes compared to
the Python 3.3.2 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
in Python 3.3.  For a more extensive list of changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.3 rc2 visit:

http://www.python.org/download/releases/3.3.3/


This is a preview release, please report any bugs to

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlKB1G4ACgkQN9GcIYhpnLAu5gCfRkfpnEs+rmtZ9iTjaaZcHDx3
sNYAn180Q4cFZmKtwJdaG+g/3jHAVd97
=n/Tt
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem installing matplotlib 1.3.1 with Python 2.7.6 and 3.3.3 (release candidate 1)

[Georg Brandl]

Am 04.11.2013 01:59, schrieb Ned Deily:
> In article <21110.62791.44734.656...@cochabamba.vanoostrum.org>,
>  Piet van Oostrum  wrote:
>> I tried to install matplotlib 1.3.1 on the release candidates of Python 
>> 2.7.6 
>> and 3.3.3.
> 
> [...]
> 
> Please open an issue on the Python bug tracker for the Python component of 
> this.
> 
> http://bugs.python.org

And please mark as release blocker, I think this should go into 3.3.3rc2.

Georg

-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.3 release candidate 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm quite happy to announce the
Python 3.3.3 release candidate 1.

Python 3.3.3 includes several security fixes and over 150 bug fixes compared to
the Python 3.3.2 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.

Python 3.3.3 also contains a new batteries-included feature for OS X users of
IDLE and other Tkinter-based programs.  The python.org Mac OS X 64-bit/32-bit
x86-64/i386 Installer for OS X 10.6+ now includes its own builtin version of
Tcl/Tk 8.5.  It is no longer necessary to install a third-party version of
Tcl/Tk 8.5 to workaround the problematic system versions.  See
http://www.python.org/download/mac/tcltk/ for more information.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
in Python 3.3.  For a more extensive list of changes in the 3.3 series, see

http://docs.python.org/3.3/whatsnew/3.3.html

and for the detailed changelog of 3.3.3, see

http://docs.python.org/3.3/whatsnew/changelog.html

To download Python 3.3.3 rc1 visit:

http://www.python.org/download/releases/3.3.3/

This is a preview release, please report any bugs to

 http://bugs.python.org/

The final version is scheduled to be released in two weeks' time, on or about
the 10th of November.

Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlJte8kACgkQN9GcIYhpnLDx8wCgqtabbC8DaoW+Vy03AYGWyLhw
sWcAoIK5jQeXDAxHayG+VWH/rRF1+qHC
=yOed
-END PGP SIGNATURE-
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.5 and Python 3.3.2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I am pleased to announce the
releases of Python 3.2.5 and 3.3.2.

The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip
and xml.sax modules.  Details can be found in the changelogs:

http://hg.python.org/cpython/file/v3.2.5/Misc/NEWS  and
http://hg.python.org/cpython/file/v3.3.2/Misc/NEWS

To download Python 3.2.5 or Python 3.3.2, visit:

http://www.python.org/download/releases/3.2.5/  or
http://www.python.org/download/releases/3.3.2/

respectively.  As always, please report bugs to

http://bugs.python.org/

(Thank you to those who reported these regressions.)

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and all contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlGUbJ4ACgkQN9GcIYhpnLDH8ACdEM4k7bobLJsFmCb49zuwQR3W
EjgAoIWAOFNhJNdTAWEGSWqFWUP20wrb
=YnPr
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.2.4 and Python 3.3.1

[Georg Brandl]

Am 06.04.2013 22:48, schrieb cmcp:
> On Saturday, 6 April 2013 21:43:11 UTC+1, Georg Brandl  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> 
>> Hash: SHA1
>> 
>> 
>> 
>> On behalf of the Python development team, I am pleased to announce the
>> 
>> final releases of Python 3.2.4 and 3.3.1.
>> 
> The Python 3.3.1 Release page on python.org still says "This is a preview
> release, and its use is not recommended in production settings."  I'm
> assuming this is just an oversight?

Yes.  Thanks for the report, it's fixed now.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.4 and Python 3.3.1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I am pleased to announce the
final releases of Python 3.2.4 and 3.3.1.

Python 3.2.4 is the final regular maintenance release for the Python 3.2
series, while Python 3.3.1 is the first maintenance release for the 3.3
series.  Both releases include hundreds of bugfixes.

There has recently been a lot of discussion about XML-based denial of service
attacks. Specifically, certain XML files can cause XML parsers, including ones
in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. These
releases do not include any changes in Python XML code to address these issues.
Interested parties should examine the defusedxml package on PyPI:
https://pypi.python.org/pypi/defusedxml

To download Python 3.2.4 or Python 3.3.1, visit:

http://www.python.org/download/releases/3.2.4/  or
http://www.python.org/download/releases/3.3.1/

respectively.  As always, please report bugs to

http://bugs.python.org/

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and all contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlFgiN8ACgkQN9GcIYhpnLAXxQCdHAd2lECpYfmYM4Wbd3I01es4
898AoKBDvHtgecD/PeVRKUrdQRSWGPJg
=K8RQ
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.4 rc 1 and Python 3.3.1 rc 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I am pleased to announce the
first release candidates of Python 3.2.4 and 3.3.1.

Python 3.2.4 will be the last regular maintenance release for the Python 3.2
series, while Python 3.3.1 is the first maintenance release for the 3.3
series.  Both releases include hundreds of bugfixes.

There has recently been a lot of discussion about XML-based denial of service
attacks. Specifically, certain XML files can cause XML parsers, including ones
in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. These
releases do not include any changes in Python XML code to address these issues.
Interested parties should examine the defusedxml package on PyPI:
https://pypi.python.org/pypi/defusedxml

These are testing releases: Please consider trying them with your code
and reporting any bugs you may notice to:

http://bugs.python.org/

To download Python 3.2.4 or Python 3.3.1, visit:

http://www.python.org/download/releases/3.2.4/  or
http://www.python.org/download/releases/3.3.1/

respectively.


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and all contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlFRRIoACgkQN9GcIYhpnLD6jACgnzYdYRKZ4kwkKeN3zSLSZ3Zr
M/IAn17vlpxI3a3xk+i/ODOrCkMnRZro
=B5sA
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [RELEASED] Python 3.3.0

[Georg Brandl]

On 09/29/2012 06:53 PM, Antoine Pitrou wrote:


Hello,

I've created a 3.3 category on the buildbots:
http://buildbot.python.org/3.3/
http://buildbot.python.org/3.3.stable/

Someone will have to update the following HTML page:
http://python.org/dev/buildbot/


Should be done now.

Georg


--
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0

[Georg Brandl]

On behalf of the Python development team, I'm delighted to announce the
Python 3.3.0 final release.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
   distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 120x speedup
   for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
   significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
   PEP 411) policy that adds much improved unicode support for email
   header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
   modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
   switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

 http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.0 visit:

 http://www.python.org/download/releases/3.3.0/

This is a production release, please report any bugs to

  http://bugs.python.org/


Enjoy!

--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
--
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 release candidate 3

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm delighted to announce the
third release candidate of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

  http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.0 visit:

  http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

  http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBf+0cACgkQN9GcIYhpnLBqfgCglbN63XUr2m4Ya4ff8Hza1Axl
SgMAniQZRJi8uYfeqltf5/G4QV/+SdWT
=KXTo
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 release candidate 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm delighted to announce the
second release candidate of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

  http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.0 visit:

  http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

  http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBMYJMACgkQN9GcIYhpnLCc5ACfcufn57tkNBPFU7qCpZ74GzjW
msMAn3sIwWHLdqixypnnyMBOw1ijILjo
=+e0e
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 release candidate 1

[Georg Brandl]

On behalf of the Python development team, I'm delighted to announce the
first release candidate of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
   distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
   for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
   significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
   PEP 411) policy that adds much improved unicode support for email
   header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
   modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
   switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

 http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.0 visit:

 http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
--
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 beta 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
second beta release of Python 3.3.0 -- a little later than originally
scheduled, but much better for it.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
   distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
   for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
   significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
   PEP 411) policy that adds much improved unicode support for email
   header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
   modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
   switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

 http://docs.python.org/3.3/whatsnew/3.3.html (*)

To download Python 3.3.0 visit:

 http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlAnxVAACgkQN9GcIYhpnLAECACcDeE+N2AfYVnuwMkq682znfDU
ODAAn0J87+MVA9WHEV5iYZd3ub9ZhbpC
=LvY0
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 beta 1

[Georg Brandl]

On behalf of the Python development team, I'm happy to announce the
first beta release of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
  distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
  for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
  significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
  PEP 411) policy that adds much improved unicode support for email
  header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
  modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
  switched on by default

In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see

http://docs.python.org/3.3/whatsnew/3.3.html (*)

To download Python 3.3.0 visit:

http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.

--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)

--
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 alpha 4

[Georg Brandl]

On behalf of the Python development team, I'm happy to announce the
fourth alpha release of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
  distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
  for decimal-heavy applications
* The import system (__import__) is based on importlib by default
* The new "packaging" module (also known as distutils2, and released
  standalone under this name), implementing the new packaging formats
  and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
  significantly saves memory for object-oriented code
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
  modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
  switched on by default

For a more extensive list of changes in 3.3.0, see

http://docs.python.org/3.3/whatsnew/3.3.html (*)

To download Python 3.3.0 visit:

http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.

--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)

-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 alpha 3

[Georg Brandl]

On behalf of the Python development team, I'm happy to announce the
third alpha release of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
  distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* A C implementation of the "decimal" module, with up to 80x speedup
  for decimal-heavy applications
* The import system (__import__) is based on importlib by default
* The new "packaging" module, building upon the "distribute" and
  "distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* The new "faulthandler" module that helps diagnosing crashes
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
  modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
  switched on by default

For a more extensive list of changes in 3.3.0, see

http://docs.python.org/3.3/whatsnew/3.3.html (*)

To download Python 3.3.0 visit:

http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.

--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 alpha 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
second alpha release of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
  distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* A C implementation of the "decimal" module, with up to 80x speedup
  for decimal-heavy applications
* The new "packaging" module, building upon the "distribute" and
  "distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* The new "faulthandler" module that helps diagnosing crashes
* Wrappers for many more POSIX functions in the "os" and "signal"
  modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
  switched on by default.

For a more extensive list of changes in 3.3.0, see

http://docs.python.org/3.3/whatsnew/3.3.html (*)

To download Python 3.3.0 visit:

http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.

- - --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
- -BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk95PJgACgkQN9GcIYhpnLCN1QCfeYWp+QbPGYhaLSxc4YKnlE/F
zU8An2q5qzvjL0qaxqaYleFGoGKPzzJu
=qo4v
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk95P10ACgkQN9GcIYhpnLBo8QCePW2BuTqXSmtVl6/Yae1HWrGB
UFgAn0ytSqd70vq58gj9N8xUtKC+BJ2D
=3DA/
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 alpha 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
second alpha release of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x.  Major new features and changes
in the 3.3 release series are:

* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
  distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* A C implementation of the "decimal" module, with up to 80x speedup
  for decimal-heavy applications
* The new "packaging" module, building upon the "distribute" and
  "distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* The new "faulthandler" module that helps diagnosing crashes
* Wrappers for many more POSIX functions in the "os" and "signal"
  modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
  switched on by default.

For a more extensive list of changes in 3.3.0, see

http://docs.python.org/3.3/whatsnew/3.3.html (*)

To download Python 3.3.0 visit:

http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk95PJgACgkQN9GcIYhpnLCN1QCfeYWp+QbPGYhaLSxc4YKnlE/F
zU8An2q5qzvjL0qaxqaYleFGoGKPzzJu
=qo4v
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.3.0 alpha 1

[Georg Brandl]

On behalf of the Python development team, I'm happy to announce the
first alpha release of Python 3.3.0.

This is a preview release, and its use is not recommended in
production settings.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  Major new features in the 3.3 release series are:

* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
  distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* The new "packaging" module, building upon the "distribute" and
  "distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* The new "faulthandler" module that helps diagnosing crashes
* Wrappers for many more POSIX functions in the "os" and "signal"
  modules, as well as other useful functions such as "sendfile()"

For a more extensive list of changes in 3.3.0, see

http://docs.python.org/3.3/whatsnew/3.3.html

To download Python 3.3.0 visit:

http://www.python.org/download/releases/3.3.0/

Please consider trying Python 3.3.0a1 with your code and reporting any
bugs you may notice to:

http://bugs.python.org/


Enjoy!

--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
--
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
Python 3.2.2 maintenance release.

Python 3.2.2 mainly fixes `a regression <http://bugs.python.org/12576>`_ in the
``urllib.request`` module that prevented opening many HTTP resources correctly
with Python 3.2.1.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk5j3d4ACgkQN9GcIYhpnLA2BACeLZ8nSdVOoxlJw4DnbM42neeA
fwAAoKTHetXsVxrEfvCWSorUhoJ083kZ
=5Wm1
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I am pleased to announce the
final release of Python 3.2.1.

Python 3.2.1 is the first bugfix release for Python 3.2, fixing over 120
bugs and regressions in Python 3.2.

For an extensive list of changes and features in the 3.2 line, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2.1 visit:

http://www.python.org/download/releases/3.2.1/

This is a final release: Please report any bugs you may notice to:

http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk4aiNMACgkQN9GcIYhpnLDofwCglfgDQ1/B/TxxwfqtDxK13ksz
micAn0CVWmNNaYE2a6z0N7+Dz+hCZSj1
=7Mia
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.1 rc 2

[Georg Brandl]

On behalf of the Python development team, I am pleased to announce the
second release candidate of Python 3.2.1.

Python 3.2.1 will the first bugfix release for Python 3.2, fixing over 120
bugs and regressions in Python 3.2.

For an extensive list of changes and features in the 3.2 line, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2.1 visit:

http://www.python.org/download/releases/3.2.1/

This is a testing release: Please consider trying Python 3.2.1 with your code
and reporting any bugs you may notice to:

http://bugs.python.org/


Enjoy!

-- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2.1 rc 1

[Georg Brandl]

On behalf of the Python development team, I am pleased to announce the
first release candidate of Python 3.2.1.

Python 3.2.1 will the first bugfix release for Python 3.2, fixing over 120
bugs and regressions in Python 3.2.

For an extensive list of changes and features in the 3.2 line, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2.1 visit:

http://www.python.org/download/releases/3.2.1/

This is a testing release: Please consider trying Python 3.2.1 with your code
and reporting any bugs you may notice to:

http://bugs.python.org/


Enjoy!

-- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2

[Georg Brandl]

On behalf of the Python development team, I'm delighted to announce
Python 3.2 final release.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 rc 3

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the third release candidate of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk1YzkAACgkQN9GcIYhpnLAggwCfQ92djMinrmNkGI4Ma3VRqrcX
EWIAn16kTEJtvEH/7DJApp7YdhnmIRBd
=NJ1B
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 rc 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm quite happy to announce
the second release candidate of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk1Gj6IACgkQN9GcIYhpnLC53wCfcZhc6bxbc+fsmi+PAJxM6npr
Hh4An3QRdeyKHm+L3CqVk+EX02PxNx2r
=sTu6
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 rc 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm very happy to announce the
first release candidate of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0yn1QACgkQN9GcIYhpnLDTdACgqQYW5ZmTLlxmppBZItprSj7I
TmAAn13lgnu9TdVy0Jln7VwOt5JW9CwL
=VZ3p
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 beta 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
second beta preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* countless fixes regarding bytes/string issues; among them full
  support for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk0Q/aAACgkQN9GcIYhpnLDf8gCgkLGAsE+T3R505jZc1RxXDYsa
NSsAnRGaFjeTm9o2Z5O8FuIzTUG8t1PT
=hHzz
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 beta 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
first of two beta preview releases of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* countless fixes regarding bytes/string issues; among them full
  support for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkz9WcgACgkQN9GcIYhpnLBRYwCeMmH1GMmKOx9fVk8a/F0/TOzj
Vp0AoIHYBNcxV/U0AXIwMGWFHi1bAB+a
=KBam
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 alpha 4

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
fourth and (this time really) final alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
  support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

 http://www.python.org/download/releases/3.2/

3.2 documentation can be found at:

 http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkzij74ACgkQN9GcIYhpnLCbtwCgi4whRruM0Oi6yfgjVclYErFa
OJcAn0U8UBBsQBFyGcnKJRbls6B+guQ2
=Vuqf
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 alpha 3

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
third and final alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
  support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

 http://www.python.org/download/releases/3.2/

3.2 documentation can be found at:

 http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAky0V1QACgkQN9GcIYhpnLCm3wCeJ5EUcv8lYu4Yj/obNvOsIpvC
kXAAnR9znSCZwMoEvWwzernXWIxrhojM
=UE9Z
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 alpha 2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce
the second alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
  support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

 http://www.python.org/download/releases/3.2/

3.2 documentation can be found at:

 http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkyEpLkACgkQN9GcIYhpnLCzSwCdFyPz1dPEehJZmeW8wDltqkqe
/ogAnim1J99qDpeLmcUDTf0YBh1W95vf
=x+ee
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 3.2 alpha 1

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
first alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
  support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

 http://www.python.org/download/releases/3.2/

3.2 documentation can be found at:

 http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

 http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ
2N4An04q36lr47OA+bslqG/4Zj7ZwVOX
=iL8N
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Reminder: Python Bug Day on Saturday

[Georg Brandl]

Hi,

I'd like to remind everyoone that there will be a Python Bug Day on
April 25.  As always, this is a perfect opportunity to get involved
in Python development, or bring your own issues to attention, discuss
them and (hopefully) resolve them together with the core developers.

We will coordinate over IRC, in #python-dev on irc.freenode.net,
and the Wiki page http://wiki.python.org/moin/PythonBugDay has all
important information and a short list of steps how to get set up.

Hope to see you there!

Georg


--
http://mail.python.org/mailman/listinfo/python-list

Correction: Python Bug Day on April 25

[Georg Brandl]

Hi,

I managed to screw up the date, so here it goes again:

I'd like to announce that there will be a Python Bug Day on April 25.
As always, this is a perfect opportunity to get involved in Python
development, or bring your own issues to attention, discuss them and
(hopefully) resolve them together with the core developers.

We will coordinate over IRC, in #python-dev on irc.freenode.net,
and the Wiki page http://wiki.python.org/moin/PythonBugDay has all
important information and a short list of steps how to get set up.

Please spread the word!

Georg

--
http://mail.python.org/mailman/listinfo/python-list

Python Bug Day on April 23

[Georg Brandl]

Hi,

I'd like to announce that there will be a Python Bug Day on April 23.
As always, this is a perfect opportunity to get involved in Python
development, or bring your own issues to attention, discuss them and
(hopefully) resolve them together with the core developers.

We will coordinate over IRC, in #python-dev on irc.freenode.net,
and the Wiki page http://wiki.python.org/moin/PythonBugDay has all
important information and a short list of steps how to get set up.

Please spread the word!

Georg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Bragging about Python

[Georg Brandl]

Mathias Panzenboeck schrieb:
> Steve Howell schrieb:
>> --- "[EMAIL PROTECTED]"
>> <[EMAIL PROTECTED]> wrote:
>> 
>>> Is there a resource somewhere on the net that can be
>>> used to quickly
>>> and effectively show Python's strengths to
>>> non-Python programmers?
>>> Small examples that will make them go "Wow, that
>>> _is_ neat"?
>>>
>> 
>> 15 small programs here:
>> 
>> http://wiki.python.org/moin/SimplePrograms
>> 
> 
> IMHO a few python goodies are missing there.

"It's a Wiki." ;)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What makes an iterator an iterator?

[Georg Brandl]

Stefan Rank schrieb:
> on 18.04.2007 07:39 Steven D'Aprano said the following:
>> I thought that an iterator was any object that follows the iterator
> 
> replace object with "instance of a class", i.e. the relevant methods are 
> looked up in the __class__ not in the instance (I think).
> I had the same troubles trying to dynamically reassign a __call__ method...

This is correct.

It's not properly documented though, and not applied consistently, e.g.
__enter__ and __exit__ are looked up in the instance itself.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: proposed PEP: iterator splicing

[Georg Brandl]

Steven Bethard schrieb:
> Paul Rubin wrote:
>> The boilerplate
>> 
>> def some_gen():
>>...
>>for x in some_other_gen():
>>yield x
>>...
>> 
>> is so common (including the case where some_other_gen is the same as
>> some_gen, i.e. it's a recursive call) that I find myself wanting
>> a more direct way to express it:
>> 
>> def some_gen():
>>...
>>yield *some_other_gen()
>> 
>> comes to mind.  Less clutter, and avoids yet another temp variable
>> polluting the namespace.
>> 
>> Thoughts?
> 
> This has been brought up before and there was mixed support:
> 
> http://www.python.org/dev/summary/2006-01-16_2006-01-31/#yielding-from-a-sub-generator
> 
> My guess is that the only way it has any chance is if someone takes the 
> time to implement it and posts a full-fledged PEP to python-dev.

BTW, I've implemented a different feature, namely extended unpacking, such as

a, *b, c = range(10)

where I already had to add the concept of a ``starred'' expression.
If someone wants to do it, we can probably share some code.


Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Feature Request: Add the "using" keyword which works like "with" in Visual Basic

[Georg Brandl]

BJörn Lindqvist schrieb:
> On 4/14/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
>> On 14 Apr 2007 07:24:32 -0700, jamadagni <[EMAIL PROTECTED]> wrote:
>> > > You already can emulate the using statement like this:
>> >
>> > You can emulate only assignments like this. How would you emulate
>> > function calls, like the ones in my example?
>>
>> You can't, of course. But using the with statement:
>>
>> using self.q:
>> .doit()
>>
>> becomes:
>>
>> with self.quit as q:
>> q.doit()
> 
> Er.. I guess there are some details you need to work out for that. But
> in principle, it works fine.

No, it does not. The "q" here is *not* assigned to self.quit, but to the
result of self.quit.__enter__().

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: exec statement Syntax Error on string pulled from MySQL

[Georg Brandl]

[EMAIL PROTECTED] schrieb:
> It's the strangest thing,  I'm pulling some text out of a MySQL table
> and trying to run exec on it, and it keeps giving me a syntax error,
> always at the end of the first line.
> 
> Thanks in advance for any help.  I'm really stuck on this one!
> 
> -Greg
> 
> I'm not sure what information would be most useful but here's a start:
> 
> The last code I stored in the table and pulled out was simply:
> print 'greg'
> print 'greg2'
> 
> To which my error log says:
> Traceback (most recent call last):
>   File "/home/public/web/webapi.py", line 303, in wsgifunc
> result = func()
>   File "/home/public/web/request.py", line 125, in 
> func = lambda: handle(inp, fvars)
>   File "/home/public/web/request.py", line 61, in handle
> return tocall(*([urllib.unquote(x) for x in args] + fna))
>   File "/home/public/EZsession.py", line 119, in proxyfunc
> return func(self, *args, **kw)
>   File "/home/htdocs/code.py", line 94, in POST
> print utility.run(name,revision,inp)
>   File "/home/public/utility.py", line 177, in run
> exec code+'\n' in context
>   File "", line 1
> print 'greg'
> ^
> SyntaxError: invalid syntax
> (Note the ^ actually appears under after the ' )

You have Windows line endings (\r\n) in the string, which Python doesn't like.

Don't store it like that, or if you must, do a .replace('\r', '') before 
exec'ing it.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RFC: Assignment as expression (pre-PEP)

[Georg Brandl]

Alex Martelli schrieb:
> Adam Atlas <[EMAIL PROTECTED]> wrote:
> 
>> Hasn't this been discussed many many times before? I think Guido has
>> been favourable to the idea of allowing :=, but that was a long time
>> ago, and I don't think anything ever came of it.
>> 
>> Personally, if anything, I'd like to see more use of the 'as' keyword
>> as in Python 2.5's new 'with' statement. Assignment is basically what
>> it adds to the statement, so if anything we should reuse it in other
>> statements for consistency.
>> 
>> if my_re1.match(exp) as temp:
>>   # do something with temp
>> elif my_re2.match(exp) as temp:
>>   # do something with temp
>> elif my_re3.match(exp) as temp:
>>   # do something with temp
>> elif my_re4.match(exp) as temp:
>>   # do something with temp
>> 
>> As others have mentioned, your particular instance is probably
>> evidence that you need to restructure your code a little bit, but I do
>> agree that "x = y; if x: ..." is a common enough idiom that it
>> warrants a shortcut. And reusing "as", I think, is nice and readable,
>> and it's an advantage that it doesn't require adding any new keywords
>> or symbols.
> 
> Actually, I agree with you.  Unfortunately, I doubt python-dev will, but
> the chance is good enough that it's probably worth proposing there
> (ideally together with a patch to implement it, just to avoid any
> [otherwise likely] whines about this being difficult to implement:-).

The patch is already done -- I have it lying around here :)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode problem

[Georg Brandl]

Martin v. Löwis schrieb:
>> Thanks! That's a nice little stumbling block for a newbie like me ;) Is 
>> there a way to make utf-8 the default encoding for every string, so that 
>> I do not have to encode each string explicitly?
> 
> You can make sys.stdout encode each string with UTF-8, with
> 
> sys.stdout = codecs.getwriter('utf-8')(sys.stdout)
> 
> Make sure that you then that *all* strings that you print
> are Unicode strings.

BTW, any reason why an EncodedFile can't act like a Unicode writer/reader object
if one of its encodings is explicitly set to None?

IMO the docs don't make it clear that getwriter() is the correct API to use
here. I've wanted to write "sys.stdout = codecs.EncodedFile(sys.stdout, 
'utf-8')" more than once.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: tuples, index method, Python's design

[Georg Brandl]

Paul Rubin schrieb:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> I think the problem is that Python developers are split between those who
>> see tuples as immutable lists, and those who see them as records/structs.
> 
> I think the construction
> 
>def f(*a): ...
> 
> shows that the "immutable list" interpretation is firmly ensconced in
> the language.

IIRC, for this use case of tuples there was a practical reason rather than
an interpretation one. It is also on the list of potential changes for
Python 3000.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: tuples, index method, Python's design

[Georg Brandl]

Paul Rubin schrieb:
> Carsten Haese <[EMAIL PROTECTED]> writes:
>> Will tuples also get a sort method? What about append and extend? pop?
>> __iadd__? __delslice__?
> 
> They are immutable so they won't get .sort() etc.  sorted(...) already
> works on them.
> 
>> How many brain cells are actually freed up by not having to remember
>> that *one* method that you'd never use doesn't exist?
> 
> I dunno but I do know that Ruby is attracting a lot of potential Python
> users because it apparently has fewer of these inconsistencies.

It remains to be proven that it is an inconsistency, rather than a design
decision.

>  A big
> web site I hang out on decided to do a software rewrite (currently using
> a huge perl script) and evaluated a bunch of possible approaches.  In
> the final decision, Ruby/Rails won out over Python/Django.

Given that so many web sites still decide to (re)write in PHP, I don't think
that is much of an argument.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exec Statement Question

[Georg Brandl]

Gregory Piñero schrieb:
> I'm curious why this code isn't working how I expect it to:
> 
> import sys
> d=3
> 
> def func1(a,b,c):
> print a,b,c,d
> print sys.path
> 
> exec "func1(1,2,3)" in {'func1':func1}
> 
> 
> returns:
> 1 2 3 3
> [ sys.path stuff ]
> 
> Since I'm telling exec to operate only within the context of the
> dictionary I give it, why does it still see sys.path and d?  I figured
> it would throw a NameError.
> 
> Is there a way to call exec such that it won't have access to any more
> objects than I explicitly give it?

The function f has a func_globals attribute which points to the globals it
will use for execution. This is of course set at definition time so that
functions from, e.g., another module, have the globals of that module available.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How do I get a slice of a string held in a tuple?

[Georg Brandl]

Lorenzo schrieb:

>> > How do I go about it?
>> 
>> Do it correctly. Post your actual example that fails
>> and the related error message. Possibnly your indexes
>> were out of range.
>> 
>> > I googled this and found a couple
>> > of references, but no solution.
>> 
>> Well, there wouldn't be  a solution to a non-existent
>> problem, would there?
>> 
>> > TIA
> 
> Here's the code:
> 
>  elapsedTime = mydata[1]
>  index = elapsedTime.find("real")
>  # the index will have a value 0f 110 
>  totaltime = elapsedTime[index:]
>  # instead of this returning a shortened html string, i only 
>  # get the left angle bracket '<'

May it be that mydata[1] doesn't contain "real" at all? In that case,
find() returns -1, and the slice elapsedTime[-1:] always contains
at most one character.

If you replace "find" by "index", you get a ValueError exception if
"real" was not found, if that helps you.

Whenever one calls str.find(), one has to check the return value for -1.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: block scope?

[Georg Brandl]

Alex Martelli schrieb:
> Paul Rubin  wrote:
> 
>> [EMAIL PROTECTED] (Alex Martelli) writes:
>> > > exec?
>> > option 1: that just runs the compiler a bit later ...
>> 
>> Besides exec, there's also locals(), i.e.
>>locals['x'] = 5
>> can shadow a variable.  Any bad results are probably deserved ;)
> 
 locals['x']=5
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'builtin_function_or_method' object does not support item
> assignment
> 
> I suspect you want to index the results of calling locals(), rather than
> the builtin function itself.  However:
> 
 def f():
> ...   locals()['x'] = 5
> ...   return x
> ... 
 f()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in f
> NameError: global name 'x' is not defined
> 
> No "shadowing", as you see: the compiler knows that x is NOT local,
> because it's not assigned to (the indexing of locals() does not count:
> the compiler's not expected to detect that), so it's going to look it up
> as a global variable (and not find it in this case).

Even assignments to real local variable names in the locals() result do
normally not result in the variable having a new value.

> I think that ideally there should be a runtime error when assigning an
> item of locals() with a key that's not a local variable name (possibly
> excepting functions containing exec, which are kind of screwy anyway).

I would make the locals() result completely independent from the frame,
and document that it is read only.

(though, this needs some other way for trace functions to interact with
the frame's local variables.)

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How can i compare a string which is non null and empty

[Georg Brandl]

[EMAIL PROTECTED] schrieb:
> Hi,
> 
> how can i compare a string which is non null and empty?
> 
> 
> i look thru the string methods here, but cant find one which does it?
> 
> http://docs.python.org/lib/string-methods.html#string-methods
> 
> In java,I do this:
> if (str != null) && (!str.equals("")) 
> 
> how can i do that in python?

Strings cannot be "null" in Python.

If you want to check if a string is not empty, use "if str".

This also includes the case that "str" may not only be an empty
string, but also None.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode list

[Georg Brandl]

Rehceb Rotkiv schrieb:
> Hello,
> 
> I have this little grep-like program:
> 
> ++snip++
> #!/usr/bin/python
> 
> import sys
> import re
> 
> pattern = sys.argv[1]
> inputfile = file(sys.argv[2], 'r')
> 
> for line in inputfile:
> matches = re.findall(pattern, line)
> if matches:
> print matches
> ++snip++
> 
> Like this, the program prints some characters as strange escape 
> sequences, which is due to the input file being encoded in utf-8

As Paul said, your terminal is likely set to iso-8859 encoding, which
is why it doesn't display UTF-8 correctly. The above program produces
correct UTF-8 output.

What you could do is:
1. read the file in as unicode
2. print the unicode to the terminal (will use the terminal encoding) or
convert the unicode to strings with an explicit encoding before printing

codecs.open() is very helpful for step 1, BTW.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyPy for dummies

[Georg Brandl]

Cameron Laird schrieb:
> In article <[EMAIL PROTECTED]>,
> Paddy <[EMAIL PROTECTED]> wrote:
>   .
>   .
>   .
>>It is also European funding for an open source project with sprints.
>>I'm sure some eurocrat will be dissecting the project to see if it is
>>aa good way to fund technical projects.
>>
>>- Paddy.
>>
> 
> PyPy-ers, what *are* the prospects in this direction?
> Are there write-ups planned that'll be of interest to
> computing people?

There is already a whole bunch of reports for the EU at

http://codespeak.net/pypy/extradoc/eu-report/

HTH,
Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about extending tuple

[Georg Brandl]

abcd schrieb:
>> As an immutable type, tuple makes use of __new__.
>>
>> class MyTuple(tuple):
>>  def __new__(cls, *args):
>>  return tuple.__new__(cls, args)
>>
>> should work.
>>
>> Georg
> 
> strange.  not very consistent.

On the contrary -- __new__ *and* __init__ exist for all types.
The only difference is where a specific object is initialized, and
therefore which method you have to override.

__new__ is a static method (it doesn't need to be declared as one,
this is done automatically as it predates the introduction of
staticmethod()) which is called to *construct* an instance.
This can only be done once for a specific object since each call to
__new__ will result in a *new* object. In other words, this is
perfect for immutable objects -- once created, never changed.

__init__, OTOH, is called on the *instance* to initialize it. Of
course, this process can be repeated, and is therefore apt for
mutable objects like lists.

I hope you see now why it is consistent.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about extending tuple

[Georg Brandl]

abcd schrieb:
> I wanted to extend tuple but ran into a problem.  Here is what I
> thought would work
> 
> class MyTuple(tuple):
> def __init__(self, *args):
> tuple.__init__(self, args)
> 
> x = MyTuple(1,2,3,4)
> 
> That gives me...
> 
> TypeError: tuple() takes at most 1 argument (4 given).
> 
> However, this call works:
> 
> x = MyTuple((1,2,3,4))
> 
> I am perplexed only because "args" is a tuple by the definition of
> *args.  Anyone?

As an immutable type, tuple makes use of __new__.

class MyTuple(tuple):
 def __new__(cls, *args):
 return tuple.__new__(cls, args)

should work.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: very strange syntax errors

[Georg Brandl]

Peter Otten schrieb:
> hg wrote:
> 
>> I'v been facing some very strange errors lately:
>> 
>> one example:
>> 
>> def __init__(self):
>> 
>> import my_info
>> some_text = my_info.T_SOME_TEXT
>>   ^ syntax error
>> 
>> 
>> I manage to get rid of that one by moving the import on top of my file.
>> 
>> Note: Python 2.4.1 under Windows
>> 
>> 
>> Any clue ?
> 
> A guess: you may have mixed Unix ("\n") and Windows ("\r\n") newlines. Try
> to ensure that every line ends with "\r\n".

That shouldn't be a problem since Python reads source files in universal
newline mode.

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Weekly Python Patch/Bug Summary

[Georg Brandl]

Kurt B. Kaiser schrieb:
> Patch / Bug Summary
> ___
> 
> Patches :  380 open (-36) /  3658 closed (+65) /  4038 total (+29)

We should really try to keep the numbers in this magnitude :)

Georg

-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: Pygments 0.7 "Faschingskrapfn" released

[Georg Brandl]

I'm very pleased to announce the third public release of Pygments,
the generic Python syntax highlighter.

Download it from , or
look at the demonstration at .

News


The new features since 0.6 include:

* New lexers for
  * OCaml
  * Dylan
  * Java Server Pages
  * Windows batch files
  * Trac Wiki markup
  * Python tracebacks
  * ReStructuredText
  * sources.list
  * Mako templates
  * and the Befunge esoteric programming language (yay!)
* Token stream filters, which can e.g. highlight certain names or
  code tags.
* An HTML formatter that is easily subclassable.
* An option to control the command prefix for the LaTeX formatter.
* A MoinMoin parser plugin to easily get Pygments highlighting in Moin.
* ... and many little changes and fixes that are listed in the detailed
  changelog.


About
-

Pygments is a generic syntax highlighter for general use in all kinds of
software such as forum systems, wikis or other applications that need to
prettify source code. Highlights are:

* a wide range of common languages and markup formats is supported
* special attention is paid to details increasing quality by a fair amount
* support for new languages and formats are added easily
* a number of output formats is available, presently HTML, LaTeX, RTF
  and ANSI sequences
* it is usable as a command-line tool and as a library
* ... and it highlights even Brainf*ck!

The home page is at .

Read more in the FAQ list  or look at the
documentation .

regards and happy Valentine's day,
Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list1.append(list2) returns None

[Georg Brandl]

Pyenos schrieb:
> i rewrote the code following the advices from subdir of the parent thread:
> 
> # well, table is composed of a list of columns.
> # so let's stick them together
> def enlargetable(table,col):
> table.append(col) # the code won't return sorted lists :-o

Why should it sort the list?

> return_the_fucking_table_bitch=table # assign it to a new variable to 
> return it
> return return_the_fucking_table_bitch # :-|

That isn't necessary. A simple "return table" is fine.

> 
> def removecolfromtable(table,col):
> return table.remove(col)

table.remove() also returns None.

> print enlargetable([[1],[2],[3]],[4])
> 
> # and this code works.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: Pygments 0.6 "Zimtstern" released

[Georg Brandl]

I'm happy to announce the second public release of Pygments, the
generic Python syntax highlighter.

Download it from <http://cheeseshop.python.org/pypi/Pygments>, or
look at the demonstration at <http://pygments.pocoo.org/demo>.

News


The new features since 0.5.1 include:

   * New lexers: Scheme, Bash, Apache configs, Myghty templates, Groff.
   * New RTF formatter.
   * Added option for the HTML formatter to write the CSS to an external file
 in "full document" mode.
   * Improved guessing methods for various lexers.
   * Support for guessing input encoding added.
   * Encoding support added: all processing is now done with Unicode strings,
 input and output are converted from and optionally to byte strings.
   * License change to BSD.

In other news, the Trac 0.11 trunk already includes support for Pygments as
the default highlighting library.

About
-

Pygments is a generic syntax highlighter for general use in all kinds of
software such as forum systems, wikis or other applications that need to
prettify source code. Highlights are:

   * a wide range of common languages and markup formats is supported
   * special attention is paid to details increasing quality by a fair 
amount
   * support for new languages and formats are added easily
   * a number of output formats is available, presently HTML, LaTeX, RTF
 and ANSI sequences
   * it is usable as a command-line tool and as a library
   * ... and it highlights even Brainf*ck!

The home page is at <http://pygments.pocoo.org>.

Read more in the FAQ list <http://pygments.pocoo.org/faq> or
look at the documentation <http://pygments.pocoo.org/docs>.

regards,
Georg Brandl
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: perl better than python for users with disabilities?

[Georg Brandl]

Thomas Ploch schrieb:
> Martin P. Hellwig schrieb:
>> Quite punny title though I assume you are really serious and mean people 
>> with a physical disability, I won't comment any further on this subject 
>> :-), if I already offended anyone, please excuse me, since I'm original 
>> from Germany I'm not supposed to be funny.
> 
> Argh, I am writing to President Horst Köhler to take away your German
> citizenship. You _need_ to stay true to German attributes (like not
> being funny, what you have been...)! This is the last warning!

I don't think he'd have the time for that. I heard he's busy planning
his lawsuit to enforce his claim for more pension.

> Regarding the topic:
> 
> I can't see where Perl should be more accessible than Python.

Well, not really. But your $, @, %, {, }, ! etc. keys should be
accessible very fast if you want to write Perl.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fall of Roman Empire

[Georg Brandl]

Felix Benner schrieb:

>> Sorry, somehow had to do this. Please slap me (i like it, don't worry)
>> if it's totally stupid
>> 
>> 
> 
> s totally stupid! You forgot the main function! (not to mention you
> returned universe instead of everything)
> 
> static int main(int argc, char **argv) {
>   char *god_name;
>   if (argc)
>   god_name = argv[1];
>   else
>   god_name = "YHWH";
>   metaPower God = getGodByName(god_name);
>   universe *everything = makeUniverse(God);
>   while (simulatePhysics(everything));
>   return 0;
> }

Well, I'd expect God to be more clever as to do it that way.
Could you imagine toying around with your universe in C?

No, it must have been

static PyObject *
create_universe(char *god_name) {
PyObject *universe;
universe = PyObject_New(universetype, PyUniverse_Type);
if (!universe) {
PyErr_SetString(PyExc_CreationError,
"Out of spacetime, or BDFL is too busy hacking "
"on web-based collaboration tools");
return NULL;
}
universe->un_god = PyGod_FromName(god_name);
universe->un_size = 0;
universe->un_expand_rate = COSMOLOGICAL_CONSTANT;
return universe;
}

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Property error

[Georg Brandl]

king kikapu wrote:
> Hi to all,
> 
> i am trying to use properties in Python and i am sure i have made
> something wrong with the below code but i just cannot see what it is.
> 
> Can anyone please help me on this ?
> 
> The code is :
> 
> class Person(object):
> age = 0
> 
> @property
> def age():
> def fget(self):
> return self.age
> def fset(self, value):
> self.age = value
> 
> me = Person()
> me.age = "34"
> print me.age
> 
> 
> and i am getting the error:
> 
> "  File "C:\projects\Python\p2.py", line 12, in 
> me.age = "34"
> AttributeError: can't set attribute "
> 
> What exactly i am doing wrong ??

This will not work. There are some versions of a property decorator
flowing around that allow you to do a similar thing, like

class Person(object):
 age = 0

 @Property
 def age():
 def fget(self):
 return self.age
 def fset(self, value):
 self.age = value
 return locals()

but here, Property is not the built-in "property" function.

It is impossible to use the built-in property function as a decorator to create
a property that isn't read-only.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Property error

[Georg Brandl]

Peter Otten wrote:

> @decorator
> def f():
># ...
> 
> is the same as
> 
> def f():
> # ...
> f = decorator(f())
  ^^
Nope, f is not called here. (Think of staticmethod).

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: tuple.index()

[Georg Brandl]

Nick Maclaren schrieb:
> In article <[EMAIL PROTECTED]>,
> "Glenn Hutchings" <[EMAIL PROTECTED]> writes:
> |> Fredrik Lundh wrote:
> |> 
> |> > if you don't want to understand the design, nobody can force you.  but 
> arguing
> |> > that the people behind the design "don't get it" isn't very practical.
> |> 
> |> I'm not arguing that at all.  What I'm saying is that from the
> |> perspective of someone not interested in design issues, it seems like
> |> an omission for tuples to be missing the non-modifying methods that
> |> lists have.
> 
> And, from the perspective of someone VERY interested in design issues,
> from the viewpoint of program validation (a.k.a mathematical models,
> a.k.a. 'program proving' a.k.a. 'software engineering') it also seems
> like one!
> 
> If lists are intended to be homogeneous, then they should be checked
> for that, and an exception raised when an attempt is to make them
> non-homogeneous.  At least as a Python checking option.

There you have the "consenting adults" philosophy again: You know what lists
are for, so you can use them for it. You can also use them for something else,
but in that case it's moot to complain about missing features.

> If tuples are intended to be bags, then it makes no sense to allow
> them to be subscripted OR indexed.  Mathematically, 'x = a[i]' and
> 'i = a.index(x)' have dual properties - and are true duals if you
> include the constraint of no duplicate elements.

You're describing sets. Tuples are not sets. Sets are not indexable and have
unique elements.

Indexing is the *vital* point of tuples. They are an ordered collection of
values, and you are supposed to know which data is found at which index.
Don't tell me that tuples in maths are sets.

For a mathematical example, take

A = { (x,y) : 0 < x < 1, 0 < y < 1 }

Here, (x,y) is a 2-tuple, and you know that at index 0 there's the x-coordinate
of a point contained in the square A, and at index 1 there's the y-coordinate.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: funcs without () like print

[Georg Brandl]

iwl wrote:
> Hello can I make funktions callable without () like print
> at time the interpreter seems to printout the adres when I type the
> function without ()

print is not a function, it's a statement, and as such equivalent to
raise or assert.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Common Python Idioms

[Georg Brandl]

Stephen Eilert wrote:
> Hendrik van Rooyen escreveu:
> 
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Peter> Bjoern Schliessmann wrote:
>> > >> Wouldn't be "if k in d.keys()" be the exact replacement?
>> >
>> > Peter> No, 'k in d' is equivalent to 'd.has_key(k)', only with less
>> > Peter> (constant) overhead for the function call. 'k in d.keys()' on 
>> > the
>> > Peter> other hand creates a list of keys which is then searched 
>> > linearly
>> > Peter> -- about the worst thing you can do about both speed and memory
>> > Peter> footprint.
> 
> I've always used has_key(), thinking it was the only way to do it.
> Given that Python says that "There Should Be Only One Way to Do It", I
> didn't bother searching for alternatives.
 >
> Is there a list somewhere listing those not-so-obvious-idioms? I've
> seen some in this thread (like the replacement for .startswith).
> 
> I do think that, if it is faster, Python should translate
> "x.has_key(y)" to "y in x".

How and when should it do that?

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python25.zip

[Georg Brandl]

Colin J. Williams wrote:
> Dennis Lee Bieber wrote:
>> On Thu, 30 Nov 2006 18:14:11 -0500, "Colin J. Williams"
>> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>> 
>>> As part of the Python initialization, C:\Windows\System32\Python25.zip 
>>> is set up in the path.
>>>
>>> I haven't seen any documentation on the use or purpose of the zip file.
>>>
>>  Well, did you examine the contents of it?
> There is no such file in C:\Windows\System32 - Python 2.5 on a Windows XP
>> 
>>  I believe for some versions now, "import" can pull from a ZIP
>> archive -- perhaps they've put the many standard library imports into a
>> single file...
> Yes, since 2.3 - thanks to Fredrick for the pointer to PEP 273.  That 
> gives the helpful warning that the above should follow the home 
> directory in the path list.
> 
> PEP 302 says "[PYTHONPATH] is directly needed for Zip imports."
> 
> The role of Python25.zip is not clear.  Is it required in the path just 
> to enable the import X.zip capability?

No. It's there just *in case* you have a Python25.zip lying around containing
the library. By default, it isn't.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Parsing/Splitting Line

[Georg Brandl]

Fredrik Lundh schrieb:
> Noah Rawlins wrote:
> 
> 
>> I'm a nut for regular expressions and obfuscation...
>> 
>> import re
>> def splitline(line, size=4):
>>  return re.findall(r'.{%d}' % size, line)
>> 
>>  >>> splitline("helloiamsuperman")
>> ['hell', 'oiam', 'supe', 'rman']
> 
> there are laws against such use of regular expressions in certain 
> jurisdictions.

... and in particularly bad cases, you will be punished by Perl
not less than 5 years ...

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: atexit.register does not return the registered function. IMHO, it should.

[Georg Brandl]

Skip Montanaro schrieb:
>> Since that the decorator syntax is upon us, I think it would be good if
>> atexit.register() was returning the function passed as argument.  This
>> simple change to the library would solve a problem with the use of
>> atexit.register as a decorator (and I can't think of any use case where
>> this change would break any code).
> ...
> 
> Can you submit a bug report to the SourceForge bug tracker?  I'll take
> care of the problem when I have access to the subversion repository.

Sorry, didn't read this thread before the bug report, which is why I
already handled this one ;)

cheers,
Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3K idea: why not drop the colon?

[Georg Brandl]

Michael Hobbs wrote:
> Georg Brandl wrote:
>> Ron Adam wrote:
>>   
>>> Michael Hobbs wrote:
>>>
>>> 
>>>> The same problem that is solved by not having to type parens around the 
>>>> 'if' conditional, a la C and its derivatives. That is, it's unnecessary 
>>>> typing to no good advantage, IMHO. I was coding in Ruby for several 
>>>> months and got very comfortable with just typing the if conditional and 
>>>> hitting return, without any extra syntax. When I came back to Python, I 
>>>> found that I felt annoyed every time I typed the colon, since it 
>>>> obviously isn't required. The FAQ says that the colon increases 
>>>> readability, but I'm skeptical. The indentation seems to provide more 
>>>> than enough of a visual clue as to where the if conditional ends.
>>>>   
>>> I'm not sure why '\'s are required to do multi-line before the colon.
>>> 
>>
>> Special cases aren't special enough to break the rules.
>>
>> Georg
>>   
> 
> Eh? So multi-line strings are special enough to create a new syntax, 
> like, say, triple-quoted strings? Very long expressions aren't special 
> enough to create a special backslash token to continue the expression on 
> the next line? Multiple short expressions aren't special enough to 
> create a special semi-colon token to combine them on a single line?

For me, the above are not special cases in the sense that "leaving off the
line continuation character is allowed only in the line beginning a new suite"
is.

A similar special case would be, e.g., if triple quoted strings were
automatically dedented, but only if there's no text between the opening
quotes and the first linebreak. Etc. etc.

 > Programming language design is nothing more than deciding the best way
 > to deal with special cases. That even includes Lisp.

Of course. This is why the Zen includes more than one statement.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3000 idea -- + on iterables -> itertools.chain

[Georg Brandl]

Carl Banks wrote:
> Georg Brandl wrote:
>> What has a better chance of success in my eyes is an extension to yield
>> all items from an iterable without using an explicit for loop: instead of
>>
>> for item in iterable:
>>  yield item
>>
>> you could write
>>
>> yield from iterable
>>
>> or
>>
>> yield *iterable
> 
> Since this is nothing but an alternate way to spell a very specific
> (and not-too-common) for loop, I expect this has zero chance of
> success.

well, it could also be optimized internally, i.e. with a new opcode.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3000 idea -- + on iterables -> itertools.chain

[Georg Brandl]

George Sakkis wrote:
> Fredrik Lundh wrote:
> 
>> John Reese wrote:
>>
>> > It seems like it would be clear and mostly backwards compatible if the
>> > + operator on any iterables created a new iterable that iterated
>> > throught first its left operand and then its right, in the style of
>> > itertools.chain.
>>
>> you do know that "iterable" is an informal interface, right?  to what
>> class would you add this operation?
>>
>> 
> 
> The base object class would be one candidate, similarly to the way
> __nonzero__ is defined to use __len__, or __contains__ to use __iter__.

What has a better chance of success in my eyes is an extension to yield
all items from an iterable without using an explicit for loop: instead of

for item in iterable:
 yield item

you could write

yield from iterable

or

yield *iterable

etc.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3K idea: why not drop the colon?

[Georg Brandl]

Ron Adam wrote:
> Georg Brandl wrote:
>> Ron Adam wrote:
>>> Michael Hobbs wrote:
>>>
>>>> The same problem that is solved by not having to type parens around the 
>>>> 'if' conditional, a la C and its derivatives. That is, it's unnecessary 
>>>> typing to no good advantage, IMHO. I was coding in Ruby for several 
>>>> months and got very comfortable with just typing the if conditional and 
>>>> hitting return, without any extra syntax. When I came back to Python, I 
>>>> found that I felt annoyed every time I typed the colon, since it 
>>>> obviously isn't required. The FAQ says that the colon increases 
>>>> readability, but I'm skeptical. The indentation seems to provide more 
>>>> than enough of a visual clue as to where the if conditional ends.
> 
>>> I'm not sure why '\'s are required to do multi-line before the colon.
>> 
>> Special cases aren't special enough to break the rules.
>> 
>> Georg
> 
> A bit of a circular answer.
> 
>  Why the rule? -> So not to break the rule?

You proposed to allow leaving off line continuation '\' only in the
"if", "for" and "while" headers. This is a special case in my eyes.

> I would guess this probably is more applicable in this case.
> 
>  Explicit is better than implicit.

Of course, this always applies :)

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py3K idea: why not drop the colon?

[Georg Brandl]

Ron Adam wrote:
> Michael Hobbs wrote:
> 
>> The same problem that is solved by not having to type parens around the 
>> 'if' conditional, a la C and its derivatives. That is, it's unnecessary 
>> typing to no good advantage, IMHO. I was coding in Ruby for several 
>> months and got very comfortable with just typing the if conditional and 
>> hitting return, without any extra syntax. When I came back to Python, I 
>> found that I felt annoyed every time I typed the colon, since it 
>> obviously isn't required. The FAQ says that the colon increases 
>> readability, but I'm skeptical. The indentation seems to provide more 
>> than enough of a visual clue as to where the if conditional ends.
> 
> I'm not sure why '\'s are required to do multi-line before the colon.

Special cases aren't special enough to break the rules.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple question to split

[Georg Brandl]

Diez B. Roggisch schrieb:
> Diez B. Roggisch schrieb:
>> Matthias Winterland schrieb:
>>> Hi,
>>>
>>> I have a simple question. When I read in a string like:
>>> a='1,2,3,4,5 6 7,3,4', can I get the list l=[1,2,3,4,5,6,7,3,4] with a 
>>> single split-call?
>> 
>> Nope. But you could replace the commas with spaces, and then split.
> 
> Or use re.split

And not forget to map it through int() afterwards.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is there a commas-in-between idiom?

[Georg Brandl]

Peter van Kampen schrieb:
> On 2006-11-06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> I've collected a bunch of list pydioms and other notes here:
>>
>> http://effbot.org/zone/python-list.htm
> 
> """
> A = B = [] # both names will point to the same list
> """
> 
> I've been bitten by this once or twice in the past, but I have always
> wondered what it was useful for? Can anybody enlighten me?

Do you never have a situation where you want to assign the same value
to two variables?

Or are you objecting to the fact that both names point to the same object?
It couldn't be otherwise. Consider:

X = []
A = B = X

What should this do? Copy "X" and assign one copy to A, one to B?

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode/ascii encoding nightmare

[Georg Brandl]

Thomas W wrote:
> I'm getting really annoyed with python in regards to
> unicode/ascii-encoding problems.
> 
> The string below is the encoding of the norwegian word "fødselsdag".
> 
 s = 'f\xc3\x83\xc2\xb8dselsdag'

Which encoding is this?

> I stored the string as "fødselsdag" but somewhere in my code it got

You stored it where?

> translated into the mess above and I cannot get the original string
> back. It cannot be printed in the console or written a plain text-file.
> I've tried to convert it using
> 
 s.encode('iso-8859-1')
> Traceback (most recent call last):
>   File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1:
> ordinal not in range(128)

Note that "encode" on a string object is often an indication for an error.
The encoding direction (for "normal" encodings, not special things like
the "zlib" codec) is as follows:

encode: from Unicode
decode: to Unicode

(the encode method of strings first DEcodes the string with the default
encoding, which is normally ascii, then ENcodes it with the given encoding)

 s.encode('utf-8')
> Traceback (most recent call last):
>   File "", line 1, in ?
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1:
> ordinal not in range(128)
> 
> And nothing helps. I cannot remember hacing these problems in earlier
> versions of python and it's really annoying, even if it's my own fault
> somehow, handling of normal characters like this shouldn't cause this
> much hassle. Searching google for "codec can't decode byte" and
> UnicodeDecodeError etc. produces a bunch of hits so it's obvious I'm
> not alone.

Unicode causes many problems if not used properly. If you want to use Unicode
strings, use them everywhere in your Python application, decode input as early
as possible, and encode output only before writing it to a file or another
program.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Distilled

[Georg Brandl]

Paul McGuire wrote:
> "Marc 'BlackJack' Rintsch" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> In <[EMAIL PROTECTED]>, Simon Wittber
>> wrote:
>>
>>> I'd also like to remove any deprecated or stuff which is left in for
>>> backwards functionality (eg Classic classes).
>>
>> Classic classes are still needed for exceptions:
>>
> class E(object):
>> ...pass
>> ...
> raise E
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> TypeError: exceptions must be classes, instances, or strings (deprecated),
>> not type
>>
>> Ciao,
>> Marc 'BlackJack' Rintsch
> 
> I thought exceptions were converted to new-style classes for Py2.5 
> (http://docs.python.org/whatsnew/pep-352.html).

Yes, they were. Still, you can't raise instance of arbitrary new-style classes
as exceptions, and you will never be able to. In Py3k, only instances of
"BaseException" subclasses will be raisable.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Distilled

[Georg Brandl]

Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Simon Wittber
> wrote:
> 
>> I'd also like to remove any deprecated or stuff which is left in for
>> backwards functionality (eg Classic classes).
> 
> Classic classes are still needed for exceptions:
> 
 class E(object):
> ...pass
> ...
 raise E
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: exceptions must be classes, instances, or strings (deprecated),
> not type

The error is a bit misleading, since in Python 2.5 all exceptions are new-style,
but new exception classes must be derived from an existing one.
Classic classes, their instances and strings are only allowed for backwards 
compatibility.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: enumerate improvement proposal

[Georg Brandl]

James Stroud wrote:
> I think that it would be handy for enumerate to behave as such:
> 
> def enumerate(itrbl, start=0, step=1):
>i = start
>for it in itrbl:
>  yield (i, it)
>  i += step
> 
> This allows much more flexibility than in the current enumerate, 
> tightens up code in many cases, and seems that it would break no 
> existing code. Yes, I have needed this behavior with enumerate, like 
> tonight and the current example. I put the "step" parameter in for 
> conceptual symmetry with slicing.
> 
> Here is a case use (or is it use case?):

Incidentally, I yesterday wrote a patch giving enumerate() a start parameter
(and, more importantly, changing it so that it doesn't wraparound at 
sys.maxint). It can be found here:

https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586315&group_id=5470

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Metaclasses are not called in subclasses. What did I wrong?

[Georg Brandl]

Létező wrote:
> I use Python 2.4.4. Please read the code below:
> 
> ---
> from new import classobj
> 
> def mymeta(name,bases,clsdict):
> print 'meta: %s'%name
> return classobj(name,bases,clsdict)
> 
> class A(object):
> __metaclass__=mymeta
> 
> class B(A):
> pass
> 
> ---
> 
> This should print
> 
> meta: A
> meta: B
> 
> when classes A and B are created. But only meta: B is missing,
> since mymeta() is not called when class B is created.
> 
> Related python documentation states that mymeta() must be called when B is 
> created, since metaclasses are looked up in bases classes if not found in 
> the dictionary of the class itself.
> 
>>From Python 2.4.4's manual: "Otherwise, if there is at least one base class, 
> its metaclass is used (this looks for a __class__ attribute first and if not 
> found, uses its type)."

Peter already explained that when __metaclass__ is not directly defined in the
class body, it's not used as the metaclass, but the class of the first base
class is.

This is an inconsistency IMHO, since Python normally respects inherited
attributes just like those defined in the class itself.

But well, you can live with it :)

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: question about True values

[Georg Brandl]

Chetan wrote:

>>> I am joining after some network downtime here, so I seem to have missed what
>>> the real issue here is. At the risk of being completely irrelevant to the
>>> discussion here, I think it doesn't seem to be just about something or
>>> nothing - is None something or nothing? It seems to be neither:
>>
>> If is, of course, nothing. You may have misunderstood the semantics of the
>> "and" and "or" operators.
> 
> I have not. I just posted another message on the subject. All I am trying to
> point out is that the "nothingness" evaluation does not occur at the level of
> expressions. It is only when the expression is needed to make decisions about
> control flow that this comes into picture. 

This is not correct. "and" and "or" involve truth (or "somethingness") 
evaluation, as you can see from this example:

Python 2.5 (r25:51908, Sep 22 2006, 10:45:03)
 >>> class A:
... def __nonzero__(self):
... print "nonzero"
... return True
...
 >>> A() and 1
nonzero
1
 >>>

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: question about True values

[Georg Brandl]

Chetan wrote:
>> Steven D'Aprano wrote:
>> > On Sat, 28 Oct 2006 03:13:42 +0100, Steve Holden wrote:
>>  >
>> >>> Finally, while True/False is a good mental mapping for numeric 
>> >>> comparisons,
>> >>> take the following:
>> >>>
>> >>>  >>> if "Cliff is a pillar of the open source community":
>> >>>  print "thank you"
>> >>>  else:
>> >>>  print "bugger off"
>> >>>
>> >>> bugger off
>> >>>
>> 
>> First off, even though nobody has called me on it, this example really prints
>> "thank you", not "bugger off".  I got confused in my cutting and pasting.
>> Sorry about that.
>> 
>> 
>> >>> Clearly this is not true.  (Google Cliff/Dyer open source: only 11 
>> >>> hits.),
>> >>> but the string is *something* so the if block gets evaluated.
>> >>>
>> >>   >>> if "The above example was bollocks":
>> >>   ...   print "You don't know what you are talking about"
>> >>   ... else:
>> >>   ...   print "Sorry: of course you are perfectly correct"
>> >>   ...
>> >> You don't know what you are talking about
>> > Cliff is making a point about semantics, and he's absolutely correct about
>> > it, although it is irrelevant since we're talking about two-value logic
>> > not semantics.
>> Cheers,
>> Cliff
> 
> I am joining after some network downtime here, so I seem to have missed what
> the real issue here is. At the risk of being completely irrelevant to the 
> discussion here, I think it doesn't seem to be just about something or 
> nothing - is None something or nothing? It seems to be neither:

If is, of course, nothing. You may have misunderstood the semantics of the
"and" and "or" operators.

 None
 None and True
 None or True
> True
 None and False
 None or False
> False
 False or None
 False and None
> False
 True and None
 True or None
> True
 not None
> True

x and y | x something | x nothing
---
y something | y   | x
y nothing   | y   | x

x or y  | x something | x nothing
---
y something | x   | y
y nothing   | x   | y


Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: question about True values

[Georg Brandl]

J. Clifford Dyer wrote:
> Georg Brandl wrote:
>> J. Clifford Dyer wrote:
>> 
>>>  >>> (1 > 0) < 1
>>> False
>>>  >>> 1 > 0 < 1
>>> True
>>>  >>> 1 > (0 < 1)
>>> False
>>>  >>> 10 > (0 < 1)
>>> True
>> 
>> I hope you know why this works the way it does.
>> 
>> Georg
> 
> Yes, I do understand why it works.  I couldn't have crafted it if I 
> didn't, but my point is that the reason why it works is not explainable 
> if you believe that you are dealing with booleans.

Okay, but you should have left off the second example, because it has nothing
to do with the others.

>  It's only 
> explainable if you recognize that you are actually dealing with 
> integers, and specifically, 1 and 0.  So the something/nothing dichotomy 
> combined with an understanding of what the comparison operation REALLY 
> does (yield a 1 or a 0) helps you understand where your result came 
> from, while thinking in terms of true/false will mislead you.

That's true. The only sensible thing to do, if you had "real" booleans, for
1 > True, would be to raise an exception.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: what is "@param" in docstrings?

[Georg Brandl]

[EMAIL PROTECTED] wrote:
> I'm starting to read about twisted and I keep seeing things like:
> [from twisted/internet/app.py]
> 
> def __init__(self, name, uid=None, gid=None, authorizer=None,
> authorizer_=None):
> """Initialize me.
> If uid and gid arguments are not provided, this application
> will
> default to having the uid and gid of the user and group who
> created it.
> 
> @param name: a name
> 
> @param uid: (optional) a POSIX user-id.  Only used on POSIX
> systems.
> 
> @param gid: (optional) a POSIX group-id.  Only used on POSIX
> systems.
> """
> _AbstractServiceCollection.__init__(self)
> self.name = name
> ...
> 
> What does the "@param" mean?  It looks like something meant to be
> machine readable.  Alas, googling on "@param" doesn't work...  It looks
> at first like a decorator, but that doesn't make much sense.

It's docstring markup that can be parsed by e.g. epydoc. It's borrowed
from JavaDoc's similar syntax.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Import if condition is correct

[Georg Brandl]

MindClass wrote:
> Is possible import a library according to a condition?
> 
> if Foo = True:
> import bar
> 

Why don't you try it?

(in the above code, not the import is the problem, but using the
assignment operator in an expression)

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: question about True values

[Georg Brandl]

J. Clifford Dyer wrote:

>  >>> (1 > 0) < 1
> False
>  >>> 1 > 0 < 1
> True
>  >>> 1 > (0 < 1)
> False
>  >>> 10 > (0 < 1)
> True

I hope you know why this works the way it does.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN compiler2 : Produce bytecode from Python 2.5 Abstract Syntax Trees

[Georg Brandl]

Michael Spencer wrote:
> Georg Brandl wrote:
>> Michael Spencer wrote:
>>> Announcing: compiler2
>>> -
>>>
>>> For all you bytecode enthusiasts:  'compiler2' is an alternative to the 
>>> standard 
>>> library 'compiler' package, with several advantages.
>> 
>> Is this a rewrite from scratch, or an improved stdlib compiler package?
>> 
>> In the latter case, maybe you can contribute some patches to the core.
>> 
>> Georg
> 
> Georg
> 
> It started as the latter (i.e., the stdlib compiler package improved) and 
> proceeded via incremental change with the twin goals of generating correct 
> object code and creating a clean compiler architecture (the latter somewhat 
> subjective of course).  I'd be happy in principle to contribute the work, but 
> the sum of the changes amounts to a substantial re-write, so I don't think it 
> can be meaningfully submitted as a patch.

Perhaps you can bring up a discussion on python-dev about your improvements
and how they could be integrated into the standard library...

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint: What's wrong with the builtin map()

[Georg Brandl]

Tuomas wrote:
> Georg Brandl wrote:
>> Some people think that all occurences of map() must be replaced
>> by list comprehensions. The designer of pylint seems to be
>> one of those.
> 
> So it seems, but why?

See Fredrik's post. There's no error in the expression with map(),
it's just less effective than a LC, but only if used with a
lambda.

> Formally spoken we ase "using variable 'x' before 
> assigment" in the comprehension too.

That's another issue. I'd suggest a bug in pylint. (You probably
have a variable called "x" later in the file.

My version of pylint (0.12.1) doesn't show this "error".

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pylint: What's wrong with the builtin map()

[Georg Brandl]

Tuomas wrote:
> #!/usr/bin/python
> """test pydev_0.9.3/../pylint"""
> __revision__ = "test_mod 0.1 by TV 06/10/22"
> 
> lst = ['aaa', ' bbb', '\tccc\n']
> lst = map(lambda x: x.strip(), lst)
> 
> result = """
> No config file found, using default configuration
> * Module test_mod
> W:  6: Used builtin function 'map'
> E:  6: Using variable 'x' before assigment

Some people think that all occurences of map() must be replaced
by list comprehensions. The designer of pylint seems to be
one of those.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN compiler2 : Produce bytecode from Python 2.5 Abstract Syntax Trees

[Georg Brandl]

Michael Spencer wrote:
> Announcing: compiler2
> -
> 
> For all you bytecode enthusiasts:  'compiler2' is an alternative to the 
> standard 
> library 'compiler' package, with several advantages.

Is this a rewrite from scratch, or an improved stdlib compiler package?

In the latter case, maybe you can contribute some patches to the core.

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: default variable in python $_

[Georg Brandl]

rh0dium wrote:
> Hi all,
> 
> So I have this simple little routine..  say like this..
> 
> 
> def foo()
>return {"a":"b", "b":"c"}
> 
> if foo():
>print "Have foo"
> 
> 
> Now I want the dictionary item a (ie. b)
> 
> How can I do it the above way or do I still have to go like this..
> 
> def foo()
>return {"a":"b", "b":"c"}
> 
> z = foo()
> if z:
>print "Have foo"
>print z['a']
> 
> This is where $_ in perl is awesome - There must be a default variable
> in python right?

Why should there? When you're learning a new language, the first thing you
should do is to empty your mind and stop expecting concepts known from other
languages. Instead, try to grasp what the essence of the new language is.

In the case of Python, one credo is "explicit is better than implicit".
IMO, this precludes, among other things, the notion of a "default variable".

Where is the problem with your second snippet?

Georg
-- 
http://mail.python.org/mailman/listinfo/python-list