Python-Dev October 1999

python-dev@python.org

18 participants
16 discussions

Misleading syntax error text
by M.-A. Lemburg 01 Nov '99

01 Nov '99

[Extracted from the psa-members list...] Gordon McMillan wrote: > > Chris Fama wrote, > > And now the rub: the exact same function definition has passed > > through byte-compilation perfectly OK many times before with no > > problems... of course, this points rather clearly to the > > preceding code, but it illustrates a failing in Python's syntax > > error messages, and IMHO a fairly serious one at that, if this is > > indeed so. > > My simple experiments refuse to compile a "del getattr(..)" at > all. Hmm, it seems to be a failry generic error: >>> del f(x,y) SyntaxError: can't assign to function call How about chainging the com_assign_trailer function in Python/compile.c to: static void com_assign_trailer(c, n, assigning) struct compiling *c; node *n; int assigning; { REQ(n, trailer); switch (TYPE(CHILD(n, 0))) { case LPAR: /* '(' [exprlist] ')' */ com_error(c, PyExc_SyntaxError, assigning ? "can't assign to function call": "can't delete expression"); break; case DOT: /* '.' NAME */ com_assign_attr(c, CHILD(n, 1), assigning); break; case LSQB: /* '[' subscriptlist ']' */ com_subscriptlist(c, CHILD(n, 1), assigning); break; default: com_error(c, PyExc_SystemError, "unknown trailer type"); } } or something along those lines... BTW, has anybody tried my import patch recently ? I haven't heard any citicism since posting it and wonder what made the list fall asleep over the topic :-) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 61 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

2 2

dircache.py
by Gordon McMillan 01 Nov '99

01 Nov '99

Pursuant to my volunteering to implement Guido's plan to combine cmp.py, cmpcache.py, dircmp.py and dircache.py into filecmp.py, I did some investigating of dircache.py. I find it completely unreliable. On my NT box, the mtime of the directory is updated (on average) 2 secs after a file is added, but within 10 tries, there's always one in which it takes more than 100 secs (and my test script quits). My Linux box hardly ever detects a change within 100 secs. I've tried a number of ways of testing this ("this" being checking for a change in the mtime of the directory), the latest of which is below. Even if dircache can be made to work reliably and surprise-free on some platforms, I doubt it can be done cross-platform. So I'd recommend that it just get dropped. Comments? --------------------------------------------------- import os import sys import time d = os.getcwd() atimes = [] def test(): m = os.stat(d)[8] for i in range(10): fnm = 's%d.tmp' % i open(fnm,'w').write('dummy - delete me') for j in range(10000): newm = os.stat(d)[8] if newm != m: atimes.append(j*0.01) m = newm break time.sleep(0.01) else: print "At round %d, failed to detect add within %3.2f secs" % (i, j*0.01) break def report(): import operator if atimes: print "detect adds: min= %3.2f max= %3.2f avg= %3.2f" % (min(atimes), max(atimes), reduce(operator.add, atimes, 0.0)/len(atimes)) else: print "no successfully detected adds" test() report() - Gordon

2 1

Embedding Python when using different calling conventions.
by Mark Hammond 30 Oct '99

30 Oct '99

This is a bit yucky, but still a valid problem. Malte Kroeger [kroeger(a)bigfoot.com] recently posted to python-help with a problem. He has an existing Windows project that he wishes to use Python in. This project does not use the standard __cdecl calling convention that Python uses, for various reasons known only to him. As it is an existing project and quite probably a large, complex one, I am willing to accept that moving his existing project to match Python's calling convention is not reasonable. I also feel for him, as I have personally battled this - both with Python and with other projects. He has requested that Python explicitely declare the calling convention it uses. Thus, it can be embedded in any project. He wants a new macro. Eg: DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *)); becomes DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *)); I suggested embedding the calling convention in with the DL_IMPORT macro, but he pointed out this macro is also used for variables, where the convention syntax is illegal. To my mind this is reasonable (maybe not the spelling, but definately the intent). Any thoughts? Mark.

2 1

Irrelevant but very informative piece of patent law
by David Ascher 19 Oct '99

19 Oct '99

http://slashdot.org/features/99/10/19/1032254.shtml Very well written, too. Many many standard deviations away from standard slashdot fare. --da

1 0

forwarded message from Greg Rose
by Barry A. Warsaw 19 Oct '99

19 Oct '99

Folks, I'm resending this message here for Greg Rose. If anybody can help him out, please respond to ggr(a)qualcomm.com (not to me). Greg, if you still get no response, then I suggest sending the mssage to greater python-list(a)python.org. There's gotta be /somebody/ out there who is interested in participating. -Barry ------- start of forwarded message (RFC 934 encapsulation) ------- From: Greg Rose <ggr(a)qualcomm.com> To: bwarsaw(a)python.org Subject: Re: python advocate in Perl/Python/Tcl bakeoff Date: Tue, 19 Oct 1999 20:28:37 +1000 X-Sender: ggr2(a)avalon.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 At 17:07 30/09/1999 -0400, you wrote: >Hope that helps. If neither of these guys can do it, and can't >suggest someone who can, let me know and we'll post an announcement on >all the usual Python haunts. Well, as they say, those who volunteer end up doing things... I've tried both of your associates, and about three or four others who were recommended, and have struck out. I'd really appreciate your help trying to find someone competent to do this. Bear in mind that the audience is sysadmins, not generic programmers. thanks in advance, Greg. Here's the text I've been sending out, but you should feel free to modify non-factual stuff: Long ago there was a shell/perl/awk bakeoff invited talk at a USENIX conference somewhere or other. It was fun for all involved, and was very well received. We're looking to do something similar at the LISA conference in Seattle. You have been recommended as Python advocate. It would be on thursday 11th november. The idea would be to have a moderator and three advocates, and a slightly rowdy audience. We'd ask each advocate to nominate in advance some simple sysadmin task which shows their language to its advantage, and also to do the solutions to the other two's tasks... then there'd be some room for (presubmitted) tasks from the audience to be solved on the fly. Any suggestions you have regarding how to make it work would be appreciated. Are you intending to attend LISA? Would you be willing to do this? (We have Tom Christiansen for perl and Brent Welch for Tcl/Tk.) Greg Rose INTERNET: ggr(a)Qualcomm.com Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C ------- end -------

2 1

Corporate installations
by Tim Peters 18 Oct '99

18 Oct '99

Python is getting used widely enough in my place of employment that people are agitating for a common installation (personal variants are screwing people too often). Various machines are running Win95, Win98, NT, Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke on that whole banana when it's shoved down my throat. For starters, I just need to get it running across Windows platforms. Never looked into this before, and it seems to be exceedingly complicated right out of the box <0.5 wink>: D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'D:\\PYTHON\\DLLs', 'D:\\PYTHON\\lib', 'D:\\PYTHON\\lib\\plat-win', 'D:\\PYTHON\\lib\\lib-tk', 'D:\\PYTHON'] >>> Where does all that stuff come from? The first is apparently the current directory; cool. The next 4 appear to come from MarkH's stuff, via the registry. The next 4 appear to come from Python's own registry PythonPath key. The 4 after that are a mystery, and duplicate the preceding 4 (except for meaningless-- it's Windows <wink> -- case differences). The last is another mystery. site.py isn't implicated in any of them (same thing when running with -S). I suppose this is a clue: D:\Python>set PYTHONHOME=ick;fooey D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys >>> sys.path ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'ick', 'fooey\\DLLs', 'ick', 'fooey\\lib', 'ick', 'fooey\\lib\\plat-win', 'ick', 'fooey\\lib\\lib-tk', 'D:\\PYTHON'] >>> Doesn't appear to be sensible, but at least it's predictable <wink>. I was surprised to find that setting PYTHONPATH can't be used to override any of this -- it just inserts even more stuff, into sys.path[1:1]. Do I really care? Not much -- the complexity just makes it hard to get a mental model of what Python *thinks* it's trying to accomplish here, and so harder to figure out what needs to be done. Which is pretty severe: "Dragon std" apps must run the same version of Python (which can be local) with the same libraries (which must be network-mounted), regardless of whatever version of Python each user may have built on their own, and regardless of their registry settings or envar values. I think this means I need to distribute a python15.dll and python.exe (via our source control system) into a directory very early on the PATH (other common .exe's are distributed this way, so no big deal), and add a sitecustomize.py that replaces all of sys.path with the Big Four (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the common Dragon dir. Network name mangling being what it is, I suppose I'll also need to force PYTHONCASEOK. There's no way to do that from within Python, is there? If not, everyone going through "unfortunate" paths in the network will have to set that themselves. Anyone have better ideas? That shouldn't be hard <wink>. the-difference-between-one-user-and-two-is-infinite-ly y'rs - tim

9 13

Walking up the package hierarchy
by M.-A. Lemburg 14 Oct '99

14 Oct '99

Hi everybody, while I'm still thinking about writing the import manager, here is a patch that implements the walk-up-the-hierarchy import scheme that got so much positive feedback. I'm intending to use this implementation as proof of concept for the switch to my new package structure, but wouldn't mind seeing something like it the distribution as well ;-) It changes the default import mechanism to work like this: >>> import d try a.b.c.d try a.b.d try a.d try d fail instead of just doing the current two-level lookup: >>> import d try a.b.c.d try d fail As a result, relative imports referring to higher level packages work out of the box without any ugly underscores in the import name. Plus the whole scheme is pretty simple to explain and straightforward. Since the patch is so small, I attached it to this mail. Hope you don't mind. The ZIP archive also contains a sample package which demonstrates the feature. Run Python with -v flag to see how the new scheme works. Feedback is most welcome. I am especially interested whether the scheme breaks any existing packages. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 81 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

2 2

new opportunities for obfuscation... ;-)
by Skip Montanaro 12 Oct '99

12 Oct '99

Barry's note prompted me to update my Python tree. The result: >>> ".".join(dir("")) 'capitalize.count.endswith.find.index.join.lower.lstrip.replace.rfind.rindex.rstrip.split.startswith.strip.swapcase.translate.upper' A job well done, Barry... Skip Montanaro | http://www.mojam.com/ skip(a)mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented...

1 0

string methods branch
by Barry A. Warsaw 12 Oct '99

12 Oct '99

Guido has agreed to let me mainline the string methods branch. Those of you on python-checkins should have seen the CVS messages by now. This is a good thing because I think we can all agree we hate CVS branches. For me, that final merge put the nail in the coffin. Anyway, those of you who have put off playing with string methods until now should just be able to do a CVS update, rebuild, and go. You should read the revision log messages for the branch checkins for details of the changes. Let me know if you have any problems. Fred and I will work out changes to the documentation some time soon. >>> sig=['branches','are','only','useful','for','trees','and','streams','ly'] >>> print '-'.join(sig) + " y'rs" -Barry

1 0

RE: [Python-Dev] an alternative language for CP4E, perhaps?
by Ken Manheimer 06 Oct '99

06 Oct '99

Concerning the possibility of cobolscript, i wrote: > said), i guess someone thinks there's leverage in making cobol a scripting > language. I think it's not so different than making interpreted versions > of C (but i'm not very C friendly). After posting i thought this might come off as more ignorantly bigoted than i meant for it to seem:-) I was trying to say that C doesn't seem very well suited to scripting/running interpreted, like cobol - not that C is as fraught with ancient and awkward design as cobol (seems). Sigh. Ken klm(a)digicool.com

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev October 1999