Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le lundi 18 août 2008 à 17:19 +, Brett Cannon a écrit :
> That's also a possibility.
>
> Out of curiosity, what HTTP response should be received?
There shouldn't be an HTTP response at all. If DNS lookup fails,
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>From the discussion on the python-3000, it looks like it would be nice
if sax.parser handled both bytes and unicode streams.
Edward, does your simple fix make sax.parser work entirely well with
byt
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le lundi 18 août 2008 à 19:42 +, Ismail Donmez a écrit :
> Ismail Donmez <[EMAIL PROTECTED]> added the comment:
>
> Ah cool, we might be at the end of multiprocessing problems then I guess
> :-)
Well, not really
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> The same calls to sax read the file correctly on Python 2.5.
What are those calls exactly?
Why is "cp1252" used as an encoding? Is it what is specified in the XML
file? Or do you somehow feed stdin to the SAX parser?
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> I know this is long closed, but no one on the nosy list happens to have
> this fix backported to 2.5, do they? :)
I think that at the time no one was sure the patch was 100% harmless. It
also subtly changes the behaviour of
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11145/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11147/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11148/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11151/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Ok, then xml.sax looks rather broken.
(by the way, can you avoid sending HTML emails? each time you send one,
the bug tracker attaches a file names "unnamed". I've removed all 4 of
them now.)
_
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
For what it's worth, this is documented in
http://docs.python.org/dev/library/multiprocessing.html#windows
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a preliminary patch implementing slices with getitem, adding a
bunch of tests, and fixing a few problems.
As stated elsewhere I only bother to test with simple byte buffers. The
semantics of other types of buffers are too fuz
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is another patch with setitem too (integers and slices supported),
and further tests.
Added file: http://bugs.python.org/file11156/mem2.patch
___
Python tracker <[EMAIL PROTECTE
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This patch fixes a crash in the codecs module.
However, memoryview should also support comparisons (just == and !=)
with bytes/bytearray objects (or any buffer-enabled objects), otherwise
utf-8-sig produces wrong values (and there
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a patch to support comparisons of memoryview objects with other
objects offering the buffer interface. Two objects are equal if their
buffers have the same characteristics and compare equal bytewise.
It also improves the t
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Adding some comparison tests.
Added file: http://bugs.python.org/file11159/mem5.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Ok, please disable the test for now, I have more important things to do
for the beta :)
--
components: +Tests
priority: critical -> high
type: -> behavior
versions: +Python 2.6
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
(the fix is probably trivial, it involves dividing sys.maxsize by the number of
bytes of an unicode character, something like:
width = sys.getsizeof("a") - sys.getsizeof("")
alloc = lambda: u&
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
It seems to me that the patch has been applied. Can this be closed?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This should has been fixed by Amaury as part of another patch (the one
which is tested for in test_raiseMemError).
Could you try again?
--
nosy: +pitrou
___
Python tracker <[EMAIL
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
As a reminder, I want to mention that PEP 3118 itself needs to be
updated (see #3560).
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Well, the PEP needs some love generally speaking; many things are un- or
under-specified (and I don't understand better than anyone else). As for
docs, there aren't any ("grep -ri memoryview Doc/" yields only the
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Fixed in r65860. Someone should check the docs though (at least try to
generate them, and review my changes a bit since English isn't my mother
tongue).
--
resolution: accepted -> fixed
status:
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This patch changes all bytearray results (in indexing, tobytes()) to
bytes, and adds the implementation the tolist().
Note: the tolist() implementation only handles one-dimensional byte
buffers. It will have to be re-written using the
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Please review at http://codereview.appspot.com/3004
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 16 août 2008 à 05:50 +, Ismail Donmez a écrit :
> This seems to break test_unicode on MacOSX 10.5.4,
>
> test_unicode
> python(80320,0xa0659fa0) malloc: *** mmap(size=2147483648) failed (error
> code=1
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Do you have a simple code sample to showcase that?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Roger Upole <[EMAIL PROTECTED]> added the comment:
>
> Py_BEGIN_ALLOW_THREADS
> PyErr_SetString(PyExc_SystemError, "bork bork bork");
> Py_END_ALLOW_THREADS
Well, if you start using all k
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
I have the following deterministic failure on py3k:
test test_multiprocessing failed -- Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/test_multiprocessing.py",
line 932, in test_dict
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Committed in r65886 after review from Benjamin and some small fixes.
I'm downgrading this to critical for the remains of the memoryview API
(support for more format types, multi-dimensional objects...). Perhaps
those remainings w
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Thanks a lot Mark!
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2834>
___
___
Python
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> I also noticed a crash in PyErr_SetObject(): in block ,
> tstate->exc_value value may changes and so it's possible that
> tstate->exc_value becomes NULL.
How can tstate->exc_value become NULL at that
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This is certainly a consequence of #3187, which is very high priority
but also very difficult to find a satisying solution to.
--
nosy: +pitrou
resolution: -> duplicate
status: open
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
See #3616 for a consequence of this.
--
nosy: +haypo
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
superseder: -> os.listdir can return byte strings
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Well, this is not a bug in itself. Memoryview objects are designed to
give access to a memory area backed by another object - they don't "own"
the memory by themselves (in the sense that you e.g. own a reference to
a Py
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
priority: -> normal
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3608>
___
___
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Interesting, but it should be discussed on the mailing-list first.
Also, since this is a new feature, it must be retargeted to 2.7/3.1.
--
nosy: +pitrou
priority: -> normal
type: -> feature request
versions: +Python 2.7
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
There's an unquote()-related failure in #3613.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The encodestring() function is refered to in the docs as "the legacy
interface". Perhaps it should be simply deprecated in 3.0?
--
assignee: -> georg.brandl
components: +Documentation
nosy: +georg.brandl, pitrou
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Yes indeed. We could use an RLock to avoid the problem but RLock's are
damn slow since they are written in pure Python (see #3001). Rewriting
the critical parts of RLock (constructor, acquire(), release(),
__enter__(), __exit__())
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Wow, that was quick. Did you try to replace threading.RLock with your
implementation, and run the tests?
By the way:
> - acquire() method argument "blocking" is not a keyword
> - In the Python version, RLock._release
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon STINNER Victor <[EMAIL PROTECTED]>:
>
> > How can tstate->exc_value become NULL at that point? [error.c:86]
> > Could you investigate?
>
> PyEval_CallObject(exception, args) may calls PyErr_SetObject
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I retract what I said above. PyErr_SetObject() and friends only change
tstate->curexc_* variables, not tstate->exc_*.
The former (tstate->curexc_*) contain the current, pending (uncaught)
exception state of the thread. The
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
[...]
>
> This exception may comes from PyObject_IsSubclass() which calls
> PyObject_GetAttr(cls, "__subclasscheck__").
If you look at the code for PyObject_IsSubclass(), there is a pair of
PyErr_Fetch / P
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> As background, what I need is an equivalent of
> PyBuffer_New(size), which creates an object that manages its
> own buffer memory, and is not based on another object at all.
Well, you can create either a bytes or bytearray
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Gregory, would you have an advice on #3618?
--
versions: -Python 2.6, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> The problem comes when PyErr_SetObject triggers garbage collection which
> runs python code (finalizers...).
Mmmh, normally this shouldn't change the value of tstate->exc_value once
that Python code returns. That'
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
And if it doesn't work, try the following instead:
if (why == WHY_EXCEPTION) {
PyObject *tmp1, *tmp2, *tmp3;
tmp1 = tstate->exc_type;
tmp2 = tstate->exc_value;
tmp3 = tstate->exc_trace
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon STINNER Victor <[EMAIL PROTECTED]>:
> IMHO, the best solution is to create such class:
>
> class Filename:
> def __init__(self, orig):
> self.as_bytes = orig
> self.as_str = myforma
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
With immutable types, you must use __new__ instead. Passing the
arguments to __init__ is too late since the object is immutable and it
has already been built in memory, thus you can't initialize it with
another value.
>&g
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon STINNER Victor <[EMAIL PROTECTED]>:
>
> So if we consider that RLock is fast enough (see my C version of RLokc
> in #3001), we can use RLock instead of Lock to avoid this issue. Here
> is a patch to use RLock an
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> * bytes parent class "class Filename(bytes): ..." -> that's the
> current implementation
I don't think that makes sense (especially under Windows which has Unicode file
APIs). os.listdir() and friends s
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The error is in the bytecode verifier and also occurs with 2.6.
(perhaps a good reason not to backport it to 2.5 :-))
--
nosy: +gvanrossum, pitrou
versions: +Python 2.6
___
Python tracker &
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The following expression is sufficient to reproduce the bug:
re.compile("(?P)(?(quote))")
___
Python tracker <[EMAIL PROTECTED]>
<http://
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
This is a failure that seems to occur quite often (always?) on the
Solaris buildbot:
==
FAIL: test_invalid_inputs (test.test_float.HexFloatTe
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
(FWIW, I just ran Misc/find_recursion_limit.py on a 32-bit Windows box.
With 2.6 I get 5900.
With 3.0 I get 9000.
So the good news is that 3.0 seems to be less stack-hungry :-))
___
Python t
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Mark, that check looks fragile:
+IS32BIT = sys.maxint == 0x7fff and "64 bit" not in sys.version
Why don't you check for sys.maxsize instead? By construction,
sys.maxsize should give you the pointer widt
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The failure happens even when test_smtplib runs before both
test_asyncore and test_asynchat (*). So the latter can't be the culprit.
(*)
http://www.python.org/dev/buildbot/3.0.stable/sparc%20Debian%203.0/builds/419/
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
assignee: -> pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3601>
___
___
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> If Filename has no parent class but is convertible to bytes(), os
> functions requires no change and so we can fix it before final 3.0 ;-)
This sounds highly optimistic.
Also, I think it's wrong to introduce a strin
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Thomas, the bytes object is not broken anymore with respect to the
buffer API, but it depends which buffer API you are talking about :-) I
hope it is the new, 3.0 one.
--
nosy: +pitrou
___
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
For what it's worth, py3k has a subtler recursion checking algorithm
which would probably fix this problem if backported properly. See
_Py_CheckRecursiveCall() in ceval.c (lines 462+), and especially the
role played by the tstate-
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Well, the standard recursion limit is precisely there to guard against
segfaults when blowing up the C stack, so if you make the recursion
limit much larger, it's quite normal to get segfaults.
Therefore, I don't think th
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
On a Windows box, I manage to make the following script reliably hang on
a non-debug build of beta3. This can be a good base for further diagnosing.
def f():
class Bug:
def __del__(self):
1/0
import gc
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Haypo, this is a separate bug I think. Please open a new ticket :)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le jeudi 21 août 2008 à 21:12 +, Mark Dickinson a écrit :
> For now, it just seems simplest to replace the isxdigit call with an
> explicit check for the ASCII 7-bit characters '0' through '9', 'a&
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Isn't it a new feature and, therefore, should wait for 3.1?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le jeudi 21 août 2008 à 21:26 +, Mark Dickinson a écrit :
> Here's a patch. I'm reasonably confident that this should fix the
> problem, but I don't have a Solaris machine to test it on.
>
> If anyo
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Thanks, Tony!
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Well, it's definitely a bug, or inconsistency, if you like, between
> cPickle and pickle.
There is clearly a problem with cPickle stack consumption and a new bug has been
opened for this in #3640.
What I don't agree
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Mark, your patch is ok to me. You can check it in.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Unless someone thinks it's somehow release-critical, I'm retargetting
this to 2.7/3.1.
--
nosy: +pitrou
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0
___
Python
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
keywords: +needs review, patch
priority: -> release blocker
versions: +Python 2.6, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
In my opinion this is a bug in cPickle. It is completely wrong to
consume more than 3KB of stack space for each recursion level, and it
should be fixed.
--
components: +Library (Lib)
priority: -> releas
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Guido, do we retarget the rest of this to 3.1? It sounds more reasonable
to me.
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Should this be a release blocker?
--
type: feature request -> behavior
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3101>
___
___
Python
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
A sensible solution would be to put all the memoryview / buffer API
stuff in the same standalone file (e.g. memoryobject.c), rather than
having half of it dumped in abstract.c.
___
Python tracker &
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Agreed with Amaury, it's not PyErr_SetObject's job to try to
save/restore the tstate->exc_* variables. We'll probably have to live
with the small context-losing glitches in 3.0.
For 3.1, a radical solution would b
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hmm, answering to myself, I don't think dropping exception normalization
would solve the problem, it would just let it occur in a different place...
___
Python tracker <[EMAIL PRO
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Sometimes
> encoding problems in Python are driving me mad.
The thing is, they are not "encoding problems in Python", they are
encoding problems in the outside world. Python cannot know magically
which encoding is us
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Seems fixed on 2.6.
Python 2.6b3+ (trunk, Aug 22 2008, 11:27:51) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> imp
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is an additional patch which adds a cpickle test to
Misc/find_recursion_limit.py. It helps show that Amaury's patch does fix
the issue. +1 for applying it.
Added file: http://bugs.python.org/file11219/find_recursion_
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
There are still some instances of get_name() in threading.py itself,
which gives errors like the following:
Unhandled exception in thread started by >
Traceback (most recent call last):
File "/home/antoine/cpython/cpickle/Li
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 23 août 2008 à 01:26 +, Mark Hammond a écrit :
> cpickle.patch does make test_cpickle pass for me. FWIW,
> find_recursionlimit.py now causes a segfault on 32 and 64bit Windows
> (the comments imply a MemoryEr
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This patch is ok on both UCS2 and UCS4 builds (on 32-bit machines).
Someone should test it on a 64-bit machine.
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file11230/memerror2
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The patch should probably used PyErr_Format() followed by
PyErr_WriteUnraisable().
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hi,
Making Py_buffer INCREF the original object is IMO the right thing to
do, because in most cases letting the original object disappear means
the memory region will become invalid as well. If you don't want the
INCREF, you can p
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
priority: -> normal
type: -> behavior
versions: +Python 2.6, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 24 août 2008 à 09:18 +, Amaury Forgeot d'Arc a écrit :
> If FillInfo() increfs the given object, every object should have a
> bf_releasebuffer that decrefs it.
There's no need for that, PyBuffer_Release(
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
priority: -> normal
versions: +Python 2.7, Python 3.1 -Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3663>
___
___
Python
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
- Check that it also works for chars > 0x (even in UCS2 builds, at
least when the chars are not part of [character range])
- What does happen with e.g. [\U0001-\U00010001] on an UCS build?
--
nosy
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
(in the last sentence, I meant UCS2. Sorry)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hi Travis,
Glad you're back!
> I'm not convinced that Py_buffer should have grown a link to an object.
> I think this is a shortcut solution due to misuse of the protocol that
> may have unfortunate consequences.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Great. It would be nice if you could at least do a quick review what has
been committed though.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> I don't know the buffer code to know if this is the correct fix.
> However, it fixes the problems and that's probably good enough for now.
> If you can get someone familiar with the buffer code to review, that
&
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Viktor?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3160>
___
___
Python-bugs
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3160>
___
_
4201 - 4300 of 16792 matches
Mail list logo