Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Thinking about this, I realized that an exception can become its own
context if it is explicitly re-raised in its except handler (with "raise
variable", not bare "raise").
Not a critical bug, but it should be fixed
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Apparently the error can happen in test_pickling:
test_pickling (__main__.WithProcessesTestPicklingConnections) ...
Process Process-24:
Traceback (most recent call last):
File "/home/antoine/py3k/traceback/Lib/multiprocessing
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Oh, in another regrtest run, test_multiprocessing just hanged without
eating any CPU, this is what it printed after I pressed Ctrl-C:
test_multiprocessing
Process PoolWorker-5:4:
Traceback (most recent call last):
File "/home/a
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The following patch fixes it, which is somehow a bit scary...
--
keywords: +patch
Added file: http://bugs.python.org/file10629/3114.patch
___
Python tracker <[EMAIL PROTECTE
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
And a test.
Added file: http://bugs.python.org/file10630/test_3114.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Adam is right, we should use three temporaries so that the tstate is
consistent when the former values are DECREf'ed. I'll produce a patch
later today, unless someone beats me to it.
__
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
PS: I don't think this is "release blocker" anymore.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 15 juin 2008 à 13:18 +, Robert Schuppenies a écrit :
> If I understand configure correctly, PY_UNICODE_TYPE is only set when
> a type matching the size of $unicode_size is found. And this is set to
> either
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 15 juin 2008 à 15:21 +, Jesse Noller a écrit :
>
> For Beta 1 I am proposing a reduced test suite to remove the more
> unreliable tests.
This would be nice (especially the tests which make regrtest hang).
I a
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a patch against the current py3k, along with a stricter test
(which fails both with the previous patch, and the original unpatched
py3k). I've also checked the svnmerged test_lib2to3 doesn't crash.
Added file: http:/
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +effbot, lemburg, loewis, pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3112>
___
__
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Does anyone know why there is the following test in pythonrun.c:
http://hg.pitrou.net/public/py3k/py3k/file/c143699d8dee/Python/pythonrun.c#l1346
Can PyErr_Display be called with something else than a PyException in
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Two other questions:
1) Should I expose a PyErr_DisplaySingle API to display an exception
without chaining?
2) Should PyErr_Display return an integer value (0: success, -1:
failure) rather than void as it currentl
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a draft patch for those who want to take a look.
(it works but the final cleanup is waiting for the API decisions
mentioned above)
--
keywords: +patch
Added file: http://bugs.python.org/file10656/exc_reporting
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I agree with this bug entry. Also, since pages are usually long, if the
left nav bar is really to be useful it should use some "fixed"
positioning in the CSS (that is, doesn't move when the rest of the page
is scroll
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Yet another question. There is a slight discrepancy between tracebacks
generated by the builtin-reporting and tracebacks generated by traceback.py.
With built-in reporting:
Traceback (most recent call last):
File "", li
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 21 juin 2008 à 16:40 +, sebastian serrano a écrit :
> sebastian serrano <[EMAIL PROTECTED]> added the comment:
>
> Running with python -O the timing gets a little closer between Lock and
> RLock. Th
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 22 juin 2008 à 07:04 +, Adam Olsen a écrit :
> Adam Olsen <[EMAIL PROTECTED]> added the comment:
>
> * cause/context cycles should be avoided. Naive traceback printing
> could become confused,
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. However, I
> hadn't read your patch, so I didn't realize you already knew of a way
> to create a non
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 it.
> Conceptually, there shouldn't be a cycle
I agree your example is not far-fetched. How about av
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 cheap enough.
O(n) when n will almost never be greater than 5 (and very often equal to
1 or 2), and w
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 22 juin 2008 à 20:40 +, Adam Olsen a écrit :
> > How do you duplicate an instance of an user-defined exception? Using
> an
> > equivalent of copy.deepcopy()? It will probably end up much more
> &g
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le lundi 23 juin 2008 à 06:16 +, Adam Olsen a écrit :
> Failure doesn't have an args tuple and doesn't subclass Exception (or
> BaseException) - it already needs modification in 3.0. It's heaped
> full of
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Indeed, this is not a bug, although it can be misleading.
Generally, if you test for None, it is better to write "if x is None",
it is at the same time more accurate, more explicit for someone reading
your code, and also exec
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
What is the bug actually? "for k in s" is defined to work on any
iterable, not only on sequences. And "iterable" is clearly defined, it's
sufficient to check whether s.__iter__ exists or whether iter(s) succee
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is the final patch. Features:
- cleanup of internal APIs
- standardize traceback indentation (source lines are prefixed with 4
spaces)
- break cycles along the context chain (a synthetic benchmark with a
6-level deep context chain
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> The escaped regexp is not utf-8 (why should it be?)
I suppose it is annoying if you want to print the escaped regexp for
debugging purposes.
Anyway, I suppose someone should really decide if improving re.escape is
worth it, a
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> You're right: probably not. Would be great to have the test on the
> Py2.x version as well - to see the difference in performance.
I'm not following you, what test are you talking about?
The patch is only about r
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This new patch avoids using temporary variables named "new", it also
adopts the "do { ... } while (0)" idiom for definition of the macros.
Added file: http://bugs.python.org
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Same here, re.LOCALE doesn't circumvent the problem.
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Uh, actually, it works if you specify re.UNICODE. If you don't, the
getlower() function in _sre.c falls back to the plain ASCII algorithm.
>>> pat = re.compile('Á', re.IGNORECASE | re.UNICODE)
>>> p
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 28 juin 2008 à 20:12 +, Raymond Hettinger a écrit :
> Raymond Hettinger <[EMAIL PROTECTED]> added the comment:
>
> -1 on the new macros. The mnemonic doesn't work for me and the example
> code
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 28 juin 2008 à 22:20 +, Guido van Rossum a écrit :
> Finally, is there a use case of re.LOCALE any more? I'm thinking not.
It's used for locale-specific case matching in the non-unicode case. But
it loo
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
Some patterns can be compiled in str form but not in bytes form. This
was overlooked because the test suite wasn't correctly adapted for py3k:
>>> re.compile('[\\1]')
<_sre.SRE_Pattern object at
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a patch fixing both the bug and the test suite.
--
keywords: +patch
Added file: http://bugs.python.org/file10765/rebytes.patch
___
Python tracker <[EMAIL PROTECTE
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
Lib/encodings/idna.py claims to do the following when `input` is a
string object (lines 183-184, and see comment line 178: "IDNA allows
decoding to operate on Unicode strings, too"):
# Force to bytes
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a preliminary patch which doesn't remove re.LOCALE, but adds
TypeError's for mistyped matchings, a ValueError when specifying
re.UNICODE with a bytes pattern, and implies re.UNICODE for unicode
patterns. The test suite
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10767/reunicode.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10768/reunicode.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
The following says it all:
>>> 1+1 is 2
True
>>> int('2') is 2
False
>>> int(b'2') is 2
False
--
components: Interpreter Core
messages: 68947
nosy: pitrou
severity: normal
statu
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This new patch also introduces re.ASCII as discussed on the mailing-list.
Added file: http://bugs.python.org/file10777/reunicode2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Improved patch which also detects incompatibilities for "(?u)".
Added file: http://bugs.python.org/file10778/reunicode3.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 29 juin 2008 à 17:43 +, Martin v. Löwis a écrit :
> For long, it's much more tricky, as no C type can be used to store the
> intermediate result. So instead, PyLong_FromString already allocates a
> suf
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 29 juin 2008 à 21:52 +, Martin v. Löwis a écrit :
> Can you propose an implementation strategy that doesn't create the
> object, yet still avoids duplication of large chunks of code?
If by "duplicatin
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Some remarks:
- I don't think doing a bulk backport of ceval.c is the right approach.
Instead, each functionality should be considered and backported
independently, if desired.
- Guido already said that 3.0 should be mostly
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Interesting. Why do you use a deque? You never seem to prepend or pop
from the beginning of it, so using a plain list should be as fast.
Also, your patch should add one or several unit tests to enforce the new
behaviour.
-
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Gregory, your patch probably deserves checking in, it doesn't seem to me
there is any concern preventing you to do that.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> I agree with this patch and will commit it later this weekend if I hear
> no objections.
Gregory, it seems there has been no objection on the ML :-)
--
nosy: +pitrou
___
Python tra
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Potential reviewers, let's make life easier for you:
http://codereview.appspot.com/2448
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
While we are at it, should we keep this one as is?
« Python3000
A mythical python release, not required to be backward compatible,
with telepathic interface. »
Not so mythical after all... missing the telepathic interface
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hi,
Le mercredi 02 juillet 2008 à 20:43 +, Aaron Gallagher a écrit :
> Aaron Gallagher <[EMAIL PROTECTED]> added the comment:
>
> Ah, I didn't know that a list would be as fast for appending and popping.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Martin, you seem to be the author of that module.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Wow...
Isn't this kind of code supposed to ask for a buffer on the bytearray
object, together with an optional lock on it (or something like that)?
--
nosy: +pitrou
___
Python trac
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Pickle is a solution only if you accept the target format to be opaque,
which is not what you are looking for usually.
Once again I just had to write the cumbersome:
junk_len = 1024
junk = (("%%0%dX" % junk_len) % ra
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
If I try to follow the chain the consequences:
- all PyArg_ParseTuple("s#") calls that release the GIL afterwards
should be re-written to use another API (which one I don't know exactly,
but hopefully the appropriate
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
By the way, here's a more reliable way to make it crash (on my Linux
machine):
import bz2, threading
bz2c = bz2.BZ2Compressor()
# Span at least a whole arena (256KB long)
junk_len = 512 * 1024
junk = b"a" * junk_len
b
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Now I've just discovered there is the same problem with the
array.array() type (see following code).
import bz2, threading, array
bz2c = bz2.BZ2Compressor()
# Span at least a whole arena (256KB long)
junk_len = 512
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
In the latest py3k versions, rlcompleter doesn't work anymore. Pressing
the tab key (with tab-completion enabled) doesn't produce anything on
screen.
--
components: Library (Lib)
messages: 69293
nosy: pitrou
severit
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 05 juillet 2008 à 20:32 +, Benjamin Peterson a écrit :
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Antoine, can you try it before r64671?
Bingo, the regression occ
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This new patch adds re.ASCII in all sensitive places I could find in the
stdlib (except lib2to3 which as far as I understand is maintained in a
separate branch, and even has its own copy of tokenize.py...).
Also, I didn't get a
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a fix (in addition to the one you already committed).
--
keywords: +patch
Added file: http://bugs.python.org/file10820/rlcompleter.patch
___
Python tracker <[EMAIL PROTECTE
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
http://codereview.appspot.com/2439
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2834>
___
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
The declaration for PyObject_ReleaseBuffer (in Include/abstract.h) has
the following comments attached to it. But the part about the return
value is wrong since the function is defined as returning void. Also,
PEP 3118 says it
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
In the py3k SVN branch I can see the following link. I suppose it is a
mistake?
$ ls -la Mac/IDLE/IDLE.app/Contents/MacOS/Python
lrwxrwxrwx 1 antoine antoine 92 2008-07-01 22:33
Mac/IDLE/IDLE.app/Contents/MacOS/Python ->
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
Astonishingly, PyExc_BufferError is defined in pyerrors.h but it is
defined nowhere. Consequently, any piece of code raising a
PyExc_BufferError will cause the interpreter to crash as soon as it
tries to do something with the exc
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 05 juillet 2008 à 22:20 +, Martin v. Löwis a écrit :
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> I believe the 2.6 s# processing works correctly; the error is in the
> bytearray objec
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The following patch fixes it.
--
keywords: +patch
nosy: +teoliphant
Added file: http://bugs.python.org/file10821/buffererror.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
For reference, here is a proof-of-concept patch which shows how to fix
the bytearray crasher above (it raises a BufferError instead).
Added file: http://bugs.python.org/file10822/bzcrash.py
___
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10822/bzcrash.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10823/bzcrash.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le vendredi 11 juillet 2008 à 12:12 +, Amaury Forgeot d'Arc a
écrit :
> I think there is a problem when the source file cannot be opened (a .pyc
> without its .py): the four spaces are printed, but not the line, and the
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le vendredi 11 juillet 2008 à 22:18 +, Amaury Forgeot d'Arc a
écrit :
> I committed r64881, which invalidates your patch a bit :-|
Apparently you committed in trunk rather than py3k? Could you svnmerge
into py3k as well?
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Raymond, would you want to take a look?
--
nosy: +rhettinger
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a new patch incorporating Amaury's better indentation fix for
tracebacks. It should be ready for consumption (all the tests pass).
And for the code review junkies: http://codereview.appspot.com/2448
Added
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
With the latest py3k, some tests fail when run in debug mode:
- test_distutils fails with the following message:
FAILED (errors=1)
Traceback (most recent call last):
File "Lib/test/test_distutils.py", line 17, in
te
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
On another machine, with another distro (Debian stable) and another gcc
version (4.1.2 instead of 4.3.1), I even get a segmentation fault on
test_distutils:
$ ./python Lib/test/test_set.py
test_add (__main__.TestSet) ... ok
te
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Antonine, do you have a patch address the review comments?
Yes, although I've forgotten to upload it here - you will find it at
http://codereview.appspot.com/2448
PS: it is Antoin
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> I still don't like the _after_fork() implementation. Its O(n) where n
> == number of threads the parent process had.
It may be O(n) but the inner loop looks very cheap. Even with n == 1000
I'm not sure it would make
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Why was 1000 chosen in the first place? If it's just an arbitrary value
then we can bump it to 4000 so that people don't get bad surprises when
upgrading their Python.
> This looks more
> like the interpreter is adding
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
It would be nice to test under Windows first, if you can.
Also, this bug entry should stay open until we discuss the remaining
details.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon "Gregory P. Smith" <[EMAIL PROTECTED]>:
>
> To answer Antoine Pitrou's question about using the old ident vs the new
> _get_ident(). I don't know if the forked process will have the same
>
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
How about simply doing sys.path_importer_cache.clear() at the right
point in setup.py? I don't think the performance loss would be
overwhelming...
--
nosy: +pitrou
___
Python trac
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Has a resolution been made on this?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
If nobody objects I'll commit Alexandre's patch in a few days (after
beta 2 though).
___
Python tracker <[EMAIL PROTECTED]>
<http://
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a small script that shows various possibilities depending on how
object creation is done, and here is the output with the trunk:
rec1 stopped at 1000
rec2 stopped at 1000
rec3 stopped at 500
rec4 stopped at 334
rec5 stopped
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
priority: -> high
versions: +Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
This is a regression caused by #449227. When typing e.g. "int." and then
pressing tab, none of the int members is proposed. It worked until just
before r64664.
--
components: Library (Lib)
messages: 69905
nosy
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This issue caused a regression in #3396.
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
keywords: +patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3390>
___
__
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon "Martin v. Löwis" <[EMAIL PROTECTED]>:
>
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> I don't understand the second loop (where n is given). If n is given,
> the
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon Facundo Batista <[EMAIL PROTECTED]>:
>
> Then I wrote "int". Then I pressed TAB. Nothing happened. I pressed TAB
> again, and the following appeared:
>
> >>> int
> int( intern(
Th
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le lundi 21 juillet 2008 à 21:18 +, Martin v. Löwis a écrit :
> IIUC, a read of the full requested size would achieve exactly that: on a
> non-blocking stream (IIUC), a read will always return
> min(bytes_available, bytes_r
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> It also just "feels right", to me; an attempt to convert a nan
> to an integer should not pass silently.
I have the same gut feeling.
--
nosy: +pitrou
___
Python tra
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
priority: -> high
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +teoliphant
priority: -> normal
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I think the fix is trivial enough. Committed in r65185.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Fixed in r65186
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> When I revised the patch I had a weak understanding of nonblocking I/O.
> I thought the "exponential" reads were for nonblocking I/O, but I see
> now that is non-sense.
Fine, so it will make the patch simpler.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Would someone object to committing this before beta3?
For clarity I would first commit the rewrite of test_locale to use
unittest, and then the fix for the thousands separator bug.
--
priority: -&g
3901 - 4000 of 16792 matches
Mail list logo
