[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 rep...@bugs.python.org 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
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 rep...@bugs.python.org http://bugs.python.org/issue21652 ___ ___ Python-bugs-list mailing list Unsubscribe: https://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 f...@users.sourceforge.net 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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 Python2.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 Python2.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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 rep...@bugs.python.org
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 f...@users.sourceforge.net 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 rep...@bugs.python.org 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 f...@users.sourceforge.net 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 rep...@bugs.python.org
http://bugs.python.org/issue2650
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5154] OSX broken poll testing doesn't work
James Y Knight f...@users.sourceforge.net 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 rep...@bugs.python.org http://bugs.python.org/issue5154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
