subject:"The real problem with Python 3 \- no business case for conversion"

On Tue, Jul 6, 2010 at 1:37 AM, Terry Reedy tjre...@udel.edu wrote:
 On 7/5/2010 9:00 PM, Philip Semanchuk wrote:

 On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:

 On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchuk

 I ported two pure C extensions from 2 to 3 and was even able to keep a
 single C codebase. I'd be willing to contribute my experiences to a
 document
 somewhere. (Is there a Wiki?)

 Indeed there is: http://wiki.python.org/moin/

 Thanks. I don't want to appear ungrateful, but I was hoping for
 something specific to the 2-to-3 conversion. I guess someone has to
 start somewhere...

 There is an existing 2to3 and other pages for Python code conversion. I do
 not know of any for CAPI conversion. The need for such has been acknowledged
 among the devs but if there is nothing yet, we need someone with specialized
 experience and a bit of time to make a first draft. If you start one, give
 it an easy to remember name C2to3? 2to3Capi? You choose. And link to it from
 the 2to3 page

 In his post on this thread, Martin Loewis volunteered to list what he knows
 from psycopg2 if someone else will edit.

I'm not sure why I don't have this post, but I'm happy to help edit
etc if Martin
wants to put together a rough draft.

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Kevin Walzer


On 7/2/10 3:07 PM, John Nagle wrote:



That's the real issue, not parentheses on the print statement.
Where's the business case for moving to Python 3? It's not faster.
It doesn't do anything you can't do in Python 2.6. There's no
killer app for it. End of life for Python 2.x is many years away;
most server Linux distros aren't even shipping with 2.6 yet. How can a
business justify spending money on conversion to Python 3?


That's decision for each business to make. My guess is that many 
businesses won't upgrade for some time, until the major 
libraries/modules support Python 3. I don't plan to move to Python 3 for 
at least a couple of years.


Python 3 is a nice cleanup of some legacy syntax issues. But
that's just not enough. Perl 6 is a nice cleanup of Perl 5, and
look how that went. Ten years on, it's not even mainstream, let
alone dominant.


The Perl analogy isn't really useful here. Perl 6 is somewhere between 
the HURD and Duke Nukem Forever in terms of being viable. Even the Perl 
website says, If you are looking for production ready code please use 
Perl 5. That's one reason why Perl 5 development has recently undergone 
a resurgence.


Python 3, by contrast, is production-ready in itself; libraries are 
gradually moving to support it, and Python 2 has a definite end-of-life 
release in 2.7, with an extended maintenance period for 2.7. The Python 
developers are providing a much stronger and clearer path forward for 
Python 3. The transition period may last five years, but the path is clear.


As a Mac developer, I'm sympathetic to your frustration. A few years ago 
Apple deprecated one of its major API's (Carbon), on which my own 
development depended, and there was a lot of uncertainty about major 
libraries that use Carbon being updated. This is normal in any 
transition period. Eventually, the major libraries I depend on were 
updated by their developers (i.e. ported to the Cocoa API), I was able 
to migrate my own applications to the updated libraries, and life went on.


I think the same thing will happen with Python. It's useful to note the 
libraries that are not yet ported to support Python 3, and to share best 
practices for moving forward. Past a certain point, however, I don't see 
much point in attacking the existence of Python 3 or questioning the 
need to move toward Python 3. It's here, it's the way forward, and 
that's not going to change. Might as well accept it.


--Kevin


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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Roy Smith

In article 5325a$4c349b5b$4275d90a$27...@fuse.net,
 Kevin Walzer k...@codebykevin.com wrote:

 That's decision for each business to make. My guess is that many 
 businesses won't upgrade for some time, until the major 
 libraries/modules support Python 3. I don't plan to move to Python 3 for 
 at least a couple of years.

It takes a long time for big businesses to upgrade.  It's not like me or 
you.  I just download the latest and greatest, run the installer, and 
I'm good to go.

A big company has to install it in a test lab, certify it, get approval 
from IT, log a change request, etc.

You need to get approval from your manager, your director, your VP, and 
so on up the management chain until you finally reach somebody who has 
no clue what's going on and either sits on the request or denies it out 
of ignorance.  Or, more likely, you just hit some middle-management 
layer where the guy doesn't have the authority to approve it himself, 
and isn't willing to expend the political capital it would take to get 
approval from the next layer up.

Somebody might decide they don't want to disturb any existing production 
systems (not a bad idea, really), so you need to order new hardware for 
it.  Even if you can get capital approval for that, it mushrooms into 
finding rack space, and the UPS is already oversubscribed, and so is the 
cooling, and there's no available network ports, and so on.  Suddenly, 
downloading some free software has become a 5-figure project.

Big businesses have lots of ways to ensure that no progress is ever 
made.  If you think any of the above is made up, you've never worked for 
a big company.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Carl Banks

On Jul 7, 1:31 am, Paul McGuire pt...@austin.rr.com wrote:
 On Jul 6, 3:30 am, David Cournapeau courn...@gmail.com wrote: On Tue, Jul 
 6, 2010 at 4:30 AM, D'Arcy J.M. Cain da...@druid.net wrote:

  One thing that would be very useful is how to maintain something that
  works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
  versions below 2.6 is out of the question for most projects with a
  significant userbase IMHO. As such, the idea of running the python 3
  warnings is not so useful IMHO - unless it could be made to work
  better for python 2.x  2.6, but I am not sure the idea even makes
  sense.

 This is exactly how I felt about my support for pyparsing, that I was
 trying continue to provide support for 2.3 users, up through 3.x
 users, with a single code base.  (This would actually have been
 possible if I had been willing to introduce a performance penalty for
 Python 2 users, but performance is such a critical issue for parsing I
 couldn't justify it to myself.)  This meant that I had to constrain my
 implementation, while trying to incorporate forward-looking support
 features (such as __bool__ and __dir__), which have no effect on older
 Python versions, but support additions in newer Pythons.  I just
 couldn't get through on the python-dev list that I couldn't just
 upgrade my code to 2.6 and then use 2to3 to keep in step across the
 2-3 chasm, as this would leave behind my faithful pre-2.6 users.

 Here are some of the methods I used:

 - No use of sets.  Instead I defined a very simple set simulation
 using dict keys, which could be interchanged with set for later
 versions.

 - No generator expressions, only list comprehensions.

 - No use of decorators.  BUT, pyparsing includes a decorator method,
 traceParseAction, which can be used by users with later Pythons as
 @traceParseAction in their own code.

 - No print statements.  As pyparsing is intended to be an internal
 module, it does no I/O as part of its function - it only processes a
 given string, and returns a data structure.

 - Python 2-3 compatible exception syntax.  This may have been my
 trickiest step.  The change of syntax for except from

     except ExceptionType, ex:

 to:

     except ExceptionType as ex:

 is completely forward and backward incompatible.  The workaround is to
 rewrite as:

     except ExceptionType:
         ex = sys.exc_info()[0]

 which works just fine in 2.x and 3.x.  However, there is a slight
 performance penalty in doing this, and pyparsing uses exceptions as
 part of its grammar success/failure signalling and backtracking; I've
 used this technique everywhere I can get away with it, but there is
 one critical spot where I can't use it, so I have to keep 2 code bases
 with slight differences between them.

 - Implement __bool__, followed by __nonzero__ = __bool__.  This will
 give you boolean support for your classes in 2.3-3.1.

 - Implement __dir__, which is unused by old Pythons, but supports
 customization of dir() output for your own classes.

 - Implement __len__, __contains__, __iter__ and __reversed__ for
 container classes.

 - No ternary expressions.  Not too difficult really, there are several
 well-known workarounds for this, either by careful use of and's and
 or's, or using the bool-as-int to return the value from
 (falseValue,trueValue)[condition].

 - Define a version-sensitive portion of your module, to define
 synonyms for constants that changed name between versions.  Something
 like:

     _PY3K = sys.version_info[0]  2
     if _PY3K:
         _MAX_INT = sys.maxsize
         basestring = str
         _str2dict = set
         alphas = string.ascii_lowercase + string.ascii_uppercase
     else:
         _MAX_INT = sys.maxint
         range = xrange
         _str2dict = lambda strg : dict( [(c,0) for c in strg] )
         alphas = string.lowercase + string.uppercase

 The main body of my code uses range throughout (for example), and with
 this definition I get the iterator behavior of xrange regardless of
 Python version.

 In the end I still have 2 source files, one for Py2 and one for Py3,
 but there is only a small and manageable number of differences between
 them, and I expect at some point I will move forward to supporting Py3
 as my primary target version.  But personally I think this overall
 Python 2-3 migration process is moving along at a decent rate, and I
 should be able to make my switchover in another 12-18 months.  But in
 the meantime, I am still able to support all versions of Python NOW,
 and I plan to continue doing so (albeit support for 2.x versions
 will eventually mean continue to offer a frozen feature set, with
 minimal bug-fixing if any).

 I realize that pyparsing is a simple-minded module in comparison to
 others: it is pure Python, so it has no issues with C extensions; it
 does no I/O, so print-as-statement vs. print-as-function is not an
 issue; and it imports few other modules, so the ones it does have not
 been dropped in Py3; and

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Brendan Abel

   One thing that would be very useful is how to maintain something that
   works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
   versions below 2.6 is out of the question for most projects with a
   significant userbase IMHO. As such, the idea of running the python 3
   warnings is not so useful IMHO - unless it could be made to work
   better for python 2.x  2.6, but I am not sure the idea even makes
   sense.

The entire fact that 3.x was *designed* to be incompatible should tell
you that supporting 2.x and 3.x with a single code base is a bad idea,
except for the very smallest of projects.  This is the point where a
project should fork and provide two different versions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread MRAB


Brendan Abel wrote:

One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As such, the idea of running the python 3
warnings is not so useful IMHO - unless it could be made to work
better for python 2.x  2.6, but I am not sure the idea even makes
sense.


The entire fact that 3.x was *designed* to be incompatible should tell
you that supporting 2.x and 3.x with a single code base is a bad idea,
except for the very smallest of projects.  This is the point where a
project should fork and provide two different versions.


I wouldn't say that 3.x was designed to be incompatible. It was designed
to tidy the language, and the incompatibilities are an unfortunate
result.
--
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

2010-07-07 Thread John Bokma

John Nagle na...@animats.com writes:

Python 3 is a nice cleanup of some legacy syntax issues.  But
 that's just not enough.  Perl 6 is a nice cleanup of Perl 5,

Eh, I wouldn't call Perl 6 a nice cleanup. It's much better to
consider it a new language with roots in Perl 5 (amongst others). Or
to quote from http://dev.perl.org/perl6/:

  Perl 5 and Perl 6 are two languages in the Perl family, but of
   different lineages.

 and look how that went.  Ten years on, it's not even mainstream, let
 alone dominant.

I don't think that's the point of Perl 6 (if one can even say such a
thing, that is). Right now, (I) think of Perl 6 as a test bed for features
that couldn't be put in Perl 5 in an easy manner. Or (I) think of it as a
programming language lab.

My best guess is that with coming Christmas there will be a Perl 6
comparable to Python 3. But huge disclaimer: I hardly follow Perl 6
development.

-- 
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: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Brendan Abel

On Jul 7, 3:00 pm, MRAB pyt...@mrabarnett.plus.com wrote:
 Brendan Abel wrote:
  One thing that would be very useful is how to maintain something that
  works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
  versions below 2.6 is out of the question for most projects with a
  significant userbase IMHO. As such, the idea of running the python 3
  warnings is not so useful IMHO - unless it could be made to work
  better for python 2.x  2.6, but I am not sure the idea even makes
  sense.

  The entire fact that 3.x was *designed* to be incompatible should tell
  you that supporting 2.x and 3.x with a single code base is a bad idea,
  except for the very smallest of projects.  This is the point where a
  project should fork and provide two different versions.

 I wouldn't say that 3.x was designed to be incompatible. It was designed
 to tidy the language, and the incompatibilities are an unfortunate
 result.

You're missing the point, and arguing semantics.  It's a good thing I
didn't misspell anything.

Python 3.x will continue to change.  The incompatibilities between 3.x
and 2.x will only become more numerous.  If your goal is to support
2.x, and 3.x, you'd be best supporting them separately.


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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel 007bren...@gmail.com wrote:
 On Jul 7, 3:00 pm, MRAB pyt...@mrabarnett.plus.com wrote:
 Brendan Abel wrote:
  One thing that would be very useful is how to maintain something that
  works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
  versions below 2.6 is out of the question for most projects with a
  significant userbase IMHO. As such, the idea of running the python 3
  warnings is not so useful IMHO - unless it could be made to work
  better for python 2.x  2.6, but I am not sure the idea even makes
  sense.

  The entire fact that 3.x was *designed* to be incompatible should tell
  you that supporting 2.x and 3.x with a single code base is a bad idea,
  except for the very smallest of projects.  This is the point where a
  project should fork and provide two different versions.

 I wouldn't say that 3.x was designed to be incompatible. It was designed
 to tidy the language, and the incompatibilities are an unfortunate
 result.

 You're missing the point, and arguing semantics.  It's a good thing I
 didn't misspell anything.

 Python 3.x will continue to change.  The incompatibilities between 3.x
 and 2.x will only become more numerous.  If your goal is to support
 2.x, and 3.x, you'd be best supporting them separately.

I maintain two projects that have to work from 2.5 to 3.1. On one of
them (~5kloc) we took the separate support route, and on the other
(~30kloc) I decided to keep a single codebase. IME the maintenance
burden on the former is substantially higher than the latter. Is the
difference in difficulty perhaps domain-related, or a result of a
certain style of coding? Could you give us some more details about
what you were working on that caused you to conclude this?

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

Re: The real problem with Python 3 - no business case for conversion

2010-07-07 Thread Ben Finney

geremy condra debat...@gmail.com writes:

 On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel 007bren...@gmail.com wrote:
  Python 3.x will continue to change.  The incompatibilities between
  3.x and 2.x will only become more numerous.  If your goal is to
  support 2.x, and 3.x, you'd be best supporting them separately.

 I maintain two projects that have to work from 2.5 to 3.1. On one of
 them (~5kloc) we took the separate support route, and on the other
 (~30kloc) I decided to keep a single codebase. IME the maintenance
 burden on the former is substantially higher than the latter.

The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.

If you now have a code base that is relatively easy to maintain for both
Python 2.x and 3.x, that is a result of much back-porting efforts and of
a new-feature moratorium that is currently in effect. Enjoy that
situation as you may, because it is guaranteed not to last.

Indeed, the feature moratorium is designed in part to help slow-moving
codebases migrate to Python 3.x before Python resumes its normal pace of
change again. If you're choosing to use that time to further entrench
codebases for Python 2.x, I think that's a short-sighted choice.

Python 2.7 is the last 2.x, no further 3.x features will be back-ported.
New 3.x features will begin to appear after the moratorium ends. The
combination of those two means that *the single-codebase burden will
only increase over time* as Python 3.x diverges further from what Python
2.x can support.

-- 
 \  “Programs must be written for people to read, and only |
  `\incidentally for machines to execute.” —Abelson  Sussman, |
_o__)  _Structure and Interpretation of Computer Programs_ |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread MRAB


geremy condra wrote:

On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel 007bren...@gmail.com wrote:

On Jul 7, 3:00 pm, MRAB pyt...@mrabarnett.plus.com wrote:

Brendan Abel wrote:

One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As such, the idea of running the python 3
warnings is not so useful IMHO - unless it could be made to work
better for python 2.x  2.6, but I am not sure the idea even makes
sense.

The entire fact that 3.x was *designed* to be incompatible should tell
you that supporting 2.x and 3.x with a single code base is a bad idea,
except for the very smallest of projects.  This is the point where a
project should fork and provide two different versions.

I wouldn't say that 3.x was designed to be incompatible. It was designed
to tidy the language, and the incompatibilities are an unfortunate
result.

You're missing the point, and arguing semantics.  It's a good thing I
didn't misspell anything.

Python 3.x will continue to change.  The incompatibilities between 3.x
and 2.x will only become more numerous.  If your goal is to support
2.x, and 3.x, you'd be best supporting them separately.


I maintain two projects that have to work from 2.5 to 3.1. On one of
them (~5kloc) we took the separate support route, and on the other
(~30kloc) I decided to keep a single codebase. IME the maintenance
burden on the former is substantially higher than the latter. Is the
difference in difficulty perhaps domain-related, or a result of a
certain style of coding? Could you give us some more details about
what you were working on that caused you to conclude this?


In my work on the regex module I use a single codebase and generate the
sources for Python 2.5-2.7 and for Python 3.1 from it. It works easily
enough for me.
--
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Fuzzyman

On Jul 5, 1:34 am, sturlamolden sturlamol...@yahoo.no wrote:
 On 5 Jul, 01:58, John Nagle na...@animats.com wrote:

       Exactly.

       The incompatible with all extension modules I need part
  is the problem right now.  A good first step would be to
  identify the top 5 or 10 modules that are blocking a move to
  Python 3 by major projects with many users.

 The big danger is Python 2.x becoming abandonware (2.7 being the final
 release) before major projects are ported. Using Python 2.x for new
 projects is not advisable (at least many will think so), and using 3.x
 is not possible. What to do? It's not a helpful situation for Python.

But Python 2.3, 2.4  2.5 are *already* abandonware and see *major*
use in many systems and businesses. Python development has always gone
ahead of what *some* people use - and they don't seem to mind that
they're using essentially abandoned versions of Python.

Now that 2.7 is out I *might* be able to persuade my current company
to migrate to 2.6 on the servers, and they're far faster at adopting
tech than many companies I know.

All the best,

Michael Foord
--
http://www.voidspace.org.uk
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Carl Banks

On Jul 7, 2:10 pm, Brendan Abel 007bren...@gmail.com wrote:
One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As such, the idea of running the python 3
warnings is not so useful IMHO - unless it could be made to work
better for python 2.x  2.6, but I am not sure the idea even makes
sense.

 The entire fact that 3.x was *designed* to be incompatible should tell
 you that supporting 2.x and 3.x with a single code base is a bad idea,
 except for the very smallest of projects.  This is the point where a
 project should fork and provide two different versions.

Well, I think it could be a reasonable thing to maintain a single
codebase in 2.x and use 2to3 (and/or a custom translator) to translate
to 3.x version for quite a while.

For the humble library I maintain, I plan to release a Python 3
version as soon as a Python 3 version of numpy is released, maintain a
single codebase (translating from 2 version to 3) for awhile, then at
some point fork them and maintain them separately.

Given that I add features about once every 2 years I don't think it'll
be too much of a burden, though.


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

Re: The real problem with Python 3 - no business case for conversion

2010-07-07 Thread Paul Rubin

Ben Finney ben+pyt...@benfinney.id.au writes:
 The point, one more time with feeling, is that the incompatibilities
 between 2.x and 3.x will *increase* over time.

The issue is less the incompatibilities than the -backwards-
incompatibilities.  Yes, Python 3 may introduce forward
incompatibilities by adding features absent from Python 2.  But it will
be possible to maintain a common codebase simply by not using those
features.  On the other hand, the door appears closed for Python 3
adding more stuff that breaks Python 2 code.

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

Re: The real problem with Python 3 - no business case for conversion

On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 geremy condra debat...@gmail.com writes:

 On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel 007bren...@gmail.com wrote:
  Python 3.x will continue to change.  The incompatibilities between
  3.x and 2.x will only become more numerous.  If your goal is to
  support 2.x, and 3.x, you'd be best supporting them separately.

 I maintain two projects that have to work from 2.5 to 3.1. On one of
 them (~5kloc) we took the separate support route, and on the other
 (~30kloc) I decided to keep a single codebase. IME the maintenance
 burden on the former is substantially higher than the latter.

 The point, one more time with feeling, is that the incompatibilities
 between 2.x and 3.x will *increase* over time.

...and? I don't get to use features from 2.7, why would I expect to
use features from 3.3?

 If you now have a code base that is relatively easy to maintain for both
 Python 2.x and 3.x, that is a result of much back-porting efforts and of
 a new-feature moratorium that is currently in effect. Enjoy that
 situation as you may, because it is guaranteed not to last.

I have to target the oldest version of Python I want to support. New
features are irrelevant. I'm not sure why I should need to explain
that to you.

 Indeed, the feature moratorium is designed in part to help slow-moving
 codebases migrate to Python 3.x before Python resumes its normal pace of
 change again. If you're choosing to use that time to further entrench
 codebases for Python 2.x, I think that's a short-sighted choice.

I welcome the day that I can stop supporting 2.x. Until then, I have to
support both and your argument is irrelevant.

 Python 2.7 is the last 2.x, no further 3.x features will be back-ported.
 New 3.x features will begin to appear after the moratorium ends. The
 combination of those two means that *the single-codebase burden will
 only increase over time* as Python 3.x diverges further from what Python
 2.x can support.

See above.

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

Re: The real problem with Python 3 - no business case for conversion

2010-07-07 Thread Ben Finney

Paul Rubin no.em...@nospam.invalid writes:

 Ben Finney ben+pyt...@benfinney.id.au writes:
  The point, one more time with feeling, is that the incompatibilities
  between 2.x and 3.x will *increase* over time.

 The issue is less the incompatibilities than the -backwards-
 incompatibilities.

Yes, that's what I meant. Python 3 is deliberately under no obligation
to support code that works in Python 2. If something needs fixing, and
that fix would involve breaking Python 2 code, then that's not a
consideration any more.

The predictable result is that Python 3 will continue to gain
backward-incompatible changes in future.

 On the other hand, the door appears closed for Python 3 adding more
 stuff that breaks Python 2 code.

What gives you that idea? Can you reference a specific statement from
the PYthon developers that says that?

-- 
 \ “Not to be absolutely certain is, I think, one of the essential |
  `\ things in rationality.” —Bertrand Russell |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread David Cournapeau

On Wed, Jul 7, 2010 at 10:55 PM, Carl Banks pavlovevide...@gmail.com wrote:
 On Jul 7, 1:31 am, Paul McGuire pt...@austin.rr.com wrote:
 On Jul 6, 3:30 am, David Cournapeau courn...@gmail.com wrote: On Tue, Jul 
 6, 2010 at 4:30 AM, D'Arcy J.M. Cain da...@druid.net wrote:

  One thing that would be very useful is how to maintain something that
  works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
  versions below 2.6 is out of the question for most projects with a
  significant userbase IMHO. As such, the idea of running the python 3
  warnings is not so useful IMHO - unless it could be made to work
  better for python 2.x  2.6, but I am not sure the idea even makes
  sense.

 This is exactly how I felt about my support for pyparsing, that I was
 trying continue to provide support for 2.3 users, up through 3.x
 users, with a single code base.  (This would actually have been
 possible if I had been willing to introduce a performance penalty for
 Python 2 users, but performance is such a critical issue for parsing I
 couldn't justify it to myself.)  This meant that I had to constrain my
 implementation, while trying to incorporate forward-looking support
 features (such as __bool__ and __dir__), which have no effect on older
 Python versions, but support additions in newer Pythons.  I just
 couldn't get through on the python-dev list that I couldn't just
 upgrade my code to 2.6 and then use 2to3 to keep in step across the
 2-3 chasm, as this would leave behind my faithful pre-2.6 users.

 Here are some of the methods I used:

 - No use of sets.  Instead I defined a very simple set simulation
 using dict keys, which could be interchanged with set for later
 versions.

 - No generator expressions, only list comprehensions.

 - No use of decorators.  BUT, pyparsing includes a decorator method,
 traceParseAction, which can be used by users with later Pythons as
 @traceParseAction in their own code.

 - No print statements.  As pyparsing is intended to be an internal
 module, it does no I/O as part of its function - it only processes a
 given string, and returns a data structure.

 - Python 2-3 compatible exception syntax.  This may have been my
 trickiest step.  The change of syntax for except from

     except ExceptionType, ex:

 to:

     except ExceptionType as ex:

 is completely forward and backward incompatible.  The workaround is to
 rewrite as:

     except ExceptionType:
         ex = sys.exc_info()[0]

 which works just fine in 2.x and 3.x.  However, there is a slight
 performance penalty in doing this, and pyparsing uses exceptions as
 part of its grammar success/failure signalling and backtracking; I've
 used this technique everywhere I can get away with it, but there is
 one critical spot where I can't use it, so I have to keep 2 code bases
 with slight differences between them.

 - Implement __bool__, followed by __nonzero__ = __bool__.  This will
 give you boolean support for your classes in 2.3-3.1.

 - Implement __dir__, which is unused by old Pythons, but supports
 customization of dir() output for your own classes.

 - Implement __len__, __contains__, __iter__ and __reversed__ for
 container classes.

 - No ternary expressions.  Not too difficult really, there are several
 well-known workarounds for this, either by careful use of and's and
 or's, or using the bool-as-int to return the value from
 (falseValue,trueValue)[condition].

 - Define a version-sensitive portion of your module, to define
 synonyms for constants that changed name between versions.  Something
 like:

     _PY3K = sys.version_info[0]  2
     if _PY3K:
         _MAX_INT = sys.maxsize
         basestring = str
         _str2dict = set
         alphas = string.ascii_lowercase + string.ascii_uppercase
     else:
         _MAX_INT = sys.maxint
         range = xrange
         _str2dict = lambda strg : dict( [(c,0) for c in strg] )
         alphas = string.lowercase + string.uppercase

 The main body of my code uses range throughout (for example), and with
 this definition I get the iterator behavior of xrange regardless of
 Python version.

 In the end I still have 2 source files, one for Py2 and one for Py3,
 but there is only a small and manageable number of differences between
 them, and I expect at some point I will move forward to supporting Py3
 as my primary target version.  But personally I think this overall
 Python 2-3 migration process is moving along at a decent rate, and I
 should be able to make my switchover in another 12-18 months.  But in
 the meantime, I am still able to support all versions of Python NOW,
 and I plan to continue doing so (albeit support for 2.x versions
 will eventually mean continue to offer a frozen feature set, with
 minimal bug-fixing if any).

 I realize that pyparsing is a simple-minded module in comparison to
 others: it is pure Python, so it has no issues with C extensions; it
 does no I/O, so print-as-statement vs. print-as-function is not an
 issue; and it imports

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)


On 7/7/2010 5:29 AM, geremy condra wrote:

On Tue, Jul 6, 2010 at 1:37 AM, Terry Reedytjre...@udel.edu  wrote:

On 7/5/2010 9:00 PM, Philip Semanchuk wrote:

On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:

On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchu



I ported two pure C extensions from 2 to 3 and was even able to keep a
single C codebase. I'd be willing to contribute my experiences to a
document
somewhere. (Is there a Wiki?)



Indeed there is: http://wiki.python.org/moin/



Thanks. I don't want to appear ungrateful, but I was hoping for
something specific to the 2-to-3 conversion. I guess someone has to
start somewhere...



There is an existing 2to3 and other pages for Python code conversion. I do
not know of any for CAPI conversion. The need for such has been acknowledged
among the devs but if there is nothing yet, we need someone with specialized
experience and a bit of time to make a first draft. If you start one, give
it an easy to remember name C2to3? 2to3Capi? You choose. And link to it from
the 2to3 pag
In his post on this thread, Martin Loewis volunteered to list what he knows
from psycopg2 if someone else will edit.



I'm not sure why I don't have this post, but I'm happy to help edit
etc if Martin
wants to put together a rough draft.


Since I wrote that, someone pointed out the the Python How-to collection 
includes Porting Extension Modules to 3.0
by Benjamim Peterson. So all Pyilip or Martin need to do is read that 
and suggest additions.


Since it is part of the doc set, I presume an issue could be opened on 
the tracker.


--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion

2010-07-07 Thread Ben Finney

geremy condra debat...@gmail.com writes:

 On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
  [backward-]incompatibilities between 2.x and 3.x will *increase*
  over time.

 ...and? I don't get to use features from 2.7, why would I expect to
 use features from 3.3?

Conversely, why would you support Python 3.1?

  Indeed, the feature moratorium is designed in part to help
  slow-moving codebases migrate to Python 3.x before Python resumes
  its normal pace of change again. If you're choosing to use that time
  to further entrench codebases for Python 2.x, I think that's a
  short-sighted choice.

 I welcome the day that I can stop supporting 2.x. Until then, I have
 to support both and your argument is irrelevant.

Why do you have to support Python 3 at all? Will you expect to continue
maintaining a single code base that supports PYthon 2.x and Python 3.2,
then 3.3, and so on?

The only point being made here is to answer the question of why people
are saying that a single code base for both 2.x and 3.x is a maintenance
burden. If, in your case, at the present time, that's not the case, then
good for you! But it will get increasingly harder to do, and the reasons
why have now been explained. Apply them as you see fit.

-- 
 \ “I'm a born-again atheist.” —Gore Vidal |
  `\   |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)


On 7/7/2010 4:31 AM, Paul McGuire wrote:

[snip interesting report on how Paul suppost pyparsing for 2.3 to 3.1]

Thank you for this.

Do you think such cross-version support would have been easier or harder 
if the major changes and deletions in 3.0 has been spread over several 
versions, such as 2.5 - 2.7. In other words, suppose the Python 3 idea 
never occurred to anyone and


2.5 dropped the old int division and finished the unification of int and 
long.


2.6 dropped classic classes and switched range, filter, and map to their 
iterator versions.


2.7 made unicode the text type

This is not purely a hypothetical question since the issue of spreading 
or bunching changes may arise again in the future.


--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion

2010-07-07 Thread Paul Rubin

Ben Finney ben+pyt...@benfinney.id.au writes:
 On the other hand, the door appears closed for Python 3 adding more
 stuff that breaks Python 2 code.

 What gives you that idea? Can you reference a specific statement from
 the PYthon developers that says that?

It's just logic.  As I understand it, future versions of Python 3 are
supposed to not break programs that work under current versions of
Python 3.  So any Python 2 program that is a valid Python 3 program
today has to stay valid.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

On Wed, Jul 7, 2010 at 11:32 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 geremy condra debat...@gmail.com writes:

 On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney ben+pyt...@benfinney.id.au 
 wrote:
  [backward-]incompatibilities between 2.x and 3.x will *increase*
  over time.

 ...and? I don't get to use features from 2.7, why would I expect to
 use features from 3.3?

 Conversely, why would you support Python 3.1?

Because in 10 years the percentage of people who have Python 2.x
installed will be the same as the percentage that have Python 1.x
installed today.

  Indeed, the feature moratorium is designed in part to help
  slow-moving codebases migrate to Python 3.x before Python resumes
  its normal pace of change again. If you're choosing to use that time
  to further entrench codebases for Python 2.x, I think that's a
  short-sighted choice.

 I welcome the day that I can stop supporting 2.x. Until then, I have
 to support both and your argument is irrelevant.

 Why do you have to support Python 3 at all?

See above.

 Will you expect to continue
 maintaining a single code base that supports PYthon 2.x and Python 3.2,
 then 3.3, and so on?

Yes, with the occasional feature or bugfix. Is there an alternate
interpretation I'm missing?

 The only point being made here is to answer the question of why people
 are saying that a single code base for both 2.x and 3.x is a maintenance
 burden. If, in your case, at the present time, that's not the case, then
 good for you! But it will get increasingly harder to do, and the reasons
 why have now been explained. Apply them as you see fit.

I see you stating that it will become harder but I don't see why that
should be the case.

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

Re: The real problem with Python 3 - no business case for conversion


On 7/7/2010 9:14 PM, Ben Finney wrote:


The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.


For the purpose of maintaining least-common-denominator multi-version 
code, it is only deletions and semantic changes that matter. Feature 
additions will be more common, at least for awhile. The problem of 
backporting 3.x code that uses 3.x features definitely will increase.



--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Zooko O'Whielacronx

Dear Paul McGuire:

Thank you very much for these notes!

See also a few other notes:

Michael Foord: 
http://www.voidspace.org.uk/python/weblog/arch_d7_2010_03_20.shtml#e1167
Ned Batchelder:
http://nedbatchelder.com/blog/200910/running_the_same_code_on_python_2x_and_3x.html

I was wondering if it would be useful to have a library that
implements these hacks so that people like me who prefer to maintain a
single codebase instead of using a tool like 2to3 could easily adopt
them.

Oh look! Here is one:

http://pybites.blogspot.com/2010/06/six-python-23-compatibility-helpers.html

:-)

Regards,

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

Re: The real problem with Python 3 - no business case for conversion


On 7/7/2010 10:49 PM, Ben Finney wrote:


Yes, that's what I meant. Python 3 is deliberately under no obligation
to support code that works in Python 2. If something needs fixing, and
that fix would involve breaking Python 2 code, then that's not a
consideration any more.


Code that works in 3.1 *is* 3.1 code. Leaving aside bug fixes and 
additions that makes code that once raised an exception do something 
instead, I do not know that 3.1 broke and 3.0 code and I do not know of 
any deprecations in 3.1 that will become removals in 3.2.



The predictable result is that Python 3 will continue to gain
backward-incompatible changes in future.


For the core syntax, not too likely. In any case, the usually 3 version 
pending-deprecation, deprecation, removal process would apply. Some of 
the library modules that do not work well for 3.1 will see more changes.



On the other hand, the door appears closed for Python 3 adding more
stuff that breaks Python 2 code.


What gives you that idea? Can you reference a specific statement from
the PYthon developers that says that?


3.0 was stated to be a special case. I will let you look.

--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Martin v. Loewis

Am 07.07.2010 23:10, schrieb Brendan Abel:
 One thing that would be very useful is how to maintain something that
 works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
 versions below 2.6 is out of the question for most projects with a
 significant userbase IMHO. As such, the idea of running the python 3
 warnings is not so useful IMHO - unless it could be made to work
 better for python 2.x  2.6, but I am not sure the idea even makes
 sense.
 
 The entire fact that 3.x was *designed* to be incompatible should tell
 you that supporting 2.x and 3.x with a single code base is a bad idea,
 except for the very smallest of projects.  This is the point where a
 project should fork and provide two different versions.

I completely disagree. My personal experience is that this is well
possible even for large code bases, and I would recommend having a
single code base for 2.x and 3.x *in particular* for large projects,
which probably need to support 2.x users for quite some time, but
simultaneously need to support 3.x users.

Regards,
Martin

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Michele Simionato

On Jul 7, 10:55 pm, Carl Banks pavlovevide...@gmail.com wrote:
 On Jul 7, 1:31 am, Paul McGuire pt...@austin.rr.com wrote:
  I just
  couldn't get through on the python-dev list that I couldn't just
  upgrade my code to 2.6 and then use 2to3 to keep in step across the
  2-3 chasm, as this would leave behind my faithful pre-2.6 users.

This is a point I do not understand. My recent module plac is meant to
work from Python 2.3 to Python 3.1 and to this goal I make use of 2to3
at the *client* side.
Users of Python 2.X get the original code with no magic whatsoever;
users of Python 3.X
get the same code, but at installation time 2to3 is run by the
setup.py script. The mechanism requires distribute to be installed,
but I would say that having distribute is a must for Python 3.X users;
Python 2.X users do not need anything, so the approach is backward
compatible. I thought this was the recommended way of using 2to3 and
so far is working for me.

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-07 Thread Martin v. Loewis

 Python 3.x will continue to change.  The incompatibilities between 3.x
 and 2.x will only become more numerous.  If your goal is to support
 2.x, and 3.x, you'd be best supporting them separately.

I don't think that's a particularly good approach. Having a single code
base for both likely reduced the maintenance burden significantly
compared to a code fork.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

2010-07-07 Thread Martin v. Loewis

 The point, one more time with feeling, is that the incompatibilities
 between 2.x and 3.x will *increase* over time.

I think this is unfounded, and actually false.

Instead, the incompatibilities will *decrease* over the next few years.
Suppose you support 2.x and 3.x from a single code base. Today, you
might support 2.3 up to 3.1. In a year, you might drop 2.3, and start
support 3.2. That will lead to a reduction of incompatibilities: you
can start using 2.4 features, and drop work-arounds for 2.3 limitations.
Likewise when you then, later, drop 2.4.

As a specific example, since 2.5, the modules in the email package are
in lower case, in compliance with PEP 8. 2.x has backwards compatibility
so that you can continue to use the uppercase module names, which you
need for 2.3/2.4 compat. In 3.x, you can't use these spelling anymore,
so your code might use try/except as a work-around. When you drop 2.4,
you can drop the work-around.

 If you now have a code base that is relatively easy to maintain for both
 Python 2.x and 3.x, that is a result of much back-porting efforts and of
 a new-feature moratorium that is currently in effect. Enjoy that
 situation as you may, because it is guaranteed not to last.

On the contrary: it's getting better. The back-porting efforts only
become available in 2.6, and you would have to support at least 2.5
today (at least, that's how many maintainers feel). Only when you
can drop 2.5 support, you can actually start *using* these backport
features, allowing you to make the 2.x and 3.x code more similar.

Eventually, the difference will get larger again. Hopefully, by that
time, 2.7 got out of use.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread David Cournapeau

On Tue, Jul 6, 2010 at 4:30 AM, D'Arcy J.M. Cain da...@druid.net wrote:
 On Mon, 05 Jul 2010 14:42:13 -0400
 Terry Reedy tjre...@udel.edu wrote:
 Good start. Now what is blocking those four?
 Lack of developer interest/time/ability?
 or something else that they need?

 How about a basic how-to document?  I maintain PyGreSQL and would like
 to move it to 3.x right now but I don't even know what the issues are.

One thing that would be very useful is how to maintain something that
works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
versions below 2.6 is out of the question for most projects with a
significant userbase IMHO. As such, the idea of running the python 3
warnings is not so useful IMHO - unless it could be made to work
better for python 2.x  2.6, but I am not sure the idea even makes
sense.


 Or is there no change at the C level?  That would make things easy.

There are quite a few, but outside of the big pain point of
strings/byte/unicode which is present at python level as well, a lot
of the issues are not so big (and even simpler to deal with). For
example, although numpy took time to port (and is still experimental
in nature), it took me a couple of hours to get a basic scipy working
(numpy uses a lot of C api dark corners, whereas scipy is much more
straightforward in its usage of the C API).

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread Stefan Behnel


Steven D'Aprano, 05.07.2010 08:31:

On Sun, 04 Jul 2010 17:34:04 -0700, sturlamolden wrote:


Using Python 2.x for new
projects is not advisable (at least many will think so), and using 3.x
is not possible. What to do? It's not a helpful situation for Python.


That's pure FUD.

Python 2.7 will be supported longer than the normal support period for
versions 2.6, 2.5, 2.4, ... so if you have a new project that requires
libraries that aren't available for 3.1, then go right ahead and use 2.7.
By the time 2.7 is no longer supported (probably around the time 3.4
comes out?), the library situation will be fixed.

Those 3.1 features that can be backported to 2.x have been, specifically
to reduce the pain in porting 2.7-based applications to 3.x. Feature-
wise, 2.7 is designed to ease the transition from the 2.x series to the
3.x series. Claiming that it's not advisable to use 2.7 is simply
nonsense.


Not to forget about the 2to3 tool. If you write code for 2.6 or 2.7 now, 
you can actually port it automatically and continuously, and do the final 
switch when you think it's time. So both choices (2 or 3) are real and 
available.


Stefan

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread D'Arcy J.M. Cain

On Tue, 6 Jul 2010 16:30:34 +0800
David Cournapeau courn...@gmail.com wrote:
 One thing that would be very useful is how to maintain something that
 works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
 versions below 2.6 is out of the question for most projects with a

Yes, PyGreSQL officially supports 2.3 and up.  That means that we can't
use from __future__.  We might be able to bump that to 2.4 in the
next release but I wouldn't want to jump all the way to 2.6 in one
version release.

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread Steven

On Jul 5, 2:56 am, John Nagle na...@animats.com wrote:
The Twisted team has a list of what they need:

http://stackoverflow.com/questions/172306/how-are-you-planning-on-han...;

Here's what I got from a quick google review of the below four
projects and python 3.
* Zope Interface
Here's a blog from a core contributer to Zope, Lennart Regebro
claiming Zope Interface now works with Python 3:
http://regebro.wordpress.com/2010/04/29/zope-interface-3-6-0-released-with-python-3-support/
I have no idea if this is official Zope, but it does indicate strong
progress.

* PyCrypto
Couldn't find much. Found this from an email on Pycrypto mailing
list:
http://lists.dlitz.net/pipermail/pycrypto/2010q2/000244.html

Hi Tobias

Does Pycrypto work with Python 3.x now?

To my knowledge PyCrypto doesn't work yet with Python 3.x.
Around 30% of the test cases are still fail. If you want me
to check which of the components are pass, please let me know.

Cheers,
Christoph
So someone has been looking at Python 3, but doesn't look like much is
being done.

* PyOpenSSL
Couldn't find anything.

* PyGTK
This one shows real progress. There is a bug filed for Python 3
support:
https://bugzilla.gnome.org/show_bug.cgi?id=566641
Key comment on that bug:
John Ehresman [developer] 2010-04-17 16:02:43 UTC

I just pushed to the py3k branch a couple of fixes to bugs that are
independent
of the changes for python3 so all tests pass under both python 2.5 and
python3.1. It's probably time to think about landing this on the
master
branch; obviously we want to avoid regressions in python2 support.
What needs
to be done before this lands on master?
A couple of comments follow about when to merge Python 3 support. So
it looks like they are almost there.

Conclusion: 2 of 4 dependencies that Twisted needs to port to Python
3 show strong progress towards completing the port.

Steven Rumbalski

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread Giampaolo Rodolà

2010/7/6 David Cournapeau courn...@gmail.com:
 Or is there no change at the C level?  That would make things easy.

 There are quite a few, but outside of the big pain point of
 strings/byte/unicode which is present at python level as well, a lot
 of the issues are not so big (and even simpler to deal with). For
 example, although numpy took time to port (and is still experimental
 in nature), it took me a couple of hours to get a basic scipy working
 (numpy uses a lot of C api dark corners, whereas scipy is much more
 straightforward in its usage of the C API).

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


As for this aspect, I made a port as such (C extension) for psutil,
and it hasn't been too difficult, I must admit.

For those interested here is a detailed explanation of all the steps I
faced, along with revision changes:
http://code.google.com/p/psutil/issues/detail?id=75can=1q=python%203colspec=ID%20Summary%20Type%20Opsys%20Status%20Milestone%20Opened%20Owner%20Progress#c9


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread Terry Reedy


On 7/6/2010 11:19 AM, Giampaolo Rodolà wrote:

2010/7/6 David Cournapeaucourn...@gmail.com:

Or is there no change at the C level?  That would make things easy.


There are quite a few, but outside of the big pain point of
strings/byte/unicode which is present at python level as well, a lot
of the issues are not so big (and even simpler to deal with). For
example, although numpy took time to port (and is still experimental
in nature), it took me a couple of hours to get a basic scipy working
(numpy uses a lot of C api dark corners, whereas scipy is much more
straightforward in its usage of the C API).




As for this aspect, I made a port as such (C extension) for psutil,
and it hasn't been too difficult, I must admit.

For those interested here is a detailed explanation of all the steps I
faced, along with revision changes:
http://code.google.com/p/psutil/issues/detail?id=75can=1q=python%203colspec=ID%20Summary%20Type%20Opsys%20Status%20Milestone%20Opened%20Owner%20Progress#c9


That post refers to
docs.python.org / dev/3.0/howto/cporting.html
[without added space] but that is currently 404 missing.

--
Terry Jan Reedy


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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread Thomas Jollans

On 07/06/2010 07:17 PM, Terry Reedy wrote:
 docs.python.org / dev/3.0/howto/cporting.html

http://docs.python.org/py3k/howto/cporting.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread rantingrick

On Jul 6, 12:37 am, Terry Reedy tjre...@udel.edu wrote:

 In his post on this thread, Martin Loewis volunteered to list what he
 knows from psycopg2 if someone else will edit.

Now we are getting somewhere! This is the community spirit i want to
see. You don't have to give much people, every little bit counts. But
for Google's sake we need to work together to get this thing done.
Let's get a list together of 3rd party modules that are must haves
and start knocking on doors, evangelizing, air dropping leaflets,
spreading the word, whatever it takes! The revolution is not going to
happen whilst we sleep -- not the Python revolution that is!

Get the lead out c.l.p!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-06 Thread Luis M . González

On Jul 2, 4:07 pm, John Nagle na...@animats.com wrote:
 David Cournapeau courn...@gmail.com wrote:
  I think one point which needs to be emphasized more is what does
  python 3 bring to people. The what's new in python 3 page gives
  the impression that python 3 is about removing cruft. That's a very
  poor argument to push people to switch.

     That's the real issue, not parentheses on the print statement.
 Where's the business case for moving to Python 3?   It's not faster.
 It doesn't do anything you can't do in Python 2.6.  There's no
 killer app for it. End of life for Python 2.x is many years away;
 most server Linux distros aren't even shipping with 2.6 yet. How can a
 business justify spending money on conversion to Python 3?

     If Python 3 came with Unladen Swallow, and ran several times
 faster than Python 2.x, there'd be a strong business case for
 conversion.  Especially for large sites with racks of servers
 grinding through slow CPython code.  But it looks like Unladen
 Swallow will be available for 2.6 before it's available for 3.x.
 So that's not a selling point for 3.x.

     Python 3 is a nice cleanup of some legacy syntax issues.  But
 that's just not enough.  Perl 6 is a nice cleanup of Perl 5, and
 look how that went.  Ten years on, it's not even mainstream, let
 alone dominant.

     This has all been said before. See Python 3.0: What s The Point?
 from December 2008:

 http://jens.mooseyard.com/2008/12/python-30-whats-the-point/

     Not much has changed since then.

     What I'm not seeing is a deployment plan along these lines:

     1.  Identify key modules which must be converted before Python 3
         can be used in production environments.

     2.  Get those modules converted to Python 3.

     3.  Put together a distribution for the major platforms (at least
         Linux and Windows) with builds of those modules.  This
         could be done on PyPi, which is at present is mostly a link
         farm, not a repository.

     4.  Get some major distros, like Debian and ActiveState, to
         include Python 3, as python3, not as the primary Python,
         so there are no conflicts.  (Debian already has a formal
         policy to keep Python versions separate.)

     5.  Get at least two major hosting services to put up Python 3.

     6.  Get at least two popular end-user programs (not modules) to
         support Python 3.

     7.  Publicize some success stories.

 Unless the Python 3 enthusiasts get their act together and work much
 harder on providing an easy transition experience, it's not going to
 happen.

                                 John Nagle

What's the problem?
Python 2.xx will he around for a long time. It will be supported and
you can use it for your existing projects for as long a you want.
On the other hand, if you have a new project and you plan to make it
successful and usable for many years to come, you should seriously
consider using Python 3.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Steven D'Aprano

On Sun, 04 Jul 2010 17:34:04 -0700, sturlamolden wrote:

 Using Python 2.x for new
 projects is not advisable (at least many will think so), and using 3.x
 is not possible. What to do? It's not a helpful situation for Python.

That's pure FUD.

Python 2.7 will be supported longer than the normal support period for 
versions 2.6, 2.5, 2.4, ... so if you have a new project that requires 
libraries that aren't available for 3.1, then go right ahead and use 2.7. 
By the time 2.7 is no longer supported (probably around the time 3.4 
comes out?), the library situation will be fixed.

Those 3.1 features that can be backported to 2.x have been, specifically 
to reduce the pain in porting 2.7-based applications to 3.x. Feature-
wise, 2.7 is designed to ease the transition from the 2.x series to the 
3.x series. Claiming that it's not advisable to use 2.7 is simply 
nonsense.



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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread John Nagle


On 7/4/2010 10:44 PM, Terry Reedy wrote:

On 7/4/2010 7:58 PM, John Nagle wrote:


The incompatible with all extension modules I need part
is the problem right now. A good first step would be to
identify the top 5 or 10 modules that are blocking a move to
Python 3 by major projects with many users.


Let me repeat. Last September, if not before, Guido identified numpy as
a top package blocking moves by other packages and projects. I am not
sure what he thought, but I consider it number 1. He encouraged the
numpy people to produce a 3.x version even though some did not see any
personal benefit. We supposedly will see numpy for 3.2. If we actually
do, other dominoes will fall into place.

I you have any other ideas about other top blockers, please share them.


   The Twisted team has a list of what they need:

http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-the-migration-to-python-3;

* Zope Interface
* PyCrypto
* PyOpenSSL
* PyGTK


John Nagle

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Steven D'Aprano

On Sun, 04 Jul 2010 18:59:03 -0700, John Nagle wrote:

 Denying that there's a problem does not help.

Nobody is denying that there is a problem, but there are plenty of people 
denying that there are any solutions.

The folks doing development of CPython are genuinely interested in 
constructive criticism. Go spend some time on the python-dev mailing list 
to see that they're serious about resolving problems. But harping on and 
on with the same old negatives and same old FUD (Python is too slow, 
nothing works with Python 3, people will abandon Python, the transition 
is being mismanaged, blah blah blah blah) conspicuously lacking in 
*actual* details is not helping anyone.

Let's hear specifics. What is your project, what is the project timeline, 
why did you want to use 3.1 (instead of, say, waiting for 3.2) and what 
*specific* problem stopped you? I'm not interested in hand-waving and 
vague generalities. I want to hear names and versions, not bitching.

We are planning on building an app to do Foo, and choose to target 2.6 
instead of 3.1 because the 3rd party FooLib only supports 2.5 and 2.6...

I wrote an app using 3.1, and ran into these really painful problems 
with this library...

That's the sort of thing that is helpful.

By the same token, if you've successfully targeted 3.1, we'd love to hear 
your success stories too. 



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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread David Cournapeau

On Mon, Jul 5, 2010 at 12:44 PM, Terry Reedy tjre...@udel.edu wrote:
 On 7/4/2010 7:58 PM, John Nagle wrote:

 The incompatible with all extension modules I need part
 is the problem right now. A good first step would be to
 identify the top 5 or 10 modules that are blocking a move to
 Python 3 by major projects with many users.

 Let me repeat. Last September, if not before, Guido identified numpy as a
 top package blocking moves by other packages and projects. I am not sure
 what he thought, but I consider it number 1. He encouraged the numpy people
 to produce a 3.x version even though some did not see any personal benefit.
 We supposedly will see numpy for 3.2.

I think numpy will work for 3.1 as well (I don't know about 3.0, but
my understanding is that there is no point into even looking at that
release).

With the scipy conferences going on, it will certainly be a good
occasion to synchronize a bit faster - nothing beats face to face as a
communication medium after all :)

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Terry Reedy


On 7/5/2010 2:56 AM, John Nagle wrote:

On 7/4/2010 10:44 PM, Terry Reedy wrote:



I you have any other ideas about other top blockers, please share them.


The Twisted team has a list of what they need:

http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-the-migration-to-python-3;


* Zope Interface
* PyCrypto
* PyOpenSSL
* PyGTK


Good start. Now what is blocking those four?
Lack of developer interest/time/ability?
or something else that they need?

--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Terry Reedy


On 7/5/2010 6:04 AM, David Cournapeau wrote:

On Mon, Jul 5, 2010 at 12:44 PM, Terry Reedytjre...@udel.edu  wrote:

[snip]


I think numpy will work for 3.1 as well


If numpy were released today for 3.1 (or even anytime before 3.2), that 
would be great. It would let those waiting for it that it is real and 
that they can go ahead on their ports.


Part of the reason for the 3.2 core-change moratorium was to let 
3rd-party packages target 3.2 by working with 3.1. If they finish and 
release sooner (as some have), even better. Unless they depend on 
something that changes in the stdlib, porting for one should pretty much 
be porting for both.



(I don't know about 3.0, but
my understanding is that there is no point into even looking at that
release).


Agreed.


--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Kevin Walzer


On 7/5/10 2:56 AM, John Nagle wrote:


* PyCrypto
* PyOpenSSL


These, and Mark Pilgrim's feedparser, need to be 3.x compatible before I 
can think about Python 3.x.


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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread D'Arcy J.M. Cain

On Mon, 05 Jul 2010 14:42:13 -0400
Terry Reedy tjre...@udel.edu wrote:
 Good start. Now what is blocking those four?
 Lack of developer interest/time/ability?
 or something else that they need?

How about a basic how-to document?  I maintain PyGreSQL and would like
to move it to 3.x right now but I don't even know what the issues are.
I can see on the site the 2.x documents and the 3.x documents for
extending with C modules and I can read both from end to end but that
hits the time issue above.  If there was a relatively simple document
that showed what needed to be changed in the C code we could get
started on the transition sooner.

Or is there no change at the C level?  That would make things easy.

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Martin v. Loewis

Am 05.07.2010 22:30, schrieb D'Arcy J.M. Cain:
 On Mon, 05 Jul 2010 14:42:13 -0400
 Terry Reedy tjre...@udel.edu wrote:
 Good start. Now what is blocking those four?
 Lack of developer interest/time/ability?
 or something else that they need?
 
 How about a basic how-to document?  I maintain PyGreSQL and would like
 to move it to 3.x right now but I don't even know what the issues are.
 I can see on the site the 2.x documents and the 3.x documents for
 extending with C modules and I can read both from end to end but that
 hits the time issue above.  If there was a relatively simple document
 that showed what needed to be changed in the C code we could get
 started on the transition sooner.
 
 Or is there no change at the C level?  That would make things easy.

If somebody would move that into a narrative form, I'd be happy to
list the changes I know of, and the approaches I took to make C modules
work on both 2.x and 3.x (actually, I did the port of psycopg2, so I
expect PyGreSQL might be similar).

However, I'm not willing to maintain such a document - I have too many
projects already, and English is not my native language.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread John Nagle


On 7/5/2010 12:35 PM, Kevin Walzer wrote:

On 7/5/10 2:56 AM, John Nagle wrote:


* PyCrypto
* PyOpenSSL


These, and Mark Pilgrim's feedparser, need to be 3.x compatible before I
can think about Python 3.x.


There's been an attempt to port feedparser to 3.0, but
that needed a port of BeautifulSoup:

http://code.google.com/p/feedparser/issues/detail?id=215

They also had some problems with chardet.

John Nagle

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Philip Semanchuk



On Jul 5, 2010, at 4:30 PM, D'Arcy J.M. Cain wrote:


On Mon, 05 Jul 2010 14:42:13 -0400
Terry Reedy tjre...@udel.edu wrote:

Good start. Now what is blocking those four?
Lack of developer interest/time/ability?
or something else that they need?


How about a basic how-to document?  I maintain PyGreSQL and would like
to move it to 3.x right now but I don't even know what the issues are.
I can see on the site the 2.x documents and the 3.x documents for
extending with C modules and I can read both from end to end but that
hits the time issue above.  If there was a relatively simple document
that showed what needed to be changed in the C code we could get
started on the transition sooner.

Or is there no change at the C level?  That would make things easy.


There are definitely changes at the C level.

I ported two pure C extensions from 2 to 3 and was even able to keep a  
single C codebase. I'd be willing to contribute my experiences to a  
document somewhere. (Is there a Wiki?) I would have found such a  
document very helpful before I started porting.


Cheers
Philip

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Chris Rebert

On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchuk phi...@semanchuk.com wrote:
 On Jul 5, 2010, at 4:30 PM, D'Arcy J.M. Cain wrote:
 On Mon, 05 Jul 2010 14:42:13 -0400
 Terry Reedy tjre...@udel.edu wrote:
 Good start. Now what is blocking those four?
 Lack of developer interest/time/ability?
 or something else that they need?

 How about a basic how-to document?  I maintain PyGreSQL and would like
 to move it to 3.x right now but I don't even know what the issues are.
 I can see on the site the 2.x documents and the 3.x documents for
 extending with C modules and I can read both from end to end but that
 hits the time issue above.  If there was a relatively simple document
 that showed what needed to be changed in the C code we could get
 started on the transition sooner.

 Or is there no change at the C level?  That would make things easy.

 There are definitely changes at the C level.

 I ported two pure C extensions from 2 to 3 and was even able to keep a
 single C codebase. I'd be willing to contribute my experiences to a document
 somewhere. (Is there a Wiki?)

Indeed there is: http://wiki.python.org/moin/

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Philip Semanchuk



On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:

On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchuk  
phi...@semanchuk.com wrote:

On Jul 5, 2010, at 4:30 PM, D'Arcy J.M. Cain wrote:

On Mon, 05 Jul 2010 14:42:13 -0400
Terry Reedy tjre...@udel.edu wrote:

Good start. Now what is blocking those four?
Lack of developer interest/time/ability?
or something else that they need?


How about a basic how-to document?  I maintain PyGreSQL and would  
like
to move it to 3.x right now but I don't even know what the issues  
are.

I can see on the site the 2.x documents and the 3.x documents for
extending with C modules and I can read both from end to end but  
that
hits the time issue above.  If there was a relatively simple  
document

that showed what needed to be changed in the C code we could get
started on the transition sooner.

Or is there no change at the C level?  That would make things easy.


There are definitely changes at the C level.

I ported two pure C extensions from 2 to 3 and was even able to  
keep a
single C codebase. I'd be willing to contribute my experiences to a  
document

somewhere. (Is there a Wiki?)


Indeed there is: http://wiki.python.org/moin/


Thanks. I don't want to appear ungrateful, but I was hoping for  
something specific to the 2-to-3 conversion. I guess someone has to  
start somewhere...







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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-05 Thread Terry Reedy


On 7/5/2010 9:00 PM, Philip Semanchuk wrote:


On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:


On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchuk



I ported two pure C extensions from 2 to 3 and was even able to keep a
single C codebase. I'd be willing to contribute my experiences to a
document
somewhere. (Is there a Wiki?)


Indeed there is: http://wiki.python.org/moin/


Thanks. I don't want to appear ungrateful, but I was hoping for
something specific to the 2-to-3 conversion. I guess someone has to
start somewhere...


There is an existing 2to3 and other pages for Python code conversion. I 
do not know of any for CAPI conversion. The need for such has been 
acknowledged among the devs but if there is nothing yet, we need someone 
with specialized experience and a bit of time to make a first draft. If 
you start one, give it an easy to remember name C2to3? 2to3Capi? You 
choose. And link to it from the 2to3 page


In his post on this thread, Martin Loewis volunteered to list what he 
knows from psycopg2 if someone else will edit.


--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-04 Thread sturlamolden

On 2 Jul, 21:07, John Nagle na...@animats.com wrote:

 http://jens.mooseyard.com/2008/12/python-30-whats-the-point/

He is right on. The only thing Python 3k will do for me, is break all
my code and be incompatible with all extension modules I need. What's
the point? indeed.


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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-04 Thread John Nagle


On 7/4/2010 1:20 PM, sturlamolden wrote:

On 2 Jul, 21:07, John Naglena...@animats.com  wrote:


http://jens.mooseyard.com/2008/12/python-30-whats-the-point/


He is right on. The only thing Python 3k will do for me, is break all
my code and be incompatible with all extension modules I need. What's
the point? indeed.


Exactly.

The incompatible with all extension modules I need part
is the problem right now.  A good first step would be to
identify the top 5 or 10 modules that are blocking a move to
Python 3 by major projects with many users.

John Nagle

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-04 Thread Steven D'Aprano

On Sun, 04 Jul 2010 16:58:04 -0700, John Nagle wrote:

  The incompatible with all extension modules I need part
 is the problem right now.  A good first step would be to identify the
 top 5 or 10 modules that are blocking a move to Python 3 by major
 projects with many users.

Are you volunteering to assist, or just belly-aching?

Migration to Python 3 is occurring at about the speed that should be 
expected, modulo the setback that was the seriously flawed 3.0 release. 
3.1 should be treated as the early adopter version. I would expect 3.3 
will probably be the first mainstream version, where v3 users start to 
outnumber v2 users.

If people have concrete, *specific* issues that are holding them back 
from serious plans to migrate to Python 3 then reporting them is a good 
first step: e.g. telling the author of extension module Foo that you need 
Python 3 compatibility.

Complaining that extension modules aren't compatible is just bitching 
for the sake of bitching and isn't helpful. Please take it elsewhere. 
Start a blog why I hate Python 3 or something. Or just stick with 
Python 2.x forever, without the negativity. There's no law that says you 
have to upgrade. There are people still using 1.5, and more power to them.



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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-04 Thread sturlamolden

On 5 Jul, 01:58, John Nagle na...@animats.com wrote:

      Exactly.

      The incompatible with all extension modules I need part
 is the problem right now.  A good first step would be to
 identify the top 5 or 10 modules that are blocking a move to
 Python 3 by major projects with many users.

The big danger is Python 2.x becoming abandonware (2.7 being the final
release) before major projects are ported. Using Python 2.x for new
projects is not advisable (at least many will think so), and using 3.x
is not possible. What to do? It's not a helpful situation for Python.





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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-04 Thread John Nagle


On 7/4/2010 5:34 PM, sturlamolden wrote:

On 5 Jul, 01:58, John Naglena...@animats.com  wrote:


Exactly.

The incompatible with all extension modules I need part is the
problem right now.  A good first step would be to identify the top
5 or 10 modules that are blocking a move to Python 3 by major
projects with many users.


The big danger is Python 2.x becoming abandonware (2.7 being the
final release) before major projects are ported. Using Python 2.x
for new projects is not advisable (at least many will think so), and
using 3.x is not possible. What to do? It's not a helpful situation
for Python.


Projects have been known to get into a state where version N-1
is abandonware, and version N isn't usable yet.  Then they die off.
The VRML-Web3D transition is an example.  VRML 97 was ahead of its
time because few people had enough graphics power in 1997 to run it.
During the dot-com boom, the Web 3D Consortium (http://www.web3d.org)
was formed to put 3D on the web.  The approach chosen was to recast
VRML in XML notation.  Users were starting to get 3D boards in quantity,
and VRML was starting to really work.  But the forced transition killed
work on VRML, while there wasn't enough momentum to get people to use
the XML version.

   The Web3D consortium is still around.  They have conferences.
They have something of a niche market in DoD training sims.
But they're running on empty. Nobody is paying attention.  There's
no mainstream interest in either VRML or Web3D.  It works fine;
there are X3D players, and they work great on modern graphics
processors.  But nobody cares.  That's what happens when you
mismanage an incompatible transition.

   That could happen to Python.

   Python has strong competition.  In the last two years,
Javascript has become much faster, PHP is getting a JIT compiler,
Lua, as recently mentioned, is getting up there with C in speed, and
Google is promoting Go.  The other scripting languages are becoming
rocket-powered.   Meanwhile, Python is in year 2 of a 5-year plan to
transition to something that goes no faster (and maybe slower) than
the previous version.  (Yes, there's Unladen Swallow and PyPy, but
neither of those projects seems to be anywhere near deployment,
and even if they succeed, their claimed speed goals are well below where
the competition is now.)  That's just not good enough any more.

   Denying that there's a problem does not help.

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-04 Thread rantingrick

On Jul 4, 8:59 pm, John Nagle na...@animats.com wrote:

 That's what happens when you
 mismanage an incompatible transition.

+1

     Python has strong competition.  In the last two years,
 Javascript has become much faster, PHP is getting a JIT compiler,
 Lua, as recently mentioned, is getting up there with C in speed, and
 Google is promoting Go.  The other scripting languages are becoming
 rocket-powered.   Meanwhile, Python is in year 2 of a 5-year plan to
 transition to something that goes no faster (and maybe slower) than
 the previous version.  (Yes, there's Unladen Swallow and PyPy, but
 neither of those projects seems to be anywhere near deployment,
 and even if they succeed, their claimed speed goals are well below where
 the competition is now.)  That's just not good enough any more.

     Denying that there's a problem does not help.

+1

Hmm, i myself railed against the changes in Python3.x about 1 year
ago. Then, as i pondered the reasons behind such changes i began to
believe that the BDFL is wiser than us all! However, i must agree that
many of the points you bring up here are real. People ARE stuck in
limbo right now and there is no good direction to go... Stick with 2.x
and have all the 3rd party support but soon enough you will need to do
a major bug fixing, or move to 3.x -- oh wait i can't move to 3.x
because module xxyy is not 3.x compatible! What we have here gentlemen
is a situation, a terrible situation made worse by our lack to
understand it.

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-04 Thread Terry Reedy


On 7/4/2010 7:58 PM, John Nagle wrote:


The incompatible with all extension modules I need part
is the problem right now. A good first step would be to
identify the top 5 or 10 modules that are blocking a move to
Python 3 by major projects with many users.


Let me repeat. Last September, if not before, Guido identified numpy as 
a top package blocking moves by other packages and projects. I am not 
sure what he thought, but I consider it number 1. He encouraged the 
numpy people to produce a 3.x version even though some did not see any 
personal benefit. We supposedly will see numpy for 3.2. If we actually 
do, other dominoes will fall into place.


I you have any other ideas about other top blockers, please share them.

--
Terry Jan Reedy

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

Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)

2010-07-03 Thread Nobody

On Fri, 02 Jul 2010 12:07:33 -0700, John Nagle wrote:

 I think one point which needs to be emphasized more is what does
 python 3 bring to people. The what's new in python 3 page gives
 the impression that python 3 is about removing cruft. That's a very
 poor argument to push people to switch.
 
 That's the real issue, not parentheses on the print statement.
 Where's the business case for moving to Python 3?

If you're going to be doing a lot of Unicode text processing, I would
expect that using Python 3 would make the task somewhat simpler.

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

Re: The real problem with Python 3 - no business case for conversion

On Fri, 02 Jul 2010 22:40:34 -0700
John Nagle na...@animats.com wrote:
  Not according to Vex's published package list:
 
   http://www.vex.net/info/tech/pkglist/

As it says on that page it may not be up to date.  Look at the
generated list link.  I guess I should update the static page as well.

 vex.net isn't exactly a major hosting service.

OK, I'll give you that.  It is on the backbone of the net at 151 Front
Street in Toronto, has almost 100% uptime and uses high speed servers
but we don't have 15 layers of bureaucracy between the owner and the
user and I certainly know of no real hosting provider that invites
all their clients out for dinner once a year.  And how can we be a real
ISP when the president knows most of his clients on a first name basis?

I know what being major means to the owners and stockholders but what
features of being major matter to the client?

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

On Fri, 02 Jul 2010 22:40:34 -0700
John Nagle na...@animats.com wrote:
  Not according to Vex's published package list:
 
   http://www.vex.net/info/tech/pkglist/

Hold on.  That *is* the generated list and Python 3.1 is on it.  We
have both 2.6 and 3.1.  The 3.1 version is listed right below the 2.6
one.  The page is generated from pkg_info(1) and includes everything we
have installed from FreeBSD ports.

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

2010-07-03 Thread Steven D'Aprano

On Sat, 03 Jul 2010 08:46:57 -0400, D'Arcy J.M. Cain wrote:

 On Fri, 02 Jul 2010 22:40:34 -0700
 John Nagle na...@animats.com wrote:
  Not according to Vex's published package list:
 
  http://www.vex.net/info/tech/pkglist/
 
 Hold on.  That *is* the generated list and Python 3.1 is on it.  We have
 both 2.6 and 3.1.  The 3.1 version is listed right below the 2.6 one. 
 The page is generated from pkg_info(1) and includes everything we have
 installed from FreeBSD ports.

Pfft! Facts! You can prove anything you like with facts!


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

Re: The real problem with Python 3 - no business case for conversion

2010-07-03 Thread Alf P. Steinbach /Usenet


* Steven D'Aprano, on 03.07.2010 16:24:

On Sat, 03 Jul 2010 08:46:57 -0400, D'Arcy J.M. Cain wrote:


On Fri, 02 Jul 2010 22:40:34 -0700
John Naglena...@animats.com  wrote:

  Not according to Vex's published package list:

http://www.vex.net/info/tech/pkglist/


Hold on.  That *is* the generated list and Python 3.1 is on it.  We have
both 2.6 and 3.1.  The 3.1 version is listed right below the 2.6 one.
The page is generated from pkg_info(1) and includes everything we have
installed from FreeBSD ports.


Pfft! Facts! You can prove anything you like with facts!


:-)

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

2010-07-03 Thread Aahz

In article mailman.192.1278160797.1673.python-l...@python.org,
D'Arcy J.M. Cain da...@druid.net wrote:
On Fri, 02 Jul 2010 22:40:34 -0700
John Nagle na...@animats.com wrote:

 vex.net isn't exactly a major hosting service.

OK, I'll give you that.  It is on the backbone of the net at 151 Front
Street in Toronto, has almost 100% uptime and uses high speed servers
but we don't have 15 layers of bureaucracy between the owner and the
user and I certainly know of no real hosting provider that invites
all their clients out for dinner once a year.  And how can we be a real
ISP when the president knows most of his clients on a first name basis?

vex.net is Canada's Panix.  ;-)
-- 
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

If you don't know what your program is supposed to do, you'd better not
start writing it.  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

On 03 Jul 2010 14:24:49 GMT
Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
 Pfft! Facts! You can prove anything you like with facts!

Argumentum ad Dragnet?

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The real problem with Python 3 - no business case for conversion

2010-07-03 Thread John Nagle


On 7/3/2010 5:46 AM, D'Arcy J.M. Cain wrote:

On Fri, 02 Jul 2010 22:40:34 -0700
John Naglena...@animats.com  wrote:

  Not according to Vex's published package list:

http://www.vex.net/info/tech/pkglist/


Hold on.  That *is* the generated list and Python 3.1 is on it.  We
have both 2.6 and 3.1.  The 3.1 version is listed right below the 2.6
one.  The page is generated from pkg_info(1) and includes everything we
have installed from FreeBSD ports.


   The base Python 3.1 is installed there, but without any modules.
Below is the list of Python 2.6 modules installed.  Search that
page for py3, and you get nothing.

   On a hosting service, a raw Python with none of those modules isn't
very useful.

   This is what I mean about Python 3 not being ready for prime time.

John Nagle

Python packages on Vex:

py26-MySQLdb-1.2.2  Access a MySQL database through Python
py26-PyGreSQL-4.0,1	A Python interface to PostgreSQL, both classic and 
DP-API 2.0

py26-gdbm-2.6.4 Python bindings to the GNU dbm library
py26-psycopg-1.1.21_1   The high performance Python adapter for PostgreSQL
py26-pyPgSQL-2.5.1_3	A Python DB-API 2 compliant library for using 
PostgreSQL databases
py26-rrdtool_lgpl-1.0b1	Python interface to RRDTool, the graphing and 
logging utility

py26-sqlite3-2.6.4_1Standard Python binding to the SQLite3 library
py26-asn1-0.0.9a_1  ASN.1 toolkit for Python
py26-cElementTree-1.0.5_1   A fast C implementation of the ElementTree API
py26-cheetah-2.2.1  HTML template engine for Python
py26-elementtree-1.2.6_1	Container for hierarchical data structures 
written in Python
py26-setuptools-0.6c11	Download, build, install, upgrade, and uninstall 
Python packages

py26-statgrab-0.5   A set of Python bindings for libstatgrab
py26-twisted-8.2.0  Metaport of Twisted, an event-driven networking engine
py26-twistedCore-8.2.0	An asynchronous networking framework for Python - 
Core module

py26-twistedFlow-8.0.0  Generator based asynchronous result flows
py26-twistedRunner-8.2.0	Runner has process management, including an 
inetd replacement

py26-zopeInterface-3.5.2Zope.interface package from Zope 3
py26-twistedMail-8.2.0	An SMTP, IMAP and POP protocol implementation 
with clients and servers

py26-twistedPair-8.0.0  Twisted Pair can do low level TCP work

py26-twistedWords-8.2.0 Twisted Words has more chat than you can handle

py26-snmp-3.4.4 SNMP framework for Python
py26-twistedSNMP-0.3.13 Twisted Python framework for doing SNMP stuff
news
py26-twistedNews-8.2.0	An NNTP protocol implementation with client and 
server
py26-fail2ban-0.8.3_2	scans log files and bans IP that makes too many 
password failures.

py26-openssl-0.8_1  Python interface to the OpenSSL library
py26-paramiko-1.7.6 A python library for making SSH2 connections
py26-posix1e-0.4.0  Python module for manipulating POSIX.1e ACLs
py26-pycrack-0.5.1  Python bindings to cracklib
py26-pycrypto-2.1.0_1   The Python Cryptography Toolkit
py26-twistedConch-8.2.0	An SSH and SFTP protocol implementation with 
clients and servers

py26-docutils-0.5   Python Documentation Utilities
py26-dsv-1.4.0	A Python module to parse or write delimeter-separated 
(e.g. CSV) files

py26-twistedLore-8.2.0  Documentation generator with HTML and LaTeX support
py26-xml-0.8.4_2PyXML: Python XML library enhancements
py26-cherrypy-3.1.2 A pythonic, object-oriented web development framework
py26-django-1.1.1   High-level Python Web framework
py26-flup-1.0.2 Random assortment of WSGI servers, middleware
py26-twistedWeb-8.2.0	An HTTP protocol implementation together with 
clients and servers
py26-twistedWeb2-8.1.0	The next generation Web Server Framework built 
with Twisted

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

Re: The real problem with Python 3 - no business case for conversion