Mark Dickinson added the comment:
> I'd prefer to drop the ExtendedContext completely.
We have to be careful not to break existing 3rd party code, though. A
newly-designed decimal module, prepared with 20/20 hindsight, probably wouldn't
include an ExtendedContext with the curre
Mark Hammond added the comment:
the pywin32 DLLs have 2 heads. They are Python extension modules as well as
regular DLLs. They are built by distutils and therefore have no manifests - I
think many packages use distutils to build their extension modules - it is just
that they usually don&#
Mark Hammond added the comment:
Another consideration here will be how distutils will work in a python with
restricted permissions - the pattern of "just run 'setup.py install'" will not
work unless it is done from an elevated command-prompt. As I expect this would
f
Mark Summerfield added the comment:
IMO there's another problem with subprocess portablity---the lack of control
over encodings: see issue 6135.
--
nosy: +mark
___
Python tracker
<http://bugs.python.org/i
New submission from Mark Dickinson :
http://speleotrove.com/decimal/daexcep.html specifies a precedence for decimal
exceptional conditions (scroll right to the bottom of the page):
"""The Clamped, Inexact, Rounded, and Subnormal conditions can coincide with
each other or with o
Changes by Mark Dickinson :
--
nosy: +facundobatista, rhettinger, skrah
___
Python tracker
<http://bugs.python.org/issue8567>
___
___
Python-bugs-list mailin
New submission from Mark Dickinson :
Test issue: I just got a 'there was a problem with your submission: tracker
maintainers informed' message when submitting issue 8567, though it looks as
though the submission succeeded.
Here's a test issue to try to reproduce.
Steps t
Changes by Mark Dickinson :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8568>
___
___
Python-bugs-list
Changes by Mark Dickinson :
--
stage: -> unit test needed
___
Python tracker
<http://bugs.python.org/issue8567>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Regarding the flags that should be set, the relevant portion of the
specification is at the top of the page mentioned above:
"""
For each condition, the corresponding signal in the context is given, along
with the defined result. The va
Mark Dickinson added the comment:
Raising priority: I'd like to get the precedence fix into 2.7.
--
priority: normal -> high
___
Python tracker
<http://bugs.python.or
Mark Dickinson added the comment:
Thanks, Stefan. The cdecimal and decnumber behaviour sounds like the ideal one
to me.
I'm not sure how easy it would be to adopt this behaviour for decimal: it could
require some significant rewriting, so we may have to leave decimal as it is
and cal
Mark Dickinson added the comment:
I think this is superseded by issue 7332, which is now fixed in trunk (but not
in 2.6).
--
nosy: +mark.dickinson, pitrou
resolution: remind -> out of date
status: open -> closed
superseder: -> python script segment
Mark Dickinson added the comment:
Closing as fixed.
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issue2715>
___
___
Python-bugs-list mai
Changes by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue2715>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue8540>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Closing as out of date.
--
nosy: +mark.dickinson
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
As far as I can tell there's no bug in 3.x: the 3.x range happily accepts an
instance of a class that defines __index__.
--
versions: -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Currently, in trunk, I get:
>>> range(0.0, 11.0, 1.1)
Traceback (most recent call last):
File "", line 1, in
TypeError: range() integer start argument expected, got float.
But with Alexander's patch on trunk, I get:
>>>
Mark Dickinson added the comment:
> IIRC, it was a very deliberate choice not to allow float arguments to range
Ignore this bit. IDRC. It was a deliberate choice not to let something
range(0.0, 1.0, 0.1) work to give [0.0, 0.1, ...], since the usual
floating-point difficulties g
Mark Dickinson added the comment:
Alexander: range *does* still accept such arguments (in 2.7); just not floats:
>>> from decimal import Decimal
>>> range(Decimal(20), Decimal(20))
[]
>>> range(Decimal('1e100'), Decimal('1e100'))
Traceback
Mark Dickinson added the comment:
Here's a quick fix for Decimal._fix, that just makes sure that it raises
exceptions in the appropriate order.
I'll also try to apply the check_precedence methodology included in this patch
to every single testcase. I don't think it's re
Changes by Mark Dickinson :
Added file: http://bugs.python.org/file17163/issue8567.patch
___
Python tracker
<http://bugs.python.org/issue8567>
___
___
Python-bugs-list m
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file17162/issue8567.patch
___
Python tracker
<http://bugs.python.org/issue8567>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
Decimal is behaving in exactly the same way as MyInt, isn't it? What do you get
for range(MyInt(20), MyInt(20))?
--
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Better patch, that checks exception precedence for every test case when
EXTENDEDERRORTEST is defined. With this patch, I get 11 test failures in
test_decimal (down from 50 test failures before the Decimal._fix fix).
Now we just have to track down the
Mark Dickinson added the comment:
Final patch (?!) fixes all the test failures due to exception precedence issues.
--
Added file: http://bugs.python.org/file17167/issue8567_3.patch
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
> Hmm, maybe there is a 2.7 bug here after all:
Yes, indeed! Which is why I was suggesting 'wont fix' rather than 'out of
date' :)
The bltinmodule2.diff patch from Robert causes a segfault in test_builtin on my
system; I haven'
Changes by Mark Dickinson :
--
resolution: out of date ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bugs-
Mark Dickinson added the comment:
A couple of suggestions regarding the patch:
(1) I'd suggest leaving the first part of handle_range_longs intact, up to and
including the "/* ilow and ihigh correct now; do istep */" block. Then build
out the three "if (!PyInt_Check(...
Mark Dickinson added the comment:
Alexander, I think it should be as simple as replacing the if
(!PyInt_Check(ilow) && ...) block with something like this:
if (!PyInt_Check(ilow) && !PyLong_Check(ilow)) {
PyNumberMethods *nb = Py_TYPE(ilo
Mark Dickinson added the comment:
Thanks---the new patch looks good. Pulling the argument conversion out into a
separate function makes the whole thing much cleaner.
I still have a couple of nits:
- Please add a comment before get_range_argument indicating
what it's for. I&#
Mark Dickinson added the comment:
Thinking about it a bit more, I really would prefer get_range_argument not to
steal a reference. If I'm reading a bit of C code and encounter something like:
obj = transform(obj);
if (obj == NULL) ...
my hindbrain immediately starts fretting
Mark Dickinson added the comment:
BTW, I've changed the various "nb_int should return int object" error messages
in Objects/intobject.c to the more meaningful and accurate message: "__int__
method should return an
Mark Dickinson added the comment:
I doubt this is a Python issue, since the crypt function does little more than
wrap the system crypt function.
What does your man page for crypt say? Are you sure you're providing a salt
that the system crypt accepts?
--
nosy: +mark.dick
Changes by Mark Dickinson :
--
resolution: -> invalid
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue8596>
___
___
Python-bugs-
Changes by Mark Dickinson :
--
stage: unit test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue8567>
___
___
Python-bugs-list mai
Mark Dickinson added the comment:
I'm also seeing this on OS X 10.6. It seems to have started with r80243.
--
nosy: +mark.dickinson, ronaldoussoren
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
To clarify, that last message was about trunk, where this test is failing for
me since r80243. Adding 2.7 to the versions.
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
> FreeBSD's crypt(3) doesn't explain the 'salt' for Blowfish crypt exactly.
Reading:
http://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&sektion=3&manpath=FreeBSD+7.2-RELEASE&format=html
and especially the section
Mark Dickinson added the comment:
Okay, thanks for the update!
Looks like the FreeBSD crypt manpage could use some work...
--
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
You'd be better off asking this on the python mailing list
http://mail.python.org/mailman/listinfo/python-list (or in some other forum);
this tracker is for reporting bugs in Python itself, not bugs in code written
in Python.
[The problem y
Mark Dickinson added the comment:
Thanks for the fixes. The latest patch looks good to me.
Alexander, is it okay for me to commit this?
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/iss
Mark Dickinson added the comment:
Hi Alexander,
I took the liberty of messing with your patch slightly; I didn't want to ask
you to make further changes since the patch was fine, and my messing was mostly
just to satisfy my own fussiness (only the first two items were really
nece
Mark Dickinson added the comment:
Re emacs:
C-c . python
should set a python 2.x-friendly indentation mode.
There's also a python-new style floating around somewhere on the web (not part
of emacs as standard), suitable for the 4-space indent style that's supposed to
be used fo
Mark Dickinson added the comment:
Precedence fixed in r80753 through r80756.
That still leaves open the problem of what flags should be set; however, we
should discuss this in a separate issue.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -&g
New submission from Mark Dickinson :
In an effort to keep to one issue per tracker item, I'm pulling this issue out
of the comments on issue 8567.
Issue: if a Decimal operation raises several signals, and one or more of those
signals is trapped, how should that operation affect
Mark Dickinson added the comment:
[Some of the Alexander's questions about procedures aren't really related to
this issue; I've answered those offline. Here are the answers to the others.]
>> - initialize low to NULL, to match the Py_XDECREF(low) (could change
&g
Mark Dickinson added the comment:
Applied to trunk in r80758.
Do people want this to go into 2.6 as well? The patch would need to be
modified to produce a warning for floats instead of giving a TypeError (and the
tests would need to be modified to test for that warning
Mark Dickinson added the comment:
+1 for forward-porting/adapting relevant tests to py3k.
--
assignee: mark.dickinson -> belopolsky
___
Python tracker
<http://bugs.python.org/iss
New submission from Mark Dickinson :
test_buffered_reader test_gzip is failing for me since r80720, on trunk on OS X
10.6.3:
==
ERROR: test_buffered_reader (__main__.TestGzip
Mark Dickinson added the comment:
Yep, that's enough to trigger it:
Python 2.7b1+ (trunk:80760, May 4 2010, 19:27:27)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>&
Mark Dickinson added the comment:
That fixes the failure.
--
___
Python tracker
<http://bugs.python.org/issue8614>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Thanks, Antoine. Applied in r80762 through r80765.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.pytho
Mark Dickinson added the comment:
Since r80665, a
./configure --with-pydebug
seems to give compilation with -O2 (tested on OS X and Linux). Is this
intentional?
I'm getting, e.g.,
gcc -c -g -O2 -g -Wall -Wstrict-prototypes -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Modules/pyt
Mark Dickinson added the comment:
Yes, that's a good point. It would be nice for e.g. "Inexact => Rounded"
invariants to be, well, invariant.
I agree that the cdecimal behaviour is the correct one. I'm looking for wiggle
room here because I don't really want
Mark Dickinson added the comment:
> Yes. I've restored the previous behavior of configure to
> have AC_PROG_CC determine CFLAGS defaults.
Just to be clear, the previous behaviour has *not* been restored. Up until
r80665, a '--with-pydebug' build did not include optimi
Mark Dickinson added the comment:
Ah, I understand now: -O2 started appearing in debug builds in r79218, which
changed the Makefile to respect CFLAGS. I tested a variety of revision, but
failed to test revision in between that and Victor's c
New submission from Mark Dickinson :
When doing a debug build of Python with gcc, without any previous setting of
CFLAGS, the '-O2' flag is now automatically included.
This behaviour started in r79218.
It would be nice to restore the original behaviour, if possible, since the
op
Mark Dickinson added the comment:
Just double checked the gcc manual. From:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
"""If you use multiple -O options, with or without level numbers, the last such
option is the one th
New submission from Mark Dickinson :
Lines 3884 and 3890 of Objects/typeobject.c (trunk, r80782), which check for a
subclass overriding __eq__ (or __cmp__) but not __hash__, call PyErr_WarnPy3k
but don't check the return value. [This was reported when compiling Python
with clang.] Thi
Mark Dickinson added the comment:
Hmm. Fixing this isn't easy: a simple 'if (inherit_slots(...) < 0) goto
error;' produces a huge reference leak in PyType_Ready.
--
___
Python tracker
<http://bugs
Mark Dickinson added the comment:
Thanks for the report! Fixed in r80826 through r80829.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
Applied in r80832 (trunk), r80834 (py3k). Thanks, all.
--
assignee: -> mark.dickinson
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.o
Mark Dickinson added the comment:
Perfect! Committed in r80836 (py3k); fixed that one test and comment in
r80842 in trunk.
Alexander, do you want to tackle the 2.6 backport?
BTW, I think in most cases it's unnecessary to add Python 3.3 to the Versions
field above, since there
Mark Dickinson added the comment:
Bah. That's r80841, not r80842.
--
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bugs-list m
Changes by Mark Dickinson :
--
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
Mark Dickinson added the comment:
That should have been r80839, not r80842.
--
___
Python tracker
<http://bugs.python.org/issue1533>
___
___
Python-bugs-list m
Mark Hammond added the comment:
I tried to use this in place of shlex for parsing IMAP responses for the
'imapclient' package. A couple of things struck me.
* The class no longer has a next() method but probably should be added for b/w
compat.
* The class no longer has a 't
Mark Dickinson added the comment:
> I've never done a maintenance branch backport, but here is my attempt:
[...]
Yes, that sounds about right. But after all that, you'll still need to modify
the patch somewhat, since the requirements are different for 2.6: floats
Mark Dickinson added the comment:
> As far as I know, it is a binary search tree,
It's not: it's based on a hash table. It's essentially a dict with keys but
no values. An additional complication is that the hash table can be very
sparsely filled, in the case of a larg
Mark Dickinson added the comment:
This is correct behaviour. Note that .seconds is only one of the three
attributes that contribute to the value of a timedelta: the others are
.microseconds and .days. A timedelta is normalised in such a way that
td.seconds and td.microseconds are always
Mark Dickinson added the comment:
Hmm. My example did make me realize that the total_seconds() method isn't as
accurate as it could be. I'll open another issue for this.
--
___
Python tracker
<http://bugs.python.
New submission from Mark Dickinson :
I just noticed (while responding to issue 8643) that timedelta.total_seconds()
has some accuracy problems, especially for negative timedeltas:
Python 3.2a0 (py3k:80840:80842, May 7 2010, 12:29:35)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "
Mark Dickinson added the comment:
P.S. This change would also make total_seconds() consistent with division by
timedelta(seconds=1):
>>> td / timedelta(seconds=1)
-0.000123
In fact, this might even be a good way to re-implement total_seconds i
Mark Dickinson added the comment:
Yes, okay---that makes some sense; I'm happy to leave floats as they are
(i.e., DeprecationWarning for small floats; TypeError for larger floats) and
just fix use of __int__ for non-floats.
I'll look at the patch.
--
assignee:
Mark Dickinson added the comment:
The backport looks fine. Applied in r80917. Thanks, Alexander.
--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Mark Dickinson added the comment:
Thanks for the patch! Comments, in increasing order of fussiness:
(1) there should be a Py_DECREF(total_microseconds) in the case that the
"PyLong_FromLong(100L)" call fails
(2) in the docstring, replace 'loose' by 'lose'
Mark Dickinson added the comment:
Grr. s/docstring/docs/
--
___
Python tracker
<http://bugs.python.org/issue8644>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Thanks! Fixed in r80961 (trunk) and r80962 (py3k).
BTW, are there any particular commit messages or news entries that indicate a
switch to two's complement? I've looked for these in the past, but not found
them.
--
nosy: +mark.dickinson
Mark Dickinson added the comment:
I found:
- Long integer shift/mask operations now simulate 2's complement
to give more useful results for negative operands
in Misc/HISTORY, for the Python 0.9.6 release. That's different, though: it's
about Python's semantics, not C
Mark Dickinson added the comment:
Ah, now I understand :)
r2604 introduced a scheme where for a negative PyLongObject x with n digits,
the value stored in x->ob_size was -1-n. A little like ones' complement, but
unrelated to anything to do with the platform integer representation
Mark Dickinson added the comment:
Looks good to me.
I definitely think this should go into 2.7 as well; total_seconds has only
seen the light of day in the beta releases so far, so it's unlikely we'd break
anyone's code with this change. (And IMO this is a bugfix, not a feat
Mark Dickinson added the comment:
If you want a second (third?) opinion, we could ask Antoine.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
[Antoine declines to offer an opinion.]
Committed to py3k in r80979. I moved the Misc/NEWS entry from the 'Library'
section to the 'Extension Modules' section.
Leaving open for the 2.7 backport.
--
__
Changes by Mark Dickinson :
--
resolution: -> accepted
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue8644>
___
___
Python-bugs-lis
Mark Dickinson added the comment:
I also have my doubts about the other 'goto error' lines in PyType_Ready, but I
haven't figured out how to trigger those gotos in normal code.
Trying to figure out how to clean up properly on error in PyType_Ready is
making my head hurt.
As
Mark Dickinson added the comment:
Ronald, r80967 makes test_site fail on my machine, with the following output:
==
FAIL: test_getsitepackages (__main__.HelperFunctionsTests
Mark Dickinson added the comment:
r81004: Remove extra closing bracket and comma introduced in r80969. (This was
causing misdetection of the OS X 10.5 SDK on Linux and OS X, and a
test_platform failure on OS X.)
--
nosy: +mark.dickinson
Mark Dickinson added the comment:
Perfect! Applied in r81020.
You're correct that n/10**6 and n/1e6 aren't the same thing, at least for n
large enough:
Python 2.7b2+ (trunk:81019:81020, May 9 2010, 10:33:17)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", &
Mark Dickinson added the comment:
Hmm. The 'delay_traps' context manager idea doesn't quite work here. A
problem occurs if (for example) an Overflow occurs during the with block; in
that case, Overflow should be raised at the end of the with block. That's
fine, exce
Mark Dickinson added the comment:
Umm. Please pretend I didn't write this:
> One simple change that might help would be to have all Decimal
> exceptions derive from a common `DecimalException` superclass, making
> it easier to catch just decimal exceptions in a tr
Mark Dickinson added the comment:
Fixed in r81024 (py3k), r81025 (release31-maint).
--
components: +Library (Lib)
nosy: +mark.dickinson
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Py
Mark Dickinson added the comment:
I think this was fixed in r80969, but confirmation would be good.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue8
Mark Dickinson added the comment:
Sorry; r81004, rather.
--
___
Python tracker
<http://bugs.python.org/issue8673>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Thanks for the patch. I agree that undefined behaviour (e.g., from signed
overflow) should be avoided where at all possible.
Do you have any Python examples that failed to trigger the overflow on your
platform? If so, it would be useful to add them to Lib
Mark Dickinson added the comment:
Unless you have an explicit exploit, I think the 'type' should be 'behavior'
rather than 'security'.
--
stage: -> unit test needed
type: security -> behavior
versions:
Mark Dickinson added the comment:
Okay, it looks to me as though all those 'int' lengths should really be
'Py_ssize_t'. I don't think that's something we can change in 2.6, though;
probably not in 2.7 either, since we're getting too close to the release
Mark Dickinson added the comment:
Yes, writing portable tests turns out to be tricky; I also don't want to write
tests based on int that'll fail when/if Py_ssize_t is substituted.
Applied the patch (with a couple of minor changes) in r81045 through r81048.
I'll open anothe
New submission from Mark Dickinson :
The audioop module still uses 'int' for most of its sizes; it would be better
if it used 'Py_ssize_t' instead, so that data aren't artificially limited to
2Gb on 64-bit systems.
Converting ought to be a fairly straightforward ta
2001 - 2100 of 12223 matches
Mail list logo
