Mailman 3 May 2000 - Python-Dev

weird bug in test_winreg
by Guido van Rossum 04 May '00

04 May '00

I just noticed a weird traceback in test_winreg. When I import test.autotest on Windows, I get a "test failed" notice for test_winreg. When I run it by itself the test succeeds. But when I first import test.autotest and then import test.test_winreg (which should rerun the latter, since test.regrtest unloads all test modules after they have run), I get an AttributeError telling me that 'None' object has no attribute 'get'. This is in encodings.__init__.py in the first call to _cache.get() in search_function. Somehow this is called by SetValueEx() in WriteTestData() in test/test_winreg.py. But inspection of the encodings module shows that _cache is {}, not None, and the source shows no evidence of how this could have happened. Any suggestions? --Guido van Rossum (home page: http://www.python.org/~guido/)

1 1

Re: [XML-SIG] Re: [I18n-sig] Re: [Python-Dev] Unicode debate
by tpassin＠home.com 03 May '00

03 May '00

Guido van Rossum wrote, about how to represent strings: > Paul, we're both just saying the same thing over and over without > convincing each other. I'll wait till someone who wasn't in this > debate before chimes in. I'm with Paul and Federick on this one - at least about characters being the atoms of a string. We **have** to be able to refer to **characters** in a string, and without guessing. Otherwise, how could you ever construct a test, like theString[3]==[a particular japanese ideograph]? If we do it by having a "string" datatype, which is really a byte list, and a "unicodeString" datatype which is a list of abstract characters, I'd say everyone could get used to working with them. We'd have to supply conversion functions, of course. This route might be the easiest to understand for users. We'd have to be very clear about what file.read() would return, for example, and all those similar read and write functions. And we'd have to work out how real 8-bit calls (like writing to a socket?) would play with the new types. For extra clarity, we could leave string the way it is, introduce stringU (unicode string) **and** string8 (Latin-1 or byte list, whichever seems to be the best equivalent to the current string). Then we would deprecate string in favor of string8. Then if tcl and perl go to unicode strings we pass them a stringU, and if they go some other way, we pass them something else. COme to think of it, we need some some data type that will continue to work with c and c++. Would that be string8 or would we keep string for that purpose? Clarity and ease of use for the user should be primary, fast implementations next. If we didn't care about ease of use and clarity, we could all use Scheme or c, don't use sight of it. I'd suggest we could create some use cases or scenarios for this area - needs input from those who know encodings and low level Python stuff better than I. Then we could examine more systematically how well various approaches would work out. Regards, Tom Passin

13 50

Re: [Python-checkins] CVS: python/dist/src/Python bltinmodule.c,2.154,2.155
by Jack Jansen 03 May '00

03 May '00

> _PyBuiltin_Init_2(): Don't test Py_UseClassExceptionsFlag, just go > ahead and initialize the class-based standard exceptions. If this > fails, we throw a Py_FatalError. Isn't a Py_FatalError overkill? Or will not having the class-based standard exceptions lead to so much havoc later on that it is better than limping on? -- 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

2 1

Unicode comparisons & normalization
by Just van Rossum 03 May '00

03 May '00

After quickly browsing through the unicode.org URLs I posted earlier, I reach the following (possibly wrong) conclusions: - there is a script and language independent canonical form (but automatic normalization is indeed a bad idea) - ideally, unicode comparisons should follow the rules from http://www.unicode.org/unicode/reports/tr10/ (But it seems hardly realistic for 1.6, if at all...) - this would indeed mean that it's possible for u == v even though type(u) is type(v) and len(u) != len(v). However, I don't see how this would collapse /F's world, as the two strings are at most semantically equivalent. Their physical difference is real, and still follows the a-string-is-a-sequence-of-characters rule (!). - there may be additional customized language-specific sorting rules. I currently don't see how to implement that without some global variable. - the sorting rules are very complicated, and should be implemented by calculating "sort keys". If I understood it correctly, these can take up to 4 bytes per character in its most compact form. Still, for it to be somewhat speed-efficient, they need to be cached... - u.find() may need an alternative API, which returns a (begin, end) tuple, since the match may not have the same length as the search string... (This is tricky, since you need the begin and end indices in the non-canonical form...) Just

4 4

PROPOSAL: exposure of values in limits.h and float.h
by Trent Mick 03 May '00

03 May '00

I apologize if I am hitting covered ground. What about a module (called limits or something like that) that would expose some appropriate #define's in limits.h and float.h. For example: limits.FLT_EPSILON could expose the C DBL_EPSILON limits.FLT_MAX could expose the C DBL_MAX limits.INT_MAX could expose the C LONG_MAX (although that particulay name would cause confusion with the actual C INT_MAX) - Does this kind of thing already exist somewhere? Maybe in NumPy. - If we ever (perhaps in Py3K) turn the basic types into classes then these could turn into constant attributes of those classes, i.e.: f = 3.14159 f.EPSILON = <as set by C's DBL_EPSILON> - I thought of these values being useful when I thought of comparing two floats for equality. Doing a straight comparison of floats is dangerous/wrong but is it not okay to consider two floats reasonably equal iff: -EPSILON < float2 - float1 < EPSILON Or maybe that should be two or three EPSILONs. It has been a while since I've done any numerical analysis stuff. I suppose the answer to my question is: "It depends on the situation." Could this algorithm for float comparison be a better default than the status quo? I know that Mark H. and others have suggested that Python should maybe not provide a float comparsion operator at all to beginners. Trent -- Trent Mick trentm(a)activestate.com

2 1

Re: [XML-SIG] Re: [I18n-sig] Re: [Python-Dev] Unicode debate
by jkraai＠murlmail.com 02 May '00

02 May '00

The ever quotable Guido: > English is the one natural language that we can all sue to communicate ------------------------------------------------------------------ You've received MurlMail! -- FREE, web-based email, accessible anywhere, anytime from any browser-enabled device. Sign up now at http://murl.com Murl.com - At Your Service

1 0

Re: [Python-checkins] CVS: python/dist/src/Doc/lib libos.tex,1.38,1.39
by pf＠artcom-gmbh.de 02 May '00

02 May '00

Barry A. Warsaw: > Update of /projects/cvsroot/python/dist/src/Doc/lib [...] > libos.tex [...] > Availability: Macintosh, \UNIX{}, Windows. > \end{funcdesc} > --- 703,712 ---- > \end{funcdesc} > > ! \begin{funcdesc}{utime}{path, times} > ! Set the access and modified times of the file specified by \var{path}. > ! If \var{times} is \code{None}, then the file's access and modified > ! times are set to the current time. Otherwise, \var{times} must be a > ! 2-tuple of numbers, of the form \var{(atime, mtime)} which is used to > ! set the access and modified times, respectively. > Availability: Macintosh, \UNIX{}, Windows. > \end{funcdesc} I may have missed something, but I haven't seen a patch to the WinXX and MacOS implementation of the 'utime' function. So either the documentation should explicitly point out, that the new additional signature is only available on Unices or even better it should be implemented on all platforms so that programmers intending to write portable Python have not to worry about this. I suggest an additional note saying that this signature has been added in Python 1.6. There used to be several such notes all over the documentation saying for example: "New in version 1.5.2." which I found very useful in the past! Regards, Peter

4 4

Traceback style
by Ka-Ping Yee 02 May '00

02 May '00

This was also going to go out after i posted the display/displaytb patch. But anyway, let's see what you all think. I propose the following stylistic changes to traceback printing: 1. If there is no function name for a given level in the traceback, just omit the ", in ?" at the end of the line. 2. If a given level of the traceback is in a method, instead of just printing the method name, print the class and the method name. 3. Instead of beginning each line with: File "foo.py", line 5 print the line first and drop the quotes: Line 5 of foo.py In the common interactive case that the file is a typed-in string, the current printout is File "<stdin>", line 1 and the following is easier to read in my opinion: Line 1 of <stdin> Here is an example: >>> class Spam: ... def eggs(self): ... return self.ham ... >>> s = Spam() >>> s.eggs() Traceback (innermost last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in eggs AttributeError: ham With the suggested changes, this would print as Traceback (innermost last): Line 1 of <stdin> Line 3 of <stdin>, in Spam.eggs AttributeError: ham -- ?!ng "In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand." -- Gerald Holton

7 11

documentation for new modules
by Fred L. Drake, Jr. 02 May '00

02 May '00

The "winreg" module needs some documentation; is anyone here up to the task? I don't think I know enough about the registry to write something reasonable. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

3 5

fun with unicode, part 1
by Fredrik Lundh 02 May '00

02 May '00

>>> filename = u"gröt" >>> file = open(filename, "w") >>> file.close() >>> import glob >>> print glob.glob("gr*") ['gr\303\266t'] >>> print glob.glob(u"gr*") [u'gr\366t'] >>> import os >>> os.system("dir gr*") ... GRÇôT 0 01-02-03 12.34 grÇôt 1 fil(es) 0 byte 0 dir 12 345 678 byte free hmm. </F>

9 12