Mailman 3 November 2001 - Python-Dev

python-dev vs. the spammers
by Fredrik Lundh 28 Nov '01

28 Nov '01

just noticed that I received 60 check-in messages during the last 24 hours (yesterday, in local time), and only 51 spams. and as far as I can tell, that's the first time that happened since I changed mail system (my old setup didn't generate statistics, so this could be the first time ever ;-) </F>

1 0

Re: [Python-Dev] PyArg_ParseTuple and unicode
by Jack Jansen 28 Nov '01

28 Nov '01

MAL wrote: > Jack Jansen wrote: > > > > I had expected the PyArg_ParseTuple() "u" specifier to automatically convert > > string objects to unicode strings with the default encoding (just as the > > reverse is true for "s"), but to my surprise it doesn't. > [...] > > I could imagine extending the "u" parser marker to do the same > using an temporary Unicode object the contents of which are then > copied into a user provided buffer (much like what "es#" does). > Alternatively, we could extend the "e" parser marker with a > "u" target... this has the added benefit of being able > to define an encoding to use for dealing with non-Unicode > string data. I like this second alternative, because it also provides a possible solution for a more complex problem I have. I'm porting the PythonWin MFC modules to Windows CE, and on WinCE the OS API's are completely unicode-based. In C you can write code that is portable between 8-bit systems and Unicode systems by using a set of macros and types that get expanded to char/strlen/sprintf/etc or wchar_t/wslen/etc. Currently I have every PyArg_ParseTuple #ifdeffed, but using an "e" marker would be better. > If you think this is needed, please upload a feature request to > SF and assign it to me. I'll look into this after the feature > freeze then. As I'm doing this project with a very old Python I might as well do it myself (unless I can't figure out how:-), and then I'll put the patch in sourceforge, hand it over to you and you can turn my gibberish into real C:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

[development doc updates]
by Fred L. Drake 27 Nov '01

27 Nov '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Minor updates; mostly changed organization of the "Internet Data Handling" chapter.

1 0

Re: mysnprintf broken
by Martin v. Loewis 27 Nov '01

27 Nov '01

> Is there some reason why we can't incorporate a free snprintf > implementation? There is a list available at > http://www.ijs.si/software/snprintf/. Looks like the time machine is at work again: the version we use *is* a free snprintf implementation. If you want to replace it with a different one, you should indicate specifically which one you'd like to use instead. I think Mark Martinec's implementation (the top one on the URL you give) is unacceptable, because the license is too restrictive: we must incoporate the package in its entirety, i.e. redistribution of portions seems not to be licensed by the Frontier Artistic License. I don't have the time to review 10 other implementations for their suitability both in terms of licensing and correctness. Instead, I'd rather review the three occurrences of PyOS_snprintf, to determine quickly that you will have a hard time to overflow that buffer; *it is not at all easy*. Even if it does overflow, you will get a fatal error, rather than silent memory corruption. That is good enough for me. Regards, Martin

4 8

Re: Change to sys.path[0] for Python 2.3
by Martin v. Loewis 27 Nov '01

27 Nov '01

> This insertion occurs after a number of imports have already > occurred. Specifically, it occurs after the import of site, os, and > sitecustomize. This is confusing. It is clear that sys.path should > not change unless the user changes it. I disagree. It is clear that sys.path will change during "bootstrap", e.g. as the result of processing .pth files. > If we want the directory of the script to be sys.path[0], then an > absolute path should be inserted. I think this would be unimplementable in the general case. > If everyone agrees, I will create a patch. It's not clear to me what this patch would do, so I disagree. Regards, Martin

3 7

Re: [Python-Dev] Re: Change to sys.path[0] for Python 2.3
by Jack Jansen 27 Nov '01

27 Nov '01

> 4) For the "-c" option, sys.argv[0] is getcwd() instead of "". A related issue: what is sys.path[0] for an interactive interpreter? I customarily use Python as a shell, and os.chdir() from one place to another, importing things along the way. Would an interactive interpreter keep the "" entry in sys.path[0]? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 3

PyArg_ParseTuple and unicode
by Jack Jansen 27 Nov '01

27 Nov '01

I had expected the PyArg_ParseTuple() "u" specifier to automatically convert string objects to unicode strings with the default encoding (just as the reverse is true for "s"), but to my surprise it doesn't. Is there a deep reason for this, or am I the first person to want this functionality? Or do I miss something and should I use a different format specifier? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

Re: [Python-Dev] Re: Change to sys.path[0] for Python 2.3
by Jack Jansen 27 Nov '01

27 Nov '01

> I am not happy with changing current directories because I am trying > to speed up imports, and it is harder to cache directory contents > on multiple operating systems. But I can do it if we need to. Ah, at least now I understand what you're trying to do. BUT: have you done any measurements that show that this caching is actually beneficial? For many years we've used a special caching importer in a very big Python project here, and when we finally did some real measurements it turned out that it had slowed down imports all that time in stead of speeding them up. You have to be especially aware of NFS mounted filesystems. Hmm, why not cache on a sys.path entry-by-entry basis? Then, if the entry is a zipfile we always cache, if the entry is a relative pathname we never cache, if the entry is an absolute pathname we cache on the basis of a preference. Use the sys.path entry as a key in a dictionary, the result is either None (don't cache) or the cache for this sys.path entry. If the key isn't found this is the first time we come across this sys.path entry so we decide whether to cache or not. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Python-Dev] Re: Change to sys.path[0] for Python 2.3
by Jack Jansen 27 Nov '01

27 Nov '01

> 1) Create an initial sys.path but without its first item. > 2) Import site, os, sitecustomize, etc. > 3) Insert a new item as sys.path[0]. This will not work for a frozen MacPython program. In such a program the sys.path initializer is ["$(APPLICATION)"]. So, there's no empty current directory entry in sys.path[0], the only thing in sys.path is the magic cookie "$(APPLICATION)". Early in startup, before site.py is imported, the cookie is replaced by the full pathname of the application. The import code knows that if it sees a file on sys.path (as opposed to a directory) it will look in that file for frozen PYC resources. And, before you ask, I'm aware that in the future this code will have to test whether or not the file has a .zip extension, and go down the zip-import leg if it has. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

re: PEP 275: Switching on Multiple Values, Rev 1.2
by Brian Slesinsky 27 Nov '01

27 Nov '01

Hi, I'm new to the list and apologies for going off-topic a bit (this has nothing to do with performance): If Python implements switch statements it would be a shame not to have pattern-matching in switch statements too. This is a feature that has long been used in functional languages like ML. For example, here's pattern matching on a tuple: def foo(a,b): switch (f(a), g(b)): case (c,1): something(c) # if g(b)==1, assigns c = f(a) case (1,d): something(d) # if f(a)==1, assigns d = g(b) case (c,_): something(c) # any tuple: assigns c = f(a), _ is wildcard Some syntactic sugar related to this would be a way to pattern-match on arbitrary objects as is now done with tuples: def foo(pair, number): Pair(x,y) = pair # assert isinstance(pair,Pair), assigns x and y int(i) = number # assert type(x)==IntType, assign i (To implement this, classes would have a __tuple__ method that returns the tuple for matching. By convention it should return the arguments to its __init__ method.) Note how type-checking happens in a very natural way: a = int(a) # convert a int(a) = a # type-check a Combining the two: def sum(pairOrInt): switch pairOrInt: case int(a): return a case Pair(x,y): return sum(x)+sum(y) Here's some documentation on how it's done in Cyclone, a C variant from AT&T that seems to have a strong ML influence: http://www.research.att.com/projects/cyclone/online-manual/main-screen005.h… ---------------------------------------------------------------------- Brian Slesinsky

4 6