Mailman 3 April 2000 - Python-Dev

Re: [Python-checkins] CVS: distutils/distutils sysconfig.py
by Greg Stein April 10, 2000

April 10, 2000

Why aren't we getting diffs on these things? Is it because of the "distutils" root instead of the Python root? Just curious... thx, -g On Sun, 9 Apr 2000, Greg Ward wrote: > Update of /projects/cvsroot/distutils/distutils > In directory kaluha:/tmp/cvs-serv16499 > > Modified Files: > sysconfig.py > Log Message: > Added optional 'prefix' arguments to 'get_python_inc()' and > 'get_python_lib()'. > > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://www.python.org/mailman/listinfo/python-checkins > -- Greg Stein, http://www.lyra.org/

1 0

SRE: regex.set_syntax
by Fredrik Lundh April 9, 2000

April 9, 2000

one of my side projects for SRE is to create a regex-compatible frontend. since both engines have NFA semantics, this mostly involves writing an alternate parser. however, when I started playing with that, I completely forgot about the regex.set_syntax() function. supporting one extra syntax isn't that much work, but a whole bunch of them? so what should we do? 1. completely get rid of regex (bjorn would love that, don't you think?) 2. remove regex.set_syntax(), and tell people who've used it that they're SOL. 3. add all the necessary flags to the new parser... 4. keep regex around as before, and live with the extra code bloat. comments? </F>

7 10

str() for interpreter output
by Ka-Ping Yee April 9, 2000

April 9, 2000

Guido van Rossum wrote: > However, it may be time to switch so that "immediate expression" > values are printed as str() instead of as repr()... You do NOT want this. I'm against this change -- quite strongly, in fact. Greg Ward wrote: > Oh, joy! oh happiness! someday soon, I may be able to type > "blah.__doc__" at the interactive prompt and get a readable result! Have repr() use triple-quotes when strings contain newlines if you like, but do *not* hide the fact that the thing being displayed is a string. Imagine the confusion this would cause! (in a hypothetical Python-with-str()...) >>> a = 1 + 1 >>> b = '2' >>> c = [1, 2, 3] >>> d = '[1, 2, 3]' ...much later... >>> a 2 >>> b 2 >>> a + 5 7 >>> b + 5 Traceback (innermost last): File "<stdin>", line 1, in ? TypeError: illegal argument type for built-in operation Huh?!? >>> c [1, 2, 3] >>> d [1, 2, 3] >>> c.append(4) >>> c [1, 2, 3, 4] >>> d.append(4) Traceback (innermost last): File "<stdin>", line 1, in ? AttributeError: attribute-less object Huh?!?! >>> c[1] 2 >>> d[1] 1 What?! This is guaranteed to confuse! Things that look the same should be the same. Things that are different should look different. Getting the representation of objects from the interpreter provides a very important visual cue: you can usually tell just by looking at the first character what kind of animal you've got. A digit means it's a number; a quote means a string; "[" means a list; "(" means a tuple; "{" means a dictionary; "<" means an instance or a special kind of object. Switching to str() instead of repr() completely breaks this property so you have no idea what you are getting. Intuitions go out the window. Granted, repr() cannot always produce an exact reconstruction of an object. repr() is not a serialization mechanism! We have 'pickle' for that. But the nice thing about repr() is that, in general, you can *tell* whether the representation is accurate enough to re-type: once you see a "<...>" sort of thing, you know that there is extra magic that you can't type in. "<...>" was an excellent choice because it is very clearly syntactically illegal. As a corollary, here is an important property of repr() that i think ought to be documented and preserved: eval(repr(x)) should produce an object with the same value and state as x, or it should cause a SyntaxError. We should avoid ever having it *succeed* and produce the *wrong* x. * * * As Tim suggested, i did go back and read the comp.lang.python thread on "__str__ vs. __repr__". Honestly i'm really surprised that such a convoluted hack as the suggestion to "special-case the snot out of strings" would come from Tim, and more surprised that it actually got so much airtime. Doing this special-case mumbo-jumbo would be even worse! Look: (in a hypothetical Python-with-snotless-str()...) >>> a = '\\' >>> b = '\'' ...much later... >>> a '\' >>> '\' File "<stdin>", line 1 '\' ^ SyntaxError: invalid token (at this point i am envisioning the user screaming, "But that's what YOU said!") >>> b ''' >>> ''' ... Wha...?!! Or, alternatively, if even more effort had been expended removing snot: >>> b "'" >>> "'" "'" >>> print b ' Okay... then: >>> c = '"\'" >>> c '"'' >>> '"'' File "<stdin>", line 1 '"'' ^ SyntaxError: invalid token Oh, it should print as '"\'', you say? Well then what of: >>> c '"\'' >>> d = '"\\\'' '"\\'' >>> '"\\'' File "<stdin>", line 1 '"\\'' ^ SyntaxError: invalid token Damned if you do, damned if you don't. Tim's snot-removal algorithm forces the user to *infer* the rules of snot removal, remember them, and tentatively apply them to everything they see (since they still can't be sure whether snot has been removed from what they are seeing). How are the user and the interpreter ever to get along if they can't talk to each other in the same language? * * * As for the suggestion to add an interpreter hook to __builtins__ such that you can supply your own display routine, i'm all for it. Great idea there. * * * I think Donn Cave put it best: there are THREE different kinds of convert-to-string, and we'll only confuse the issue if we try to ignore the distinctions. (a) accurate serialization (b) coerce to string (c) friendly display (a) is taken care of by 'pickle'. (b) is str(). Clearly, coercing a string to a string should not change anything -- thus str(x) is just x if x is already a string. (c) is repr(). repr() is for the human, not for the machine. (a) is for the machine. repr() is: "Please show me as much information as you reasonably can about this object in an accurate and unambiguous way, but if you can't readably show me everything, make it obvious that you're not." repr() must be unambiguous, because the interpreter must help people learn by example. -- ?!ng

4 7

PYTHON_API_VERSION and threading
by Jack Jansen April 9, 2000

April 9, 2000

Something that just struck me: couldn't we use a couple of bits in the PYTHON_API_VERSION to check various other things that make dynamic modules break? WITH_THREAD is the one I just ran in to, but there's a few others such as the object refcounting statistics and platform-dependent things like the debug/nodebug compilation on Windows. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

python -O weirdness
by Vladimir.Marangozov＠inrialpes.fr April 8, 2000

April 8, 2000

Strange. Can somebody confirm/refute, explain this behavior? -------------[ bug.py ]------------ def f(): pass def g(): a = 1 b = 2 def h(): pass def show(func): c = func.func_code print "(%d) %s: %d -> %s" % \ (c.co_firstlineno, c.co_name, len(c.co_lnotab), repr(c.co_lnotab)) show(f) show(g) show(h) ----------------------------------- ~> python bug.py (1) f: 2 -> '\003\001' (4) g: 4 -> '\003\001\011\001' (8) h: 2 -> '\003\000' ~> python -O bug.py (1) f: 2 -> '\000\001' (4) g: 4 -> '\000\001\006\001' (1) f: 2 -> '\000\001' <=== ??? -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

3 5

re: Unicode as argument for 8-bit strings
by Bill Tutt April 8, 2000

April 8, 2000

> There has been a bug report about the treatment of Unicode > objects together with 8-bit format strings. The current > implementation converts the Unicode object to UTF-8 and then > inserts this value in place of the %s.... > > I'm inclined to change this to have '...%s...' % u'abc' > return u'...abc...' since this is just another case of > coercing data to the "bigger" type to avoid information loss. > > Thoughts ? Suddenly returning a Unicode string from an operation that was an 8-bit string is likely to give some code exterme fits of despondency. Converting to UTF-8 didn't give you any data loss, however it certainly might be unexpected to now find UTF-8 characters in what the user originally thought was a binary string containing whatever they had wanted it to contain. Throwing an exception would at the very least force the user to make a decision one way or the other about what they want to do with the data. They might want to do a codepage translation, or something else. (aka Hey, here's a bug I just found for you!) In what other cases are you suddenly returning a Unicode string object from which previouslly returned a string object? Bill

3 2

RE: [Python-Dev] re: Unicode as argument for 8-bit strings
by Bill Tutt April 8, 2000

April 8, 2000

> From: Fredrik Lundh [mailto:fredrik@pythonware.com] > > Bill Tutt wrote: > > > There has been a bug report about the treatment of Unicode > > > objects together with 8-bit format strings. The current > > > implementation converts the Unicode object to UTF-8 and then > > > inserts this value in place of the %s.... > > > > > > I'm inclined to change this to have '...%s...' % u'abc' > > > return u'...abc...' since this is just another case of > > > coercing data to the "bigger" type to avoid information loss. > > > > > > Thoughts ? > > > > Suddenly returning a Unicode string from an operation that > was an 8-bit > > string is likely to give some code exterme fits of despondency. > > why is this different from returning floating point values from > operations involving integers and floats? > > > Converting to UTF-8 didn't give you any data loss, however > it certainly > > might be unexpected to now find UTF-8 characters in what > the user originally > > thought was a binary string containing whatever they had > wanted it to contain. > > the more I've played with this, the stronger my opinion that > the "now it's an ordinary string, now it's a UTF-8 string, now > it's an ordinary string again" approach doesn't work. more on > this in a later post. > Well, unicode string/UTF-8 string, but I definately agree with you. Pick one or the other and make the user convert betwixt the two. > (am I the only one here that has actually tried to write code > that handles both unicode strings and ordinary strings? if not, > can anyone tell me what I'm doing wrong?) > In C++, yes. :) Autoconverting into or out of unicode is bound to lead to trouble for someone. Look at the various messes that misused C++ operator overloading can get you into. Whether its the code that wasn't expecting UTF-8 in a normal string type, or a formatting operation that used to return a normal string type now returning a Unicode string. > > Throwing an exception would at the very least force the > user to make a > > decision one way or the other about what they want to do > with the data. > > They might want to do a codepage translation, or something > else. (aka Hey, > > here's a bug I just found for you!) > > > In what other cases are you suddenly returning a Unicode > string object from > > which previouslly returned a string object? > > if unicode is ever to be a real string type in python, and not just a > nifty extension type, it must be okay to return a unicode string from > any operation that involves a unicode argument... Err. I'm not sure what you're getting at here. If your saying that it'd be nice if we could ditch the current string type and just use the Unicode string type, then I agree with you. However, that doesn't mean you should change the semantics of an operation that existed before unicode came into the picture, since it would break backward compatability. +1 for '%s' % u'\u1234' throwing a TypeError exception. Bill

1 0

Unicode as argument for 8-bit format strings
by M.-A. Lemburg April 7, 2000

April 7, 2000

There has been a bug report about the treatment of Unicode objects together with 8-bit format strings. The current implementation converts the Unicode object to UTF-8 and then inserts this value in place of the %s.... I'm inclined to change this to have '...%s...' % u'abc' return u'...abc...' since this is just another case of coercing data to the "bigger" type to avoid information loss. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 6

the regression test suite
by Vladimir.Marangozov＠inrialpes.fr April 7, 2000

April 7, 2000

My kitchen programs show that regrtest.py keeps requesting more and more memory until it finishes all tests. IOW, it doesn't finalize properly each test. It keeps importing modules, without deleting them after each test. I think that before a particular test is run, we need to save the value of sys.modules, then restore it after the test (before running the next one). In a module enabled interpreter, this reduces the memory consumption almost by half... Patch? Think about the number of new tests that will be added in the future. I don't want to tolerate a silently approaching useless disk swapping :-) -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

2 1

Long Multiplication is not commutative.
by Christian Tismer April 7, 2000

April 7, 2000

Yikes! No, it is computatively commutative, just not in terms of computation time. :-)) The following factorial loops differ by a remarkable factor of 1.8, and we can gain this speed by changing long_mult to always put the lower multiplicand into the left. This was reported to me by Lenny Kneler, who thought he had found a Stackless bug, but he was actually testing long math. :-) This buddy... >>> def ifact3(n) : ... p = 1L ... for i in range(1,n+1) : ... p = i*p ... return p performs better by a factor of 1.8 than this one: >>> def ifact1(n) : ... p = 1L ... for i in range(1,n+1) : ... p = p*i ... return p The analysis of this behavior is quite simple if you look at the implementation of long_mult. If the left operand is big and the right is small, there are much more carry operations performed, together with more loop overhead. Swapping the multiplicands would be a 5 line patch. Should I submit it? ciao - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com

3 3