Re: [Python-Dev] Proposed resolutions for open PEP 343 issues
Guido van Rossum wrote: > Here's another argument against automatically decorating __context__. > > What if I want to have a class with a __context__ method that returns > a custom context manager that *doesn't* involve applying > @contextmanager to a generator? > > While technically this is possible with your proposal (since such a > method wouldn't be a generator), it's exceedingly subtle for the human > reader. I'd much rather see the @contextmanager decorator to emphasize > the difference. Being able to easily pull a native context manager out and turn it into an independent context manager just by changing its name is also a big plus. For that matter, consider a class that had a "normal" context manager (its context slot), and an alternative context manager (defined as a separate method). The fact that one had the contextmanager decorator and the other one didn't would be rather confusing. So you've convinced me that auto-decoration is not the right thing to do. Those that really don't like decorating a slot can always write it as: def UndecoratedSlot(object): @contextmanager def native_context(self): print "Entering native context" yield print "Exiting native context cleanly" __context__ = native_context Or: def UndecoratedSlot(object): def __context__(self): return self.native_context() @contextmanager def native_context(self): print "Entering native context" yield print "Exiting native context cleanly" However, I'm still concerned about the fact that the following class has a context manager that doesn't actually work: class Broken(object): def __context__(self): print "This never gets executed" yield print "Neither does this" So how about if type_new simply raises a TypeError if it finds a generator-iterator function in the __context__ slot? Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
Reinhold Birkenfeld wrote:
> Michele Simionato wrote:
>> As other explained, the syntax would not work for functions (and it is
>> not intended to).
>> A possible use case I had in mind is to define inlined modules to be
>> used as bunches
>> of attributes. For instance, I could define a module as
>>
>> module m():
>> a = 1
>> b = 2
>>
>> where 'module' would be the following function:
>>
>> def module(name, args, dic):
>> mod = types.ModuleType(name, dic.get('__doc__'))
>> for k in dic: setattr(mod, k, dic[k])
>> return mod
>
> Wow. This looks like an almighty tool. We can have modules, interfaces,
> classes and properties all the like with this.
>
> Guess a PEP would be nice.
Very nice indeed. I'd be more supportive if it was defined as a new statement
such as "create" with the syntax:
create TYPE NAME(ARGS):
BLOCK
The result would be roughly equivalent to:
kwds = {}
exec BLOCK in kwds
NAME = TYPE(NAME, ARGS, kwds)
Such that the existing 'class' statement is equivalent to:
create __metaclass__ NAME(ARGS):
BLOCK
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST reverts PEP 342 implementation and IDLE starts working again
[Phillip J. Eby] > your observation actually means that the bug, if any, was somewhere > else, or was inadvertently fixed or hidden by the AST branch merge. What a nice side benefit :-) Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New codecs checked in
M.-A. Lemburg wrote:
> I've checked in a whole bunch of newly generated codecs
> which now make use of the faster charmap decoding variant added
> by Walter a short while ago.
>
> Please let me know if you find any problems.
I think we should work on eliminating the decoding_map variables.
There are some codecs which rely on them being present in other codecs
(e.g. koi8_u.py is based on koi8_r.py); however, this could be updated
to use, say
decoding_table = codecs.update_decoding_map(koi8_r.decoding_table, {
0x00a4: 0x0454, # CYRILLIC SMALL LETTER UKRAINIAN IE
0x00a6: 0x0456, # CYRILLIC SMALL LETTER
BYELORUSSIAN-UKRAINIAN I
0x00a7: 0x0457, # CYRILLIC SMALL LETTER YI (UKRAINIAN)
0x00ad: 0x0491, # CYRILLIC SMALL LETTER UKRAINIAN GHE
WITH UPTURN
0x00b4: 0x0404, # CYRILLIC CAPITAL LETTER UKRAINIAN IE
0x00b6: 0x0406, # CYRILLIC CAPITAL LETTER
BYELORUSSIAN-UKRAINIAN I
0x00b7: 0x0407, # CYRILLIC CAPITAL LETTER YI (UKRAINIAN)
0x00bd: 0x0490, # CYRILLIC CAPITAL LETTER UKRAINIAN GHE
WITH UPTURN
})
With all these cross-references gone, the decoding_maps could also go.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] cross compiling python for embedded systems
is this the right place to ask: How could I build the python interpreter for an embedded linux target system (arm9 based), cross-compiling on a linux PC host? thanks, Giovanni Angeli. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed resolutions for open PEP 343 issues
On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > However, I'm still concerned about the fact that the following class has a > context manager that doesn't actually work: > >class Broken(object): > def __context__(self): > print "This never gets executed" > yield > print "Neither does this" That's only because of your proposal to endow generators with a default __context__ manager. Drop that idea and you're golden. (As long as nobody snuck the proposal back in to let the with-statement silently ignore objects that don't have a __context__ method -- that was rejected long ago on.) In my previous mail I said I had to think about that one more -- well, I have, and I'm now -1 on it. Very few generators (that aren't used a context manangers) will need the immediate explicit close() call, and it will happen eventually when they are GC'ed anyway. Too much magic is bad for your health. > So how about if type_new simply raises a TypeError if it finds a > generator-iterator function in the __context__ slot? No. type should not bother with understanding what the class is trying to do. __new__ is only special because it is part of the machinery that type itself invokes in order to create a new class. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed resolutions for open PEP 343 issues
At 09:19 AM 10/23/2005 -0700, Guido van Rossum wrote: >On 10/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > However, I'm still concerned about the fact that the following class has a > > context manager that doesn't actually work: > > > >class Broken(object): > > def __context__(self): > > print "This never gets executed" > > yield > > print "Neither does this" > >That's only because of your proposal to endow generators with a >default __context__ manager. Drop that idea and you're golden. > >(As long as nobody snuck the proposal back in to let the >with-statement silently ignore objects that don't have a __context__ >method -- that was rejected long ago on.) Actually, you've just pointed out a new complication introduced by having __context__. The return value of __context__ is supposed to have an __enter__ and an __exit__. Is it a type error if it doesn't? How do we handle that, exactly? That is, assuming generators don't have enter/exit/context methods, then the above code is broken because its __context__ returns an object without enter/exit, sort of like an __iter__ that returns something without a 'next()'. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
I'd like to start the subversion switchover this coming Wednesday, with a total commit freeze at 16:00 GMT. If you have larger changes to commit that you would like to commit before the switchover, but after that date, please let me know. At that point, I will set the repository to read-only (through a commitinfo hook), and request that SF rolls a tarfile. I will then notify you when the Subversion repository is online. If you have sandboxes with modifications, it might be good to cvs diff -u them now. I plan to keep the CVS up for a short while after the switchover (about a month); after that point, you will need to get the CVS tarball and retarget your sandbox to perform diffs. I'm not aware of a procedure to convert a CVS sandbox into an SVN one, so you will have to recheckout all your sandboxes after the switch. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cross compiling python for embedded systems
There's a patch on sourceforge for cross compiling. I haven't used it personally. http://sourceforge.net/tracker/index.php?func=detail&aid=1006238&group_id=5470&atid=305470 Jeff pgpzVmD49shTu.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cross compiling python for embedded systems
[EMAIL PROTECTED] wrote: > How could I build the python interpreter for an embedded linux target system > (arm9 based), cross-compiling on a linux PC host? No. news:comp.lang.python (aka: mailto:[email protected]) would be the right list. This would be the right list for the question "I made this and that modification to get it cross-compile, can somebody please review them?" Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed resolutions for open PEP 343 issues
On 10/23/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Actually, you've just pointed out a new complication introduced by having > __context__. The return value of __context__ is supposed to have an > __enter__ and an __exit__. Is it a type error if it doesn't? How do we > handle that, exactly? > > That is, assuming generators don't have enter/exit/context methods, then > the above code is broken because its __context__ returns an object without > enter/exit, sort of like an __iter__ that returns something without a > 'next()'. I would have thought that the parallel with __iter__ would be the right way to go: >>> class C: ... def __iter__(self): ... return 12 ... >>> c = C() >>> iter(c) Traceback (most recent call last): File "", line 1, in ? TypeError: __iter__ returned non-iterator of type 'int' >>> So, when you try calling __context__ in a with statement (or I guess in a context() builtin if one were to be added), raise a TypeError if the resulting object doesn't have __enter__ and __exit__ methods. (Or maybe just if it has neither - I can't recall if the methods are optional, but certainly having neither is wrong). Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > I'd like to start the subversion switchover this coming Wednesday, > with a total commit freeze at 16:00 GMT. Yay! Thanks again for doing this. Cheers, mwh -- [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
-1 on keeping the source encoding of string literals. Python should definitely decode them at compile time. -1 on decoding implicitly "as needed". This causes decoding to happen late, in unpredictable places. Decodes can fail; they should happen as early and as close to the data source as possible. -j ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 351, the freeze protocol
I've had this PEP laying around for quite a few months. It was inspired by some code we'd written which wanted to be able to get immutable versions of arbitrary objects. I've finally finished the PEP, uploaded a sample patch (albeit a bit incomplete), and I'm posting it here to see if there is any interest. http://www.python.org/peps/pep-0351.html Cheers, -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed resolutions for open PEP 343 issues
On 10/23/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Actually, you've just pointed out a new complication introduced by having > __context__. The return value of __context__ is supposed to have an > __enter__ and an __exit__. Is it a type error if it doesn't? How do we > handle that, exactly? Of course it's an error! The translation in the PEP should make that quite clear (there's no testing for whether __context__, __enter__ and/or __exit__ exist before they are called). It would be an AttributeError. > That is, assuming generators don't have enter/exit/context methods, then > the above code is broken because its __context__ returns an object without > enter/exit, sort of like an __iter__ that returns something without a > 'next()'. Right. That was my point. Nick's worried about undecorated __context__ because he wants to endow generators with a different default __context__. I say no to both proposals and the worries cancel each other out. EIBTI. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
On 10/23/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > I've had this PEP laying around for quite a few months. It was inspired > by some code we'd written which wanted to be able to get immutable > versions of arbitrary objects. I've finally finished the PEP, uploaded > a sample patch (albeit a bit incomplete), and I'm posting it here to see > if there is any interest. > > http://www.python.org/peps/pep-0351.html My sandboxes need freezing for some stuff and ultimately freezable user classes will be desirable, but for performance reasons I prefer freezing inplace. Not much overlap with PEP 351 really. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
On Oct 23, 2005, at 3:10 PM, Jason Orendorff wrote: > -1 on decoding implicitly "as needed". This causes decoding to happen > late, in unpredictable places. Decodes can fail; they should happen > as early and as close to the data source as possible. That's not necessarily true... Some codecs can't fail, like latin1. I think the main use case for this is to speed up usage of text in these sorts of formats anyway. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
On Sunday 23 October 2005 18:10, Jason Orendorff wrote: > -1 on keeping the source encoding of string literals. Python should > definitely decode them at compile time. > > -1 on decoding implicitly "as needed". This causes decoding to happen > late, in unpredictable places. Decodes can fail; they should happen > as early and as close to the data source as possible. +1. We have followed this last practice throughout Zope 3 successfully. In our case, the publisher framework (in other words the output-protocol-specific layer) is responsible for the decoding and encoding of input and output streams, respectively. We have been pretty much free of any encoding/decoding troubles since. Having our application only use unicode internally was one of the best decisions we have made. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
Folks, please focus on what Python 3000 should do. I'm thinking about making all character strings Unicode (possibly with different internal representations a la NSString in Apple's Objective C) and introduce a separate mutable bytes array data type. But I could use some validation or feedback on this idea from actual practitioners. I don't want to see proposals to mess with the str/unicode semantics in Python 2.x. Let' leave the Python 2.x str/unicode semantics alone until Python 3000 -- we don't need mutliple transitions. (Although we could add the mutable bytes array type sooner.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
On Oct 23, 2005, at 6:06 PM, Guido van Rossum wrote: > Folks, please focus on what Python 3000 should do. > > I'm thinking about making all character strings Unicode (possibly with > different internal representations a la NSString in Apple's Objective > C) and introduce a separate mutable bytes array data type. But I could > use some validation or feedback on this idea from actual > practitioners. > > I don't want to see proposals to mess with the str/unicode semantics > in Python 2.x. Let' leave the Python 2.x str/unicode semantics alone > until Python 3000 -- we don't need mutliple transitions. (Although we > could add the mutable bytes array type sooner.) +1, this is precisely what I'd like to see. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
At 06:06 PM 10/23/2005 -0700, Guido van Rossum wrote: >Folks, please focus on what Python 3000 should do. > >I'm thinking about making all character strings Unicode (possibly with >different internal representations a la NSString in Apple's Objective >C) and introduce a separate mutable bytes array data type. But I could >use some validation or feedback on this idea from actual >practitioners. +1. Chandler has been going through quite an upheaval to get its unicode handling together. Having a bytes type would be great, as long as there was support for files and sockets to produce bytes instead of strings (unless an encoding was specified). I'm tempted to say it would be even better if there was a command line option that could be used to force all binary opens to result in bytes, and require all text opens to specify an encoding. The Chandler i18n project lead would jump for joy if we had a way to keep "legacy" strings out of the system, apart from ASCII string constants found in code. It would then be okay not to drop support for the implicit conversions; if you can't get strings on input, then conversion's not really an issue. Anyway, I think all of the things I'd like to see can be done without breakage in 2.5. For Chandler at least, we'd be willing to go with a command-line option that's more strict, in order to be able to ensure that plugin developers can't accidentally put 8-bit strings in somewhere, just by opening a file. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Reinhold Birkenfeld wrote:
> > Michele Simionato wrote:
> >> As other explained, the syntax would not work for functions (and it is
> >> not intended to).
> >> A possible use case I had in mind is to define inlined modules to be
> >> used as bunches
> >> of attributes. For instance, I could define a module as
> >>
> >> module m():
> >> a = 1
> >> b = 2
> >>
> >> where 'module' would be the following function:
> >>
> >> def module(name, args, dic):
> >> mod = types.ModuleType(name, dic.get('__doc__'))
> >> for k in dic: setattr(mod, k, dic[k])
> >> return mod
> >
> > Wow. This looks like an almighty tool. We can have modules, interfaces,
> > classes and properties all the like with this.
> >
> > Guess a PEP would be nice.
>
> Very nice indeed. I'd be more supportive if it was defined as a new statement
> such as "create" with the syntax:
>
>create TYPE NAME(ARGS):
> BLOCK
>
> The result would be roughly equivalent to:
>
>kwds = {}
>exec BLOCK in kwds
>NAME = TYPE(NAME, ARGS, kwds)
And is equivalent to the class/metaclass abuse...
#suport code
def BlockMetaclassFactory(constructor):
class BlockMetaclass(type):
def __new__(cls, name, bases, dct):
return constructor(name, bases, dct)
return BlockMetaClass
#non-syntax syntax
class NAME(ARGS):
__metaclass__ = BlockMetaclassFactory(TYPE)
BLOCK
Or even...
def BlockClassFactory(constructor):
class BlockClass:
__metaclass__ = BlockMetaclassFactory(constructor)
return BlockClass
class NAME(BlockClassFactory(TYPE), ARGS):
BLOCK
To be used with properties, one could use a wrapper and class definition...
def _Property(names, bases, dct):
return property(**dct)
Property = BlockClassFactory(_Property)
class foo(object):
class x(Property):
...
With minor work, it would be easy to define a subclassable Property
which could handle some basic styles: write once, default value, etc.
I am unconvinced that a block syntax is necessary or desireable for this
case. With the proper support classes, you can get modules, classes,
metaclasses, properties, the previous 'given:' syntax, etc.
- Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
Barry Warsaw <[EMAIL PROTECTED]> wrote: > I've had this PEP laying around for quite a few months. It was inspired > by some code we'd written which wanted to be able to get immutable > versions of arbitrary objects. I've finally finished the PEP, uploaded > a sample patch (albeit a bit incomplete), and I'm posting it here to see > if there is any interest. > > http://www.python.org/peps/pep-0351.html class xlist(list): def __freeze__(self): return tuple(self) Shouldn't that be: class xlist(list): def __freeze__(self): return tuple(map(freeze, self)) "Should dicts and sets automatically freeze their mutable keys?" Dictionaries don't have mutable keys, but it is of my opinion that a container which is frozen should have its contents frozen as well. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
Guido van Rossum: > Folks, please focus on what Python 3000 should do. > > I'm thinking about making all character strings Unicode (possibly with > different internal representations a la NSString in Apple's Objective > C) and introduce a separate mutable bytes array data type. But I could > use some validation or feedback on this idea from actual > practitioners. I'd like to more tightly define Unicode strings for Python 3000. Currently, Unicode strings may be implemented with either 2 byte (UCS-2) or 4 byte (UTF-32) elements. Python should allow strings to contain any Unicode character and should be indexable yielding characters rather than half characters. Therefore Python strings should appear to be UTF-32. There could still be multiple implementations (using UTF-16 or UTF-8) to preserve space but all implementations should appear to be the same apart from speed and memory use. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int(string)
Tim Peters wrote:
>[Adam Olsen]
>
>>https://sourceforge.net/tracker/index.php?func=detail&aid=1334979&group_id=5470&atid=305470>
>>
>>That patch removes the division from the loop (and fixes the bugs),
>>but gives only a small increase in speed.
>>
>In any case, I agree it _should_ fix the bugs (although it also needs
>new tests to verify that).
>
I started with Adam's patch and did some additional work on
PyOS_strtoul. I ended up with a patch that seems to correctly evaluate
the tests that Tim listed in bug #1334662, includes new tests (in
test_builtin), passes (almost) all of "make test," and it seems to be
somewhat faster (~20%) for a "spoj.sphere.pl"-like test on a ~8MB input
file. All the ugly details are here (along with my ugly code):
http://sourceforge.net/tracker/index.php?func=detail&aid=1335972&group_id=5470&atid=305470
When running "make test" I get some errors in test_array and
test_compile that did not occur in the build from CVS. Given the inputs
to long() have '.' characters in them, I assume that these tests really
should be failing as implemented, but I haven't dug into them to see
what's going on:
==
ERROR: test_repr (__main__.FloatTest)
--
Traceback (most recent call last):
File "Lib/test/test_array.py", line 187, in test_repr
self.assertEqual(a, eval(repr(a), {"array": array.array}))
ValueError: invalid literal for long(): 100.0
==
ERROR: test_repr (__main__.DoubleTest)
--
Traceback (most recent call last):
File "Lib/test/test_array.py", line 187, in test_repr
self.assertEqual(a, eval(repr(a), {"array": array.array}))
ValueError: invalid literal for long(): 100.0
--
test test_compile crashed -- exceptions.ValueError: invalid literal for
long():
90.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
Neil Hodgson wrote: >I'd like to more tightly define Unicode strings for Python 3000. > Currently, Unicode strings may be implemented with either 2 byte > (UCS-2) or 4 byte (UTF-32) elements. Python should allow strings to > contain any Unicode character and should be indexable yielding > characters rather than half characters. Therefore Python strings > should appear to be UTF-32. There could still be multiple > implementations (using UTF-16 or UTF-8) to preserve space but all > implementations should appear to be the same apart from speed and > memory use. That's very tricky. If you have multiple implementations, you make usage at the C API difficult. If you make it either UTF-8 or UTF-32, you make PythonWin difficult. If you make it UTF-16, you make indexing difficult. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
Phillip J. Eby wrote: > I'm tempted to say it would be even better if there was a command line > option that could be used to force all binary opens to result in bytes, and > require all text opens to specify an encoding. For Python 3000? -1. There shouldn't be command line switches that have that much importance. For Python 2.x? Well, we are not supposed to discuss this. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
