As already announced, the
*** S t a c k l e s s S p r i n t ***
has now a settled date:
It will take place in Berlin, March 10-14 2004.
We will have a room in the Free University of Berlin
in Berlin-Dahlem. Address and room will be announced,
How to attend?
See bottom of this message.
Well, there is a lot possible.
Current topics which come into mind are
* scheduling object
* brain storming!
* Zope Wiki and Documentation
* making channels really stackless
* demo applications
* more regression tests
* real zope apps?
* refactoring Stackless: simpler and configurable
* create a Stackless tutorial
* minimalist Stackless Python with no hardware dependency
* assembly-free Stackless with setjmp/longjmp
* spreading the internals between developers
but this is completely open for discussion.
Well, it will be a bit simpler than the pypy-sprints,
which I think are very difficult, but Stackless
has its built-in difficulties by nature.
This is by far, now and forever, the best possible way
to learn about Stackless Python and to become a core
developer. But no guarantee possible :-)
Well, it is intended that Stackless Python should
be developed further. If you are using or planning to
use Stackless for your products, you are highly encouraged
to support Stackless Python by money and by submitting
your best developers, regardless how painfully they are
going to be missed by the company.
Yes, it is probable and whished, that Stackless Python
will become a topic for training and coaching.
First of all, we will try to leverage our knowledge.
There is no particular schedule, yet, but for the first day.
I am planning to give a talk on Stackless technology, and
to be available for questions and discussion during the
whole first day.
Attendees with small or no knowledge about Stackless Python
are strongly encouraged to join that session.
There are no special arrangements planned. We hope to find
a place for every external sprinter at the home of the
Berlin habitants. I'm taking two already, please don't ask.
How to attend:
Please subscribe to the mailing list
which you can find via this interface:
By subscribing, you state that you want to come to the sprint.
We have only limited reources left and can take only a few.
I hereby wish to thank *Dirk Pape* and *Christoph v. Stuckrad*
from FU Berlin for making this event possible!
cheers - chris
Christian Tismer :^) <mailto:firstname.lastname@example.org>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
Delaney, Timothy C (Timothy):
> a. def foo (bar) [baz]:
> b. def foo (bar) as baz:
> c. def [baz] foo (bar):
Note that c. is like Quixote
> d. def baz foo (bar):
> e. def foo [baz] (bar):
> (1b) is the most visually pleasing, but the
> lack of syntax means that the decorator doesn't
> stand out as well as (a). However, it's simple
> to syntax-colour 'as', so that's close to a non-issue.
> (1a) seems to be the most understandable, and is
> quite visually pleasing - the decorator is obviously special,
> but feels more like it's an explanatory note.
You left out
f. def foo (bar) mod [baz]:
The current patch is not really using a list, it is
using magic characters "[" and "]". Given that, it
could as easily use magic characters "mod [" and "]"
Option 1.f. still has all the syntax-coloring advantages
of 1.a., but makes it more obvious that the "mod [baz]"
is truly an optional annotation.
("as" is the shortest suggestion for "mod", but
not the only one. Also suggested are many variations
on "transformed_by", "modified_by", "decorators",
"providing", "extended_by", etc.)
> if (PyObject_Size(args) < 0) return NULL;
> ! args = PyTuple_Pack(1, args);
> ! if (args == NULL)
> ! return NULL;
> ! tmp = PyObject_Call(joiner, args, NULL);
> ! Py_DECREF(args);
> UNLESS (tmp) return NULL;
There are both tabs and spaces in this code. Question: is there a
convention about tabs and spaces in C code?
From: Michael Hudson
> "Delaney, Timothy C (Timothy)" <tdelaney(a)avaya.com> writes:
>> Anyway, those are my thoughts on the whole topic. I'm:
> Nice work.
>> +1 on syntax for decorators attached to function definitions
>> +1 on def foo (bar) [baz]:
>> +0 on def foo (bar) as baz: if there's a way to extend it multi-line.
>> -1 on all the other proposed syntaxes.
>> -1 on restricting it to specific decorators such as classmethod
> I agree, FWIW.
Agreed, on all counts.
Also, while people are currently coming up with some fairly extreme uses of
the new feature, I don't think that's a particularly bad thing. As with any
new construct, it can be abused, but in practice, good taste will prevail,
and in the meantime, the experimentation just proves the flexibility of the
> * Is there a way to compute the standard deviation without multiple
> passes over the data (one to compute the mean and a second to sum the
> squares of the differences from the mean?
I do not understand the problem in getting stdev in a single pass.
Perhaps I not understood your problem. If you have a series of values
you merely have to calculate their sum and sum-of-squares and use the
Ignore this if this is dumb.
Prof G A Vignaux
Mathematical and Computing Sciences,
Victoria University, PO Box 600, Work: +64 4 463 5276
Wellington, NZ Home: +64 4 934 7851
Tony.Vignaux.Remove_This_Bit(a)mcs.vuw.ac.nz Mobile: +64 21 89 7851
In the threading module, one must of course only start a thread once. I
have some questions about handling this gracefully.
First of all, the documentation only says it is an error to start a
thread more than once. It does not say which exception is raised. On my
system I find it is AssertionError. So...is that going to be true on all
systems? Is the test based on "assert", in which case it will go away
for optimized code (and then what happens)?
Anyway, if it is always AssertionError, I'd like to get the docs updated
to say that.
Also...if possible, it'd be nice to have some way to ask if a thread has
ever been started. More generally, it'd be nice to be able to determine
what state a thread is in. I'm not sure if there are any states other
than ready to run, running and finished. If that's it, perhaps one could
add methods isReady and didRun (a getState method would probably be
better if there are more states, but then one has to deal with magic
I realize it is a common Python paradigm to assume something will work
(such as starting the thread) and catch the exception if it doesn't, but:
- this is tricky if the exception is not documented
- sometimes one simply wants to know, without actually starting the
> Some of these may even be bad ideas apon further
> thought, but it's something to ponder.
Also, many of them don't work with the proposed
syntax. Specifically, you're trying to provide
a second binding for the function (such as running
for __main__, or registering with the exit handler).
For me, this is the most common use case, but ...
PEP 318 doesn't handle it. (Which is one reason
that I don't think this will be the *last* extension,
which is one reason I don't want *bare* syntax.)
> Quixote'd PTL uses almost this exact syntax to
> distinguish between PTL functions/methods which
> return HTML or plain text. The only difference
> is that it places the annotation before the argument
> def head [html] (title):
> I haven't heard any Quixote users complain about the
But they do warn you that it doesn't quite work with
standard python. Nobody comes across this syntax until
they have gone out of their way to expect it. Even so,
would it be better or worse for them to start finding
code that says
def head [classmethod] (title):
I realize that the new syntax (patch version) would
actually say something more like
def head [html](title)[classmethod]:
which goes a fair way toward exhausting special syntax.
If they want to get more detailed (xml vs html, only
do this if the user is authenticated, etc), then the
new syntax starts to be useful to them as well.
def head(title) decorators[html4, authenticated_user]:
Even if the two cases are combined, I don't see it
as useful enough to use up bare syntax. (And so I
suggest yet another possible keyword, "decorators")
> C# allows the wrapping of attributes, not just
> functions and classes.
> In Python this could be accomplished if we used
> delimiters that didn't look like lists (e.g. <> or [! !]).
Do this sort of thing often enough, and you have a
keyword anyhow -- it just happens to look like line noise.
> C# distinguishes between bareword declarations like
> "public" and "int" and metadata attachments like
> XML serialization information.
> The Java way does make clear what is a language builtin
> ("public", "void") and what is extension metadata
> "@remote", "@debug". That may not be a bad thing...
Unless we define a specific list (just classmethod and
staticmethod?), then this might be more confusing than
useful. in __builtins__? In the current standard library?
in another module that might become standard someday?
> If anything, features which are expected to be used by
> more advanced users should require less "COBOL" to be
> useful. I'm not arguing that the zen of Python shouldn't
> apply, just that advanced features (which will probably
> be used a lot less than more basic features) don't
> necessarily need quite the English-like structure supporting
> them in the language syntax.
Features which are used frequently need to be short.
Features which are used rarely (like this one?) can be
I agree that if only advanced users will need it, then it
can be a bit more complex to use. It should absolutely
not be harder to recognize as irrelevant.
If you use an almost meaningless keyword like
"extended_syntax_form_a", then the only extra burden is
on the advanced users who actually use it. (This is one
reason that I'm not too concerned over *which* keyword
gets used.) If you use bare syntax, then the burden is
on everyone, and you have raised the barrier to entry for
the rest of the language.
> Exactly. As a beginner, classes were more advanced than
> you needed. So the (relative) difficulty of finding the
> relevant details wasn't an issue - you just didn't use
> the feature for a while. By the time you needed classes,
> you were familiar enough with Python to know where to look.
I have never *needed* classes, and have a bias towards
functions. If *functions* had seemed awkward, I would have
chosen another language instead. People with a bias
towards objects - or wanting to learn about them - may
well have different criteria. (In real life, most
object systems are pretty wordy, so this particular concern
may not bother OO folk as much. But the main use cases are
At 02:12 PM 2/26/04 -0500, Jewett, Jim J wrote:
> >> Also, many of them don't work with the proposed
> >> syntax. Specifically, you're trying to provide
> >> a second binding for the function (such as running
> >> for __main__, or registering with the exit handler).
> >> For me, this is the most common use case, but ...
> >> PEP 318 doesn't handle it. (Which is one reason
> >> that I don't think this will be the *last* extension,
> >> which is one reason I don't want *bare* syntax.)
> > Sorry, but you understate the capabilities of this new
> > syntax and overestimate the need for future related syntax.
>Not really; I guess I should have left in the full original
> def foo[__main__]:
>will not work.
and it will indeed work. Just try it:
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> def __main__(f):
>>> def foo(): print "testing"
>>> foo = __main__(foo)
<function foo at 0x00A9E990>
__main__ could be defined in another module and imported. It's not
specific to a particular main function. It simply runs the function if
it's defined in the main program module. And in either case, it returns
the original function, so that if the module is not "main", then the
function is still available for importing.
Thus, the 'foo' function would still be the 'foo' function, but it would
also be run if it was the main module. The only remaining downside I see
is that foo() could not call itself recursively, since it can run before
the name 'foo' is bound to it.
>> Also, many of them don't work with the proposed
>> syntax. Specifically, you're trying to provide
>> a second binding for the function (such as running
>> for __main__, or registering with the exit handler).
>> For me, this is the most common use case, but ...
>> PEP 318 doesn't handle it. (Which is one reason
>> that I don't think this will be the *last* extension,
>> which is one reason I don't want *bare* syntax.)
> Sorry, but you understate the capabilities of this new
> syntax and overestimate the need for future related syntax.
Not really; I guess I should have left in the full original
will not work.
Yes, you can first define a decorator function specific to
this particular function you're about to define, just as you
can currently rebind the functions's name to a transform of
the function. Both are ugly.
>> I realize that the new syntax (patch version) would
>> actually say something more like [for Quixote]
>> def head [html](title)[classmethod]:
> in theory the proposed new syntax is enough to accommodate
> Quixote's domain specific language **without the need for a
> custom grammar**.
Agreed. If it weren't for backwards compatibility, they could
just migrate to the new version entirely. My point isn't that
both are needed; my point is that using up unnamed syntax can
come back to bite you later. (In fairness, this is also a
slight knock against "as", which could just as easily mean
"alias" - which I find a more common use case. But "as" is
OK if the proponents really want something short.)
>> Features which are used frequently need to be short.
>> Features which are used rarely (like this one?) can be
>> more verbose.
>> I agree that if only advanced users will need it, then it
>> can be a bit more complex to use. It should absolutely
>> not be harder to recognize as irrelevant.
> The problem is that advanced users will need it /quite/
> frequently :)
Fair enough; then it is reasonable to use an obscure
abbreviation, so long as it isn't obscure enough to
be mistaken for possibly normal usage. Use "X" as the
magic keyword if you want. (Though even "as" is better.)
> I don't think it's a burden on the rest of the language,
> I just think it's a burden on newbies who try and read
> advanced code. They'll probably be confused by what it
> does, anyway.
I haven't seen much in the way of difficulty-graded
indices of sample code. A common introduction to a new
language is to have a specific problem, and to hear that
package X solves it. If package HyperMetaConfusing is
the package that solves the problem, then it is the first
package new users will look at.
>> If *functions* had seemed awkward, I would have
>> chosen another language instead.
> Classes are currently so much more preferable to
> functions because it's easier to make them carry
> around lots of beautiful wonderful metadata.
For me, the advantage is that they save state.
I understand that others use them very differently;
my main point is that adding syntax to something I
consider crucial (functions) is more of a problem
(for me) than adding it to something that I don't
If this transform applied only to class methods, it
would not have put newbie-me off, because those aren't
as basic. (I don't suggest this artificial distinction;
I only point out that it affects the "cost" of the
I am willing to bet that most programmers (and non-
programmers starting with python as a first language)
will believe that they need to learn functions. So
function syntax should be as transparent as possible.