Re: [Python-Dev] Fwd: Anyone still using Python 2.5?
On Thu, Dec 22, 2011 at 4:55 AM, Victor Stinner < [email protected]> wrote: > On 21/12/2011 15:26, anatoly techtonik wrote: > >> I believe most AppEngine applications in Python are still using 2.5 >> run-time. So are development boxes for these applications. It may take >> another year or two for the transition. >> > > App engine 1.6 improved support of Python 2.7, so I hope that -slowly- > everybody will move to Python 3. Oops, I mean Python 2.7 ;-) > > http://code.google.com/appengine/docs/python/python27/ > I've just got reminded that Python 2.7 support in AppEngine is still experimental, so the exodus is unlikely to happen soon. https://groups.google.com/forum/#!topic/google-appengine-python/tPbDEAHke64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Anyone still using Python 2.5?
On Wed, 2011-12-21 at 07:42 -0500, Barry Warsaw wrote: > On Dec 21, 2011, at 07:16 AM, Chris Withers wrote: > > >What's the general consensus on supporting Python 2.5 nowadays? > > FWIW, Ubuntu dropped 2.5 quite a while ago. Some servers I deploy to run Ubuntu, but we're installing previous python versions to support our apps - OS support isn't a factor in which version we develop for. I work on applications in 2.4-2.6. Generally: 2.4 apps are legacy and a migration is planned in the next year (either to 2.7 or to pypy). 2.5 apps are the speed-critical ones. Our tests showed the performance was different enough between 2.5 and 2.6 for me to not update. They also have significant native extensions in them so are potentially the most difficult to port to python3. 2.6 apps are newish and (mainly) pure python. I can see myself still using 2.5 for many years, but porting the 2.6 and 2.4 code to either pypy or python3 in the not too distant future. I believe we're most likely to choose python3 for apps with heavy use of Unicode (and pick a version after the changes to internal unicode format landed). Tim Wintle ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone still using Python 2.5?
On Thu, 22 Dec 2011 09:44:32 + Tim Wintle wrote: > > 2.5 apps are the speed-critical ones. Our tests showed the performance > was different enough between 2.5 and 2.6 for me to not update. Really? Where's the regression? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone still using Python 2.5?
Antoine Pitrou, 22.12.2011 10:56: On Thu, 22 Dec 2011 09:44:32 + Tim Wintle wrote: 2.5 apps are the speed-critical ones. Our tests showed the performance was different enough between 2.5 and 2.6 for me to not update. Really? Where's the regression? That's not unexpected at least, and matches my own (limited) experience here. My gut feeling is that Py2.6 added a lot of "new in Py3.0" overhead, but without all the optimisations that went into Py3.x since then. At least some of that came back later with Py2.7. Would be nice to (eventually) see Py2.[567] run in speed.python.org in order to get a better idea of the relative performance. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone still using Python 2.5?
On Thu, Dec 22, 2011 at 11:56 AM, Antoine Pitrou wrote: > On Thu, 22 Dec 2011 09:44:32 + > Tim Wintle wrote: >> >> 2.5 apps are the speed-critical ones. Our tests showed the performance >> was different enough between 2.5 and 2.6 for me to not update. > > Really? Where's the regression? > > Regards > > Antoine. Sounds weird, for all I know 2.6 is faster or not slower than 2.5. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone still using Python 2.5?
On Thu, 2011-12-22 at 10:56 +0100, Antoine Pitrou wrote: > On Thu, 22 Dec 2011 09:44:32 + > Tim Wintle wrote: > > > > 2.5 apps are the speed-critical ones. Our tests showed the performance > > was different enough between 2.5 and 2.6 for me to not update. > > Really? Where's the regression? I'm not certain - IIRC there were several nice optimisations in 2.6, and I wasn't expecting that when I first looked. I was running code designed for 2.5 under 2.6, so it's likely that with sufficient tweaking for 2.6 I might not have the same result. I tested this specific code with the python builds we have in production, not general python code - I don't mean this as a recommendation that anyone else assume 2.5 is faster for them. I suspect that Stefan's comments about newly added features without the optimisation in python3 might be partially true, but having the extra code to support them (while not using them) might also be part of the cause - ceval.c had over 1K line changes between r25 and r26, including cases for new opcodes, and new opcode predictions etc - it's possible that my code just happens to not follow the most optimal paths. I'm talking about a slow-down of under 10%, but enough that I couldn't justify moving these apps to 2.6 at the time for economic reasons, and pypy would be the main incentive to move this to 2.7. Tim ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] reading multiline output
Hi, I have started HandBrakeCLI using subprocess.popen but the output is multiline and not terminated with \n so i am not able to read it using readline() while the HandBrakeCLI is running. kindly suggest some alternative. i have attached the output in a file. output Description: Binary data -- Thanks Mac___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reading multiline output
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Thu, Dec 22, 2011 at 04:40:32PM +0530, Mac Smith wrote: > I have started HandBrakeCLI using subprocess.popen but the output is > multiline and not terminated with \n so i am not able to read it using > readline() while the HandBrakeCLI is running. kindly suggest some > alternative. i have attached the output in a file. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding GNU conditional execution in the Makefile?
> If this is a policy, I would like to know. As Guido says: Python should work with "traditional make", I think this is particularly relevant for the BSDs, and Solaris. > And if somebody has a suggestion to cope with this difficulty... Why don't you use some @FOO@ replacement? Have something expand to either the object file name, or nothing. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dict for Xmas?
> The current dict implementation is getting pretty old, > isn't it time we had a new one (for xmas)? I like the approach, and I think something should be done indeed. If you don't contribute your approach, I'd like to drop at least ma_smalltable for 3.3. A number of things about your branch came to my mind: - it would be useful to have a specialized representation for all-keys-are-strings. In that case, me_hash could be dropped from the representation. You would get savings compared to the status quo even in the non-shared case. - why does _dictkeys need to be a full-blown Python object? We need refcounting and the size, but not the type slot. - I wonder whether the shared keys could be computed at compile time, considering all attribute names that get assigned for self. The compiler could list those in the code object, and class creation could iterate over all methods (taking base classes into account). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] hg.python.org mod_wsgi changes
Hello, Today I've modified the WSGI configuration at hg.python.org. If you notify anything wrong (e.g. when cloning a repository), please tell me. For the curious: http://mercurial.selenic.com/bts/issue2595 Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dict for Xmas?
> - I wonder whether the shared keys could be computed at compile > time, considering all attribute names that get assigned for > self. The compiler could list those in the code object, and > class creation could iterate over all methods (taking base > classes into account). This is hard, because sometimes you don't quite know what the self *is* even, especially if __init__ calls some methods or there is any sort of control flow. You can however track what gets assigned at runtime at have shapes associated with objects. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 07:42:45AM -0500, Barry Warsaw wrote: >FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support) That's true for *CURRENT* releases, however Ubuntu still supports Python 2.5 via 8.04 LTS (end of life in April 2013). Lucid is 2.6 and goes EOL in 2015. Red Hat Enterprise is a bit more difficult a situation. They currently still have active support for Python 2.3 in RHEL 4, but that comes up to EOL in just a couple of months (Feb 2012). But they have this "extended life cycle" that ends in Feb 2015. RHEL 5 has python 2.4.3 and has an EOL of April 2014 (April 2017 for extended life cycle). There was a fairly large lag between RHEL 5 and RHEL 6 (almost 4 years), so there are a *LOT* of RHEL 5 systems out there. RHEL 6 has Python 2.6.6, BTW. This is why I recently released the "ineedpy2" package so that your program can request and search for specific versions of Python on a multi-python system. We have a number of systems that have Python 2.3 and older on them, but many of those systems have newer Pythons also available as alternate names. We recommend that whenever possible customers target deploying against the system python, meaning version 2.4.3 if they are deploying on CentOS 5. Because otherwise security updates of Python and *all the libraries they depend on* need to be tracked manually. Some customers decide to go one route, some to go the other, but that is our recommendation. Ideally, you are building your apps to target a production environment, not just using the latest and greatest Python without compelling reasons. So, yes, people are still using Python 2.5 and 2.4. Mostly this is people who have already deployed apps and are either fixing/updating them, or are adding new applications that they want to target the same production environment rather than setting up a new environment. Sean -- Linux, because eventually you grow up enough to be trusted with a fork(). Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
