Re: Simple Password Strength Checker Review Help needed

[Paul Rubin]

Steven D'Aprano  writes:
> I think you're missing a word there. Relatively secure perhaps?

Yes, something like that, oops.

> The problem is that most users will not be a little bit careful. They 
> will stick the password on a Post-it note on the side of the monitor,...

Right, that's what I mean about careful.  But, people do generally
develop skills at keeping important bits of paper (like their drivers'
license) safe.

> Besides, with the number of on-line identities and passwords many people 
> need, you'll need a separate wallet just for the passwords. I have 
> something of the order of 80 or 90 passwords written down..

I don't have anywhere that many important ones.  For the less important
ones I just use my browser's auto-fill feature (i.e. the passwords are
stored in the browser).  I generate important ones with a program (2-6
words selected at random from a dictionary).  When I generate a new one,
I write it on a slip of paper that I keep in my pocket and refer to as
necessary.  After referring to the paper a few times I usually remember
the password and don't need the paper any more, so I dispose of it.

> So I need at least one (and likely more) password I can keep in my
> head, so I can encrypt my list of rarely-used passwords. 

If there's just one, and it's a phrase, you can remember it.

> since I'm really bad at judging randomness (like nearly all humans),

Right, humans are no good at generating or judging randomness.  It's
best to use an entropy source.  www.diceware.com explains how to do it
with dice and a wordlist they supply.  I use a program something like
the following instead:

   from math import log
   dictfile = '/usr/share/dict/words'

   def genrandom(nbytes):
   with open('/dev/urandom') as f:
   return int(f.read(nbytes).encode('hex'), 16)

   def main():
   wordlist = list(x.strip() for x in open(dictfile) if len(x) < 7)
   nwords = len(wordlist)
   print "%d words, entropy=%.3f bits/word"% (
   nwords, log(nwords, 2))
   print '-'.join(wordlist[genrandom(10)%nwords] for i in xrange(5))

   main()

You can also use the diceware word list instead of the unix wordlist,
of course.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Tue, 26 Jan 2010 23:37:00 -0800, Paul Rubin wrote:

> Steven D'Aprano  writes:
>> Sorry, I meant consistent with the rest of Python, which mostly uses
>> functions/methods and only rarely statements (e.g. del and import).
> 
> yield, assert, if/else, return, etc.  If we're after that kind of
> consistency, why not get rid of all those statements too?  They have
> already partly done it with yield, and they ended up introducing a new
> separate if/else expression syntax as an alternative to the statement.

Without becoming a purely functional language, you won't get rid of all 
statements. In my opinion, outside of such purely functional languages 
and unconventional languages like Forth, statements play a valuable role 
in that they are controlling syntax. For example:

for, while, if, try, break, yield, return

are all used for flow control, and should remain as statements. But print 
is not -- it's a function disguised as a statement. print, after all, is 
just sugar for stdout.write, which is fine as far as it goes, but when 
you want to do something slightly different from what the sugar does, it 
becomes terribly inconvenient.

A consequence of print being a statement is that my modules are often 
filled with functions and methods called "print_". Suppose I want to 
print the type of each argument as well as it's value. I would like to do 
this:


def decorator(pr):
def inner(*args, **kwargs):
 args = [(type(a), a) for a in args]
 pr(*args, **kwargs)
return inner

print = decorator(print)


and then use print as normal, but of course I can't. So instead I do 
something like this:


def print_(*args, **kwargs):
args = [(type(a), a) for a in args]
kw = {'file': sys.stdout, 'sep': ' ', 'end': '\n'}
kw.update(kwargs)
if len(kw) != 3:
raise TypeError('invalid keyword argument')
file = kw['file']
sep = kw['sep']
end = kw['end']
for arg in args:
print >>file, (str(arg) + sep),  # Don't forget the comma.
print >>file, end,  # Another comma.


And then, I have to remember to call print_ instead of print.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Steven D'Aprano  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 

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?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Sikuli: the coolest Python project I have yet seen...

[alex23]

Tim Roberts  wrote:
> it's not the most efficient way to automate applications

Sikuli doesn't seem that much different from Python in this way: it
may not be the most efficient use of the computer's time, but I dare
say it's significantly less demanding on the end user's.

I can see Sikuli easily progressing to a full visual programming
interface, replacing the 'click' keyword et al with iconic
representations.

Simple "script-less" GUI macro-ing for the masses? Fantastic.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Daniel Fetchinson]

>>> * Print is now a function. Great, much improvement.
>
> Actually not, IMHO. All it does is is to provide incompatibility.


What incompatibility are you exactly talking about?

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
>>>

Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Help parsing a page with python

[mierdatutis mi]

Hi,

I would like to parse a webpage to can get the url of the video download. I
use pyhton and firebug but I cant get the url link.

Example:

The url where I have to get the video link is:
http://www.rtve.es/mediateca/videos/20100125/saber-comer---salsa-verde-judiones-25-01-10/676590.shtml
"

The video is
http://www.rtve.es/resources/TE_SSAC011/flv/8/2/1264426362028.flv
Could you help me please?
Many thanks and sorry for my english!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[Simon Brunning]

2010/1/27 mierdatutis mi :
> Hi,
>
> I would like to parse a webpage to can get the url of the video download. I
> use pyhton and firebug but I cant get the url link.
>
> Example:
>
> The url where I have to get the video link is:
> http://www.rtve.es/mediateca/videos/20100125/saber-comer---salsa-verde-judiones-25-01-10/676590.shtml";
>
> The video is
> http://www.rtve.es/resources/TE_SSAC011/flv/8/2/1264426362028.flv
> Could you help me please?

That URL doesn't appear to be in the HTML - it must be being brought
in by the JavaScript somehow.

-- 
Cheers,
Simon B.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steve Holden]

Paul Rubin wrote:
> Steven D'Aprano  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 
> 
> 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?

Remember that Guido stated (I think in the original FAQ entry for why
assignments don't produce results, but I could be wrong) that he
explicitly wanted Python to be a statement-based language.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Ad hoc lists vs ad hoc tuples

[Floris Bruynooghe]

One thing I ofter wonder is which is better when you just need a
throwaway sequence: a list or a tuple?  E.g.:

if foo in ['some', 'random', 'strings']:
...
if [bool1, bool2, boo3].count(True) != 1:
   ...

(The last one only works with tuples since python 2.6)

Is a list or tuple better or more efficient in these situations?


Regards
Floris

PS: This is inspired by some of the space-efficiency comments from the
list.pop(0) discussion.
-- 
http://mail.python.org/mailman/listinfo/python-list

myths about python 3

[Daniel Fetchinson]

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!

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Stefan Behnel]

Daniel Fetchinson, 27.01.2010 11:32:
> 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

This is actually misleading by itself, as the first statement is not a
function call in Py2:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print(1,2)
(1, 2)

It can, however, be made a function call through a future import in 2.6:

>>> from __future__ import print_function
>>> print(1,2)
1 2

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Andre Engels]

On Wed, Jan 27, 2010 at 11:32 AM, 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. The
other way around this is _not_ the case. 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.


-- 
André Engels, andreeng...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Terminal application with non-standard print

[Rémi]

On 25 jan, 23:30, Sean DiZazzo  wrote:
> On Jan 24, 11:27 am, Rémi  wrote:
>
>
>
> > Hello everyone,
>
> > I would like to do a Python application that prints data to stdout, but
> > not the common way. I do not want the lines to be printed after each
> > other, but the old lines to be replaced with the new ones, like wget
> > does it for example (when downloading a file you can see the percentage
> > increasing on a same line).
>
> > I looked into the curses module, but this seems adapted only to do a
> > whole application, and the terminal history is not visible anymore when
> > the application starts.
>
> > Any ideas?
>
> > Thanks,
>
> > Remi
>
> You might want to take a look at the readline module.
>
> ~Sean

Thanks everyone for your answers, that helped a lot.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[mierdatutis mi]

Those videos are generated by javascript.
There is some parser with python for javascript???

Thanks a lot!


2010/1/27 Simon Brunning 

> 2010/1/27 mierdatutis mi :
> > Hi,
> >
> > I would like to parse a webpage to can get the url of the video download.
> I
> > use pyhton and firebug but I cant get the url link.
> >
> > Example:
> >
> > The url where I have to get the video link is:
> >
> http://www.rtve.es/mediateca/videos/20100125/saber-comer---salsa-verde-judiones-25-01-10/676590.shtml
> "
> >
> > The video is
> > http://www.rtve.es/resources/TE_SSAC011/flv/8/2/1264426362028.flv
> > Could you help me please?
>
> That URL doesn't appear to be in the HTML - it must be being brought
> in by the JavaScript somehow.
>
> --
> Cheers,
> Simon B.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Xah Lee]

Someone is badmouthing me, and it has been doing so over the years. I
feel obliged to post a off topic relpy. See:

• DreamHost.com and A Incidence of Harassment
  http://xahlee.org/Periodic_dosage_dir/t2/harassment.html

• Why Can't You Be Normal?
  http://xahlee.org/Netiquette_dir/why_cant_you_be_normal.html

 Xah

On Jan 26, 7:12 pm, "Alf P. Steinbach"  wrote:
> * John Bokma:
>
> > "Alf P. Steinbach"  writes:
>
> >> Please don't post more noise and ad hominem attacks to the group,
> >> Steve.
>
> > Funny that you talk about noise while replying yourself to noise. Xah
> > Lee is just a pathetic spammer. He's not going to reply in this
> > thread. He just shits out his stuff in as many groups as possible to
> > promote his website.
>
> Sorry, I didn't know.
>
> Thanks for the heads-up.
>
> Cheers,
>
> - Alf

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[Simon Brunning]

2010/1/27 mierdatutis mi :
> Those videos are generated by javascript.
> There is some parser with python for javascript???

There is , but
simulating the whole context of a browser is going to be a horror.

You are probably far better off automating a real browser. WebDriver
() has Python bindings these days. It's
primarily intended for functional testing, but it might be a good fit
here too.

-- 
Cheers,
Simon B.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scraping with urllib2

[Javier Collado]

Hello,

To accept cookies, use the HTTPCookieProcessor as explained here:
http://www.nomadjourney.com/2009/03/automatic-site-login-using-python-urllib2/

Best regards,
Javier

2010/1/27 Andre Engels :
> On Wed, Jan 27, 2010 at 6:26 AM, Patrick  wrote:
>> I'm trying to scrape the attached link for the price listed $99.99:
>> http://bananarepublic.gap.com/browse/product.do?cid=41559&vid=1&pid=692392
>>
>> I can see the price if I view the source(I even turned off java and
>> javascript), but when I use urllib2, the price doesn't show up.
>>
>> Is there another library other than urllib2 that would work?
>
> To see that page you need to accept cookies from the site and send them back.
>
>
>
> --
> André Engels, andreeng...@gmail.com
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[Javier Collado]

Hello,

A test case for Windmill might also be used to extract the information
that you're looking for.

Best regards,
Javier

2010/1/27 mierdatutis mi :
> Those videos are generated by javascript.
> There is some parser with python for javascript???
>
> Thanks a lot!
>
>
> 2010/1/27 Simon Brunning 
>>
>> 2010/1/27 mierdatutis mi :
>> > Hi,
>> >
>> > I would like to parse a webpage to can get the url of the video
>> > download. I
>> > use pyhton and firebug but I cant get the url link.
>> >
>> > Example:
>> >
>> > The url where I have to get the video link is:
>> >
>> > http://www.rtve.es/mediateca/videos/20100125/saber-comer---salsa-verde-judiones-25-01-10/676590.shtml";
>> >
>> > The video is
>> > http://www.rtve.es/resources/TE_SSAC011/flv/8/2/1264426362028.flv
>> > Could you help me please?
>>
>> That URL doesn't appear to be in the HTML - it must be being brought
>> in by the JavaScript somehow.
>>
>> --
>> Cheers,
>> Simon B.
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[mierdatutis mi]

Hello again,

What test case for Windmill? Can you say me the link, please?

Many thanks

2010/1/27 Javier Collado 

> Hello,
>
> A test case for Windmill might also be used to extract the information
> that you're looking for.
>
> Best regards,
> Javier
>
> 2010/1/27 mierdatutis mi :
> > Those videos are generated by javascript.
> > There is some parser with python for javascript???
> >
> > Thanks a lot!
> >
> >
> > 2010/1/27 Simon Brunning 
> >>
> >> 2010/1/27 mierdatutis mi :
> >> > Hi,
> >> >
> >> > I would like to parse a webpage to can get the url of the video
> >> > download. I
> >> > use pyhton and firebug but I cant get the url link.
> >> >
> >> > Example:
> >> >
> >> > The url where I have to get the video link is:
> >> >
> >> >
> http://www.rtve.es/mediateca/videos/20100125/saber-comer---salsa-verde-judiones-25-01-10/676590.shtml
> "
> >> >
> >> > The video is
> >> > http://www.rtve.es/resources/TE_SSAC011/flv/8/2/1264426362028.flv
> >> > Could you help me please?
> >>
> >> That URL doesn't appear to be in the HTML - it must be being brought
> >> in by the JavaScript somehow.
> >>
> >> --
> >> Cheers,
> >> Simon B.
> >> --
> >> http://mail.python.org/mailman/listinfo/python-list
> >
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
> >
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[Simon Brunning]

2010/1/27 mierdatutis mi :
> Hello again,
>
> What test case for Windmill? Can you say me the link, please?

http://lmgtfy.com/?q=windmill+test

-- 
Cheers,
Simon B.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ad hoc lists vs ad hoc tuples

[Iain King]

On Jan 27, 10:20 am, Floris Bruynooghe 
wrote:
> One thing I ofter wonder is which is better when you just need a
> throwaway sequence: a list or a tuple?  E.g.:
>
> if foo in ['some', 'random', 'strings']:
>     ...
> if [bool1, bool2, boo3].count(True) != 1:
>    ...
>
> (The last one only works with tuples since python 2.6)
>
> Is a list or tuple better or more efficient in these situations?
>
> Regards
> Floris
>
> PS: This is inspired by some of the space-efficiency comments from the
> list.pop(0) discussion.

I tend to use tuples unless using a list makes it easier to read.  For
example:

if foo in ('some', 'random', 'strings'):

draw.text((10,30), "WHICH IS WHITE", font=font)
draw.line([(70,25), (85,25), (105,45)])

I've no idea what the performance difference is; I've always assumed
it's negligible.

Iain
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Xah Lee]

On Jan 26, 3:47 pm, Xah Lee  wrote:

> * Many functions that return lists now returns “Views” or
> “Iterators” Instead. A fucking fuck all fucked up shit. A extraneous
> “oop engineering” complication. (See: Lambda in Python 3000)

See also:

“Iterators: Signs of Weakness in Object-Oriented Languages” (1992) By
Henry G Baker. http://home.pipeline.com/~hbaker1/Iterator.html

Xah wrote:
> * The cmp() function used in sort is basically gone, users are now
> supposed to use the “key” parameter instead. This is a flying-face-
> fuck to computer science. This would be the most serious fuckup in
> python 3. (See: Sorting in Python and Perl)

Steven D'Aprano 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.

The reason cmp is a order slower is due to Python lang's limitation
and compiler implementation limitation.

• Sorting in Python and Perl
  http://xahlee.org/perl-python/sort_list.html

the python lang, by the very nature of being a dynamic lang, makes it
hard for compiler analize and optimize a sort function call with cmp
argument that is equivalent to a key.

So, for practical reasons, i think a “key” parameter is fine. But
chopping off “cmp” is damaging. When your data structure is complex,
its order is not embedded in some “key”. Taking out “cmp” makes it
impossible to sort your data structure.

in the essay, i also gave a few examples of data structures where you
need a general means to specify the ordering function in order to
sort. Without a cmp, you'll need to munge your data by some decorate-
sort-dedecorate technique.

From another perspective, often it is considered a good principle of
design that the lang be a bit flexible to let programers do what they
want, instead of force them into one way. Python, being a loosely
typed lang, with so-called “duck typing”, in contrast to Java or OCaml
in different ways, certainly is more on the lose extreme of the lang
spectrum with respect to code construction. So, i don't see how python
3 people made the decision to removed cmp. (am pretty sure, at least
part of the reason, is a ill attitude towards functional programing
and lambda, lead by Guido.)

> There may be a handful of rare applications where there is no obvious way
> to convert a cmp function to a key, but they are vanishingly rare. I
> think, if you search the archives, Paul Rubin may have come up with one
> example. There are a number of recipes for easily converting cmp sorts to
> key sorts.

You say that it is rare. You are probably right. Though, that may just
be caused by the language itself and consequently the type of people
who uses it. If Python's lambda is not limited, and the python
community doesn't look down on lambda, it is likely cmp will used
more. The more your data structure becomes complex, the more cmp will
be needed.

> I think, in my perfect world, list.sort() and sorted() should continue
> being key based, while the standard library contained (perhaps in the
> functools module?) a sort function that contains all the bells and
> whistles. You want cmp, it's there, and you can pay the extra cost if you
> need it. You want to sort multiple lists by the contents of one? One
> import away. But keep the general sort() function lean and super-fast.

btw, is something like cmp still available in some module for sort?

  Xah
∑ http://xahlee.org/

☄
-- 
http://mail.python.org/mailman/listinfo/python-list

Python and Ruby

[Jean Guillaume Pyraksos]

What are the arguments for choosing Python against Ruby
for introductory programming ? Python has no provisions
for tail recursion, Ruby is going to... So what ?
Thanks,

   JG
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Ruby

[Stefan Behnel]

Jean Guillaume Pyraksos, 27.01.2010 14:01:
> What are the arguments for choosing Python against Ruby
> for introductory programming ?

PEP 20:

http://www.python.org/dev/peps/pep-0020/

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

starting a thread in a nother thread

[Richard Lamboj]

hello,

just for _curiosity_. What would be if i start a thread in a nother thread and 
acquire a lock in the "child" thread. Is there anything that could go wrong 
if someone try to start threads in threads?

Kind Regards,

Richi
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: starting a thread in a nother thread

[Stefan Behnel]

Richard Lamboj, 27.01.2010 14:06:
> just for _curiosity_. What would be if i start a thread in a nother thread 
> and 
> acquire a lock in the "child" thread. Is there anything that could go wrong 
> if someone try to start threads in threads?

There's usually tons of things that can go wrong w.r.t. threads:

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

However, there's nothing special to a thread that was started from another
thread, so the problems don't change.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Ruby

[Simon Brunning]

2010/1/27 Jean Guillaume Pyraksos :
> What are the arguments for choosing Python against Ruby
> for introductory programming ?

Frankly, either would be a good choice.

I think Python is a little cleaner, but I'm sure you'd find Ruby fans
who'd argue the complete opposite. Both have good ecosystems, (i.e.
good communities, and plenty of good libraries and frameworks) - but
Python is probably a bit ahead here having been around a bit longer.

> Python has no provisions
> for tail recursion, Ruby is going to... So what ?

This would be a very strange reason to pick one language over the
other - it's a very minor point.

-- 
Cheers,
Simon B.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[Javier Collado]

Hello,

You can find some advice here:
http://www.packtpub.com/article/web-scraping-with-python-part-2

Best regards,
Javier

2010/1/27 mierdatutis mi :
> Hello again,
>
> What test case for Windmill? Can you say me the link, please?
>
> Many thanks
>
> 2010/1/27 Javier Collado 
>>
>> Hello,
>>
>> A test case for Windmill might also be used to extract the information
>> that you're looking for.
>>
>> Best regards,
>>    Javier
>>
>> 2010/1/27 mierdatutis mi :
>> > Those videos are generated by javascript.
>> > There is some parser with python for javascript???
>> >
>> > Thanks a lot!
>> >
>> >
>> > 2010/1/27 Simon Brunning 
>> >>
>> >> 2010/1/27 mierdatutis mi :
>> >> > Hi,
>> >> >
>> >> > I would like to parse a webpage to can get the url of the video
>> >> > download. I
>> >> > use pyhton and firebug but I cant get the url link.
>> >> >
>> >> > Example:
>> >> >
>> >> > The url where I have to get the video link is:
>> >> >
>> >> >
>> >> > http://www.rtve.es/mediateca/videos/20100125/saber-comer---salsa-verde-judiones-25-01-10/676590.shtml";
>> >> >
>> >> > The video is
>> >> > http://www.rtve.es/resources/TE_SSAC011/flv/8/2/1264426362028.flv
>> >> > Could you help me please?
>> >>
>> >> That URL doesn't appear to be in the HTML - it must be being brought
>> >> in by the JavaScript somehow.
>> >>
>> >> --
>> >> Cheers,
>> >> Simon B.
>> >> --
>> >> http://mail.python.org/mailman/listinfo/python-list
>> >
>> >
>> > --
>> > http://mail.python.org/mailman/listinfo/python-list
>> >
>> >
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Just drawing lines and plotting points?

[Alf P. Steinbach]

* rantingrick:

On Jan 26, 10:52 pm, "Alf P. Steinbach"  wrote:

* rantingrick:






On Jan 26, 9:38 pm, Terry Reedy  wrote:

On 1/26/2010 7:54 PM, Chris Rebert wrote:

On Tue, Jan 26, 2010 at 4:36 PM, Someone Something  wrote:

Hello,
I need a python library that makes drawing lines and plotting points (these
two things are the only things I need to do) easy. Or, how can I do
something like this with pygame? Basically, what I want to do is make
graphs. In pygame, since the coordinate system switches the x's and the y's
I would have to switch them again when I plot my points so my graphs look
okay. I hope this was enough info for me to get a good answer.

matplotlib, perhaps?:http://matplotlib.sourceforge.net/

or dislin?

it doesn't get any easier than the tkCanvas widget...
import Tkinter as tk
#import tkinter as tk #python3.0+
app = tk.Tk()
canvas = tk.Canvas(app)
canvas.pack()
canvas.create_line(sx,sy, ex,ey)
#...
#...
app.mainloop()

He he, it's even easier to draw a graph using the turtle module.

Cheers,

- Alf


Yes Alf please forgive me, i had completely forgotten about the
"visual" learners amongst us.

turtle, turtle, watch him go...
turtle, turtle, why he so slow...
turtle, turtle, not even he don't know...?

;-)


Uhm, that is a misconception.

Just do

  turtle.hideturtle()
  turtle.tracer( 0 )

to turn off the animation stuff.

That said, the turtle module bundled with Python is somewhat limited, but for 
plotting simple graphs it's certainly simpler than using tkinter directly.



Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Daniel Fetchinson]

>> 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

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: starting a thread in a nother thread

[Richard Lamboj]

Am Wednesday 27 January 2010 14:10:13 schrieb Stefan Behnel:
> Richard Lamboj, 27.01.2010 14:06:
> > just for _curiosity_. What would be if i start a thread in a nother
> > thread and acquire a lock in the "child" thread. Is there anything that
> > could go wrong if someone try to start threads in threads?
>
> There's usually tons of things that can go wrong w.r.t. threads:
>
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
>
> However, there's nothing special to a thread that was started from another
> thread, so the problems don't change.
>
> Stefan

Hello,

i have tried a little bit around with psycopg2 and threads,

I'am sharing one connection for all threads. When i'am starting the 
threads "normal" everything works without any Problem. When i'am starting the 
threads from another thread than i got a "segmentation fault" - i'am using 
locks. I'am sending 2048 Reqeuest at once. The "normal" Methode with one 
thread for every Request needs 10 seconds. The other Methode starting a 
thread and starting two other threads from this thread crashes after 10 to 40 
requests with the segmentation fault error. Any Idea why? Its a 64 bit 
maschine. Maybe i'am making something wrong?

Kind Regards

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Daniel Fetchinson]

>> 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
>
> This is actually misleading by itself, as the first statement is not a
> function call in Py2:
>
> Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55)
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> print(1,2)
> (1, 2)
>
> It can, however, be made a function call through a future import in 2.6:
>
> >>> from __future__ import print_function
> >>> print(1,2)
> 1 2

Thanks! This is true, luckily you provided a better solution and the
conclusion is not changed, as long as print is concerned, 2.6 and 3.x
can trivially be made compatible.

Surely there are incompatibilities, but first of all there are many
tools that help the transition such as 2to3 and there is a clear and
officially documented migration guide too (quoted by Steve Holden in
another thread not so long ago), second of all the most vocal
arguments that one hears mostly from ill-informed people are related
to print and similar non-issues. These then get quoted over and over
again, which led me to write this post :)

Cheers,
Daniel


Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Jean-Michel Pichavant]

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

  

How would you write in python 2.6

if print:
   print('Hello')

---

def myPrint(*args):
   for arg in args:
   sys.stdout.write(str(arg))

print = myPrint

JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: starting a thread in a nother thread

[Stefan Behnel]

Richard Lamboj, 27.01.2010 15:23:
> Am Wednesday 27 January 2010 14:10:13 schrieb Stefan Behnel:
>> Richard Lamboj, 27.01.2010 14:06:
>>> just for _curiosity_. What would be if i start a thread in a nother
>>> thread and acquire a lock in the "child" thread. Is there anything that
>>> could go wrong if someone try to start threads in threads?
>> There's usually tons of things that can go wrong w.r.t. threads:
>>
>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
>>
>> However, there's nothing special to a thread that was started from another
>> thread, so the problems don't change.
> 
> i have tried a little bit around with psycopg2 and threads,
> 
> I'am sharing one connection for all threads. When i'am starting the 
> threads "normal" everything works without any Problem. When i'am starting the 
> threads from another thread than i got a "segmentation fault"

Sounds like a bug that you might want to report to the maintainers of psycopg2.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Generic proxy (that proxies methods like __iter__)

[D HANNEY]

>>> def show(opened):
... with opened as file:
... for line in file:
... print line.strip()
...

>>> show(open("test.txt"))
blah1
blah2
blah3


#
# Good! I wonder if I can do that with StringIO ...
#


>>> import StringIO
>>> show(StringIO.StringIO("blah1\nblah2\nblah3\n"))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in show
AttributeError: StringIO instance has no attribute '__exit__'

#
# Oh dear ... I'll need to proxy it ...
#


>>> class IterNoGuardProxy(object):
... def __init__(self, t):
... self.t = t
... def __enter__(self):
... return self
... def __exit__(self, type, value, traceback):
... return False
... def __iter__(self):
... return self.t.__iter__()
...
>>> show(IterNoGuardProxy(StringIO.StringIO("blah1\nblah2\nblah3\n")))
blah1
blah2
blah3
>>>


#
# Great! That works well. Now I wonder if I can do it generically
# in a way that can proxy for ALL methods (including, but not limited
to, __iter__)
#


>>> class NoGuardProxy(object):
... def __init__(self, t):
... self.t = t
... def __enter__(self):
... return self
... def __exit__(self, type, value, traceback):
... return False
... def __getattr__(self):
... return self.t.__getattr__(self)
...
>>> show(NoGuardProxy(StringIO.StringIO("blah1\nblah2\nblah3\n")))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in show
TypeError: 'NoGuardProxy' object is not iterable

#
# Now I'm stuck.
# Can anyone help?
#
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Lie Ryan]

On 01/28/10 01:32, Jean-Michel Pichavant 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.

 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
>>
>>   
> How would you write in python 2.6
> 
> if print:
>print('Hello')
> 
> ---
> 
> def myPrint(*args):
>for arg in args:
>sys.stdout.write(str(arg))
> 
> print = myPrint
> 
> JM


from __future__ import print_function

if print:
print('Hello')

def myPrint(*args):
   for arg in args:
   sys.stdout.write(str(arg))

print = myPrint
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ad hoc lists vs ad hoc tuples

[M.-A. Lemburg]

Iain King wrote:
> On Jan 27, 10:20 am, Floris Bruynooghe 
> wrote:
>> One thing I ofter wonder is which is better when you just need a
>> throwaway sequence: a list or a tuple?  E.g.:
>>
>> if foo in ['some', 'random', 'strings']:
>> ...
>> if [bool1, bool2, boo3].count(True) != 1:
>>...
>>
>> (The last one only works with tuples since python 2.6)
>>
>> Is a list or tuple better or more efficient in these situations?
>>
>> Regards
>> Floris
>>
>> PS: This is inspired by some of the space-efficiency comments from the
>> list.pop(0) discussion.
> 
> I tend to use tuples unless using a list makes it easier to read.  For
> example:
> 
> if foo in ('some', 'random', 'strings'):
> 
> draw.text((10,30), "WHICH IS WHITE", font=font)
> draw.line([(70,25), (85,25), (105,45)])
> 
> I've no idea what the performance difference is; I've always assumed
> it's negligible.

Tuples are a faster to create than lists, so if you create
lots of them and don't need the list features, use tuples.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 27 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list.pop(0) vs. collections.dequeue

[Steve Howell]

On Jan 26, 11:34 pm, Arnaud Delobelle  wrote:
> Steve Howell  writes:
> > On Jan 25, 1:32 pm, Arnaud Delobelle  wrote:
> >> Steve Howell  writes:
>
> >> [...]
>
> >> > My algorithm does exactly N pops and roughly N list accesses, so I
> >> > would be going from N*N + N to N + N log N if switched to blist.
>
> >> Can you post your algorithm?  It would be interesting to have a concrete
> >> use case to base this discussion on.
>
> > I just realized you meant the Python code itself.  It is here:
>
> >https://bitbucket.org/showell/shpaml_website/src/tip/shpaml.py
>
> Hi - I didn't have the time to look at it before today.  You scan
> through a list called prefix_lines, and you use pop(0) as a means to
> keep track of your position in this list.  It seems to me that it would
> be more effective to explicitely keep track of it - and it would remove
> the need to the numerous copies of sublists of indent_lines that you
> have to create.
>
> I have rewritten part of the three relevant functions (html_block_tag,
> get_indented_block and recurse, within indent_lines) to show you what I
> mean (see below).  I have tried to keep the changes to a minimum - you
> can see that the code is no more complex like this.  The advantage is
> that only one list is created, prefix_lines, and there is no need to
> mutate it or copy parts of it during the algorithm.  I have not had the
> time to test it though (only on one of the examples on the examples
> webpage).
>
> Code follows:
>
> [...]
>
> def html_block_tag(output, block, start, end, recurse):
>     append = output.append
>     prefix, tag = block[start]
>     if RAW_HTML.regex.match(tag):
>         append(prefix + tag)
>         recurse(block, start + 1, end)
>     else:
>         start_tag, end_tag = apply_jquery_sugar(tag)
>         append(prefix + start_tag)
>         recurse(block, start + 1, end)
>         append(prefix + end_tag)
>
> [...]
>
> def get_indented_block(prefix_lines, start, end):
>     prefix, line = prefix_lines[start]
>     len_prefix = len(prefix)
>     i = start + 1
>     while i < end:
>         new_prefix, line = prefix_lines[i]
>         if line and len(new_prefix) <= len_prefix:
>             break
>         i += 1
>     while i-1 > start and prefix_lines[i-1][1] == '':
>         i -= 1
>     return i
>
> [...]
>
> def indent_lines(lines,
>             output,
>             branch_method,
>             leaf_method,
>             pass_syntax,
>             flush_left_syntax,
>             flush_left_empty_line,
>             indentation_method,
>             get_block,
>             ):
>     append = output.append
>     def recurse(prefix_lines, start, end):
>         while start < end:
>             prefix, line = prefix_lines[start]
>             if line == '':
>                 start += 1
>                 append('')
>             else:
>                 block_end = get_block(prefix_lines, start, end)
>                 if block_end == start + 1:
>                     start += 1
>                     if line == pass_syntax:
>                         pass
>                     elif line.startswith(flush_left_syntax):
>                         append(line[len(flush_left_syntax):])
>                     elif line.startswith(flush_left_empty_line):
>                         append('')
>                     else:
>                         append(prefix + leaf_method(line))
>                 else:
>                     branch_method(output, prefix_lines, start, block_end, 
> recurse)
>                     start = block_end
>         return
>     prefix_lines = map(indentation_method, lines)
>     recurse(prefix_lines, 0, len(prefix_lines))

I think your rewrite makes sense for the way that Python is
implemented today.

Instead of mutating the list as you consume elements, you propose to
advance the "start" variable, which is essentially a pointer.

There are only two disadvantage of the "start" approach that I can
think of:

  1) You have to pass around two parameters where before there was
only one.  (Aside: for stylistic concerns, would you bundle them in a
tuple, since they kind of go hand in hand?)
  2) You hold on to memory from the elements longer.

Pushing this complexity down into CPython of course would have similar
disadvantages:

  1) you have to store two pointers where before there was only one
  2) you hold on to memory from pointers to orphaned elements longer

Disadvantage #1 is more than offset by the fact that you would have
had to waste memory with the "start" in the Python program.

Disadvantage #2 is offset by the fact that you would have been holding
on to the elements themselves in the Python program.

Admittedly this a pretty narrow context where pushing the logic down
into CPython gains overall simplicity and performance.  Disadvantage
#1 is the sticky point when you consider the patch in the broader
context of all programs.

Thanks for looking at the code, by the way.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Ruby

[Roald de Vries]

On Jan 27, 2010, at 2:01 PM, Jean Guillaume Pyraksos wrote:


What are the arguments for choosing Python against Ruby
for introductory programming ? Python has no provisions
for tail recursion, Ruby is going to... So what ?
Thanks,


I think the main difference is in culture, especially for  
*introductory* programming. For example, I have the impression that  
Rubyists like to write the same thing in as many ways as possible  
(example: rubyquiz.com), Python prefers one obvious way; this  
(arguably) makes Ruby more writable and Python more readable.




--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Daniel Fetchinson:

* Print is now a function. Great, much improvement.

Actually not, IMHO. All it does is is to provide incompatibility.



What incompatibility are you exactly talking about?

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

Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?


I gather that your example is about code that technically executes fine with 
both versions and produces the same result, i.e. that there is a subset with the 
same syntax and semantics.


But 'print' calls that technically execute fine with both versions may and will 
in general produce different results.


I.e. not just the syntax but also the semantics have changed:


>>> import sys
>>> sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
>>>
>>> print( "2+2 =", 2+2 )
('2+2 =', 4)
>>> _


>>> import sys
>>> sys.version
'3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
>>>
>>> print( "2+2 =", 2+2 )
2+2 = 4
>>> _



Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Generic proxy (that proxies methods like __iter__)

[Arnaud Delobelle]

On 27 Jan, 14:41, D HANNEY  wrote:
[...]
> >>> class NoGuardProxy(object):
>
> ... def __init__(self, t):
> ... self.t = t
> ... def __enter__(self):
> ... return self
> ... def __exit__(self, type, value, traceback):
> ... return False
> ...         def __getattr__(self):
> ...                 return self.t.__getattr__(self)
> ...>>> show(NoGuardProxy(StringIO.StringIO("blah1\nblah2\nblah3\n")))
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in show
> TypeError: 'NoGuardProxy' object is not iterable
>
> #
> # Now I'm stuck.
> # Can anyone help?
> #

See [1] for an explanation.  Here is an idea: you could get round that
by generating a class on the fly, if you don't mind changing the class
of the object (untested):

def noguardproxy(obj):
class NoGuardProxy(type(obj)):
def __enter__(self):
   return self
def __exit__(self, type, value, traceback):
   return False
obj.__class__ = NoGuardProxy
return obj


If you want to keep obj untouched, you could add the line

obj = copy(obj)

before changing the class.

--
Arnaud

[1] http://docs.python.org/reference/datamodel.html#new-style-special-lookup
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ad hoc lists vs ad hoc tuples

[Steve Holden]

Iain King wrote:
> On Jan 27, 10:20 am, Floris Bruynooghe 
> wrote:
>> One thing I ofter wonder is which is better when you just need a
>> throwaway sequence: a list or a tuple?  E.g.:
>>
>> if foo in ['some', 'random', 'strings']:
>> ...
>> if [bool1, bool2, boo3].count(True) != 1:
>>...
>>
>> (The last one only works with tuples since python 2.6)
>>
>> Is a list or tuple better or more efficient in these situations?
>>
>> Regards
>> Floris
>>
>> PS: This is inspired by some of the space-efficiency comments from the
>> list.pop(0) discussion.
> 
> I tend to use tuples unless using a list makes it easier to read.  For
> example:
> 
> if foo in ('some', 'random', 'strings'):
> 
> draw.text((10,30), "WHICH IS WHITE", font=font)
> draw.line([(70,25), (85,25), (105,45)])
> 
> I've no idea what the performance difference is; I've always assumed
> it's negligible.
> 
The fact that you have felt able to neglect the performance difference
makes it quite literally negligible.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Library support for Python 3.x

[Kevin Walzer]

I'm going to be starting some new Python projects in Python 2.6, but am 
concerned that at least three of the libraries I will be 
using--pycrypto, paramiko and feedparser--are not currently supported in 
Python 3.x. The authors of these programs have not given any indication 
that work is underway to support Python 3.x. Eventually I plan to 
migrate to Python 3.x.


I don't want to be stuck using libraries that may not be updated for the 
next generation of Python. How are others handling this issue?


--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Daniel Fetchinson]

> * Print is now a function. Great, much improvement.
>>> Actually not, IMHO. All it does is is to provide incompatibility.
>>
>>
>> What incompatibility are you exactly talking about?
>>
>> 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
>>
>> Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?
>
> I gather that your example is about code that technically executes fine with
> both versions and produces the same result, i.e. that there is a subset with
> the
> same syntax and semantics.
>
> But 'print' calls that technically execute fine with both versions may and
> will
> in general produce different results.
>
> I.e. not just the syntax but also the semantics have changed:
>
>
>  >>> import sys
>  >>> sys.version
> '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
>  >>>
>  >>> print( "2+2 =", 2+2 )
> ('2+2 =', 4)
>  >>> _
>
>
>  >>> import sys
>  >>> sys.version
> '3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
>  >>>
>  >>> print( "2+2 =", 2+2 )
> 2+2 = 4
>  >>> _

True. However, as someone else pointed out in a neighbouring thread you can do

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.
>>> from __future__ import print_function
>>> print( "2+2 =", 2+2 )
2+2 = 4
>>>

which gives 100% compatibility as far as print is concerned between 2.6 and 3.x.

So again, what sort of an incompatibility are you talking about
concerning 'print' between 2.6 and 3.x?

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Daniel Fetchinson:

* Print is now a function. Great, much improvement.

Actually not, IMHO. All it does is is to provide incompatibility.


What incompatibility are you exactly talking about?

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

Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

I gather that your example is about code that technically executes fine with
both versions and produces the same result, i.e. that there is a subset with
the
same syntax and semantics.

But 'print' calls that technically execute fine with both versions may and
will
in general produce different results.

I.e. not just the syntax but also the semantics have changed:


 >>> import sys
 >>> sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
 >>>
 >>> print( "2+2 =", 2+2 )
('2+2 =', 4)
 >>> _


 >>> import sys
 >>> sys.version
'3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
 >>>
 >>> print( "2+2 =", 2+2 )
2+2 = 4
 >>> _


True. However, as someone else pointed out in a neighbouring thread you can do

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.

from __future__ import print_function
print( "2+2 =", 2+2 )

2+2 = 4

which gives 100% compatibility as far as print is concerned between 2.6 and 3.x.


That makes the code behave with 3.x syntax and semantics regarding print. I.e. 
it chooses one language. It doesn't make them compatible: if they were, then you 
wouldn't have to choose.


For example, it doesn't fix up 2.x code that prints tuples: incompatible, it 
will still execute but no longer do what it was supposed to do.


But lest you focus down on that rare case, consider 2.x code that contains

  print "2+2", 2

All such statements need to be fixed up in a 2->3 transition. Adding __future__ 
just makes the code invalid, it doesn't give you any shred of compatibility for 
this. A code rewrite can be partially automated like 2to3 but the 
incompatibility needlessly introduces an additional set of things that Can Go 
Wrong(TM), and with Murphy present, as He always is, well.




So again, what sort of an incompatibility are you talking about
concerning 'print' between 2.6 and 3.x?


Syntax and semantics. They're different.


Cheers & hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: ctypes for AIX

[Antoine Pitrou]

Hello,

> I then figured I would get a new copy of python and install it
> on AIX. I downloaded python.2.5.5c2 from http://www.python.org. I did
> the configure and make which posted many errors in the ctypes function
> which I guess is the reason that is does not get include in the final
> make.

I would suggest two things:
1) try with the latest Python 2.6.x, because 2.5 only receives security 
fixes now. 2.6 is the stable branch which receives regular bug fixes 
(which includes build problems)
2) if Python 2.6.x also fails compiling, please file a bug report on
http://bugs.python.org

Regards

Antoine.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[eric_dex...@msn.com]

On Jan 27, 8:42 am, Lie Ryan  wrote:
> On 01/28/10 01:32, Jean-Michel Pichavant 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.
>
>  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
>
> > How would you write in python 2.6
>
> > if print:
> >    print('Hello')
>
> > ---
>
> > def myPrint(*args):
> >    for arg in args:
> >        sys.stdout.write(str(arg))
>
> > print = myPrint
>
> > JM
>
> from __future__ import print_function
>
> if print:
>     print('Hello')
>
> def myPrint(*args):
>    for arg in args:
>        sys.stdout.write(str(arg))
>
> print = myPrint

I can't say that I am that keen on 2.6 all my favorite graphics
libraries are in 2.5.  If there was money
involved I would probably think y'all were doing it to stay employed
so I am thinking I should wait till 3.4
and 3.5 to get involved with this but much sooner than python 4.0.  I
did notice that I had trouble compiling
a library because some version of microsoft c is no longer
available...sort of forced migration.


__
http://dextracker.blogspot.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Stefan Behnel]

Xah Lee, 27.01.2010 00:47:
> Any comment on this?

No, sorry. Not worth bothering.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Grant Edwards]

On 2010-01-27, Alf P. Steinbach  wrote:

> I'm responding to the original message by Xah Lee, which is
> not carried by my Usenet provider.

A Usenet provider that doesn't carry messages from Xah Lee.

So... many... jokes.

-- 
Grant


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Help parsing a page with python

[mierdatutis mi]

Hello,

Thanks Javier,

But I think that the page embeds a viewer. Only the viewer knows the URL to
the FLV file itself. I can't see any direct correspondence between the
elements of the two URLs,  I cant see a way to construct the FLV's URL from
the contents of that page :-(

I have to do manually, I dont see other way :-(

Many thanks for your answer
Muchas gracias





2010/1/27 Javier Collado 

> Hello,
>
> You can find some advice here:
> http://www.packtpub.com/article/web-scraping-with-python-part-2
>
> Best regards,
>Javier
>
> 2010/1/27 mierdatutis mi :
> > Hello again,
> >
> > What test case for Windmill? Can you say me the link, please?
> >
> > Many thanks
> >
> > 2010/1/27 Javier Collado 
> >>
> >> Hello,
> >>
> >> A test case for Windmill might also be used to extract the information
> >> that you're looking for.
> >>
> >> Best regards,
> >>Javier
> >>
> >> 2010/1/27 mierdatutis mi :
> >> > Those videos are generated by javascript.
> >> > There is some parser with python for javascript???
> >> >
> >> > Thanks a lot!
> >> >
> >> >
> >> > 2010/1/27 Simon Brunning 
> >> >>
> >> >> 2010/1/27 mierdatutis mi :
> >> >> > Hi,
> >> >> >
> >> >> > I would like to parse a webpage to can get the url of the video
> >> >> > download. I
> >> >> > use pyhton and firebug but I cant get the url link.
> >> >> >
> >> >> > Example:
> >> >> >
> >> >> > The url where I have to get the video link is:
> >> >> >
> >> >> >
> >> >> >
> http://www.rtve.es/mediateca/videos/20100125/saber-comer---salsa-verde-judiones-25-01-10/676590.shtml
> "
> >> >> >
> >> >> > The video is
> >> >> > http://www.rtve.es/resources/TE_SSAC011/flv/8/2/1264426362028.flv
> >> >> > Could you help me please?
> >> >>
> >> >> That URL doesn't appear to be in the HTML - it must be being brought
> >> >> in by the JavaScript somehow.
> >> >>
> >> >> --
> >> >> Cheers,
> >> >> Simon B.
> >> >> --
> >> >> http://mail.python.org/mailman/listinfo/python-list
> >> >
> >> >
> >> > --
> >> > http://mail.python.org/mailman/listinfo/python-list
> >> >
> >> >
> >> --
> >> http://mail.python.org/mailman/listinfo/python-list
> >
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
> >
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Daniel Fetchinson]

>>> * Print is now a function. Great, much improvement.
> Actually not, IMHO. All it does is is to provide incompatibility.

 What incompatibility are you exactly talking about?

 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

 Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?
>>> I gather that your example is about code that technically executes fine
>>> with
>>> both versions and produces the same result, i.e. that there is a subset
>>> with
>>> the
>>> same syntax and semantics.
>>>
>>> But 'print' calls that technically execute fine with both versions may
>>> and
>>> will
>>> in general produce different results.
>>>
>>> I.e. not just the syntax but also the semantics have changed:
>>>
>>>
>>>  >>> import sys
>>>  >>> sys.version
>>> '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
>>>  >>>
>>>  >>> print( "2+2 =", 2+2 )
>>> ('2+2 =', 4)
>>>  >>> _
>>>
>>>
>>>  >>> import sys
>>>  >>> sys.version
>>> '3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
>>>  >>>
>>>  >>> print( "2+2 =", 2+2 )
>>> 2+2 = 4
>>>  >>> _
>>
>> True. However, as someone else pointed out in a neighbouring thread you
>> can do
>>
>> 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.
> from __future__ import print_function
> print( "2+2 =", 2+2 )
>> 2+2 = 4
>>
>> which gives 100% compatibility as far as print is concerned between 2.6
>> and 3.x.
>
> That makes the code behave with 3.x syntax and semantics regarding print.
> I.e. it chooses one language.
>
> It doesn't make them compatible:

Of course it makes them compatible. I'm not saying any print-related
code in python 2.6 is valid python 3 code, but that it is *possible*
to write print-related code in python 2.6 that is also valid in python
3.

> if they were, then you wouldn't have to choose.

It seems to me you are arguing with the statement "Any print-related
python 2.6 code is valid python 3 code". Nobody is making this
statement. Let me repeat, what you should be arguing with is "It is
possible to write print-related python 2.6 code that is also valid
python 3 code". Perhaps I didn't make myself clear before, but at
least now I hope it's clear what I mean.

Cheers,
Daniel

> For example, it doesn't fix up 2.x code that prints tuples: incompatible, it
> will still execute but no longer do what it was supposed to do.
>
> But lest you focus down on that rare case, consider 2.x code that contains
>
>print "2+2", 2
>
> All such statements need to be fixed up in a 2->3 transition. Adding
> __future__
> just makes the code invalid, it doesn't give you any shred of compatibility
> for
> this. A code rewrite can be partially automated like 2to3 but the
> incompatibility needlessly introduces an additional set of things that Can
> Go
> Wrong(TM), and with Murphy present, as He always is, well.
>
>
>> So again, what sort of an incompatibility are you talking about
>> concerning 'print' between 2.6 and 3.x?
>
> Syntax and semantics. They're different.


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

GUI-pyqt solution needed

[Chirag Dhyani]

Hi,

My sincere apologies if I am mailing in wrong list.

My mission:I have to develop GUI based tool on python and will be using
PyQT with qtdesigner. I am automating creation of test script for call flows
just by drawing them from tool.

Challenges: In this tool there will be a drawing area where I should
have to utility to create call flow by drag and droping the elements. I will
have a small database from which relevent piece of codes will be retrieved
during the execution time and the script will be retrieved.

I know that I will be quering the database based on cordinates so think that
cordinate programming will be the correct solution. However, can anybody
have idea for the ideal solution that can be?

Thank you in advance.
Chi
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Library support for Python 3.x

[Aahz]

In article <9f3c3$4b605a65$4275d90a$30...@fuse.net>,
Kevin Walzer   wrote:
>
>I'm going to be starting some new Python projects in Python 2.6, but am 
>concerned that at least three of the libraries I will be 
>using--pycrypto, paramiko and feedparser--are not currently supported in 
>Python 3.x. The authors of these programs have not given any indication 
>that work is underway to support Python 3.x. Eventually I plan to 
>migrate to Python 3.x.
>
>I don't want to be stuck using libraries that may not be updated for the 
>next generation of Python. How are others handling this issue?

>From my POV, your question would be precisely identical if you had
started your project when Python 2.3 was just released and wanted to
know if the libraries you selected would be available for Python 2.6.

Choose the best libraries for your circumstances now and worry about the
future later.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

import antigravity
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple Password Strength Checker Review Help needed

[Aahz]

In article <7xfx5sxbmw@ruckus.brouhaha.com>,
Paul Rubin   wrote:
>
>From a security point of view, the concept
>of "password strength checking" is pretty dubious.  If you want secure
>passwords, generate them from a random number source and assign them to
>the users.  Don't have the users make up their own passwords.  It's
>relatively (compared to using a computer file exposed to remote internet
>attacks) for users to write down the the random passwords on paper, as
>long as they're a little bit careful.  As Bruce Schneier put it:
>
>"My wallet is already a secure container; it has valuable things in
>it, and I have a lifetime of experience keeping it safe. Adding a
>piece of paper with my passwords seems like a natural thing to do."

Actually, I treat my wallet as a source of trouble and only keep
replaceable items in it.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

import antigravity
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Daniel Fetchinson:

* Print is now a function. Great, much improvement.

Actually not, IMHO. All it does is is to provide incompatibility.

What incompatibility are you exactly talking about?

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

Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

I gather that your example is about code that technically executes fine
with
both versions and produces the same result, i.e. that there is a subset
with
the
same syntax and semantics.

But 'print' calls that technically execute fine with both versions may
and
will
in general produce different results.

I.e. not just the syntax but also the semantics have changed:


 >>> import sys
 >>> sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
 >>>
 >>> print( "2+2 =", 2+2 )
('2+2 =', 4)
 >>> _


 >>> import sys
 >>> sys.version
'3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
 >>>
 >>> print( "2+2 =", 2+2 )
2+2 = 4
 >>> _

True. However, as someone else pointed out in a neighbouring thread you
can do

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.

from __future__ import print_function
print( "2+2 =", 2+2 )

2+2 = 4

which gives 100% compatibility as far as print is concerned between 2.6
and 3.x.

That makes the code behave with 3.x syntax and semantics regarding print.
I.e. it chooses one language.

It doesn't make them compatible:


Of course it makes them compatible. I'm not saying any print-related
code in python 2.6 is valid python 3 code, but that it is *possible*
to write print-related code in python 2.6 that is also valid in python
3.


if they were, then you wouldn't have to choose.


It seems to me you are arguing with the statement "Any print-related
python 2.6 code is valid python 3 code". Nobody is making this
statement. Let me repeat, what you should be arguing with is "It is
possible to write print-related python 2.6 code that is also valid
python 3 code". Perhaps I didn't make myself clear before, but at
least now I hope it's clear what I mean.


Perhaps we're in violent agreement. :-)

However, the root node of this subthread was my statement about the needless 
incompatibility introduced by changing print in 3.x, whether that statement was 
correct or reasonable / whatever.


The main problem with the incompatibility is for porting code, not for writing 
code from scratch. It's also a problem wrt. learning the language. And I see no 
good reason for it: print can't really do more, or less, or more conveniently 
(rather, one has to write a bit more now for same effect).



Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Ad hoc lists vs ad hoc tuples

[Antoine Pitrou]

Le Wed, 27 Jan 2010 02:20:53 -0800, Floris Bruynooghe a écrit :
> 
> Is a list or tuple better or more efficient in these situations?

Tuples are faster to allocate (they are allocated in one single step) and 
quite a bit smaller too.
In some situations, in Python 2.7 and 3.1, they can also be ignored by 
the garbage collector, yielding faster collections.

(not to mention that they are hashable, which can be useful)


-- 
http://mail.python.org/mailman/listinfo/python-list

Extract half screen of a video

[aditya shukla]

Hello Guys,

I have a video and what I want is to extract only half of the screen of
it.By half screen i mean when i run the video i can say the left half(from
the monitor's screen) of the video and dump the right half.


Thanks

Aditya
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steve Holden]

Alf P. Steinbach wrote:
[...]
> The main problem with the incompatibility is for porting code, not for
> writing code from scratch. It's also a problem wrt. learning the
> language. And I see no good reason for it: print can't really do more,
> or less, or more conveniently (rather, one has to write a bit more now
> for same effect).

Of course it can do more: it allows you to layer your own print
functionality into the system much more easily than you could with the
print statement.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Steve Holden:

Alf P. Steinbach wrote:
[...]

The main problem with the incompatibility is for porting code, not for
writing code from scratch. It's also a problem wrt. learning the
language. And I see no good reason for it: print can't really do more,
or less, or more conveniently (rather, one has to write a bit more now
for same effect).


Of course it can do more: it allows you to layer your own print
functionality into the system much more easily than you could with the
print statement.


Yeah, point. Very minor though. :-)


Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: site.py confusion

[Arnaud Delobelle]

George Trojan  writes:

> Inspired by the 'Default path for files' thread I tried to use
> sitecustomize in my code. What puzzles me is that the site.py's main()
> is not executed. My sitecustomize.py is
> def main():
> print 'In Main()'
> main()
> and the test program is
> import site
> #site.main()
> print 'Hi'
> The output is
> $ python try.py
> Hi

That's normal as site.py is automatically imported on initialisation.
So when you do:

import site

the module is not re-executed as it already has been imported.
Try this:

 file: foo.py
print 'Foo'
 end

--- Interactive session
>>> import foo # First time, print statement executed
Foo
>>> import foo # Second time, print statement not executed
>>>

> When I uncomment the site.main() line the output is
> $ python try.py
> In Main()
> Hi

Now you explicitely call site.main(), so it executes it!

> If I change import site to import sitecustomize the output is as
> above. What gives?

It's normal, this time it's the first time you import it so its content
is executed.

HTH

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I really need webbrowser.open('file://') to open a web browser

[Mitchell L Model]

On Jan 15, 2010, at 3:59 PM, Timur Tabi 


After reading several web pages and mailing list threads, I've learned
that the webbrowser module does not really support opening local
files, even if I use a file:// URL designator.  In most cases,
webbrowser.open() will indeed open the default web browser, but with
Python 2.6 on my Fedora 10 system, it opens a text editor instead.  On
Python 2.5, it opens the default web browser.

This is a problem because my Python script creates a local HTML file
and I want it displayed on the web browser.

So is there any way to force webbrowser.open() to always use an actual
web browser?


I had some discussions with the Python documentation writers that led  
to the following note being included in the Python 3.1 library  
documentation for webbrowser.open: "Note that on some platforms,  
trying to open a filename using this function, may work and start the  
operating system’s associated program. However, this is neither  
supported nor portable." The discussions suggested that this lack of  
support and portability was actually always the case and that the  
webbrowser module is simply not meant to handle file URLs. I had taken  
advantage of the accidental functionality to generate HTML reports and  
open them, as well as to open specific documentation pages from within  
a program.


You can control which browser opens the URL by using webbrowser.get to  
obtain a controller for a particular browser, specified by its  
argument, then call the open method on the controller instead of the  
module.


For opening files reliability and the ability to pick a particular  
program (browser or otherwise) to open it with you might have to  
resort to invoking a command line via subprocess.Popen.

--
http://mail.python.org/mailman/listinfo/python-list

Re: site.py confusion

[George Trojan]

Arnaud Delobelle wrote:

George Trojan  writes:


Inspired by the 'Default path for files' thread I tried to use
sitecustomize in my code. What puzzles me is that the site.py's main()
is not executed. My sitecustomize.py is
def main():
print 'In Main()'
main()
and the test program is
import site
#site.main()
print 'Hi'
The output is
$ python try.py
Hi


That's normal as site.py is automatically imported on initialisation.
So when you do:

import site

the module is not re-executed as it already has been imported.
Try this:

 file: foo.py
print 'Foo'
 end

--- Interactive session
>>> import foo # First time, print statement executed
Foo
>>> import foo # Second time, print statement not executed
>>>


When I uncomment the site.main() line the output is
$ python try.py
In Main()
Hi


Now you explicitely call site.main(), so it executes it!


If I change import site to import sitecustomize the output is as
above. What gives?


It's normal, this time it's the first time you import it so its content
is executed.

HTH

I understand that importing a module repeatedly does nothing. Also, I 
made a typo in my previous posting - I meant sitecustomize.main(), not 
site.main(). My understanding of the code in site.py is that when the 
module is imported, main() is executed. main() calls execsitecustomize() 
that attempts to import sitecustomize. That action should trigger 
execution of code in sitecustomize.py, which is located in the current 
directory. But that does not work. I changed execsitecustomize() to


def execsitecustomize():
"""Run custom site specific code, if available."""
try:
import sitecustomize
except ImportError:
pass
import sys
print sys.path
raise

That gave me the explanation why the above happens: when site is 
imported, the current directory is not yet prepended to sys.path.


$ python2.6 -v try.py
...
 ['/usr/local/Python-2.6.3/lib/python26.zip', 
'/usr/local/Python-2.6.3/lib/python2.6', 
'/usr/local/Python-2.6.3/lib/python2.6/plat-linux2', 
'/usr/local/Python-2.6.3/lib/python2.6/lib-tk', 
'/usr/local/Python-2.6.3/lib/python2.6/lib-old', 
'/usr/local/Python-2.6.3/lib/python2.6/lib-dynload', 
'/usr/local/Python-2.6.3/lib/python2.6/site-packages']

'import site' failed; traceback:
Traceback (most recent call last):
  File "/usr/local/Python-2.6.3/lib/python2.6/site.py", line 516, in 


main()
  File "/usr/local/Python-2.6.3/lib/python2.6/site.py", line 507, in main
execsitecustomize()
  File "/usr/local/Python-2.6.3/lib/python2.6/site.py", line 472, in 
execsitecustomize

import sitecustomize
...

This also explains the recipe http://code.activestate.com/recipes/552729/

I wanted to have library location specific to application without having 
to explicitly change sys.path in all App-Top-Dir/bin/*.py. I thought 
creating bin/sitecustomize.py would do the trick.


I guess the documentation should mention this fact. The comment in 
recipe 552729 is:


Since Python 2.5 the automatic import of the module "sitecustomize.py" 
in the directory of the main program is not supported any more (even if 
the documentation says that it is).


George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Library support for Python 3.x

[Paul Rubin]

a...@pythoncraft.com (Aahz) writes:
> From my POV, your question would be precisely identical if you had
> started your project when Python 2.3 was just released and wanted to
> know if the libraries you selected would be available for Python 2.6.

I didn't realize 2.6 broke libraries that had worked in 2.3, at least on
any scale.  Did I miss something?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Library support for Python 3.x

[exarkun]

On 07:03 pm, no.em...@nospam.invalid wrote:

a...@pythoncraft.com (Aahz) writes:

From my POV, your question would be precisely identical if you had
started your project when Python 2.3 was just released and wanted to
know if the libraries you selected would be available for Python 2.6.


I didn't realize 2.6 broke libraries that had worked in 2.3, at least 
on

any scale.  Did I miss something?


Lots of tiny things change.  Any of these can break a library.  With the 
3 releases between 2.3 and 2.6, there are lots of opportunities for 
these changes.  I don't know what you mean by "any scale", but I know 
that I've seen lots of things break on 2.6 that worked on 2.3, 2.4, or 
2.5.


Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list

Re: Library support for Python 3.x

[sjdevn...@yahoo.com]

On Jan 27, 2:03 pm, Paul Rubin  wrote:
> a...@pythoncraft.com (Aahz) writes:
> > From my POV, your question would be precisely identical if you had
> > started your project when Python 2.3 was just released and wanted to
> > know if the libraries you selected would be available for Python 2.6.
>
> I didn't realize 2.6 broke libraries that had worked in 2.3, at least on
> any scale.  Did I miss something?

I certainly had to update several modules I use (C extensions) to work
with the new memory management in a recent release (changing PyMem_Del
to Py_DECREF being a pretty common alteration); I can't remember
whether that was for 2.6 or 2.5.
-- 
http://mail.python.org/mailman/listinfo/python-list

Pyowa Meeting Next Monday

[Mike Driscoll]

Hi,

Next Monday, February 1st, we will be having our first Pyowa meeting
of 2010! It will be held at the Marshall County Sheriff's Office and
start at 7 p.m. (barring inclement weather). I will be demoing some
software I created for our Sheriff's office and will talk about the
various modules used to put it all together. We'll probably have
plenty of free time to chat and you can show off anything neat that
you've been doing too. I hope to see you there!


-
Mike Driscoll

Website: www.pyowa.org
Twitter: www.twitter.com/pyowa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Grant Edwards]

On 2010-01-27, Alf P. Steinbach  wrote:
> * Steve Holden:
>> Alf P. Steinbach wrote:
>> [...]
>>> The main problem with the incompatibility is for porting code, not for
>>> writing code from scratch. It's also a problem wrt. learning the
>>> language. And I see no good reason for it: print can't really do more,
>>> or less, or more conveniently (rather, one has to write a bit more now
>>> for same effect).
>> 
>> Of course it can do more: it allows you to layer your own print
>> functionality into the system much more easily than you could with the
>> print statement.
>
> Yeah, point. Very minor though. :-)

I don't think it's minor at all.  Being able to globally
redefine the behavior of "print" for all modules is a big win
when you want to import a module that's too chatty about what
it's doing.  The "right" way for modules to chatter about
internals is using the logging module, but not everybody
follows that convention.

-- 
Grant Edwards   grante Yow! Four thousand
  at   different MAGNATES, MOGULS
   visi.com& NABOBS are romping in my
   gothic solarium!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Adam Tauno Williams]

On Wed, 2010-01-27 at 18:52 +0100, Alf P. Steinbach wrote:
> * Steve Holden:
> > Alf P. Steinbach wrote:
> > [...]
> >> The main problem with the incompatibility is for porting code, not for
> >> writing code from scratch. It's also a problem wrt. learning the
> >> language. And I see no good reason for it: print can't really do more,
> >> or less, or more conveniently (rather, one has to write a bit more now
> >> for same effect).
> > Of course it can do more: it allows you to layer your own print
> > functionality into the system much more easily than you could with the
> > print statement.
> Yeah, point. Very minor though. :-)

So you get to determine that?

I'd call the whole print thing (a) a legitimate change to increase
consistency and (b) a fairly minor porting nuisance since application
code [as in big-chunks-o-code] almost never contains print statements.
I know at least two shops that have scripts they run on all Python code,
prior to it entering production, to ensure there are no print
statements.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple Password Strength Checker Review Help needed

[John Nagle]

Mallikarjun(ಮಲ್ಲಿಕಾರ್ಜುನ್) wrote:

Dear friends,
 I am newbie to Python + pygtk + Glade and recently wrote a simple password
strength checker app.
Since this is my first app/program, can someone review my code (just over
150 lines) and help me improve my programming capabilities


   Here's my classic "Obvious password detector":

http://www.animats.com/source/obvious/obvious.c

This prevents dictionary attacks using an English dictionary, but
needs only a small bit table and does no I/O.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: Library support for Python 3.x

[Mike C. Fletcher]

Kevin Walzer wrote:
> I'm going to be starting some new Python projects in Python 2.6, but
> am concerned that at least three of the libraries I will be
> using--pycrypto, paramiko and feedparser--are not currently supported
> in Python 3.x. The authors of these programs have not given any
> indication that work is underway to support Python 3.x. Eventually I
> plan to migrate to Python 3.x.
>
> I don't want to be stuck using libraries that may not be updated for
> the next generation of Python. How are others handling this issue?
>
> --Kevin
Some of us are saying:

* When Python 3.x has something compelling to offer:
  o Users will start asking for Python 3.x with a *reason* to
justify the cost
  o Libraries will begin to see the pain of porting, and most
importantly, *maintaining*, as a reasonable trade-off
  o Libraries will port (and maintain)
  o Applications should *then* port
* or When everyone is already on a (basically) compatible 2.x
  version (i.e. 2.6+); say in 3 years:
  o Conversion and maintenance costs will lower to the point
where we can justify them for libraries

Python 3.x has very little that is a compelling use-case (versus 2.x)
for most people I've talked to.  My paying customers aren't screaming
"we want to spend a week of your time to rewrite, re-test and re-deploy
our working code into Python 3.x so that it can do exactly the same
thing with no visible benefit and lots of likely subtle failures". 
Unicode-as-default doesn't really make customers say "wow" when all
their Unicode-needing code is already Unicode-using.  A few syntax
changes here and there... well, no, they certainly don't care (can't say
I *really* do either).  The initial marked slowdown for 3.0 (which I
gather should be mostly fixed in 3.1) didn't do much of a sales-job either.

Possible compelling arguments that would get people to convert (with the
projects working on them):

* 5x (or more) speedup (PyPy, Unladen Swallow)
* adaptive parallelization/execution-kernel mechanism as a
  first-class primitive (Apple's C extensions for OpenCL)
* continuation-like mechanisms, anonymous code blocks a-la Ruby
  (PyPy, Stackless)
* (free) threading, GIL removal (IronPython, Jython)
* compilation-to-native (PyPy)
* compilation to mobile-platform native (PyPy?)

None of those in in Python 3.x, though there's talk of merging Unladen
Swallow into CPython to provide a carrot for conversions (though AFAIK
it's not yet a 5x improvement across the board).  To compound the
problem, Python 3.x doesn't include any of the syntax changes you'd want
to see to support e.g. anonymous blocks, continuations, OpenCL
integration, etceteras... so if we want those, we're going to have to
either introduce new syntax (which is blocked) or hack it in... which we
could do on Python 2.x too.

I don't know about other maintainers, but I've started running PyOpenGL
tests with -3 on Python 2.6 to get a feel for how many issues are going
to come up.  Most have been minimal.  But when I sit down and actually
consider *maintaining* a 3.x release when I'm already *barely* able to
keep up with the 2.x maintenance in my tiny amounts of free time...
well... I do *that* stuff for *fun* after all, and double the headaches
for no noticeable benefit doesn't really sound like fun... oh, and numpy
isn't ported, so screw it ;) ...

Interestingly, at PyGTA Myles mentioned that he'd found his first-ever
Python 3.x-only library!  Which he then converted to Python 2.x, because
he actually wanted to use it in real code :) .

Projects which haven't ported to Python 3.x aren't necessarily dead,
they're just not nailed to that particular perch (yet),
Mike

-- 

  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I really need webbrowser.open('file://') to open a web browser

[Timur Tabi]

On Wed, Jan 27, 2010 at 12:29 PM, Mitchell L Model  wrote:

> I had some discussions with the Python documentation writers that led to the
> following note being included in the Python 3.1 library documentation for
> webbrowser.open: "Note that on some platforms, trying to open a filename
> using this function, may work and start the operating system’s associated
> program. However, this is neither supported nor portable."

Then they should have renamed the API.  I appreciate that they're
finally documenting this, but I still think it's a bunch of baloney.

> You can control which browser opens the URL by using webbrowser.get to
> obtain a controller for a particular browser, specified by its argument,
> then call the open method on the controller instead of the module.

How can I know which controller (application) the system will use when
it opens an http URL?  I depend on webbrowser.open('http') to choose
the best web browser on the installed system.  Does webbrowser.get()
tell me which application that will be?

> For opening files reliability and the ability to pick a particular program
> (browser or otherwise) to open it with you might have to resort to invoking
> a command line via subprocess.Popen.

But that only works if I know which application to open.

-- 
Timur Tabi
Linux kernel developer at Freescale
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[John Nagle]

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.

FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

2.  Python 3 is supported by multiple Python implementations.

FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
PyPy, and Jython have all stayed with 2.x versions of Python.

3.  Python 3 is supported by most 3rd party Python packages.

FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

Arguably, Python 3 has been rejected by the market.  Instead, there's
now Python 2.6, Python 2.7, and Python 2.8.  Python 3 has turned into
a debacle like Perl 6, now 10 years old.

That's the reality, Python 3 fanboys.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Grant Edwards]

On 2010-01-27, John Nagle  wrote:

> Arguably, Python 3 has been rejected by the market.

Let's just say that it hasn't yet been accepted by the market. ;)

> Instead, there's now Python 2.6, Python 2.7, and Python 2.8.
> Python 3 has turned into a debacle like Perl 6, now 10 years
> old.

I think I'd have to wait a couple more years before making that
sort of pronouncement.

That said, I don't expect to start using Python 3 until library
availability or my Linux distro forces me to.

-- 
Grant Edwards   grante Yow! Inside, I'm already
  at   SOBBING!
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: starting a thread in a nother thread

[John Nagle]

Stefan Behnel wrote:

Richard Lamboj, 27.01.2010 15:23:

Am Wednesday 27 January 2010 14:10:13 schrieb Stefan Behnel:

Richard Lamboj, 27.01.2010 14:06:

just for _curiosity_. What would be if i start a thread in a nother
thread and acquire a lock in the "child" thread. Is there anything that
could go wrong if someone try to start threads in threads?

There's usually tons of things that can go wrong w.r.t. threads:

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

However, there's nothing special to a thread that was started from another
thread, so the problems don't change.

i have tried a little bit around with psycopg2 and threads,

I'am sharing one connection for all threads. When i'am starting the 
threads "normal" everything works without any Problem. When i'am starting the 
threads from another thread than i got a "segmentation fault"


Sounds like a bug that you might want to report to the maintainers of psycopg2.

Stefan


  If a C package called from Python crashes, the package is defective.
Nothing you can do from Python should be able to cause a segmentation fault.

Google search: "Results 1 - 10 of about 29,400 for psycopg2 crash".

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: Library support for Python 3.x

[John Nagle]

Kevin Walzer wrote:
I'm going to be starting some new Python projects in Python 2.6, but am 
concerned that at least three of the libraries I will be 
using--pycrypto, paramiko and feedparser--are not currently supported in 
Python 3.x. The authors of these programs have not given any indication 
that work is underway to support Python 3.x. Eventually I plan to 
migrate to Python 3.x.


   Maybe by 2015 or so, that might be feasible.  Wait until Python 3.x
ships as standard with major Linux distros.  Right now, 2.4 or 2.5 is
the production version of Python.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Adam Tauno Williams]

On Wed, 2010-01-27 at 12:56 -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.
>   FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

CentOS:  python26-2.6.4-1.ius.parallel.el5  

openSUSE: python-2.6.2-6.3.i586, python3-3.1-3.3.i586

Darn, those pesky facts.

> 2.  Python 3 is supported by multiple Python implementations.
>   FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
>   PyPy, and Jython have all stayed with 2.x versions of Python.

And of all Python development what percentage takes place on all those
combined?  2%?  Maybe.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[sjdevn...@yahoo.com]

On Jan 27, 9:22 am, 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.

I think you're misunderstanding what "compatibility" means in a
programming language context.  Python 3 and Python 2 are not mutually
compatible, as arbitrary programs written in one will not run in the
other.  The most important fallout of that is that Python 3 is not
backwards compatible, in that existing Python 2 programs won't run
unaltered in Python 3--while it's easy to write a new program in a
subset of the languages that runs on both Python 2 and 3, the huge
existing codebase of Python 2 code won't run under Python 3.

That there exists an intersection of the two languages that is
compatible with both doesn't make the two languages compatible with
each other--although it being a fairly large subset does help mitigate
a sizable chunk of the problems caused by incompatibility (as do tools
like 2to3).

In your example, a python2 program that uses print and division will
fail in python3.  The print problem is less significant, since the
failure will probably be a syntax error or a rapid exception raised.
The division problem is more problematic, since a program may appear
to run fine but silently misbehave; such errors are much more likely
to result in significant damage to data or other long-term badness.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: C Structure rebuild with ctypes

[Georg]

Hi Mark,

many thanks for your hints.

> --- func.py --
> import ctypes as c
>
> # int func (int numVars, char **varNames, int *varTypes)
>
> INT = c.c_int
> PINT = c.POINTER(INT)
> PCHAR = c.c_char_p
> PPCHAR = c.POINTER(PCHAR)
>
> func = c.CDLL('func').func
> func.restype = None
> func.argtypes = [INT,PPCHAR,PINT]
>
> numVars = 3
> varNames = (PCHAR * numVars)('abc','def','ghi')
> varTypes = (INT * numVars)(1,2,3)
>
> func(numVars,varNames,varTypes)

The function to call has the following signiture:

int SetVarLabel(int handle, const char *varName, const char *varLabel)

I did as you suggested by doing the following:

INT = c_int
PCHAR = c_char_p

libc.argtypes = [INT,PCHAR,PCHAR]

vn = create_string_buffer("var1")
vl = create_string_buffer("Label")

print "vn: ", vn.value
print "vl: ", vl.value

returnCode = libc.SetVarLabel(h,byref(vn), byref(vl))
print "Return Code: ", returnCode

The return code is always "variable not found". Thus my call to the C 
library is not working.

What do I do wrong?

Best regards

Georg


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Ben Finney]

John Nagle  writes:

> Myths about Python 3:
>   
> 1.  Python 3 is supported by major Linux distributions.
>
>   FALSE - most distros are shipping with Python 2.4, or 2.5 at
>   best.

There's a big difference between “What list of versions of Python does
 ship with?” versus “Which one version of Python does  use
for its implementation of ‘python’?”. I think the latter is the more
pertinent question.

Do you have evidence to back up a claim (not that I'm saying you have
necessarily made the claim; it's not clear from what you wrote) that
most operating systems use Python 2.4 as their implementation of
‘python’?

-- 
 \  “Anyone who believes exponential growth can go on forever in a |
  `\finite world is either a madman or an economist.” —Kenneth |
_o__) Boulding |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Benjamin Kaplan]

On Wed, Jan 27, 2010 at 3:56 PM, 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.
>
>        FALSE - most distros are shipping with Python 2.4, or 2.5 at best.
>
The latest versions of Ubuntu Jaunty and Karmic, Fedora 11 and 12, and
OpenSUSE 11.2 all use Python 2.6. Ubuntu has been shipping python 3
since Jaunty came out last April. According to Fedora's package index,
Python 3 is in the devel version which probably means it will be in
upcoming versions of Fedora as well.


> 2.  Python 3 is supported by multiple Python implementations.
>
>        FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
>        PyPy, and Jython have all stayed with 2.x versions of Python.
>
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.

> 3.  Python 3 is supported by most 3rd party Python packages.
>
>        FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.
>
> Arguably, Python 3 has been rejected by the market.  Instead, there's
> now Python 2.6, Python 2.7, and Python 2.8.  Python 3 has turned into
> a debacle like Perl 6, now 10 years old.
>

Give the package maintainers time to update. There were some pretty
big changes to the C API. Most of the major 3rd party packages like
numpy and MySQLdb have already commited to having a Python 3 version.
They just haven't gotten them out yet.

> That's the reality, Python 3 fanboys.
>
>                                John Nagle
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Christian Heimes]

John Nagle wrote:
> 1.  Python 3 is supported by major Linux distributions.
> 
>   FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

You are wrong. Modern versions of Debian / Ubuntu are using Python 2.6.
My Ubuntu box has python3.0, too.

> 2.  Python 3 is supported by multiple Python implementations.
> 
>   FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
>   PyPy, and Jython have all stayed with 2.x versions of Python.

You are wrong again. We have an active discussion on the Python
developer mailinglist to integrate Unladen Swallow into py3k, see
http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/
. The other implementations have been planing Python 3.x support for
more than a year.

> 
> 3.  Python 3 is supported by most 3rd party Python packages.
> 
>   FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

Python 3.x has builtin support for several aspects of OpenSSL. Other
important projects like Cython, lxml, some Postgres DBAs, Django,
mod_wsgi and many more have been ported to Python 3.x for more than a
year. In fact Graham has helped us to identify several issues in 3.0
beta while he was porting mod_wsgi to Python 3.0.

(Personally I neither see MySQL as mission critical nor as a powerful
RDBMS. Just try to combine foreign keys with triggers and you'll see
what I'm talking about. *scnr*)

Christian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Ben Finney]

Adam Tauno Williams  writes:

> On Wed, 2010-01-27 at 12:56 -0800, John Nagle wrote:
> > 2.  Python 3 is supported by multiple Python implementations.
> > FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
> > PyPy, and Jython have all stayed with 2.x versions of Python.
>
> And of all Python development what percentage takes place on all those
> combined?

That's irrelevant to the point, though. Regardless of how small the
minority of developers on the platform, it clearly matters to those
developers which versions of Python they can use.

-- 
 \   “When I get new information, I change my position. What, sir, |
  `\ do you do with new information?” —John Maynard Keynes |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Ben Finney]

Christian Heimes  writes:

> John Nagle wrote:
> > 1.  Python 3 is supported by major Linux distributions.
> > 
> > FALSE - most distros are shipping with Python 2.4, or 2.5 at best.
>
> You are wrong. Modern versions of Debian / Ubuntu are using Python
> 2.6.

Only if by “modern” you mean “not released yet”.

The latest stable Debian (Debian 5.0, Lenny) has only Python 2.4 and
Python 2.5. It does not have Python 2.6 at all, and until this month
Python 2.6 was not even in the in-development suite of Debian.

Fortunately, Debian Squeeze now finally has added Python 2.6 (though
currently ‘python’ still uses Python 2.5). But Squeeze is currently a
long way from being released.

Python 3 is in the play-pen of Debian “unstable”, but only arrived this
week. It's even further from being released; it has to pass the filter
from “unstable” to “testing” before it gets consideration for that.

So I think your statement above is at least a mischaracterisation of the
truth.

-- 
 \ “As scarce as truth is, the supply has always been in excess of |
  `\   the demand.” —Josh Billings |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Adam Tauno Williams:

On Wed, 2010-01-27 at 18:52 +0100, Alf P. Steinbach wrote:

* Steve Holden:

Alf P. Steinbach wrote:
[...]

The main problem with the incompatibility is for porting code, not for
writing code from scratch. It's also a problem wrt. learning the
language. And I see no good reason for it: print can't really do more,
or less, or more conveniently (rather, one has to write a bit more now
for same effect).

Of course it can do more: it allows you to layer your own print
functionality into the system much more easily than you could with the
print statement.

Yeah, point. Very minor though. :-)


So you get to determine that?


I'm sorry, I don't find that question meaningful.



I'd call the whole print thing (a) a legitimate change to increase
consistency and (b) a fairly minor porting nuisance since application
code [as in big-chunks-o-code] almost never contains print statements.
I know at least two shops that have scripts they run on all Python code,
prior to it entering production, to ensure there are no print
statements.



Considering that in your opinion "application code [as in big-chunks-o-code] 
almost never contains print statements", is the point about being able to 
replace print, as you see it, more than a minor point?



Cheers & sorry for not grokking your question,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Adam Tauno Williams]

On Wed, 2010-01-27 at 16:25 -0500, Benjamin Kaplan wrote:
> On Wed, Jan 27, 2010 at 3:56 PM, John Nagle  wrote:
> Give the package maintainers time to update. There were some pretty
> big changes to the C API. Most of the major 3rd party packages like
> numpy and MySQLdb have already commited to having a Python 3 version.
> They just haven't gotten them out yet.

PostgreSQL support is available for Python3.  

Just switch to using a real database and one of you problems is
solved. :)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I really need webbrowser.open('file://') to open a web browser

[Mitchell L Model]

On Jan 27, 2010, at 3:31 PM, Timur Tabi wrote:

On Wed, Jan 27, 2010 at 12:29 PM, Mitchell L Model  
 wrote:


I had some discussions with the Python documentation writers that  
led to the
following note being included in the Python 3.1 library  
documentation for
webbrowser.open: "Note that on some platforms, trying to open a  
filename
using this function, may work and start the operating system’s  
associated

program. However, this is neither supported nor portable."


Then they should have renamed the API.  I appreciate that they're
finally documenting this, but I still think it's a bunch of baloney.


I agree, but I am pretty sure that, based on the discussions I had  
with the Python
documenters and developers, that there's no hope of winning this  
argument.
I suppose that since a file: URL is not, strictly speaking, on the  
web, that it
shouldn't be opened with a "web" browser. It's just that the "web"  
part of

"web browser" became more or less obsolete a long time ago since there
are so many more ways of using browsers and so many more things they can
do then just browse the web. So if you interpret the name "webbrowser"  
to mean
that it browses the web, as opposed to files, which means going  
through some
kind of server-based protocol, the module does what it says. But I  
still like
the idea of using it to open files, especially when I want the file to  
be opened

by its associated application and not a browser.



You can control which browser opens the URL by using webbrowser.get  
to
obtain a controller for a particular browser, specified by its  
argument,

then call the open method on the controller instead of the module.


How can I know which controller (application) the system will use when
it opens an http URL?  I depend on webbrowser.open('http') to choose
the best web browser on the installed system.  Does webbrowser.get()
tell me which application that will be?


webbrowser.get() with no arguments gives you the default kind of
browser controller, just as if you had used webbrowser.open()
directly.



For opening files reliability and the ability to pick a particular  
program
(browser or otherwise) to open it with you might have to resort to  
invoking

a command line via subprocess.Popen.


But that only works if I know which application to open.


Aha. You could use subprocess to specify the application from within  
your Python code,
but not to indicate "the user's default browser", unless the platform  
has a command for that.

On OS X, for instance, the command line:
open file.html
opens file.html with the application the user has associated with html  
files, whereas

open -a safari file.html
will open it with Safari even if the user has chosen Firefox for html  
files. There's
stuff like this for Windows, I suppose, but hardly as convenient. And  
I think that

Linux environments are all over the place on this, but I'm not sure.

webbrowser.get() returns a control object of the default class for the  
user's environment --

the one that means "use the default browser" so it won't help.
--
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Carl Banks]

On Jan 27, 12:56 pm, John Nagle  wrote:
> Arguably, Python 3 has been rejected by the market.

No it's not fathomably arguable, because there's no reasonable way
that Python 3 could have fully replaced Python 2 so quickly.

At best, you could reasonably argue there hasn't been enough time to
tell.


> Instead, there's
> now Python 2.6, Python 2.7, and Python 2.8.

It was always the plan to continue developing Python 2.x alongside
Python 3.x during the transition period.

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.


> Python 3 has turned into
> a debacle like Perl 6, now 10 years old.

Perl 6 has never been released.  The situations aren't even
comparable.


> That's the reality, Python 3 fanboys.

You're the fanboy, fanboi.  You are so hellbent on badmouthing Python
3 that you throw three ridiculous, straw-grasping arguments at us.

Here's the real reality.

Python 3 is going to replace Python 2, and it has nothing to do with
technical merit.  The developers are planning to stop development on
2.x line, and only continue with 3.x, so anyone who wants to stay
current--which is most people--with Python will have to use 3.x.
There is no hope that developers will be pressured by the market to
change their plans; we would have seen enough of a backlash by now.
There is also no hope someone will fork Python 2.x and continue it in
perpetuity.  Well, someone might try to fork it, but they won't be
able to call it Python.  No, don't be silly, a fork of Python not
called Python won't gain market share.

So rail if it makes you feel better but you've already lost.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ad hoc lists vs ad hoc tuples

[Terry Reedy]

On 1/27/2010 12:32 PM, Antoine Pitrou wrote:

Le Wed, 27 Jan 2010 02:20:53 -0800, Floris Bruynooghe a écrit :


Is a list or tuple better or more efficient in these situations?


Tuples are faster to allocate (they are allocated in one single step) and
quite a bit smaller too.
In some situations, in Python 2.7 and 3.1, they can also be ignored by
the garbage collector, yielding faster collections.

(not to mention that they are hashable, which can be useful)


Constant tuples (a tuple whose members are all seen as constants by the 
compiler) are now pre-compiled and constructed once and put into the 
code object as such rather than re-constructed with each run of the code.


>>> from dis import dis
>>> def l(): return [1,2,3]

>>> def t(): return 1,2,3

>>> dis(l)
  1   0 LOAD_CONST   1 (1)
  3 LOAD_CONST   2 (2)
  6 LOAD_CONST   3 (3)
  9 BUILD_LIST   3
 12 RETURN_VALUE
>>> dis(t)
  1   0 LOAD_CONST   4 ((1, 2, 3))
  3 RETURN_VALUE
>>> # 3.1

Terry Jan Reedy


--
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[exarkun]

On 10:07 pm, pavlovevide...@gmail.com wrote:

On Jan 27, 12:56�pm, John Nagle  wrote:

Arguably, Python 3 has been rejected by the market.


No it's not fathomably arguable, because there's no reasonable way
that Python 3 could have fully replaced Python 2 so quickly.

At best, you could reasonably argue there hasn't been enough time to
tell.

�Instead, there's
now Python 2.6, Python 2.7, and Python 2.8.


It was always the plan to continue developing Python 2.x alongside
Python 3.x during the transition period.

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.  As far as I can 
tell, it's based on the personal desire of many of the core developers 
to stop bothering with 2.x.  In other words, it's more a gauge of 
adoption of Python 3 amongst Python core developers.


Jean-Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I really need webbrowser.open('file://') to open a web browser

[Paul Boddie]

On 27 Jan, 23:00, Mitchell L Model  wrote:
>
> I suppose that since a file: URL is not, strictly speaking, on the  
> web, that it shouldn't be opened with a "web" browser.

But anything with a URL is (or should be regarded as being) on the
Web. It may not be anything more than a local resource and thus have
no universal or common meaning - someone else may not be able to
resolve the URL to a file at all, or it may resolve to a different
file - but it's part of the Web as observed by one party.

Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: some turtle questions

[Lee Harr]

> I am trying to think of things to do with the turtle module

> 1) is there a way to determine the current screen pixel color?


This would not use the included turtle module, but you could use
the turtle module from the pygsear collection:

http://www.nongnu.org/pygsear/

It requires pygame, but if you have that installed already it is
pretty easy to get it working.


Code to get a drawn color would look like:

>>> from pygsear.Drawable import Turtle
>>> t=Turtle()
>>> t.bg.get_at((0,0))
(0, 0, 0, 255)
>>> t.forward(100)
>>> t.position
[400.0, 200.0]
>>> t.bg.get_at((400,300))
(255, 255, 255, 255)
>>> t.left(90)
>>> t.set_color((255,0,0))
>>> t.forward(100)
>>> t.position
[300.0, 200.0]
>>> t.bg.get_at((350,200))
(255, 0, 0, 255)
>>>



> 2) is there a way to put a limit on the extent the turtle can
> travel? it seems I can keep moving off of the screen.

You could write a subclass for interactive use. Maybe like this:

from pygsear.Drawable import Turtle
class T2(Turtle):
    def forward(self, dist):
    Turtle.forward(self, dist)
    if not self.onscreen(slack=10):
    self.backward(dist)


... but I'm not sure that's the best approach. Often when doing
something interesting the turtle will go offscreen for a bit and
come back later to finish up the visible portion of his drawing.

  
_
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Mensanator]

On Jan 27, 2:56 pm, 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.
>
>         FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

So? I use Mac OSX 10.6, not Linux. And that comes with 2.6.
Nothing stopped me from adding 3.1.

>
> 2.  Python 3 is supported by multiple Python implementations.
>
>         FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
>         PyPy, and Jython have all stayed with 2.x versions of Python.

So? I only use CPython.

>
> 3.  Python 3 is supported by most 3rd party Python packages.
>
>         FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

So? The only 3rd party module I use is gmpy, and that's been updated
to 3.x.

>
> Arguably, Python 3 has been rejected by the market.  Instead, there's
> now Python 2.6, Python 2.7, and Python 2.8.  Python 3 has turned into
> a debacle like Perl 6, now 10 years old.
>
> That's the reality, Python 3 fanboys.

Maybe in *your* world. I'm perfectly happy in my world using 3.1.

>
>                                 John Nagle

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Terry Reedy]

On 1/27/2010 3:56 PM, John Nagle wrote:


2. Python 3 is supported by multiple Python implementations.

FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow,
PyPy, and Jython have all stayed with 2.x versions of Python.


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.



Arguably, Python 3 has been rejected by the market.


Almost everything is 'arguable'. Based on experience, Guido never 
expected major uptake until 3.2 (a year away).


> Instead, there's now Python 2.6,

Just who produced that? and why?


Python 2.7,


Does not exist yet, but again, coming from the same devs for the purpose 
of helping transition to 3.x.


> and Python 2.8.

Unlikely to ever exist.


Python 3 has turned into a debacle like Perl 6, now 10 years old.


You have to wait another 9 years to really say that. However, my 
impression is that Python 3 alreays surpasses Perl 6.



That's the reality, Python 3 fanboys.


Why are you such a Python 3 hateboy?

Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Library support for Python 3.x

[Terry Reedy]

On 1/27/2010 2:03 PM, Paul Rubin wrote:

a...@pythoncraft.com (Aahz) writes:

 From my POV, your question would be precisely identical if you had
started your project when Python 2.3 was just released and wanted to
know if the libraries you selected would be available for Python 2.6.


I didn't realize 2.6 broke libraries that had worked in 2.3, at least on
any scale.  Did I miss something?


For a windows user who depends on pre-built binaries, every new release 
breaks *every* library that is not pure Python and needs to be compiled.


--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[John Bokma]

Xah Lee  writes:

> Someone is badmouthing me, and it has been doing so over the years. I
> feel obliged to post a off topic relpy. See:
>
> • DreamHost.com and A Incidence of Harassment
>   http://xahlee.org/Periodic_dosage_dir/t2/harassment.html

Dreamhost is not the only ISP that has agreed with me in the past
regarding your spamming. And yes, it's spamming if you copy paste an
article from your web site with the link to that site and cross post it
to as many groups as your Usenet provider allows for. Thank goodness
that GG has a limit on how many groups you can spam at a time.

Post to on-topic groups only, really on-topic groups, not as many as you
can select. And participate like you know do, and nobody will complain
about /how/ you post. And if you cross-post /set a follow-up-to/.

That's netiquette.

-- 
John Bokma   j3b

Hacking & Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Ruby

[Jonathan Gardner]

On Jan 27, 5:47 am, Simon Brunning  wrote:
>
> I think Python is a little cleaner, but I'm sure you'd find Ruby fans
> who'd argue the complete opposite.
>

Are you sure about that?

There's a lot of line noise in Ruby. How are you supposed to pronounce
"@@"? What about "{|..| ... }"?

There's a lot of "magic" in Ruby as well. For instance, function calls
are made without parentheses. Blocks can only appear as the first
argument. There's a lot more, if you put your mind to it.

Indentation is also optional in Ruby. You can quickly fool a newbie by
not indenting your code properly, which is impossible in Python.

Python is much, much cleaner. I don't know how anyone can honestly say
Ruby is cleaner than Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Ruby

[Jonathan Gardner]

On Jan 27, 6:56 am, Roald de Vries  wrote:
> On Jan 27, 2010, at 2:01 PM, Jean Guillaume Pyraksos wrote:
>
> > What are the arguments for choosing Python against Ruby
> > for introductory programming?
>
> I think the main difference is in culture, especially for  
> *introductory* programming.

To add to that, Python is the type of language where experienced
programmers can pick it up by reading code, and newbies won't get
hopelessly lost. I've taught less-than-formal introductory programming
classes to people who are new to programming. Python gets out of the
way, and allows you to focus on the programming concepts, such as
variable, functions, parameters, classes, and algorithms.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Daniel Fetchinson]

>> 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:

I said myths, not facts! :)

s/Myths/Facts/

> 1.  Python 3 is supported by major Linux distributions.
>
>   FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

This latter statement is false, Fedora 11 and 12 come with python 2.6.

> 2.  Python 3 is supported by multiple Python implementations.
>
>   FALSE - Only CPython supports 3.x.  Iron Python, Unladen Swallow,
>   PyPy, and Jython have all stayed with 2.x versions of Python.

This latter statement is false, unladen swallow is currently targeting
3.x and may even be merged into cpython 3.x.

> 3.  Python 3 is supported by most 3rd party Python packages.
>
>   FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

s/most/my favorite/

Actually, tons of 3rd party packages are already ported, postgres and
django are just 2 examples, the next release of PIL will be another.

> Arguably, Python 3 has been rejected by the market.  Instead, there's
> now Python 2.6, Python 2.7, and Python 2.8.  Python 3 has turned into
> a debacle like Perl 6, now 10 years old.

These are the kinds of myths I had in mind when starting the thread.
All sorts of BS is kept circulating without any facts to back up the
claims. Actually, in this thread tons of rebuttals can be found to
your statements but I doubt you will change your mind :) Hopefully
others reading all of this will at least see what is BS and what is
the actual situation about python 3.

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[David Malcolm]

On Wed, 2010-01-27 at 16:25 -0500, Benjamin Kaplan wrote:
> On Wed, Jan 27, 2010 at 3:56 PM, 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.
> >
> >FALSE - most distros are shipping with Python 2.4, or 2.5 at best.
> >
> The latest versions of Ubuntu Jaunty and Karmic, Fedora 11 and 12, and
> OpenSUSE 11.2 all use Python 2.6. Ubuntu has been shipping python 3
> since Jaunty came out last April. According to Fedora's package index,
> Python 3 is in the devel version which probably means it will be in
> upcoming versions of Fedora as well.

FWIW, more information on Fedora python 3 status here:
https://fedoraproject.org/wiki/Features/Python3F13

[snip]

> Give the package maintainers time to update. There were some pretty
> big changes to the C API. Most of the major 3rd party packages like
> numpy and MySQLdb have already commited to having a Python 3 version.
> They just haven't gotten them out yet.

I'll take this opportunity to make a shameless plug for my 2to3c tool:
http://dmalcolm.livejournal.com/3935.html

which takes some of the grunt work out of taking C code and making it
compilable against both 2 and 3.  (it will still require a human to do
some of the work, alas).


Hope this is helpful
Dave

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: myths about python 3

[Edward A. Falk]

In article ,
Daniel Fetchinson   wrote:
>Hi folks,
>
>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:

Yes, but does print as a statement work?

Your argument is that python 2.x code can be ported to 3.x and still
run under 2.6 if you're careful about how you do the port.  That's
not the same as saying they're compatible.


>2. Integer division creates incompatibility between 2.x and 3.x!

Same as above.  Saying you can make it work by rewriting your code
is not the same as saying that it works.


If they'd wanted wide adoption of python 3, they should have made it
as compatible as possible with python 2 code.  If they dropped the
print statement, then they did not do so.
-- 
-Ed Falk, f...@despams.r.us.com
http://thespamdiaries.blogspot.com/
-- 
http://mail.python.org/mailman/listinfo/python-list