Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10564>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> I get 114.9.
How many '9's are there on what you're getting? If you really get
'114.9' then something surprising is happening. If, on the other hand,
you get '114.99', then it's
Mark Dickinson added the comment:
> I am not sure, whether support for non-ascii digits in float()
> constructor is worth maintaining.
I'd be very happy to drop such support. If you allow alternative digit sets,
trying to work out exactly what should be supported and what sho
New submission from Mark Florisson :
Attached is a patch that adds a few features to the Python debugging support
for gdb:
- listing of globals
- python breakpoints
- python stepping/stepping over/finishing of frames/running/continuing
- python code execution in the most recent Python frame
Mark Dickinson added the comment:
About Alexander's solution: might it make more sense to have
PyUnicode_EncodeDecimal raise for inputs like this? I see it as
PyUnicode_EncodeDecimal's job to turn the unicode input into usable ASCII (or
raise an exception); it looks like
Mark Dickinson added the comment:
> Did your chocolate packaging use European digits or Arabic-Indic ones?
> Note that they have different bidi properties:
Good question; I think it was Arabic-Indic digits, but to be honest I don't
remember. (It wasn't *al
Mark Dickinson added the comment:
> Just to keep this discussion as clear as possible Mark, it was your
> first option that I suggest is needed.
Okay, so you want + to try xint.__radd__
before float.__add__.
How do you propose this be achieved? Can you explain exactly what sem
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19859/unnamed
___
Python tracker
<http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
> It would be a welcome feature in Python if the programming language
> would, like MATLAB, associate both i and j with the imaginary unit.
I suggest taking this to the python-ideas mailing list. A working patch might
increase the idea
Mark Dickinson added the comment:
> Why not allow complex('1i')?
Indeed, if 4i were permitted as an imaginary literal, I'd expect to allow
complex('3 + 4i') as well.
(And possible just plain complex('i') too, since co
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19860/unnamed
___
Python tracker
<http://bugs.python.org/issue10562>
___
___
Python-bugs-list mailin
Mark Florisson added the comment:
I forgot to mention, this patch works with gdb 7.2 or higher, but it does not
prevent using other libpython functionality with gdb 7.1 or running the tests
with gdb 7.1.
--
___
Python tracker
<h
Mark Dickinson added the comment:
Grr. Why wasn't this fix backported to the release maintenance branch before
2.6.6 was released? I've just had an application break as a result of
upgrading from 2.6.5 to 2.6.6.
Oh well, too late now. :-(
--
nosy: +mark
Mark Dickinson added the comment:
Ah well, it turned out to be fairly easy to work around, at least. :-)
Just in case any other urllib2 users have to deal with this in 2.6.6 (and also
manage to find their way to this bug report :-): it's easy to monkeypatch your
way around the problem.
Mark Dickinson added the comment:
What results were you expecting here? Both those results look fine to me
(though it's arguable that the second should be +0.0 rather than -0.0).
--
assignee: -> mark.dickinson
___
Python tracke
Mark Dickinson added the comment:
Did you look at the second footnote on that page?
--
___
Python tracker
<http://bugs.python.org/issue10596>
___
___
Python-bug
Mark Dickinson added the comment:
Is the stripping of whitespace necessary for this fix?
Currently, the complex constructor accepts whitespace both inside and outside
the (optional) parentheses:
>>> complex(' ( 2+3j ) ')
(2+3j)
The classes of whitespace accepted in ea
Mark Dickinson added the comment:
Just to clarify: I'm not opposed to allowing arbitrary Unicode whitespace in
the float, int, complex constructors (indeed, it's probably a good thing). But
I'd like to see the change made consistently; for the complex constructor this
looks
Mark Dickinson added the comment:
Ah yes, you're right: this shouldn't be a hard fix. I withdraw my suggestion
for a separate patch. :-)
Checking that:
complex('\xa0(\xa02+3j\xa0)\xa0') == complex(2.0, 3.0)
woul
Mark Dickinson added the comment:
> There should be an environment variable to make the symbol settable.
That could work; it's a bit late to do this in 3.2, though. How about the
following transition strategy for the complex output.
Python 3.3: Introduce PYTHONIMAGINARYSYMBOL env
Mark Dickinson added the comment:
In all seriousness, the idea of accepting both 'i' and 'j' in complex() isn't
horrible. I'm personally -0.small on it, mostly because it seems likely to lead
to more objections about the complex str() and repr() *output* co
Mark Dickinson added the comment:
> Personally, I think it's more important to be able to read
> scientific data easily without too many problems, then to be
> able to write the processed data in exactly the same way it
> was read.
I wonder whether there are many examples wher
Mark Dickinson added the comment:
Maybe we need a complex analog to datetime.strptime:
complex.strpcx('(3 + 4i)', '(%R + %Ii)') -> 3 + 4j
--
___
Python tracker
<http://
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10610>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
The reference to the language spec was really just a way to avoid spelling out
all the details (again) about the precise form of a floating-point string;
apart from the accepted set of digits, the forms are exactly the same (optional
sign, numeric part
Mark Dickinson added the comment:
> Whether 1+2j is a literal or an expression is debatable.
Really? I can't imagine what basis you'd have for calling either 1+2j or +1 a
literal.
--
___
Python tracker
<http://bugs.pytho
Mark Dickinson added the comment:
> For reference, Numpy's PEP 3118 implementation is here:
Thanks for that, and the other information you give; that's helpful.
It sounds like we're on the same page with respect to alignment of substructs.
(Bar the mostly academic ques
Mark Dickinson added the comment:
> For reference, Numpy's PEP 3118 implementation is here
BTW, does this already exist in a released version of NumPy? If not, when is
it likely to appear in the wild?
--
___
Python tracke
Mark Dickinson added the comment:
Thanks for that, Robert.
Actually, I find those few results quite convincing as evidence that it would
be useful to support 'i' (and 'I') on input.
--
___
Python tracker
<http://bug
Mark Dickinson added the comment:
> Are you sure ? I'm not sure how the underlying PyOS_string_to_double()
> (IIRC) works.
I believe it accepts ASCII whitespace (i.e., chars ' ', '\t', '\f', '\n', '\r',
'\v'), and no
Mark Dickinson added the comment:
> According to comments in the code and verified by inspection,
> PyOS_string_to_double does not accept any whitespace.
Bah. You're right, of course. :-)
Any whitespace (post PyUnicode_EncodeDecimal) is handled in PyFloat_FromString,
using
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
nosy: -mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10562>
___
___
Python-
Mark Dickinson added the comment:
I suggest closing this as 'won't fix' (or even the apostrophetically-challenged
'wont fix'). I'll leave it open for a while to allow others to comment.
I have some sympathy for the idea: I also think that the str/repr of a com
Mark Dickinson added the comment:
Looks okay, I guess.
I don't much like the extra boilerplate that's introduced (and repeated) in
longobject.c, floatobject.c and complexobject.c, though.
--
___
Python tracker
<http://bugs.python.o
Mark Dickinson added the comment:
Fixed the sign of the zero (in py3k) in r87032. I'll backport to 2.7 and 3.1,
then close this.
Sergio, is that acceptable? You still haven't said what results you were
expecting for these operations.
--
resolution: -> fixed
stage:
Mark Dickinson added the comment:
Backported to 3.1 (after one botched backport attempt) and 2.7 in r87037 and
r87033.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
+1.
--
___
Python tracker
<http://bugs.python.org/issue10624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10625>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Okay, closing as 'wont fix'.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.py
Changes by Mark Dickinson :
--
components: +Interpreter Core -IO
type: -> feature request
___
Python tracker
<http://bugs.python.org/issue10621>
___
___
Py
Mark Dickinson added the comment:
> Another possibility is to implement the 'O' format unsafely [...]
Hmm. I don't much like that idea. Historically, it's supposed to be very
difficult to segfault the Python interpreter with pure Python code (well except
if you&#
Mark Dickinson added the comment:
> What do you think about adding number parsers that operate directly on
> Py_UNICODE* strings?
I think that might make some sense. It's not without difficulties, though.
One issue is that we'd still need the char* -> double operatio
Mark Dickinson added the comment:
Right; this is expected behaviour. The error you're seeing comes from the
implicit conversion of 1234! from long to float.
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19947/unnamed
___
Python tracker
<http://bugs.python.org/issue10516>
___
___
Python-bugs-list mailin
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19948/unnamed
___
Python tracker
<http://bugs.python.org/issue10516>
___
___
Python-bugs-list mailin
Mark Florisson added the comment:
Indeed, I'm trying to make the code Python 2 and Python 3 (for the inferior)
compatible, it's not really hard but indeed, the 'u' (Python 2) and 'b' (Python
3) stuff need special casing. Python 2 compatibility was also the reason
Mark Roddy added the comment:
Attaching patch that adds the unittestgui to Tools/scripts. Also has updates
to the unittest documentation which includes a note that this tool is for
beginners and a CI system should be used in general.
--
keywords: +patch
nosy: +MarkRoddy
Added file
Mark Florisson added the comment:
Ok I attached a new patch that solves the things you mentioned. It can debug
Python inferiors with versions 2.6+. Execution control commands (py-{run, cont,
finish, step, next}) and py-exec need gdb 7.2+, py-break works with 7.1+.
It now also "sup
Mark Florisson added the comment:
I forgot to remove a tempfile and reverted the Cython note at the top. A diff
is provided (that should be applied upon the previously submitted patch). It's
a diff because I don't have commit rights and svn does not support local
commits.
--
Changes by Mark Florisson :
Removed file: http://bugs.python.org/file19857/libpython_patch.diff
___
Python tracker
<http://bugs.python.org/issue10566>
___
___
Python-bug
Mark Dickinson added the comment:
> That's because the new buffer protocol doesn't define ownership of
> Py_buffer structs. As a result, nothing can be assumed at to which
> piece of code is responsible for allocation and deallocation of
> related memory areas (such as sha
Mark Dickinson added the comment:
Yes, sorry; I'm not likely to find time to do anything with this.
Unassigning, and downgrading priority.
Is it worth leaving this open in case anyone wants to do something about it?
--
assignee: mark.dickinson ->
priority: high -
Mark Dickinson added the comment:
I'll take a look at this.
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9990>
___
_
Mark Dickinson added the comment:
Antoine, a couple of questions:
(1) Is there documentation for the 'smalltable' field of the Py_buffer struct
anywhere? What are the requirements for the exporter here? E.g., is it /
should it be a requirement that shape, strides and suboffse
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue8719>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10787>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Roddy :
--
keywords: +patch
Added file: http://bugs.python.org/file20193/py27.patch
___
Python tracker
<http://bugs.python.org/issue10786>
___
___
Changes by Mark Roddy :
Added file: http://bugs.python.org/file20194/py32.patch
___
Python tracker
<http://bugs.python.org/issue10786>
___
___
Python-bugs-list mailin
Mark Roddy added the comment:
All patches change the default value of stream to None in the constructor, and
set it to the current to sys.stderr if the argument is None. Unit tests
included to check this behavior.
Also, the patch against Python 3.1 adds the Test_TextTestRunner test case
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10809>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
It might be instructive to look at how NumPy itself manages sharing of ndarray
data and ownership of the corresponding structs. I meant to find time to look
at this over the break.
--
___
Python tracker
<h
Mark Dickinson added the comment:
BTW, I agree that it looks as though significant changes might be needed. I
wonder whether it would make sense to exclude the Py_buffer struct fro m the
Stable ABI PEP for now.
--
___
Python tracker
<h
Mark Dickinson added the comment:
Nick, it sounds as though you have an idea of how you think things should be
working here---perhaps you can help me out. I'd really like to understand what
the implementation should look like from the POV of a 3rd party module that
defines some o
Mark Dickinson added the comment:
[Nick]
> For point 2, it must be the same pointer. When the PEP says "the same", > I
> agree it could be taken as ambiguous, but the later reference to the
> exporter managing a linked-list of exported views makes it clear that
>
Changes by Mark Dickinson :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue9920>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
[Nick]
> @Mark: I don't think that follows. [...]
> If the exporter actually needs to release buffer specific
> resources, then it should maintain an internal data structure keyed off
> the Py_buffer address.
Ah, okay. So that would make
Mark Dickinson added the comment:
> an internal data structure keyed off
> the Py_buffer address.
If we're using the Py_buffer address coming into getbuffer as a key, then we
probably shouldn't be using a stack address, since it would be difficult to
guarantee uni
Mark Dickinson added the comment:
> by the time the relevant C stack frame goes away, ReleaseBuffer should
> already have been called.
Hmm. I'm not sure I understand how/when that would happen. Looking at the
current py3k code, in Objects/memoryobject.c at line 92, we have
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue1641>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue8684>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10889>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Dickinson :
It would be helpful (perhaps to developers of alternative implementations) to
give a pure Python version of correctly-rounded long-to-float conversion.
Attached is such a version, as a patch to test_long in the release27-maint
branch.
--
assignee
Changes by Mark Dickinson :
--
components: +Tests
type: -> feature request
___
Python tracker
<http://bugs.python.org/issue10925>
___
___
Python-bugs-list mai
New submission from Mark Summerfield :
I'm reporting this at Georg Brandl's suggestion.
If you unpack the attached (tiny) tarball you get this directory structure:
Graphics/
Graphics/Xpm.py
Graphics/Vector/
Graphics/Vector/__init__.py
Graphics/Vector/Svg.py
Graphics/__init__.py
Mark Summerfield added the comment:
I just installed 3.1.3 and it does indeed give the import error:
Python 3.1.3 (r313:86834, Jan 17 2011, 16:29:46)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>&
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10451>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Florisson :
In both Python versions EINTR is not handled properly in the file.write and
file.read methods.
- file.write -
In Python 2, file.write can write a short amount of
bytes, and when it is interrupted there is no
Mark Florisson added the comment:
Here is fread.py (why can you only attach one file at a time? :P)
--
Added file: http://bugs.python.org/file20463/fread.py
___
Python tracker
<http://bugs.python.org/issue10
Mark Florisson added the comment:
I think this sums it up:
file.write, on EINTR, could decide to continue writing if no Python signal
handler raised an exception.
Analogously, file.read could decide to keep on reading on EINTR if no Python
signal handler raised an exception
Mark Florisson added the comment:
> Ok. This would only be done in buffered mode, though, so your fwrite.py
> example would have to be changed slightly (drop the ",0" in fdopen()).
Indeed, good catch. So apparently file.write (in buffered mode) is also
"i
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11084>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Nice catch! Please could you test the attached patch (against py3k)?
I'll apply it after 3.2 is out. The fix should also go into the 2.7
maintenance branch, I think.
--
assignee: -> mark.dickinson
keywords: +patch
versions: +Python 2.7
Ad
Mark Dickinson added the comment:
Ah, good point about the context; thanks for the updated patch.
Yes, those missing regression tests are a problem; this isn't the first time
that the above problem has appeared.
--
___
Python tracker
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11144>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I'd call this a bug, albeit a minor one. The documentation for 'int' says:
"If the argument is outside the integer range a long object will be returned
instead."
... which certainly suggests (without actually formally implying) t
Mark Dickinson added the comment:
This turns out to be a one-line fix (modulo comments and tests); see attached
patch. The new code depends on the assumption that C longs are represented
using two's complement, but note that this assumption is (a) already present
elsewhere in the P
Mark Dickinson added the comment:
Ha, yes. I commented out the first four tests for zeros of atan in the
cmath_testcases.txt file, but failed to notice that they're tested again, later
on. And the same goes for atanh.
I need to look at this, but I don't have write-access to the
Mark Dickinson added the comment:
[Raymond]
> Also, I question your assertions about running time. [...]
Interesting observation. I wonder what the average number of comparisons
actually is, for random inputs. A quick back-of-the-envelope calculation
suggests that O(max(k*log(k)*log(n)
Mark Dickinson added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file20745/issue9920.patch
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Are you positive that your 'all' is the builtin Python 'all'? NumPy's 'all'
function would behave the way you describe:
>>> all(x < 3 for x in range(5))
False
>>> from numpy import all
>>>
Mark Dickinson added the comment:
> After saying that - I believe overloading a built in Python function in
> a popular package\module is a mistake!
I believe NumPy had 'any' and 'all' *before* Python did. :-)
--
___
Mark Hammond added the comment:
I'm failing to get a new pywin32 out of the door due to this issue. I've spent
a few hours playing with this and I think the analysis is generally correct
here. The key thing is that when using distutils, the extensions end up with a
manifest (
Mark Dickinson added the comment:
Unassigning. I don't think that r82043 is the *real* culprit here; that
bugfix just happened to expose a deficiency in the peepholer; one that's
already present in other situations:
>>> dis.dis(lambda: 2*(3*4))
1 0 LOAD_CO
Mark Dickinson added the comment:
> It should. Can you test?
Ah, you're asking me to actually do some (minimal) work instead of just
complaining?
Yep, the patch tests fine over here (OS X 10.6), and fixes the 2*(3*4) case.
--
___
Python
Mark Dickinson added the comment:
Because (arguably) we don't want to be able to pack non-integral floats (or
Decimal instances, or ...) using integer formats:
>>> import struct
[56090 refs]
>>> struct.pack('L', 2.3)
Traceback (most recent call last):
Mark Dickinson added the comment:
Sorry, I'm unassigning myself from this; I'm still following the issue, but
just don't forsee having time to work on it at all.
--
assignee: mark.dickinson ->
___
Python tracker
<h
Mark Veldhuis <[EMAIL PROTECTED]> added the comment:
thank you too. Yes the text is there, I pasted the whole header here:
Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "copyright", "credits" or "
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
The re module has the following flags (amongst others):
re.X == re.VERBOSE
re.S == re.DOTALL
The short forms of both these flags are clearly taken from Perl, but
they don't seem necessary for Python and are confusing since al
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
This bug can be worked around by using the more modern style of menu
creation. If the program that exhibits the bug has its __init__()
replaced as follows it works correctly on both Linux and Windows:
def __init__(self,
Mark Veldhuis <[EMAIL PROTECTED]> added the comment:
Interesting. I click on an icon-launcher in my panel. The command in the
launcher's properties is: "/usr/bin/idle-python2.5 -n". I got the icon
by dragging the regular icon from under applications-programm
1301 - 1400 of 12223 matches
Mail list logo
