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&quo
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
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 ridicu
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" st
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
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 v
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://
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 mo
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 es
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 we
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
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/issue21
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 qui
13 matches
Mail list logo
