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/issue1
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.
--
___
Python
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:
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
signals.
The fact
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 rha...@gmail.com 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
Adam Olsen rha...@gmail.com added the comment:
As far as I know.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1441
___
___
Python-bugs-list
Adam Olsen rha...@gmail.com 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 rep...@bugs.python.org
http
Adam Olsen rha...@gmail.com 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 would
Adam Olsen rha...@gmail.com added the comment:
There should be a way to walk the unicode string in Python too. Afaik there
isn't.
--
nosy: +Rhamphoryncus
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9200
Changes by Adam Olsen rha...@gmail.com:
--
nosy: +Rhamphoryncus
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9198
___
___
Python-bugs-list
Adam Olsen rha...@gmail.com added the comment:
Why aren't you using 64-bit hashes on 64-bit architectures?
--
nosy: +Rhamphoryncus
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
Adam Olsen rha...@gmail.com added the comment:
I assume you mean 63. ;)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8188
___
___
Python-bugs
Adam Olsen rha...@gmail.com 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))'
100 loops, best of 3
Adam Olsen rha...@gmail.com added the comment:
On Sun, Jan 10, 2010 at 14:59, Marc-Andre Lemburg
rep...@bugs.python.org 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com added the comment:
That's fine, but please provide a link to the new issue once you create it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3999
Adam Olsen rha...@gmail.com added the comment:
Nope, no access.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1722344
___
___
Python-bugs-list
Adam Olsen rha...@gmail.com added the comment:
On Mon, Oct 5, 2009 at 03:03, Marc-Andre Lemburg rep...@bugs.python.org 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
Adam Olsen rha...@gmail.com added the comment:
On Mon, Oct 5, 2009 at 12:10, Marc-Andre Lemburg rep...@bugs.python.org 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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 rep
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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 ugly
Adam Olsen rha...@gmail.com 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 and global/builtin
Adam Olsen rha...@gmail.com 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
On May 19, 5:05 am, jer...@martinfamily.freeserve.co.uk wrote:
Thanks for explaining a few things to me. So it would seem that
replacing the GIL with something which allows better scalability of
multi-threaded applications, would be very complicated. The paper by
Jesse Nolle which I referenced
On Apr 17, 5:30 am, Tim Wintle tim.win...@teamrubber.com wrote:
On Thu, 2009-04-16 at 21:44 -0700, Adam Olsen wrote:
The Wayback Machine has 150 billion pages, so 2**37. Google's index
is a bit larger at over a trillion pages, so 2**40. A little closer
than I'd like, but that's still
On Apr 17, 9:59 am, norseman norse...@hughes.net wrote:
The more complicated the math the harder it is to keep a higher form of
math from checking (or improperly displacing) a lower one. Which, of
course, breaks the rules. Commonly called improper thinking. A number
of math teasers make use
On Apr 17, 9:59 am, SpreadTooThin bjobrie...@gmail.com wrote:
You know this is just insane. I'd be satisfied with a CRC16 or
something in the situation i'm in.
I have two large files, one local and one remote. Transferring every
byte across the internet to be sure that the two files are
On Apr 15, 12:56 pm, Nigel Rantor wig...@wiggly.org wrote:
Adam Olsen wrote:
The chance of *accidentally* producing a collision, although
technically possible, is so extraordinarily rare that it's completely
overshadowed by the risk of a hardware or software failure producing
an incorrect
On Apr 16, 3:16 am, Nigel Rantor wig...@wiggly.org wrote:
Adam Olsen wrote:
On Apr 15, 12:56 pm, Nigel Rantor wig...@wiggly.org wrote:
Adam Olsen wrote:
The chance of *accidentally* producing a collision, although
technically possible, is so extraordinarily rare that it's completely
On Apr 16, 8:59 am, Grant Edwards inva...@invalid wrote:
On 2009-04-16, Adam Olsen rha...@gmail.com wrote:
I'm afraid you will need to back up your claims with real files.
Although MD5 is a smaller, older hash (128 bits, so you only need
2**64 files to find collisions),
You don't need
On Apr 16, 11:15 am, SpreadTooThin bjobrie...@gmail.com wrote:
And yes he is right CRCs hashing all have a probability of saying that
the files are identical when in fact they are not.
Here's the bottom line. It is either:
A) Several hundred years of mathematics and cryptography are wrong.
On Apr 16, 4:27 pm, Rhodri James rho...@wildebst.demon.co.uk
wrote:
On Thu, 16 Apr 2009 10:44:06 +0100, Adam Olsen rha...@gmail.com wrote:
On Apr 16, 3:16 am, Nigel Rantor wig...@wiggly.org wrote:
Okay, before I tell you about the empirical, real-world evidence I have
could you please
On Apr 15, 11:04 am, Nigel Rantor wig...@wiggly.org wrote:
The fact that two md5 hashes are equal does not mean that the sources
they were generated from are equal. To do that you must still perform a
byte-by-byte comparison which is much less work for the processor than
generating an md5 or
On Apr 13, 8:39 pm, Grant Edwards gra...@visi.com wrote:
On 2009-04-13, Peter Otten __pete...@web.de wrote:
But there's a cache. A change of file contents may go
undetected as long as the file stats don't change:
Good point. You can fool it if you force the stats to their
old values
On Apr 8, 8:09 am, George Sakkis george.sak...@gmail.com wrote:
On Apr 7, 3:18 pm, Adam Olsen rha...@gmail.com wrote:
On Apr 6, 3:02 pm, George Sakkis george.sak...@gmail.com wrote:
For example, it is common for a function f(x) to expect x to be simply
iterable, without caring of its
On Apr 6, 3:02 pm, George Sakkis george.sak...@gmail.com wrote:
For example, it is common for a function f(x) to expect x to be simply
iterable, without caring of its exact type. Is it ok though for f to
return a list for some types/values of x, a tuple for others and a
generator for
Adam Olsen rha...@gmail.com 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 rep
New submission from Adam Olsen rha...@gmail.com:
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 the operation creates
On Feb 27, 9:55 am, Falcolas garri...@gmail.com wrote:
If order did matter, and the list itself couldn't be stored in memory,
I would personally do some sort of hash of each item (or something as
simple as first 5 bytes, last 5 bytes and length), keeping a reference
to which item the hash
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Changes by Adam Olsen rha...@gmail.com:
--
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1975
On Feb 23, 7:18 pm, bvdp b...@mellowood.ca wrote:
Gabriel Genellina wrote:
En Mon, 23 Feb 2009 23:31:20 -0200, bvdp b...@mellowood.ca escribió:
Gabriel Genellina wrote:
En Mon, 23 Feb 2009 22:46:34 -0200, bvdp b...@mellowood.ca escribió:
Chris Rebert wrote:
On Mon, Feb 23, 2009 at 4:26
On Feb 21, 10:48 am, a...@pythoncraft.com (Aahz) wrote:
In article 499f397c.7030...@v.loewis.de,
=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= mar...@v.loewis.de wrote:
Yes, I know that. But every concrete representation of a unicode string
has to have an encoding associated with it,
Adam Olsen rha...@gmail.com added the comment:
Antoine, x ^= x4 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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 than the lower ones
Adam Olsen rha...@gmail.com 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
Adam Olsen rha...@gmail.com 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, 0
Adam Olsen rha...@gmail.com 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, 1
Changes by Adam Olsen rha...@gmail.com:
--
nosy: +Rhamphoryncus
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3959
___
___
Python-bugs-list
Adam Olsen rha...@gmail.com added the comment:
I didn't test it, but the patch looks okay to me.
--
nosy: +Rhamphoryncus
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4074
Changes by Adam Olsen [EMAIL PROTECTED]:
--
nosy: +Rhamphoryncus
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3999
___
___
Python-bugs-list mailing
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]
http://bugs.python.org/issue1215
Changes by Adam Olsen [EMAIL PROTECTED]:
--
nosy: +Rhamphoryncus
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4006
___
___
Python-bugs-list mailing
operates in a different monitor. As you say, most C functions are
already thread-safe (reentrant). All I need to do is avoid letting
multiple threads modify a single mutable object (such as a list) at a
time, which I do by containing it within a single monitor (context).
--
Adam Olsen, aka
overhead and
is completely scalable.
--
Adam Olsen, aka Rhamphoryncus
--
http://mail.python.org/mailman/listinfo/python-list
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 code points,
but it no longer
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.python.org/issue3297
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 builds
Changes by Adam Olsen [EMAIL PROTECTED]:
--
components: +Unicode
type: - behavior
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3672
___
___
Python
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 maintenance and development
Changes by Adam Olsen [EMAIL PROTECTED]:
--
nosy: +Rhamphoryncus
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3299
___
___
Python-bugs-list mailing
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
surrogates
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 [EMAIL
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'
Result: True
Len: 1 1
Repr: u'\U00010123' u
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 surrogates
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 this until Py_Finalize can
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 by just replacing
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.python.org/issue874900
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 a long time
Changes by Adam Olsen [EMAIL PROTECTED]:
--
nosy: +Rhamphoryncus
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue874900
___
___
Python-bugs-list mailing
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/browse_frm/thread
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. Any other problems (trac
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_FatalError(Invalid thread state
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 documentation is referring
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 versions), so here's
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
still get it to hang?;
I removed
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:
Macintosh-3:trunk dickinsm$ ./python.exe -m
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 overrun, etc
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 [EMAIL PROTECTED]
http
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). However
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 +, Adam Olsen a écrit :
Passing in e.args is probably sufficient.
I think it's very optimistic :-) Some exception objects can hold
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 exceptions in 2.x
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 performance
sensitive in comparison
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 meant only that trivial cycles should be detected
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 behaviour, this is the most natural way to write
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 :
That's still O(n). I'm not so easily convinced it's
Changes by Adam Olsen [EMAIL PROTECTED]:
--
nosy: +Rhamphoryncus
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3155
___
___
Python-bugs-list mailing
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(self-statement,
self
1 - 100 of 213 matches
Mail list logo
