Re: [Python-Dev] Python-3.0, unicode, and os.environ

There has been some discussion here that users should use the str or byte function variant based on what is relevant to their system, for example when getting a list of file names or opening a file. That thought process really doesn't do much for those of us that write code that needs to run on a

Re: [Python-Dev] RELEASED Python 3.0 final

On 01:47 am, [EMAIL PROTECTED] wrote: In spite of Python being a programming language, there is a difference between 'casual user of the language' and 'library developer'; 3.0 is certainly a must for all actual library developers, and I'm sure most of them know about 3.0 by now. We're talking ab

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Guido van Rossum writes: > This sounds too pessimistic to me. I expect that in five years it will > be universally accepted that these variables must be encoded in a > standard encoding. Archival material will not catch up until the plastic rots. And I bet it takes ten years before the Japane

Re: [Python-Dev] Python-3.0, unicode, and os.environ

"Martin v. Löwis" writes: > >> 5) represent all environment variables in Unicode strings, > >>including the ones that currently fail to decode. > >>(then do the same to file names, then drop the byte-oriented > >> file operations again) > > > > Please, don't do that! Bytes are no

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Nick Coghlan writes: > True, but it's still a fairly important problem to have a solution to. > Even internally in large organisations there can be some pretty insane > environments as cruft accumulates over the years. M&A and globalization makes it inevitable. Toshio will remember the Mizuho

Re: [Python-Dev] RELEASED Python 3.0 final

On 5 Dec, 06:10 pm, [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 11:27 PM, <[EMAIL PROTECTED]> wrote: With all due respect, for me, "library support" and "serious use" are synonymous. Glyph, I cannot have a discussion with you if every single post of yours is longer than my combined daily

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Sat, 6 Dec 2008 at 13:06, Steven D'Aprano wrote: Applications can deal with such weird file names. KDE's file manager (konqueror) and file selection dialog both show the character as a small square, presumably the font's missing character glyph, and KDE apps can open and save the file. Still s

Re: [Python-Dev] Python-3.0, unicode, and os.environ

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Eckhardt wrote: > On Friday 05 December 2008, Guido van Rossum wrote: >> At the risk of bringing up something that was already rejected, let me >> propose something that follows the path taken in 3.0 for filenames, >> rather than doubling back:

Re: [Python-Dev] RELEASED Python 3.0 final

Thomas Wouters <[EMAIL PROTECTED]> wrote: > Allow me to paraphrase glyph (with whom I'm in complete agreement, for what > it's worth): many newbies will be disappointed by Python if they start with > Python 3.0 and discover that most of the cool possibilities they had heard > about are 'being work

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Sat, 6 Dec 2008 11:48:27 am Nick Coghlan wrote: > Toshio Kuratomi wrote: > > Nick Coghlan wrote: ... > >> Why? Most programs won't be able to do anything with it. And if > >> the program *can* do something with it... that's what the bytes > >> version of the APIs are for. > > > > Nonsense. A pr

Re: [Python-Dev] Python-3.0, unicode, and os.environ

>> And environment variables, command line arguments, and file names >> are not bytes, but characters. > > On Windows NT, sure. On Unix they're still bytes no matter how much we > want them to be characters. Only in the API of the OS itself. Treating them as bytes in the application is a mistake.

Re: [Python-Dev] RELEASED Python 3.0 final

On Sat, 6 Dec 2008 12:47:45 pm Guido van Rossum wrote: > But I disagree that "most of the cool possibilities they have heard > about" are necessarily third party libraries. Python's standard > library has lots of stuff to offer. +1 on that. I've been using Python for a decade now, and the first th

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Fri, Dec 5, 2008 at 19:22, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Please, don't do that! Bytes are not characters! > > And environment variables, command line arguments, and file names > are not bytes, but characters. On Windows NT, sure. On Unix they're still bytes no matter how much

Re: [Python-Dev] RELEASED Python 3.0 final

On Fri, Dec 5, 2008 at 4:49 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On Fri, Dec 5, 2008 at 19:10, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> >> On Thu, Dec 4, 2008 at 11:27 PM, <[EMAIL PROTECTED]> wrote: >> > With all due respect, for me, "library support" and "serious use" are >> > sy

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote: You can't display a non-decodable filename to the user, hence the user will have no idea what they're working on. Non-filesystem related apps have no business trying to deal with insane filenames. Sigh, same arguments, all over again. Again, *bot

Re: [Python-Dev] Python-3.0, unicode, and os.environ

>> 5) represent all environment variables in Unicode strings, >>including the ones that currently fail to decode. >>(then do the same to file names, then drop the byte-oriented >> file operations again) > > Please, don't do that! Bytes are not characters! And environment variables, co

Re: [Python-Dev] RELEASED Python 3.0 final

> There was already "Programming Language :: Python", provided by many > packages. I think version compatibility relationships meant by each of > these classifiers should be made explicit, wherever it is that > documentation for classifiers is provided. > > I don't recall having seen any such doc

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Toshio Kuratomi wrote: > Nick Coghlan wrote: >> Toshio Kuratomi wrote: >>> Are most programs specific to one organization or are they distributed >>> to other people? >> The former. That's pretty well documented in assorted IT literature >> ('shrink-wrap' and open source commodity software are stil

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Sat, 6 Dec 2008 09:18:47 am Nick Coghlan wrote: > Toshio Kuratomi wrote: > > Guido van Rossum wrote: > >> Glob was just an example. Many use cases for directory traversal > >> couldn't care less if they see *all* files. > > > > Okay. Makes it harder to prove correct or not if I don't know what

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Fri, Dec 5, 2008 at 18:48, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Toshio Kuratomi wrote: >> Nick Coghlan wrote: >>> Toshio Kuratomi wrote: Guido van Rossum wrote: > Glob was just an example. Many use cases for directory traversal > couldn't care less if they see *all* files.

Re: [Python-Dev] RELEASED Python 3.0 final

On Fri, Dec 5, 2008 at 19:10, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 11:27 PM, <[EMAIL PROTECTED]> wrote: > > With all due respect, for me, "library support" and "serious use" are > > synonymous. > > Glyph, I cannot have a discussion with you if every single post of

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Toshio Kuratomi wrote: > Nick Coghlan wrote: >> Toshio Kuratomi wrote: >>> Guido van Rossum wrote: Glob was just an example. Many use cases for directory traversal couldn't care less if they see *all* files. >>> Okay. Makes it harder to prove correct or not if I don't know what the

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Fri, 5 Dec 2008 at 12:11, Guido van Rossum wrote: On Fri, Dec 5, 2008 at 12:05 PM, Toshio Kuratomi <[EMAIL PROTECTED]> wrote: Guido van Rossum wrote: On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt <[EMAIL PROTECTED]> wrote: In 99% of all cases, using the default encoding will work and do w

Re: [Python-Dev] RELEASED Python 3.0 final

> Good. Now we just need to populate them. I take it the classifiers without > minor numbers imply any known minor version (e.g., 2 ==> 2.3 and greater)? Perhaps. As usual, they mean what people use them for. I intended them to mean 2.x and 3.x, respectively, with no constraint on x (i.e. inclu

[Python-Dev] Merging flow

Nick Coghlan wrote: > For now it looks like we might have to maintain 3.0 manually, with > svnmerge only helping out for trunk->2.6 and trunk->py3k Does it make the bookkeeping horrible if you merge from trunk straight to 3.0, and then blocked svnmerged changes from propagating? -jJ

Re: [Python-Dev] Merging flow

On Dec 5, 2008, at 5:31 PM, Nick Coghlan wrote: I think we're discovering the real reasons why people generally prefer to use a DVCS when trying to manage multiple branches :P Really? I don't. The issue has nothing to do with someone maintaining private change sets, or wanting to do develop

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Nick Coghlan wrote: > Toshio Kuratomi wrote: >> Guido van Rossum wrote: >>> Glob was just an example. Many use cases for directory traversal >>> couldn't care less if they see *all* files. >>> >> Okay. Makes it harder to prove correct or not if I don't know what the >> use case is :-) I can't thi

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Nick Coghlan wrote: > Toshio Kuratomi wrote: >> Are most programs specific to one organization or are they distributed >> to other people? > > The former. That's pretty well documented in assorted IT literature > ('shrink-wrap' and open source commodity software are still relatively > new players

Re: [Python-Dev] Merging flow

Nick Coghlan wrote: I think we're discovering the real reasons why people generally prefer to use a DVCS when trying to manage multiple branches :P For now it looks like we might have to maintain 3.0 manually, with svnmerge only helping out for trunk->2.6 and trunk->py3k... The problem seems t

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Toshio Kuratomi wrote: > Are most programs specific to one organization or are they distributed > to other people? The former. That's pretty well documented in assorted IT literature ('shrink-wrap' and open source commodity software are still relatively new players on the scene that started to shi

Re: [Python-Dev] Merging flow

Fred Drake wrote: > On Dec 5, 2008, at 2:20 PM, Mark Dickinson wrote: >> Did I mess up somewhere, or does svnmerge not work on >> a revision that was itself the result of an svnmerge? > > I ran into this yesterday as well with my patch to the cgi module. The > work-around was to revert the change

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Victor Stinner wrote: >>> It would be maybe easier if os.environ supports bytes and unicode keys. >>> But we have to keep these assertions: >>>os.environ[bytes] -> bytes >>>os.environ[str] -> str >> I think the same choices have to be made here. If LANG=C, we still have >> to decide what t

Re: [Python-Dev] __import__ docs follow-up

Georg Brandl wrote: > Hi, > > as a follow-up to the thread a few days ago, and the bug report, I've > rewritten most of the __import__ docs. I've attached the suggested patch > to the issue . > > I'd be glad for reviews. Also, I'd like to ask about opinions if t

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Toshio Kuratomi wrote: > Guido van Rossum wrote: >> Glob was just an example. Many use cases for directory traversal >> couldn't care less if they see *all* files. >> > Okay. Makes it harder to prove correct or not if I don't know what the > use case is :-) I can't think of a single use case off-

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Hi, > > But they are open questions (already asked in the bug tracker): > > I answered these in the bug tracker. Here are the answers for the > mailing list: Oh, sorry. I didn't follow the end of the discussion on the bug tracker. > >os.environb['PATH'] = '\xff' > >=> os.environ['PATH']

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Guido van Rossum wrote: > At the risk of bringing up something that was already rejected, let me > propose something that follows the path taken in 3.0 for filenames, > rather than doubling back: > > For os.environ, os.getenv() and os.putenv(), I think a similar > approach as used for os.listdir()

Re: [Python-Dev] RELEASED Python 3.0 final

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregor Lingl wrote: > > [EMAIL PROTECTED] schrieb: >> To be fair, if someone asked me specifically about educating non- >> programmer adults about programming, I would probably at least >> *mention* py3, if not recommend it outright. The improved c

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Guido van Rossum wrote: > Glob was just an example. Many use cases for directory traversal > couldn't care less if they see *all* files. > Okay. Makes it harder to prove correct or not if I don't know what the use case is :-) I can't think of a single use case off-hand. Even your example of a ?

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Fri, Dec 5, 2008 at 12:05 PM, Toshio Kuratomi <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: >> On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt <[EMAIL PROTECTED]> wrote: >>> In 99% of all cases, using the default encoding will work and do what people >>> expect, which is why I would make

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Guido van Rossum wrote: > On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt <[EMAIL PROTECTED]> wrote: >> In 99% of all cases, using the default encoding will work and do what people >> expect, which is why I would make this conversion automatic. In all other >> cases, it will at least not fail silen

Re: [Python-Dev] RELEASED Python 3.0 final

On 5-Dec-08, at 8:40 AM, A.M. Kuchling wrote: On Fri, Dec 05, 2008 at 05:40:46AM -, [EMAIL PROTECTED] wrote: For most users, especially new users who have yet to be impressed with Python's power, 2.x is much better. It's not like "library support" is one small check-box on the languag

Re: [Python-Dev] ANN: new python-porting mailing list

[EMAIL PROTECTED] schrieb: > Georg>[EMAIL PROTECTED] > > Georg> It is a public mailing list open to everyone. We expect active > Georg> participation of many people porting their libraries/programs, > Georg> and hope that the list can be a help to all wanting to go this >

Re: [Python-Dev] ANN: new python-porting mailing list

Georg>[EMAIL PROTECTED] Georg> It is a public mailing list open to everyone. We expect active Georg> participation of many people porting their libraries/programs, Georg> and hope that the list can be a help to all wanting to go this Georg> (not always smooth :-) way. I

Re: [Python-Dev] RELEASED Python 3.0 final

[EMAIL PROTECTED] schrieb: To be fair, if someone asked me specifically about educating non- programmer adults about programming, I would probably at least *mention* py3, if not recommend it outright. The improved consistency is worth a lot in an educational setting. (But, if one is educa

Re: [Python-Dev] Merging flow

On Dec 5, 2008, at 2:20 PM, Mark Dickinson wrote: Did I mess up somewhere, or does svnmerge not work on a revision that was itself the result of an svnmerge? I ran into this yesterday as well with my patch to the cgi module. The work-around was to revert the change to that property and edit

Re: [Python-Dev] RELEASED Python 3.0 final

Guido van Rossum schrieb: I hear some folks are considering advertising 3.0 as experimental or not ready for serious use yet. I think that's too negative -- we should encourage people to use it, period. They'll have to decide for themselves whether they can live with the lack of ported 3rd par

Re: [Python-Dev] Merging flow

On Fri, Dec 5, 2008 at 11:20, Mark Dickinson <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: >> Flow diagram >> >> >> trunk ---> release26-maint >> \-> py3k ---> release30-maint >> > > I'm running into problems m

Re: [Python-Dev] ANN: new python-porting mailing list

On Fri, Dec 5, 2008 at 10:36, Georg Brandl <[EMAIL PROTECTED]> wrote: > Hi all, > > to facilitate discussion about porting Python code between different versions > (mainly of course from 2.x to 3.x), we've created a new mailing list > > [EMAIL PROTECTED] > > It is a public mailing list open to ev

Re: [Python-Dev] Merging flow

On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Flow diagram > > > trunk ---> release26-maint > \-> py3k ---> release30-maint > I'm running into problems making this work, with a trivial change: I committed r67590 (which adds a single ass

[Python-Dev] ANN: new python-porting mailing list

Hi all, to facilitate discussion about porting Python code between different versions (mainly of course from 2.x to 3.x), we've created a new mailing list [EMAIL PROTECTED] It is a public mailing list open to everyone. We expect active participation of many people porting their libraries/pro

[Python-Dev] __import__ docs follow-up

Hi, as a follow-up to the thread a few days ago, and the bug report, I've rewritten most of the __import__ docs. I've attached the suggested patch to the issue . I'd be glad for reviews. Also, I'd like to ask about opinions if this "winning idiom" (as a bug comm

Re: [Python-Dev] RELEASED Python 3.0 final

On Dec 5, 2008, at 10:25 AM, [EMAIL PROTECTED] wrote: Good. Now we just need to populate them. I take it the classifiers without minor numbers imply any known minor version (e.g., 2 ==> 2.3 and greater)? This is an excellent question, Skip. There was already "Programming Language :: Pyth

Re: [Python-Dev] RELEASED Python 3.0 final

On Thu, Dec 4, 2008 at 11:27 PM, <[EMAIL PROTECTED]> wrote: > With all due respect, for me, "library support" and "serious use" are > synonymous. Glyph, I cannot have a discussion with you if every single post of yours is longer than my combined daily output. Please spend some time writing shorte

Re: [Python-Dev] RELEASED Python 3.0 final

On Dec 4, 2008, at 7:59 PM, [EMAIL PROTECTED] wrote: On 02:35 am, [EMAIL PROTECTED] wrote: On Thu, Dec 04, 2008 at 05:29:31PM -0800, Raymond Hettinger wrote: Here's a bright idea. On the 3.0 release page, include a box listing which major third-party apps have been converted. Update it on

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Fri, Dec 5, 2008 at 2:27 AM, Ulrich Eckhardt <[EMAIL PROTECTED]> wrote: > Seriously, what would you suggest to someone that > wants to handle paths in a portable way? Using the Unicode variants of > functions is fubar, because encoding/decoding is not universally possible. > Using the byte varia

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Victor Stinner wrote: > Hi, > > Le Thursday 04 December 2008 21:02:19 Toshio Kuratomi, vous avez écrit : > >> These mixed encodings can occur for a variety of reasons. Here's an >> example that isn't too contrived :-) >> (...) >> Furthermore, they don't want to suffer from the space loss of usin

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (11/28/08 - 12/05/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2233 open (+55) / 14139 closed (+41) / 16372 total (+96) Open issues with patches: 753 Average

Re: [Python-Dev] Python + Java Integration

> One thing that would help Python in this "debate" (or, perhaps simply > put it in the running, at least as a "next Java" candidate) would be > if Python had an easier migration path for Java developers that > currently rely upon various third-party libraries. The wealth of > third-party

Re: [Python-Dev] RELEASED Python 3.0 final

On Fri, Dec 05, 2008 at 05:40:46AM -, [EMAIL PROTECTED] wrote: > For most users, especially new users who have yet to be impressed with > Python's power, 2.x is much better. It's not like "library support" is > one small check-box on the language's feature sheet: most of the > attractive

Re: [Python-Dev] RELEASED Python 3.0 final

Martin> There is. There have been the following trove classifiers Martin> defined for a few weeks now: Martin> Programming Language :: Python :: 2 Martin> Programming Language :: Python :: 2.3 Martin> Programming Language :: Python :: 2.4 Martin> Programming Language :: Py

[Python-Dev] Python security: draft article on the wiki

Hi, I started to write a short article about Python security on the wiki: http://wiki.python.org/moin/Security Nothing useful yet. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list Python-Dev@python.org http://

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Terry Reedy wrote: > Toshio Kuratomi wrote: >> >>> I would think life would be ultimately easier if either the file server >>> or the shell server automatically translated file names from jis and >>> utf8 and back, so that the PATH on the *nix shell server is entirely >>> utf8. >> >> This is not po

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Dec 5, 2008, at 5:27 AM, Ulrich Eckhardt wrote: Using the byte variant is equally fubar, because e.g. on MS Windows it is not supported, except through a very lossy roundtrip through the locale's codepage, limiting your functionality. Yeah, IMO whole mess could have been avoided by keepin

Re: [Python-Dev] Fix for frame_setlineno() in frameobject.c function

Hi, Please post this on the issue tracker. http://bugs.python.org On Fri, Dec 5, 2008 at 4:42 AM, <[EMAIL PROTECTED]> wrote: > Hello, > > This concerns a known bug in the frame_setlineno() function for Python > 2.5.x and 2.6.x (maybe in earlier version too). It is not possible to use > this funct

Re: [Python-Dev] RELEASED Python 3.0 final

On Fri, Dec 5, 2008 at 12:35 AM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Thu, Dec 04, 2008 at 05:29:31PM -0800, Raymond Hettinger wrote: >> Here's a bright idea. On the 3.0 release page, include a box listing >> which major third-party apps have been converted. Update it >> once every coupl

Re: [Python-Dev] RELEASED Python 3.0 final

On Thu, 4 Dec 2008 22:05:05 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: On Thu, Dec 4, 2008 at 9:40 PM, <[EMAIL PROTECTED]> wrote: The default case, the case of the user without the wherewithal to understand the nuances of the distinction between 2.x and 3.x, is a user who should use 2.x

Re: [Python-Dev] RELEASED Python 3.0 final FFT

http://code.activestate.com/recipes/576550/ This recipe shows how to use gsl FFT with python 3. ctypes is really good! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python

[Python-Dev] Fix for frame_setlineno() in frameobject.c function

Hello, This concerns a known bug in the frame_setlineno() function for Python 2.5.x and 2.6.x (maybe in earlier version too). It is not possible to use this function when the address or line offset are greater than 127. The problem comes from the lnotab variable which is typed char*, therefore

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Friday 05 December 2008, Guido van Rossum wrote: > At the risk of bringing up something that was already rejected, let me > propose something that follows the path taken in 3.0 for filenames, > rather than doubling back: > > For os.environ, os.getenv() and os.putenv(), I think a similar > approa

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Hi, Le Thursday 04 December 2008 21:02:19 Toshio Kuratomi, vous avez écrit : > I opened up bug http://bugs.python.org/issue4006 a while ago and it was > suggested in the report that it's not a bug but a feature and so I > should come here to see about getting the feature changed :-) Yeah, I prefe

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Friday 05 December 2008, Adam Olsen wrote: > Many of the windows APIs use UTF-16 without validating it. They'll > pass through invalid strings until they hit something that does > validate, at which point it'll blow up. > > I suspect that it doesn't happen very often in practice, as having > on

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Friday 05 December 2008, [EMAIL PROTECTED] wrote: > Filenames and environment variables would all need to be encoded or > decoded according to this magic encoding. Those, and commandline arguments, too. Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Le Friday 05 December 2008 00:39:24 Martin v. Löwis, vous avez écrit : > 5) represent all environment variables in Unicode strings, >including the ones that currently fail to decode. >(then do the same to file names, then drop the byte-oriented > file operations again) Please, don't do

Re: [Python-Dev] Python-3.0, unicode, and os.environ

[EMAIL PROTECTED] wrote: > At least this time I think I've encapsulated pretty much my entire > argument here, so if you don't buy it, we can probably just agree to > disagree :). Glyph, the only point I would add to your message is this one: Adding a "blessed" way to encode arbitrary binary data

Re: [Python-Dev] Taint Mode in Python 3.0

Maciej Fijalkowski wrote: > Hello, > > The thing is pypy's taint code is broken. Basically you don't only > need to patch all places that return pyobject, but also all places > that might modify anything. (All side effects) For example innocently > looking call to addition might end up calling arb

Re: [Python-Dev] Python-3.0, unicode, and os.environ

On Fri, Dec 5, 2008 at 12:00 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Please, if you have a *new* idea that doesn't have a failure mode, by >> all means post it. But don't resurrect a pointless bikeshed. > > While I completely agree that it is pointless to reiterate the same > arguments

Re: [Python-Dev] RELEASED Python 3.0 final

Barry Warsaw schrieb: > On Dec 4, 2008, at 6:21 PM, Martin v. Löwis wrote: > I can't find any docs built for Python 3.0 (not 3.1a0). >>> >>> The Windows installation has new 3.0 doc dated Dec 3, so it was >>> built, >>> just not posted correctly. > >> That doesn't mean very much. I built i

Re: [Python-Dev] Python-3.0, unicode, and os.environ

Martin v. Löwis wrote: >> Please, if you have a *new* idea that doesn't have a failure mode, by >> all means post it. But don't resurrect a pointless bikeshed. > > While I completely agree that it is pointless to reiterate the same > arguments over and over, I disagree that the bikeshed metapher