comp.lang.python - 26 new messages in 5 topics - digest

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

* python 3's adoption - 12 messages, 4 authors
http://groups.google.com/group/comp.lang.python/t/69463c4b9b1ecd8f?hl=en
* myths about python 3 - 9 messages, 6 authors
http://groups.google.com/group/comp.lang.python/t/8b8f4a9f999e33e8?hl=en
* Updating form action attribute with mechanize.Browser - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/f952a4cecda87263?hl=en
* Stuck on a three word street name regex - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.python/t/76a4ab9fd7279a4e?hl=en
* CodeInvestigator testers - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/e19d3e1df29698e6?hl=en

==============================================================================
TOPIC: python 3's adoption
http://groups.google.com/group/comp.lang.python/t/69463c4b9b1ecd8f?hl=en
==============================================================================

== 1 of 12 ==
Date: Wed, Jan 27 2010 3:51 pm
From: Jonathan Gardner

On Jan 27, 9:38 am, Luis M. González <luis...@gmail.com> wrote:
> > Please don't post more noise and ad hominem attacks to the group, Steve.
>
> "Ad hominem"?
> Please, operor non utor lingua non notus per vulgaris populus.
> Gratias ago vos...

My rough, machine-assisted translation:

"Don't try to use language that the people don't know. Thanks."

== 2 of 12 ==
Date: Wed, Jan 27 2010 3:54 pm
From: Jonathan Gardner

On Jan 26, 10:12 pm, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.au> wrote:
>
> I did too, when I first heard cmp was to be dumped. But I changed my mind
> and now agree with the decision to drop cmp. Custom sorts are nearly
> always much better written with key rather than cmp: key adds an O(N)
> overheard to the sorting, while cmp makes sorting O(N**2). In other
> words, key is *much* faster, and generally easier to write as well.
>

Imagine what sort() could do if all the keys were platform-native
types. In other words, if you could bypass the Python compare because
all the keys were native int, char, char*, or float. You can't do that
with cmp either.

== 3 of 12 ==
Date: Wed, Jan 27 2010 3:54 pm
From: Paul Rubin

Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:
> always much better written with key rather than cmp: key adds an O(N)
> overheard to the sorting, while cmp makes sorting O(N**2).

Whaaaaaaaaaa ...... ???? No I don't think so.

== 4 of 12 ==
Date: Wed, Jan 27 2010 4:12 pm
From: Jonathan Gardner

On Jan 27, 12:36 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
> > Without becoming a purely functional language, you won't get rid of all
> > statements.
>
> Why not?  GCC lets you use any statement in an expression:
>
>     #include <stdio.h>
>
>     main()
>     {
>       int i, x, p=0;
>       x = ({ for (i=1; i<=10; i++) p += i; p;});
>       printf ("x=%d\n", x);
>     }
>
> and C is certainly not a purely functional language.
>
> > for, while, if, try, break, yield, return
> > are all used for flow control, and should remain as statements.
>
> What about assert, import, and pass?

I think you missed the point about what a functional language is and
is not.

Let me see if I can help clear up that confusion a bit.

In a functional language, you don't use statements. For instance, when
you declare a new function, you call the function-declaring-function
with parameters describing the parameters and body of that function.

In such a language, flow control is very, very strange for those not
familiar with it. For instance, how can you call an "if" function that
only evaluates one or the other branches? In such a case, you're not
making a function call, at least not as you know it. What you're doing
is calling a special kind of function that doesn't evaluate its
parameters until later, if at all.

With the above paradigm, you have to start thinking about the
programming task in a completely different light. Rather than
organizing your code into a sequence of evaluated statements, you
organize it into one giant function that will evaluate its parameters
and return some result. This is a difficult paradigm for programmers
to grasp, and is one reason why Lisp and other functional languages
aren't know for being newbie-friendly.

Whether or not a statement can be used as an expression is really
orthogonal to this conversation.

If "yield", "break", and "continue" were functions, then you could
"call" them from within another function and have the call-ee yield,
break, or continue. For instance:

def do_something():
break()

while 1:
do_something()
# The next line is never reached
do_something_else()

This could be useful for some situations, but it is really, really
confusing and so it's not allowed. Such a function would have to rely
on some type of magic so that it is correctly identified as a yield,
break, or continue, and not a typical function call.

"import" is another case. It does something very special. It assigns
to values in the namespace of the code from which it was called. No
function can do that, at least not without some weird magic. It's
better to leave it as a statement and teach new users that it is very,
very special, than to redefine how functions work with the call-ees
namespace, or make it a common task to muck with such things.

If "while", "for", "try", "if", "def", and "class" were functions,
they would have to be written like so:

if(expr, if-true-expr, if-false-expr)

Note, however, that you can't execute if-true of if-false until AFTER
the if() function is called. That means either we re-define what it
means to call a function, or we have some notation that means "Don't
execute this yet". Either way, it's really, really confusing.

Also, note that statements allow you to combine many statements into
one. Python's rule is that you can't pass statements to a function,
only expression, so you'd have to re-define how that works to allow
some function that would combine multiple statements together.

In the end, print is a great candidate for a function, while the
others are most definitely not. Adding any of them as functions would
mean other, fundamental aspects of Python would have to be re-defined
as well.

I hope this clears up Steve's point about functional languages.

== 5 of 12 ==
Date: Wed, Jan 27 2010 4:16 pm
From: Jonathan Gardner

On Jan 27, 3:54 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
> > always much better written with key rather than cmp: key adds an O(N)
> > overheard to the sorting, while cmp makes sorting O(N**2).
>
> Whaaaaaaaaaa ...... ????  No I don't think so.

You're referring to the O(N**2) bit, right? I am sure he knew it was O
(N*log(N)), which is still worse than O(N) for key.

If he didn't, well, Python has some fundamental flaws in its basic
sort algorithm.

== 6 of 12 ==
Date: Wed, Jan 27 2010 4:25 pm
From: Paul Rubin

Jonathan Gardner <jgardner@jonathangardner.net> writes:
>> What about assert, import, and pass?
>...
> For instance, how can you call an "if" function ...
> If "yield", "break", and "continue" were functions, ...
> "import" ... does something very special. It assigns
> to values in the namespace of the code from which it was called.
> In the end, print is a great candidate for a function,

Reasonable point about import. "If", "yield", "break", and "continue"
are irrelevant if one accepts the flow control argument, although there
is already expression syntax for "if" and "yield". What about assert
and pass?

> Also, note that statements allow you to combine many statements into
> one. Python's rule is that you can't pass statements to a function,

But if we're going around introducing changes that break things, why not
get rid of that silly restriction?

I don't mind that 3.x is breaking stuff for the sake of improving
things. That's the whole idea of 3.x, after all. What bugs me is that
the improvements are mostly quite superficial, and the breakage seems
often gratuitous. I'd rather see much more drastic changes and
correspondingly much larger improvements.

Right now I rent an apartment in a city where real estate values have
dropped a couple percent in the past few years. So in principle, I
could move to a 2% bigger apartment while paying the same rent, or move
to a similarly sized apartment while paying 2% less. Either of those is
objectively an improvement, but am I going to do it? Hell no--moving
even down the same street is way too big a hassle to even consider doing
it for such a tiny gain. But if the "2%" were replaced by 3x or 5x, the
proposition would be a heck of a lot more attractive, even if I had to
move a larger distance. That's sort of the way I feel about switching
from Python 2.x to 3.x.

== 7 of 12 ==
Date: Wed, Jan 27 2010 4:30 pm
From: Paul Rubin

Jonathan Gardner <jgardner@jonathangardner.net> writes:
> You're referring to the O(N**2) bit, right? I am sure he knew it was O
> (N*log(N)), which is still worse than O(N) for key.

It's O(n log n) for both key and cmp. key is usually more convenient
and usually gives a constant-factor speedup (DSU pattern), but it uses
more memory and there are some types of orderings that it can't handle
without a bunch of contortion.

== 8 of 12 ==
Date: Wed, Jan 27 2010 4:44 pm
From: Carl Banks

On Jan 27, 4:16 pm, Jonathan Gardner <jgard...@jonathangardner.net>
wrote:
> On Jan 27, 3:54 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>
> > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
> > > always much better written with key rather than cmp: key adds an O(N)
> > > overheard to the sorting, while cmp makes sorting O(N**2).
>
> > Whaaaaaaaaaa ...... ????  No I don't think so.
>
> You're referring to the O(N**2) bit, right? I am sure he knew it was O
> (N*log(N)), which is still worse than O(N) for key.
>
> If he didn't, well, Python has some fundamental flaws in its basic
> sort algorithm.

Quicksort is O(N**2) worst case, perhaps that's what he meant. I'm
not sure about timsort but since it's based on quicksort I'd guess it
is O(N**2) or worse, worst case, as well.

Typical case of a sort is still O(N*log(N)) whether using key or cmp.
People recommended against cmp not because of overall algorithmic time
considerations, but because of the number of function calls. cmp
function was called a minimum of N-1 times and typically around N*log2
(N) times, whereas key was called exactly N times. Since the overhead
of a Python function call was very large compared to the built-in cmp
operation, it usually outweighed the algorithmic time considerations.

Carl Banks

== 9 of 12 ==
Date: Wed, Jan 27 2010 4:47 pm
From: Steven D'Aprano

On Wed, 27 Jan 2010 18:29:25 +0100, Alf P. Steinbach wrote:

> The main problem with the incompatibility is for porting code, not for
> writing code from scratch.

Correct. It's a trivial problem, but still a problem.

> It's also a problem wrt. learning the language.

This makes no sense. Why is it harder to learn

print(x, y, z)

than this?

print x, y, z

The first case is like the other functions you have to learn, like len().
In fact, many newbies to Python put unneeded parentheses around arguments
to print simply because they assume it is a function.

I would argue that the new print function is *simpler* to learn. It is
more consistent with other built-ins, and has fewer magic idioms to
learn. Instead of:

print >>fileObj, x, y, z

you use regular function syntax with a meaningful keyword:

print(x, y, z, file=fileObj)

If you want suppress the newline at the end of each print:

print x, y, z, # note the final comma

compared to:

print(x, y, z, end='')

If you want to change the space between elements, instead of:

sys.stdout.write(str(x) + "*" + str(y) + "*" + str(z) + '\n')

you use:

print(x, y, z, sep='*')

If you want to override the behaviour of print in a module, instead of
having to edit the source code of the module (which might not even be
available), all you need to do is monkey-patch it:

import module
module.print = myprint

--
Steven

== 10 of 12 ==
Date: Wed, Jan 27 2010 5:09 pm
From: Steven D'Aprano

On Wed, 27 Jan 2010 00:36:52 -0800, Paul Rubin wrote:

> Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:
>> Without becoming a purely functional language, you won't get rid of all
>> statements.
>
> Why not? GCC lets you use any statement in an expression:

I stand corrected. Whether it is a good idea or not is another story.

>> for, while, if, try, break, yield, return are all used for flow
>> control, and should remain as statements.
>
> What about assert, import, and pass?

Both assert and pass are special and need to be treated specially by the
compiler. Arguably we could replace pass with None, but pass makes the
intent more obvious.

Although assert could be a function, it is treated specially by the
compiler and so making it a statement emphases that it is special.

The regular form of import could easily be a function returning the
module object. After all, that's exactly what __import__ is! But using
__import__ for anything but the simplest cases is quite awkward, hence we
have syntactic sugar in the form of the import statement.

You also missed del as another statement-based command.

All the current statements have good strong reasons for being statements.
print on the other hand lacks a strong reason for being a statement, and
the only good argument against changing is to avoid an incompatible
change. But since it is not a gratuitous incompatible change, the long
term benefit out-weighs the short-term pain, in my opinion.

--
Steven

== 11 of 12 ==
Date: Wed, Jan 27 2010 5:44 pm
From: Steven D'Aprano

On Wed, 27 Jan 2010 16:16:59 -0800, Jonathan Gardner wrote:

> On Jan 27, 3:54 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>> Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
>> > always much better written with key rather than cmp: key adds an O(N)
>> > overheard to the sorting, while cmp makes sorting O(N**2).
>>
>> Whaaaaaaaaaa ...... ????  No I don't think so.
>
> You're referring to the O(N**2) bit, right? I am sure he knew it was O
> (N*log(N)), which is still worse than O(N) for key.
>
> If he didn't, well, Python has some fundamental flaws in its basic sort
> algorithm.

I may have the details wrong, but the performance of sort with cmp is
very poor.

sort with key calls the key function once for each element in the list,
which is O(N), and then sorts O(N*log N), giving a total of O(N*log N).

sort with cmp has to compare the comparison function multiple times for
each element. I *thought* it ended up calling it N times each, giving
O(N**2), but I may be delusional. Whatever it is though, it's quite slow.
Here's my test code (for Python 2.5):

from timeit import Timer
from string import letters
from random import shuffle

def mycmp(s, t):
return cmp(s.upper(), t.upper())

def randstr():
L = list(letters)
shuffle(L)
return ''.join(L)

setup = "from __main__ import mycmp, data"

N = 300
data = [randstr() for _ in xrange(N)]
t1 = Timer("d = data[:]; d.sort()", setup) # raw sort
t2 = Timer("d = data[:]; d.sort(cmp=mycmp)", setup)
t3 = Timer("d = data[:]; d.sort(key=str.upper)", setup)

for t in (t1, t2, t3):
print min(t.repeat(number=500))

N *= 10 # Do it again with bigger N.
data = [randstr() for _ in xrange(N)]
for t in (t1, t2, t3):
print min(t.repeat(number=500))

And here are the results on my PC:

# N = 300
0.0631489753723
2.36756515503
0.226485967636

# N = 3000
1.03457903862
35.3092911243
2.77242517471

This doesn't support my claim of O(N**2), but it does demonstrate that
sort with cmp should be avoided if at all possible.

--
Steven

== 12 of 12 ==
Date: Wed, Jan 27 2010 5:56 pm
From: Steven D'Aprano

On Wed, 27 Jan 2010 16:44:18 -0800, Carl Banks wrote:

>> You're referring to the O(N**2) bit, right? I am sure he knew it was O
>> (N*log(N)), which is still worse than O(N) for key.
>>
>> If he didn't, well, Python has some fundamental flaws in its basic sort
>> algorithm.
>
> Quicksort is O(N**2) worst case, perhaps that's what he meant.

No, apparently I was delusional.

> I'm not
> sure about timsort but since it's based on quicksort I'd guess it is
> O(N**2) or worse, worst case, as well.

timsort is actually a mergesort, not a quicksort.

You may like to read this:

http://svn.python.org/projects/python/trunk/Objects/listsort.txt

> Typical case of a sort is still O(N*log(N)) whether using key or cmp.
> People recommended against cmp not because of overall algorithmic time
> considerations, but because of the number of function calls. cmp
> function was called a minimum of N-1 times and typically around N*log2
> (N) times, whereas key was called exactly N times. Since the overhead
> of a Python function call was very large compared to the built-in cmp
> operation, it usually outweighed the algorithmic time considerations.

Yes, that sounds more like it. Thanks for the corrections.

--
Steven

==============================================================================
TOPIC: myths about python 3
http://groups.google.com/group/comp.lang.python/t/8b8f4a9f999e33e8?hl=en
==============================================================================

== 1 of 9 ==
Date: Wed, Jan 27 2010 3:52 pm
From: falk@mauve.rahul.net (Edward A. Falk)

In article <hjq8l0$ge5$1@reader1.panix.com>,
Grant Edwards <invalid@invalid.invalid> wrote:
>
>That said, I don't expect to start using Python 3 until library
>availability or my Linux distro forces me to.

If python 3 is much more efficient than python 2, or it has features
I really need for some application I'll write in the future, I might
be tempted to switch. Maybe some future version of python 3 will
be compatible with python 2 source code. That would help.

--
-Ed Falk, falk@despams.r.us.com
http://thespamdiaries.blogspot.com/

== 2 of 9 ==
Date: Wed, Jan 27 2010 4:14 pm
From: Ethan Furman

Daniel Fetchinson wrote:
>>> Hi folks,
>>>
>>> I was going to write this post for a while because all sorts of myths
>>> periodically come up on this list about python 3. I don't think the
>>> posters mean to spread false information on purpose, they simply are
>>> not aware of the facts.
>>>
>>> My list is surely incomplete, please feel free to post your favorite
>>> misconception about python 3 that people periodically state, claim or
>>> ask about.
>>>
>>> 1. Print statement/function creates incompatibility between 2.x and 3.x!
>>>
>>> Certainly false or misleading, if one uses 2.6 and 3.x the
>>> incompatibility is not there. Print as a function works in 2.6:
>>>
>>> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
>>> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> print( 'hello' )
>>> hello
>>>>>> print 'hello'
>>> hello
>>>
>>> 2. Integer division creates incompatibility between 2.x and 3.x!
>>>
>>> Again false or misleading, because one can get the 3.x behavior with 2.6:
>>>
>>> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
>>> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> 6/5
>>> 1
>>>>>> from __future__ import division
>>>>>> 6/5
>>> 1.2
>>>
>>>
>>> Please feel free to post your favorite false or misleading claim about
>>> python 3!
>> Well, I see two false or misleading claims just above - namely that
>> the two claims above are false or misleading. They tell just half of
>> the story, and that half is indeed easy. A Python 3 program can be
>> unchanged (in the case of print) or with only trivial modifications
>> (in the case of integer division) be made to run on Python 2.6.
>
> Okay, so we agree that as long as print and integer division is
> concerned, a program can easily be written that runs on both 2.6 and
> 3.x.
>
> My statements are exactly this, so I don't understand why you disagree.
>
>> The other way around this is _not_ the case.
>
> What do you mean?
>
>> To say that two things are
>> compatible if one can be used for the other, but the other not for the
>> first, is false or misleading.
>
> I'm not sure what you mean here. Maybe I didn't make myself clear
> enough, but what I mean is this: as long as print and integer division
> is concerned, it is trivial to write code that runs on both 2.6 and
> 3.x. Hence if someone wants to highlight incompatibility (which surely
> exists) between 2.6 and 3.x he/she has to look elsewhere.
>
> Cheers,
> Daniel
>

I think what Andre is saying is that you can't get 2.x behavior in 3.x,
only the other way 'round.

In the integer division instance, the 2.x behavior of 6/5 = 1 is not
going to happen in 3.x.

~Ethan~

== 3 of 9 ==
Date: Wed, Jan 27 2010 4:19 pm
From: Steven D'Aprano

On Wed, 27 Jan 2010 12:56:10 -0800, John Nagle wrote:

> Daniel Fetchinson wrote:
>> Hi folks,
>>
>> I was going to write this post for a while because all sorts of myths
>> periodically come up on this list about python 3. I don't think the
>> posters mean to spread false information on purpose, they simply are
>> not aware of the facts.
>>
>> My list is surely incomplete, please feel free to post your favorite
>> misconception about python 3 that people periodically state, claim or
>> ask about.
>
> Myths about Python 3:
>
> 1. Python 3 is supported by major Linux distributions.
> 2. Python 3 is supported by multiple Python implementations.
> 3. Python 3 is supported by most 3rd party Python packages.

A myth actually needs to be believed by some sector of the population,
even if a small one. (Isolated nut cases don't count.) Star Wars is not a
myth, because nobody -- not even those wacky people who put down "Jedi"
as their religion on census forms -- actually believes it is a
documentary.

I've never heard anyone claiming any of those three "myths". I conclude
that you just made them up, that they are fictional claims rather than
genuine myths mistakenly believed by some people. So, in that spirit,
here are three more for your collection. Perhaps you could start a list
on a website somewhere.

4. Python 3 will make you irresistible to women.

FALSE - Python 3 coders are no more likely to get a date than any
other programmer.

5. Python 3 programs cannot be buggy, no matter how poorly you code.

FALSE - programs written in Python 3 can contain bugs.

6. The code for Python 3 was handed down to Guido from the Heavens,
carved into stone tablets by the Gods themselves.

FALSE - Python 3 was designed and written by fallible human beings,
and consequently there is no guarantee that it will be perfect in
all ways for all purposes.

> That's the reality, Python 3 fanboys.

Speaks for itself.

--
Steven

== 4 of 9 ==
Date: Wed, Jan 27 2010 4:32 pm
From: Carl Banks

On Jan 27, 2:19 pm, exar...@twistedmatrix.com wrote:
> On 10:07 pm, pavlovevide...@gmail.com wrote:
> >Last I heard, don't remember where, the plan was for Python 2.7 to be
> >the last version in the Python 2 line.  If that's true, Python 3
> >acceptance is further along at this point than anticipated, since they
> >originally thought they might have to go up to 2.9.
>
> This assumes that the decision to stop making new 2.x releases is based
> on Python 3 adoption, rather than on something else.

I should have said, "If anything...".

Carl Banks

== 5 of 9 ==
Date: Wed, Jan 27 2010 4:28 pm
From: Paul Rubin

Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:
> 6. The code for Python 3 was handed down to Guido from the Heavens,
> carved into stone tablets by the Gods themselves.

That is heresy. The direction was up, not down.

== 6 of 9 ==
Date: Wed, Jan 27 2010 4:35 pm
From: Steven D'Aprano

On Wed, 27 Jan 2010 16:25:46 -0500, Benjamin Kaplan wrote:

> When Python 2.6 came out, Jython was still on 2.2. The difference
> between 2.2 and 2.6 is almost as big of a difference as between 2.6 and
> 3.0. In that time, you had the introduction of the boolean type,
> generators, list comprehensions, the addition of the "yield" and "with"
> keywords, universal newline support, and decorators in addition to the
> large number of changes to the standard library such as the introduction
> of the subprocess module.

THANK YOU Benjamin for injecting this note of sanity into the discussion.

I believe that, with the possible exception of the change from byte
strings to unicode strings, virtually *all* the hoo-har over Python 3 is
simply due to the tactical mistake of Guido and the Python Dev team of
*calling* Python 3 a backward incompatible release. Python has had
previous major changes in the past (e.g. 1.5 to 2.0 and 2.1 to 2.2) and
hardly anyone made a complaint.

Certainly the move from 2.x to 3.x is a big move. If you have to support
both series simultaneously, I don't envy your job, but if CherryPy can do
it, so can others. But it's not qualitatively different from supporting
(say) 2.4 through 2.6. Targeting multiple versions is always a PITA.

I also find it telling that perhaps the biggest change of all, the one
from byte strings to unicode, hardly rates a mention from the skeptics
and haters. Instead we get rants about how division behaves differently
(forgetting that "from __future__ import division" has worked since at
least 2.4 and possibly older) and complaints that print is different.

--
Steven

== 7 of 9 ==
Date: Wed, Jan 27 2010 5:36 pm
From: alex23

Terry Reedy <tjre...@udel.edu> wrote:
> Actually, Unladen Swallow is now targeted at 3.1; its developers have
> conservatively proposed its integration in CPython 3.3. I would not be
> completely shocked if it happens in 3.2.

Why do I feel like there's less of an onus on Unladen Swallow to
_actually prove itself in substantial real world usage_ before
integration into CPython than there is on even the smallest of modules
for inclusion in the standard library?

Are we really expected to just ditch everything we know about
CPython's performance characteristics just for some questionable and
possibly uneven gains?

I've been a big supporter of Py3 from the beginning, but this repeated
claim of US becoming the mainline interpreter for 3.x pretty much
kills dead a lot of my interest. What am I not seeing amidst the high
memory usage and variable performance results of US's _custom-made_
benchmarks? Doesn't that fact alone worry anyone else? Or that LLVM is
listed as only having "partial support" with non-Cygwin x86 Windows?

Yes, I'd _love_ Python to be faster, who wouldn't? But I'm not seeing
the evidence here to support the almost unbridled eagerness that's
being demonstrated.

== 8 of 9 ==
Date: Wed, Jan 27 2010 5:46 pm
From: Steven D'Aprano

On Wed, 27 Jan 2010 16:28:08 -0800, Paul Rubin wrote:

> Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:
>> 6. The code for Python 3 was handed down to Guido from the Heavens,
>> carved into stone tablets by the Gods themselves.
>
> That is heresy. The direction was up, not down.

SPLITTER!!!

--
Steven

== 9 of 9 ==
Date: Wed, Jan 27 2010 5:59 pm
From: Carl Banks

On Jan 27, 5:36 pm, alex23 <wuwe...@gmail.com> wrote:
> Terry Reedy <tjre...@udel.edu> wrote:
> > Actually, Unladen Swallow is now targeted at 3.1; its developers have
> > conservatively proposed its integration in CPython 3.3. I would not be
> > completely shocked if it happens in 3.2.
>
> Why do I feel like there's less of an onus on Unladen Swallow to
> _actually prove itself in substantial real world usage_ before
> integration into CPython than there is on even the smallest of modules
> for inclusion in the standard library?

I don't sense that. I get a sense that there's a lot of people
licking their chops because it's sponsored by Google and everything
Google touches turns to gold, but that's just nameless plebians. I
trust the developers not to be easily convinced. If GvR allows this
into CPython without something like a typical 4x speed increase I'll
eat my hat.

Carl Banks

==============================================================================
TOPIC: Updating form action attribute with mechanize.Browser
http://groups.google.com/group/comp.lang.python/t/f952a4cecda87263?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 27 2010 4:00 pm
From: cookiecaper

Hi all. I am using mechanize.Browser to download web pages and such.
One of these has the wrong URL in the action attribute of the form I
need to submit. Anyone know how I can update this quickly?
ClientForm.__init__ seems to take the action attribute but that is
passed by b.select_form(), I think.

==============================================================================
TOPIC: Stuck on a three word street name regex
http://groups.google.com/group/comp.lang.python/t/76a4ab9fd7279a4e?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Jan 27 2010 4:28 pm
From: Brian D

I've tackled this kind of problem before by looping through a patterns
dictionary, but there must be a smarter approach.

Two addresses. Note that the first has incorrectly transposed the
direction and street name. The second has an extra space in it before
the street type. Clearly done by someone who didn't know how to
concatenate properly -- or didn't care.

1000 RAMPART S ST

100 JOHN CHURCHILL CHASE ST

I want to parse the elements into an array of values that can be
inserted into new database fields.

Anyone who loves solving these kinds of puzzles care to relieve my
frazzled brain?

The pattern I'm using doesn't keep the "CHASE" with the "JOHN
CHURCHILL":

>>> p = re.compile(r'(?P<streetnum>\d+)\s(?P<streetname>[A-Z\s]*)\s(?P<streetdir>\w*)\s(?P<streettype>\w{2})$')
>>> s = '1405 RAMPART S ST'
>>> m = re.search(p, s)
>>> m
<_sre.SRE_Match object at 0x011A4440>
>>> print m.groups()
('1405', 'RAMPART', 'S', 'ST')
>>> s = '45 JOHN CHURCHILL CHASE ST'
>>> m = re.search(p, s)
>>> m
<_sre.SRE_Match object at 0x011A43E8>
>>> print m.groups()
('45', 'JOHN CHURCHILL', 'CHASE', 'ST')

== 2 of 3 ==
Date: Wed, Jan 27 2010 4:35 pm
From: Paul Rubin

Brian D <briandenzer@gmail.com> writes:
> I've tackled this kind of problem before by looping through a patterns
> dictionary, but there must be a smarter approach.>
> Two addresses. Note that the first has incorrectly transposed the
> direction and street name. ....

If you're really serious about it (e.g. you are the post office trying
to program automatic mail sorting machines) there is no simple regex
trick anything like what you want. A lot of addresses will be
ambiguous. You have use all the info you have about your entire address
corpus (e.g. you need a complete street directory of the whole US) and
do a bunch of Bayesian inference. As a very simple example, for an
address like "1000 RAMPART S ST" you'd use the zip code to identify the
address's geographic neighborhood, and then use your street directory to
find candidate correct addresses within that zip code. The USPS does
an amazing job of delivering mail to completely mangled addresses
based on methods like that.

== 3 of 3 ==
Date: Wed, Jan 27 2010 5:27 pm
From: MRAB

Brian D wrote:
> I've tackled this kind of problem before by looping through a patterns
> dictionary, but there must be a smarter approach.
>
> Two addresses. Note that the first has incorrectly transposed the
> direction and street name. The second has an extra space in it before
> the street type. Clearly done by someone who didn't know how to
> concatenate properly -- or didn't care.
>
> 1000 RAMPART S ST
>
> 100 JOHN CHURCHILL CHASE ST
>
> I want to parse the elements into an array of values that can be
> inserted into new database fields.
>
> Anyone who loves solving these kinds of puzzles care to relieve my
> frazzled brain?
>
> The pattern I'm using doesn't keep the "CHASE" with the "JOHN
> CHURCHILL":
>
[snip]
Regex doesn't gain you much. I'd split the string and then fix the parts
as necessary:

>>> def parse_address(address):
... parts = address.split()
... if parts[-2] == "S":
... parts[1 : -1] = [parts[-2]] + parts[1 : -2]
... parts[1 : -1] = [" ".join(parts[1 : -1])]
... return parts
...
>>> print parse_address("1000 RAMPART S ST")
['1000', 'S RAMPART', 'ST']
>>> print parse_address("100 JOHN CHURCHILL CHASE ST")
['100', 'JOHN CHURCHILL CHASE', 'ST']

==============================================================================
TOPIC: CodeInvestigator testers
http://groups.google.com/group/comp.lang.python/t/e19d3e1df29698e6?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 27 2010 6:00 pm
From: hans moleman

I need Python programmers to test my Python tracing tool
CodeInvestigator please.

It records all debug information in a recording phase. The program
runs as per usual, albeit a lot slower, while this recording takes
place.
You can then move anywhere in your code and click words in the code to
obtain debug information. Useful if you have no idea where to start to
debug or you want to see how a program works.

Your Python installation isn't changed by this tool. It can easily be
uninstalled or forgotten.
It requires Python 2.6 and a Firefox browser.
It comes with an installer for Windows, Linux and Mac OSX.

Any bugs, ideas and remarks please.

http://sourceforge.net/projects/cde-investigatr/

Thank you.
Martien Friedeman

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en