Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-06-13 16:20, Benjamin Peterson wrote:
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Ok. I ran it through reindent.py and removed the True and False.
Thanks, but the all() is still there :-)
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-06-13 16:59, Benjamin Peterson wrote:
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Wow, I really admire you for keeping it compatible with Python 1.5. As
> you may have noticed, I&#
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
It's actually very easy:
Py_UNICODE is a 2-byte value for UCS-2 builds and 4 byte value for UCS-4
builds of Python.
print ((sys.maxunicode < 66000) and 'UCS2' or 'UCS4')
tells you which one you have.
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
BTW: Here's another trick you can use:
print 'sizeof(Py_UNICODE) =', len(u'\0'.encode('unicode-internal'))
(for Py2.x)
___
Python tracker <[EMAIL P
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-06-13 21:56, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Hmm, so it seems that in some UCS4 builds, sizeof(Py_UNICODE) could end
> up being more than 4 if the native i
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-06-13 22:32, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le vendredi 13 juin 2008 à 20:18 +0000, Marc-Andre Lemburg a écrit :
>> AFAIK, only Crays have this proble
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-06-13 21:54, Marc-Andre Lemburg wrote:
> BTW: Here's another trick you can use:
>
> print 'sizeof(Py_UNICODE) =', len(u'\0'.encode('unicode-internal'))
>
> (for Py2
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-06-28 21:33, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
>> You're right: probably not. Would be great to have the test on the
>> Py2.x version as well - t
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
There's nothing new to .encode() and .decode(). They have existed since
Python 1.6.
--
nosy: +lemburg
resolution: -> wont fix
status: open -> closed
___
Python tracker
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Please see the top of platform.py:
#This module is maintained by Marc-Andre Lemburg <[EMAIL PROTECTED]>.
#If you find problems, please submit bug reports/patches via the
#Python SourceForge Project Page and as
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Also note that linux_distribution() will use the parsed distro name from
the release file per default (full_distribution_name=1), so the problem
described in the original ticket description should no longer be
relevant: all release
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Just to clarify: Python can be built as UCS2 or UCS4 build (not UTF-16
vs. UTF-32).
The conversions done from the literal escaped representation to the
internal format are done using the unicode-escape and raw-unicode-escape
codecs
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Adam, I do know what I'm talking about: I was the lead designer of the
Unicode integration you find in Python and implemented most of it.
What you see as repr() of a Unicode object is the result of applying a
codec to t
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Could you please check whether this is still the case with the current
version of platform.py we have in SVN ?
http://svn.python.org/view/python/trunk/Lib/platform.py?rev=64233&view=markup
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
The patch looks good to me.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2620>
___
_
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
The comment gives a wrong impression: The problem is not (only) that a
codec might by evil, it's the fact that a codec may well execute Python
code and thus allow the list to be changed by other threads during the
operation.
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Two comments:
* I like the new *-getarg parameters, but it would be better to test
for '#' first since this is still by far the most used getarg
parameter.
* Antoine, I think your codecs.c patch has a glitc
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-08-02 16:49, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> You've missed the preceding line that says:
>
> +consumed = pbuf.len;
>
> If final is NU
New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:
Here's the "make -d" output:
Prerequisite `Parser/Python.asdl' is older than target
`Include/Python-ast.h'.
Prerequisite `Parser/asdl.py' is older than target
`Include/Python-a
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
As work-around, you can untar the source tarball and then touch the
files in question:
touch Include/Python-ast.h
touch Python/Python-ast.c
___
Python tracker <[EMAIL PROTECTE
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-08-07 23:17, Bill Janssen wrote:
> Bill Janssen <[EMAIL PROTECTED]> added the comment:
>
> My main fear with this patch is that "unquote" will become seen as
> unreliable, because naive
Changes by Marc-Andre Lemburg <[EMAIL PROTECTED]>:
--
nosy: -lemburg
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3300>
___
__
New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:
Since we are shipping the msvcr90.dll (+ assemblies) together with the
Python installer for Windows, we need to include the MS EULA for VS2008
in the third-party licenses section as this is the license that covers
the V
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Note that there are a few gotchas in the MS EULA, such as disallowing to
ship the DLLs with GPLed Python products or requiring that the PSF
prevents further redistribution of the DLLs unless used in conjunction
with
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Mark Hammond wrote:
> Mark Hammond <[EMAIL PROTECTED]> added the comment:
>
> Obviously IANAL, but my reading of eula.txt included with VS9 seems less
> restrictive than the 2003 one. It has 2 clauses that se
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Attaching the VS7.1 EULA. This is only relevant for Python 2.5... should
we do another patch level release.
--
versions: +Python 2.5
Added file: http://bugs.python.org/file11188/eu
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Mark Hammond wrote:
> MAL:
>> Note that I'm not suggesting to dive into all this. We
>> should simply put the EULA into the installer package
>> and be done with it :-)
>
> I can't ar
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Adding the EULA should be easy... the MSI installer code already adds
the other licenses for OpenSSL, etc. to the license text in
Tools/msi/msi.py (took me a while to find that file, since I would have
expected this to live under P
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I think what you're after is the encoding used in SMS messages:
http://en.wikipedia.org/wiki/Short_message_service
Here's an old discussion about this codec:
http://mail.python.org/pipermail/python-list/2002-October/
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Is this still an issue in 2.6 ?
AFAIK, there have been a few changes both to setuptools and PyPI that
make it easy to just use Unicode objects in the setup() call for
non-ASCII values.
___
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-08-23 10:08, Hye-Shik Chang wrote:
> Hye-Shik Chang <[EMAIL PROTECTED]> added the comment:
>
> Committed patch "cjkmactemporary.diff" as r65988 in the py3k branch.
> I'll open another is
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Here's an updated patch that applies the same logic to all meta-data
fields, instead of just a few. This simplifies the code somewhat.
I've tested it with the test you provided and also with eGenix packages
using Unicode
New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:
The PKG-INFO file currently only provides an "Authors" field which is
mapped to the DistributionMetadata.get_contact() information.
However, the latter method is really meant to provide access to contact
information an
New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:
d:\Python26\lib\msilib\__init__.py:5: DeprecationWarning: the sets
module is deprecated
import sets, os, string, re
Should be easy to solve.
--
components: Distutils, Library (Lib)
keywords: easy
messages: 7216
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Is adding the double-quotes enough to solve the problem ?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I think it's better to disable that function in the same way as done for
_syscmd_uname:
if sys.platform in ('dos','win32','win16','os2'):
# XXX Others too ?
return d
Changes by Marc-Andre Lemburg <[EMAIL PROTECTED]>:
--
assignee: -> lemburg
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3748>
___
__
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Looks good. Could you apply it to both trunk and the py3k branch ?!
Mark it "Reviewed by Marc-Andre Lemburg" to keep folks happy ;-)
___
Python tracker <[EMAIL PROTECTED]>
&
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-08-29 23:33, Terry J. Reedy wrote:
> Terry J. Reedy <[EMAIL PROTECTED]> added the comment:
>
> "Just to clarify: Python can be built as UCS2 or UCS4 build (not UTF-16
> vs. UTF-32)"
>
&g
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Using subprocess is only possible conditionally, ie. if available.
Please note that the module is intended to be usable with multiple
Python versions and must at least support Python 2.1.
We could consider an updated patch for 2
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Updated the Python versions.
--
versions: +Python 2.5, Python 2.6, Python 3.0 -Python 2.4
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-09-02 12:55, Hirokazu Yamamoto wrote:
> Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:
>
> Well, if python was installed into directory named
> "foo ELF boo", python will say wrong arc
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Checked in as r66145 and r66146.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Raising priority since this needs to be resolved prior to the final
release of Python 2.6/3.0.
Regarding finding the eula.txt in the VS2008 installation, there doesn't
appear to be a generic way. The eula.txt is stored in a f
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Removing Python 2.5 from the version list, since the patch may in some
cases (e.g. using a different encoding than UTF-8) cause problems with
existing setup.py files out there.
The patch is not compatible with Python 3.0 for o
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Checked in as r66181 on trunk.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-09-08 23:45, Benjamin Peterson wrote:
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Does this need to be merged into py3k? If so, can someone who handled
> this bug do it. I met a few tes
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-09-09 17:54, Martin v. Löwis wrote:
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> I don't think this needs to be resolved before 2.6, not without a
> pronouncement from a lawyer advisi
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-09-09 23:09, Martin v. Löwis wrote:
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
>> Rather than arguing about the necessity of including the license
>> of a 3rd party file that we inte
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Here's a patch that adds the MS EULA to the MSI installer.
I couldn't test this, since I don't have a Python build environment on
Windows, but it should be more or less working.
--
keywords: +p
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-09-10 00:15, Martin v. Löwis wrote:
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
>> We've had the same issue with the OpenSSL license and the other
>> 3rd party packages which com
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Reviewed the patch: looks fine to me.
One nit: the unicodedata module doc-string must be updated to 5.1.0 as
well. Ditto for the documentation.
--
nosy: +lemburg
___
Python tracker &
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Thank you, Van, for this comprehensive analysis.
By including your text we'll also bypass the issues with finding the
EULA file in the Visual Studio installation.
The text should be easy to add as extra file and we can the
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
As explained in #1322. platform.dist() has been superseded by
platform.linux_distribution().
Please check what platform.linux_distribution() returns on your platform
using Python 2.6rc2.
I'm closing this ticket since it&#x
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Zooko, I think the main reason for the parser in platform.py to fail on
Ubuntu is that Ubuntu doesn't ship with a /etc/ubuntu-release file and
instead uses the optional override parameters in /etc/lsb-release to
setup the d
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-09-23 21:49, Zooko O'Whielacronx wrote:
> Zooko O'Whielacronx <[EMAIL PROTECTED]> added the comment:
>
> MAL: why do you say it is better to look for
> /etc/$supportedplatform-release files f
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-09-23 22:19, Zooko O'Whielacronx wrote:
> Zooko O'Whielacronx <[EMAIL PROTECTED]> added the comment:
>
>> Because that's exactly what lsb_release does as well.
I have to correct that:
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Does this also affect sys.byteorder and the struct module ?
I think those would be more important to get right than the UTF-16
codec, since this only uses the native byte ordering for increased
performance and compatibility with ot
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
BTW: Does this simplified approach really work for Python on Mac OS X:
On 2008-10-07 00:27, Trent Mick wrote:
>> The block below does compile-time checking for endianness on
> platforms
>> that use GCC
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-10-07 00:52, Trent Mick wrote:
> Trent Mick <[EMAIL PROTECTED]> added the comment:
>
>> BTW: Does this simplified approach really work for Python on Mac OS X
>
> It works for Python 2.5:
>
>
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-10-07 14:33, Ronald Oussoren wrote:
> Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
>
> Annoyingly enough my patch isn't good enough, it turns out that ctypes
> has introduced a SIZEOF__BO
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I'm not sure whether pybench is the right tool for this.
Note that pybench disables GC per default for exactly the reasons
causing #4074 :-)
pybench already has a --with-gc switch, so it's possible to benchmark
with o
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I'll follow up on this next week.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Marc-Andre Lemburg added the comment:
buffer() is only deprecated in Python 3.x, not in Python 2.7, so the current
implementation is perfectly valid for Python 2.7.
Note that buffer() has long been the preferred type for passing binary objects
to and from a database.
--
nosy
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> This is not exact. buffer() doesn't exist at all in 3.x, and it issues a
> warning in 2.x when used with the -3 flag:
>
> $ ./python -3
> Python 2.7a2+ (trunk:
Marc-Andre Lemburg added the comment:
Here's another reference I found:
http://developer.apple.com/legacy/mac/library/documentation/mac/Text/Text-30.html
It appears that the "macintosh" encoding is the same as the MacRoman one, but
without the character D9-FF. The document als
Marc-Andre Lemburg added the comment:
A few things:
* The ceval_gil.h file is missing from the patch.
* Please check whether you can move these variable declarations inside the
main loop function (as statics):
+/* This single variable consolidates all requests to break out of the fast
Marc-Andre Lemburg added the comment:
See Tools/pybench/systimes.py for more comments on clocks, ticks and update
frequency.
--
___
Python tracker
<http://bugs.python.org/issue7
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> * Instead of deprecating the set/getcheckinterval APIs, convert the
>> arguments passed to these to the switch interval. The new APIs
>> set/getswitchinteral are
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> While the semantics are different, the result is similar and
>> the actual numbers used are usually determined by experiment
>> or rough estimate - noone expe
Marc-Andre Lemburg added the comment:
On second thought, you're right: while sys.setcheckinterval() could
be made to work with the switching interval, sys.getcheckinterval()
could not be made to return anything useful.
Still, please have a look at the other issues mentioned. They
apply t
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>> Perhaps I'm missing some feature of the new GIL. Is there some
>> documentation for it somewhere ?
>
> Almost nothing besides what is found in ceval_gil.h and in the following
> thread:
> http://mail.py
Marc-Andre Lemburg added the comment:
Richard Hansen wrote:
>
> Richard Hansen added the comment:
>
> Any comments on the patches? I'd love to see at least patches 1-3 make it
> into Python 2.7. :)
Sorry, I haven't had a chance to review
Marc-Andre Lemburg added the comment:
Could you provide a dump of the (whole) release file ?
It's a bit strange to have an empty release file.
Thanks.
--
___
Python tracker
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
Arfrever Frehtes Taifersar Arahesis wrote:
>
> Arfrever Frehtes Taifersar Arahesis added the
> comment:
>
> My release file actually is correct (non-empty).
Could you post it on the ticket, so that I can check what's
causing th
Marc-Andre Lemburg added the comment:
Eric Smith wrote:
>
> Eric Smith added the comment:
>
> The more I think about this, the more concerned I am about changing the
> number of elements in the tuple. That's the change that broke platform.py.
> Maybe we shoul
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
> I feel uneasy to change the default unicode-escape encoding.
> I think that we mix two features here; to transfer a unicode string between
> two points, programs must agree on where the data ends, and how cha
Marc-Andre Lemburg added the comment:
Eric Smith wrote:
>
> Eric Smith added the comment:
>
> Great idea, Marc-Andre. I agree that's the better approach.
>
> It looks like PyStructSequence supports this, by setting n_in_sequence to a
> value
Marc-Andre Lemburg added the comment:
Please also add a NEWS entry which mentions the changes to those APIs and the
change in the email package.
Thanks.
--
___
Python tracker
<http://bugs.python.org/issue4
Marc-Andre Lemburg added the comment:
Ross Cohen wrote:
>
> Ross Cohen added the comment:
>
> On Fri, 22 Jan 2010 09:32:36 +
> Marc-Andre Lemburg wrote:
>
>> * Please add the fallback solutions from the time module in case
>> gettimeofday() is not ava
Marc-Andre Lemburg added the comment:
Ross Cohen wrote:
>> By the way, the new GIL only works with POSIX and Windows NT threading APIs.
>> Perhaps it can't be backported at all to 2.x, given that 2.x supports more
>> threading APIs than py3k does?
>
> Looking a
Marc-Andre Lemburg added the comment:
Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> Marc-Andre,
>
> on 64-bit Ubuntu, this method ...
>
> BASECFLAGS=-m32 LDFLAGS=-m32 ./configure
>
> ... results in a gcc segfault:
>
>
> gcc -pthread
Marc-Andre Lemburg added the comment:
Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> The builds are almost identical, so I attach a diff of the build output.
> For both builds, I used a fresh Python-3.1.1 directory. This looks
> suspicious:
>
> -checki
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> Le mercredi 27 janvier 2010 à 10:37 +, Marc-Andre Lemburg a écrit :
>>
>> I find it rather strange that Python 3.x now only supports
>> NT and POSIX t
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> The arguments given in that thread sound a bit strange to me:
>> just because there were no changes to a few files, doesn't really
>> say anything about whet
Marc-Andre Lemburg added the comment:
Closing the issue since we can't backport to Python 2.7 due to the missing
thread library support.
The patch may still be useful for experiments by users, though, so thanks to
Ross and Neil for creating it.
--
resolution: -> rejecte
Marc-Andre Lemburg added the comment:
Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> (1) I can get around the configure problem by patching configure.in,
> meaning that va_list is detected correctly now. Perhaps BASECFLAGS
> should be used by default for
Changes by Marc-Andre Lemburg :
--
assignee: -> pitrou
___
Python tracker
<http://bugs.python.org/issue1628484>
___
___
Python-bugs-list mailing list
Unsubscri
Marc-Andre Lemburg added the comment:
I'm with Antoine on this one.
Also, instead of removing the flag completely which will cause problems with
extensions relying on it, I'd suggest to just disable the PyErr_WarnPy3k(msg,
stacklevel) macro and turn it into a no-op if a compile tim
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
>> where available and only use gettimeofday() as fallback solution
>> together with times(), ftime(
Marc-Andre Lemburg added the comment:
Ross Cohen wrote:
>
> Ross Cohen added the comment:
>
> I am confused by this line of reasoning. Is it ok to ignore the
> deprecation process in py3k but not in 2.x? Is it only ok if a core
> developer does it?
It's normal
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> I find that the null termination for 8-bit strings makes low-level
>> parsing operations (e.g., parsing a numeric string) safer and easier:
>
> Not to mention
Marc-Andre Lemburg added the comment:
Amaury Forgeot d'Arc wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
>> Base type Unicode buffers end with a null-Py_UNICODE termination,
>> but this is not used anywhere, AFAIK
> On Windows, code like
>Cre
Marc-Andre Lemburg added the comment:
modules to py3k.
> This is not an implementation detail.
It is, otherwise I would have documented it. The fact that some
developers are not using those APIs correctly doesn't change that.
Note that PyUnicode_AsUnicode() only returns a pointe
Marc-Andre Lemburg added the comment:
Barry A. Warsaw wrote:
>
> New submission from Barry A. Warsaw :
>
> Python 2.x supports a -U flag which has the effect largely the same as 'from
> __future__ import unicode_literals'. However -U is undocumented anywhere
>
Marc-Andre Lemburg added the comment:
The patch looks ok. Since we are emulating the Unix uname() function here, we
might as well mimic its inconsistencies.
Note that platform.machine() and platform.processor() are not really very
reliable ways of determining the machine type or processor
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> The test could simply check that platform.machine() never returns "x86" when
> sys.maxsize is greater than 2**32.
> (and it would even be platform-agnostic)
I
Marc-Andre Lemburg added the comment:
lplatypus wrote:
>
> lplatypus added the comment:
>
> Okay thanks, but in that case might I suggest that this limitation be
> mentioned in the documentation for sys.setdefaultencoding? It currently
> reads as if any available enco
Marc-Andre Lemburg added the comment:
Brian Curtin wrote:
>
> Brian Curtin added the comment:
>
> Here's a patch which fixes this on trunk.
>
> 2.6/3.1 is a different story as there doesn't appear to be a way to get the
> platform type to differentiate wo
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.
>
> The patch against trunk works correctly for Win7, Win 2003 Server SP1, Win XP
> SP
401 - 500 of 1946 matches
Mail list logo
