Alexander Belopolsky added the comment:
I am attaching a patch that uses a regular union of long and Py_ssize_t to
store cached hash/index value in both set and dict entry. Using an anonymous
union would simplify the patch and would reduce the likelihood of breaking
extensions that access
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file18005/unnamed
___
Python tracker
<http://bugs.python.org/issue9260>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
This looks like a duplicate of issue 1581183. The issue is still present in
py3k, but only shows up in picklecycle.py when using pickle.py version. I am
attaching picklecycle3.py which is py3k version of picklecycle.py using python
pickler
Alexander Belopolsky added the comment:
There seems to be a bug somewhere in 2.x cPickle. Here is a somewhat simpler
way to demonstrate the bug: the following code
from pickletools import dis
import cPickle
t = 1L, # use long for easy 3.x comparison
s1 = cPickle.dumps(t)
s2 = cPickle.dumps
Alexander Belopolsky added the comment:
OK, the 2.7 behavior is explainable and correct. cPickle checks the reference
count and does not generate PUT for objects that don't have references:
>>> from pickletools import dis
>>> from cPickle import dumps
>>&
Alexander Belopolsky added the comment:
I am speculating here while Alexandre probably knows the answer. The skip PUT
on unreferenced objects optimization was probably removed because doing so
makes _pickle module behave more like pickle and because pickletools now has
optimize method which
Alexander Belopolsky added the comment:
I've just closed issue8738 as invalid and surely a document explaining the
differences between cPickle and _pickle would save me a lot of effort. It will
also help anyone porting from 2.x to 3.x.
Alexandre, do you have any notes that you can
Alexander Belopolsky added the comment:
The issue is still present in py3k. Attaching an updated patch with tests
only. Is this the same as issue998998?
--
assignee: -> belopolsky
nosy: +alexandre.vassalotti, belopolsky
stage: -> needs patch
versions: +Python 3.2
Added file
Alexander Belopolsky added the comment:
This does not look like a valid bug to me. OP does not show that pickle files
are different on different systems, he mangles pickle file with unix2dos
instead. This would certainly produce an invalid pickle because pickle format
requires '\n&#x
Changes by Alexander Belopolsky :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue1520662>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
> The pickle.py docsstrings in 2.7+ contain the following text
> (amongst others):
>
> .. Protocol 0 is the
> only protocol that can be written to a file opened in text
> mode and read back successfully.
Hmm,
Alexander Belopolsky added the comment:
Antoine,
I think I have found a better solution. Since we are dealing with classic
classes, they should not define __new__. If in porting to 3.x, users introduce
__new__ that requires arguments, they will not be able to unpickle 2.x pickles
no
New submission from Alexander Belopolsky :
Pickle opcode documentation in pickletools still refers to old/new style
classes and changes made in 2.x series. Opcodes such as INT, INST, and OBJ
that are no longer produced by 3.x pickling code should be described as such
and discussion added on
Changes by Alexander Belopolsky :
--
dependencies: +3.1 cannot unpickle 2.7-created pickle
nosy: +alexandre.vassalotti, lemburg, mark.dickinson, pitrou
___
Python tracker
<http://bugs.python.org/issue9
New submission from Alexander Belopolsky :
Example:
>>> dis(pickle.dumps(T, 3), annotate=1)
>>>
>>>
0: \x80 PROTO 3 |
Alexander Belopolsky added the comment:
I am going to close this as a duplicate of issue 1062277. The later has a
patch, but Raymond questioned whether proposed feature is desirable. [msg47268]
I am -1, but will look at the patch there.
--
nosy: +rhettinger
resolution
New submission from Alexander Belopolsky :
Attached script, cycle.py demonstrates a simplification of the behavior
reported by mike bayer in msg77200.
Essentially, the script attempts to pickle a set that contains a class instance
that has an attribute referring back to the set:
class C
Changes by Alexander Belopolsky :
--
nosy: +alexandre.vassalotti, grubert, rhettinger, schmir, zzzeek
___
Python tracker
<http://bugs.python.org/issue9
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file18021/cycle.py
___
Python tracker
<http://bugs.python.org/issue9269>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file18020/cycle.py
___
Python tracker
<http://bugs.python.org/issue9269>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
There are two issues here. The original issue is a duplicate of #1062277. The
other issue is specific to cycles containing a set. [msg77200]
I am opening a separate issue for that. See #9269.
--
resolution: -> duplicate
status: o
Alexander Belopolsky added the comment:
Chances are we will need to add protocol support for sets. See issue9269.
--
___
Python tracker
<http://bugs.python.org/issue9
Alexander Belopolsky added the comment:
I am reclassifying this as an RFE because as a bug, this is a duplicate of
issue1062277. The later contains an excellent description of the problem by
Dima Dorfman:
Our pickle implementations don't check for reduce
cycles. This is som
Alexander Belopolsky added the comment:
On Thu, Jul 15, 2010 at 8:26 PM, mike bayer wrote:
..
> where is it defined that sets are not "supposed" to contain mutable items?
> such a requirement vastly limits the usefulness of sets.
>
Well, there is no such requirement. The
Alexander Belopolsky added the comment:
On Thu, Jul 15, 2010 at 8:52 PM, Jack Diederich wrote:
..
> If database rows were mutable the results of a JOIN could be nonsensical.
And if your result set is self-referential you have a bigger problem
on your hands than not being able to pickle
Alexander Belopolsky added the comment:
I think Raymond might be interested. Since this is not a bug fix, it can only
be considered for 3.x.
--
nosy: +belopolsky, rhettinger
versions: +Python 3.2 -Python 2.7
___
Python tracker
<h
Alexander Belopolsky added the comment:
Just a reminder to myself based on Mark's suggestion on IRC. In TUPLE
opcode documentation two-tuple and three-tuple are redundant in summary line.
Can be replaced with just tuple without loss of clarity. See r
Alexander Belopolsky added the comment:
Revision 68903 was merged in py3k in r68908. It looks like a similar issue
shows up in test_random:
==
ERROR: test_pickling (test.test_random.MersenneTwister_TestBasicOps
Alexander Belopolsky added the comment:
>From IRC:
Sasha: What's the current status of pickling float inf, nan, -0.0, etc.?
Mark: In py3k and release27-maint, there shouldn't be any issues with any of
those. Same with release31-maint. In release26-maint, pickling infinities
Changes by Alexander Belopolsky :
--
dependencies: +cPickle can misread data type
___
Python tracker
<http://bugs.python.org/issue9267>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
> Perhaps the annotations should be wrapped at 78 chars/line ..
I don't know. With deeply nested pickles, annotations may not even start
before column 80. I think further improvement in alignment and layout
algorithms will show diminishing
Alexander Belopolsky added the comment:
OK, can someone show me an example of how functions defined in core Python can
be made available to extension modules? I thought I could model pytime.h/.c
after pymath.h/.c, but the later is not used in extension modules. I must be
missing something
Alexander Belopolsky added the comment:
No it must be something else. Attached issue9079-fail.diff fails with
Symbol not found: __PyTime_gettimeofday
Referenced from: .../build/lib.macosx-10.4-x86_64-3.2-pydebug/datetime.so
even though it is in pytime.o
$ nm ./Python/pytime.o
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file18030/issue9079-fail.diff
___
Python tracker
<http://bugs.python.org/issue9079>
___
___
Python-bug
Alexander Belopolsky added the comment:
Antoine,
you must be building on Windows. I'll try to guess where ftime is defined and
repost the patch.
--
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
I fixed the ftime issue (I hope), but the build still fails. I did not test on
Linux, but I tested on OSX with HAVE_FTIME. Replacing the failing patch.
--
Added file: http://bugs.python.org/file18031/issue9079-fail.diff
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file18030/issue9079-fail.diff
___
Python tracker
<http://bugs.python.org/issue9079>
___
___
Pytho
Alexander Belopolsky added the comment:
Removing spurious configure change from the "fail" patch.
--
Added file: http://bugs.python.org/file18032/issue9079-fail.diff
___
Python tracker
<http://bugs.python.
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file18031/issue9079-fail.diff
___
Python tracker
<http://bugs.python.org/issue9079>
___
___
Pytho
Alexander Belopolsky added the comment:
It looks like my reluctance to add gettimeofday to core without using it there
was well founded. Simply adding a dummy call to _PyTime_gettimeofday in main()
fixed the build problem. This is a hack, of course, so I am still looking for
suggestions on
Alexander Belopolsky added the comment:
Reid,
I am leaning towards reverting to Plan A (issue9079.diff). Would your use case
be served well by a _time module exposing C API via a capsule? This what
datetime does currently.
--
___
Python tracker
Alexander Belopolsky added the comment:
I believe "Confirmed in trunk and py3k." means that the issue was verified to
exist in trunk and py3k branches at the time of the message.
--
___
Python tracker
<http://bugs.python.org
Alexander Belopolsky added the comment:
> The OP has done everything asked of him.
Not quite. He split out the documentation part of his patch and it was
accepted and committed.
Guido raised an issue with the code. OP raised more questions. The code was
never updated.
Now the patch
Alexander Belopolsky added the comment:
It turns out I misunderstood how date.today() worked [1] and issue9079.diff
introduced significant change in behavior. Bringing timeofday into core rather
than _time.c also introduced several complications. As a result it makes sense
to start with
Alexander Belopolsky added the comment:
Antoine said on IRC that he is ok with the latest approach. Does anyone want
to review the patch before it goes in?
--
resolution: -> accepted
stage: patch review -> commit review
___
Python tracker
Changes by Alexander Belopolsky :
--
superseder: -> test_timeout refactoring
___
Python tracker
<http://bugs.python.org/issue728815>
___
___
Python-bugs-lis
Alexander Belopolsky added the comment:
Alexandre,
I am not sure your change form PyObject_Size(args) to Py_SIZE(args) is correct.
As far as I can tell, args come from pickle machine stack without any type
checks. The equivalent code in 2.x cPickle uses PyObject_Size and checks for
errors
Alexander Belopolsky added the comment:
Committed in r82931 with small changes based on comments here and on IRC:
1. Annotations are separated from disassembly by spaces without '|'.
2. Made a small improvement to the annotation alignment algorithm. Excessively
long lines do not
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
I am merging in the nosy list from issue9079 after we had a lengthy discussion
there and on IRC about the best way to share code between stdlib extension
modules.
For the issue9079, we decided to bring the shared code into python core, but
this cannot
Changes by Alexander Belopolsky :
--
stage: committed/rejected -> needs patch
___
Python tracker
<http://bugs.python.org/issue9012>
___
___
Python-bugs-list mai
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue5673>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Indeed. Replacing issue9079a.diff now.
--
Added file: http://bugs.python.org/file18045/issue9079a.diff
___
Python tracker
<http://bugs.python.org/issue9
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file18034/issue9079a.diff
___
Python tracker
<http://bugs.python.org/issue9079>
___
___
Python-bug
Alexander Belopolsky added the comment:
2.7 is not gone. It has entered an extended maintenance period. During this
period, 2.7.x releases will incorporate bug fixes but will not get any new
features. This particular issue is arguably a bug. I think Christian should
make a call on
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
resolution: -> accepted
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
Committed issue5180b.diff with minor additions in r82937 (r82938 for 3.1):
1. Added an assert that args is a tuple in instantiate() with an explanation
why it is true.
2. Added a test for the other code branch instantiate. (Not all conditions are
Alexander Belopolsky added the comment:
Upon further investigation, I am no longer convinced that "reduce cycles" are
necessarily fatal to pickling. I am attaching a script testcycle.py that
allows creating cycles using various containers. It takes the name of container
class as a
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
stage: -> needs patch
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
Martin,
Was there a reason for not accepting this patch for the trunk?
--
assignee: -> belopolsky
keywords: +easy
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
If any RedHat/Fedora people are tuned in, can you give us an update on
Systemtap/DTrace support in RedHat/Fedora python? I understand that one of the
main problems with bringing this upstream was the lack of uniformity between
Apple and Sun approaches
Changes by Alexander Belopolsky :
--
dependencies: +Single-line option to pygettext.py
___
Python tracker
<http://bugs.python.org/issue7962>
___
___
Python-bug
Alexander Belopolsky added the comment:
A rare example of a 5-year old patch that still applies with only a minor
tweak. This is probably a sign that pygettext itself has not been kept up to
date. In any case, I am attaching an updated patch which I did not test
beyond running
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file18055/issue1098749.diff
___
Python tracker
<http://bugs.python.org/issue1098749>
___
___
Pytho
Alexander Belopolsky added the comment:
Mark L,
This could use some shaking. Please take a look.
--
nosy: +BreamoreBoy, belopolsky
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
I did not test the patch, but if it really addresses the issue, I don't see why
such a simple fix would not be applied.
Guilherme,
Can you add unit tests? Also, the second chunk in your patch is just a style
fix which is a distraction for revi
Alexander Belopolsky added the comment:
Georg,
Do you mind if I take this over?
While I have issues with east/west of UTC terminology, it is the accepted
terminology throughout the manual and Brian's rewording is an improvement.
--
___
P
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
nosy: +belopolsky -Alexander.Belopolsky
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue
Changes by Alexander Belopolsky :
--
keywords: -needs review
___
Python tracker
<http://bugs.python.org/issue7829>
___
___
Python-bugs-list mailing list
Unsub
Alexander Belopolsky added the comment:
LGTM
Unless someone objects, I will check that the patch generates reasonable HTML
and apply.
--
assignee: d...@python -> belopolsky
resolution: -> accepted
stage: needs patch -> commit review
_
Alexander Belopolsky added the comment:
The patch does not apply to py3k. Also, when you generate patches please do so
from the root directory of the branch. For example, tutorial/inputoutput.rst
should be patched as Doc/tutorial/inputoutput.rst.
Thanks
New submission from Alexander Belopolsky :
I am opening this to supersede issue7229. See discussion following msg107148.
In many places offsets representing the difference between local time and UTC
are described as minutes or seconds east or west of UTC. This is not correct
because UTC is
Changes by Alexander Belopolsky :
--
dependencies: +Manual entry for time.daylight can be misleading
___
Python tracker
<http://bugs.python.org/issue9305>
___
___
Alexander Belopolsky added the comment:
After reading the new wording on a formatted page, I don't like the proposed
changes:
"""
time.altzone
When daylight is nonzero, altzone specifies the offset of the local DST
timezone, in seconds west of UTC. This is negative if th
New submission from Alexander Belopolsky :
Is there a reason for not documenting Py_TPFLAGS_LONG_SUBCLASS
(Py_TPFLAGS_INT_SUBCLASS in 2.x)?
This flag is used in PyLong_Check, but neither this flag or its inheritance
properties are explained anywhere in the docs.
See also issue5476
Alexander Belopolsky added the comment:
As I suspected, datetime not recognizing numpy.int_ as a valid input is a numpy
issue. Unlike regular int subclasses, numpy.int_ does not have
Py_TPFLAGS_INT_SUBCLASS flag set:
>>> numpy.int_.__flags__ & (1<<23)
0
>&
Alexander Belopolsky added the comment:
Here are other similar flags that are not documented:
/* These flags are used to determine if a type is a subclass. */
#define Py_TPFLAGS_INT_SUBCLASS (1L<<23)
#define Py_TPFLAGS_LONG_SUBCLASS(1L<<24)
#define Py_TPFLAGS_L
Alexander Belopolsky added the comment:
Adding issue7989 as a dependency because one of the stated reasons for not
calling system strftime from datetime directly is because pure python
implementations cannot do the same. This of course can be resolved by exposing
raw strftime in separate
Changes by Alexander Belopolsky :
--
dependencies: +Add pure Python implementation of datetime module to CPython
superseder: Add pure Python implementation of datetime module to CPython ->
___
Python tracker
<http://bugs.python.org/issue1
Alexander Belopolsky added the comment:
On Mon, Jul 19, 2010 at 2:17 PM, Antoine Pitrou wrote:
> .. These flags are primarily useful for C extension developers, there's
> little point checking them from Python code.
Of course there is: it helps debugging problems in types imple
New submission from Alexander Belopolsky :
On Mon, Jul 19, 2010 at 2:45 AM, Guido van Rossum wrote:
> Sounds like a good idea to try to remove redundant cookies *and* to
> remove most occasional use of non-ASCII characters outside comments
> (except for unittests specifically tryin
Alexander Belopolsky added the comment:
In the attached patch, I've removed encoding cookies in all files listed in the
message above except
>> Lib/test/bad_coding.py:# -*- coding: uft-8 -*-
>> Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*-
>> Lib/shlex.py:#
Alexander Belopolsky added the comment:
It turns out that test_imp tests that pydoc.py is in iso-8859-1. This is not
right. The test should use a dedicated file under Lib/test for that.
--
___
Python tracker
<http://bugs.python.org/issue9
Alexander Belopolsky added the comment:
On Mon, Jul 19, 2010 at 4:33 PM, Éric Araujo wrote:
..
> The shlex fix was reverted IIRC because Mark was unsure of the fix, since our
> diff tools
> try to be too clever and decode files, not showing us the bytes differences.
Well, it is
Alexander Belopolsky added the comment:
Tracker eating python prompt prefixed lines is truly annoying. Here are the
missing lines:
>>> len(shlex(posix=True).wordchars) - len(shlex().wordchars)
62
>>> len([chr(i) for i in range(128, 256) if chr
Alexander Belopolsky added the comment:
>
> Changes by Éric Araujo :
> --
> nosy: +esr
I don't think posix mode was added by ESR, but I cannot check ATM.
--
nosy: +Alexander.Belopolsky
___
Python tracker
<http://bugs.
Alexander Belopolsky added the comment:
I wonder whether 3.x shlex working with unicode files is just incidental to 3.x
string model and is not really correct. I think issue1170 is a better place to
have this discussion. I'll add a comment there.
--
nosy: -Alexander.Belop
Alexander Belopolsky added the comment:
As discussed in msg110828 under issue9308, it is not clear whether logic
identifying word characters in shlex is correct in presence of unicode.
--
assignee: -> belopolsky
keywords: +patch
nosy: +belopol
Changes by Alexander Belopolsky :
___
Python tracker
<http://bugs.python.org/issue1170>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/o
Alexander Belopolsky added the comment:
I believe the e-mail thread that culminated in r32284, "Implemented posix-mode
parsing support in shlex.py", was "shellwords" from April 2003:
http://mail.python.org/pipermail/python-dev/2003-April/034670.html
I scanned through the
Alexander Belopolsky added the comment:
I am attaching a new patch, issue9308a.diff which fixes test_imp by introducing
a new package, test.encoded_modules which currently contains a module encoded
with iso-8859-1 and another with a somewhat more interesting encoding, koi8-r.
I think it
Changes by Alexander Belopolsky :
--
keywords: +needs review
stage: commit review -> patch review
___
Python tracker
<http://bugs.python.org/issue9308>
___
_
Alexander Belopolsky added the comment:
> Does Numpy correctly call PyType_Ready()?
As far as I can tell, it does:
#define DUAL_INHERIT(child, parent1, parent2) \
Py##child##ArrType_Type.tp_base = &Py##parent2##ArrType_Type; \
Py
Alexander Belopolsky added the comment:
As I explained in msg110617 under issue9269, it is possible that we can do
better than simply detect reduce cycles and bail out.
I am torn between two options:
1. Reject this patch and wait until a proper solution is found.
2. Admit that better is the
Alexander Belopolsky added the comment:
On Tue, Jul 20, 2010 at 10:46 AM, anatoly techtonik
wrote:
> .. Another
> concern - if UTC is 0 reference point then there is no reason to add
> something to it - you just can say - "Return timedelta equal to local
> UTC offset.&quo
Alexander Belopolsky added the comment:
On Tue, Jul 20, 2010 at 11:39 AM, Tim Peters wrote:
>.. As I recall it, the current wording was just to avoid saying "ahead of
>UTC" or "behind UTC" (which was the original wording).
Interesting. I actually like the origin
Alexander Belopolsky added the comment:
On Tue, Jul 20, 2010 at 12:14 PM, Alexander Belopolsky
wrote:
..
> Interesting. I actually like the original wording better. For me,
> "my watch is 6 hours behind UTC" makes it clear that when the Big Ben
> clock shows tea tim
Alexander Belopolsky added the comment:
> Could you add comments in encoded_modules/__init__.py?
Please see updated issue9308a.diff.
--
Added file: http://bugs.python.org/file18093/issue9308a.diff
___
Python tracker
<http://bugs.pyth
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file18077/issue9308a.diff
___
Python tracker
<http://bugs.python.org/issue9308>
___
___
Python-bug
Alexander Belopolsky added the comment:
On Tue, Jul 20, 2010 at 12:08 PM, anatoly techtonik
wrote:
..
> Ok. Sold.
Good. All we need now is just a patch. :-)
--
___
Python tracker
<http://bugs.python.org/iss
2801 - 2900 of 3596 matches
Mail list logo
