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,
soon.
How to attend?
See bottom of this message.
Contents?
Well, there is a lot possible.
Current topics which come into mind are
* autoscheduling
* 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.
Level?
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.
Usability?
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 :-)
Payback?
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.
Coaching?
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.
Fun?
Guaranteed.
Schedule
--------
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.
Accomodation
------------
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
stackless-sprint(a)stackless.com
which you can find via this interface:
http://www.stackless.com/mailman/listinfo/stackless-sprint
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:tismer@stackless.com>
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]:
pass
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.)
-jJ
rhettinger(a)users.sourceforge.net writes:
> 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?
Thomas
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
feature.
Paul.
Raymond,
You asked:
> * 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
usual formula.
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
http://www.mcs.vuw.ac.nz/~vignaux
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
constants).
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
thread
-- Russell
Pete Shinners:
> 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.)
Skip:
> 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
> list:
> def head [html] (title):
> I haven't heard any Quixote users complain about the
> construct.
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")
Paul Prescod:
> 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?
Skip Montanaro:
> 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
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.
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.
Paul Moore:
> 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
for functions.)
-jJ
Patch / Bug Summary
___________________
Patches : 243 open ( +2) / 2319 closed ( +4) / 2562 total ( +6)
Bugs : 728 open (+17) / 3904 closed (+12) / 4632 total (+29)
RFE : 130 open ( +3) / 119 closed ( +1) / 249 total ( +4)
New / Reopened Patches
______________________
Add Py_InitializeEx to allow embedding without signals. (2004-02-19)
http://python.org/sf/900727 opened by Dave Wilson
catch invalid chunk length in httplib read routine (2004-02-20)
http://python.org/sf/900744 opened by Wummel
markupbase misses comments (bug 736659) (2004-02-20)
http://python.org/sf/901369 opened by Jim Jewett
urllib2.parse_http_list bugfix 735248 (2004-02-20)
http://python.org/sf/901480 opened by Jim Jewett
FreeBSD new pthread problem with system scope (2004-02-23)
http://python.org/sf/902444 opened by Hye-Shik Chang
dict.update should take a 2-tuple sequence like dict.__init_ (2004-02-25)
http://python.org/sf/904720 opened by Bob Ippolito
Patches Closed
______________
bdist_wininst pre-install script, and --target-version fix (2004-02-08)
http://python.org/sf/892660 closed by theller
logging says to call shutdown - make it more likely (2004-01-21)
http://python.org/sf/881676 closed by vsajip
Refactored patch #815911 for logging with SocketHandler (2003-12-01)
http://python.org/sf/851993 closed by vsajip
Extension logging.handlers.SocketHandler (2003-10-01)
http://python.org/sf/815911 closed by vsajip
New / Reopened Bugs
___________________
Duplicated <link rel="next"> in <head> (2004-02-18)
http://python.org/sf/899423 opened by Joseph Walton
1==float('nan') (2004-02-17)
http://python.org/sf/899109 reopened by mwh
optparse: usage issues (2004-02-19)
http://python.org/sf/900071 opened by Simon Dahlbacka
hotshot.stats.load (2004-02-19)
http://python.org/sf/900092 opened by Simon Dahlbacka
cgi.fieldStorage doesn't grok standards env. variables (2004-02-19)
http://python.org/sf/900112 opened by Dominique Hazaël-Massieux
win shell interpreter error (arithmetic) (2004-02-19)
http://python.org/sf/900494 opened by Mark Okamura
IDLE docs broken on OSX (2004-02-19)
http://python.org/sf/900580 opened by Jonathan Brandmeyer
add logging.shutdown() to python logging module example code (2004-02-19)
http://python.org/sf/900626 opened by Manuel Schulte
urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr (2004-02-20)
http://python.org/sf/900898 opened by James Kruth
plat-mac/videoreader.py not working on OS X (2004-02-20)
http://python.org/sf/900949 opened by Dinu C. Gherman
cygwinccompiler.get_versions fails on `ld -v` output (2004-02-20)
http://python.org/sf/900977 opened by Pearu Peterson
strange behaviour of xmlrpclib.Server proxy (2004-02-20)
http://python.org/sf/901198 opened by Andreas Eisele
random.randint fails for some ranges (2004-02-20)
http://python.org/sf/901285 opened by paul rubin
logging handlers can close without flush (2004-02-20)
http://python.org/sf/901330 opened by Jim Jewett
random.seed not initialized as advertised (2004-02-21)
http://python.org/sf/901605 opened by paul rubin
split method documentation can be improved (2004-02-21)
http://python.org/sf/901654 opened by Sjoerd Mullender
extra_path kwarg to setup() undocumented (2004-02-21)
http://python.org/sf/901727 opened by Bob Ippolito
relative on-disk SYSTEM id handling is incorrect (2004-02-22)
http://python.org/sf/902037 opened by Bob Ippolito
pydoc insists upon producing file: URLs (2004-02-22)
http://python.org/sf/902061 opened by Matthias Klose
fails building C++ extensions when configured --without-cxx (2004-02-22)
http://python.org/sf/902065 opened by Matthias Klose
urllib2 should be more robust for sloppy proxy URLs (2004-02-22)
http://python.org/sf/902075 opened by Matthias Klose
Thread start - strange error under Cygwin (2004-02-22)
http://python.org/sf/902151 opened by Artur de Sousa Rocha
Timezone miscalculation (time.mktime) (2004-02-22)
http://python.org/sf/902172 opened by Marti Raudsepp
Encodings: koi8-u.py -- errata in decoding map (2004-02-23)
http://python.org/sf/902501 opened by Alexander Belchenko
doctest confused by super-instances in class-dicts (2004-02-23)
http://python.org/sf/902628 opened by Christian Tanzer
help("exec") doesn't work (2004-02-23)
http://python.org/sf/902998 opened by Tom Lynn
OpenVMS file system and UNIVERSAL_NEWLINES support (2004-02-24)
http://python.org/sf/903339 opened by Piéronne Jean-François
cPickle/pickle incompatibility (2004-02-24)
http://python.org/sf/903483 reopened by tismer
File read of Chinese utf-16-le treats upper byte 1A as EOF (2004-02-25)
http://python.org/sf/904474 opened by Ron Rother
threading docs, start error should be specified (2004-02-25)
http://python.org/sf/904498 opened by Russell Owen
test_tcl fails -- "can't find package Tclx" (2004-02-26)
http://python.org/sf/905046 opened by Michael Hudson
Bugs Closed
___________
1==float('nan') (2004-02-17)
http://python.org/sf/899109 closed by mwh
win shell interpreter error (arithmetic) (2004-02-19)
http://python.org/sf/900494 closed by tim_one
add logging.shutdown() to python logging module example code (2004-02-19)
http://python.org/sf/900626 closed by vsajip
logging.shutdown() exception (2003-11-14)
http://python.org/sf/842170 closed by vsajip
random.randint fails for some ranges (2004-02-20)
http://python.org/sf/901285 closed by rhettinger
logging handlers can close without flush (2004-02-20)
http://python.org/sf/901330 closed by vsajip
random.seed not initialized as advertised (2004-02-21)
http://python.org/sf/901605 closed by rhettinger
Incorrect ZeroDivisionError message with __future__ division (2004-01-26)
http://python.org/sf/884841 closed by rhettinger
Timezone miscalculation (time.mktime) (2004-02-22)
http://python.org/sf/902172 closed by sipsick
Encodings: koi8-u.py -- errata in decoding map (2004-02-23)
http://python.org/sf/902501 closed by lemburg
help("exec") doesn't work (2004-02-23)
http://python.org/sf/902998 closed by tlynn
cPickle/pickle incompatibility (2004-02-24)
http://python.org/sf/903483 closed by tismer
codecs.open().readlines(sizehint) bug (2003-11-18)
http://python.org/sf/844561 closed by lemburg
bsddb btree set_location() semantics changed (2003-08-13)
http://python.org/sf/788421 closed by greg
New / Reopened RFE
__________________
bundlebuilder: some way to add non-py files in packages (2004-02-19)
http://python.org/sf/900502 opened by Russell Owen
bundlebuilder: an arg to disable zipping the code (2004-02-19)
http://python.org/sf/900506 opened by Russell Owen
bundlebuilder: easily keep main routine in orig location (2004-02-19)
http://python.org/sf/900514 opened by Russell Owen
cPickle/pickle incompatibility (2004-02-24)
http://python.org/sf/903483 opened by Christian Tismer
http://doc.python.org (2004-02-25)
http://python.org/sf/904770 opened by Bob Ippolito
RFE Closed
__________
Enable __slots__ for meta-types (2003-03-02)
http://python.org/sf/696184 closed by tismer
At 02:12 PM 2/26/04 -0500, Jewett, Jim J wrote:
>Jim Jewett:
> >> 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.)
>
>Bob Ippolito:
> > 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
>example.
>
> def foo[__main__]:
>
>will not work.
You mean:
def foo()[__main__]:
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):
if f.func_globals['__name__']=='__main__':
f()
return f
>>> def foo(): print "testing"
>>> foo = __main__(foo)
testing
>>> 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.
Jim Jewett:
>> 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.)
Bob Ippolito:
> 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
example.
def foo[__main__]:
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.
Jim Jewett:
>> I realize that the new syntax (patch version) would
>> actually say something more like [for Quixote]
>> def head [html](title)[classmethod]:
Bob Ippolito:
> 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.)
Jim Jewett:
>> 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.
Bob Ippolito:
> 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.
Jim Jewett:
>> If *functions* had seemed awkward, I would have
>> chosen another language instead.
Bob Ippolito:
> 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
consider crucial.
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
change.)
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.
-jJ
