Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)
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. Not sure whom you had been talking to. But I would have tried to explain that you don't *have* to port to 2.6 to use 2to3 - it will work just as fine with 2.3 code, and earlier. - No use of sets. Instead I defined a very simple set simulation using dict keys, which could be interchanged with set for later versions. This I don't understand. IIUC, you want to support 2.3 and later. Now, 2.3 already has a set module, even though set is not a builtin. So you could use sets just as well. - No generator expressions, only list comprehensions. Ok. Not sure how this causes problems, though - just don't use them, then. - 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. Of course, users of older Python versions could explicitly wrap the functions with the decorator if they wanted to. - 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. If you don't need them, fine. If you do, I'd just let 2to3 transform them. - 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] Likewise, and more importantly so: use 2to3. It can be done this way, but I find the 2to3 solution much cleaner. 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). The same would have been possible if you had chosen to use 2to3. 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)
On Wed, 07 Jul 2010 14:10:57 -0700, Brendan Abel wrote: 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. I don't see that follows at all. If the incompatibilities are designed to be mechanically translatable (e.g. x.keys() - list(x.keys()) then you can start with a single code-base and run the translator. If only there were some sort of Python program that could be used to translate code from 2 to 3... *wink* -- 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/7/8 Michele Simionato michele.simion...@gmail.com: 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 I used the same approach (2.x default code base which gets translated by 2to3 at installation time) and I managed to do this with distutils alone by doing a little hack in setup.py. Take a look at: http://code.google.com/p/psutil/source/browse/tags/release-0.1.3/setup.py#11 Regards, --- 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)
On Jul 7, 2010, at 11:26 PM, Terry Reedy wrote: 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. That document is here: http://wiki.python.org/moin/PortingExtensionModulesToPy3k It took me a while to find. It's a shame it's not better known; I looked for such a document before I started porting sysv_ipc and posix_ipc and didn't find this one. Thanks for the pointer. 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)
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 overall it is only a few thousand lines of code. But I just offer this post as a concrete data point in this discussion. -- Paul --
Re: The real problem with Python 3 - no business case for conversion (was I strongly dislike Python 3)
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)
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)
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)
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)
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)
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 (was I strongly dislike Python 3)
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 (was I strongly dislike Python 3)
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)
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)
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 (was I strongly dislike Python 3)
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 (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 (was I strongly dislike Python 3)
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 (was I strongly dislike Python 3)
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)
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)
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 (was I strongly dislike Python 3)
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)
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)
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)
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/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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 (was I strongly dislike Python 3)
On 07/02/2010 09:07 PM, John Nagle wrote: 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. That depends VERY strongly on the environment in question. 2.Get those modules converted to Python 3. The stdlib is there. The rocky bits are being fixed all the time. The other important modules all have strong development communities. Upstream numpy works with Python 3 already. (no release yet) That enables SciPy to update, which they will do. PyGObject is also working on Py3 support. 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. The use cases for Python being as diverse as they are, this is utter nonsense. Also, I myself see no benefit in making PyPI a mirror of everything, as opposed to a useful index of packages that you may or may not want to use. 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.) Current Ubuntu releases include Python 3.1 as /usr/bin/python3. So does Debian (not sure about stable at this point). I'm sure the other major Linux distributions are doing the same thing. It's happening! 5.Get at least two major hosting services to put up Python 3. Apparently, some hosters already support Python 3. Web development is a bit of a weak spot at the moment though, and this is problematic, due to WSGI not being quite unicode ready. 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. It's not happening fast, it probably can't, but it *is* happening. Software distributions are including Python 3, and popular modules/packages are starting to support it. Other software is going to move on in its own time. -- 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 Jul 2, 12:07 pm, John Nagle na...@animats.com wrote: This has all been said before. Yes, we know. And when no one did anything about it the first dozen times it's been said, it wasn't because we didn't hear it, it was because we didn't care. We still don't care now, and won't care no matter how many times you repeat it, because it's simply wrong. So, please do everyone a favor, and stop wasting your own time, and stop repeating this. Carl Banks -- 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)
In article 4c2e38f5.10...@animats.com, John Nagle na...@animats.com wrote: 5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 -- 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 (was I strongly dislike Python 3)
On 7/2/2010 3:00 PM, Aahz wrote: In article4c2e38f5.10...@animats.com, John Naglena...@animats.com wrote: 5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 WebFaction's big thing is that they have a really good system for installing anything the user wants. They're doing semi-virtual machine hosting, where each user sees a somewhat different environment, but doesn't have their own copy of the Linux kernel. That's a nice advance in server management. Any user can install Python 3.x, but it's not there by default. See: http://blog.webfaction.com/python-3-0-is-here; If that approach catches on, Python 3 deployment will be much easier. But for now, only a few smaller players like WebFaction are using it. 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)
On Fri, 02 Jul 2010 12:07:33 -0700, John Nagle wrote: 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 you (generic you, not John specifically) can't, then don't. It's as simple as that. Stick with 2.6, or 2.7, or even 1.5 if that's the version you're using. A client of mine is still using 2.3. That's okay. It's allowed. If your business case is best satisfied by staying with 2.x until the sun burns out, more power to you. Just don't expect security upgrades (let alone functional upgrades) for more than a few years. If they are important to you, then *that's* your business case for upgrading. But if you're starting a new project, there is no cost of conversion. -- 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)
On Sat, Jul 3, 2010 at 5:27 AM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Fri, 02 Jul 2010 12:07:33 -0700, John Nagle wrote: 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? The point is python2.7 is the last 2.x version. It will be supported, bugs will be fixed but no new feature will be added. Core devs will concentrate on python 3.x. You can still use 2.x, no one is stopping you. But assume that it is stagnant now. After some time only security related bugs will be fixed. So if you want to wait by then, it's all your wish. ~l0nwlf -- 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)
In article 4c2e79d3$0$1663$742ec...@news.sonic.net, John Nagle na...@animats.com wrote: On 7/2/2010 3:00 PM, Aahz wrote: In article4c2e38f5.10...@animats.com, John Naglena...@animats.com wrote: 5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 Any user can install Python 3.x, but it's not there by default. Yes, it is. I logged into my webfaction shell, typed python3.1, and got a standard Python prompt, without doing anything whatsoever to make Python 3.1 available. http://blog.webfaction.com/python-3-0-is-here; Is there some reason you're using a broken URL format? If that approach catches on, Python 3 deployment will be much easier. But for now, only a few smaller players like WebFaction are using it. In the hosting space that makes Python available, WebFaction is hardly a smaller player. -- 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 (was I strongly dislike Python 3)
On 7/2/2010 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. False. One cannot run code in 2.6 that depends on bugfixes in 3.1. Nor can one run code with unicode identifiers. The exclusive new features in 3.1 and 3.2 are less than they might have been because the developers expended extra effort, now ended, to backport new things developed for 3.x. (One result was some neglect of the stdlib, which is now the focus of efforts.) One reason was to make porting to 3.x easier should one wish to do so. The other reason was to make some thing available should one wish not to do so. Using that extra effort as a reason to put down 3.x is not very gracious. There's no killer app for it. For some, unicode identifiers are 'killer reason' to use 3.1. Anyway, can you name me a killer app for each and every version of 2.x? End of life for Python 2.x is many years away; Given that 1.x is still used, so what? most server Linux distros aren't even shipping with 2.6 yet. How can a business justify spending money on conversion to Python 3? How can a business justify spending money on conversion to 2.0, 2,1, 2.2, 2.3, 2.4, 2.5, 2.6, or soon, 2.7? Some cannot for some projects and have not. Enough with strawman arguments against claims no sensible person has made. Python3 was developed for new Python programmers and current programmers who wished to add or switch. It was developed for new code and old code that would benefit from the changes. -- 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)
On 2 Jul 2010 15:00:17 -0700 a...@pythoncraft.com (Aahz) wrote: 5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 So does http://www.Vex.Net/ so there's your two. -- 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)
On 7/2/2010 9:10 PM, D'Arcy J.M. Cain wrote: On 2 Jul 2010 15:00:17 -0700 a...@pythoncraft.com (Aahz) wrote: 5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 So does http://www.Vex.Net/ so there's your two. Not according to Vex's published package list: http://www.vex.net/info/tech/pkglist/ They list packages only for Python 2.6. vex.net isn't exactly a major hosting service. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
