there's a new PEP 278 plus an accompanying patch available on
the subject of universal newline support (the ability to read
and import files that use a different newline convention than
what the current platform uses).
Please read, apply, try, provide feedback and put me back to work:-)
- Jack Jansen <Jack.Jansen(a)oratrix.com>
- If I can't dance I don't want to be part of your revolution --
Emma Goldman -
> I just logged into Sourceforge. Now every time I visit a page, although
> that page displays, I also get username/password popup saying the document
> is locked and giving a server message of "foo". Any idea where this came
> from? Perhaps a test on SF they forgot to undo before putting some pages
> into production?
Haven't noticed that, but sf is being nice and snappy this morning,
isn't it? It seems to take five minutes for a bug report to finish
displaying. Argh! <thump> <thump> <thump>
$ head -n 2 src/bash/bash-2.04/unwind_prot.c
/* I can't stand it anymore! Please can't we just write the
whole Unix system in lisp or something? */
-- spotted by Rich van der Hoff
I just logged into Sourceforge. Now every time I visit a page, although
that page displays, I also get username/password popup saying the document
is locked and giving a server message of "foo". Any idea where this came
from? Perhaps a test on SF they forgot to undo before putting some pages
My client is trying to build a version of Python on Windows with Tkinter and
pymalloc enabled, and threads disabled (in part because pymalloc is not
thread-safe). There appears to be a bug in _tkinter.c:EventHook. It has
#if defined(WITH_THREAD) || defined(MS_WINDOWS)
tcl_tstate = event_tstate;
result = Tcl_DoOneEvent(TCL_DONT_WAIT);
tcl_tstate = NULL;
if (result == 0)
result = Tcl_DoOneEvent(0);
It seems on the surface that the "|| defined(MS_WINDOWS)" bit should be
deleted. This code dates from 1998 and comes with this log text:
date: 1998/06/13 13:56:28; author: guido; state: Exp; lines: +26 -6
Fixed the EventHook() code so that it also works on Windows, sort of.
(The "sort of" is because it uses kbhit() to detect that the user
starts typing, and then no events are processed until they hit
Also fixed a nasty locking bug: EventHook() is called without the Tcl
lock set, so it can't use the ENTER_PYTHON and LEAVE_PYTHON macros,
which manipulate both the Python and the Tcl lock. I now only acquire
and release the Python lock.
(Haven't tested this on Unix yet...)
This suggests that Guido was (rightly) worried about the case of threading
on Windows. What about a non-threaded interpreter on Windows?
Hi. Thanks to http://www.pythonware.com/daily/
I landed in
Peter Norvig is about to supply
Python versions of the algorithms with
the 2nd edition of his AI: A Modern Approach.
So far, so good. In the section about
coding convetions he says:
¦In general, follow Guido's style conventions,
¦but I have some quirks that I prefer (although I could be talked out of them):
¦* _ instead of self as first argument to methods: def f(_, x):
I'm perfectly aware that the 'self' thing it is just a convetion,
OTOH much of the cross-programmer readability
of code relies on such convention.
It is good, bad or irrelevant to have such
an authoritative book (although about AI not
Python directly) adopting such a line-noisy
Maybe nobody cares, but I preferred not to
let this go unnoticed. Someone who cares
could try to discuss the issue or make it
apparent to Mr. Norvig.
regards, Samuele Pedroni.
>>> Peter Norvig wrote
> That may be a good analogy, and as I said, I'm willing to try. But I
> still think one character is easier to ignore than four, and that there
> is no compelling argument for 'self' over '_', while there is a positive
> reason for parens (ease of automated parsing tools).
The primary arguments against '_' are that it already has meaning. I can
think of three, off the top of my head.
Interactive mode uses this as "result of last expression".
The i18n code uses it as a function _('translate me').
Zope uses it in DTML (python) expressions as the default namespace.
I'd also add the subjective argument that it's ugly, and looks far too
magical and perl-like. I don't _want_ it to disappear into the background,
as it's going to cause me pain if I miss it.
Neal Norwitz <neal(a)metaslash.com> writes:
> Currently, I think there are 2 or 3 warnings which definitely fit this class:
> No global found, using ++/--, and expressions with no effect as Jason
It would sure be nice if using a variable before assignment produced a
warning at compile time. However I think this needs flow analysis and
you won't catch me trying to add that to compile.c.
MGM will not get your whites whiter or your colors brighter.
It will, however, sit there and look spiffy while sucking down
a major honking wad of RAM. -- http://www.xiph.org/mgm/
I think that if we're going to do string interpolation we might as go
all of the way and have one unified string interpolation model.
1. There should be no string-prefix. Instead the string \$ should be
magical in all non-raw literal strings as \x, \n etc. are. (if you want
to do string interpolation on a raw string, you could do it using the
method version below)
>>> from __future__ import string_interp
>>> a = "acos(.5) = \$(acos(.5))"
Embrace the __future__!
2. There should be a transition period where literal strings containing
"\$" are flagged. This is likely rare but may occur here and there. And
by the way, unused \-sequences should probably be proactively reserved
now instead of silently "failing" as they do today. What's the use of
making "\" special if sometimes it isn't special?
3. I think that it would be clearest if any expression other than a
simple variable name required "\$(parens.around.it())". But that's a
4. Between the $-sign and the opening paren, it should be possible to
put a C-style formatting specification.
"pi = \$5.3f(math.pi)".
There is no reason to force people to switch to a totally different
language feature to get that functionality. I never use it myself but
presume that scientists do!
5. The interpolation functionality is useful enough to be available for
use on runtime-generated strings. But at runtime it should have a
totally different syntax. Now that Python has string methods it is clear
that "%" could (and IMO should) have been implemented that way:
newstr = mystr.interp(variabledict, evaluate_expressions=0)
By default evaluate_expressions is turned off. That means that all it
does is look up variables in the dictionary and insert them into the
string where it seems \$. If you want full interpretation behaviour you
would flip the evaluate_expressions switch. May Guido have mercy on your
6. People should be discouraged from using the "%" version. Some day
far in the future it could be officially deprecated. We'll tell our
children stories about the days when we modulo'd strings, tuples and
dictionaries in weird and wonderful ways.
Once the (admittedly long) transition period is over, we would simply
have a better way to do everything we can do today. Code using the new
model will be easier to read, more concise, more consistent, more like
other scripting languages, abuse syntax less and use fewer logical
concepts. Arguably, functions like vars(), locals() and globals() could
be relegated to an "introspection" module where no newbie will ever look
at them again. (okay, now I'm over-reaching)
There will undoubtedly be language-change backlash. Guido will take the
heat, not me. He would have to decide if it was worth the pain. I think,
however, that the resulting language would be an improvement for experts
and newbies alike. And as with other changes -- sooner is better than
later. The year after next year is going to be the Year of Python so
let's get our changes in before then!
For some technical reasons we have partially lost our Data Bank of art galleries.
Please, write the address of your website, so that we could continue our
Our site is http://www.gallery-a.ru/