Mailman 3 August 2006 - Python-Dev

Re: [Python-Dev] Dicts are broken ...
by Nick Maclaren Aug. 4, 2006

Aug. 4, 2006

Michael Hudson <mwh(a)python.net> wrote: > > I'd say it's more to do with __eq__. It's a strange __eq__ method > that raises an Exception, IMHO. Not entirely. Any type that supports invalid values (e.g. IEEE 754) and is safe against losing the invalid state by accident needs to raise an exception on A == B. IEEE 754 is not safe. > Please do realize that the motivation for this change was hours and > hours of tortous debugging caused by a buggy __eq__ method making … [View More]

1 0

Re: [Python-Dev] Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys
by Michael Chermside Aug. 4, 2006

Aug. 4, 2006

Marc-Andre Lemburg writes: > How about generating a warning instead and then go for the exception > in 2.6 ? Agreed. Michael Hudson's explanation convinced me. -- Michael Chermside

1 0

unicode hell/mixing str and unicode as dictionary keys
by Jim Jewett Aug. 4, 2006

Aug. 4, 2006

http://mail.python.org/pipermail/python-dev/2006-August/067934.html M.-A. Lemburg mal at egenix.com > Ralf Schmitt wrote: >> Still trying to port our software. here's another thing I noticed: >> d = {} >> d[u'm\xe1s'] = 1 >> d['m\xe1s'] = 1 >> print d (a 2-element dictionary, because they are not equal) >> With python 2.5 I get: [ a traceback ending in ] >> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 1: >> ordinal … [View More]

10 15

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionarykeys
by Kristján V. Jónsson Aug. 4, 2006

Aug. 4, 2006

The "string" isn´t necessarily text, so selecting latin-1 doesn´t help (in fact, what happens is that the current default encoding is used, in his case this was ascii). What if it is image data? What if you are using a dict to implement a singleton set for arbitrary objects? The point is that if the comparison operator raises an exception, the two objects are likely to be dissimilar. We could even define that behaviour. Propagating the exception means that you can't have objects as keys … [View More]in a dictionary that raise an exception when compared. This goes over and beyond any unicode vs. string question. If the propagation of the exception was a concious change for debugging purposes, why not make that somehow optional? A flag on the dict object? Or special lookup mehtods for that? Cheers, Kristján > -----Original Message----- > From: python-dev-bounces+kristjan=ccpgames.com(a)python.org > [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] > On Behalf Of Josiah Carlson > Sent: 4. ágúst 2006 04:34 > To: Bob Ippolito; python-dev(a)python.org > Subject: Re: [Python-Dev] unicode hell/mixing str and unicode > as dictionarykeys > > > Bob Ippolito <bob(a)redivi.com> wrote: > > On Aug 3, 2006, at 6:51 PM, Greg Ewing wrote: > > > > > M.-A. Lemburg wrote: > > > > > >> Perhaps we ought to add an exception to the dict lookup > mechanism > > >> and continue to silence UnicodeErrors ?! > > > > > > Seems to be that comparison of unicode and non-unicode > strings for > > > equality shouldn't raise exceptions in the first place. > > > > Seems like a slightly better idea than having dictionaries suppress > > exceptions. Still not ideal though because sticking > non-ASCII strings > > that are supposed to be text and unicode in the same data > structures > > is *probably* still an error. > > If/when 'python -U -c "import test.testall"' runs without > unexpected error (I doubt it will happen prior to the "all > strings are unicode" > conversion), then I think that we can say that there aren't > any use-cases for strings and unicode being in the same dictionary. > > As an alternate idea, rather than attempting to > .decode('ascii') when strings and unicode compare, why not > .decode('latin-1')? We lose the unicode decoding error, but > "the right thing" happens (in my opinion) when u'\xa1' and > '\xa1' compare. > > - Josiah > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kristjan%40c cpgames.com > [View Less]

1 0

struct module and coercing floats to integers
by Bob Ippolito Aug. 4, 2006

Aug. 4, 2006

It seems that the pre-2.5 struct module has some additional undocumented behavior[1] that didn't percolate into the new version: http://python.org/sf/1530559 Python 2.4 and previous will coerce floats to integers when necessary as such without any kind of complaint: $ python2.4 -c "import struct; print repr(struct.pack('>H', 0.9999999999999999))" '\x00\x00' Python 2.5 refuses to coerce float to int: $ python2.5 -c "import struct; print repr(struct.pack('>H', 0.… [View More]

12 25

TRUNK FREEZE 2006-07-03, 00:00 UTC for 2.5b3
by Anthony Baxter Aug. 4, 2006

Aug. 4, 2006

The trunk is FROZEN from 00:00 UTC/GMT on 03 July 2006. That's in about 12 hours from now. This is for the third (and final, hopefully!) beta of 2.5. Please help the release team out by not making checkins on the trunk after that time until I send out an email that the release is done. Thanks, Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

4 4

RELEASED Python 2.5 (beta 3)
by Anthony Baxter Aug. 4, 2006

Aug. 4, 2006

On behalf of the Python development team and the Python community, I'm happy to announce the third BETA release of Python 2.5. This is an *beta* release of Python 2.5. As such, it is not suitable for a production environment. It is being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 2.5 might impact you. If you find things broken or incorrect, please log a bug on Sourceforge. In particular, note that changes to improve Python's … [View More]

1 0

Re: [Python-Dev] Rounding float to int directly ...
by Nick Maclaren Aug. 4, 2006

Aug. 4, 2006

"M.-A. Lemburg" <mal(a)egenix.com> wrote: > > You often have a need for controlled rounding when doing > financial calculations or in situations where you want to > compare two floats with a given accuracy, e.g. to work > around rounding problems ;-) The latter is a crude hack, and was traditionally used to save cycles when floating-point division was very slow. There are better ways, and have been for decades. > Float formatting is an entirely different issue. Not … [View More]

3 2

using globals
by Werkhoven J.P. van (Sjaak) Aug. 4, 2006

Aug. 4, 2006

Hi, I have got a problem with importing global variables. For instance I have got two files: # t1.py #t2.py counter = 1 def counter_adder(filenr): def show_adder(): global counter import t1 counter+= 1 print("adder is %d" % t1.counter) if filenr == 1: show_adder() else: import t2 t2.show_adder() def show_adder(): print("adder is %d" % counter) >>counter_adder(1) adder is 2 >>counter_adder(2) adder is 1 When I … [View More]

2 1

Re: [Python-Dev] Rounding float to int directly ...
by Nick Maclaren Aug. 3, 2006

Aug. 3, 2006

Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > > > There are algorithms where the operation of rounding (or truncation) > > is needed, but where the value may be larger than can be held in an > > integer, and that is not an error. > > Is that really true for python? Python integers are unbounded in > magnitute, they are not the same as int or long in C, therefore any > float except exceptional values like NaN can be converted to an > … [View More]

1 0