Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Brian Curtin wrote:
>>
>> Brian Curtin added the comment:
>>
>> I'll look into whatever other trickery could be applied to 2.6/3.1.
>>
Marc-Andre Lemburg added the comment:
Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> Thanks for the patch.
>
> Rather than remove that optimization entirely, I'd consider pushing it into
> PyUnicode_Decode.
>
> All tests (whether for the
Marc-Andre Lemburg added the comment:
Ori Avtalion wrote:
>
> Ori Avtalion added the comment:
>
> Ignoring the custom utf-8/latin-8 conversion functions, the actual checking
> if a codec exists is done in Python/codecs.c's PyCodec_Decode.
>
> Is that where I shou
Marc-Andre Lemburg added the comment:
I think it's better to close the ticket as "won't fix".
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<htt
Marc-Andre Lemburg added the comment:
A.M. Kuchling wrote:
>
> A.M. Kuchling added the comment:
>
> I tried figuring out to rebuild the codecs using the scripts in
> Tools/unicode/ but failed. Is the use of that directory documented anywhere?
See the Makefile in that dir
Marc-Andre Lemburg added the comment:
platform.system() is a direct interface to platform.uname() which in return is
an interface to the platform's uname() API, so the reasoning is much the same
as for sys.platform on those platforms that do expose a uname() function (and
command).
O
Marc-Andre Lemburg added the comment:
Brian Curtin wrote:
>
> Brian Curtin added the comment:
>
> Here is the patch which checks whether the new info is available and uses it,
> otherwise it falls back to the original way.
Thanks. Could you apply the same logic to the sec
Marc-Andre Lemburg added the comment:
> --- python/trunk/Objects/unicodeobject.c (original)
> > +++ python/trunk/Objects/unicodeobject.cWed Feb 24 00:16:07 2010
> > @@ -8170,6 +8170,7 @@
> > size_t buflen,
> > PyObject *v)
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> Could you please check for chars above 0x7f first and then use
>> PyUnicode_Decode() instead of the PyUnicode_FromStringAndSize() API
>
>
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>>> But why is it necessary to check for chars above 0x7f?
>> The Python default encoding has to be ASCII compatible,
> Yes, but it is not
Marc-Andre Lemburg added the comment:
Looking at the code, the whole approach to finding the project base appears to
be very fragile.
I'd suggest to use a landmark file for finding the project base, say
"Modules/main.c", and a function which searches all directories on the
o
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
> Just to clarify:
> "u'%c' % some_int" should behave like unichr(some_int);
> "u'%c' % some_chr" should behave like "u'%s' % some_chr".
That's correct.
I guess
Marc-Andre Lemburg added the comment:
Have you checked how big the structural changes are between 5.2 and 5.1.
If we only have to rerun the makeunicodedata.py script, then I'd be +1 on going
with 5.2.
Otherwise, I think it's better to wait another release before upgrading to the
t
Marc-Andre Lemburg added the comment:
About the _PyUnicode_AsStringOrDefault() patch:
Since the _PyUnicode_AsString*() APIs are scheduled to be removed, it would be
better to not introduce yet another way to use them.
If that's not easily possible now, then please fix the indentation
Marc-Andre Lemburg added the comment:
Florent Xicluna wrote:
>
> Florent Xicluna added the comment:
>
> It is just a matter of running "makeunicodedata" affter changing "5.1" ->
> "5.2".
>
> It generates the 3 db files:
>
Marc-Andre Lemburg added the comment:
Florent Xicluna wrote:
>
> Florent Xicluna added the comment:
>
>> So the Unicode database format itself has not changed ?
>
> No. The changes listed below have no impact afai-have-tested.
Ok, so +1 for updating to 5.2.
The files
Marc-Andre Lemburg added the comment:
Florent Xicluna wrote:
>
> Florent Xicluna added the comment:
>
> Reverted in 3.x: it triggers some failures.
>
> Symptoms:
> * repr('\uaaa') gives an empty string
> * test_bigmem fails
repr() for Unicode doesn&#
Marc-Andre Lemburg added the comment:
Florent Xicluna wrote:
>
> Florent Xicluna added the comment:
>
> The bug was a side-effect of the update. Code point "\u" is now assigned
> to a printable character:
>
> ;TAI VIET LETTER LOW VO;Lo;0;L;N;;
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> Looking closer at the patch, you also changed the unicodetype mappings
>> and since this removes a lot of entries, it looks like the Unicode
Marc-Andre Lemburg added the comment:
Stefan Behnel wrote:
>
> Stefan Behnel added the comment:
>
>> Supporting unicode for lxml.etree compatibility is fine with me, but I
>> think it might make sense to support the string "unicode" as well (as
>> a pseud
Marc-Andre Lemburg added the comment:
Florent Xicluna wrote:
> Backward compatibility concern:
> * it adds VT u'\x0b' and FF u'\x0c' as line breaks.
>
> The choice is either to preserve backward compatibility, or to comply with
> the specification (UAX #1
Marc-Andre Lemburg added the comment:
R. David Murray wrote:
>
> R. David Murray added the comment:
>
> Patches applied to trunk in r79294, py3k in r79298. Should this be
> backported?
I don't think so: applications relying on the previous behavior
would need to be u
Marc-Andre Lemburg added the comment:
Florent Xicluna wrote:
>
> Florent Xicluna added the comment:
>
> This patch should fix it...
> "HFS Plus uses a variant of Normal Form D in which U+2000 through U+2FFF,
> U+F900 through U+FAFF, and U+2F800 through U+2FAFF are
Marc-Andre Lemburg added the comment:
Setting CFLAGS is broken in Python configure system, so it's better not to rely
on it (or to fix it, but that's a major task - the whole CFLAGS and LDFLAGS
system used in Python's configure has over the years turned into a complete
mess).
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> (or to fix it, but that's a major task - the whole CFLAGS
>> and LDFLAGS system used in Python's configure has over the
>> years turned into a comple
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> MaL> It unconditionally overrides CFLAGS - even if it is not
> MaL> set and defined by AC_PROG_CC as "-g -O2". That would need
> MaL> to be corrected.
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I commited my patch: r79392 (trunk). I'm waiting for the buildbots before
>> porting to other branches :-)
>
> The buildbots look happy => r79401 (py3
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> MaL> The patch you checked in still unconditionally overrides the
> MaL> CFLAGS setting applied by AC_PROG_CC in case no CFLAGS variable
> MaL> is set.
>
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> Buffering applies when writing, not when reading a file.
>
> There is indeed a problem in codecs.py: after a readline(), read() will
> return the
Marc-Andre Lemburg added the comment:
I guess the term "failing" byte somewhat underdefined.
Page 95 of the standard PDF
(http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf) suggests to "Replace
each maximal subpart of an ill-formed subsequence by a single U+FFFD"
Marc-Andre Lemburg added the comment:
Arnaud Fontaine wrote:
>
> Arnaud Fontaine added the comment:
>
> I meant whether it returns a new reference or not. For instance,
> documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states
> that a new reference is
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> The #define dates back from 2007, this changeset:
>
> branch: trunk
> user:guido
> date:Sat Aug 30 17:02:50 1997 +0200
> files: Inc
Marc-Andre Lemburg added the comment:
John Machin wrote:
>
> John Machin added the comment:
>
> @lemburg: "failing byte" seems rather obvious: first byte that you meet that
> is not valid in the current state. I don't understand your explanation,
> espec
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Here is an incomplete patch. It seems to solve the problem but I still have
> to add more tests and check it better.
Thanks. Please also check whether it's worthwhile unro
Marc-Andre Lemburg added the comment:
John Machin wrote:
>
> John Machin added the comment:
>
> Unicode has been frozen at 0x10. That's it. There is no such thing as a
> valid 5-byte or 6-byte UTF-8 string.
The UTF-8 codec was written at a time when UTF-8 still incl
Marc-Andre Lemburg added the comment:
John Machin wrote:
>
> John Machin added the comment:
>
> @lemburg: RFC 2279 was obsoleted by RFC 3629 over 6 years ago.
I know.
> The standard now says 21 bits is it.
It says that the current Unicode codespace only uses 21 bits. In
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Even if they are not valid they still "eat" all the 4/5/6 bytes, so they
> should be fixed too. I haven't see anything about these bytes in chapter 3 so
>
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
> Here's a new patch. Should be complete but I want to test it some more before
> committing.
> I decided to follow RFC 3629, putting 0 instead of 5/6 for bytes in range
Marc-Andre Lemburg added the comment:
Updating the ticket title to what we actually have in SVN (I had renamed the
APIs to mark them as private to the interpreter some time ago).
--
title: Remove PyUnicode_AsString(), rework PyUnicode_AsStringAndSize(), add
PyUnicode_AsChar
Marc-Andre Lemburg added the comment:
A.M. Kuchling wrote:
>
> New submission from A.M. Kuchling :
>
> While looking at #4440, I grepped for similar problems and found one in
> platform.py in the following line:
>
> if no_os_uname or not filter(None, (system, node, rele
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I also found out that, according to RFC 3629, surrogates
>> are considered invalid and they can't be encoded/decoded,
>> but the UTF-8 codec actually
Marc-Andre Lemburg added the comment:
Victor, could you please fix the patch or revert it ?
Thanks.
--
___
Python tracker
<http://bugs.python.org/issue8
Marc-Andre Lemburg added the comment:
Reopening the ticket: it shouldn't have been closed.
I'm also making this a release blocker, since this needs to be fixed before the
next release - the CC variable has to be initialized by the build system and
breaking this in general for a
Changes by Marc-Andre Lemburg :
--
resolution: fixed ->
___
Python tracker
<http://bugs.python.org/issue8211>
___
___
Python-bugs-list mailing list
Unsubscri
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> getdefaultlocale is inherently unmaintainable, and shouldn't be used by
> applications. I wish it was removed from Python (but unfortunately, too many
> people got
Marc-Andre Lemburg added the comment:
M.-A. Lemburg wrote:
>> That said, if anybody feels like updating the tables from the various data
>> sources, please go ahead.
>
> I last updated the table in 2008. Will do that again this week.
I saw that Antoine already did t
Marc-Andre Lemburg added the comment:
Both pickle and marshal will need to use the new error handler in order to stay
compatible with Python 3.0 (and 2.x) and also to enable creating Unicode
literals that include lone surrogates.
--
___
Python
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Both pickle and marshal will need to use the new error handler
>> in order to stay compatible with Python 3.0 (and 2.x)
>> and also to enable creating Un
Marc-Andre Lemburg added the comment:
I think it would be best to backport the handler (even though it is not needed
in Python 2.7), since it makes porting apps to 3.x easier.
--
nosy: +lemburg
___
Python tracker
<http://bugs.python.org/issue8
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> -1 on backporting. The handler isn't really meant to be used in applications,
> plus 2.7 is in feature-freeze.
Since 2.7 is meant to be the last release of the 2.
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I think it would be best to backport the handler (even though
>> it is not needed in Python 2.7), since it makes porting apps
>> to 3.x easier.
>
> s
Marc-Andre Lemburg added the comment:
Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>> I consider this an important missing backport for 2.7, since
>> without this handler, the UTF-8 codecs in 2.7 and 3.x are
>> incompatible and there's no other
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> Or perhaps the bytearray can be converted to a bytes object. This is not
> optimal performance-wise but is unlikely to make a difference in real-world
> code (if you are
Marc-Andre Lemburg added the comment:
Brian Curtin wrote:
>
> Brian Curtin added the comment:
>
> Any thoughts on this last bit about using the registry to identify between
> workstation and server?
I can't comment on that since I don't know anything much
abou
Marc-Andre Lemburg added the comment:
> STINNER Victor added the comment:
>
> Even if this issue doesn't fix all the configure "complete mess", I think
> that it improves it a little bit. Open new issues if you would like to fix
> other parts of the configure
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Please change the configure.in script to only override the CFLAGS in case
> they were set before entering the AC_PROG_CC part !
Sorry, this should have read:
...
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> Python3 uses unicode filenames in Windows and bytes filenames (but support
> also unicode filenames) on other OS. We have to support both types. On POSIX
> system, byte
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Oh! In Python3, ntpath.expanduser() supports bytes path and uses
> sys.getfilesystemencoding() to encode an unicode environment variable to a
> byte string.
>
>
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Please follow the naming convention used in os.path. The functions
>> would have to be called os.path.fsencode() and os.path.fsdecode().
>
> Ok
>
>>
Marc-Andre Lemburg added the comment:
Matthias Klose wrote:
>
> New submission from Matthias Klose :
>
> Building with -flto (GCC 4.5.0) requires passing the very same optimization
> flags to the linker (lto1) as well. The attached patch just does this.
> Tested on Linux
Marc-Andre Lemburg added the comment:
Matthias Klose wrote:
>
> Matthias Klose added the comment:
>
>> It's probably better to just pass OPT to the linker instead.
>
> not enough, because -fno-strict-aliasing might be passed in BASE_CFLAGS.
Shouldn't -fno-
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Le lundi 26 avril 2010 13:06:48, vous avez écrit :
>> I don't see what environment variables have to do with the file
>> system.
>
> A POSIX system o
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Le vendredi 30 avril 2010 15:58:28, vous avez écrit :
>> It's better to let the application decide how to solve this problem
>> and in order to allow fo
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Sorry but i don't really understand the problem of my patch, and I don't want
> to spend time of this. Revert my patch if you think that it introduced a
&
Changes by Marc-Andre Lemburg :
--
assignee: -> lemburg
priority: release blocker -> normal
resolution: -> fixed
status: open -> closed
title: configure: ignore AC_PROG_CC hardcoded CFLAGS -> configure: allow
user-provided CFLAGS to override AC_P
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> No, you store the environment data as bytes and only
>> decode in getenv() ...
>
> Yes, this is the best solution for POSIX. We need maybe also a
> os.ge
Marc-Andre Lemburg added the comment:
I agree with Martin regarding the os.environ changes. Victor, please
open a new ticket for this.
Martin: As you probably know, these issues are managed as micro-
mailing lists. Discussions on these lists often result in new
aspects which then drift off to
Marc-Andre Lemburg added the comment:
A view comments on the patch:
+def __init__(self, data, encodekey, decodekey, encodevalue, decodevalue,
putenv, unsetenv):
As general guideline: When adding new parameter, please add them to the
end of the parameter list and preferably with a default
Marc-Andre Lemburg added the comment:
Matthias Klose wrote:
>
> Matthias Klose added the comment:
>
> my understanding is that the builder is allowed to overwrite OPT, but not
> BASECFLAGS.
The builder should actually be allowed to override the complete
CFLAGS and LDFLAGS se
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> Can somebody please explain what problem is being solved with this patch?
The way os.environ is currently set up on Unix breaks applications
using the environment to pass da
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> Please see the discussion on http://bugs.python.org/issue8514
>> for details.
>
> I can't see any report of actual breakage in that report, only claims
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> Set your CODESET to ASCII and watch the surrogate escaping
>> begin... seriously, Martin, if you've ever worked with CGI
>> or WSGI or FastCGI or SCGI or
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> Here's one (RFC 3875, sections 4.1.7 and 4.1.5):
>>
>> LANG = 'en_US.utf8'
>> CONTENT_TYPE = 'application/x-www-form-urlencoded'
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
>> Your name will end up being partially escaped as surrogate:
>>
>> 'L\udcf6wis'
>>
>> Further processing will fail
>
> That depen
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> I don't think it's a good idea to display an fatal error at runtime. If
> nl_langinfo(CODESET) is not available, configure should fail or we should
> fallback to an hardcoded encoding (ok but which one?).
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> The documentation of os.environb and os.getenvb() in my last patch is very
> short. I'm not inspired.
>
> We told me on IRC to not use function annotations because annotation semantic
> was not decided
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> manpage for nl_langinfo() doesn't mention any errors that could
>> be raised by it
>
> It's more about get_codeset(). This function can fail for d
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> I think that using ASCII is a safer choice in case of errors.
>
> I choosed UTF-8 to keep backward compatibility:
> PyUnicode_DecodeFSDefaul
Marc-Andre Lemburg added the comment:
Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> Since r80665, a
>
> ./configure --with-pydebug
>
> seems to give compilation with -O2 (tested on OS X and Linux). Is this
> intentional?
Yes. I've r
Changes by Marc-Andre Lemburg :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8211>
___
___
Python-bugs-list mailing list
Unsubscri
Marc-Andre Lemburg added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Mark Dickinson wrote:
>>
>> Mark Dickinson added the comment:
>>
>> Since r80665, a
>>
>> ./configure --with-pydebug
>>
>
Marc-Andre Lemburg added the comment:
Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> Ah, I understand now: -O2 started appearing in debug builds in r79218, which
> changed the Makefile to respect CFLAGS. I tested a variety of revision, but
> failed t
New submission from Marc-Andre Lemburg :
As discussed on issue8610, we need a way to override the automatic detection of
the file system encoding - for much the same reasons we also do for the I/O
encoding: the detection mechanism isn't fail-safe.
We should add a new environment variable
Marc-Andre Lemburg added the comment:
I've opened issue8622 for the env. var idea.
--
___
Python tracker
<http://bugs.python.org/issue8610>
___
___
Pytho
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> It would be nice to restore the original behaviour, if possible, since
>> the optimization causes difficulties when debugging. One solution
>> would be to add &#
Marc-Andre Lemburg added the comment:
Brian Curtin wrote:
>
> Brian Curtin added the comment:
>
> Now that I have access to a Server 2008 R2 machine, I've verified that this
> fix works there.
>
> Committed in r80857 thro
Marc-Andre Lemburg added the comment:
We can add those to 3.2. Not sure about 2.7 - it's already in feature freeze.
--
versions: +Python 2.7, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
Benjamin: Would the added parameter be a new feature or not ?
It looks like an oversight when adding the parameter to the standard codec
classes, so could be viewed as a bug.
--
assignee: -> benjamin.peterson
nosy: +benjamin.peter
Marc-Andre Lemburg added the comment:
André: Could you provide a patch ?
Thanks.
--
assignee: benjamin.peterson ->
___
Python tracker
<http://bugs.python.org/iss
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> "I think that using ASCII is a safer choice in case of errors. (...) Ouch,
> that was a poor choice."
>
> Ok, you conviced me with your PYTHONFSENCOD
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
>> +codec = _PyCodec_Lookup(Py_FileSystemDefaultEncoding);
>> +if (!codec) {
>> +Py_FatalError(
>> +"Py_Initialize: unable to load the file system codec"
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> New submission from Daniel Stutzbach :
>
> Currently, Python can be built with an internal Unicode representation of
> UCS2 or UCS4. To prevent extension modules compiled with the wrong Unicode
> represent
Marc-Andre Lemburg added the comment:
Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> I propose a different approach:
>
> 1. add a flag to PyModuleDef, indicating whether the module was built in
> UCS-2 or UCS-4 mode. Then let the interpreter refus
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
> On Sat, May 8, 2010 at 5:03 AM, Marc-Andre Lemburg
> wrote:
>> If you can propose a different method of reliably protecting against
>> mixed Unicode build
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
> On Sat, May 8, 2010 at 10:16 AM, Marc-Andre Lemburg
> wrote:
>> Are you sure this doesn't get optimized away in practice ?
>
> I'm sure it doesn&#
Marc-Andre Lemburg added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach added the comment:
>
> On Sat, May 8, 2010 at 11:35 AM, Marc-Andre Lemburg
> wrote:
>> One of the more important cases you are missing is the
>> argument parser in Python:
>
Marc-Andre Lemburg added the comment:
Interesting. It appears as if r57142 caused this change.
Before:
# if !(defined(__BEOS__) || defined(__CYGWIN__) || (defined(PYOS_OS2) &&
defined(PYCC_VACPP)))
After:
# if defined(__CYGWIN__) || (defined(PYOS_OS2) && defined(PYCC_VACP
Marc-Andre Lemburg added the comment:
Doesn't this bug report also refer to Python 2.5 and 2.6 ?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1514>
__
___
Marc-Andre Lemburg added the comment:
While the patch looks right (can't say for sure whether netinet/tcp.h is
always available), I think the approach itself of adding these constants
to the socket module is wrong.
Instead of adding these constants to the socket module, they should go
i
Marc-Andre Lemburg added the comment:
If you think we need a better tool, that's a different story, but not an
argument for cluttering up the socket module with a more or less
complete list of C constants.
It's much easier to maintain this outside the socket module in a
separate
501 - 600 of 1946 matches
Mail list logo
