Marc-Andre Lemburg added the comment:
The change we did was for == and != comparisons to always work (they now
"raise" warnings) - mostly because doing otherwise resulted in strange
exceptions when dealing with dictionary lookups.
However, this was not done for comparisons <, &l
Marc-Andre Lemburg added the comment:
Some background information: http://www.cns11643.gov.tw/eng/word.jsp
The most recent version appears to be: "CNS11643-2004", sometimes also
called "CNS11643 version 3" or "CNS11643-3"
(http://docs.hp.com/en/5991-7974/5991-79
Marc-Andre Lemburg added the comment:
How often would this character set be needed ?
In any case, using a (pre)compiler switch is not a good idea. Please add
support to enable/disable the support via a configure switch.
--
nosy: +lemburg
__
Tracker
Marc-Andre Lemburg added the comment:
I think Martin was looking for other optimizations that still leave the
data in a static C const (in order to be shared between processes and
only loaded on demand), but do compress the data representation, e.g.
using some form of Huffman coding.
While I
Marc-Andre Lemburg added the comment:
In that case, I'm +1 on adding it.
The OS won't load those tables unless really needed, so it's more a
question of disk space than anything else.
__
Tracker <[EMAIL PROTECTED]>
<http://b
Marc-Andre Lemburg added the comment:
Could explain what exactly is wrong with the end-of-line on Windows ?
Note that "Unicode text files" on Windows are generally interpreted as
UTF-16 encoded files. Perhaps that's what makes you think there's a bug.
-
Marc-Andre Lemburg added the comment:
I agree that it's a bit unfortunate that the 8-bit string APIs in Python
use the locale aware C functions per default (this should really be
reversed: there should be locale-aware .upper() and .lower() methods and
the the standard ones should work just
Marc-Andre Lemburg added the comment:
As Antoine already pointed out: the codecs.open() function does not
support the C lib's text mode. As a result, no magical conversion of a
single newline to a CRLF takes place.
Closing as invalid.
--
resolution: -> invalid
status: open -
Marc-Andre Lemburg added the comment:
Whether or not to keep placing all builtin modules into the Windows
Python DLL is not really a question to be discussed on the tracker.
Given the size of the Python DLL (around 2MB) and the extra 350kB that
the support for CNS11643 would cost, I think such a
Marc-Andre Lemburg added the comment:
Thanks, Georg.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2131>
__
___
Python-bugs-list mailing list
Unsubs
Marc-Andre Lemburg added the comment:
I think it's better to add the new name rather than replace the existing
one.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Marc-Andre Lemburg added the comment:
Fixed in r61304.
Backport candidate.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2255>
__
___
Python-bugs-list
Changes by Marc-Andre Lemburg:
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2255>
__
___
Python-bugs-list mailing li
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Antoine, as I've already mentioned in my other comments, I'm -1 on
changing the Unicode object to a variable size object.
I also don't think that the micro-benchmarks you are applying really do
test the implemen
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Sean: I'd suggest to discuss this on python-dev.
Note that even if we do use Unicode for the cases in question, the
Turkish locale will still pose a problem - see #1528802 for a discussion.
___
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Yes, all those objections apply to the string type as well. The fact
that strings are variable length objects makes it impossible to do apply
any of the possible optimizations I mentioned. If strings were a fixed
length object, it
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Regarding benchmarks: It's difficult to come up with decent benchmarks
for things like this. A possible strategy is to use an instrumented
interpreter that records which Unicode objects are created and when they
are deleted.
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I've read the comments from Guido and Martin, but they don't convince me
in changing my -1.
As you say: it's difficult to get support for optimizations such a
slicing and concatenation into the core. And that's
New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:
platform should use _winreg and sys.getwindowsversion() to emulate the
missing win32all APIs.
--
assignee: lemburg
components: Library (Lib)
messages: 64187
nosy: lemburg
severity: normal
status: open
title: I
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Checked in as r61674 and r61676 along with some other improvements for
detecting the machine type on Windows.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Regarding the benchmark: You can instrument a 2.x version of the
interpreter to build the data set and then have the test load this data
set in Py3k and have it replay the allocation/deallocation in the same
way it was done on t
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Thanks for running the tests again. The use of pymalloc for the buffer
made a significant difference indeed. I expect that more can be had by
additionally tweaking KEEPALIVE_SIZE_LIMIT.
It is interesting to see that the free list
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I wasn't clear enough: my point was that your free list patch would
probably benefit from some tuning of the cut-off parameters. 15
characters appears to be too small (see the HISTORY file histogram).
You'll likely ge
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
The flag should be named "unicode_literals" since that what changes.
Unicode strings are already available in Python 2.x :-)
BTW: I'm not convinced that these future imports are all that useful -
the ratio between
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Hi Mark,
I hope this patch makes it into 2.6.
One thing I'm curious about is the version of "Visual Studio 2008" that
is needed to support this kind cross-compilation and which version will
be or is used to build t
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Nevermind, diving deep into the MSDN, I found the answer:
http://msdn2.microsoft.com/en-us/library/hs24szh9.aspx
So for cross-compilation, the Visual Studio 2008 Standard Edition is
sufficient.
Is the Professional Edition used f
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
The was not a mistake, it was done on purpose since there would
otherwise have been no way to add non-ASCII Unicode code points to a raw
Unicode literal, rendering raw Unicode literals pretty useless.
Even if you use UTF-8 as sourc
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Note that
value = unicode(value).encode("utf-8")
will also work if value is already Unicode, so a backwards compatible
fix would be to allow passing in:
* ASCII encoded strings
* Unicode objects
for the meta data ke
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Agreed, but any change will target the package authors who can easily
upgrade their packages to use Unicode for e.g. names.
If the change were to address distutils users, we'd have to be a lot
more careful.
In any case, if U
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
With "distutils users" I'm referring to people that are told to run
"python setup.py install". Changed affecting the way this line behaves
need to be carefully considered.
OTOH, when upgrading a packa
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
You can't change the codec - it's being used in other places as well,
e.g. for use cases where you need to have a 7-bit encoded readable
version of a Unicode object.
Adding a new codec would be fine, though I don'
Changes by Marc-Andre Lemburg <[EMAIL PROTECTED]>:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2541>
__
___
Python-bugs-list mailing list
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
You can't change the codec - it's being used in other places as well,
e.g. for use cases where you need to have an 8-bit encoded readable
version of a Unicode object (which happens to be Latin-1 + Unicode
escapes for
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
What do you mean with "enough" ?
The "raw-unicode-escape" codec is used in Python 2.x to convert literal
strings of the form ur"" to Unicode objects. It's a variant of the
"unicode-escape&qu
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
While that's true for cPickle, it is not for pickle. The pickle protocol
itself is defined in terms of the "raw-unicode-escape" codec (see
pickle.py).
Besides, you cannot assume that the Python interpreter itself is
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
You are probably referring to 32-bit platforms. At least on 64-bit
platforms, there's no problem with your test cases:
>>> # this is to get the unicode_freelist initialized
... # the length of the string
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 32-bit platforms, it's probably best to add a size check. I don't
it's worth doing that on 64-bit platforms - overflows are rather
unlikely there.
__
Tracker <[EMAIL PROTECTED]&
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
While it may be desirable to to have repr(unicode) return a non-ASCII
string, the suggested approach is not suitable to solve the problem.
repr() is usually used in logging and applications/users/tools don't
expect to sudden
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-04-18 05:35, atsuo ishimoto wrote:
> atsuo ishimoto <[EMAIL PROTECTED]> added the comment:
>
> Is a codec which encode() returns an Unicode allowed in Python3?
Sure, why not ?
I think you have to ask anot
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
@@ -2195,7 +2200,7 @@
}
return Py_None;
}
- len = lastdot - start;
+ len = (size_t)(lastdot -
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
BTW: The API PyUnicode_AsString() is pretty useless by itself - there's
no way to access the size information of the returned string without
again going to the Unicode object.
I'd suggest to remove the API altoget
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-05-03 20:25, Alexandre Vassalotti wrote:
> Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:
>
> Committed to r62667.
>
> Thank you all for your comments!
>
> --
>
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-05-06 00:07, Guido van Rossum wrote:
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>
> On Fri, Apr 18, 2008 at 1:46 AM, Marc-Andre Lemburg
> <[EMAIL PROTECTED]> wrote:
>> On 20
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-05-06 19:10, Guido van Rossum wrote:
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>
> On Tue, May 6, 2008 at 1:26 AM, Marc-Andre Lemburg wrote:
>> So you've limited the codec desi
New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:
The API PyUnicode_AsString() is pretty useless by itself - there's
no way to access the size information of the returned string without
again going to the Unicode object.
I'd suggest to remove the API altoget
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
IMO, it's better to correct API design errors early, rather than going
through a deprecation process.
Note that PyUnicode_AsString() is also different than its cousind
PyString_AsString().
PyString_AsString() is mostly use
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
AFAIR, this code was added by Martin as optimization.
The function is a direct interface to PyUnicode_BuildEncodingMap() which
builds either a dictionary or EncodingMap object for use by the charmap
codec.
It is primarily used
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-10-21 11:22, Dan Dibagh wrote:
> Your reasoning shows a lack of understanding how Python is actually used
> from a programmers point of view.
Hmm, I've been using Python for almost 15 years now and do believe
th
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-10-22 01:34, Martin v. Löwis wrote:
>> What makes you think that the problem cannot be fixed without changing
>> the existing pickle format 0?
>
> Applications might rely on what was implemented rather t
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Before CodecInfo tuple subclasses were introduced, the lookup() function
used to return a tuple: (encoder, decoder, stream_reader, stream_writer)
See http://www.python.org/dev/peps/pep-0100/
These were normally addressed by po
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
The lower-casing doesn't hurt, since that's done anyway during codec
lookup, but I'd be -1 on making this try to duplicate the aliasing
already done by the encodings package.
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
+1 on adding Viktor's patch.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4213>
___
___
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
You can have all this by using the time module's functions.
It is true that these don't work for all dates, but they are still
useful to have.
FWIW: mxDateTime has always had methods to convert the date/time values
t
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Are you sure that you've used the right source code encoding for writing
these characters ?
Note that the Unicode .isalpha() method relies entirely on what the
Unicode database provides as code point information. If a characte
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
FWIW: I get the following in Python 2.5:
>>> print u'\u0401'
Ё
>>> print u'\u0451'
ё
>>> print u'\u0401'.isalpha()
True
>>> print u'\u0451'.isalpha()
True
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
... and for the other character:
>>> print u'\u0427'
Ч
>>> print u'\u0447'
ч
>>> print u'\u0427'.isalpha()
True
>>> print u'\u0447'.isalpha()
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-11-25 12:11, Nick Barnes wrote:
> New submission from Nick Barnes <[EMAIL PROTECTED]>:
>
> UTF-7 decoding raises an exception for any character not in the RFC2152
> "Set D" (directly encoded char
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-11-25 21:16, David Schnur wrote:
> New submission from David Schnur <[EMAIL PROTECTED]>:
>
> This is my first time submitting an issue; sorry if I am doing this
> wrong. While attempting to build/inst
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
This is why we don't see the problem:
http://msdn.microsoft.com/en-us/library/f2c0w594.aspx
"""
The default is /MANIFEST.
"""
So it appears that yo
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-11-25 19:56, Nick Barnes wrote:
> Nick Barnes <[EMAIL PROTECTED]> added the comment:
>
> Well, I could submit a diff for unicodeobject.c, but I have never
> contributed to Python (or used this particular
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Would be nice if the same icon could also be the default for bdist_msi.
"Retro" could you point us to some documentation on how to fix this ?
--
nosy: +lemburg
___
Python
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I think this is a documentation bug more than anything else.
Removing PyObject_HEAD_INIT() is certainly not an option, since it is
required to init static PyObject singletons that are declared in C (just
like the PyTypeObjec
New submission from Marc-Andre Lemburg <[EMAIL PROTECTED]>:
Now that #4389 is fixed, it would be nice if the bdist_msi and
bdist_wininst created installers could use the same Python icon for
their uninstallers.
Note that both commands create installers that are prefixed with the
Python v
Changes by Marc-Andre Lemburg <[EMAIL PROTECTED]>:
--
type: -> feature request
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4480>
___
_
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
I opened #4480 for the distutils commands.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
This is due to the function downcasting the wchar_t values to
Py_UNICODE, which is a 2-byte value if you build Python as UCS2 version
on Unix.
Most Unixes ship with UCS4 builds, so you don't see the problem there.
Mac OS X s
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-01 14:52, Retro wrote:
> Retro <[EMAIL PROTECTED]> added the comment:
>
> Marc-Andre, why haven't you selected the version 'Python 3.0' as well? I
> think it's still time to fix thi
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
There are still quite a few C99 comments left in the code, esp. in code
that's meant for MSVC (which works fine with them) and code for the Mac
(which uses gcc and also doesn't have problems with them). Esp. the
ctypes an
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-03 01:44, Christian Heimes wrote:
> Christian Heimes <[EMAIL PROTECTED]> added the comment:
>
> Barry, the issue in _ctypes/callproc.c could be a problem for us
> although Python 2.6 and 3.0 are comp
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Amaury, I don't see where imp.find_module() tries to do a compile()
(which would trigger the SyntaxError). Is that really the full traceback ?
Regarding the strategy of pydoc to try to list all modules: I don't
think th
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-05 11:24, Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
>
> Yes, it is the full traceback.
>
> The modules are not compiled nor imp
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-05 11:49, Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
>
> Explanation is simple:
> help("modules") just lists all files but do not ope
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Looks good.
--
nosy: +lemburg
stage: patch review -> commit review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-05 13:28, Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
>
> Attached patch ignores any Exception during module import.
> Note that KeyboardInt
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
For Python 2.x you cannot change the "main" function name of C
extensions, since this is used by the Python import mechanism.
--
nosy: +lemburg
___
Python tracker <[EMAI
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Please put the PyUnicode_Compare() API back in there.
Removing __cmp__ really doesn't have anything to do with removing often
used helper functions for comparing certain object types and only
cripples the C API in a needless w
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Instead of removing cmp(a, b) and replacing all uses with (a>b)-(b
<http://bugs.python.org/issue1717>
___
___
Python-bugs-list mailing list
Uns
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-09 00:12, Christian Heimes wrote:
> Christian Heimes <[EMAIL PROTECTED]> added the comment:
>
> Marc-Andre, how do you like a function PyUnicode_Equal() instead of
> PyUnicode_Compare()?
>
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-09 00:58, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> I wrote:
>> IMO PyUnicode_Compare() should be replaced by a hypothetical
>> PyObject_RichCompare(
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-09 10:59, Raymond Hettinger wrote:
> Raymond Hettinger <[EMAIL PROTECTED]> added the comment:
>
> Moving cmp() somewhere other than builtins is not progress. IMO, it
> needs to die off and the concept
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
On 2008-12-09 16:06, Antoine Pitrou wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
>> The idea was to have one implementation of the work-around (a>b) - (b> instead of 10 or so instances
Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:
Python uses the Unicode database for the mapping and this only contains
1-1 mappings. The special cases (mostly 1-2 mappings) are not included.
It would be nice to have them available as well, but I guess we'd have
to write t
Marc-Andre Lemburg added the comment:
On 2008-12-13 16:08, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Here is a new patch without any dispatch shortcut in ceval.c, just
> optimizations in unicodeobject.c and longobject.c. Net result on pybenc
Marc-Andre Lemburg added the comment:
On 2008-12-15 16:34, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Le lundi 15 décembre 2008 à 14:41 +0000, Marc-Andre Lemburg a écrit :
>> Why have you removed the complete error handling section in
>>
Changes by Marc-Andre Lemburg :
--
nosy: -lemburg
___
Python tracker
<http://bugs.python.org/issue1673409>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marc-Andre Lemburg added the comment:
On 2008-12-17 00:25, Eric Eisner wrote:
> New submission from Eric Eisner :
>
> I discovered this when trying to splice a string containing unicode
> codepoints higher than U+
>
>
> all examples on 32-bit Ubuntu Linux
&
Marc-Andre Lemburg added the comment:
On 2008-12-17 00:53, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
> As Marc-Andre say, this is not a bug. Finding out the exact name of the
> configure option is left as an exercise.
Ah, so that changed as well... for Pyt
Marc-Andre Lemburg added the comment:
On 2008-12-20 11:54, Mark Dickinson wrote:
> New submission from Mark Dickinson :
>
> pybench needs to be updated for Python 3.0, in particular to remove use of
> cmp. Here's a patch, against the py3k branch.
>
> Questions (mainly
Marc-Andre Lemburg added the comment:
Please remember to add back PyUnicode_Compare() if that hasn't already
been done.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
2008-12-02: Released mxODBC.Connect 1.0.0
Marc-Andre Lemburg added the comment:
On 2008-12-20 17:19, Alex Stapleton wrote:
> Alex Stapleton added the comment:
>
> I am trying to get a PEP together for this. Does anyone have any thoughts
> on how to handle comparison between unicode strings in a locale aware
> s
Marc-Andre Lemburg added the comment:
On 2008-12-21 22:37, Antoine Pitrou wrote:
> New submission from Antoine Pitrou :
>
> This patch prints opcode statistics at the end of a pybench run if
> DYNAMIC_EXECUTION_PROFILE has been enabled when compiling the interpreter.
>
&g
Marc-Andre Lemburg added the comment:
On 2008-12-22 15:07, Mark Dickinson wrote:
> Mark Dickinson added the comment:
>
> Thanks for the responses!
>
>> I don't think should go into 3.0.1 - they are a new feature
>> and not a bug fix.
>
> But if these c
Marc-Andre Lemburg added the comment:
On 2008-12-27 13:58, STINNER Victor wrote:
> Python 2.x allows to encode any byte string (str) and ASCII unicode
> string (unicode):
>
> $ python
> Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>>> import zlib
>>>&g
Marc-Andre Lemburg added the comment:
On 2008-12-26 22:09, Antoine Pitrou wrote:
> This patch implements what is usually called "threaded code" for the
> ceval loop on compilers which support it (only gcc). The idea is that
> there is a separate opcode dispatch epilog at the
Marc-Andre Lemburg added the comment:
On 2008-12-30 13:20, John Machin wrote:
> byte-compiling C:\python26\Lib\site-packages\x9d.py to x9d.pyc
> SyntaxError: ('unknown encoding: cp1252',
> ('C:\\python26\\Lib\\site-packages\\x9d.py', 0, 0, None))
>
>
Marc-Andre Lemburg added the comment:
FWIW: POSIX defines Unix time_t *not* to include leap seconds.
You can easily check whether your platform or C lib behaves
POSIX-ly correct or not:
POSIX: 1986-12-31 23:59:59 UTC == 536457599 ticks
With leap seconds: == 536457612 ticks
Marc-Andre Lemburg added the comment:
On 2009-01-01 23:59, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> I've updated the comments as per Alexandre's request, added support for
> SUN CC, and fixed the generation script to use the new filename.
Since th
Marc-Andre Lemburg added the comment:
Moving declarations into header files is not really in line with the way
Python developers use header files:
We usually only put code into header files that is meant for public use.
Buy putting declarations into the header files without additional
Marc-Andre Lemburg added the comment:
Also note that by removing the extern "C" declarations, you not only
change the exported symbol names of functions, but also those of
exported globals.
Those would also have to get declared in the header files, to prevent
their names from bei
Marc-Andre Lemburg added the comment:
The added type casts are useful to have - even outside the context of
the idea behind the patch.
___
Python tracker
<http://bugs.python.org/issue4
901 - 1000 of 2239 matches
Mail list logo
