Mailman 3 August 2006 - Python-Dev

Re: [Python-Dev] Dicts are broken ...
by Nick Maclaren 04 Aug '06

04 Aug '06

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 keys > "impossibly" seem to not be in dictionaries. Quite. Been there - been caught by that. It is a catastrophic (but very common) misdesign to conflate failure and the answer "no". There is a fundamental flaw of that nature in card-based banking, that I pointed out was insoluble to the Grid people, and then got caught by just a month later! Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Re: [Python-Dev] Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys
by Michael Chermside 04 Aug '06

04 Aug '06

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 04 Aug '06

04 Aug '06

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 not in range(128) > Let's put it this way: Python 2.5 uncovered a bug in your > application that has always been there. No; he application would only have a bug if he expected those two objects to compare equal. Trying to stick something hashable into a dictionary should not raise an Exception just because there is already a similar key, (regardless of whether or not the other key is equal or identical). The only way this error could be the right thing is if you were trying to suggest that he shouldn't mix unicode and bytestrings at all. There is a command line switch for that, but it doesn't get much use. -jJ

10 15

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

04 Aug '06

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 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 >

1 0

struct module and coercing floats to integers
by Bob Ippolito 04 Aug '06

04 Aug '06

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.9999999999999999))" Traceback (most recent call last): File "<string>", line 1, in <module> File "/Users/bob/src/python/Lib/struct.py", line 63, in pack return o.pack(*args) TypeError: unsupported operand type(s) for &: 'float' and 'long' The available options are to: 1. Reinstate the pre-2.5 weirdness 2. Reinstate the pre-2.5 weirdness with a DeprecationWarning 3. Break existing code that relies on undocumented behavior (seems more like a bug than lack of specification) Either 2 or 3 seems reasonable to me, with a preference for 3 because none of my code depends on old bugs in the struct module :) As far as precedent goes, the array module *used* to coerce floats silently, but it's had a DeprecationWarning since at least Python 2.3 (but perhaps even earlier). Maybe it's time to promote that warning to an exception for Python 2.5? [1] The pre-2.5 behavior should really be considered a bug, the documentation says "Return a string containing the values v1, v2, ... packed according to the given format. The arguments must match the values required by the format exactly." I wouldn't consider arbitrary floating point numbers to match the value required by an integer format exactly. Floats are not in general interchangeable with integers in Python anyway (e.g. list indexes, etc.). -bob

12 25

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

03 Aug '06

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 03 Aug '06

03 Aug '06

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 support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ There's been over 50 fixes since the second beta. This large number of changes meant we felt more comfortable cutting a third beta release, rather than charging ahead to the release candidate. As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The plan is that this will be the final beta release (no, really, this time for sure (probably)). We should now move to one or more release candidates, leading to a 2.5 final release early August. PEP 356 includes the schedule and will be updated as the schedule evolves. At this point, any testing you can do would be greatly, greatly appreciated. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref and ctypes. In addition, a new profiling module "cProfile" was added. Enjoy this new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

1 0

Re: [Python-Dev] Rounding float to int directly ...
by Nick Maclaren 03 Aug '06

03 Aug '06

"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 really. You need controlled rounding to a fixed precision in the other base. But I agree that controlled rounding in binary does not help with controlled rounding in decimal. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

3 2

using globals
by Werkhoven J.P. van (Sjaak) 03 Aug '06

03 Aug '06

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 look at the outcome of two function calls I expected no differences but much to my surprise it goes wrong when the global variable is imported. It doesn't give the updated value but the value it get when instantiated. Who come? What should I do to get the updated value greetings, Sjaak van Werkhoven ****************************DISCLAIMER*********************************** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. Fortis sluit iedere aansprakelijkheid uit die voortvloeit uit electronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Fortis rules out any and every liability resulting from any electronic transmission. ******************************************************************************

2 1

Re: [Python-Dev] Rounding float to int directly ...
by Nick Maclaren 03 Aug '06

03 Aug '06

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 > integer value. The converse is not true, python integers can contain > values that are larger than any float (aka C's double). It depends a great deal on what you mean by a Python integer! Yes, I was assuming the (old) Python model, where it is a C long, but so were many (most?) of the other postings. If you are assuming the (future?) model, where there is a single integer type of unlimited size, then that is true. There is still an efficiency point, in that such algorithms positively don't want a float value like 1.0e300 (or, worse, 1.0e4000) expanded to its full decimal representation as an intermediate step. Whatever. There should still be at least one operation that rounds or truncates a float value, returning a float of the same type, on either functionality or efficiency grounds. I and most programmers of such algorithms don't give a damn which it does, provided that it is clearly documented, at least half-sane and doesn't change with versions of Python. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0