"Fredrik Lundh" <fredrik(a)pythonware.com> wrote:
> I look away for two hours (damn the french!), and when I get back,
> some kiwi troll has successfully taken control over python-dev.
Sorry friend, but asking an unpopular question doesn't make
me a ``troll'', and I don't appreciate the cultural slurs.
http://movies.yahoo.com.au - Yahoo! Movies
- What's on at your local cinema?
The attached will obviate need for patches like the following forever:
Unfortunately, this is a slippery slope. Unlike auto-importing
functions which has been around for a while, auto-importing data is
very new (and kind of scary). Additionally, it requires a special
linker option, --enable-runtime-pseudo-reloc, to work in all cases.
Hence, Cygwin Python shared extensions and embedded interpreters will
need to modify their build process unless they are using distutils.
I'm looking for advice. Should I use the latest, greatest Cygwin
functionality that makes building as similar as possible to Unix? Most
likely at the expense of breaking some dependent packages. Or, are
patches like the above considered acceptable and the preferred way to
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
From: Raymond Hettinger [mailto:firstname.lastname@example.org]
> The docs and examples are a good place to start.
Just looked at the documentation for now...
count: In the absence of any explicit statement, I'd expect it
to work transparently with longs, not just integers. You should
likely make this explicit.
dropwhile: the definition doesn't mention an "invert" parameter,
but the Python equivalent does (but doesn't use it). This
parameter (I assume) would merge the functionality of "dropwhile"
and "dropuntil". Maybe it would be more readable to have both
(implemented internally via a single function and a flag, probably)?
It's also probably worth pointing out that dropwhile could have a
slow startup time - imagine
from itertools import dropwhile, count
for n in dropwhile(lambda x: x < 2**30, count(-2**30)):
The first iteration wouldn't happen for a long time... (This is
true of most iterator functions, it's just more surprising in this
case as all of the remaining iterations will be "fast")
ifilter: "Evaluates to True" should probably just be "is true".
The Python code accepts functions returning non-boolean values
in the natural way.
imap: The stop-on-shortest behaviour is reasonable (given the nature
of iterators), but the fact that it's different from map is
definitely a wart. That's the key reason for having zip as well as
map, isn't it? It's nearly worth a different name, but I can't think
of one :-(
izip: No real problem, other than that the subtle differences between
zip and map(None) are hard to remember. Add the subtle differences
between zip and izip, and map and imap, and it all gets rather messy.
I wish there was an easy way of unifying or differentiating these.
But I can't offer one myself :-(
starmap: Um, I see the point. Sort of. A usage example or two would
help a lot - I can't think why I'd want this. And I hate the name.
Isn't it basically iapply?
takewhile: As with dropwhile, the issue of the invert parameter (or
a function dropuntil) needs resolving.
In the examples section, reimplementation of existing tools, nth is
wrong (the definition doesn't use "s"!) Also, with the definitions
of enumerate/iteritems, my initial thought was "but the builtins will
be quicker". This makes the examples bad, as they associate the
itertools functions with the idea that they are slow. (Of course,
that isn't the point, nor is it true, but it's not a good impression
to leave the reader with).
One final point - I don't really like the i- form of the names. We
already have this style with x- forms like range/xrange, and it bugs
me because I'm not *really* comfortable with having 2 forms (it's the
usual problem of why use one rather than the other - and the name
gives no clue). The need is there with builtins, but for a module
maybe it isn't. Could we not have itertools just defining map, zip, ...
functions. Then a user can either use the qualified form, or use
import from. So you have
for x in itertools.zip(a,b):
from itertools import zip as izip
for x in izip(a,b):
On the other hand, maybe this will also end up causing confusion...
Hope this helps,
I've recently written a short Informational PEP describing all the
places that may need updating when you change Python's Grammar.
Naturally, it's on the web at
I'd be very grateful if people could scan through it and tell me about
or just add anything I've missed, particularly the Jython issues.
Title: How to Change Python's Grammar
Version: $Revision: 1.2 $
Last-Modified: $Date: 2003/01/30 10:27:45 $
Author: Michael Hudson <mwh(a)python.net>
There's more to changing Python's grammar than editing
Grammar/Grammar and Python/compile.c. This PEP aims to be a
checklist of places that must also be fixed.
It is probably incomplete. If you see omissions, just add them if
you can -- you are not going to offend the author's sense of
ownership. Otherwise submit a bug or patch and assign it to mwh.
This PEP is not intended to be an instruction manual on Python
grammar hacking, for several reasons.
People are getting this wrong all the time; it took well over a
year before someone noticed that adding the floor division
operator (//) broke the parser module.
__ Grammar/Grammar: OK, you'd probably worked this one out :)
__ Python/compile.c: you'll most likely need to edit both the
actual compiler and the symtable builder (which is to say both
the com_foo and the sym_foo functions).
__ You may need to regenerate Lib/symbol.py and/or Lib/token.py.
__ The parser module. Add some of your new syntax to test_parser,
bang on parsermodule.c until it passes.
__ The compiler package. A good test is to compile the standard
library and test suite with the compiler package and then check
it runs. You did add some of your new syntax to the test
suite, didn't you? There's a script in Tools/compiler that
__ If you've gone so far as to change the token structure of
Python, then the tokenizer library module will need to be
__ Certain changes may require tweaks to the library module
__ Jython too will need work, but I don't know what. Explanations
 SF Bug #676521, parser module validation failure
This document has been placed in the public domain.
I don't have any special knowledge of all this. In fact, I made all
the above up, in the hope that it corresponds to reality.
-- Mark Carroll, ucam.chat
Just van Rossum <just(a)letterror.com> writes:
> Jim Fulton wrote:
> > In particular:
> > def name(arg, ...) [expr1, expr2, expr3]:
> > ...body...
> > would be equivalent to (some variation on):
> > def name(arg, ...):
> > ...body...
> > name=expr1(expr2(expr3(name)))
> With Michael's patch (which indeed still works) it's actually
> name = expr3(expr2(expr1(name)))
I can't remember if that was deliberate or accidental. I think
> > I wonder if the same mechanism could be used in class statements.
> > If I had this, I might say what interface a class implements
> > with:
> > class foo(spam, eggs) [implements(IFoo, IBar)]:
> > body of class
> > or (wo parens):
> > class foo [implements(IFoo, IBar)]:
> > body of class
> I don't know how Zope interfaces work, but I can imagine the following
> could be made to work as well:
> class foo(spam, eggs) [IFoo, IBar]:
> body of class
> I think this would be wonderful. Would someone be interested in
> extending Michael's patch to also cover the class statement?
Maybe even me :-) It wasn't very hard.
You still can't use lambdas in the filter list. I thought I'd fixed
that ages ago, but it seems not.
I have no disaster recovery plan for black holes, I'm afraid.
Also please be aware that if it one looks imminent I will be
out rioting and setting fire to McDonalds (always wanted to do
that) and probably not reading email anyway. -- Dan Barlow
From: Samuele Pedroni [mailto:email@example.com]
> Can you modify the locals of the surrounding (function) scope in the
> thunk, or its an anonymous closure with the current nested scopes
> rules (no rebinding)?
That's a very good point. I can see arguments both ways. And equally,
I can see arguments *against* either.
> I honestly find that trying to use a single extension to solve
> very different problems is a bad idea, e.g. currently class is
> semantically very different from control flow statements, the idea
> that a single extension can offer extensions for both up to general
> syntax extensibility seems far stretched.
Again, this is a good point.
There are basically two sorts of compound statement in Python, which I
could characterise as "defining" statements (class, def), and "control
flow" statements (if, while, try, ...)
The property() issue is a "defining" problem, whereas the acquire/release
issue is a "control flow" one. I think you're right that the two can't
be solved sensibly with a single mechanism.
> Personally I would find the addition of:
> 1)  extendend function syntax to def (and possibly class and 2)
> 2) a statement that captures and extends what class does now ("my" proposal)
> 3) a 'with' statement for semantics like those of CL with- macros (Michael
> Hudson has some ideas on this)
> more pythonic.
Sounds reasonable. (1) is useful for staticmethod/classmethod. (2) is
useful for properties, and I assume (3) fits in with acquire/release (I'm
not completely familiar with what you mean by with-macros, so I'm guessing
> General syntax extensibility is another level of identity crisis for the
> language <wink>.
Aw, can't we have a completely user-definable syntax, like Perl 6 is going to?
Please? Pleeeeease? All the other kids do it! I'm gonna look so uncool!!!
Sorry, I was getting frustrated by having nothing to disagree with in your
message. I'll go and lie down now :-)
> Maybe we can change the syntax back to something that started this.
> Instead of the xdef keyword, we'd use a colon at the end of an
> expression or assignment line. The grammar could be e.g.
> statement: (variable '=')* expression [':' suite]
> (Where suite is a simple statement or NEWLINE INDENT block DEDENT.)
OK, that's the grammar. But what's the semantics? I can infer some
of it from the examples below, but I can't generalise it.
Let's start with some specifics:
You're *only* proposing this extension (the : suite) for expression and
assignment statements, yes? Specifically, from the current grammar,
"expression_statement" and "assignment_statement". No augmented
assignments? I can't see the use for
var += expr : suite
but someone's going to (ab)use it if it's available.
On the other hand, what about destructuring assignments?
v1, v2, v3 = expr : suite
It's not at all clear what that would mean... (Or maybe it is, see
If you're looking solely at the case you state above, that becomes
a completely new grammar rule (which overlaps a lot of others). For
a more explicit rule, you want
guido_statement: (variable '=')* expression ':' suite
which is a compound (rather than simple) statement in the grammar.
I consider it a bad sign that I can't think of an obvious name for
this construct :-)
> Then the locking example could be written as
> This would mean
> where thunk would be a callable representing the block as before.
OK, so the semantics are that
expr : suite
requires expr to be a callable of a single argument, and calls that
callable, passing it *another* callable whose effect is to execute
That's not unreasonable, but you'd need to handle errors (most likely
that expr isn't the right type of value) very carefully, or nobody's
going to understand what went wrong :-)
> If a variable was present it would receive the result, so that e.g.
> foo = property:
> def get(self): ...
> would end up meaning
> foo = property(thunk)
> which is only a very small stretch from what property currently does
> (it would have to do a typecheck on its argument for backwards
But this isn't compatible with your previous example! If thunk is a
callable which encapsulates the suite, then in this case, you need
foo = property(*thunk())
and you need the suite to end explicitly with a return statement,
returning a tuple of values for the argument to property(). Unless
you are suggesting letting property() do something different when
called with a single argument which is a callable. I don't like that,
it's too magical.
The more I think about it, the less I like it. Basically, it's under-
specified. You can give examples showing "how" you can use the syntax
to solve lots of problems, but when you try to unify the examples,
the edge cases don't match.
The advantage of Samulele's proposal is that the semantics was explicit,
by defining the equivalent code. I also liked the fact that the suite
was "just evaluated", and the user code got passed the resulting
environment - it meant you didn't have to remember to add "return"
statements. But on the other hand, it meant you couldn't control *when*
the thunk was executed (to wrap try...finally round it, or to do
conditional or repeated execution). So it's not useful for your
There are two separate requirements here - a syntax for property
definitions, and a synchronised block construct (which can easily be
generalised to cover most forms of acquire/release requirements). I'm
not at all sure it's valid to try to make a general construct which
satisfies both requirements.
... And actually, I'm much less bothered about properties than about
acquire/release. I use neither a lot, but I find the current situation
more bothersome for acquire/release. At some point we really *must* get
this thread split into separate issues, if only to give Brent a fighting
chance when summarising :-)
I'm taking this thread across the great divide to the python-dev mailing
list. The point Yasushi makes is that the security hole found and fixed by
Zack Weinberg back in August 2002 (os.py 1.59) should be avaiable as a patch
for versions of Python "out there" which might be affected. The versions
he's concerned with are 1.5.2 and 2.1.3. I don't think we have to worry
about 2.2.1 because those users can (and should) upgrade to 2.2.2 if the
patch is important to them.
To see the original thread, go here:
Yasushi> Thank you. But I think this patch or pached version of Python
Yasushi> should be placed on ftp.python.org.
Yasushi> Zope doesn't work with Python 2.2 yet. So many new Zope users
Yasushi> will install Python 2.1.3. But there is no patch on
Yasushi> ftp.python.org and no security alert on www.python.org.
Zope ships with its own version of Python, often in binary (for Windows).
The Zope folks probably need to provide their own patch.
Yasushi> How do they know that Python 2.1.3 has security problem?
Who are "they"?
You have to realize that the people who develop Python don't know all the
people who bundle Python in applications. It's open source and most of the
people who work on Python are volunteers.
Can someone on python-dev more in-the-know about these things respond?
So far, the itertools package has had two reviewers
and I implemented every suggestion except one.
The package is in very good shape and could use
another pair of reviewers. The C code, setup.py,
unittests, and documentation are at:
The docs and examples are a good place to start.
I enjoy programming in Python and find it very productive. However,
one glaring weakness is the absence of a high-performance native code
compiler. Are there any plans to develop this?
Languages like OCaml have both a bytecode compiler and a native code
compiler, so you can do rapid development with the interactive
interpreter, and then compile down to native-code when you're finished
to get C-like speed out of your application.
So, it seems feasible that this could be done for Python as well, no?
http://movies.yahoo.com.au - Yahoo! Movies
- What's on at your local cinema?