Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue12672>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
On a 64-bit Linux machine (where C `long` is 64 bits):
>>> len(pickle.dumps(2**30))
8
>>> len(pickle.dumps(2**31))
16
>>> len(pickle.dumps(2**62))
25
>>> len(pickle.dumps(2**63))
14
This is because the old text protocol i
Antoine Pitrou added the comment:
This patch contains assorted improvements for 64-bit compatibility of the
pickle module. The protocol still doesn't support >4GB bytes or str objects,
but at least its behaviour shouldn't be misleading anymore.
--
keywords: +patch
sta
Changes by Antoine Pitrou :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue12731>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +haypo, loewis
stage: -> needs patch
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue12737>
___
_
Changes by Antoine Pitrou :
--
nosy: +haypo, lemburg
___
Python tracker
<http://bugs.python.org/issue12746>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
I had never heard of "nmemb". "nmembers" would be less cryptic.
The patch needs a "versionadded" directive in the docs.
--
nosy: +pitrou
___
Python tracker
<
Antoine Pitrou added the comment:
It is a wiki page, so you can edit it yourself (you probably need to register,
though).
If you think your modifications would be too drastic, perhaps you want to
launch a discussion on the python-dev mailing-list about that page and its
current contents
Changes by Antoine Pitrou :
--
nosy: +alexandre.vassalotti
___
Python tracker
<http://bugs.python.org/issue12744>
___
___
Python-bugs-list mailing list
Unsub
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> However, because the \w&c issues are bigger, Java addressed the tr18 RL1.2a
> issues differently, this time by creating a new compilation flag called
> UNICODE_CHARACTER_CLASSES (with corresponding embedded "(?U)" regex flag.)
>
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> Here's why I say that Python uses UTF-16 not UCS-2 on its narrow builds.
> Perhaps someone could tell me why the Python documentation says it uses
> UCS-2 on a narrow build.
There's a disagreement on that point between several developers.
Antoine Pitrou added the comment:
> There are occasions when you want to do string slicing, often of the form:
>
> pos = my_str.index(x)
> endpos = my_str.index(y)
> substring = my_str[pos : endpos]
>
> To me that suggests that if UTF-8 is used then it may be worth
>
Antoine Pitrou added the comment:
> I have private builds that are 2.7 and 3.2, but those are both narrow.
> I do not have a 3.3 build. Should I?
I don't know if you *should*. But you can make one easily by passing
"--with-wide-unicode
Antoine Pitrou added the comment:
> > The UTF-8 codec described by RFC 2279 didn't say so, so, since our
> > codec was following RFC 2279, it was producing valid UTF-8. With RFC
> > 3629 a number of things changed in a non-backward compatible way.
> > Therefor
Antoine Pitrou added the comment:
> It looks like the choice is between s.nmembers and len(s). I thought
> about len(s), but since Struct.pack() returns a bytes object, this
> might be confusing.
I agree there's a risk of confusion between len()-number-of-elements and
size()-n
Antoine Pitrou added the comment:
> HIGH_SURROGATE and LOW_SURROGATE require that their ordinal argument
> has been preproceed to fit in [0; 0x]. I added this requirement in
> the comment of these macros.
The macros should preprocess the argument themselves. It will make the
Antoine Pitrou added the comment:
The proposed resolution looks ok. Another possibility is simply to use .lower()
if the string is an unicode string, since that will bypass the C locale.
--
nosy: +pitrou
stage: test needed -> patch rev
Antoine Pitrou added the comment:
> I think the 4 macros:
> #define _Py_UNICODE_ISSURROGATE
> #define _Py_UNICODE_ISHIGHSURROGATE
> #define _Py_UNICODE_ISLOWSURROGATE
> #define _Py_UNICODE_JOIN_SURROGATES
> are quite straightforward and can avoid using the trailing _
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1826/steps/test/logs/stdio
==
ERROR: test_get_and_set_scheduler_and_param (test.test_posix.PosixTester
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file22913/524e47d8b878.diff
___
Python tracker
<http://bugs.python.org/issue12555>
___
___
Python-bug
Changes by Antoine Pitrou :
--
type: performance -> behavior
___
Python tracker
<http://bugs.python.org/issue12763>
___
___
Python-bugs-list mailing list
Un
Antoine Pitrou added the comment:
Updated patch with latest changes from the PEP. The implementation is now
complete.
--
___
Python tracker
<http://bugs.python.org/issue12
New submission from Antoine Pitrou :
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/789/steps/test/logs/stdio
--
assignee: eric.araujo
components: Library (Lib), Tests
messages: 142220
nosy: eric.araujo, pitrou
priority: release blocker
severity
New submission from Antoine Pitrou :
>>> class Foo:
...__slots__ = ['foo']
...foo = None
...
>>> x = Foo()
>>> x.foo
>>> x.foo = 5
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'Foo' object att
Antoine Pitrou added the comment:
> This sort of thing is true of any slotted class with class attributes:
>
> >>> class X:
> ... __slots__ = ()
> ... foo = None
> ...
> >>> X().foo = "hello"
> Traceback (most recent call last):
&
Antoine Pitrou added the comment:
> So would you prefer to see
>
> >>> x.foo
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: foo
> >>> x.foo = 5
> >>> x.foo
> 5
> ?
No, I would prefer to se
Antoine Pitrou added the comment:
> I'm afraid that's not (easily) possible. Using __slots__ implicitly
> gives classes attributes, so what you are seeing is the effect of
> toying with that. It's not really possible to pretend there are
> different attributes on the
Antoine Pitrou added the comment:
I think the functions should:
- accept both str and bytes for keys and values; when it's an str, encoding it
using the FS encoding
- return str for attribute names, using the FS encoding
- return bytes for attribute values, although returning str mig
Antoine Pitrou added the comment:
> I asked the user who reported this documentation omission what he's
> using the 'n' argument for. His reply:
>
> "Yes I am using the n parameter, it is mainly to implement a
> subclass of Queue that supports "bulk&
Antoine Pitrou added the comment:
The "#ifdef O_EXCL" in the source code is probably very old. Copying a message
I posted on python-ideas:
O_EXCL is a POSIX standard. It is also supported
under Windows by the _open/_wopen compatibility functions (which we use
for file I/O).
Prob
Antoine Pitrou added the comment:
> Well, I'd rather have this flag called 'x', to be consistent with
> glibc's fopen():
>
> """
>c (since glibc 2.3.3)
> Do not make the open operation, or subsequent read and write
&
Antoine Pitrou added the comment:
As Charles-François said: it would be nice to know which Python version you are
using. Also, if you could test with 2.7 or 3.2 and the standard json module (or
the latest simplejson if you prefer).
Also, while Python's performance is not always excellen
New submission from Antoine Pitrou :
In the implementation of nt._getfinalpathname() (in posixmodule.c) we have:
/* We have a good handle to the target, use it to determine the
target path name. */
buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT
Antoine Pitrou added the comment:
> The bug note contains a test script. You just have to generate a huge
> JSON-blob, or allocate 1 GB or so and pickle it down to file and
> replace the cjson.decode to pickle.loads, pickle is about 20 times
> faster without GC.
You can't s
Antoine Pitrou added the comment:
That's slightly off-topic, but is it enough to strip the leading '\\?\' (and
replace 'UNC' with '\'), or are there other things to watch out for?
--
___
Python tracker
New submission from Antoine Pitrou :
On a 8GB RAM box (more than 6GB free), serializing many small objects can eat
all memory, while the end result would take around 600MB on an UCS2 build:
$ LANG=C time opt/python -c "import json; l = [1] * (100*1024*1024); encoded =
json.dumps(l)"
Antoine Pitrou added the comment:
> Correct. We can't touch Python 3.1, 2.6, or earlier because those are all in
> security-only mode, and unless a specific security related issue is
> identified, the change should not be made there. That's just life (a recent
> similar
Antoine Pitrou added the comment:
> So overall it looks like it's less of a problem in newer versions of
> Python. We are phasing out the software that is deployed on Debian
> Lenny so it's a problem that will go away. I don't think I have any
> objections wit
Antoine Pitrou added the comment:
Bill is the owner of that buildbot.
--
nosy: +janssen
___
Python tracker
<http://bugs.python.org/issue12765>
___
___
Python-bug
Antoine Pitrou added the comment:
> > It means someone upgrading from 2.6 to 2.7 will see sys.platform change
> > from "linux3" to "linux2". That breaks compatibility.
>
> No, it doesn't. Code that works on 2.6 and Linux 3 will likely support
> bo
Antoine Pitrou added the comment:
> > Then, let's just advise that all code follow the same path and use
> > sys.platform.startswith() (which is really not a difficult change to
> > make).
>
> Antoine, please accept that people want better backwards compatibilit
Antoine Pitrou added the comment:
This patch does the trick.
--
keywords: +patch
Added file: http://bugs.python.org/file22942/jsonacc.patch
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
Interestingly, there's already the following code in Modules/main.c:
if ((Py_InspectFlag || (command == NULL && filename == NULL && module ==
NULL)) &&
isatty(fileno(stdin))) {
PyObject *v;
v = Py
Antoine Pitrou added the comment:
> > Really, it's not difficult to understand that code testing for "linux2"
> > will stop working when "linux3" gets released.
>
> This doesn't matter. People will still complain. And, as there is an
> obvi
Antoine Pitrou added the comment:
> Updated patch (not using Mercurial, looks like I haven’t enough
> bandwidth to push all those changesets).
I think there's a bug in the way you are detecting interactive mode:
$ ./python -c "import sys; print(sys.stdin
Changes by Antoine Pitrou :
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/issue12720>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> The suggested change removes the compile time information from
> the platform string, so that information needs to be preserved
> in a new attribute.
-1 on any new platform identification attribute. We already have too
many of them, and there'
Antoine Pitrou added the comment:
> I have tried running the tests on a machine with 12GB of RAM, but when I do
> so,
> the new tests get skipped saying "not enough memory", even when I specify "-M
> 11G"
> on the command-line.
How much does it say is re
Antoine Pitrou added the comment:
> I'd be glad to do so, but I'm not sure what the aim of the "dryrun" flag is.
> Do you want to make it the default that precisionbigmem tests are skipped,
> unless the decorator invocation explicitly specifies dryrun=False?
No,
Changes by Antoine Pitrou :
--
nosy: +benjamin.peterson, ncoghlan
type: behavior -> feature request
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
I would say I find "accepted" little useful in practice. Removing it would
avoid the confusion with its various (intended or not) meanings.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> Please reread the quoted sentence:
>
> The *compile time* version information needs to be preserved.
Then please give it a very explicit name, such as "sys.build_platform"
or "sys.compile_time_version_info". We don't want
Antoine Pitrou added the comment:
Have you tried with other large files? Or on another system?
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
> I actually looked into doing this for issue #12134, but it didn't seem
> so simple; Since C has no yield, I think the iterator would need to
> maintain its own stack to keep track of where it is in the object tree
> it's encoding..
Antoine Pitrou added the comment:
> Note how the ascii codes for the faulty characters only differ by one
> bit, and only the 5th least significant bit.
This looks very much like a hardware issue.
Python usually does nothing special with the 5th bit of characters. Also, the
IO syst
Changes by Antoine Pitrou :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Antoine Pitrou :
--
nosy: +neologix
type: resource usage -> behavior
___
Python tracker
<http://bugs.python.org/issue12786>
___
___
Python-bugs-lis
Antoine Pitrou added the comment:
> D'oh. I just realized why the -M option wasn't being recognized - I had
> passed it
> after the actual test name, so it was being treated as another test instead
> of an
> option. Sorry for the confusion :/
>
>
Antoine Pitrou added the comment:
I think your expectations for BufferedRWPair are wrong. You should not use
BufferedRWPair with the same underlying stream (that's the whole point of
BufferedRWPair).
--
___
Python tracker
<http://bugs.py
Antoine Pitrou added the comment:
> > It would just need to call a given callable (fp.write) at regular
> intervals and that would be enough to C-accelerate dump().
>
> True, but that would just special case dump(), just like dumps() is
> special-cased now. Ideally JSON
Antoine Pitrou added the comment:
Here is a patch.
--
stage: -> patch review
Added file: http://bugs.python.org/file22950/bufrandom.patch
___
Python tracker
<http://bugs.python.org/issu
New submission from Antoine Pitrou :
$ ./python -m test -R 3:2 test_email
[1/1] test_email
beginning 5 repetitions
12345
Warning -- sys.path was modified by test_email
test test_email failed -- Traceback (most recent call last):
File "/home/antoine/cpython/default/Lib/test/test_
Antoine Pitrou added the comment:
The problem is probably that the frame keeps the last execution state around,
and since the exception itself has a reference to a frame, a cycle is created.
Note that it doesn't happen if you catch the GeneratorExit that gets raised
inside the generat
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file22961/genexcstate.patch
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
Thanks for the report, fixed.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
This should be fixed for BufferedRandom. As I said, I don't think
BufferedRWPair is buggy.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> pending
title: BufferedRandom, BufferedRWPair: issues with i
Changes by Antoine Pitrou :
--
title: BufferedRandom, BufferedRWPair: issues with interlaced read-write ->
BufferedRandom: issues with interlaced read-write
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
I think it can be closed now.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12213>
___
___
Py
Changes by Antoine Pitrou :
Added file: http://bugs.python.org/file22966/aa9e276a791d.diff
___
Python tracker
<http://bugs.python.org/issue12555>
___
___
Python-bug
Antoine Pitrou added the comment:
New patch incorporating Ezio's comments and synchronized with latest default.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Antoine Pitrou :
This small test file exhibits the issue. When @total_ordering is not applied,
the '<' operator raises TypeError as expected. When @total_ordering is applied,
there is an infinite recursion error.
--
components: Library (Lib)
fil
New submission from Antoine Pitrou :
Right now it is painful to integrate openat() with the normal IO classes. You
have to figure out the low-level flags yourself (i.e. replicate the logic and
error handling from the FileIO constructor), then replicate the open() logic
yourself (because you
Antoine Pitrou added the comment:
> A third idea is to find a way to override the low-level open()
> function (the one that returns a fd).
Why not. It would e.g. allow to use CreateFile under Windows (the hg
guys do this in order to change the "sharing" mode to somet
Antoine Pitrou added the comment:
Sounds fine to me.
--
___
Python tracker
<http://bugs.python.org/issue12783>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Antoine Pitrou :
>From a look at the code, realpath() does not seem to resolve symlinks under
>Windows, even though we have the _getfinalpathname function to do that.
Please indulge with me if I'm wrong :)
--
components: Library (Lib)
messages:
Antoine Pitrou added the comment:
> I believe openat is new to POSIX (mandatory as of POSIX 2008). For
> example, it's not currently in OS X and apparently was first added to
> FreeBSD in 8.0. So it would have to be checked by configure and
> documented as platform-dependent.
New submission from Antoine Pitrou :
We have our own quirky implementation of C realpath() in posixpath.py.
It would probably be simpler, safer and more efficient to simply call the POSIX
function instead (but it most be exposed somewhere, by posixmodule.c I suppose).
--
components
Antoine Pitrou added the comment:
The latest POSIX versions (*) allow NULL to be passed for the target memory
area, meaning that realpath() will allocate as much memory as necessary by
itself. This essentially does the same thing as canonicalize_file_name(), but
in a standard way rather than
New submission from Antoine Pitrou :
Windows error 3 is returned when a directory path doesn't exist, but 267 is
returned when an existing path is not a directory. This corresponds straight to
the definition of ENOTDIR, but Python translates it to EINVAL:
>>> os.listdir("x
Changes by Antoine Pitrou :
--
stage: -> patch review
versions: +Python 3.3 -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> Antoine, is it correct that io.BytesIO should only be used with bytearray
> buffers?
BytesIO does a copy of the original object, it does not touch the
original buffer.
--
___
Python tracker
Antoine Pitrou added the comment:
> > Can you replace "_2G" with "_4G" in the decorator for that test?
>
> When I do that, it pushes the memory usage for the test up to 16GB, which is
> beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4)
Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue9893>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: -pitrou
___
Python tracker
<http://bugs.python.org/issue12678>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> However, in doing this, I noticed that these methods will, at best,
> work during the time between connection and the socket going secure
> and were not added to the list of methods that the SSL is documented
> as exposing. Perhaps we should jus
Antoine Pitrou added the comment:
> That's the part I'm questioning though. I'm not clear why you'd ever do
> that instead of doing everything on the original socket before invoking
> ssl.wrap_socket.
>
> What I missed on the original patch before committin
Antoine Pitrou added the comment:
Please also see issue5231.
--
___
Python tracker
<http://bugs.python.org/issue12817>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
> Or go all the way and make memoryview take any flag:
>
> a = array.array('i', [1,2,3])
> m = memoryview(a, getbuf=PyBUF_SIMPLE)
This is good for testing, but Python developers shouldn't have to kno
Antoine Pitrou added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue9993>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
> Hmm, indeed. How about:
>
> 1) memoryview(a, format='B')
>
> Shadows a builtin function; annoying syntax highlighting in current Vim.
>
> 2) memoryview(a, fmt='B')
>
> I'm fully expecting a comment about
Antoine Pitrou added the comment:
> However, requiring an explicit two-step process for any other casting
> (i.e. take a 1-D view, then a shaped view of that flat 1-D view) also
> sounds reasonable.
>
> So I agree with Victor that 1-D bytes -> any shape/format and any
>
Antoine Pitrou added the comment:
> For 3.3, it may be relevant that send/recvmsg are now available via
> the socket API (see #6560)
I think sendfds/recvfds helper methods could be added to the socket type, so
that programmers don't have to get the incantations right by themselves
Antoine Pitrou added the comment:
Now that I think of it, it would be nice to add some simple tests for recvfd
and sendfd in test_multiprocessing.
(also, when os.dup2() is available, you can easily generate an arbitrary big
file descriptor
Antoine Pitrou added the comment:
I committed a patch with some tests. Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
I would add it in test_exceptions, since errno mapping is ultimately used by
exceptions.
--
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
I would simply remove the link, or point it to a similar document
--
keywords: +easy
nosy: +pitrou
stage: -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1
___
Python tracker
&l
Antoine Pitrou added the comment:
The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC
is supported at build time.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue12
Antoine Pitrou added the comment:
The OS X buildbots show some failures:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x
--
___
Python tracker
<http://bugs.python.org/issue6
1101 - 1200 of 16792 matches
Mail list logo
