Marc-Andre Lemburg added the comment:
The problem is also present in Python 2.4 and 2.3. Confirmed on AIX 5.3.
--
nosy: +lemburg
versions: +Python 2.3, Python 2.4
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Marc-Andre Lemburg added the comment:
I think you have a wrong understanding of round-tripping.
In Unicode it is really irrelevant if you're using a UCS2 surrogate pair
or a UCS4 representation to describe a code point. The length of the
Unicode representation may change, but the meaning
Changes by Jean-Marc Gillet:
--
nosy: jmgillet
severity: minor
status: open
title: 0**0 should raise an error
type: behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Jean-Marc Gillet:
The result is actually undefined, as x**0 gives 1 and 0**x gives 0.
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more infor
Jean-Marc Gillet added the comment:
See http://en.wikipedia.org/wiki/Exponentiation "Zero to the zero
power". There are pros and cons of 0**0==1 so if you mark this one as
"wontfix" I promise not to bother you again :-)
__
Tracker <[
Marc-Andre Lemburg added the comment:
Rejecting the patch, since it hasn't been updated.
--
resolution: -> rejected
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Marc-Andre Lemburg added the comment:
Tom Christiansen wrote:
>
> I'm pretty sure that anything that claims to be UTF-{8,16,32} needs
> to reject both surrogates *and* noncharacters. Here's something from the
> published Unicode Standard's p.24 abo
Marc-Andre Lemburg added the comment:
The final parameter is an extension to the decoder API signature,
so it's not surprising that not all codecs implement it.
The ones that do should use it for all calls, since that way
the actual consumed number of bytes is correctly reported
back t
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> New submission from Antoine Pitrou :
>
> This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.
>
> Example micro-benchmark:
>
> ./python -m timeit -s "a='x'*1
Marc-Andre Lemburg added the comment:
[Posted the reply to the right ticket; see issue13136 for the original
post to the wrong ticket]
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> Before going further with this, I'd suggest you have a look at your
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
>> I tested using memchr() when writing those "naive" loops.
>
> memchr() is mentioned in another issue, #13134.
Looks like I posted the comment to the wrong ticket.
--
_
Marc-Andre Lemburg added the comment:
I don't see why these modules should be auto-generated. The constants
in the modules hardly ever change and are also not affected by architecture
differences (e.g. Mac OS X, Solaris, etc.) AFAICT.
If you think they need to be auto-generated, you s
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> you should make a case by example
>
> Did you read comments of this issue and my email thread on python-dev?
No.
> There are differents examples:
>
> - L
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> The error comes from the way Python computes timezone and daylight: it
> queries the tm_gmtoff of two timestamps, one close to the first of January,
> the other close to the first of July. But last Jan
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> A fairly "correct" way is to query the time zone database at time module
>> import time by using the DST and GMT offset of that tim
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>>> But that does not give the *other* timezone :-(
>> Which other timezone ?
> I meant the other timezone *name*.
>
> I think we don&#x
Marc-Andre Lemburg added the comment:
Terry J. Reedy wrote:
>
> Terry J. Reedy added the comment:
>
> Martin, I do not understand. The default hash is based on id (as is default
> equality comparison), not value. Are you OK with hash values changing if the
> &
Marc-Andre Lemburg added the comment:
Some comments:
1. The security implications in all this is being somewhat overemphasized.
There are many ways you can do a DoS attack on web servers. It's the
responsibility of the used web frameworks and servers to deal with
the possible cases.
I
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> 3. Changing the way strings are hashed doesn't solve the problem.
>
> Hash values of other types can easily be guessed as well, e.g.
> take integers which use a trivial hash function.
Here's an exa
Marc-Andre Lemburg added the comment:
The email interface ate part of my reply:
>>> g = ((x*(2**64 - 1), hash(x*(2**64 - 1))) for x in xrange(1, 100))
>>> s = ''.join(str(x) for x in g)
>>> len(s)
32397634
>>> g = ((x*(2**64 - 1), hash(x*(2
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> 1. The security implications in all this is being somewhat overemphasized.
>
> There are many ways you can do a DoS attack on web servers. It's the
> responsibility of the used web frameworks and server
Marc-Andre Lemburg added the comment:
Paul McMillan wrote:
>
> This is not something that can be fixed by limiting the size of POST/GET.
>
> Parsing documents (even offline) can generate these problems. I can create
> books that calibre (a Python-based ebook format shift
Marc-Andre Lemburg added the comment:
Before continuing down the road of adding randomness to hash
functions, please have a good read of the existing dictionary
implementation:
"""
Major subtleties ahead: Most hash schemes depend on having a "good" hash
function, i
Marc-Andre Lemburg added the comment:
Demo patch implementing the collision limit idea for Python 2.7.
--
Added file: http://bugs.python.org/file24151/hash-attack.patch
___
Python tracker
<http://bugs.python.org/issue13
Marc-Andre Lemburg added the comment:
The hash-attack.patch solves the problem for the integer case
I posted earlier on and doesn't cause any problems with the
test suite.
Traceback (most recent call last):
File "", line 1, in
KeyError: 'too many hash collisions'
I
Marc-Andre Lemburg added the comment:
Stupid email interface again... here's the full text:
The hash-attack.patch solves the problem for the integer case
I posted earlier on and doesn't cause any problems with the
test suite.
>>> d = dict((x*(2**64 - 1), hash(x*(2**64 - 1))
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> hash-attack.patch does never decrement the collision counter.
Why should it ? It's only used as local variable in the lookup function.
Note that the limit only triggers o
Marc-Andre Lemburg added the comment:
Here's an example of hash-attack.patch finding an on-purpose
programming error (hashing all objects to the same value):
http://stackoverflow.com/questions/4865325/counting-collisions-in-a-python-dictionary
(see the second example on the page for @Wi
Marc-Andre Lemburg added the comment:
Paul McMillan wrote:
>
>> I'll upload a patch that demonstrates the collisions counting
>> strategy to show that detecting the problem is easy. Whether
>> just raising an exception is a good idea, is another issue.
>
>
Marc-Andre Lemburg added the comment:
Tim Peters wrote:
>
> Tim Peters added the comment:
>
> [Marc-Andre]
>> BTW: I wonder how long it's going to take before
>> someone figures out that our merge sort based
>> list.sort() is vulnerable as well... its wors
Marc-Andre Lemburg added the comment:
Christian Heimes wrote:
> Marc-Andre:
> Have you profiled your suggestion? I'm interested in the speed implications.
> My gut feeling is that your idea could be slower, since you have added more
> instructions to a tight loop, that is
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Christian Heimes wrote:
>> Marc-Andre:
>> Have you profiled your suggestion? I'm interested in the speed implications.
>> My gut feeling is that y
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> Patch version 5 fixes test_unicode for 64-bit system.
Victor, I don't think the randomization idea is going anywhere. The
code has many issues:
* it is exceedingly complex
* the method would need to be implemen
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> * it is exceedingly complex
>
> Which part exactly? For hash(str), it just add two extra XOR.
I'm not talking specifically about your patch, but the whole idea
Marc-Andre Lemburg added the comment:
Mark Shannon wrote:
>
> Mark Shannon added the comment:
>
>>>> * the method would need to be implemented for all hashable Python types
>>> It was already discussed, and it was said that only hash(str) need to
>>>
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> OTOH, the collision counting patch is very simple, doesn't have
>> the performance issues and provides real protection against the
>> attack.
>
> I
Marc-Andre Lemburg added the comment:
Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> [Antoine]
>> Also, how about false positives? Having legitimate programs break
>> because of legitimate data would be a disaster.
>
> This worries me, too.
&
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> On my slow dev machine 1000 collisions run in around 22ms:
>>
>> python2.7 -m timeit -n 100 "dict((x*(2**64 - 1), 1) for x in xrange(1,
>> 1000))&q
Marc-Andre Lemburg added the comment:
Frank Sievertsen wrote:
>
> I don't want my software to stop working because someone managed to enter
> 1000 bad strings into it. Think of a software that handles names of customers
> or filenames. We don't want it to break c
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> I suggest to:
> 1) remove the alias for tactis;
> 2) add the aliases for latin_* and the tests for the aliases;
> 3) fix the email.charset to use the new aliases in
Marc-Andre Lemburg added the comment:
I think it's better to use a StringIO instance for the tests.
Regarding resetting the incremental codec every time .encode() is called:
Hye-Shik will have to comment. Perhaps there's an internal reason why the
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> euc_jp and euc_kr seem to be backward (that is, codecs translates them to the
> _ version, instead of translating the _ version to the - version). I worry
> that th
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> Sometimes, we need to know the version of the Linux kernel. Recent examples:
> test if SOCK_CLOEXEC or O_CLOEXEC are supported by the kernel or not. Linux <
> 2.6.
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> The returned value should be a version string in a fixed format,
>> not a tuple. I'd suggest to use _norm_version() for this.
>
> How do you compare vers
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Use "%s.%s.%s" % linux_version() if you would like to format the version. The
> format is well defined. (You should only do that under Linux.)
No, please follow th
Marc-Andre Lemburg added the comment:
Closing the ticket again.
We still need codecs.open() to support applications that target Python 2.x and
3.x.
You can reopen it after Python 2.x has been end-of-life'd.
--
resolution: -> postponed
status: open -
Marc-Andre Lemburg added the comment:
Correcting the title: this ticket is about codecs.open(), not StreamRead and
StreamWriter, both of which are essential parts of the Python codec machinery
and are needed to be able to implement per-codec implementations of codecs
which read from and
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> Codec.encode() and Codec.decode() refer to StreamCode, but I cannot find this
> class in the doc nor in the code.
>
> I suppose that it should be replaced by I
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> You can then use linux_version().split('.') in code that want
>> to do version comparisons.
>
> It doesn't give the expected result:
>
&g
Changes by Marc-Andre Lemburg :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12158>
___
___
Pyth
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> TextIOWrapper() is conceptually something completely different. It's
>> more something like StreamReaderWriter().
>
> That's a rather strange asser
Changes by Marc-Andre Lemburg :
--
title: Deprecate codecs.open(), codecs.StreamReader and codecs.StreamWriter ->
Deprecate codecs.open()
___
Python tracker
<http://bugs.python.org/iss
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I think it's better to use a StringIO instance for the tests.
>
> For which test excatly? An encoder produces bytes, I don't the relation with
> StringIO
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> Do we need an additional method? It seems that this reset() could also be
> written encoder.encode('', final=True)
+1
I think that
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Le mercredi 25 mai 2011 à 08:23 +, Marc-Andre Lemburg a écrit :
>>> Do we need an additional method? It seems that this reset() could
>>> also be written
Marc-Andre Lemburg added the comment:
Éric Araujo wrote:
>
> Éric Araujo added the comment:
>
> Definitely. We can fix real bugs in distutils, but sometimes it’s best to
> avoid disruptive changes and let distutils with its buggy behavior and let
> the packaging mo
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> What is not-a-charset?
>
> I apparently misunderstood what normalize_encodings does. It isn't doing a
> lookup in the codecs registry and returning the ca
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> Well, my thought was to avoid having multiple charset alias lists in the
> stdlib, and reusing the one in codecs, which is larger than the one in email,
> seemed to
Marc-Andre Lemburg added the comment:
Roundup Robot wrote:
>
> Roundup Robot added the comment:
>
> New changeset 3555cf6f9c98 by Victor Stinner in branch 'default':
> Issue #8796: codecs.open() calls the builtin open() function instead of using
> http
Marc-Andre Lemburg added the comment:
Michele Orrù wrote:
>
> Michele Orrù added the comment:
>
> Any idea about how to unittest mime.aliases?
Test the APIs you probably created for accessing it.
> Also, since I've just created a new file, are there some buracratic iss
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> '\u1ff3'.upper() returns '\u1ffc', so we have:
> U+1FF3 (ῳ - GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI)
> U+1FFC (ῼ - GREEK CAPITAL LETTER OMEGA WITH
Changes by Jean-Marc Saffroy :
Removed file: http://bugs.python.org/file21443/netrc.patch
___
Python tracker
<http://bugs.python.org/issue11416>
___
___
Python-bugs-list m
Jean-Marc Saffroy added the comment:
Ping? A patch is available for review.
--
___
Python tracker
<http://bugs.python.org/issue11416>
___
___
Python-bugs-list m
Marc-Andre Lemburg added the comment:
Chris Rebert wrote:
>
> Chris Rebert added the comment:
>
> Per msg129958, attached is my stab at a patch to replace most uses of
> os.popen() with the subprocess module. The test suite passes on my Mac, but
> the patch does touc
Jean-Marc Saffroy added the comment:
You are suggesting something like this, I suppose?
--- a/Lib/netrc.py
+++ b/Lib/netrc.py
@@ -105,8 +105,8 @@ class netrc:
def __repr__(self):
"""Dump the class data in the format of a .netrc file."""
Jean-Marc Saffroy added the comment:
Patch slightly updated after Eric's comments.
--
Added file: http://bugs.python.org/file22193/netrc.patch
___
Python tracker
<http://bugs.python.org/is
Jean-Marc Saffroy added the comment:
Patch formatting changed to be more review-friendly (looks like MQ-style patch
isn't?), otherwise same as 2011-05-30 16:14.
--
Added file: http://bugs.python.org/file22194/netrc.patch
___
Python tracker
Jean-Marc Saffroy added the comment:
Eric: yes I can look into the asserts, but note I generated and tested my patch
from a checkout of 2.6 (see my first report), so maybe that's why I didn't see
any warning.
--
___
Python trac
Jean-Marc Saffroy added the comment:
Here is a patch against 2.7.
--
Added file: http://bugs.python.org/file22195/netrc.patch
___
Python tracker
<http://bugs.python.org/issue11
Jean-Marc Saffroy added the comment:
Additional patch for docstrings and documentation. Applies on top of previous
patch.
--
Added file: http://bugs.python.org/file22204/netrc-doc.patch
___
Python tracker
<http://bugs.python.org/issue11
Marc-Andre Lemburg added the comment:
mike bayer wrote:
> >
> > mike bayer added the comment:
> >
> > regarding "hey this is an MS bug not Python", projects which feature
> > optional C extensions are starting to apply workarounds for the issue on
Marc-Andre Lemburg added the comment:
Stefan Krah wrote:
> >
> > Stefan Krah added the comment:
> >
> > Marc-Andre Lemburg wrote:
>> >> Wouldn't it be better to have distutils tell the user about the
>> >> possible options, instead of
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> The change to sys.platform=='linux' would break code even on current
>> platforms.
>
> Correct. Compared to introducing 'linux3', I consi
Marc-Andre Lemburg added the comment:
I think it would be better to use this code:
if (!Py_UNICODE_ISUPPER(*s)) {
*s = Py_UNICODE_TOUPPER(*s);
status = 1;
}
s++;
while (--len > 0) {
if (Py_UNICODE_ISLOWER(*s)) {
*s = Py_UNICODE_TOLOWER
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Do you mean "if (!Py_UNICODE_ISLOWER(*s)) {" (with the '!')?
Sorry, here's the correct version:
if (!Py_UNICODE_ISUPPER(*s)) {
*s = Py_UN
Marc-Andre Lemburg added the comment:
Alan Justino wrote:
>
> I am getting a hard time trying to do some BDD with c-based datetime because
> I cannot mock it easily to force datetime.datetime.now() to return a desired
> value, making almost impossible to test time-based co
Marc-Andre Lemburg added the comment:
Tom Christiansen wrote:
>
> Tom Christiansen added the comment:
>
> Please do not call this "utf-8-java". It is called "cesu-8" per UTS#18 at:
>
> http://unicode.org/reports/tr26/
>
> CESU-8 is *not* a a v
Marc-Andre Lemburg added the comment:
Corrected the title again. See my comment.
--
title: Add CESU-8 codec ("java modified utf-8") -> Add "java modified utf-8"
codec
versions: +Python 3.3 -Python 2.7, Python 3.2
__
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Corrected the title again. See my comment.
Please open a new ticket, if you want to add a CESU-8 codec.
Looking at the relevant use cases, I'm at most +0 on adding the
modified UTF-8 codec. I think such codecs ca
Marc-Andre Lemburg added the comment:
> Keep in mind that we should be able to access and use lone surrogates too,
> therefore:
> s = '\ud800' # should be valid
> len(s) # should this raise an error? (or return 0.5 ;)?
> s[0] # error here too?
> list(s) # he
Marc-Andre Lemburg added the comment:
Julian Taylor wrote:
>
> New submission from Julian Taylor :
>
> using unicode strings for locale.normalize gives following traceback with
> python2.7:
>
> ~$ python2.7 -c 'import locale; locale.normalize(u"en_US")
Marc-Andre Lemburg added the comment:
Maxim Koltsov wrote:
>
> New submission from Maxim Koltsov :
>
> Python docs (http://docs.python.org/library/time.html#time.time) say that
> time.time() function should return UTC timestamp, but actually i get local
> one:
>>&g
Changes by Marc-Andre Lemburg :
--
assignee: -> docs@python
components: +Documentation, Library (Lib)
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issu
Changes by Marc-Andre Lemburg :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue12758>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> A PEP 393 draft implementation is available at
> https://bitbucket.org/t0rsten/pep-393/ (branch pep-393); if this gets into
> 3.3, this issue will be outdated: there won't be "narrow" builds of Python
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> #10542 proposes the following macros to factor out common code:
> #define _Py_UNICODE_ISSURROGATE
> #define _Py_UNICODE_ISHIGHSURROGATE
> #define _Py_UNICODE_ISLO
Marc-Andre Lemburg added the comment:
Tom Christiansen wrote:
> So keeping your preamble bits, I might have considered doing it
> this way if it were me doing it:
>
> #define _Py_UNICODE_IS_SURROGATE
> #define _Py_UNICODE_IS_LEAD_SURROGATE
> #define _Py_UNICODE_
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I'm reposting my patch from #12751. I think that it's simpler than
> belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't
&
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> STINNER Victor wrote:
>>
>> STINNER Victor added the comment:
>>
>> I'm reposting my patch from #12751. I think that it's simpler than
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Le 17/08/2011 07:04, Ezio Melotti a écrit :
>> As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and
>> Py_UNICODE_JOIN_SURROGATES can be committ
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>> Ezio used two different naming schemes in his email. Please always
>> use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_).
>
> Indeed, that was a typ
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>> For bug fixes, you can put the macros straight into unicodeobject.c,
>> but please leave unicodeobject.h untouched - otherwise people will
>> mess around with the
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I don't think that macros specific to unicodeobject.c should get the
> _PY_UNICODE_ prefix. "_Py_" prefix is reserved to exported symbols, but
> symbols re
Marc-Andre Lemburg added the comment:
Some thoughts:
* We can't change the value of a system variable in a patch level
release. It's not a bug and the change is not motivated by
Python, but by the OS vendor. So changes to released versions
are not possible. They ar
Marc-Andre Lemburg added the comment:
James Y Knight wrote:
>
> 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.
Marc-Andre Lemburg added the comment:
Barry A. Warsaw wrote:
>
> Barry A. Warsaw added the comment:
>
> On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote:
>
>> As for the cases where "linux3" is reported: I don't care that
>> they break. Python
Marc-Andre Lemburg added the comment:
James Y Knight wrote:
>
> 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 ?
Marc-Andre Lemburg added the comment:
Martin von Gagern wrote:
>
> Martin von Gagern added the comment:
>
> Marc-Andre Lemburg wrote:
>> Both Python and the application will make certain assumptions about
>> the platform depending on the compile time environment.
&g
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> The suggested change removes the compile time information from
>> the platform string, so that information needs to be preserved
>> in a new attribute.
Marc-Andre Lemburg added the comment:
Éric Araujo wrote:
>
> Éric Araujo added the comment:
>
>> We do have distutils to read the full compile time information
> We have sysconfig in the stdlib in 2.7 and 3.2+.
Right (it originated in distutils), but it has the same pr
301 - 400 of 2239 matches
Mail list logo
