Re: [Python-3000] exclusion feature for 2to3?

2007-07-16 Thread Georg Brandl
Guido van Rossum schrieb: > On 7/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote: >> In order to have a codebase run in 2.x and 3.x, via automated translated by >> 2to3, there should be some "exclusion feature" for single lines that tells >> the refactorer not to touch those lines. >> >> For example,

Re: [Python-3000] exclusion feature for 2to3?

2007-07-16 Thread Guido van Rossum
On 7/16/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > > Absolutely. (Were you in the audience of my keynote at EuroPython? I > > believe I briefly mentioned the need for such a feature there. :-) > > No, I ran the new documentation toolset through 2to3; and e.g. docutils > nodes have a has_key() th

Re: [Python-3000] test_mmap.py and OSError

2007-07-16 Thread Guido van Rossum
So, after seeing the patch and thinking this over some more, I have changed my mind (again). Attempting to flush a closed file seems to indicate that you're confused about whether a file is closed or not, and that seems indicative of unclear thinking, i.e. it's likely a bug that ought to be caught.

Re: [Python-3000] test_mmap.py and OSError

2007-07-16 Thread Joe Gregorio
On 7/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > So, after seeing the patch and thinking this over some more, I have > changed my mind (again). Attempting to flush a closed file seems to > indicate that you're confused about whether a file is closed or not, > and that seems indicative of u

Re: [Python-3000] test_mmap.py and OSError

2007-07-16 Thread Guido van Rossum
On 7/16/07, Joe Gregorio <[EMAIL PROTECTED]> wrote: > On 7/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > So, after seeing the patch and thinking this over some more, I have > > changed my mind (again). Attempting to flush a closed file seems to > > indicate that you're confused about wheth

Re: [Python-3000] Invalid \U escape in source code give hard-to-trace error

2007-07-16 Thread Guido van Rossum
Doesn't look like it's the same problem. I've assigned that one to Martin who knows that area best of all. On 7/15/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 7/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > When a source file contains a string literal with an out-of-range \U > > esca

Re: [Python-3000] TextIOWrapper.write(s:str) and bytes in py3k-struni

2007-07-16 Thread Guido van Rossum
On 7/14/07, Christian Heimes <[EMAIL PROTECTED]> wrote: > I'm having some troubles with unit tests in the py3k-struni branch. Some > test like test_uu are failing because an io.TextIOWrapper instance's > write() method doesn't handle bytes. The method is defined as: > > def write(self, s: str):

Re: [Python-3000] pep3115 - metaclasses in python 3000

2007-07-16 Thread Guido van Rossum
On 7/13/07, Talin <[EMAIL PROTECTED]> wrote: > Thomas Heller wrote: > > playing a little with py3k... > > > > pep3115 mentions that "__prepare__ returns a dictionary-like object > > which is used to store the class member definitions during evaluation > > of the class body." > > > > It does not men

Re: [Python-3000] pep3115 - metaclasses in python 3000

2007-07-16 Thread Guido van Rossum
On 7/16/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > The object returned by __prepare__() actually *is* incorporated into > the class object, unless the metaclass' __new__() passes something > else to type.__new__(). However this isn't obvious when you ask for > the class' __dict__ attribute:

Re: [Python-3000] TextIOWrapper.write(s:str) and bytes in py3k-struni

2007-07-16 Thread Christian Heimes
Guido van Rossum wrote: > I came across this in your SF patch. I disagree with your desire to > let TextIOWrapper.write() handle bytes: it should *only* be passed str > objects. The uu test was failing because it was writing bytes to a > text stream. > > Perhaps the error should be better; though

Re: [Python-3000] Heaptypes

2007-07-16 Thread Martin v. Löwis
Guido van Rossum schrieb: > That sounds like a good idea to try. It may break some more tests but > those are all indications of places that incorrectly still require > str8. > >> I wonder whether the "s" specifier in CallFunction, BuildValue etc >> should create Unicode objects, rather than str8