Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This is very interesting, although it should probably go through
discussion on python-dev since it involves integrating a big chunk of
external code.
--
components: +Interpreter Core
nosy: +pitrou
priority: -> normal
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hi,
> Sadly, this isn't quite as easy as it would seem.
You are right, I was overly optimist when thinking about this.
> Offering this ability in the momoryview object would be very
> interesting, though I'm not
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le vendredi 08 août 2008 à 21:44 +, Josiah Carlson a écrit :
> Josiah Carlson <[EMAIL PROTECTED]> added the comment:
>
> In order for MemoryView to know what bytes it is pointing to in memory,
> it (generally
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I can't reproduce, your code snippet works fine. What Python version is it?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Perhaps. I'm under Linux.
However, at the end of the file_read() implementation in fileobject.c,
you can find the following lines:
if (bytesread != buffersize)
_PyString_Resize(&v, bytesread);
Which means that the stri
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le vendredi 08 août 2008 à 22:46 +, Martin v. Löwis a écrit :
> Instead, Python's own memory allocate (obmalloc) should be changed to
> directly use the virtual memory interfaces of the operating system (i.e.
> mmap),
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 09 août 2008 à 11:26 +, Andrew Dalke a écrit :
> Mind you, I also get the problem on FreeBSD 2.6 so it isn't Darwin
> specific.
Darwin and the BSD's supposedly share a lot of common stuff.
But FreeBSD 2
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Any updates ? The py3k list is also very silent since the
> week-end...Thanks!
Your two patches look good, I suppose either Alexandre or I will commit
them soon.
You shouldn't to worry when you don't get a reply imm
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hi Viktor,
It's complicated for me to test under Windows right now, but your
snippet looks buggy:
script_data = open(self.pre_install_script, "r").read()
cfgdata = cfgdata + script_data + b&quo
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
locale.getpreferredencoding() should certainly not crash but the
question remains of what should be the outcome. I can see several
possibilities:
(1) return the empty string
(2) return None
(3) return "ascii" (!!)
(4) ra
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
versions: +Python 2.6, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This is already fixed in the trunk (which will become Python 2.6).
--
nosy: +pitrou
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Fixed in r65609. Thanks for the report and for the patch!
--
nosy: +pitrou
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hmm, I suppose that while the filename is latin1-encoded,
Py_FileSystemDefaultEncoding is "utf-8" and therefore os.listdir fails
decoding the filename and falls back on returning a byte string.
It was acceptable in Python 2
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le samedi 09 août 2008 à 17:28 +, Martin v. Löwis a écrit :
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> >> Instead, Python's own memory allocate (obmalloc) should be changed to
>
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Raghuram, your patch looks good to me. I'll try to test it under Windows
soon.
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
priority: -> critical
type: -> behavior
versions: +Python 3.1 -Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 10 août 2008 à 07:05 +, Matt Giuca a écrit :
> I don't think it's worth the extra code bloat and performance hit just
> to implement a feature whose only use is producing invalid URIs (since
> URIs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Do you really need to know the encoding of the pre_install_script? Isn't
it sufficient to open it in binary mode instead?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Patch works under Windows.
--
assignee: -> pitrou
priority: -> high
versions: +Python 2.6, Python 3.0 -Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Ok, it's a little more complicated than that, because the
pre-install-script must have its newlines converted, otherwise the
installer refuses to run it. Here is a working patch. Viktor, do you
want to give it a try?
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The last beta is arriving soon. We need to go ahead on this, or retarget
it for 2.7/3.1.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1179>
___
___
Python
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
msilib hasn't been updated for py3k, consequently bdist_msi fails. The
provided patch fixes it, but encoding issues are not worked out (in my
tests, selecting an utf-8 codepage produces unrecognized msi files).
--
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Similar issue but with bdist_msi in #3542.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Fixed in r65644.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Do you have a public URL for such a zip file?
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2394>
___
___
Python
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le lundi 11 août 2008 à 19:58 +, Trent Nelson a écrit :
> +if self._address[0] == '0.0.0.0':
> +self._address[0] = '127.0.0.1'
Please no. If the user asks for 0.0.0.0, either obey o
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I agree that given two similar patches, the one with more tests earns
some bonus points. Also, it seems to me that round-trippability of
quote()/unquote() is a logical and semantic requirement: in particular,
if there is a default en
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le mardi 12 août 2008 à 19:37 +, Bill Janssen a écrit :
> Let's put string_to_bytes and string_from_bytes into the binascii
> module, as a2b_percent and b2a_percent, respectively.
Well, it's my personal opinion,
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon Matt Giuca <[EMAIL PROTECTED]>:
>
> > Now that you've spent so much time with this patch, can't you think
> > of a faster way of doing this?
>
> Well firstly, you could replace Quoter (the
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Selon Antoine Pitrou <[EMAIL PROTECTED]>:
> As for the defaultdict, here is how it can look like (this is on 2.5):
>
(there should be a line here saying "class D(defaultdict)" :-))
> ... def __miss
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Well, I have no idea what the standard setup on posix boxes is - should
> objdump and ldconfig be on $PATH or not?
I think it should try first in $PATH and, if not found, try in /usr/sbin
afterwards. /usr/sbin isn't always
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le mercredi 13 août 2008 à 17:05 +, Bill Janssen a écrit :
> I think it's worth remembering that a very large proportion of the use
> of Python's urllib.unquote() is in implementations of Web server
> framewor
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le mardi 12 août 2008 à 16:15 +, Martin v. Löwis a écrit :
> I also started working on porting it to 3.0, but couldn't complete that
> port yet - the memoryview object doesn't play nicely.
I've seen your recen
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> In any case, the corresponding DECREF *does* exist: in memory_dealloc,
> PyBuffer_Release is invoked, which releases the reference.
I'm a bit confused. In the PyBuffer_Release implementation you
committed, there is
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> The problem happens for files between 2GB and 4GB. I can't really send
> you a link to such a big file. To reproduce the problem, you can
> generate one.
The problem is that the "zip" command fails to create
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hello Matt,
> OK I implemented the defaultdict solution. I got curious so ran some
> rough speed tests, using the following code.
>
> import random, urllib.parse
> for i in range(0, 10):
> str = ''.j
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> If ismount() used os.path.dirname() instead of appending "..", then this
> wouldn't happen.
But it may change the function result if the argument is a symlink to
something (directory or mount point) on anoth
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le jeudi 14 août 2008 à 16:13 +, Martin v. Löwis a écrit :
> Now, when I try to merge that into the 3k branch, test_unicode terribly
> leaks memory :-( It's really frustrating.
If you don't have the time to work
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1424152>
___
___
Python-bugs-list mailin
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file3/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le jeudi 14 août 2008 à 18:52 +, Martin v. Löwis a écrit :
> The patch is really trivial, and attached.
>
> Added file: http://bugs.python.org/file4/refcount.diff
By the way, even without that patch, there is a memor
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a new patch which simply wraps the current BufferedWriter
methods with a lock. It has a test case, and Amaury's example works fine
too.
Martin, do you think it's fine?
(as for BufferedReader, I don't
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le jeudi 14 août 2008 à 19:06 +, Martin v. Löwis a écrit :
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> > By the way, even without that patch, there is a memory leak:
>
> With the patch, th
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Sorry, the roundup e-mail interface ate some lines of code:
>>> b = b''
>>> sys.getrefcount(b)
30
>>> m = memoryview(b)
>>> sys.getrefcount(b)
32
>>> del m
>>> sys.getref
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I'm no expert in recursion checking inside the Python interpreter, but
looking at the code for _Py_CheckRecursiveCall(), I don't think it is a
bug but a feature.
Here how I understand it. When the recursion level exceeds the
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Both BufferedReader and BufferedWriter are now fixed in r65686.
Perhaps someone wants to open a separate issue for TextIOWrapper...
--
resolution: -> fixed
status: open -> closed
__
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Except that it wasn't an infinite loop in 2.5 and isn't in trunk: it
> terminates on overflower's except.
That's because the stated behaviour is only implemented in 3.0 and not
in 2.x. I'm not sure wha
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
PyMemoryViewObject has a "base" field which points to the originator of
the buffer. However, this field has become redundant now that the
Py_buffer struct has received an "obj" field which also points to the
orig
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
See also #3560.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2394>
___
___
Python
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
priority: -> critical
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2271>
___
__
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
priority: -> normal
type: -> behavior
versions: +Python 2.6, Python 3.0 -Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Please note that the flags can be inlined in the pattern instead. That
is, you can begin the pattern with "(?i)" instead of passing re.I in the
flags parameter.
--
nosy: +pitrou
priority: -> normal
type: behavior
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> It's not perfect--another thread could still spawn a subprocess in
> between
Then it could be done in socketmodule.c, when still holding the GIL.
Python code can change back the socket to inheritable afterwards if i
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This should really be fixed. Hanging on a rather normal email message
(not a theoretical example) is not right.
--
nosy: +pitrou
priority: -> high
versions: +Python 3.0
___
Python tracke
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le vendredi 15 août 2008 à 19:10 +, Martin v. Löwis a écrit :
> Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
> > Because it should be fixed before 3.0 final?
>
> And why should that be done? IMO
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
assignee: -> pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3560>
___
___
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Ok, here is a simple patch. It:
- moves the struct definition at the end of memoryobject.h with a
comment that the definition should not be considered public
- adds two macros for accessing the underlying Py_buffer* and Py
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Fixed in r65700. Thanks for the report!
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
Just got the following on trunk:
test test_multiprocessing failed -- Traceback (most recent call last):
File "/home/antoine/py3k/memapi/Lib/test/test_multiprocessing.py",
line 1040, in test_number_of_objects
pr
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
versions: +Python 3.0 -Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Barry?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2834>
___
___
Python-bugs
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: -pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1179>
___
__
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hi Jack,
> Antoine, I looked at your patch and I'm not sure why you applied it
> instead of applying mine (or saying +1 on me applying my patch).
>
> Yours uses str.partition which I pointed out is sub-optimal (s
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Apparently this has been fixed as part of r65335 ("Security patches from
Apple: prevent int overflow when allocating memory"), although it uses
sys.maxint where sys.maxsize may be more appropriate. Can you check?
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Apparently this has been fixed as part of r65335 ("Security patches from
Apple: prevent int overflow when allocating memory"), although it uses
sys.maxint where sys.maxsize may be more appropriate. Can you check?
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I would add that making the comparison "right" for partial would be
trickier than it seems:
>>> from functools import partial
>>> type == type
True
>>> 1 == 1.0
True
>>> partial(type, 1)
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Can you test with that patch?
--
components: +Tests
keywords: +patch
nosy: +pitrou
type: -> resource usage
Added file: http://bugs.python.org/file11125/memerror.patch
___
Python tracke
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
I suppose the sunau module hasn't received a lot ot love lately :-)
test test_ossaudiodev failed -- Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/test/test_ossaudiodev.py", line
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
I've been trying to track down the following failure which very recently
has started to plague the py3k buildbots:
[...]
test_os
Traceback (most recent call last):
File "./Lib/test/regrtest.py", line 1197, in
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Here is a temptative patch. It should fix the problems with test_closerange.
--
keywords: +patch
Added file: http://bugs.python.org/file11128/test_closerange.patch
___
Python tracker &
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
Reproducing this bug is simple:
./python -c "import os; os.close(2); 1/0"
--
components: Interpreter Core
messages: 71244
nosy: pitrou
priority: high
severity: normal
status: open
title: with closed file descr
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
This still happens regularly on buildbots. Just today:
http://www.python.org/dev/buildbot/3.0.stable/amd64%20gentoo%203.0/builds/925/step-test/0
The bsddb tests must be fixed so that exception raised in other threads
(especiall
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
I've finally diagnosed the problem. test_buffer_is_readonly was opening
stdin's file descriptor again in raw mode, and closing it implicitly by
using "with".
It should be fixed in r65731.
There's a justice:
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Hmm, sorry, false alarm. This was due to some debugging code I had added
in my working copy.
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PR
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Fixed in r65734. I can't guarantee that the whole sunau module is ok,
just that it works enough for the test to pass (and emit the expected
sound...).
--
resolution: -> fixed
status:
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Your patch looks right to me. It should also be backported to 2.6.
--
components: +Library (Lib)
nosy: +pitrou
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Alon, can you try with the following patch? It seems to fix it here.
--
keywords: +patch
priority: -> normal
versions: +Python 2.6, Python 3.0 -Python 2.5
Added file: http://bugs.python.org/file11137/large
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Le dimanche 17 août 2008 à 11:44 +, Hirokazu Yamamoto a écrit :
> Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:
>
> Well, MultibyteCodec_Decode() also uses Py_buffer in py3k but not in
> trunk. Is t
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
I get failures under test_os when launched under Windows XP. More
precisely, it's a Windows XP image inside qemu with the Python build dir
in a Samba mount.
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
title: failures test_os -> failures in test_os
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
I get failures in test_uuid when run inside a qemu virtual machine. It
is related to the fake MAC address used by qemu.
==
FAIL: test_ipconfig_getnode (__main__.Te
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
assignee: -> pitrou
components: +Tests
priority: -> normal
type: -> behavior
versions: +Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://b
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
After testing under Windows, fixed in r65773.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
No, it doesn't fix it.
But I've just tried manually, and GetVolumeInformation() returns "NTFS"
for the Samba share. Apparently this is a Samba "feature" to work with
Windows NT. :-)
See http://lists.samba
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Another problem of using os.path.dirname is that for /A/B, it will
return /A, and if /A is itself a symlink to a mount point itself, /A and
/A/B will have different st_dev values... which will be wrongly
interpreted as meaning that /A/
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
If you remove the print() call from joining_func(), does it stop
hanging? It may be due to differences between the io library in py3k and
the builtin file objects in 2.x.
(looking at the date of the commit disabling the test, it
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Let's retarget it to 3.1 then. It's a new feature, not a behaviour
change or a deprecation, so adding it to 3.0 isn't a necessity.
--
components: +Library (Lib)
nosy: +pitrou
priority: release blocker -> cr
Changes by Antoine Pitrou <[EMAIL PROTECTED]>:
--
nosy: +pitrou
priority: -> normal
versions: +Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Are many people using OpenDNS? Is there a way to detect that OpenDNS is
being used and trigger a separate path in the test?
I say that because returning a 404 when the domain lookup has failed is
wrong. Perhaps the test should check for
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
The re.M flag is an attribute of the compiled pattern, and as such it
must be passed to compile(), not to findall().
These all work:
>>> re.compile(r"[a-z]+").findall("hello world")
['hello&#
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
According to the aforementioned bug report, we should also add a test
for e.winerror == 5. Chances are that other cases will arise one day or
another...
Since the purpose of the test is, allegedly, to "Verify that an open
file can
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> The delayed import functions in multiprocessing.__init__ look like a
> serious misfeature to me. I'd be inclined to replace them with "from
> .synchronize import *" and "from .process import *"
+1
(
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Actually, this may be a requirement of #2394; PEP 3118 states that
> memoryview.tolist would use the struct module to do the unpacking.
:-(
However, we don't have any examples of the buffer API / memoryview
object worki
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
> Just to be clear, I am at present totally confused about io streams :-)
Python 3.0 distincts more clearly between unicode strings (called "str"
in 3.0) and bytes strings (called "bytes" in 3.0). The most import
Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
Mmmh, the problem with the list(X.items()) idiom is that it's
thread-safe only if X.items() is implemented in C. Otherwise X can be
mutated if there is a thread-switch while executing bytecode in X.items().
In weakref.py (li
New submission from Antoine Pitrou <[EMAIL PROTECTED]>:
In py3k, there should be explicit tests for byte string input (in
addition to unicode input) to elementtree's parser, including non-UTF8
encodings and non-ASCII chars.
--
components: Tests, XML
messages: 71351
nosy: eff
4101 - 4200 of 16792 matches
Mail list logo
