[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/
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
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.
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 -------
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
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/
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...
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
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
