[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight added the comment: Oh wow, so it depends on the *build* time major version? That's really not useful at all for linux 2.x and 3.x; there is nothing useful anyone can possibly do with the distinction between platform == "linux2" and platform == "linux3". All it could possibly do is to break apps. Given that: a) old versions of Python won't even build without a patch and b) changing platform to linux3 will break a lot of python apps that check sys.platform. c) It's completely useless to change it, as the change contains no actual information. Why is forcing sys.platform to remain linux2 not the *obviously right thing to do*? -- nosy: +foom ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight added the comment: > I will backport the fix to 2.7 and 3.2. Uh, wait, so does that mean you're *not* going to do the compatibility-preserving thing and force sys.platform to stay linux2 even when python is built (BUILT! not run!) on a machine where the active kernel is linux 3.x? -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight added the comment: > Well, except maybe if you plan to write applications working only on Python > >= 2.7.3? ... this version is not released yet. No, of course I don't plan on writing new code that checks sys.platform == 'linux2'. That's ridiculous. I plan to use *already written* applications on Python<2.7.3 binaries that have already been built (and thus were built on a 2.x kernel and report linux2), on Python>=2.7.3 which will be fixed to continue reporting linux2, and on Python<2.7.3 which have had the same fix backported to them by distros, since Python upstream won't do it for earlier branches. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight added the comment: M.A., your comments do not make sense in the context of Linux. It does not actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive than Linux 2.6.38 to Linux 2.6.39. *Except* that python ill-advisedly exported a "platform" string which included a value which is completely irrelevant on Linux, and has now changed. The bug here that should be fixed in release branches is that Python put the build-time linux major kernel version in sys.platform in the first place, instead of making it just be "linux". If anyone had a time machine, the right thing would be to go back in time and make Python never put the "2" there. But, since they're hard to come by (rumors to the contrary aside...), the best fix at this point is to retain consistency with earlier patch releases and force it to remain "linux2" no matter what. Again, the number provides literally *no* useful information. You can compile Python on kernel version 2.x and then run it on a 3.x kernel (sys.platform will be "linux2" in that case). You can also compile python on a 3.x kernel and then run it on a 2.x kernel (sys.platform will be "linux3" in that case). Other than the 2 vs 3 encoded into a bunch of places inside Python, the two copies of python should be 100% identical. So, there is also no need to provide this useless value under a different variable name. BTW, all the above goes for everywhere Python uses "linux[23]" right now, such as pathnames, not just literally the value of sys.platform. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight added the comment: > Sure, you can compile and run Python on both versions of Linux, but > what if your application uses features that are only present in Linux > 3.0 and later ? This comment is making me think you've missed just how irrelevant kernel version 3.0 really is. To a first approximation, it *has no new features*. Now, to be sure, there are a couple of things, sure. Just like there were a couple new features in 2.6.39 two months earlier, 2.6.38 two months before that, 2.6.37 two months before that, and so on, every 2-3 months, back to the release of 2.6.7 or so in 2004. > BTW: The new attribute should contain the complete version number, > not just the major version. `uname -r` would provide a good start. To be useful, that would have to be a runtime-computed thing, not the build-time value that sys.platform's trailing number is. But we already have that: os.uname(). It certainly doesn't need a second name. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight added the comment: YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't it, since that's been fixed at linux2 approximately forever). Why do you think people would suddenly start needing to know the build-time kernel version now? -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight added the comment: > configure_linux2.python3.2.patch It would probably be more future-proof to use "linux*)", not "linux3)" in the case expression. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
James Y Knight added the comment:
I just ran into the impl of escape after being surprised that '/' was being
escaped, and then was completely amazed that it wasn't just implemented as a
one-line re.subn. Come on, a loop for string replacement? This is *in* the
freaking re module for pete's sake!
The extra special \\000 behavior seems entirely superfluous, as well. re works
just fine with nul bytes in the pattern; there's no need to special case that.
So:
return
re.subn('([^abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890])',
'\\1', pattern)[0]
or, for the new proposed list of special chars:
return re.subn('([][.^$*+?{}\\|()])', '\\1', pattern)[0]
(pre-compilation of pattern left as an exercise to the reader)
--
nosy: +foom
___
Python tracker
<http://bugs.python.org/issue2650>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
James Y Knight added the comment:
Show your speed test? Looks 2.5x faster to me. But I'm running this on python
2.6, so I guess it's possible that the re module's speed was decimated in Py3k.
python -m timeit -s "$(printf "import re\ndef escape(s):\n return
re.sub('([][.^$*+?{}\\|()])', '\\\1', s)")"
'escape("!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()")'
10 loops, best of 3: 18.4 usec per loop
python -m timeit -s "import re"
're.escape("!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()!@#$%^&*()")'
1 loops, best of 3: 45.7 usec per loop
--
___
Python tracker
<http://bugs.python.org/issue2650>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
James Y Knight added the comment: Right you are, it seems that python's regexp implementation is terribly slow when doing replacements with a substitution in them. (fixing the broken test, as you pointed out changed the timing to 97.6 usec vs the in-error-reported 18.3usec.) Oh well. I still think it's crazy not to use re for this in its own module. Someone just needs to fix re to not be horrifically slow, too. :) -- ___ Python tracker <http://bugs.python.org/issue2650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21652] Python 2.7.7 regression in mimetypes module on Windows
New submission from James Y Knight: The change done for issue9291 in Python 2.7.7 caused the mimetypes.types_map dict to change to contain a mixture of str and unicode objects, rather than just str, as it always had before. This causes twisted.web to crash when serving static files on Windows. See https://twistedmatrix.com/trac/ticket/7461 for the bug report against Twisted. -- components: Library (Lib) messages: 219693 nosy: Daniel.Szoska, Dmitry.Jemerov, Hugo.Lol, Michał.Pasternak, Roman.Evstifeev, Suzumizaki, Vladimir Iofik, aclover, adamhj, brian.curtin, eric.araujo, foom, frankoid, haypo, jason.coombs, kaizhu, loewis, me21, python-dev, quick.es, r.david.murray, shimizukawa, tim.golden, vldmit priority: normal severity: normal status: open title: Python 2.7.7 regression in mimetypes module on Windows type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21652] Python 2.7.7 regression in mimetypes module on Windows
James Y Knight added the comment: Reverting the incorrect commit which caused the regression would be a good start. -- ___ Python tracker <http://bugs.python.org/issue21652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5154] OSX broken poll testing doesn't work
James Y Knight added the comment: The reason it's a problem is because a "device" is everything other than a socket, pipe, slave-side of tty, or file. That is, /dev/null, /dev/zero, /dev/tty, psuedo-tty masters from openpty (e.g. for running subprocesses), etc. I find it quite amazing that this is still broken after so long. Would it really be that hard for them to unify the select() and poll() code in the kernel? Sigh. BTW, this same issue also affects kqueue. But I'd say that Apple's utter failure in writing a working kernel is not really enough reason to disable the poll call for Python. If people want to use it only for the kinds of files that it works for, I don't see why python should prevent that. Note that in the distant past, poll on OSX was *severely* broken, as it was a userspace wrapper over select(). In those days, disabling it was certainly the right thing to do. -- nosy: +foom ___ Python tracker <http://bugs.python.org/issue5154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
