Mark Dickinson added the comment:
Re: specification of the pickle formats. There's a fairly detailed
description of all the opcodes already in the pickletools module, so the
main task would be to extract those descriptions and put them into the
documentation somewhere.
Perhap
Mark Dickinson added the comment:
Closing this one as won't fix.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python
New submission from Mark Dickinson :
I just got a one-off, non-reproducible test_kqueue failure, during a 'make
test' of the trunk, on OS X 10.5.6. Here's the output:
test_kqueue
test test_kqueue failed -- Traceback (most recent call last):
File "/Users/dickinsm/python_s
Mark Dickinson added the comment:
Here's a patch:
- add a time.sleep(1.0) in between calls to kq.control
- restructure for loop slightly: move initial kq.control call inside it
- bump number of trials from 5 to 10 (why not?!)
- produce more meaningful error message in the unlikely
Mark Dickinson added the comment:
I just saw this same test_kqueue failure pop up on the OS X 3.x buildbot,
so it's evidently not just a peculiarity of my machine.
Unless there are any objections, I'll go ahead and check this in: I think
it's a sufficiently trivial fix that
Changes by Mark Dickinson :
--
priority: -> normal
___
Python tracker
<http://bugs.python.org/issue5025>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Fixed in r68890, r68891, r68895 and r68896
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
Fixed in the trunk in r68897. Will merge to 2.6, 3.0 and 3.1.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
Fixed in the trunk in r68903. If the buildbots are happy with the new
tests, I'll port to 2.6, 3.0 and 3.1.
--
versions: -Python 2.7
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
Hmm. After checking in this patch, the gentoo x86 trunk buildbot
has a new failure in test_pickletools, with the following output:
test_pickletools
**
File
"/home/buildslave/python-
Mark Dickinson added the comment:
Thanks, Antoine!
___
Python tracker
<http://bugs.python.org/issue1672332>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +marketdickinson
___
Python tracker
<http://bugs.python.org/issue3657>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I just committed Tim's suggested change in r68906. This seemed a no-
brainer, regardless of what should be done about pickle.whichmodule. One
fewer sporadic buildbot failure sounds like a good thing to me.
(I hadn't noticed the pickletools fail
Mark Dickinson added the comment:
Fix merged in r68907 (2.6), r68908 (3.1) and r68909 (3.0).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
I've seen requests for combinations with replacement come up on c.l.p. a
few times in the past, though it's never been clear whether there was a
real need or whether the interest was driven by homework or curiosity.
-1 for sequences in the second a
Mark Dickinson added the comment:
I'm wondering how to move forward with this issue. Might it make sense to
break the current monster patch into a series of more-easily reviewed
patches? I was thinking of something like:
- patch 1 (Python code): remove all uses of cmp from std. lib
Mark Dickinson added the comment:
Thanks, Antoine. Here's a new patch.
> - two files have unwanted modifications on non-ASCII characters
> (Lib/heapq.py and Lib/sqlite3/test/hooks.py)
Fixed, I think. Could you double check?
> - you haven't renamed "__cmp__&
Mark Dickinson added the comment:
> that dropping the length argument will make the function iterate over
> *all* combinations,
Now *this* sounds more useful to me: an itertool that generates *all* subsets
of a list. It's
quite easy to do with existing itertools, though, either
Mark Dickinson added the comment:
So there is. Apologies---I'll try to read more carefully next time.
___
Python tracker
<http://bugs.python.org/issue5048>
___
___
Mark Dickinson added the comment:
> since I don't see how the behaviour can differ for a read-only
> non-seekable stream.
Unless I'm misunderstanding you (quite likely), I think one *can* get
different results with buffered and unbuffered stdin.
For example, on my machine,
Mark Dickinson added the comment:
> So the question is whether it is really useful to enforce unbuffered
> stdin with the '-u' option (or your example is simply too borderline).
Hard to say. It seems at least possible that there are Python users for
whom stdin being unb
Mark Dickinson added the comment:
Clearer title.
--
title: round() shows undocumented behaviour -> round(25, 1) should return an
integer, not a float
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
Some minor modifications to the last patch:
- fix round docstring: it now reads "round(number[, ndigits]) -> number"
instead of "round(number[, ndigits]) -> floating-point number"
- add Misc/NEWS entry
- add extra tests for r
Mark Dickinson added the comment:
> It's not about changing it, stdin has always been buffered in py3k.
Sorry: I should have been clearer. It's the change from 2.x to 3.x that
interests me.
So 'python3.0 -u' has buffered stdin, while 'python2.6 -u' does
Mark Dickinson added the comment:
Looks good to me! If it were me I'd probably just code the test directly
as
self.assertTrue((end_time-start_time) >= 0.0999)
to avoid having to look for epsilon when reading.
Do you want to commit it or shall I?
--
nosy: +marketd
Mark Dickinson added the comment:
Fixed in r68978 (trunk) and r68979 (2.6). bsddb is no longer part of the
standard Python distribution for 3.x, so the patch doesn't apply there.
Thank you!
--
resolution: accepted -> fixed
status: open -
New submission from Mark Hammond :
After consideration of issue 4120 and issue 4566, it seems to me that
executables created by bdist_wininst will have a manifest referencing
the MSVC9 assembly, and thus will be in a similar position to the .pyd
files in issue 4120 - that unless the assembly is
New submission from Mark Hammond :
bdist_wininst installers created by py3k fail due to PySys_SetArgv and
Py_SetProgramName both being passed 'char *' strings instead of wide
strings.
The patch is against the svn trunk as currently Python 2.x and 3.x share
the same bdist_wininst
Mark Hammond added the comment:
> Is it really useful to be have the same stub for 2.x and 3.x?
> I think it would be better if they mutually ignore each
> other, and be different.
Good question! I'm not really aware of the complexities involved in
merging between the various
Mark Hammond added the comment:
Ironically I just received personal mail:
"""I have downloaded pywin32_212 [2.6] three times today. the download
completes successfully. but on running the pywin installer i repeatedly
get an error."""
Attached is a screen-shot of
Mark Dickinson added the comment:
combinations_with_replacement addition looks good. Thank you.
I wonder whether the second argument should be constrained to be an
integer? I find the following a little surprising:
>>> list(combinations_with_replacement(range(5), -0.3))
[()]
(same
Mark Dickinson added the comment:
I only just noticed the DeprecationWarning that's already happening for
float inputs in 2.7. (And float inputs already raise TypeError in 3.1.)
So I agree that it's probably not worth it.
___
Python trac
New submission from Mark Dickinson :
Since Python 2.3, PyArg_ParseTuple and friends give a DeprecationWarning
for floating-point arguments where integers are expected. From
http://www.python.org/download/releases/2.3/NEWS.txt:
- The PyArg_Parse functions now issue a DeprecationWarning if a
Mark Dickinson added the comment:
Stage 1 committed in r69025 (py3k) and r69026 (release30-maint).
___
Python tracker
<http://bugs.python.org/issue1717>
___
___
Python-bug
Changes by Mark Hammond :
___
Python tracker
<http://bugs.python.org/issue4566>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/
Mark Hammond added the comment:
ack - I mis-clicked and accidentally removed message78811 and can't see
how to reinstate it. The message isn't critical, but I'm sorry about that!
___
Python tracker
<http://bugs.py
Mark Hammond added the comment:
Checked in to the trunk as as r69038 and svnmerge'd:
* release26-maint as 69040
* py3k as 69041
* release30-maint as 69043
--
resolution: accepted -> fixed
status: open -> closed
___
Python tra
Mark Hammond added the comment:
Thanks for the merging advice!
The patch to the build system is indeed trivial - unfortunately it also
failed to work correctly due to install.c using freopen, a CRT function,
to redirect the output. Interestingly, this probably means that if
someone attempted
Mark Hammond added the comment:
Attaching an updated patch against the py3k branch which makes no
attempt to work on py2k.
Added file: http://bugs.python.org/file12886/wininst_py3k.patch
___
Python tracker
<http://bugs.python.org/issue5
Mark Dickinson added the comment:
Can anyone who uses tkinter give me some advice? Does PyTclObject in
_tkinter.c need to have its tp_richcompare method implemented? And if so,
how do I go about testing the implementation? It seems that PyTclObjects
aren't directly exposed to Python
Mark Dickinson added the comment:
For myself, I strongly prefer that round(int, int) return an integer in
Python 3.x. Here ar\
e three reasons:
(1) Interoperability with Decimal (and, to a lesser extent, Fraction):
the decimal module is\
carefully designed so that Decimals interact well
Mark Dickinson added the comment:
Apologies for the poor formatting in the last comment. Bad
cut-and-paste job.
One more reason:
(4) "In the face of ambiguity, refuse the temptation to guess."
Why should round(int, int) be float, rather than Decimal, or Fraction?
This was the on
New submission from Mark Dickinson :
When running the test-suite (using "make test") for a 32-bit debug build
of py3k on OS X 10.5/Core 2 Duo, I occasionally (perhaps 1 time in 10) get
the following output at the end of a (successful) test_run:
...
test_zipimport_support
test_zlib
Mark Dickinson added the comment:
Thanks, Guilherme.
> For this reason I would actually prefer to them not be comparable.
That's fine with me, so long as we can be sure that there's no existing
code that depends on them being comparable. I can't figure out whether
ther
Mark Dickinson added the comment:
Committed in r69068 (py3k), r69069 (release30-maint).
The original bug with round(float, n) (loss of accuracy arising from
intermediate floating-point rounding errors) is still present; I think
further discussion for that can go into issue 1869 (which
Mark Dickinson added the comment:
See also issue 4707.
--
priority: low -> normal
___
Python tracker
<http://bugs.python.org/issue1869>
___
___
Python-bugs-lis
Mark Dickinson added the comment:
I'm not going to get more time to work on this before
the weekend, so if anyone else wants to take over please
feel free.
Still to do for stage 2: cell objects and slot
wrapper objects need to have tp_richcompare
implemented, to replace the tp_compare
Mark Dickinson added the comment:
If I understand Christian's plan correctly, it was to:
(1) raise TypeError for non-NULL tp_compare, and
(2) rename tp_compare to tp_reserved (with type void *).
and both of these would happen with 3.0.1, so no difference between
3.0.1 and 3.1.0.
It see
Mark Hammond added the comment:
Checked into trunk as r69094; merged to release26-maint as r69095, py3k
as r69096 and release30-maint as r69097.
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.p
Mark Hammond added the comment:
Checked into py3k as r6998; merged to release30-maint as 69099. I hope
I got that right!
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
New submission from Mark Dickinson :
It looks as though a few of the tests in test_funcattrs disappeared in the
conversion to unittest, committed in r60522. (The first one I noticed was
test_empty_cell, but there are others missing too.)
Question for Georg (who did the checkin): do you know
Mark Dickinson added the comment:
Here's stage 2: remove uses of tp_compare from Objects and Modules, and
replace uses of PyObject_Compare with PyObject_RichCompareBool.
PyObject_Compare, cmp and friends still haven't been removed at this
stage.
In detail:
- for cell objects, meth
Mark Dickinson added the comment:
The x86 gentoo buildbot is failing to compile, with error:
/Python/makeopcodetargets.py ./Python/opcode_targets.h
File "./Python/makeopcodetargets.py", line 28
f.write(",\n".join("\t&
Mark Dickinson added the comment:
One other thought: it seems that as a result of this change, the py3k
build process now depends on having some version of Python already
installed; before this, it didn't. Is this true, or am I misinterpreting
something?
Might it be worth adding the
Mark Dickinson added the comment:
Sorry: ignore that last. Python/opcode_targets.h is already part of the
distribution. I don't know what I was doing wrong.
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Dickinson :
--
nosy: +marketdickinson
___
Python tracker
<http://bugs.python.org/issue1205239>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Hammond :
In bug 4804, there is some debate about how desirable it is for Python
to unconditionally disable all CRT assertions on Windows - however,
there is agreement that exposing the ability to enable and disable these
assertions via the msvcrt module is reasonable
Changes by Mark Hammond :
--
components: +Windows
___
Python tracker
<http://bugs.python.org/issue5116>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Hammond added the comment:
I created bug 5116 with a patch to expose CrtSetDebugMode via the msvcrt
module. I didn't attach it to this patch as it doesn't address the
fundamental point in this bug, just offers a workaround to reinstate the
default if desired. If there *was* ag
Mark Dickinson added the comment:
Square brackets added in r69133. The gentoo x86 3.x buildbot seems to be
passing the compile stage now. (Though not the test stage, of course:
one can't have everything!)
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
This is not a bug; it's a consequence of the finite accuracy of floating-
point arithmetic. If you look at the actual value that's stored for
'2.545', you'll see that it's actually slightly less than 2.545, so
rounding it d
Changes by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5118>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
> print round(2.545, 2) // returns 2.55
Aha! Yes, that one *is* a bug (see issue #1869), though it's not one that
I regard as terribly serious, and not one that can be easily solved in all
cases.
Here's why I don't see it as particular
Mark Dickinson added the comment:
See also issue 5118.
___
Python tracker
<http://bugs.python.org/issue1869>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> So you might want to reopen the bug. But either way I don't consider
> this bug as really serious either.
I don't understand. As far as I can see '%.2f' % 2.545 is returning
the correct result: there is no bug here, so no need to r
Mark Dickinson added the comment:
> result is 2.55 and not 2.54. If python doesn't deliver "2.55" as the
> result of it's rounding algorithm then it's doing it wrong. And if
Sorry, but that's just not true. I suggest that you (a) read the
section on floa
Mark Dickinson added the comment:
I'll take this.
I think there *is* a problem here: on a system with 64-bit long,
_Py_HashDouble can end up trying to cast the float value 2.**63 to a C
long. Since 2.**63 doesn't fit in a long, we get undefined behaviour,
according to the C stan
Mark Dickinson added the comment:
> The test failure also happens on trunk, it may be related to the recent
> tk changes.
Yes; sorry---I didn't mean to suggest that the test failures were in any
way related to the opcode dispatch stuff. Apart from the ttk teething
difficulties
Mark Hammond added the comment:
I believe your new patch suffers the same problem. Consider the blocks
like:
+ /* turn off crt asserts on windows since we have no control over fd */
+ Py_BEGIN_CRT_ERROR_HANDLING
Py_BEGIN_ALLOW_THREADS
size = write(fd, pbuf.buf
Mark Hammond added the comment:
Fair enough - but assertions are still disabled while your "reference
count" is >0, which is still while other arbitrary code is running.
While I agree this is an improvement, I'm afraid I'm not playing close
enough attention to under
Mark Dickinson added the comment:
Thanks for the review, Antoine.
Stage 2 applied to py3k in r69181, merged to 3.0 in r69182.
cmp, PyObject_Cmp and PyObject_Compare removed in r69184 (py3k) and r69185
(release30-maint).
There's still the rename of the tp_compare slot to deal with,
Mark Dickinson added the comment:
All relevant changes from the py3k-issue1717 branch have now been merged into
the py3k
branch (and from there into the 3.0 maintenance branch), in a series of
revisions.
Here they are, listed in py3k/release30-maint pairs:
r69188, r69189,
r69190, r69191
Mark Hammond added the comment:
> Python shouldn't (IMHO) crahs, even if you give bogus input to
> python functions.
But it doesn't actually crash does it? It throws an assertion dialog,
which sucks when the machine is unattended - which is why it is a
problem for the
Mark Dickinson added the comment:
This all sounds good to me.
--
nosy: +marketdickinson
___
Python tracker
<http://bugs.python.org/issue5139>
___
___
Python-bug
Mark Dickinson added the comment:
I agree that the names shouldn't clash with those in math, especially
since it seems quite plausible that a user might want to use both
itertools.combinations and math.combs (for example) in the same script.
No strong feelings about the actual names, b
New submission from Mark Dickinson :
When building the py3k branch on OS X, I get the following warning:
gcc -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -IInclude -
I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c: In function ‘Py_Main’:
Modules/main.c
Mark Dickinson added the comment:
> I suggested to include math.npermutations_with_repetitions for
> completeness,
Ezio, itertools currently has combinations with and without *replacement*, not
repetition. I think
you're talking about something slightly different (repetit
Changes by Mark Dickinson :
--
assignee: -> marketdickinson
priority: -> normal
___
Python tracker
<http://bugs.python.org/issue3166>
___
___
Python-bugs-
Mark Dickinson added the comment:
It looks like this is a platform with sizeof(long) == 4 and sizeof(void *)
== 8. Is that right? As Antoine says, I can't see any problem here. Why
do you think that hash(a) should be equal to id(a) in this case?
Antoine, in what way would id()/4 be b
New submission from Mark Dickinson :
The docstring for itertools.product seems to be missing any mention of the
repeat keyword argument, in both the trunk and py3k, and the maintenance
branches.
(The itertools.rst docs are fine, though.)
--
assignee: rhettinger
components: Library
Mark Dickinson added the comment:
Hah. Good point. I'd forgotten about the taking-the-low-order-bits
thing. Should probably do some timings (and possibly also number-of-
collisions measurements) to find out whether using id() >> 3 actually
makes any significant difference (eith
Mark Dickinson added the comment:
Some preliminary timings indicate that it may well be worth replacing 'return
(long)p' with
'return (long)p >> 3' in _Py_HashPointer (in Objects/object.c): I'm getting a
10% speedup in
dict-building and dict-lookup for dicts
Changes by Mark Dickinson :
--
assignee: -> marketdickinson
nosy: +marketdickinson
___
Python tracker
<http://bugs.python.org/issue5175>
___
___
Python-
New submission from Mark Hammond :
% py30 -c "str(memoryview(bytearray((1,2,3"
Traceback (most recent call last):
File "", line 1, in
TypeError: __str__ returned non-string (type bytes)
The expected behaviour is that a string representation be returned.
--
New submission from Mark Dickinson :
See
http://mail.python.org/pipermail/python-dev/2009-February/085809.html
where Nick Coghlan writes:
"I'm wondering if Mark should add the exception he recently removed back
in as a Deprecation Warning when tp_compare is defined, but
tp_richcomp
Mark Dickinson added the comment:
N.B. The 3.x part of this was implemented in r69431 and r69432.
___
Python tracker
<http://bugs.python.org/issue5184>
___
___
Python-bug
Mark Dickinson added the comment:
Deprecation warning for types that implement tp_compare but not
tp_richcompare added in r69431, r69432.
Just the doc fixes in Doc/extending/newtypes.rst left. Assigning to Georg
and reducing priority.
--
assignee: -> georg.brandl
prior
Mark Dickinson added the comment:
This also affects 3.1.
Note that the current behaviour (or rather, its effects in
PyLong_AsUnsignedLongLong) is as documented. In
http://docs.python.org/dev/c-api/long.html
it says for PyLong_AsUnsignedLongLong:
"Return a C unsigned long long f
Mark Dickinson added the comment:
Looks like this was changed in a checkin by Tim Peters in r21099; before
r21099, PyLong_AsUnsignedLongLong raised OverflowError for negative
numbers. After the checkin, it raised TypeError. I suspect the change
was inadvertent.
Tim, any comments
Mark Dickinson added the comment:
Fixed in the trunk in r69436. Will merge to 2.6, 3.1 and 3.0.
___
Python tracker
<http://bugs.python.org/issue789290>
___
___
Python-bug
Mark Dickinson added the comment:
Fix merged in r69437, r69440, r69441.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
New submission from Mark Dickinson :
In the issue 5169 discussion, Antoine Pitrou suggested that for an object
x without a __hash__ method, id()/8 might be a better hash value than
id(), since dicts use the low order bits of the hash as initial key, and
the 3 lowest bits of an id() will
Mark Dickinson added the comment:
Here are some timings for dict creation, created with the attached script.
They're not particularly scientific, but they at least show that this one-
line optimization can make a significant difference.
Typical results on my machine (OS X 10.5.6/Intel
Mark Dickinson added the comment:
Fixed (I hope!) in the trunk in r69459. I'll wait for buildbot results
(just in case) and then merge to 2.6, 3.1 and 3.0.
The same test_cmath failure can also be seen on OS X 10.5.6/Intel when
compiling with -fmpmath=387. Annoyingly, the fix above do
Mark Dickinson added the comment:
Merged to py3k in r69465.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue4575>
___
___
Python-
Mark Dickinson added the comment:
> However, I would like to wait until Tim comments on this.
You may be in for a long wait! I hesitate to make the heretical
suggestion that there may be more important things in life than fixing
minor inconsistencies in Python, but I think it's
Mark Dickinson added the comment:
See issue 5186 for using id()/8 for the hash.
___
Python tracker
<http://bugs.python.org/issue5169>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
> This has been addressed in issue #2636.
Are you sure about this? Does the proposed new regex engine use Thompson
NFAs, or some variant thereof?
--
nosy: +marketdickinson
___
Python tracker
&l
Mark Dickinson added the comment:
Thanks for the patch!
I agree that the 'versionchanged' reference should be added in the docs.
I also think that the test should be updated to check the exception type.
Here's a modified version of your patch that adds a test for
OverflowEr
Mark Dickinson added the comment:
Committed, r69498 (trunk) and r69499 (py3k).
___
Python tracker
<http://bugs.python.org/issue5175>
___
___
Python-bugs-list mailin
2801 - 2900 of 12223 matches
Mail list logo
