Mark Dickinson added the comment:
...and your patch for setup.py applied in r69500, r69501, r69502, r69503.
Thank you!
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
I'll take a look.
--
assignee: -> marketdickinson
___
Python tracker
<http://bugs.python.org/issue3734>
___
___
Py
Mark Dickinson added the comment:
I don't see a huge need for this. In 2.6, 3.0 and higher, float(repr(x))
recovers x reliably across platforms
(modulo the occasional system strtod bug), even when x is an infinity or nan.
It's true that using float() doesn't help if you w
Changes by Mark Dickinson :
--
assignee: -> marketdickinson
___
Python tracker
<http://bugs.python.org/issue1732212>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Since PEP 754 has been rejected, I think this issue can be closed.
As noted at the top of PEP 754, much of the functionality of the patch is
already included (in somewhat different form) in 2.6 and 3.0.
--
resolution: -> out of date
status: o
Changes by Mark Dickinson :
--
assignee: -> marketdickinson
___
Python tracker
<http://bugs.python.org/issue1633648>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
I recommend closing this due to lack of interest/PEP/patch.
2.7 and 3.1 now have n.bit_length(), which matches Gregory's proposed
n.bitwid().
I'm semi-interested in the bit-access methods n.bit(x) and n.bit(hi, lo),
but not enough to write a PE
Mark Dickinson added the comment:
Some comments, while I remember:
* the argument to _Py_HashPointer is not always divisible by 8. It's
called to create hashes for various objects, including methodobjects; see
the line:
y = _Py_HashPointer((void*)(a->m_ml->ml_meth));
i
Mark Dickinson added the comment:
Closing.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue722647>
___
__
Mark Dickinson added the comment:
So there's a hint about what's happening here at the bottom of the section
http://docs.python.org/reference/datamodel.html#id5
of the docs, where it says:
"""In the current implementation, the built-in numeric types int, long and
New submission from Mark Dickinson :
In the 'coercion rules' section of the reference manual, at:
http://docs.python.org/dev/reference/datamodel.html#id5
it says:
"""Over time, the type complex may be fixed to avoid coercion."""
In 3.x, the complex ty
Mark Dickinson added the comment:
I think this issue comes down to a doc fix, though I've opened issue 5211
for anyone who fancies having a go at removing coercion from the complex
type.
Here's a doc patch.
--
assignee: marketdickinson -> georg.brandl
keywords
Mark Dickinson added the comment:
Comment by gumtree copied from issue3734 discussion:
> While Mark Dickinson's patch fixes the documentation, it does not
offer
> a solution to the original problem, which was rooted in a need to
> provide special behaviour based on the numeric
Mark Dickinson added the comment:
[gumtree]
> [...] does not offer
> a solution to the original problem, which was rooted in a need to
> provide special behaviour based on the numeric types. I made the
> original posting because I hoped that this problem could be resolved.
Plea
Mark Dickinson added the comment:
[Adam Olsen]
> The alignment requirements (long double) make it impossible to have
> anything in those bits.
Not necessarily, since not all pointers passed to _Py_HashPointer come
from a PyObject_Malloc. _Py_HashPointer is used for function pointers
a
Mark Dickinson added the comment:
Here's an updated patch, that errs on the conservative side:
- rotate instead of shifting, as suggested by Raymond. This costs
very little, and I admit to feeling uncomfortable about the
possibility of just throwing bits away
- explicit check f
Changes by Mark Dickinson :
--
assignee: -> marketdickinson
nosy: +marketdickinson
___
Python tracker
<http://bugs.python.org/issue4799>
___
___
Python-
Mark Dickinson added the comment:
It seems likely that this is a wine bug rather than a Python bug.
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
This is out of date for 2.5. Closing.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1507>
___
_
Mark Dickinson added the comment:
This issue is out of date from the perspective of python-pgsql, since
that's long been fixed.
It's difficult to figure out exactly what the issue is here. As best as
I can guess, it's something like the following. After:
class MyInt(o
Mark Dickinson added the comment:
PyNumber_Int deprecated in r69517, r69518.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Mark Dickinson added the comment:
I'm fine with rotating 4 bits instead of 3, especially if the timings look
good on 32-bit as well as 64-bit.
We should really benchmark dict lookups (and set membership tests) as well
as dict creation.
___
Python tr
Mark Dickinson added the comment:
> At four bits, you may be throwing away information and I don't think
> that's cool.
The current patch *does* do a rotation: it doesn't throw away any
information.
___
Python tracker
<http://b
Mark Dickinson added the comment:
> > - avoids comparing an unsigned long to -1
Just out of interest, why? The cast is unnecessary: there's no ambiguity
or undefinedness (the int -1 gets promoted to unsigned long, with
wraparound semantics), and neither gcc nor MSVC complains.
Mark Dickinson added the comment:
A couple of comments:
> Also, improved the utility over its cousin, range() by allowing floating
> point arguments.
Is this wise? From a numerical perspective, it seems to me that using
count with floating-point arguments is almost always going to
Mark Dickinson added the comment:
> Well, I had memories of a weird signed/unsigned problem (issue4935) and
> I wasn't sure whether it could raise its head in the present case or
> not.
I'm 99.9% sure that it's not a problem here. If it is a problem then it
needs to
Mark Dickinson added the comment:
> to write: count(Decimal('1.1'), Decimal('.1')) and get exact
> progressions.
That's pretty cool. :-)
> in itertools eons ago, there have been zero bug reports or user
> complaints about the issue. So, I
Mark Dickinson added the comment:
+1 for checking in pointer_hash4.patch, provided Raymond approves.
___
Python tracker
<http://bugs.python.org/issue5186>
___
___
Pytho
Mark Dickinson added the comment:
This needs to be merged before 3.0.1 goes out. I can't do it right now
since I don't have ssh access; will do it when I get home if no-one
beats me to it.
--
priority: critical -> release blocker
_
Mark Dickinson added the comment:
> Though I prefer you switch to x ^= x >> 4.
Okay, how about this one? Short and sweet. No loss of information
except when sizeof(void *) > sizeof(long) (unavoidable until someone
finds a way to fit all 64-bit pointers into a 32-bit integer typ
Mark Dickinson added the comment:
Merged (manually) to py3k in r69547; svnmerged to 3.0 and 2.6 in r69548,
r69549.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Changes by Mark Dickinson :
--
assignee: nnorwitz -> marketdickinson
___
Python tracker
<http://bugs.python.org/issue532631>
___
___
Python-bugs-list mai
Mark Miller added the comment:
This still occurs in the latest SVN checkout, and is preventing Python
from building on ARMV4L and ARMV5L OABI, dying during the test_float.py
compilation. The patch appears to solve this problem, however I have not
run a full suite of tests to ensure it doesn
Mark Dickinson added the comment:
+1 for the general idea from me too, assuming that all the details can
be worked out in a sane manner.
Is it worth opening a discussion about this on comp.lang.python?
--
nosy: +marketdickinson
___
Python tracker
Mark Dickinson added the comment:
> BTW, there's a warning in _struct.c:180 -> warning: ‘get_ulong’
> defined but not used, should I open a new issue?
Sure. Please could you add me to the nosy list if you do.
In my opinion, the struct module *really* needs an overhaul, espec
Mark Dickinson added the comment:
I'll take a look at this, provided Tim doesn't mind me stealing his
issue. (Please steal it back if so.)
Mark, could you please post the output from test_float?
--
assignee: tim_one -> marketdickinson
nosy: +ma
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file12978/time_object_hash.py
___
Python tracker
<http://bugs.python.org/issue5186>
___
___
Python-bug
Mark Dickinson added the comment:
> Apart from the misindentation
Apologies. My fault for editing Python files while at work, with a
substandard editor configuration...
> have you run the benchmark script with it?
I have now. See attached file for 3 sets of results (original, xor
v
Changes by Mark Dickinson :
Added file: http://bugs.python.org/file13069/pointer_hash5_xor.patch
___
Python tracker
<http://bugs.python.org/issue5186>
___
___
Python-bug
Changes by Mark Dickinson :
Added file: http://bugs.python.org/file13070/pointer_hash5_rotate.patch
___
Python tracker
<http://bugs.python.org/issue5186>
___
___
Pytho
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file13054/pointer_hash5.patch
___
Python tracker
<http://bugs.python.org/issue5186>
___
___
Python-bug
Mark Miller added the comment:
The following is where it fails un-patched:
Compiling /usr/local/lib/python2.6/test/test_float.py ...
Traceback (most recent call last):
File "/usr/local/lib/python2.6/compileall.py", line 156, in
exit_status = int(not main())
File "
Mark Dickinson added the comment:
Antoine, please check in a patch of your choice. I think we've beaten
this issue to death already. :-)
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Thanks, Mark.
A few comments:
- The patch seems incomplete. There are other places in the source tree
that care about endianness. I haven't done a thorough search, but the
native endianness support in the struct module comes to mind. There are
also
Mark Dickinson added the comment:
> native endianness support in the struct module comes to mind
Sorry: ignore that. The patch already covers this, since the struct
module just uses _PyFloat_{Unp,P}ack8.
___
Python tracker
<http://bugs.pyth
Mark Dickinson added the comment:
We still need to fix the compile failure somehow, though...
Mark, is there any way you can isolate the test(s) in test_float that are
causing compile failure? I'm suspicious of test_inf_as_str and
test_nan_as_str. Does test_float compile if you r
Mark Dickinson added the comment:
> If this feature request is accepted, I can provide the patches.
Well, that's not how things work: there isn't really a mechanism for
'accepting' a feature request. Even if there were, that wouldn't
guarantee acceptance of a pa
Mark Dickinson added the comment:
I think my -1 for adding the new format was premature: I was hoping to
find a way to fix marshal for the 'unknown' format, but the cleanest
solution does indeed appear to be to add the mixed-endian format. And
apart from the Python/compile.c oddi
Mark Miller added the comment:
I am in a position to test as much as needed. I am attempting to get
Gentoo's ARM/MIPS/Embedded distribution up to date on Python, and
noticed this build break. (Typically most embedded architectures are
several releases behind.)
I'll try this new patch
Mark Miller added the comment:
Would it be possible to get some feedback as to whether this is a
candidate for Python 2.6 on this patch?
___
Python tracker
<http://bugs.python.org/issue4
Mark Miller added the comment:
The new patch works correctly, by the way, on ARMv4L and ARMv5L OABI boards.
___
Python tracker
<http://bugs.python.org/issue1762
Mark Dickinson added the comment:
Thanks Martin and Mark Miller for the comments and testing.
I'm going to close this as "won't fix". This doesn't preclude ARM OABI
becoming a supported platform at some point in the future, just not
right now.
--
resolu
Mark Miller added the comment:
Not entirely. I applied what you had for the autoconf section to my
configure, since I do not have autoconf installed in my environment.
Specifically, this part of configure is what's messing with the build:
if test x$TARGET = xMIPS; then
MIPS
Mark Dickinson added the comment:
I'll see if I can find time to look at this; I'm currently looking at
various ways to improve long integer arithmetic in 2.7/3.1.
--
assignee: tim_one -> marketdickinson
___
Python tracker
<http:/
New submission from Mark Dickinson :
Here are various minor portability and standards-compliance fixes,
optimizations and cleanups for the trunk version of
Objects/longobject.c. Most of these also apply to py3k.
I'll admit to an ulterior motive here: the aim is to extract all
the trivial
Mark Dickinson added the comment:
The most recent patch is out of date and no longer applies cleanly. I'm
working on an update.
___
Python tracker
<http://bugs.python.org/i
Mark Hammond added the comment:
It is still present, but I'm not sure what problems can be seen due to
this so can't comment on its desirability. It would also introduce a
backwards compatability concern but I've not enough experience to know
how much of a problem that would
Mark Dickinson added the comment:
Thanks, Antoine and Gregory!
Committed, r69634 and r69635.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
New submission from Mark Florisson :
The load method, which is also called from the initializer if input is
provided, doesn't create Morsel objects for things other than strs,
because it calls self.update(rawdata), which does not invoke the custom
__setitem__.
The documentation states that
New submission from Mark Sapiro :
The message method get_params() and the related get_param() and
get_filename() do not properly decode an RFC 2231 encoded parameter such
as the following:
Content-Disposition: inline;
filename*0="Re: [Mailman-Users] Messages shunted with \"
Mark Dickinson added the comment:
Updated patch against py3k. I'm interested in getting this into the trunk
as well, but py3k is more important (because *all* integers are long
integers). It's also a little more complicated to do this for py3k
(mostly because of all the sma
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file11976/30bit_longdigit4.patch
___
Python tracker
<http://bugs.python.org/issue4258>
___
___
Python-bug
Mark Dickinson added the comment:
Forgot to mention: you'll need to rerun autoconf and autoheader after
applying the patch and before doing ./configure
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Darn. That's really very annoying. Apologies for missing this one.
Thanks for the quick fix, Benjamin.
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Closing this due to lack of feedback.
Ali Polatel's report looks like an entirely separate issue; most likely an
alpha libm bug.
--
resolution: -> out of date
status: pending -> closed
___
Python tra
Mark Shannon added the comment:
Serhiy, what is the advantage of __import__ being slower?
Not counting the argument clinic generated code, the PR doesn't add any code
and improves the docstring.
--
___
Python tracker
<https://bugs.py
Mark Shannon added the comment:
New changeset 5498a61c7c25db6f9e76032aa9c5153d79e09889 by Brandt Bucher in
branch 'main':
bpo-46841: Don't use an oparg counter for `STORE_SUBSCR` (GH-31742)
https://github.com/python/cpython/commit/5498a61c7c25db6f9e76032aa
Mark Shannon added the comment:
There are three kinds of changes that we might want to watch (that I can think
of right now):
1. Any change.
Rather coarse and potentially expensive. Used by Cinder.
2. A new key being added (or a change to the keys version as a proxy).
Useful for detect
Mark Dickinson added the comment:
This is expected. Your timing measures the time for garbage collection of the
large arrays in addition to the time for the result to be returned.
In the line `result = myfunc()`, the name `result` gets rebound to the value of
`myfunc()`. That means that
Change by Mark Shannon :
--
pull_requests: +29915
pull_request: https://github.com/python/cpython/pull/31817
___
Python tracker
<https://bugs.python.org/issue46
Mark Shannon added the comment:
You might not like global variables, they may not show up much in benchmarks,
but people do use them. I suspect a lot of jupyter notebooks have quite a few
global variables.
There should not be much of a slowdown for this code when watching `CONST`:
CONST
Mark Shannon added the comment:
Another use of this is to add watch points in debuggers.
To that end, it would better if the callback were a Python object.
The overhead is relatively small if using the vectorcall protocol.
If the call overhead matters that much, there is something wrong as
Mark Shannon added the comment:
New changeset 304197b3820309e3ed695ff3e6a71461881a1728 by Kumar Aditya in
branch 'main':
bpo-46944: use FASTCALL calling convention in generator.throw (GH-31723)
https://github.com/python/cpython/commit/304197b3820309e3ed695ff3e6a714
Mark Dickinson added the comment:
> why it costs lots of time when del a large array?
That's probably a question for the NumPy folks, or possibly for Stack Overflow
or some other question-and-answer resource. It'll depend on how NumPy arrays
are de-allocated.
> Is there an
Mark Roseman added the comment:
Just a note, that an (updated) version of the auto-generated API reference has
been "officially" added to TkDocs ... see https://tkdocs.com/pyref/
Few more things I'd like to do with it in the short term, but it's a decent
starting point
Mark Dickinson added the comment:
I forgot to update here:
> PEP at https://github.com/python/peps/pull/2295
For the record, PEP 682 has been accepted.
--
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
pull_requests: +29996
pull_request: https://github.com/python/cpython/pull/31901
___
Python tracker
<https://bugs.python.org/issue46
Change by Mark Shannon :
--
pull_requests: +30001
pull_request: https://github.com/python/cpython/pull/31908
___
Python tracker
<https://bugs.python.org/issue45
Mark Shannon added the comment:
Let me give you an example.
#module eggs
eggs_var = 0 # a variable, maybe a counter or similar
EGGS_CONST # a constant
#module spam
import eggs
spam_var # Another variable
def foo():
use(eggs.EGGS_CONST)
-
We will want to treat
Mark Shannon added the comment:
sys.settrace line events cannot use the co_lines table. They need additional
state, as we don't want to trace the same line twice (unless there is a
backwards jump).
Using the start of a entry in `co_lines` doesn't work when some entries have no
l
Mark Shannon added the comment:
New changeset 099f75614100e88ed90b68d20a51a8d9c22f81a7 by Mark Shannon in
branch 'main':
bpo-45923: Decouple suspension of tracing from tracing flag. (GH-31908)
https://github.com/python/cpython/commit/099f75614100e88ed90b68d20a51a8
Change by Mark Shannon :
--
pull_requests: +30025
pull_request: https://github.com/python/cpython/pull/31933
___
Python tracker
<https://bugs.python.org/issue46
Mark Mentovai added the comment:
Another use case for preexec_fn: establishing a new controlling terminal,
typically in conjunction with start_new_session=True. A preexec_fn may do
something like
os.close(os.open(os.ttyname(sys.stdin.fileno(), os.O_RDWR)))
with discussion at
https
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Mark Shannon :
The RESUME instruction was added to make resumption points explicit in the
bytecode. This makes it easier to implement tracing, quickening, and interrupt
checks as there is an explicit place to perform these checks.
Unfortunately, it also has considerable
New submission from Mark Shannon :
When tracing, the event supplied is insufficient to determine what is actually
happening.
E.g. A "call" event could be a call to a function or resuming a generator or
coroutine.
Adding a state field to the FrameObject would allow these c
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +30052
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31963
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 2bde6827ea4f136297b2d882480b981ff26262b6 by Brandt Bucher in
branch 'main':
bpo-46841: Quicken code in-place (GH-31888)
https://github.com/python/cpython/commit/2bde6827ea4f136297b2d882480b98
Mark Shannon added the comment:
You are on own if you create code objects by calling `types.CodeType`.
The docs could be a lot clearer about that, though.
--
___
Python tracker
<https://bugs.python.org/issue45
Mark Shannon added the comment:
The `JUMP_ABSOLUTE` doesn't have a line number, as it doesn't correspond to any
source.
The jump back to the top could follow either the `if i >= 0:` or the `pass`, so
cannot have a line number.
Don't expect every bytecode to map directly
Mark Shannon added the comment:
New changeset 49daf6dba8178c5ae5d4d65408b20566d39c36a8 by Mark Shannon in
branch 'main':
bpo-47045: Remove `f_state` field (GH-31963)
https://github.com/python/cpython/commit/49daf6dba8178c5ae5d4d65408b205
Mark Shannon added the comment:
I think this is fixed (for 3.11 at least) by
https://github.com/python/cpython/pull/31888
--
___
Python tracker
<https://bugs.python.org/issue46
Mark Shannon added the comment:
I'm looking into adding two new APIs.
One to round out the getters for FrameObject and one to introspect the internal
frame stack.
It would probably make more sense to add this capability to the frame stack
API, as it would avoid creating the frame obje
Change by Mark Shannon :
--
pull_requests: +30145
pull_request: https://github.com/python/cpython/pull/32055
___
Python tracker
<https://bugs.python.org/issue42
Change by Mark Shannon :
--
pull_requests: +30147
pull_request: https://github.com/python/cpython/pull/32055
___
Python tracker
<https://bugs.python.org/issue42
New submission from Mark Bell :
The docstring for `random.choices` indicates that
```
import random
random.choices(population, k=1)
```
should produce a list containing one item, where each item of `population` has
equal likelihood of being selected. However `random.choices` draws elements for
Mark Bell added the comment:
To give two more consequences of `random.choices` using floating point
arithmetic:
1) When doing `random.choices([A, B, C], weights=[2**55, 1, 1])` the cumulative
weight to bisect for is selected using `floor(random() * (2**55 + 1 + 1 +
0.0))`. Since this is
Mark Shannon added the comment:
With the introduction of zero cost exceptions, there is no block stack.
--
resolution: -> out of date
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
New changeset d7163bb35d1ed46bde9affcd4eb267dfd0b703dd by Mark Shannon in
branch 'main':
bpo-42197: Don't create `f_locals` dictionary unless we actually need it.
(GH-32055)
https://github.com/python/cpython/commit/d7163bb35d1ed46bde9affcd4
Change by Mark Shannon :
--
pull_requests: +30190
pull_request: https://github.com/python/cpython/pull/32114
___
Python tracker
<https://bugs.python.org/issue40
2901 - 3000 of 12223 matches
Mail list logo