twitter: comp.lang.python - 25 new messages in 9 topics

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

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Simple Password Strength Checker Review Help needed
http://groups.google.com/group/comp.lang.python/t/c320de989d20c778?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 9:27 am
From: aahz@pythoncraft.com (Aahz)

In article <7xfx5sxbmw.fsf@ruckus.brouhaha.com>,
Paul Rubin <no.email@nospam.invalid> 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 (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/

import antigravity

== 2 of 2 ==
Date: Wed, Jan 27 2010 12:41 pm
From: 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

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

== 1 of 6 ==
Date: Wed, Jan 27 2010 9:29 am
From: "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

== 2 of 6 ==
Date: Wed, Jan 27 2010 9:38 am
From: Luis M. González

> Please don't post more noise and ad hominem attacks to the group, Steve.

"Ad hominem"?
Please, operor non utor lingua non notus per vulgaris populus.
Gratias ago vos...

== 3 of 6 ==
Date: Wed, Jan 27 2010 9:50 am
From: 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/

== 4 of 6 ==
Date: Wed, Jan 27 2010 9:52 am
From: "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

== 5 of 6 ==
Date: Wed, Jan 27 2010 12:05 pm
From: Grant Edwards

On 2010-01-27, Alf P. Steinbach <alfps@start.no> 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!!

== 6 of 6 ==
Date: Wed, Jan 27 2010 12:28 pm
From: 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.

==============================================================================
TOPIC: Ad hoc lists vs ad hoc tuples
http://groups.google.com/group/comp.lang.python/t/c8a013c1b308b797?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 27 2010 9:32 am
From: 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)

==============================================================================
TOPIC: starting a thread in a nother thread
http://groups.google.com/group/comp.lang.python/t/6b1e130987c24aa2?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 9:47 am
From: Dennis Lee Bieber

On Wed, 27 Jan 2010 15:23:35 +0100, Richard Lamboj
<richard.lamboj@bilcom.at> declaimed the following in
gmane.comp.python.general:

> I'am sharing one connection for all threads. When i'am starting the

I'm not familiar with the specifications of the PostgreSQL adapters,
but does the one being used state that connections may be shared by
threads? Some db-api adapters limit one to "no shared connections", some
to "no shared cursors"... I suppose some could be even be "no shared
database" or, at the extreme, "no shared adapter module".

If it does state shared connections it may be, as has been
mentioned, a bug in the adapter.
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/

== 2 of 2 ==
Date: Wed, Jan 27 2010 1:03 pm
From: 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

==============================================================================
TOPIC: site.py confusion
http://groups.google.com/group/comp.lang.python/t/03f435bfda8b5ac9?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 9:57 am
From: Arnaud Delobelle

George Trojan <george.trojan@noaa.gov> 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

== 2 of 2 ==
Date: Wed, Jan 27 2010 10:48 am
From: George Trojan

Arnaud Delobelle wrote:
> George Trojan <george.trojan@noaa.gov> 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
<module>
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

==============================================================================
TOPIC: I really need webbrowser.open('file://') to open a web browser
http://groups.google.com/group/comp.lang.python/t/c635429687f7f7c2?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 10:29 am
From: Mitchell L Model

On Jan 15, 2010, at 3:59 PM, Timur Tabi <timur@freescale.com>

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

== 2 of 2 ==
Date: Wed, Jan 27 2010 12:31 pm
From: Timur Tabi

On Wed, Jan 27, 2010 at 12:29 PM, Mitchell L Model <MLMDev@comcast.net> 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

==============================================================================
TOPIC: Library support for Python 3.x
http://groups.google.com/group/comp.lang.python/t/ae138cefffed0d6b?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Jan 27 2010 11:03 am
From: Paul Rubin

aahz@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?

== 2 of 5 ==
Date: Wed, Jan 27 2010 11:23 am
From: exarkun@twistedmatrix.com

On 07:03 pm, no.email@nospam.invalid wrote:
>aahz@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

== 3 of 5 ==
Date: Wed, Jan 27 2010 11:26 am
From: "sjdevnull@yahoo.com"

On Jan 27, 2:03 pm, Paul Rubin <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?

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.

== 4 of 5 ==
Date: Wed, Jan 27 2010 12:23 pm
From: "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

== 5 of 5 ==
Date: Wed, Jan 27 2010 1:04 pm
From: 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

==============================================================================
TOPIC: Pyowa Meeting Next Monday
http://groups.google.com/group/comp.lang.python/t/8d6c1b91fa795bf7?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 27 2010 11:29 am
From: 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

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

== 1 of 4 ==
Date: Wed, Jan 27 2010 12:56 pm
From: 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

== 2 of 4 ==
Date: Wed, Jan 27 2010 12:45 pm
From: Grant Edwards

On 2010-01-27, John Nagle <nagle@animats.com> 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

== 3 of 4 ==
Date: Wed, Jan 27 2010 1:06 pm
From: 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.

== 4 of 4 ==
Date: Wed, Jan 27 2010 1:14 pm
From: "sjdevnull@yahoo.com"

On Jan 27, 9:22 am, Daniel Fetchinson <fetchin...@googlemail.com>
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.

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

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

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

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

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

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

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

twitter

Wednesday, January 27, 2010

comp.lang.python - 25 new messages in 9 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts