Mark Wielaard added the comment:
The original patch was created to be as close as possible to the support that
Sun and Apple added to their python implementation for Solaris and MacOS.
Changing the probe point names would make the current patch slightly different
for scripts written against
Mark Dickinson added the comment:
This sounds similar to issue 9215, which was due to a compiler optimization
bug. Certainly it points to something going wrong in _Py_dg_dtoa.
What platform are these results from?
Do you have minimal code that can be used to reproduce?
I'm surprised
Mark Dickinson added the comment:
> I'm surprised that 3.2 fixes this: the float-to-string conversion code > is
> pretty much identical in both 3.1 and 3.2.
Whoops---not quite. The conversion code *is* pretty much identical, but 3.2
now uses a different algorithm for str
Mark Dickinson added the comment:
> The puzzling thing is that the same Python.dll when used by python.exe and
> not PyScripter produces correct results.
Yes, this is indeed puzzling. Are you absolutely sure that both python.exe and
PyScripter are using the exact same Python.dll file
Changes by Mark Dickinson :
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue9980>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> It's interesting to note that '9' is ascii 57, and ':' is 58.
Right; it's that part that convinces me that the problem is somewhere deep in
_Py_dg_dtoa, in the guts of the float to string conversion, where a
xxx99.
Mark Dickinson added the comment:
Added the extra test cases (for py3k only) in r85119.
--
___
Python tracker
<http://bugs.python.org/issue9980>
___
___
Pytho
Mark Dickinson added the comment:
Applied further tweaks in r85120: for an integer n, log(n) is now computed as
log(float(n)), provided only that n is small enough to be converted to a float
without overflow. This puts log on a more equal footing with all the other
math module functions
Mark Dickinson added the comment:
> Delphi uses the following code at initialization.
Yep. That would explain the problem. On x86 machines, Python's
string-to-float and float-to-string conversions require that the x87 FPU has
precision set to 53 bits rather than 64 bits (and also
Mark Dickinson added the comment:
[Eric]
> There's no doubt a performance issue with doing so, although someone
> would have to measure that. It may well be swamped by the memory
> allocation, etc. that is going on at the same time and so won't matter.
Yes, I think cha
Mark Dickinson added the comment:
> It looks like you may need to override these macros for PyScripter.
Stupid. Of course, this isn't an option if you're using the existing Python
dll directly.
For PyScripter, can you alter your Delphi layer to drop back to the normal
d
Mark Dickinson added the comment:
Thanks for the numbers, Stefan.
What about in the reverse direction (string to float)? I don't expect any real
difference there, either, but it would be good to check.
--
___
Python tracker
Mark Dickinson added the comment:
Whoops; that *was* string to float. How about float to string?
--
___
Python tracker
<http://bugs.python.org/issue9
Mark Dickinson added the comment:
> I would feel more comfortable if the correct FPU state is guaranteed.
I agree, in principle. In practice there are some thorny issues to deal with,
and things to think about:
(1) The method for getting and setting the FPU precision varies from platf
Mark Dickinson added the comment:
A disadvantage of the patch is that ceval.c needs to know about the internal
implementation of a PyLong. At the moment, this information is encapsulated
only in Objects/longobject.c and a couple of other places (I think marshal.c
Changes by Mark Dickinson :
--
nosy: +eric.smith, mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10021>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
> I seem to remember this having been discussed before, but I
cannot find the right thread.
It came up in the issue 7951 discussion, I think.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9980>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Looks like a nice idea, at first glance, though I haven't looked at the code in
detail. I like the use of the macros to abstract away the long implementation
details.
"INPLACE_SUBTRACT_end", not "INPLACE_SU
Mark Dickinson added the comment:
+#define _PyLong_IS_SMALL_INT(v) \
+(((PyLongObject *)(v)) >= _PyLong_small_ints && \
+ ((PyLongObject *)(v)) < _PyLong_SMALL_INTS_END)
+/* These macros purposedly avoid a cast to int, since it is most of time
+ useless, and sometim
Mark Dickinson added the comment:
Maybe we could consider adding an extra field to a PyLong giving its
'small_int' value for small values, and some flag value for non-small longs.
An extra field wouldn't actually enlarge the size of a PyLong for small
values---on a 64-bit m
Mark Dickinson added the comment:
> Technically arbitrary relational comparisons of pointers are undefined,
> but in practice Antoine's assumptions here are very modest.
I disagree: there's a very real practical danger here. Namely, optimizing
compilers are free to assume t
Mark Dickinson added the comment:
> I can't say anything about the standard, but p > q looks like it should
> be the same as (p - q) > 0
Yep.
> which looks rather well-defined for pointers.
Nope. It's only well-defined for pointers pointing into the same array (or t
Mark Dickinson added the comment:
> How can the compiler tell whether two pointers are "into the same
> array"? That sounds like an undecidable criterion.
It doesn't have to be able to tell---it's allowed to assume. :-)
--
Mark Dickinson added the comment:
See the example above: suppose that a compiler is looking at a (p >= q)
comparison of pointers. Suppose furthermore that in a particular case that
compiler is smart enough to figure out that q is a pointer to the start of an
array. Then the compiler
Mark Dickinson added the comment:
> How is the compiler supposed to know whether a and b belong to the same
> array when compiling ptr_compare?
It doesn't need to know. So long as the compiler can guarantee that its code
will produce correct results in the case that a and b *do*
Mark Dickinson added the comment:
> For the record, a Py_uintptr_t version works and has the same
> performance. Would you agree to it or is there still some menacing
> oddity from the i386 days lurking around?
Technically, it's still dodgy: as the gcc manual notes in:
http
Mark Dickinson added the comment:
Thanks for the report. Some questions:
1. Have you tested this with Python 3.x at all? I'd expect the same issues to
show up for Python 3.1 and 3.2.
2. Also, do you have the relevant configure output to hand? On my machine, the
output from '.
Mark Dickinson added the comment:
> Anyway, I would like to leave the decision to the core developers.
You mean the core developers other than Stefan? ;-)
I don't have any objection to a patch for this problem, provided that that
patch is specifically targeted at FreeBSD 4, and
Changes by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10078>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
What versions of Python does this apply to? Is this a duplicate of issue 5215?
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue10
Mark Dickinson added the comment:
> For example C# uses 80 bit precision
No, I don't think that's true. It uses the x87, with its 64-bit internal
precision, but I'm fairly sure that (as is almost always true in a Windows
environment, except if you're using Delp
New submission from mark saaltink :
Tkinter, since tk 8.5 apparently, does not find all the fonts that tk knows
about.
I'm using Python 2.6.5 on Linux but have seen this on previous versions. I
have added the font with "xset fp+ "". The font is
Richard Jones' zed f
Mark Dickinson added the comment:
> The calculation of long_hash assumes an unsigned temporary type to get
> correct results for the bit shifting and masking.
Yes, exactly.
> The calculation is
> done on the absolute value of the long and then the sign is applied. We
> eith
Mark Dickinson added the comment:
Seconding Eric's comment. This is what I get on my machine; can you cut and
paste the equivalent output on yours (including whatever else is required to
reproduce the results you describe)
Python 2.6.1 (r261:67515, Feb 11 2010, 15:47:53)
[GCC 4.2.1 (
mark saaltink added the comment:
I built the latest 2.7, with tk/tcl 8.5, and see the same problem.
--
___
Python tracker
<http://bugs.python.org/issue10
Mark Dickinson added the comment:
Thanks for the report; I agree that there's a potential issue here, and I also
think that all these definitions *should* be preprocessor defines. (Idle
question: does C99 require that LONG_MAX and friends are usable in the
preprocessor? I see it i
Mark Roddy added the comment:
Patch which makes TestCase pickle-able for Python 2.7, includes unit test
--
keywords: +patch
nosy: +MarkRoddy
Added file: http://bugs.python.org/file19515/python27.pickle.patch
___
Python tracker
<h
Mark Roddy added the comment:
Attaching patch which makes TestCase pickle-able for Python 3.2, includes unit
test
--
Added file: http://bugs.python.org/file19516/python3k.pickle.patch
___
Python tracker
<http://bugs.python.org/issue10
Mark Roddy added the comment:
Attaching patch which adds support for registering a skip when raised from
tearDown. Per Michael's point regarding failed tests, this is only handled if
the test has been successful when SkipTest is raised from tearDown.
--
keywords: +patch
Mark Roddy added the comment:
Attaching patch which does the same as the previous for the release27-maint
branch.
--
Added file: http://bugs.python.org/file19527/python27.skipteardown.patch
___
Python tracker
<http://bugs.python.org/issue9
Mark Dickinson added the comment:
It's not a bug: you're seeing Python's rules for integer division, which do
indeed differ from those of (some) other languages when either the divisor or
the dividend is negative. For integers x and y, in Python 2.x, x / y gives the
flo
Mark Dickinson added the comment:
I'm not sure what can reasonably be done about these failures. The Python test
is failing because of a deficiency in the system math library.
Adding extra code to Python to handle this (making use of
TANH_PRESERVES_ZERO_SIGN) is an option, but it seems
Changes by Mark Dickinson :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue10297>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Fixed in r86286, r86287, r86288.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Here's a patch (against py3k) incorporating your suggestions. Would you be
willing to review?
[Removing Python 2.6 from versions since it's no longer maintained for
non-security issues.)
--
keywords: +patch
versions: -Python 2.6
Added
Changes by Mark Dickinson :
Added file: http://bugs.python.org/file19531/issue10325.patch
___
Python tracker
<http://bugs.python.org/issue10325>
___
___
Python-bugs-list m
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19530/issue10325.patch
___
Python tracker
<http://bugs.python.org/issue10325>
___
___
Python-bug
Mark Dickinson added the comment:
On Wed, Nov 3, 2010 at 3:28 AM, Case Van Horsen wrote:
> Has the cdecimal branch kept up with the hash value changes in 3.2?
Not sure; that's a question for Stefan.
> Is there a still a chance that cdecimal could be merged into 3.2?
A chance
Mark Dickinson added the comment:
Fixed in r86293, r86394, r86295.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
Thanks for the patch. This looks fine, in principle.
A couple of comments and questions:
(1) I think the patch should provide *MIN values alongside the *MAX values (for
signed types only, of course).
(2) Are we sure that these values are valid on all
Mark Dickinson added the comment:
Nice fix! Thanks.
--
___
Python tracker
<http://bugs.python.org/issue10337>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
P.S. Greg, as the owner of the buildbot, do you feel like reporting this
upstream? I get the impression that it's easier to do the reporting directly
from the NetBSD machine in question...
--
___
Python tr
Mark Dickinson added the comment:
Are there situations where this is a problem?
I don't think that there's any requirement that the __hash__ method for a
user-defined Python type not return -1. (It's also allowed to return values
outside the range of hash values; these ge
Mark Dickinson added the comment:
Okay; go ahead and apply (preferably in two separate commits, since you're
fixing two only marginally related issues here).
--
assignee: -> skrah
___
Python tracker
<http://bugs.python.org
Mark Dickinson added the comment:
The Fraction type has the same behaviour, so I've fixed it to match the
proposed new Decimal behaviour in r86448.
--
___
Python tracker
<http://bugs.python.org/is
Mark Hammond added the comment:
Thinking more about this, I think the approach of this patch is more complex
than necessary. I think a better patch would be one which *unconditionally*
removes the manifest from extension modules. For maximum flexibility though,
we should probably allow a
Mark Hammond added the comment:
I'm wondering if, in practice, extensions which need a manifest can have the
manifest being generated completely by the linker - ie, I expect that in most
cases where something other than the CRT or MFC is needed in the manifest, the
author will wa
New submission from Mark Hammond :
fileConfig has code to detect existing "child" loggers and ensure they are
enabled if the parent is configured. However, the approach it takes of sorting
the log names can fail in some cases. eg, if 3 loggers exist with names like
"bar&qu
Mark Dickinson added the comment:
fold-0.patch looks good to me, but why do you include tests only for the float
case (-0.0) and not the integer case (-0)?
Style nitpick: "def negzero(): return -(1.0-1.0)" should be on two source
line
Mark Dickinson added the comment:
Eugene's new patch looks good to me; +1 on applying it.
Raymond, do you happen to remember why it was necessary to add the zero-check
in the first place?
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
Fixed in 2.7, 3.1, 3.2, 3.3. Closing.
--
resolution: -> fixed
status: open -> closed
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Yes, there's interest (at least here). I've just been really short on
Python-time recently, so haven't found time to review your patch.
--
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
I'm going to unassign for now; I still hope to look at this at some point, but
can't see a time in the near future when it's going to happen.
--
assignee: mark.dickinson ->
___
Pyt
Mark Dickinson added the comment:
See:
http://docs.python.org/tutorial/floatingpoint.html
--
nosy: +mark.dickinson
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
I don't think this needs to be documented beyond the limitations of
floating-point that are already documented in the tutorial. It's the obvious
behaviour: double to float (when packing) converts to the nearest float; the
float to double con
Mark Dickinson added the comment:
[Robert]
> I have to disagree. It seems entirely reasonable to expect that
> unpack should return the same value passed to pack.
Robert: notice that a *Python* float (a *64-bit* C double internally) is here
being stored as a *32-bit* float, losing pre
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Hammond :
A tracking bug for the reference implementation of PEP397 - A Python launcher
for Windows.
--
assignee: mhammond
components: Documentation
files: pep-0397-reference.py
messages: 131723
nosy: mhammond
priority: normal
severity: normal
status: open
Mark Dickinson added the comment:
Fixed in 'default' branch. Note that the regression still exists in 3.2; I'm
not sure that it's worth backporting the two fixes.
--
status: open -> closed
___
Python tracker
<http://
Mark Dickinson added the comment:
I don't see a real problem here: both cmath.sqrt(-1) and (-1)**0.5 are
producing good approximations to the correct result, which is about as much as
you can hope for in general with floating-point algorithms.
I wouldn't want to start special-
New submission from Mark Dickinson :
[From a problem encountered by an EPD user, analyzed by Robert Kern]
There appears to be an
if isinstance(size_or_initializer, (int, long)):
check in the Python 2.x source for multiprocessing.RawArray. As a result, the
following works (as expected
Mark Dickinson added the comment:
Duplicate of issue 11673 :-)
--
resolution: -> duplicate
superseder: -> RawArray does not accept long
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11672>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Thanks for the patch.
Are there practical cases where the operator.index check is more useful that
the isinstance(..., (int, long)) check that you originally proposed
(off-tracker)? While I agree that it's the right fix in principle, the
operator.
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue11673>
___
___
Pyth
Changes by Mark Dickinson :
--
nosy: +jnoller
___
Python tracker
<http://bugs.python.org/issue11673>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Dickinson :
The documentation for the multiprocessing module says:
"If size_or_initializer is an integer, then it determines the length of the
array, and the array will be initially zeroed. "
But the part about the array being zeroed doesn't seem to b
Mark Dickinson added the comment:
Since this behaviour seems to have been present since at least Python 2.6, it's
tempting to call this a documentation bug.
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
Here's a patch that adds zeroing.
--
keywords: +patch
Added file: http://bugs.python.org/file21400/issue11675.patch
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
> The practical case I was thinking of was numpy integer scalar types
Hmm, true. But at least numpy.int instances pass an isinstance(..., int)
check, right? But that still leaves numpy.int as a
problem on 32-bit systems and Windows, and similarly for
Mark Dickinson added the comment:
As Daniel says, from_float expects a float object, not a Decimal instance.
What did you want to achieve in the following line:
self.from_float(value * decimal.Decimal(1.0))/decimal.Decimal(1.0)
?
By the way: in all current versions of Python, from_float
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Mark Dickinson :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Mark Dickinson :
--
title: Remove unneeded "context" pointer from getters and setters ->
test___all__
___
Python tracker
<http://bugs.pyth
Changes by Mark Dickinson :
--
title: test___all__ -> Remove unneeded "context" pointer from getters and
setters
___
Python tracker
<http://bugs.pyth
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.pyt
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue1446619>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Patch looks good to me. Thanks!
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9696>
___
_
Mark Dickinson added the comment:
Patience! I'm getting there...
--
___
Python tracker
<http://bugs.python.org/issue9696>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
> I'm sorry, I wasn't hurrying you. Just wanted to make sure you know.
No problem :-). Thanks for the fix!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
Mark Hammond added the comment:
Isn't the only problem here that the docs refer to SystemError instead of
SystemExit - eg 'raise SystemError("foo")' in an interactive session doesn't
terminate the process at all (and I don't believe it should)
Mark Hammond added the comment:
Note the quoted documentation in comment 1, the paragraph "Note that if an
otherwise unhandled SystemError ..."
I don't think that paragraph is correct - SystemError doesn't seem to terminate
Py_Main - but if you replace "SystemError
Mark Hammond added the comment:
@Rogi - you seem to have a problem with your keyboard - the 'h' and 'e' keys
seem to have been swapped.
The docs are wrong regardless - I don't think anyone would suggest the
behaviour match the docs regarding SystemError -
Mark Hammond added the comment:
@Rogi - you might like to re-read my responses a couple more times:
* I refer to SystemError as the docs *you quoted* refer to SystemError.
Therefore, we should *not* make the implementation match the docs - the docs
would be wrong *even if* we change Python
Mark Hammond added the comment:
> What teh docs says currently about SystemError calling
> exit() is just _WRONG_.
Correct - the docs should be fixed - which is what this bug is currently
addressing (see the "Components" and "Assigned To" fields)
> Also, I am
Mark Hammond added the comment:
For completeness, here is a doc patch against 2.6 which corrects the
documentation.
--
keywords: +patch
Added file: http://bugs.python.org/file21447/bug-6498.patch
___
Python tracker
<http://bugs.python.
Changes by Mark Hammond :
--
keywords: +needs review -patch
___
Python tracker
<http://bugs.python.org/issue6498>
___
___
Python-bugs-list mailing list
Unsub
Mark Hammond added the comment:
It will return 1 if you specify a script to run and that has an unhandled
exception.
--
___
Python tracker
<http://bugs.python.org/issue6
Mark Hammond added the comment:
Good catch - new patch with PyRun_SimpleStringFlags() corrected too.
--
keywords: +patch
Added file: http://bugs.python.org/file21448/bug-6498.patch
___
Python tracker
<http://bugs.python.org/issue6
1101 - 1200 of 12220 matches
Mail list logo
