Adam Olsen <[EMAIL PROTECTED]> added the comment:
Err, to clarify, the parse/compile/whatever stages is producing broken
UTF-32 (surrogates are ill-formed there too), and that gets transformed
into CESU-8 when the .pyc is saved.
___
Python tracker &
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3299>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Graham, I appreciate the history of sub-interpreters and how entrenched
they are. Changing those practises requires a significant investment.
This is an important factor to consider.
The other factor is the continuing maintenan
New submission from Adam Olsen <[EMAIL PROTECTED]>:
The Unicode FAQ makes it quite clear that any surrogates in UTF-8 or
UTF-32 should be treated as errors. Lone surrogates in UTF-16 should
probably be treated as errors too (but only during encoding/decoding;
unicode objects on UTF-16
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
components: +Unicode
type: -> behavior
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Marc, I don't understand what you're saying. UTF-16's surrogates are
not optional. Unicode 2.0 and later require them, and Python is
supposed to support it.
Likewise, UCS-4 originally allowed a much larger range of c
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I've got another report open about the codecs not properly reporting
errors relating to surrogates: issue 3672
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Adam Olsen added the comment:
$ ./python -m timeit -s 'from collections import deque; c =
deque(range(100))' 'c.append(c.popleft())'
100 loops, best of 3: 0.29 usec per loop
$ ./python -m timeit -s 'c = range(100)' 'c.append(c.pop(0))'
1
Adam Olsen added the comment:
Why aren't you using 64-bit hashes on 64-bit architectures?
--
nosy: +Rhamphoryncus
___
Python tracker
<http://bugs.python.org/i
Adam Olsen added the comment:
I assume you mean 63. ;)
--
___
Python tracker
<http://bugs.python.org/issue8188>
___
___
Python-bugs-list mailing list
Unsubscribe:
Adam Olsen added the comment:
The minimal patch doesn't initialize dummy_char or dummy_c. It's
harmless here, but please fix it. ;)
sizeof(dummy_char) will always be 1 (C defines sizeof as multiples of
char.) The convention seems to be hardcoding
New submission from Adam Olsen:
This adds signal.set_wakeup_fd(fd), which allows a single library to be
woken when a signal comes in.
--
files: python2.6-set_wakeup_fd1.diff
messages: 58385
nosy: rhamphoryncus
severity: normal
status: open
title: Patch for signal.set_wakeup_fd
Added
Adam Olsen added the comment:
Guido, it looks like I can't alter the Assigned To field. You get the
Nosy List instead. ;)
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Adam Olsen added the comment:
version 2, adds to Doc/library/signal.rst. It also tweaks the
set_wakeup_fd's docstring.
I haven't verified that my formatting in signal.rst is correct.
Specifically, the '\0' should be checked.
Added file: http://bugs.python.or
Adam Olsen added the comment:
Thanks georg.
Added file: http://bugs.python.org/file8925/python2.6-set_wakeup_fd3.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1583>
__Index: Doc/librar
Adam Olsen added the comment:
The python API has the advantage that you can test for it at runtime,
avoiding a compile-time check. I don't know if this is significant though.
I don't see the big deal about a C API. All you need to do is call
PyImport_ImportModule(&qu
Adam Olsen added the comment:
mwh, my threading patch is extensive enough and has enough overlap that
I'm not intimidating by fixing this. It's low on my list of priorities
though.
So far my tendency is to rip out multiple interpreters, as I haven't
seen what it wants to ac
Adam Olsen added the comment:
You have:
#define Py_NAN Py_HUGE_VAL * 0
I think this would be safer as:
#define Py_NAN (Py_HUGE_VAL * 0)
For instance, in code that may do "a / Py_NAN".
Those manual string copies (*cp++ = 'n';) are ugly. Can't you use
strcpy()
Adam Olsen added the comment:
Minor typo. Should be IEEE:
"Return the sign of an int, long or float. On platforms with full IEE
754\n\"
--
nosy: +rhamphoryncus
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Changes by Adam Olsen:
--
nosy: +rhamphoryncus
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1676>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Adam Olsen:
--
nosy: +rhamphoryncus
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1683>
__
___
Python-bugs-list mailing list
Unsubs
Adam Olsen added the comment:
The warning in the documentation should be strengthened. Python simply
does not and cannot support synchronously-generated signals.
It is possible to send a normally synchronous signal asynchronously,
such as the os.kill() Ralf mentioned, so it's theoreti
Adam Olsen added the comment:
In essence, it's a weakness of the POSIX API that it doesn't distinguish
synchronous from asynchronous signals.
The consequences of either approach seem minor though. I cannot imagine
a sane use case for catching SIGSEGV, but documentation changes
Adam Olsen added the comment:
Is the bug avoided if you import threading first and use it instead of
thread? I'd like to see thread removed in 3.0 (renamed to _thread or
the like.)
--
nosy: +Rhamphoryncus
_
Tracker <[EMAIL PROTECTED
Adam Olsen added the comment:
I think non-main threads should kill themselves off if they grab the
interpreter lock and the interpreter is tearing down. They're about to
get killed off anyway, when the process exits.
PyGILState_Ensure would still be broken. It touches various things tha
Adam Olsen added the comment:
Hrm. It seems you're right. Python needs thread-local data to
determine if the GIL is held by the current thread. Thus, autoTLSkey
and all that need to never be torn down. (The check could be done much
more directly than the current PyThreadState_IsCu
Adam Olsen added the comment:
PyGILState_Ensure WOULD block forever if it acquired the GIL before
doing anything else.
The only way to make Py_Initialize callable after Py_Finalize is to make
various bits of the finalization into no-ops. For instance, it's
currently impossible to unl
Adam Olsen added the comment:
> Adam, did you notice the change on revision 59231 ? the
> PyGILState_Ensure stuff should now remain valid during the
> PyInterpreterState_Clear() call.
That doesn't matter. PyGILState_Ensure needs to remain valid *forever*.
Only once the process
Adam Olsen added the comment:
I'm not sure I understand you, Gregory. Are arguing in favour of adding
extra logic to the GIL code, or against it?
I'm attaching a patch that has non-main thread exit, and it seems to fix
the test case. It doesn't fix the PyGILState_Ensure problem
Changes by Adam Olsen:
--
nosy: +Rhamphoryncus
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1303614>
_
___
Python-bugs-list mailing list
Unsubs
Adam Olsen added the comment:
Is there a guarantee that the with-statement is safe in the face of
KeyboardInterrupt? PEP 343 seems to imply it's not, using it as a
reason for why we need no special handling if __exit__ fails.
--
nosy: +Rhamphor
Adam Olsen added the comment:
Yes, but there's no guarantee it will even reach the C function.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1941>
__
___
Adam Olsen added the comment:
Py_Main calls WaitForThreadShutdown before calling Py_Finalize, which
should wait for all these threads to finish shutting down before it
starts wiping their globals.
However, if SystemExit is raised (such as via sys.exit()), Py_Exit is
called, and it directly
Adam Olsen added the comment:
To put it another way: SystemExit turns non-daemon threads into daemon
threads. This is clearly wrong. Brent, could you reopen the bug?
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Adam Olsen added the comment:
I disagree. sys.exit() attempts to gracefully shutdown the interpreter,
invoking try/finally blocks and the like. If you want to truly force
shutdown you should use os.abort() or os._exit().
Note that, as python doesn't call a main function, you have t
Adam Olsen <[EMAIL PROTECTED]> added the comment:
The original bug is not whether or not python reuses int objects, but
rather that an existing optimization disappears under certain
circumstances. Something is breaking our optimization.
The later cases where the optimization is simply g
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Unless someone has a legitimate use case for disabling small_int that
doesn't involve debugging (which I really doubt), I'd just assume it's
always in use.
__
Tracker <[EMAIL PROTECTED]&
Adam Olsen <[EMAIL PROTECTED]> added the comment:
This bug was introduced by r53249, which was fixing bug #1566280.
Fixed by moving the WaitForThreadShutdown call into Py_Finalize, so all
shutdown paths use it. I also tweaked the name to follow local helper
function conventions.
Martin,
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Oh, and the patch includes a testcase. The current test_threading.py
doesn't work with older versions, but a freestanding version of this
testcase passes in 2.1 to 2.4, fails in 2.5 and trunk, and passes wit
New submission from Adam Olsen <[EMAIL PROTECTED]>:
set_swap_bodies() is used to cheaply create a frozenset from a set,
which is then used for lookups within a set. It does this by creating a
temporary empty frozenset, swapping its contents with the original set,
doing the lookup usi
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1348>
__
___
Python-bugs
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Cleaned up version of Amaury's patch. I stop releasing the GIL after
sys.exitfunc is called, which protects threads from the ensuing teardown.
I also grab the import lock (and never release it). This should prevent
the nasty issue
Adam Olsen <[EMAIL PROTECTED]> added the comment:
The intended use is unsafe. contains, remove, and discard all use it
for a lookup, which can't be fixed.
Upon further inspection, intersection_update is fine. Only a temporary
set (not frozenset!) is given junk, which I don't
New submission from Adam Olsen <[EMAIL PROTECTED]>:
In 3.0, unittest's output has become line buffered. Instead of printing
the test name when it starts a test, then "ok" when it finishes, the
test name is delayed until the "ok" is printed. This makes it
unnece
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Hrm, this behaviour exists in trunk as well. I must be confused about
the cause (but the patch still fixes it.)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I decided not to wait. Here's a patch.
Several of set's unit tests covered the auto-conversion, so I've
modified them.
--
keywords: +patch
Added file: http://bugs.python.org/file1021
Adam Olsen <[EMAIL PROTECTED]> added the comment:
PEP 218 explicitly dropped auto-conversion as a feature. Why should
this be an exception?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I've been unable to find any discussion on this feature. If anything, I
think when PEP 218 was discussed and accepted (and PEP 351 rejected),
the assumption was it didn't exist. Adding it now should be regarded as
a new feature
Adam Olsen <[EMAIL PROTECTED]> added the comment:
Nevermind that the current implementation *is* broken, even if you
consider fixing it to be a low priority. Closing the report with a doc
tweak isn't right.
__
Tracker <[EMAIL PROTECTED]>
<ht
Adam Olsen <[EMAIL PROTECTED]> added the comment:
So why doesn't set() in {} work? Why was PEP 351 rejected when it would
do this properly?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Adam Olsen <[EMAIL PROTECTED]> added the comment:
new_buffersize returns a size_t. You should use SIZE_MAX instead
(although I don't see it used elsewhere in CPython, so maybe there's
portability problems.)
The call to _PyString_Resize implicitly casts the size_t to Py_ssi
Adam Olsen <[EMAIL PROTECTED]> added the comment:
The indentation still needs tweaking. You have only one tab where you
should have two, and one line uses a mix of tabs and spaces.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4006>
___
__
Adam Olsen <[EMAIL PROTECTED]> added the comment:
I'm in favour of just the doc change now. It's less work and we don't
really need to disable that usage.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Changes by Adam Olsen <[EMAIL PROTECTED]>:
--
nosy: +Rhamphoryncus
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3999>
___
__
Adam Olsen added the comment:
I didn't test it, but the patch looks okay to me.
--
nosy: +Rhamphoryncus
___
Python tracker
<http://bugs.python.org/i
Changes by Adam Olsen :
--
nosy: +Rhamphoryncus
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Adam Olsen added the comment:
On my 64-bit linux box there's nothing in the last 4 bits:
>>> [id(o)%16 for o in [object() for i in range(128)]]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Adam Olsen added the comment:
Upon further inspection, although a shift of 4 (on a 64-bit linux box)
isn't perfect for dict, it's fairly close to it and well beyond random
hash values. Mixing things more is just gonna lower it towards random
values.
>>> c()
2: 1, 1,
Adam Olsen added the comment:
The alignment requirements (long double) make it impossible to have
anything in those bits.
Hypothetically, a custom allocator could lower the alignment
requirements to sizeof(void *). However, rotating to the high bits is
pointless as they're the least like
Adam Olsen added the comment:
Antoine, I only meant list() and dict() to be an example of objects with
a larger allocation pattern. We get a substantial benefit from the
sequentially increasing memory addresses, and I wanted to make sure that
benefit wasn't lost on larger allocations
Adam Olsen added the comment:
> At four bits, you may be throwing away information and I don't think
> that's cool. Even if some selected timings are better with more bits
> shifted, all you're really showing is that there is more randomness in
> the upper bits tha
Adam Olsen added the comment:
Testing with a large set of ids is a good demonstration, but not proof.
Forming a set of *all* possible values within a certain range is proof.
However, XOR does work (OR definitely does not) — it's a 1-to-1
transformation (reversible as you say.)
Additio
Adam Olsen added the comment:
Antoine, x ^= x>>4 has a higher collision rate than just a rotate.
However, it's still lower than a statistically random hash.
If you modify the benchmark to randomly discard 90% of its contents this
should give you random addresses, reflecting a l
Adam Olsen added the comment:
The fd field may be written from the main thread simultaneous with the signal
handler activating and reading it out. Back in 2007 the only POSIX-compliant
type allowed for that was sig_atomic_t, anything else was undefined.
Looks like pycore_atomic.h should
Adam Olsen added the comment:
Disagree; if you're writing signal-handling code you should be very careful to
do it properly, even if that's only proper for your current platform. If you
can't do it properly you should find an alternative that doesn't involve
sig
Adam Olsen added the comment:
Converting to/from sig_atomic_t could have a compile time check on currently
supported platforms and isn't buggy for them. For platforms with a different
size you could do a runtime check, only allowing a fd in the range of 0-254
(with 255 reserved);
Adam Olsen added the comment:
signal-safe is different from thread-safe (despite conceptual similarities),
but regardless it's been a long time since I last delved into this so I'm quite
rusty. I could be doing it all wrong.
--
Adam Olsen added the comment:
signalmodule.c has a hack to limit it to the main thread. Otherwise there's
all sorts of platform-specific behaviour.
--
___
Python tracker
<https://bugs.python.org/i
Adam Olsen added the comment:
The key distinction between this and a "bad" circular import is that
this is lazy. You may list the import at the top of your module, but
you never touch it until after you've finished importing yourself (and
they feel the same about you.)
An ug
Adam Olsen added the comment:
It'd probably be sufficient if we raised "NameError: lazy import 'foo'
not yet complete". That should require a set of what names this module
is lazy importing, which is checked in the failure paths of module
attribute lookup
Adam Olsen added the comment:
I believe this is a duplicate of issue #3297. When given a high unicode
scalar value directly in the source (rather than in escaped form) python
will split it into surrogates, even on a UTF-32 build where those
surrogates are nonsensical and ill-formed.
Patches
Adam Olsen added the comment:
Looks like the failure mode has changed here, presumably due to issue
#3672 patches. It now always fails, even after loading from a .pyc.
This is using py3k via bzr, which reports itself as 3.2a0
$ rm unicodetest.pyc
$ ./python -c 'import unicodetest&#x
Adam Olsen added the comment:
I've traced down the biggest problem to decode_unicode in ast.c. It
needs to convert everything into a form of escapes so it becomes pure
ascii, which then become evaluated back into a unicode object.
Unfortunately, it uses UTF-16-BE to do so, which always
Adam Olsen added the comment:
Surrogates aren't optional features of UTF-16, we really need to get
this fixed. That includes .isalpha().
We might keep the old public API for compatibility, but it should be
clearly marked as broken for non-BMP scalar values.
I don't see a pr
Adam Olsen added the comment:
Patch, which uses UTF-32-BE as indicated in my last comment. Test included.
--
keywords: +patch
Added file: http://bugs.python.org/file15043/py3k-nonBMP-literal.diff
___
Python tracker
<http://bugs.python.
Adam Olsen added the comment:
With some further prodding I've noticed that although the test behaves
as expected in the py3k branch (fails on UTF-32 builds before the
patch), it doesn't fail using python 3.0. I'm guessing there's
interactions with compile() vs import an
Adam Olsen added the comment:
On Mon, Oct 5, 2009 at 03:03, Marc-Andre Lemburg wrote:
> We use UCS2 on narrow Python builds, not UTF-16.
>
>> We might keep the old public API for compatibility, but it should be
>> clearly marked as broken for non-BMP scalar values.
>
>
Adam Olsen added the comment:
On Mon, Oct 5, 2009 at 12:10, Marc-Andre Lemburg wrote:
> All this is just nitpicking, really. UCS2 is a character set,
> UTF-16 an encoding.
UCS is a character set, for most purposes synonymous with the Unicode
character set. UCS-2 and UTF-16 are both enc
Adam Olsen added the comment:
Nope, no access.
--
___
Python tracker
<http://bugs.python.org/issue1722344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Adam Olsen added the comment:
That's fine, but please provide a link to the new issue once you create it.
--
___
Python tracker
<http://bugs.python.org/i
Adam Olsen added the comment:
The real, OS signal does not get propagated to the main thread. Only
the python-level signal handler runs from the main thread.
Correctly written programs are supposed to let select block
indefinitely. This allows them to have exactly 0 CPU usage, especially
Adam Olsen added the comment:
You forget that the original report is about ctrl-C. Should we abandon
support of it for threaded programs? Close as won't-fix?
We could also just block SIGINT, but why? That means we don't support
python signal handlers in threaded programs (signa
Adam Olsen added the comment:
A better solution would be to block all signals by default, then unblock
specific ones you expect. This avoids races (as undeliverable signals
are simply deferred.)
Note that readline is not threadsafe anyway, so it doesn't necessarily
need to allow calls
Adam Olsen added the comment:
See also issue5127.
--
nosy: +Rhamphoryncus
___
Python tracker
<http://bugs.python.org/issue7663>
___
___
Python-bugs-list mailin
Adam Olsen added the comment:
Points against the subclassing argument:
* We have a null-termination invariant. For byte strings this was part of the
public API, and I'm not sure that's changed for unicode strings; aren't you
arguing that we should maximize how much of our im
Adam Olsen added the comment:
On Sun, Jan 10, 2010 at 14:59, Marc-Andre Lemburg
wrote:
> BTW, I'm not aware of any changes to the PyUnicodeObject by some
> fastsearch implementation. Could you point me to this ?
/* We allocate one more byte to make sure the string is Ux
Adam Olsen added the comment:
The readline API just sucks. It's not at all designed to be used
simultaneously from multiple threads, so we shouldn't even try. Ban
using it in non-main threads, restore the blocking of signals, and go on
with our merry lives.
--
nosy: +Rha
Changes by Adam Olsen :
--
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue1975>
___
___
Python-bug
Adam Olsen added the comment:
issue 960406 broke this as part of a fix for readline. I believe that
was motivated by fixing ctrl-C in the main thread, but non-main threads
were thrown in as a "why not" measure.
msg 46078 is the mention of this. You can go into readlingsigs7.patch
New submission from Adam Olsen :
"destination" is ambiguous. It means opposite things, depending on if
it's the symlink creation operation or if it's the symlink itself.
In contrast, "old" is clearly what existed before the operation, and
"new" is what
Adam Olsen added the comment:
Aye. 2.6 has come and gone, with most or all warnings applied using (I
believe) a different patch. If any future work is needed it can get a
new ticket.
--
status: open -> closed
___
Python tracker
&l
Adam Olsen added the comment:
Fix it at its source: patch your database engine to use the type you
want. Or wrap the list without subclassing (__iter__ may be the only
method you need to wrap).
Obscure performance hacks don't warrant language extensions.
--
nosy: +Rhamphor
Changes by Adam Olsen :
--
nosy: +Rhamphoryncus
___
Python tracker
<http://bugs.python.org/issue9198>
___
___
Python-bugs-list mailing list
Unsubscribe:
Adam Olsen added the comment:
There should be a way to walk the unicode string in Python too. Afaik there
isn't.
--
nosy: +Rhamphoryncus
___
Python tracker
<http://bugs.python.org/i
Adam Olsen added the comment:
I don't have any direct opinions on this, as it is just a bandaid. fork, as
defined by POSIX, doesn't allow what we do with it, so we're reliant on great
deal of OS and library implementation details. The only portable and robust
solution woul
101 - 196 of 196 matches
Mail list logo
