New submission from Colin Marc colinm...@gmail.com:
Recent versions of OpenSSL (1.0.1 and greater) support a new extension to
SSL/TLS called Next Protocol Negotiation, defined here:
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02.
The extension allows servers and clients
Colin Marc colinm...@gmail.com added the comment:
If I ported it to 3.3 or 3.4, would it then be backported to 2.7? Or is there
zero chance of that either? If so, why? I apologize, I'm new to the process.
--
___
Python tracker rep...@bugs.python.org
Colin Marc colinm...@gmail.com added the comment:
Re the IETF draft: I'm not sure. However, I didn't actually have to implement
the specification at all - that was all handled by OpenSSL. My patch just calls
the appropriate SSL_CTX_* methods.
Thanks for the tip. I'm still interested
Marc Abramowitz msabr...@gmail.com added the comment:
Limiting to 10.6 and above seems entirely reasonable to me. I am one of the few
folks that I know who is still on 10.6. Most of my friends are on 10.7.
Since OS X is primarily a desktop OS, I think people tend to upgrade more
quickly
Marc Abramowitz msabr...@gmail.com added the comment:
I wanted to post an update on FreeBSD 9.0, which Jesús and I worked on a bit
yesterday.
Maybe Jordan will chime in here with an answer to my FreeBSD problems. :-)
With a little bit of Makefile hackery (make it skip building the phelper
Marc Abramowitz msabr...@gmail.com added the comment:
[marca@freebsd9-0 ~]$ /home/marca/custom/bin/python
Python 2.7.2+ (dtrace-issue13405_2.7:e612f29478e3+, Feb 27 2012, 20:37:22)
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9
Type help, copyright, credits or license for more information
Marc Abramowitz msabr...@gmail.com added the comment:
For anyone who is curious about the FreeBSD 9.0 DTrace userland problems I
experienced, see http://www.freebsd.org/cgi/query-pr.cgi?pr=165541
--
___
Python tracker rep...@bugs.python.org
http
Marc Abramowitz msabr...@gmail.com added the comment:
I get a build error on FreeBSD 9.0:
make: don't know how to make ./Include/phelper_offsets.h. Stop
Any ideas?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13405
Marc Abramowitz msabr...@gmail.com added the comment:
Re my comment in #154513, the following seems to fix that problem on FreeBSD
9.0:
[marca@freebsd9-0 ~/src/cpython-2011]$ hg diff Makefile.pre.in
diff -r 70dc1e48bd7f Makefile.pre.in
--- a/Makefile.pre.in Mon Feb 27 22:43:17 2012 +0100
Marc Abramowitz msabr...@gmail.com added the comment:
Hi Jesús,
Yes, I'm on an x86 machine. A MacBook Pro with OS X 10.6.8.
I'll try to hop on Google Talk during the week. I'm on the west coast of the
U.S. (GMT-8) so it might be tricky to find a mutually good time.
Here's the result
Marc Abramowitz msabr...@gmail.com added the comment:
All tests pass on OpenIndiana b151A (SunOS openindiana 5.11 oi_151a2 i86pc i386
i86pc Solaris).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13405
Marc Abramowitz msabr...@gmail.com added the comment:
With an hg checkout, I don't run into the `offsetof` problem - it fails when it
gets to calling dtrace to generate Python/dtrace.o (again -G is the culprit).
```
$ hg clone https://hg.jcea.es/cpython-2011/
$ cd cpython-2011
$ hg update
Marc Abramowitz msabr...@gmail.com added the comment:
My understanding of DTrace is extremely shallow, but I think there is a major
difference in how USDT probes are created between Solaris and OS X. Whereas on
Solaris one generates object code using the -G option of dtrace and then links
Marc Abramowitz msabr...@gmail.com added the comment:
I noticed that jcea already had some commented out stuff for OS X in his
configure.in.
I tried it out and stuff builds and works in a basic way, although it might not
be fully functional.
```
~/src/python-hg/cpython-2011$ hg diff
Marc-Andre Lemburg m...@egenix.com added the comment:
Gregory P. Smith wrote:
Gregory P. Smith g...@krypto.org added the comment:
Question: Should sys.flags.hash_randomization be True (1) when
PYTHONHASHSEED=0? It is now.
The flag should probably be removed - simply because
the env var
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@gmail.com added the comment:
Question: Should sys.flags.hash_randomization be True (1) when
PYTHONHASHSEED=0? It is now.
Saying yes working as intended is fine by me
Marc Abramowitz msabr...@gmail.com added the comment:
Jesús said he was focusing on Solaris and couldn't help with OS X. Not sure if
anyone else was going to try tackling that...
Just tried the patch `issue13405_4027.diff` on OS X 10.6.8.
First problem I ran into was:
gcc -fno-strict
Marc-Andre Lemburg m...@egenix.com added the comment:
Dave Malcolm wrote:
[new patch]
Please change how the env vars work as discussed earlier on this ticket.
Quick summary:
We only need one env var for the randomization logic: PYTHONHASHSEED.
If not set, 0 is used as seed. If set
New submission from marc dechico marc.dech...@gmail.com:
actions do discover the bug with the source I have given:
pushing the right button to get the pop-up menu .
going out of the popup_menu still pushing the right button.
the menu doesn't disapear when releasing the button.
and still
Marc-Andre Lemburg m...@egenix.com added the comment:
Dave Malcolm wrote:
If anyone is aware of an attack via numeric hashing that's actually
possible, please let me know (privately). I believe only specific apps
could be affected, and I'm not aware of any such specific apps.
I'm not sure
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
In a security fix release, we shouldn't change the linkage procedures,
so I recommend that the LoadLibrary dance remains.
So the overhead
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
The simple collision counting approach leaves a gaping hole open, as
demonstrated by Frank.
Could you elaborate on this ?
Note that I've updated the collision counting patch to cover both
possible attack cases I
Marc-Andre Lemburg m...@egenix.com added the comment:
Jim Jewett wrote:
Jim Jewett jimjjew...@gmail.com added the comment:
On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg
rep...@bugs.python.org wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote
Marc-Andre Lemburg m...@egenix.com added the comment:
Jim Jewett wrote:
BTW: If you set the limit N to e.g. 100 (which is reasonable given
Victor's and my tests),
Agreed. Frankly, I think 5 would be more than reasonable so long as
there is a fallback.
the time it takes to process one
Marc-Andre Lemburg m...@egenix.com added the comment:
Dave Malcolm wrote:
So the overhead in startup time is not an issue?
It is an issue. Not only in terms of startup time, but also
...
because randomization per default makes Python behave in
non-deterministc ways - which is not what
Marc-Andre Lemburg m...@egenix.com added the comment:
Marc-Andre Lemburg wrote:
Dave Malcolm wrote:
The release managers have pronounced:
http://mail.python.org/pipermail/python-dev/2012-January/115892.html
Quoting that email:
1. Simple hash randomization is the way to go. We think this has
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
Right, but that doesn't contradict what I wrote about adding
env vars to fix a seed and optionally enable using a random
seed, or adding collision counting
Marc-Andre Lemburg m...@egenix.com added the comment:
Gregory P. Smith wrote:
Gregory P. Smith g...@krypto.org added the comment:
The release managers have pronounced:
http://mail.python.org/pipermail/python-dev/2012-January/115892.html
Quoting that email:
1. Simple hash randomization
Marc-Andre Lemburg m...@egenix.com added the comment:
Alex Gaynor wrote:
Can't randomization just be applied to integers as well?
A simple seed xor'ed with the hash won't work, since the attacks
I posted will continue to work (just colliding on a different hash
value).
Using a more elaborate
Marc-Andre Lemburg m...@egenix.com added the comment:
Alex Gaynor wrote:
There's no need to cover any container types, because if their constituent
types are securely hashable then they will be as well. And of course if
the constituent types are unsecure then they're directly vulnerable.
I
Marc-Andre Lemburg m...@egenix.com added the comment:
Dave Malcolm wrote:
Dave Malcolm dmalc...@redhat.com added the comment:
On Fri, 2012-01-06 at 12:52 +, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
Demo patch implementing the collision limit
Marc-Andre Lemburg m...@egenix.com added the comment:
Alex Gaynor wrote:
I'm able to put N pieces of data into the database on successive requests,
but then *rendering* that data puts it in a dictionary, which renders that
page unviewable by anyone.
I think you're asking a bit much here
Marc-Andre Lemburg m...@egenix.com added the comment:
Here's a version of the collision counting patch that takes both hash
and slot collisions into account.
I've also added a test script which demonstrates both types of
collisions using integer objects (since it's trivial to calculate
Marc-Andre Lemburg m...@egenix.com added the comment:
I've also added a test script which demonstrates both types of
collisions using integer objects (since it's trivial to calculate
their hashes).
I forgot to mention: the test script is for 64-bit platforms. It's
easy to adapt it to 32-bit
Marc-Andre Lemburg m...@egenix.com added the comment:
To see the collision counting, enable the DEBUG_DICT_COLLISIONS
macro variable.
Running (part of (*)) the test suite with debugging enabled on a 64-bit
machine shows that slot collisions are much more frequent than
hash collisions, which
Marc-Andre Lemburg m...@egenix.com added the comment:
Charles-François Natali wrote:
Anyway, I still think that the hash randomization is the right way to
go, simply because it does solve the problem, whereas the collision
counting doesn't: Martin made a very good point on python-dev
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
...
So I expect something similar in applications: no change in the
applications, but a lot of hacks/tricks in tests.
Tests usually check output of an application given a certain
input. If those fail
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
Please note, that you'd have to extend the randomization to
all other Python data types as well in order to reach the same level
of security as the collision
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
I tried the collision counting with a low number of collisions:
... no false positives with a limit of 50 collisions ...
Thanks for running those tests. Looks like a limit lower than 1000
would already do just fine
Marc-Andre Lemburg m...@egenix.com added the comment:
[Reposting, since roundup removed part of the Python output]
M.-A. Lemburg wrote:
Note that the integer attack also applies to other number types
in Python:
-- (hash(3), hash(3.0), hash(3+0j)
(3, 3, 3)
See Tim's post I referenced
Marc-Andre Lemburg m...@egenix.com added the comment:
Frank Sievertsen wrote:
Frank Sievertsen pyt...@sievertsen.de added the comment:
The suffix only introduces a constant change in all hash values
output, so even if you don't know the suffix, you can still
generate data sets
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
Patch version 7:
- Make PyOS_URandom() private (renamed to _PyOS_URandom)
- os.urandom() releases the GIL for I/O operation for its implementation
reading /dev/urandom
- move _Py_unicode_hash_secret_t
Marc-Andre Lemburg m...@egenix.com added the comment:
Eric Snow wrote:
Eric Snow ericsnowcurren...@gmail.com added the comment:
The vulnerability is known since 2003 (Usenix 2003): read Denial of
Service via Algorithmic Complexity Attacks by Scott A. Crosby and Dan
S. Wallach.
Crosby
Marc-Andre Lemburg m...@egenix.com 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 completely just
Marc-Andre Lemburg m...@egenix.com 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 implemented
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
Mark Shannon wrote:
Mark Shannon m...@hotpy.org 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
be modified.
Really
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr 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 don't know about real
Marc-Andre Lemburg m...@egenix.com added the comment:
Mark Dickinson wrote:
Mark Dickinson dicki...@gmail.com 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.
[MAL
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr 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))
100 loops, best of 3
Marc-Andre Lemburg m...@egenix.com added the comment:
Marc-Andre Lemburg wrote:
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
Tim Peters wrote:
Tim Peters tim.pet...@gmail.com 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 worst-
case
Marc-Andre Lemburg m...@egenix.com 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 execute
Marc-Andre Lemburg m...@egenix.com 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.
I'm in cautious agreement
Marc-Andre Lemburg m...@egenix.com 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, in the sense
Marc-Andre Lemburg m...@egenix.com 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 rep...@bugs.python.org
http://bugs.python.org
Marc-Andre Lemburg m...@egenix.com 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 stdin, line 1, in module
KeyError: 'too many hash collisions
Marc-Andre Lemburg m...@egenix.com 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))) for x
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com 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 shifting tool
Marc-Andre Lemburg m...@egenix.com added the comment:
Terry J. Reedy wrote:
Terry J. Reedy tjre...@udel.edu 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
'value
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com 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 example for integers
Marc-Andre Lemburg m...@egenix.com 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**64 - 1))) for x in xrange(1, 100))
d
Marc-Andre Lemburg m...@egenix.com 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 servers to deal
Marc-Andre Lemburg m...@egenix.com added the comment:
Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc amaur...@gmail.com 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 time.
But that does
Marc-Andre Lemburg m...@egenix.com added the comment:
Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
But that does not give the *other* timezone :-(
Which other timezone ?
I meant the other timezone *name*.
I think we don't understand each other
Marc-Andre Lemburg m...@egenix.com 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 January
Marc Sibson sib...@gmail.com added the comment:
changes as per the review,
--
Added file: http://bugs.python.org/file23713/issue10772.patch3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10772
Marc-Andre Lemburg m...@egenix.com 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
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com 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
Marc-Andre Lemburg m...@egenix.com 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 pit...@free.fr added the comment:
Before going further with this, I'd suggest you have a look
Marc-Andre Lemburg m...@egenix.com 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 m...@egenix.com added the comment:
Antoine Pitrou wrote:
New submission from Antoine Pitrou pit...@free.fr:
This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.
Example micro-benchmark:
./python -m timeit -s a='x'*1;b='\u0102'*1000;c='\U0010
Marc-Andre Lemburg m...@egenix.com 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
Changes by Marc Sibson sib...@gmail.com:
--
nosy: +marcs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4256
___
___
Python-bugs-list mailing list
Changes by Marc Sibson sib...@gmail.com:
--
nosy: +marcs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11176
___
___
Python-bugs-list mailing list
Changes by Marc Sibson sib...@gmail.com:
--
nosy: +marcs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12933
___
___
Python-bugs-list mailing list
Marc-Andre Lemburg m...@egenix.com 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 about noncharacter code points
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
New submission from Ezio Melotti ezio.melo...@gmail.com:
From Chapter 03 of the Unicode Standard 6[0], D91:
• UTF-16 encoding form: The Unicode encoding form that assigns each Unicode
scalar value in the ranges U
Marc-Andre Lemburg m...@egenix.com added the comment:
Tennessee Leeuwenburg wrote:
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment:
Thanks for the review. Here is a patch incorporating the two comments being
to move some comments.
Hmm, the documentation patch doesn't
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC
is supported at build time.
I think we need both: a check at build time to avoid
compiler errors and a check at runtime whether
Marc-Andre Lemburg m...@egenix.com added the comment:
Georg Brandl wrote:
Also, we might think about removing this version number everywhere.
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12326
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
So what about doing the same for FreeBSD, SunOS, and Windows?
I agree that's definitely out of scope of this issue.
We could change the title of the ticket
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I'm not sure I understand why platform.release() isn't sufficient
for this purpose. Note that some systems return alphanumeric
values
Marc-Andre Lemburg m...@egenix.com added the comment:
Moved the discussion here from issue12326:
[Larry Hastings]
If we're changing linux2 / linux3 to just linux, we should be
consistent and do it for everybody. I propose sys.platform under 3.3
should contain things like linux, freebsd
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
We could change the title of the ticket :-)
No please, move the discussion to #12795 which has a well defined title. This
issue is closed. (#12795
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
What we could do is add a function that tries to find out the
true version number of the OS, e.g. for Windows 7 that would
be (6, 1, 7601) instead of the marketing name '7' returned by
platform.release().
Yes
Marc-Andre Lemburg m...@egenix.com added the comment:
Nick Coghlan wrote:
As a separate, but related point, IncrementalDecoder.getstate() includes an
explanation on how to save arbitrary state as an integer, but no such
explanation (not even a reference to the IncrementalDecoder version
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
FreeBSD or OpenBSD release major version frequently, something like one
per year, or one per two years. FreeBSD and OpenBSD developers knows
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
Well, it is important to somehow get the build information for
Python, since that tells us which OS features were available
at the time of compilation
Marc-Andre Lemburg m...@egenix.com added the comment:
[This discussion is really off-topic for this issue, it should either
be moved to issue12795 or a new ticket]
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
No, it doesn't (except for a bug that Matthias
Marc-Andre Lemburg m...@egenix.com added the comment:
Tennessee Leeuwenburg wrote:
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment:
Some more tests, updated initial state of BufferedIncrementalEncoder to be
the correct type, updated rst file. Bit tired, hope I got it right
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
sys.platform refers to build time information,
so the platform module won't help.
When I wrote my patch, I realized that sys.platform is used
Marc-Andre Lemburg m...@egenix.com added the comment:
Ezio Melotti wrote:
Ezio Melotti ezio.melo...@gmail.com added the comment:
The attached patch adds the following 4 public macros to unicodeobjects.h:
Py_UNICODE_IS_SURROGATE(ch)
Py_UNICODE_IS_HIGH_SURROGATE(ch
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
It is mostly to test FreeBSD major version, and it looks like Python is
build on the same FreeBSD major version that it is running on. Maybe
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
New submission from STINNER Victor victor.stin...@haypocalc.com:
#12326 proposes to remove the major version from sys.platform. If we remove
it, we will need another easy way to get this information. I don't
Marc-Andre Lemburg m...@egenix.com added the comment:
James Y Knight wrote:
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
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin von Gagern wrote:
Martin von Gagern martin.vgag...@gmx.net 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
1101 - 1200 of 2192 matches
Mail list logo
