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 Python-Dev@python.org 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 timwin...@gmail.com 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On Fri, 2011-12-09 at 19:39 +0100, Xavier Morel wrote: On 2011-12-09, at 19:15 , Bill Janssen wrote: I use ElementTree for parsing valid XML, but minidom for producing it. Could you expand on your reasons to use minidom for producing XML? To throw my 2c in here: I personally normally use minidom for manipulating (x)html data (through html5lib), and for writing XML. I think it's primarily because DOM: a) matches the way I think about XML documents. b) Provides the same API as I use in other languages. (FWIW, I do a lot of DOM manipulation in javascript) c) Feels (to me) more similar to other formats I work with. All three may be because I haven't spent enough time with ElementTree - again I've found the documentation lacking. Tim ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Fri, 2011-04-01 at 08:37 +1000, Nick Coghlan wrote: On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo mer...@netwok.org wrote: If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable. Actual build fixes may be acceptable, if they're needed to allow people to build from a version control checkout or from source (since they need to be able to do that in order to apply security patches). However, the combination of running on Ubuntu 11.04+ and need to build security patched version of old Python seems unlikely. I disagree. FWIW - I maintain legacy code for python2.4, and 2.5 (mainly 2.5). I've reviewed upgrading this code to run on 2.7 - and it's too much work to do in the near future. I develop on Ubuntu (and will probably update to 11.04 in a few months) - so this will directly affect me. I'm fairly sure that others will be in the same situation. Even if their servers won't run ubuntu 11.04+ (or something with the same library paths), their development environments will. As a result, I'm very much +1 on integrating this patch to previous versions. Tim Wintle ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Mon, 2010-07-12 at 16:18 +0100, Michael Foord wrote: On 12/07/2010 15:07, Nick Coghlan wrote: On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Apranost...@pearwood.info wrote: re2 deliberately omits some features for efficiency reasons, hence is not even on the table as a possible replacement for the standard library version. If someone is in a position where re2 can solve their problems with the re module, they should also be in a position where they can track it down for themselves. If it has *partial* compatibility, and big enough performance improvements for common cases, it could perhaps be used where the regex doesn't use unsupported features. This would have some extra cost in the compile phase, but would mean Python could ship with two regex engines but only one interface exposed to the programmer... I'm not sure how common those cases are - I played around with RE2 a few months ago and found that the majority of regular expressions in my own code were noticeably slower running under RE2 than python's re module - RE2 just puts much nicer theoretical bounds on cases that were (in my code at least) unusual. The really good use case for RE2 is for applications where users can write regular expressions as input (exactly what RE2 was designed for) - but I'm not sure how common those applications are. Tim Wintle ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
On Wed, 2010-01-27 at 10:25 -0800, Collin Winter wrote: On Wed, Jan 27, 2010 at 7:26 AM, William Dode w...@flibuste.net wrote: I imagine that startup time and memory was also critical for V8. Startup time and memory usage are arguably *more* critical for a Javascript implementation, since if you only spend a few milliseconds executing Javascript code, but your engine takes 10-20ms to startup, then you've lost. Also, a minimized memory profile is important if you plan to embed your JS engine on a mobile platform, for example, or you need to run in a heavily-multiprocessed browser on low-memory consumer desktops and netbooks. (as a casual reader) I'm not sure if this has been specifically mentioned before, but there are certainly multiple uses for python - and from the arguments I've seen on-list, U-S appears to mainly appeal for one of them. The three main uses I see everyday are: * simple configuration-style applications (I'm thinking of gnome configuration options etc.) * shell-script replacements * Long running processes (web apps, large desktop applications etc) (in addition, I know several people working on python applications for mobile phones) I think the performance/memory tradeoffs being discussed are fine for the long-running / server apps (20mb on a 8Gb machine is negligable) - but I think the majority of applications probably fall into the other options - extra startup time and memory usage each time you have a server monitoring script / cronjob run becomes noticeable if you have enough of them. Among other reasons we chose LLVM, we didn't want to write code generators for each platform we were targeting. LLVM has done this for us. V8, on the other hand, has to implement a new code generator for each new platform they want to target. This is non-trivial work: it takes a long time, has a lot of finicky details, and it greatly increases the maintenance burden on the team. I'm not involved in either, but as someone who started watching the commit list on V8, I'd thoroughly agree that it would be completely impractical for python-dev to work as the V8 team seem to. What appear minor patches very frequently have to be modified by reviewers over technicalities, and I can't imagine that level of intricate work happening efficiently without a large (funded) core team focusing on code generation. Personally, picking up the (current) python code, I was able to comfortably start modifying it within a few hours - with the V8 codebase I still haven't got a clue what's going on where, to be honest. Tim Wintle ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
