New submission from Adam Olsen:
In the large else branch in decode_unicode (if encoding is not NULL or
"iso-8859-1"), the new string it produces is not nul-terminated. This
then hits PyUnicode_DecodeUnicodeEscape's octal escape case, which reads
past the end of the string (bu
New submission from Adam Olsen:
type_new() allocates the exact number of slots it's going to use, but
various other functions assume there's one more slot with a NULL name
field serving as a sentinel. I'm unsure why it doesn't normally crash.
--
components: Inter
Adam Olsen added the comment:
typeobject.c:1842:type_new
type = (PyTypeObject *)metatype->tp_alloc(metatype, nslots);
nslots may be 0.
typeobject.c:1966:type_new assigns this just-past-the-end address to
tp_members
type->tp_members = PyHeapType_GET_MEMBERS(et);
type_new
Adam Olsen added the comment:
Ugh, you're right.
I refactored PyType_GenericAlloc out of my fork, which is why I got a crash.
Sorry for wasting your time.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Adam Olsen added the comment:
The problem with "being tolerate" as you suggest is you lose the ability
to round-trip. Read in a file using the UTF-8 signature, write it back
out, and suddenly nothing else can open it.
Conceptually, these signatures shouldn't even be part
Adam Olsen added the comment:
On 11/1/07, James G. sack (jim) <[EMAIL PROTECTED]> wrote:
>
> James G. sack (jim) added the comment:
>
> Adam Olsen wrote:
> > Adam Olsen added the comment:
> >
> > The problem with "being tolerate" as you suggest is yo
New submission from Adam Olsen:
If I create a subclass of 'type' that's also an instance of 'type', then
I change __class__ to point to itself, at which point it cannot be freed
(as the type object is needed to delete the instance.)
I believe this can be solved by reset
Changes by Adam Olsen:
--
nosy: +rhamphoryncus
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1225584>
_
___
Python-bugs-list mailing list
Unsubs
New submission from Adam Olsen:
(thanks go to my partner in crime, jorendorff, for helping flesh this out.)
lookdict calls PyObject_RichCompareBool without using INCREF/DECREF on
the key passed. It's possible for the comparison to delete the key from
the dict, causing its own argument
Adam Olsen added the comment:
I don't believe there's anything to debate on this, so all it really needs is a
patch, followed by getting someone to review and commit it.
--
___
Python tracker
<http://bugs.python.org
Adam Olsen added the comment:
As far as I know.
--
___
Python tracker
<http://bugs.python.org/issue1441>
___
___
Python-bugs-list mailing list
Unsubscribe:
Adam Olsen added the comment:
Signals can directly kill a process. Try SIGTERM to see this. SIGINT is
caught and handled by Python, which just happens to default to a graceful exit
(unless stuck in a lib that prevents that.) Try pasting your script into an
interactive interpreter session
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Here's another approach to avoiding set_swap_bodies. The existing
semantics are retained. Rather than creating a temporary frozenset and
swapping the contents, I check for a set and call the internal hash
function directly
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Revised again. sets are only hashed after PyObject_Hash raises a TypeError.
This also fixes a regression in test_subclass_with_custom_hash. Oddly,
it doesn't show up in trunk, but does when my previous patch is applied
to py3k.
New submission from Adam Olsen <[EMAIL PROTECTED]>:
sets are based on dicts' code, so they have the same problem as bug
1517. Patch attached.
--
files: python-lookkeycompare.diff
keywords: patch
messages: 66829
nosy: Rhamphoryncus
severity: normal
status: open
title: loo
Adam Olsen <[EMAIL PROTECTED]> added the comment:
There is no temporary hashability. The hash value is calculated, but
never stored in the set's hash field, so it will never become out of
sync. Modification while __hash__ or __eq__ is running is possible, but
for __eq__ that app
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue689895>
___
Python-bugs
New submission from Adam Olsen <[EMAIL PROTECTED]>:
Patch allows any iterable (such as set and frozenset) to be used for
__all__.
I also add some blank lines, making it more readable.
--
files: python-importall.diff
keywords: patch
messages: 67104
nosy: Rhamphoryncus
severity:
Adam Olsen <[EMAIL PROTECTED]> added the comment:
tuples are already allowed for __all__, which breaks attempts to
monkey-patch it.
I did forget to check the return from PyObject_GetIter.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Is there any reason not to name it ProxyMixin, ala DictMixin?
--
nosy: +Rhamphoryncus
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Adam Olsen <[EMAIL PROTECTED]> added the comment:
The patch for issue 1856 should fix the potential crash, so we could
eliminate that scary blurb from the docs.
--
nosy: +Rhamphoryncus
_
Tracker <[EMAIL PROTECTED]>
<http://
Adam Olsen <[EMAIL PROTECTED]> added the comment:
_deref won't work for remote objects, will it? Nor _unwrap, although
that starts to get "fun".
Tracker <[EMAIL PROTECTED]>
<http
Adam Olsen <[EMAIL PROTECTED]> added the comment:
If it's so specialized then I'm not sure it should be in the stdlib -
maybe as a private API, if there was a user.
Having a reference implementation is noble, but this isn't the right way
to do it. Maybe as an example in D
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Surely remote proxies fall under what would be expected for a "proxy
mixin"? If it's in the stdlib it should be a canonical implementation,
NOT a reference implementation.
At the moment I can think up 3 use cases:
* weakre
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3001>
___
__
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2507>
___
__
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2833>
___
__
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3021>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Does the PythonInterpreter option create multiple interpreters within a
single process, rather than spawning separate processes?
IMO, that API should be ripped out. They aren't truly isolated
interpreters and nobody I've asked
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Right, so it's only the python modules loaded as part of the app that
need to be isolated. You don't need the stdlib or any other part of the
interpreter to be isolated.
This could be done either by not using the normal import
Adam Olsen <[EMAIL PROTECTED]> added the comment:
The inplace operators aren't right for weakref proxies. If a new object
is returned there likely won't be another reference to it and the
weakref will promptly be cleared.
This could be fixed with another property like _target,
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3042>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
PEP 3134's implicit exception chaining (if accepted) would require your
semantic, and your semantic is simpler anyway (even if the
implementation is non-trivial), so consider my objections to be dropped.
PEP 3134 also proposes implic
Adam Olsen <[EMAIL PROTECTED]> added the comment:
PEP 3134 gives reason to change it. __context__ should be set from
whatever exception is "active" from the try/finally, thus it should be
the inner block, not the outer except block.
This flipping of behaviour, and the general a
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I agree, the argument for a syntax error is weak. It's more instinct
than anything else. I don't think I'd be able to convince you unless
Guido had the same instinct I do. ;)
___
P
New submission from Adam Olsen <[EMAIL PROTECTED]>:
In 2.x, the size of C string needed for an environment variable used by
posix_execve was calculated using PyString_GetSize. In 3.0 this is
translated to PyUnicode_GetSize. However, in 3.0 the C string is the
UTF-8 encoded version
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2320>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Updated version of roudkerk's patch. Adds the new function to
pythread.h and is based off of current trunk.
Note that Parser/intrcheck.c isn't used on my box, so it's completely
untested.
roudkerk's original analys
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Incidentally, it doesn't seem necessary to reinitialize the lock. Posix
duplicates the lock, so if you hold it when you fork your child will be
able to unlock it and use it as normal. Maybe there's some non-Posix
behaviour o
New submission from Adam Olsen <[EMAIL PROTECTED]>:
All these in multiprocessing.h are lacking suitable py/_py/Py/_Py/PY/_PY
prefixes:
PyObject *mp_SetError(PyObject *Type, int num);
extern PyObject *pickle_dumps;
extern PyObject *pickle_loads;
extern PyObject *pickle_protocol;
extern Py
New submission from Adam Olsen <[EMAIL PROTECTED]>:
multiprocessing.c currently has code like this:
temp = PyDict_New();
if (!temp)
return;
if (PyModule_AddObject(module, "flags", temp) < 0)
return;
PyModule_Add
Adam Olsen <[EMAIL PROTECTED]> added the comment:
The directory is irrelevant. C typically uses a flat namespace for
symbols. If python loads this library it will conflict with any other
libraries using the same name. This has happened numerous times in the
past, so there's no ques
Adam Olsen <[EMAIL PROTECTED]> added the comment:
This doesn't look right. PyDict_SetItemString doesn't steal the
references passed to it, so your reference to flags will be leaked each
time. Besides, I think it's a little cleaner to INCREF it before call
PyModule_AddObje
New submission from Adam Olsen <[EMAIL PROTECTED]>:
$ ./python
Python 2.6a3+ (unknown, Jun 12 2008, 20:10:55)
[GCC 4.2.3 (Debian 4.2.3-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import
Adam Olsen <[EMAIL PROTECTED]> added the comment:
op is a KeyedRef instance. The instance being cleared from the module
is the multiprocessing.util._afterfork_registry.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d626b0 (LWP 2287)]
0x0809a
Adam Olsen <[EMAIL PROTECTED]> added the comment:
More specific test case.
--
title: segfault after loading multiprocessing.reduction -> segfault from
multiprocessing.util.register_after_fork
Added file: http://bugs.python.org/file10610/register_after_fork
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Very specific test case, eliminating multiprocessing entirely. It may
be an interaction between having the watched obj as its own key in the
WeakValueDictionary and the order in which the two modules are cleared.
Added file
Changes by Adam Olsen <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10612/inner.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Adam Olsen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10610/register_after_fork-crash.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
title: segfault from multiprocessing.util.register_after_fork -> segfault with
WeakValueDictionary and module clearing
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Specific enough yet? Seems the WeakValueDictionary and the module
clearing aren't necessary.
A subclass of weakref is created. The target of this weakref is added
as an attribute of the weakref. So long as a callback is present th
Changes by Adam Olsen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10612/inner.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Adam Olsen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10611/outer.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Adam Olsen <[EMAIL PROTECTED]> added the comment:
1. MyRef is released from the module as part of shutdown
2. MyRef's subtype_dealloc DECREFs its dictptr (not clearing it, as
MyRef is dead and should be unreachable)
3. the dict DECREFs the Dummy (MyRef's target)
4. Dummy's
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Ahh, I missed a detail: when the callback is called the weakref has a
refcount of 0, which is ICNREFed to 1 when getting put in the args, then
drops down to 0 again when the args are DECREFed (causing it to get
_Py_ForgetReference to be ca
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Patch to add extra sanity checks to Py_INCREF (only if Py_DEBUG is set).
If the refcount is 0 or negative if calls Py_FatalError. This should
catch revival bugs such as this one a little more clearly.
The patch also adds a little more ch
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Aww, that's cheating. (Why didn't I think of that?)
___
Python tracker <[EMAIL PROTECTED]>
<http://
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +jnoller
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3100>
___
___
Python
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Well, my attempt at a patch didn't work, and yours does, so I guess I
have to support yours. ;)
Can you review my python-incref-from-zero patch? It verifies the
invariant that you need, that once an object hits a refcount of 0 i
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Ahh, it seems gcmodule already considers the weakref to be reachable
when it calls the callbacks, so it shouldn't be a problem.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Another minor nit: "if(current->ob_refcnt > 0)" should have a space
after the "if". Otherwise it's looking good.
___
Python tracker <[EMAIL PROTE
Adam Olsen <[EMAIL PROTECTED]> added the comment:
This is messy. File descriptors from other threads are leaking into
child processes, and if the write end of a pipe never gets closed in all
of them the read end won't get EOF.
I suspect "cat"'s stdin is getting d
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3088>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I'm not sure that fix is 100% right - it fixes safety, but not
correctness. Wouldn't it be more correct to move all 3 into
temporaries, assign from tstate, then XDECREF the temporaries?
Otherwise you're going to exp
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Looking good.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3114>
___
___
Python-bugs
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus, jnoller
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3125>
___
_
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Jesse, can you be more specific?
Thomas, do you have a specific command to reproduce this? It runs fine
if I do "./python -m test.regrtest -v test_multiprocessing test_ctypes".
That's with amaury'
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I see no common symbols between #3102 and #3092, so unless I missed
something, they shouldn't be involved.
I second the notion that multiprocessing's use of pickle is the
triggering factor. Registering so many types is
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Unfortunately, Py_INCREF is sometimes used in an expression (followed by
a comma). I wouldn't expect an assert to be valid there (and I'd want
to check ISO C to make sure it's portable, not just accepted by GCC).
I&#x
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3107>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I don't see a problem with skipping it, but if chroot is the problem,
maybe the chroot environment should be fixed to include /dev/shm?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I agree with your agreement.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3111>
___
__
New submission from Adam Olsen <[EMAIL PROTECTED]>:
Found in Modules/_sqlite/cursor.c:
self->statement = PyObject_New(pysqlite_Statement,
&pysqlite_StatementTy
pe);
if (!self->statement) {
goto error;
}
rc = pysqlite_statement_create
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Works for me.
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Adam Olsen <[EMAIL PROTECTED]> added the comment:
That's the same version I'm using. Maybe there's some font size differences?
I'm also on a 64-bit AMD.
___
Python tracker <[EMAIL PROTECTED]>
&
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3155>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
* cause/context cycles should be avoided. Naive traceback printing
could become confused, and I can't think of any accidental way to
provoke it (besides the problem mentioned here.)
* I suspect PyErr_Display handled string except
Adam Olsen <[EMAIL PROTECTED]> added the comment:
On Sun, Jun 22, 2008 at 8:07 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> You mean they should be detected when the exception is set? I was afraid
> that it may make exception raising slower. Reporting is not performa
Adam Olsen <[EMAIL PROTECTED]> added the comment:
On Sun, Jun 22, 2008 at 1:04 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le dimanche 22 juin 2008 à 17:17 +, Adam Olsen a écrit :
>> I mean
Adam Olsen <[EMAIL PROTECTED]> added the comment:
On Sun, Jun 22, 2008 at 1:48 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le dimanche 22 juin 2008 à 19:23 +, Adam Olsen a écrit :
>> For this
Adam Olsen <[EMAIL PROTECTED]> added the comment:
On Sun, Jun 22, 2008 at 2:20 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le dimanche 22 juin 2008 à 19:57 +, Adam Olsen a écrit :
>> T
Adam Olsen <[EMAIL PROTECTED]> added the comment:
On Sun, Jun 22, 2008 at 2:56 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Le dimanche 22 juin 2008 à 20:40 +0000, Adam Olsen a écrit :
>> Passing in e.args is probably sufficient.
>
> I think it's very optimisti
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I've checked it again, using the font preferences rather than the zoom
setting, and I can reproduce the problem.
Part of the problem stems from using pixels to set the margin, rather
than ems (or whatever the text box is based on
Adam Olsen <[EMAIL PROTECTED]> added the comment:
On Wed, Jul 2, 2008 at 3:44 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
>> Mark, can you try commenting out _TestCondition and seeing if you can
>&g
Adam Olsen <[EMAIL PROTECTED]> added the comment:
On Wed, Jul 2, 2008 at 5:08 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> Okay. I just got about 5 perfect runs of the test suite, followed by:
Adam Olsen <[EMAIL PROTECTED]> added the comment:
That looks better. It crashed while deleting an exception, who's args
tuple has a bogus refcount. Could be a refcount issue of the
exception or the args, or of something that that references them, or a
dangling pointer, or a buffer o
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Also, make sure you do a "make clean" since you last updated the tree or
touched any file or ran configure. The automatic dependency checking
isn't 100% reliable.
___
Python tracker <
New submission from Adam Olsen <[EMAIL PROTECTED]>:
inherit_special contains logic to inherit the base type's tp_basicsize
if the new type doesn't have it set. The logic was spread over several
lines, but actually does almost nothing (presumably an artifact of
previous versio
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue874900>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Apparently modwsgi uses subinterpreters because some third-party
packages aren't sufficiently thread-safe - modwsgi can't fix those
packages, so subinterpreters are the next best thing.
http://groups.google.com/group/modwsgi/b
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Ahh, I did miss that bit, but it doesn't really matter.
Tell modwsgi to only use the main interpreter ("PythonInterpreter
main_interpreter"), and if you want multiple modules of the same name
put them in different packages
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Franco, you need to look at the line above that check:
PyThreadState *check = PyGILState_GetThisThreadState();
if (check && check->interp == newts->interp && check != newts)
Py_FatalErr
Adam Olsen <[EMAIL PROTECTED]> added the comment:
It's only checking that the original tstate *for the current thread* and
the new tstate have a different subinterpreter. A subinterpreter can
have multiple tstates, so long as they're all in different threads.
The documentat
Adam Olsen <[EMAIL PROTECTED]> added the comment:
In general I suggest replacing the lock with a new lock, rather than
trying to release the existing one. Releasing *might* work in this
case, only because it's really a semaphore underneath, but it's still
easier to think about b
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Looking over some of the other platforms for thread_*.h, I'm sure
replacing the lock is the right thing.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Adam Olsen <[EMAIL PROTECTED]> added the comment:
How would this allow you to free all memory? The interpreter will still
reference it, so you'd have to have called Py_Finalize already, and
promise not to call Py_Initialize afterwords. This further supposes the
process will live
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Basically you just want to kick the malloc implementation into doing
some housekeeping, freeing its caches? I'm kinda surprised you don't
add the hook directly to your libc's malloc.
IMO, there's no use-case for
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Simpler way to reproduce this (on linux):
$ rm unicodetest.pyc
$
$ python -c 'import unicodetest'
Result: False
Len: 2 1
Repr: u'\ud800\udd23' u'\U00010123'
$
$ python -c 'import unicodetest
Adam Olsen <[EMAIL PROTECTED]> added the comment:
No, the configure options are wrong - we do use UTF-16 and UTF-32.
Although modern UCS-4 has been restricted down to the range of UTF-32
(it used to be larger!), UCS-2 still doesn't support the supplementary
planes (ie no surrogat
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Marc, perhaps Unicode has refined their definitions since you last looked?
Valid UTF-8 *cannot* contain surrogates[1]. If it does, you have
CESU-8[2][3], not UTF-8.
So there are two bugs: first, the UTF-8 codec should refuse to load
surr
1 - 100 of 196 matches
Mail list logo
