Mark Hammond added the comment:
Adding tests would be fairly painful - there is no test infrastructure in place
for generating and running installers at all, and worse, the changes are likely
to not work correctly when run from a Python "build" tree when the built DLL is
not inst
Mark Hammond added the comment:
(OTOH though, I could tweak the patch to work in a built tree - it would mean
appending "PCBuild" to the dir and retrying the DLL load if the other options
fail...)
--
___
Python tracker
<http://bu
Mark Dickinson added the comment:
How about something like: "Return a float with the magnitude of x but the sign
of y."?
The behaviour of math.copysign with respect to non-float inputs matches that of
almost all the other math module functions: integer arguments are first
co
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12185>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Thanks for the patches! Here's a slight expansion of the wording on your
second patch:
Return a copy of the string S, where all characters occurring
in the optional argument deletechars are removed, and the
remaining characters have been mapped th
Mark Dickinson added the comment:
Closing, based on feedback in the comments. Maybe one day...
--
resolution: -> later
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
float_info.rounds is a bit of an odd fish, and I think it was probably a
mistake to include it in sys.float_info in the first place.
All the other float_info fields relate to parameters of the floating-point
format, which is fixed, useful information. In
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +christian.heimes
___
Python tracker
<http://bugs.python.org/issue12245>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
assignee: docs@python -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12245>
___
___
Python-bugs-list mai
Mark Dickinson added the comment:
Fixed for 3.3 and 2.7.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
> I think we should include the "On a platform ..."
Sure, sounds good. One of the main things that makes copysign useful is that
it distinguishes between -0.0 and 0.0.
--
___
Python t
Mark Dickinson added the comment:
> Is it possible that the problem is related to floating point exceptions?
Hmm. It's possible, but it's still a bit surprising that the crash occurs at
import time rather than when calling one of the cmath functions. But it's very
possi
Mark Dickinson added the comment:
Looking at the cmath source, I'd be a bit suspicious that either the Py_NAN or
the Py_HUGE_VAL macro (or both) is triggering an FPE. Both those values are
used during module initialization.
--
___
Python tr
Mark Dickinson added the comment:
This is expected behaviour: Python 3 changed the semantics of the comparison
operators <, <=, >, >=. See:
http://docs.python.org/py3k/whatsnew/3.0.html#ordering-comparisons
for more.
--
nosy: +mark.dickinson
resolution: -> inval
Mark Dickinson added the comment:
> In this example, I'm sort by item number 1, which is a list, and its
> first value is an int.
? You're sorting by the values of the dict d, and those values have the form
[int, int, dict]; so when the two ints match (e.g., in your data
Mark Dickinson added the comment:
... and you probably want
sorted(lst0, key=len, reverse=True)
anyway. :-)
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12
Mark Dickinson added the comment:
Not to mention d(area of circle of radius r) = r dr matey.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12
Changes by Mark Dickinson :
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12164>
___
___
Pyth
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> all it does is give information about the FPU settings at the time that
> Python was compiled
Hmm. It's actually a bit better than that: as far as I can tell, it reflects
the value of FLT_ROUNDS at the time that Python is started (when the sys
Mark Dickinson added the comment:
Patch that elaborates a bit on the meaning of sys.float_info.rounds.
--
keywords: +patch
Added file: http://bugs.python.org/file22454/issue12245.patch
___
Python tracker
<http://bugs.python.org/issue12
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue9990>
___
___
Python-bugs-list mailing list
Un
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue10227>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Thanks for the patch!
--
nosy: +mark.dickinson
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Thanks for the report.
--
nosy: +mark.dickinson
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Hadn't seen that. Interesting!
--
___
Python tracker
<http://bugs.python.org/issue7117>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
[Amaury]
"It would be interesting to see if it is better/faster than the current dtoa."
I agree that it would be interesting to compare.
[Eric]
"maybe we can say we we can live with 99.5% shortest repr coverage"
Please no! As you say,
Mark Hammond added the comment:
The most recent version of PEP397 has removed all mentioned of this reference
implementation - the C implementation at
https://bitbucket.org/vinay.sajip/pylauncher/ is now the reference.
--
resolution: -> out of date
status: open ->
Mark Dickinson added the comment:
The result of:
struct.pack("d", float("inf"))
would also be interesting. I'd expect to see:
'\x7f\xf0\x00\x00\x00\x00\x00\x00'
--
___
Python tracker
Mark Dickinson added the comment:
The '1.06...e-314' number in the gdb output is interesting: it indicates a
byte-ordering issue, though maybe that issue is only pertinent to gdb itself.
On a little-endian machine:
>>> struct.pack('>> struct.pack('
Mark Dickinson added the comment:
Question: does this test also fail after configuring with the --with-pydebug
flag? (Which I *think* should turn compiler optimizations off, amongst other
things.)
--
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
If there's dependence on undefined behaviour (from overflow of signed integer
operations) in intobject.c, I'd call that a bug. I've been trying to remove
similar overflow checks from the Python source when I've encountered them, but
th
Mark Dickinson added the comment:
> "/ 2" is an integer division, so it should be "// 3" in Python 3.
No, I don't think that's right: 2to3 has no way of knowing that the programmer
intended an integer division here (self.maxstars could be a float).
Inste
Changes by Mark Dickinson :
--
nosy: +benjamin.peterson
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12754>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I agree with you on the correct 8 output bytes. And those expected bytes are
exactly what struct.pack is producing here:
Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul 3 2011, 15:40:35)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages&qu
Mark Dickinson added the comment:
> with codes 0x3f and 0x63 respectively
Whoops: that should be '... 0x3f and 0x6e ...'.
--
___
Python tracker
<http://bugs.pytho
Mark Dickinson added the comment:
+1 for turning these into TypeErrors. It makes little sense that
PyLong_AsLongLong and PyLong_AsUnsignedLongLong behave differently here.
Do you have a patch handy?
--
___
Python tracker
<http://bugs.python.
Mark Dickinson added the comment:
> This probably shouldn't be backported to 3.2
Agreed; I don't see this as a bugfix (especially since AFAIK it's not
documented that TypeError should be raised here); rather, as a design
improvement.
> Also, it's worth noti
Mark Dickinson added the comment:
The patch still needs tests (e.g., in test_capi). I'm not sure whether it
would be good to add information about the TypeError to the docs.
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
Looks good to me.
I'd prefer 'test_long_as_size' to be called 'test_long_as_size_t' (even though
that's inaccurate for the ssize_t bits :-).
The 'Py_None' reference counting in test_long_as_size and test_long_as_dou
Mark Dickinson added the comment:
> is it really worth adding?
Probably not. For improvements along these lines, I'd rather see random.choice
support sets:
>>> random.choice({1, 2})
Traceback (most recent call last):
File "", line 1, in
File
"/Lib
Mark Dickinson added the comment:
[about adding float128]
> I realize a new float type would be a major undertaking
That's an understatement and a half. The only way this could ever be viable is
if float128 support becomes widespread enough that we don't have to write our
own a
Mark Dickinson added the comment:
Thanks, Ned!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8457>
___
___
Changes by Mark Dickinson :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7037>
___
___
Python-bugs-list
Mark Summerfield added the comment:
Perhaps a useful compromise would be to add an "encoding" attribute that is set
to the encoding of the XML file that's read in (and with a default of "ascii").
That way it would be possible to preserve the encoding, e.g.:
import
Mark Dickinson added the comment:
The problem here is the spaces in the input string:
newton:~ dickinsm$ python2.7
Python 2.7 (r27:82500, Jul 13 2010, 14:10:05)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license
Mark Dickinson added the comment:
Note also that spaces are already allowed immediately inside the parentheses in
a string argument to the complex constructor (in python 2.6 and later):
>>> complex("( 1.1+2.1j )")
(1.1001+
Changes by Mark Dickinson :
--
stage: -> needs patch
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/iss
Mark Summerfield added the comment:
I don't see how lxml is relevant here? lxml is a third party library, whereas
etree is part of the standard library. And according to the 3.1.2 docs etree
doesn't have a docinfo (or any other
Mark Dickinson added the comment:
I'm wondering whether the moratorium (PEP 3003) applies to this; from a close
reading I'd say it does. At any rate, it seems like an inessential
enhancement, so I'd be happy to delay this until 3.3.
--
versions: +Python
Mark Dickinson added the comment:
I don't think determining *which* whitespace is allowed is a problem; just use
whatever's already being used for the whitespace that's already allowed (around
the whole complex input, for example, or between the optional parentheses and
the n
Mark Dickinson added the comment:
Fixed in 2.6 in r83970 (3.1 and 2.7 were fixed in revisions r83781, r83782).
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
New submission from Mark Dickinson :
The PPC Tiger buildbot build output shows (e.g., for 2.7):
/Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:421:
warning: initialization makes pointer from integer without a cast
/Users/buildbot/buildarea/2.7.parc-tiger
Mark Dickinson added the comment:
The same warnings show up on the x86 Tiger buildbot. Leopard and Snow Leopard
seem to be fine, though.
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by Mark Dickinson :
--
title: "warning: comparison between pointer and integer" in multiprocessing
build on PPC/Tiger -> "warning: comparison between pointer and integer" in
multiprocessing build on Tiger
__
Mark Dickinson added the comment:
See also:
http://paulbeachsblog.blogspot.com/2007/12/building-firebird-20x-macos-semaphoreh.html
It looks as though SEM_FAILED is defined as -1 on OS X 10.4, and (sem_t *)-1 on
OS X 10.5+, so it's really a bug in the OS X header file. Possible workar
Mark Dickinson added the comment:
BTW, as far as I can tell from the standard (see e.g., section 6.5.9p2 of
www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
), comparison between a pointer and an integer gives undefined behaviour,
except in the case where the integer can be interpreted as
Mark Dickinson added the comment:
What flox said.
There's no reversal here: you've defined an __init__ method that takes no
arguments. The unittest framework tries to instantiate a TestSomething
instance by calling it with two arguments (one of which is self). If you look
at
Mark Dickinson added the comment:
Actually, since SEM_FAILED isn't public and is only used in one file, it seems
simplest just to redefine it on Mac. Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file18505/sem_failed_t
Mark Dickinson added the comment:
Since r83837, the py3k _ctypes module fails to build on my OS X 10.6 machine:
*** WARNING: renaming "_ctypes" since importing it failed:
dlopen(build/lib.macosx-10.6-x86_64-3.2-pydebug/_ctypes.so, 2): Symbol not
found: _ffi_closure_alloc
Refer
Mark Dickinson added the comment:
Same error on the buildbots, here:
http://www.python.org/dev/buildbot/3.x/builders/PPC%20Leopard%203.x/builds/288/steps/compile/logs/stdio
--
___
Python tracker
<http://bugs.python.org/issue5
Changes by Mark Dickinson :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue9180>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Reclassifying as out of date. NaN handling in Python 2.6 and later is
non-accidental.
--
resolution: later -> out of date
___
Python tracker
<http://bugs.python.org/issue
Mark Dickinson added the comment:
(and math.isnan is the recommended way to test for a nan).
--
___
Python tracker
<http://bugs.python.org/issue737648>
___
___
Mark Dickinson added the comment:
Reclassifying as out of date. Infinity and NaN handling in Python 2.7 and
later is consistent across platforms; those versions of Python contain their
own code for reading and writing floats, instead of depending on the system
libraries
Changes by Mark Lawrence :
--
stage: -> patch review
type: -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/
Mark Lawrence added the comment:
Does this still need a patch or can it be closed?
--
nosy: +BreamoreBoy
___
Python tracker
<http://bugs.python.org/issue6
Changes by Mark Lawrence :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue2548>
___
___
Python-bugs-list
Mark Lawrence added the comment:
This has not been implemented as part of the new regex module, see :-
http://mail.python.org/pipermail/python-dev/2010-July/102181.html
--
nosy: +BreamoreBoy
versions: +Python 3.2 -Python 2.7
___
Python tracker
Mark Lawrence added the comment:
Anyone interested in this? Marc-Andre seemed +0.? on this in msg61288.
--
nosy: +BreamoreBoy
versions: +Python 3.2 -Python 2.7
___
Python tracker
<http://bugs.python.org/issue460
Mark Lawrence added the comment:
Is anyone likely to work on this given msg53440 quote "Does anybody want to
write a PEP on thread cancellation? It sure looks like a hairy issue!"
--
nosy: +BreamoreBoy
versions: -Python 2.7
___
Pyth
Mark Lawrence added the comment:
Confirmed still an issue in py3k by using the email subject line from msg8771
and adding two extra test cases to TestParsers got two failures. Tried several
variations of the patch from msg71573 (in the original the parantheses are
unbalanced) and pushed the
Mark Lawrence added the comment:
Still a problems on py3k. Set stage to needs patch as it's so easy to
reproduce.
--
assignee: mhammond ->
nosy: +BreamoreBoy
stage: unit test needed -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2
Mark Lawrence added the comment:
Is anyone aware if this was implemented in 2.5 or later as hinted at in
msg61077? If yes please close this. If no any point in putting this into 3.2?
--
nosy: +BreamoreBoy
versions: +Python 3.2 -Python 2.7
Mark Lawrence added the comment:
Closing as nobody replied to msg71508.
--
nosy: +BreamoreBoy
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Mark Lawrence added the comment:
I'll close this unless there's a positive response within a couple of weeks.
--
nosy: +BreamoreBoy
status: open -> pending
___
Python tracker
<http://bugs.python
Mark Lawrence added the comment:
@Guilherme I'm guessing that you're still interested in this, yes?
--
nosy: +BreamoreBoy
___
Python tracker
<http://bugs.python.or
Mark Lawrence added the comment:
is this still an issue or can it be closed as out fo date?
--
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue592
Changes by Mark Lawrence :
--
assignee: -> d...@python
nosy: +d...@python
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/issue616013>
___
_
Mark Lawrence added the comment:
Closing as no reply to msg81791.
--
nosy: +BreamoreBoy
status: open -> closed
versions: +Python 3.2 -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue
Changes by Mark Lawrence :
--
versions: +Python 3.2 -Python 2.7
___
Python tracker
<http://bugs.python.org/issue626452>
___
___
Python-bugs-list mailing list
Unsub
Mark Lawrence added the comment:
@Guilherme I take it that you're still interested in this?
--
nosy: +BreamoreBoy
___
Python tracker
<http://bugs.python.org/iss
Mark Lawrence added the comment:
Anyone got a reply for msg107898?
--
nosy: +BreamoreBoy
versions: -Python 2.6
___
Python tracker
<http://bugs.python.org/issue644
Changes by Mark Lawrence :
--
stage: -> needs patch
type: -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.3
___
Python tracker
<http://bugs.python.org/is
Changes by Mark Lawrence :
--
versions: +Python 3.2 -Python 2.7
___
Python tracker
<http://bugs.python.org/issue665194>
___
___
Python-bugs-list mailing list
Unsub
Changes by Mark Lawrence :
--
stage: -> needs patch
type: -> feature request
versions: +Python 3.2 -Python 3.0
___
Python tracker
<http://bugs.python.org/is
Changes by Mark Lawrence :
--
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/issue670664>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Lawrence :
--
stage: -> needs patch
type: -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.3
___
Python tracker
<http://bugs.python.org/is
Mark Lawrence added the comment:
This looks weird, a security issue with a low priority???
--
nosy: +BreamoreBoy
___
Python tracker
<http://bugs.python.org/issue672
Mark Lawrence added the comment:
This won't happen directly as mhlib has been removed from py3k, but presumably
the patch could be reworked to apply to the mailbox module where the MH class
now lives.
--
nosy: +BreamoreBoy
versions: +Python 3.2 -Pytho
Mark Lawrence added the comment:
Closed as no response to msg81716.
--
nosy: +BreamoreBoy
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Mark Lawrence added the comment:
Closed as no response to msg81850.
--
nosy: +BreamoreBoy
___
Python tracker
<http://bugs.python.org/issue678264>
___
___
Pytho
Mark Lawrence added the comment:
Closed as fixed in r23322.
--
nosy: +BreamoreBoy
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Mark Lawrence added the comment:
Attached a patch for py3k where the file name has changed. Doc changes could
be based on the comment added to the error method in the patch. I don't think
a unit test is needed but could easily be persuaded otherwise.
--
keywords: +patch
Mark Lawrence added the comment:
Closing because of quote from msg83993 "Another feature request that I've
decided not to consider any further is recursive regular expressions. There are
other tools available for that kind of thing, and I don't want the re module to
go the
Mark Lawrence added the comment:
Works fine with pythonw on 2.6 and 2.7.
--
nosy: +BreamoreBoy
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Mark Lawrence added the comment:
Can this still be reproduced on an appropriate box or can it be closed or what?
--
nosy: +BreamoreBoy
___
Python tracker
<http://bugs.python.org/issue706
Mark Lawrence added the comment:
Is there any interest in seeing the patch updated for py3k? Any comments from
Windows users since Pexpect uses pty which is Linux only?
--
nosy: +BreamoreBoy
stage: -> patch review
type: -> feature request
versions: +Python 3.2 -Pyth
501 - 600 of 12223 matches
Mail list logo
