On Mon, 29 Jun 2009 13:05:51 +0100, Paul Moore wrote:
>> As for a bytes version of sys.argv and os.environ, you're welcome to
>> propose a patch (this would be a separate issue on the aforementioned
>> issue tracker).
>
> But please be aware that such a proposal would have to consider:
>
> 1. Th
On Mon, 29 Jun 2009 11:41:11 +, Antoine Pitrou wrote:
> Nobody nowhere.com> writes:
>>
>> This results in an internal error:
>>
>> > "\udce4\udceb\udcef\udcf6\udcfc".encode("iso-8859-1", "surrogateescape")
>> Traceback (most recent call last):
>> File "", line 1, in
>> SystemError: Objec
On Mon, 29 Jun 2009 13:57:49 +0200, Hallvard B Furuseth wrote:
>> Okay, that's useful, except that it may have some bugs:
>> (...)
>> Assuming that this gets fixed, it should make most of the problems with
>> 3.0 solvable. OTOH, it wouldn't have killed them to have added e.g.
>> sys.argv_bytes and
2009/6/29 Antoine Pitrou :
> As for a bytes version of sys.argv and os.environ, you're welcome to propose a
> patch (this would be a separate issue on the aforementioned issue tracker).
But please be aware that such a proposal would have to consider:
1. That on Windows, the native form is the cha
Nobody writes:
>On Sun, 28 Jun 2009 14:36:37 +0200, Martin v. Löwis wrote:
>> See PEP 383.
>
> Okay, that's useful, except that it may have some bugs:
> (...)
> Assuming that this gets fixed, it should make most of the problems with
> 3.0 solvable. OTOH, it wouldn't have killed them to have added
Nobody nowhere.com> writes:
>
> This results in an internal error:
>
> > "\udce4\udceb\udcef\udcf6\udcfc".encode("iso-8859-1", "surrogateescape")
> Traceback (most recent call last):
> File "", line 1, in
> SystemError: Objects/bytesobject.c:3182: bad argument to internal function
Please rep
On Sun, 28 Jun 2009 14:36:37 +0200, Martin v. Löwis wrote:
>> 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 enco
On Sun, 28 Jun 2009 21:25:13 +, Benjamin Peterson wrote:
>> > The email module is, yes, broken. You can recover the bytestrings of
>> > command-line arguments and environment variables.
>>
>> 1. Does Python offer any assistance in doing so, or do you have to
>> manually convert the surrogates
Scott David Daniels wrote:
> Nobody wrote:
>> On Sat, 27 Jun 2009 16:12:10 -0500, Benjamin Peterson wrote:
>>
>>
>> That's a significant improvement
>> All in all, Python 3.x still has a long way to go before it will be
>> suitable for real-world use.
>
> Fortunately, I have assiduously avoid
On Sun, 28 Jun 2009 23:13:34 +0100, Martin v. Löwis
wrote:
On behalf of the Python development team, I'm thrilled to announce the
first production release of Python 3.1.
Why is everyone always thrilled to announce things?
I cannot talk about everyone, but in the specific case, I suppose
B
>> On behalf of the Python development team, I'm thrilled to announce the
>> first production release of Python 3.1.
>
> Why is everyone always thrilled to announce things?
I cannot talk about everyone, but in the specific case, I suppose
Benjamin was thrilled because it was his first release of
On Sat, 27 Jun 2009 22:12:10 +0100, Benjamin Peterson
wrote:
On behalf of the Python development team, I'm thrilled to announce the
first production release of Python 3.1.
Why is everyone always thrilled to announce things? Why is noone ever
bored to announce? :-)
So PEP 378 got in then?
> 2. How do you do this for non-invertible encodings (e.g. ISO-2022)?
ISO-2022 cannot be used as a system encoding.
Please do read the responses I write, and please do identify yourself.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Benjamin Peterson writes:
>Nobody nowhere.com> writes:
>> On Sun, 28 Jun 2009 19:21:49 +, Benjamin Peterson wrote:
>> 1. Does Python offer any assistance in doing so, or do you have to
>> manually convert the surrogates which are generated for unrecognised bytes?
>
> fs_encoding = sys.getfiles
Nobody nowhere.com> writes:
>
> On Sun, 28 Jun 2009 19:21:49 +, Benjamin Peterson wrote:
>
> >> Yes, but do you get back the original byte strings? Maybe I'm missing
> >> something, but my impression is that this is still an issue for the email
> >> module as well as command-line arguments
On Sun, 28 Jun 2009 13:31:50 -0400, Terry Reedy wrote:
>>> Nobody 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. So
On Sun, 28 Jun 2009 19:21:49 +, Benjamin Peterson wrote:
>> Yes, but do you get back the original byte strings? Maybe I'm missing
>> something, but my impression is that this is still an issue for the email
>> module as well as command-line arguments and environment variables.
>
> The email
Aahz pythoncraft.com> writes:
> Yes, but do you get back the original byte strings? Maybe I'm missing
> something, but my impression is that this is still an issue for the email
> module as well as command-line arguments and environment variables.
The email module is, yes, broken. You can recove
In article ,
Benjamin Peterson wrote:
>Nobody 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.
Yes, but do you g
Paul Moore 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" attribut
Nobody wrote:
On Sun, 28 Jun 2009 15:22:15 +, Benjamin Peterson wrote:
Nobody 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. Som
Nobody 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.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, 28 Jun 2009 15:22:15 +, Benjamin Peterson wrote:
> Nobody 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 th
2009/6/28 Christian Heimes :
> Paul Moore schrieb:
>> 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.s
> 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
Paul Moore schrieb:
> 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 wa
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 alre
Nobody wrote:
On Sat, 27 Jun 2009 16:12:10 -0500, Benjamin Peterson wrote:
That's a significant improvement
All in all, Python 3.x still has a long way to go before it will be
suitable for real-world use.
Fortunately, I have assiduously avoided the real word, and am happy to
embrace the w
Nobody 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?
--
http://mail.python.org/mailman/listinfo/python-list
> 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.
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
> h
Benjamin Peterson wrote:
> On behalf of the Python development team, I'm thrilled to announce the first
> production release of Python 3.1.
Excellent news!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
--
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
33 matches
Mail list logo
