Eric Kidd thinks so:
Here's an excerpt:
[...] there's a subtle bug in the Python design. Consider tree
if (t.left != None):
for (node in inorder(t.left)):
if (t.right != None):
for (node in inorder(t.right)):
If you study this carefully, you'll see that (unless the optimizer
intervenes), Python has turned a perfectly good O(N) tree traversal
into an O(N log N) traversal.
This seems to be my week to ask simple, stupid questions.
Is there any good semantic or philosophical reason that these aren't legal?
>>> "ab" in "cabcd"
>>> "xy" in "cabcd"
>>> (1, 2) in (0, 1, 2, 3)
>>> (9, 8) in (0, 1, 2, 3)
Proposed -- the following definition of "in" as a binary operation on
sequence types: a is "in" b if a occurs as a subsequence of b.
I'd like to see Python support this mainly to get rid of the following
common but ugly idiom:
if b.find(a) > -1:
# Do one thing
# Do another
It's really easy to forget and miscode the guard "if b.find(a):".
By contrast, see how much clearer this is:
if a in b:
# Do one thing
# Do another
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
I don't like the idea that the police department seems bent on keeping
a pool of unarmed victims available for the predations of the criminal
-- David Mohler, 1989, on being denied a carry permit in NYC
I'm probably just too tired to be looking at this right now, but I'm having
no luck figuring out just where local variables are initialized. In 1.5.2
eval_code2 is called with all the bits and pieces needed to create a frame
and does so. In 2.1 eval_frame is called with an already initialized frame.
Either way I expected to see a call to PyFrame_LocalsToFast in or around
PyFrame_New, but the places where I see it don't seem like the logical place
(to my misfiring brain anyway).
Any pointers appreciated,
Paul Prescod <paulp(a)ActiveState.com> writes:
> Neil Bauman asked him why Perl wasn't being written in Perl (Neil's
> opinion is that Perl is literally the greatest language ever
> created). Damian responded with a great quote: "Performance. If
> Performance wasn't an issue, I'd probably write Perl 6 in Python or
> something like it with wonderfully beautiful OO abstractions and it
> would run like a dog."
Tell them to use ocaml.
You have run into the classic Dmachine problem: your machine has
become occupied by a malevolent spirit. Replacing hardware or
software will not fix this - you need an exorcist.
-- Tim Bradshaw, comp.lang.lisp
I noticed a bsddbmodule report today and checked it out. An anonymous
submitter had reported a bug with bsddbmodule.c. Martin responded with "try
--without-libdb" and asked the person to report whether that helped. Two
weeks later, after no response from the submitter (how would he have seen
it?), Jeremy closed the bug.
That was the right thing to do under the circumstances, but I would if
there's some way to not allow anonymous bug reports and patches. It seems
almost impossible to actually get a response back to the submitter in such
cases, so I don't see how you can have a useful dialog about the
On Fri, Aug 24, 2001 at 11:32:08AM -0700, Barry Warsaw wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory usw-pr-cvs1:/tmp/cvs-serv13719/Objects
> Modified Files:
> + end:
> + _PyString_Resize(&string, s - PyString_AsString(string));
You could use: s - PyString_AS_STRING(string)
Greg Stein, http://www.lyra.org/
Tim Peters <tim_one(a)users.sourceforge.net> writes:
> ! /* XXX Warn if (supplied_flags & PyCF_MASK_OBSOLETE) != 0? */
I think not.
If, as I *think*, all code objects compiled in 2.2 have
ob.co_flags & __future__.nested_scopes.compiler_flag
non-zero, then, eg., idle will compile all code typed interactively
(after the first line, anyway) with
__future__.nested_scopes.compiler_flag in the supplied_flags argument
to compile(). This could be wormed around, obviously, but I don't see
Michael Hudson <mwh(a)python.net> writes:
> Reminds me of what Laura Creighton said about the results of her
> case-sensitivity survey.
As Aahz has reminded me, it was Sheila King.
languages shape the way we think, or don't.
-- Erik Naggum, comp.lang.lisp