Terry Reedy wrote:
> Among other things, I looked to see if there were currently a free trial
> period for Eve, as there sometines is for online games. If I were to try
> it, and it ran smoothly for some time without lags and crashes (which I
> have experience of), then that would suggest that the tools (including
> Stackless) and use thereof were adequate to the task. If not, that
> something (though not necessarily Stackless) would be shown lacking.
Let me pop my head up for a second.
You won't see Stackless do anything (from a user's perspective) that can't be
done without Stackless. Stackless (like generators) just makes some things
Basically, any state machine(s) with complex internal state (and relatively
simple events) will be much more straightforward to write in Stackless. Put
another way (if you don't think in terms of "state machines"), if you've got
callbacks onSomething(...) where a lot of the code is concerned with where
you are in a complex interchange, it will be much easier in Stackless.
I can't speak to the new Stackless, but in 2000 I did a proprietary,
commercial app for Avid that used Stackless (and lots of C extensions). It
went through Avid's QA, so it would not have been released if it crashed.
The Mac OS8/9 port was difficult, but not because of Stackless.
 Though perhaps you can do more / quicker, because of more efficient memory
usage than an implementation using threads.
#- I'd like to get an announcement written and posted today. No one has
#- objected to Saturday, so that's the date I'll use.
I liked to don't put this on #python. #python-bugday seems a good name.
> I still hate
> the most popular proposal (def foo(args) [decorators]: body) and my
> own proposal is unpopular.
Just one voice here, but I was initially opposed to your proposal,
and favored the above-mentioned popular proposal. But as I played
around with your proposed syntax, it grew on me, and I'm now a
supporter your approach.
> I just want to suggest that we put
> this off and get 2.4 on the road without any decorator syntax at all.
> What do people think of that?
It's fine with me if we put it off. Obviously others have already
posted saying that they'd rather have the feature (at least FUNCTION
decorators... other decorators seem to be less in demand), regardless
of the syntax. As for me, I'd rather prefer to get the syntax "right"
even if it means delaying another release... but that's because I
don't have a project that is in desperate need of decorators.
I like the *idea* of releasing one syntax and reserving the right
to change syntax later (via warnings or something). But I don't
believe it is possible in the real world.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
I've removed the pcre module, unused since Python 1.6, from CVS HEAD.
Should I try to edit the various build files in PC/ and PCbuild/ to
remove it, or should that be left to the Windows-based developers
(Tim, Thomas Heller, Martin)?
For the impending 2.4alpha1 release, a coordinated effort to reduce
the bug backlog would be good. Several other projects (Zope, GNOME,
Mozilla) have "bug days" in which people meet on IRC and go through
the bug database, closing irrelevant or incorrect reports, writing
small test cases for vague reports, etc.
Holding a Python bug day seems worth a try. I've written up a Wiki
page, http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin
planning a bug day and to figure out what tools (if any) are required.
Please comment, particularly if you've participated in bug days for
Zope or other projects. Do we need transcripts of the IRC channel?
Should we use #python or a new channel?
If the details can get sorted out in time, perhaps we can have a bug
day as soon as this weekend. Is a weekend day better than a weekday
for people who are interested in participating?
This is a pre-announcement that the first alpha of Python 2.4
is about a month away. The purpose of this notice is to give
people a heads up - if you have a bug that you want to see
fixed for 2.4, start looking at it now.
Fixes are welcome through the release cycle, although after
the first beta fixes that result in a change to behaviour
will be much less likely to be accepted.
So, if you have a bug you want to see fixed, what should you do?
- If it's not logged on SF, log it.
- If it's logged, consider adding a patch that fixes the problem,
or at least a simple test case that demonstrates the bug.
- If someone else has supplied a fix, see if this fix works for
you, and post your results to the bug.
- If there's a working fix, feel free to add a note asking for
the fix to go into CVS. The SF bug tracker for Python has a
_lot_ of bugs in it, and it's easy for bugs to be overlooked.
If you're just interested in what's coming up in 2.4, see the
current development version of the "What's New in 2.4" document
On behalf of the python-dev team, thanks!
[This form of pre-announcement will hopefully become a part of
the release process for all future releases of Python, both
major and bugfix releases, to give people a chance to get their
bugfix-of-choice submitted in time. Any feedback on this process,
please feel free to email me]
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
> On Mon, May 31, 2004, Robert Brewer wrote:
> > Quite similar to my current "pet peeve":
> > >>> None > 3
> > False
> > >>> None > 'hoopy'
> > False
> > >>> None > True
> > False
> > >>> None > datetime.date(2004, 5, 31)
> > Traceback (most recent call last):
> > File "<interactive input>", line 1, in ?
> > TypeError: can't compare datetime.date to NoneType
> > ...writing an O-R mapper, this particular hobgoblin bites
> me rather often ;)
> Time for you to bite the bullet. Guido has all-but-decreed that the
> future of comparisons is that TypeError will be raised for
> all operators
> other than == and <> for types that have no appropriate relationship
...which is fine. I'll end up either disallowing None as a legal value,
or making a NO_VALUE singleton for which I can customize comparisons.
Either is a better design choice IMO; I just haven't been forced into
the choice yet. ;)