«

On behalf of the Python development team, I'm thrilled to announce the first
production release of Python 3.1.

Python 3.1 focuses on the stabilization and optimization of the features and
changes that Python 3.0 introduced. For example, the new I/O system has been
rewritten in C for speed. File system APIs that use unicode strings now handle
paths with undecodable bytes in them. Other features include an ordered
dictionary implementation, a condensed syntax for nested with statements, and
support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1,
see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python
distribution.

To download Python 3.1 visit:

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

The 3.1 documentation can be found at:

http://docs.python.org/3.1

Bugs can always be reported to:

http://bugs.python.org


Enjoy!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 3.1's contributors)

On Sat, 27 Jun 2009 16:12:10 -0500, Benjamin Peterson wrote:

> Python 3.1 focuses on the stabilization and optimization of the features and
> changes that Python 3.0 introduced. For example, the new I/O system has been
> rewritten in C for speed. File system APIs that use unicode strings now
> handle paths with undecodable bytes in them.

That's a significant improvement. It still decodes os.environ and sys.argv
before you have a chance to call sys.setfilesystemencoding(), but it
appears to be recoverable (with some effort; I can't find any way to re-do
the encoding without manually replacing the surrogates).

However, sys.std{in,out,err} are still created as text streams, and AFAICT
there's nothing you can do about this from within your code.

All in all, Python 3.x still has a long way to go before it will be
suitable for real-world use.

> That's a significant improvement. It still decodes os.environ and sys.argv
> before you have a chance to call sys.setfilesystemencoding(), but it
> appears to be recoverable (with some effort; I can't find any way to re-do
> the encoding without manually replacing the surrogates).

See PEP 383.

> However, sys.std{in,out,err} are still created as text streams, and AFAICT
> there's nothing you can do about this from within your code.

That's intentional, and not going to change. You can access the
underlying byte streams if you want to, as you could already in 3.0.

Regards,
Martin

P.S. Please identify yourself on this newsgroup.

Nobody <nobody <at> nowhere.com> writes:
> All in all, Python 3.x still has a long way to go before it will be
> suitable for real-world use.

Such as?

2009/6/28 "Martin v. Löwis" <>:
>> However, sys.std{in,out,err} are still created as text streams, and AFAICT
>> there's nothing you can do about this from within your code.
>
> That's intentional, and not going to change. You can access the
> underlying byte streams if you want to, as you could already in 3.0.

I had a quick look at the documentation, and couldn't see how to do
this. It's the first time I'd read the new IO module documentation, so
I probably missed something obvious. Could you explain how I get the
byte stream underlying sys.stdin? (That should give me enough to find
what I was misunderstanding in the docs).

Thanks,
Paul.

>>>>> Paul Moore <> (PM) wrote:

>PM> 2009/6/28 "Martin v. Löwis" <>:
>>>> However, sys.std{in,out,err} are still created as text streams, and AFAICT
>>>> there's nothing you can do about this from within your code.
>>>
>>> That's intentional, and not going to change. You can access the
>>> underlying byte streams if you want to, as you could already in 3.0.

>PM> I had a quick look at the documentation, and couldn't see how to do
>PM> this. It's the first time I'd read the new IO module documentation, so
>PM> I probably missed something obvious. Could you explain how I get the
>PM> byte stream underlying sys.stdin? (That should give me enough to find
>PM> what I was misunderstanding in the docs).

http://docs.python.org/3.1/library/sys.html#sys.stdin
--
Piet van Oostrum <>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email:

On Sun, 28 Jun 2009 15:22:15 +0000, Benjamin Peterson wrote:

> Nobody <nobody <at> nowhere.com> writes:
>> All in all, Python 3.x still has a long way to go before it will be
>> suitable for real-world use.
>
> Such as?

Such as not trying to shoe-horn every byte string it encounters into
Unicode. Some of them really are *just* byte strings.

Nobody <nobody <at> nowhere.com> writes:
>
> Such as not trying to shoe-horn every byte string it encounters into
> Unicode. Some of them really are *just* byte strings.


You're certainly allowed to convert them back to byte strings if you want.

Nobody wrote:
> On Sun, 28 Jun 2009 15:22:15 +0000, Benjamin Peterson wrote:
>
>> Nobody <nobody <at> nowhere.com> writes:
>>> All in all, Python 3.x still has a long way to go before it will be
>>> suitable for real-world use.
>> Such as?
>
> Such as not trying to shoe-horn every byte string it encounters into
> Unicode. Some of them really are *just* byte strings.

Let's ignore the disinformation. So false it is hardly worth refuting.

Paul Moore <p.f.moore <at> gmail.com> writes:

> The "buffer" attribute doesn't seem to be documented in the docs for
> the io module. I'm guessing that the TextIOBase class should have a
> note that you get at the buffer through the "buffer" attribute?


Good point. I've now documented it, and the "raw" attribute of BufferedIOBase.