New submission from almenon anon :
Code that runs fine in the command line can crash in the debugger
Note that because https://bugs.python.org/issue10933 is not fixed yet I'm
assuming this applies to all python 3 versions but it was confirmed in python
3.6
See https://github.com/microsoft
anon added the comment:
Any update on this?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19915>
___
___
Python-bugs-list
anon added the comment:
Any consensus?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24203>
___
___
Python-bugs-list
anon added the comment:
I'm struggling to get time for this. I hope someone else can take
responsibility. Sorry :-(
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
New submission from anon:
In threading.Thread isDaemon, setDaemon, getName, setName are not needed since
2.6 (preferring directly changing daemon or name instead). They should probably
be depreciated in 3.5 and removed later. isAlive has already been removed.
--
messages: 243277
nosy
anon added the comment:
Since I'm not familiar with the process I'd request someone creates the PEP.
But if really necessary I can try.
I just really want to see this in Python 3.5 - it's really essential to a
number of scientific methods. I know several open source projects that would
anon added the comment:
Above I included a first attempt however I don't think my code is good and I
couldn't figure out the case for negative integers. There's some discussion
above about its inclusion.
I like your x.bits suggestion actually, assuming x.bits returns an IntBitsView
object
anon added the comment:
Pros for x.bits being a view:
- seems slightly cleaner (in my opinion)
- can potentially abstract slicing bits without copying the underlying int
(e.g. x.bits[2:][4:])
Pros for x.bits being a function:
- Victor's point
- no need to depreciate x.bit_length
- no need
anon added the comment:
Giving it more thought: to get the int we'd need something like
int(x.bits[2:][4:]) which seems quite annoying for the general case of
int(x.bits[0:52]). So actually I'm not sure that views would add any more
abstraction for their extra complexity without becoming
anon added the comment:
@Georg: I don't think it would be as common but do agree it'd be useful.
I think it can be implemented efficiently in pure Python currently.
def with_bits(i, value, pos, width=1):
width = min(width, value.bit_length())
mask = ((1 width) - 1)
v = value mask
i
anon added the comment:
All I had meant by depreciating was changing the x.bit_length documentation to
point towards len(x.bits).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
anon added the comment:
That's something that a Python comitter would have to do isn't it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
anon added the comment:
I noticed feature freeze for 3.5 is in May 2015 which is actually only 7-8
months. It'd be really awesome if this feature could make it. Is there anyone
who can get this into 3.5?
--
status: open - pending
___
Python tracker
anon added the comment:
I think the case where i is negative can be handled by
bits_at(i, pos, width) = bits_at(~i, pos, width) ^ ((1 width) - 1)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
anon added the comment:
From what I can tell it's fairly easy to just add bits_at to int.
Indeed something like a mutable int type might be nice but that's really
outside the scope of this. And adding bits_at to int would still be desirable
anyway
anon added the comment:
Thank you! I will try to help in ways that I can such as testing.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
anon added the comment:
Antoine, I don't suggest that since you commonly want a fixed number of bits.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
anon added the comment:
Here is my very rough attempt at bits_at. It doesn't handle negative numbers
and I am not sure it's safe. This was my first time using Python internals.
Objects/longobject.c:
static PyObject *
long_bits_at(PyLongObject *v, PyObject *args)
{
PyLongObject *z = NULL
anon added the comment:
Here are some inadequate tests to add to Lib/test/test_long.py
def test_bits_at(self):
def bits_at(n, pos, width=1):
return (npos) ((1 width) - 1)
for n in [123, 777, (135)|(130)|(125)]:
for i in range(50
anon added the comment:
Both segments of code are public domain. It would be great if someone could
review them, improve them and produce a proper patch. I didn't handle the
negative case, which I hope someone else can add.
--
___
Python tracker
anon added the comment:
Some of the code may be under Python's license though. So I should clarify that
only MY parts of the two samples of code are public domain.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
anon added the comment:
Tim, I'm sorry to hear you can't accept my patch. I am afraid I want to stay
anonymous.
You have my word that I wrote the two code segments above (based on code
already in CPython) and that I put them in the public domain. But I appreciate
that the word of `anon` may
anon added the comment:
Then I think we're in agreement with regards to bits_at. :) What should happen
next?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19915
anon added the comment:
I like the i.bits_at(pos, width=1) suggestion. Unless slicing is chosen instead
this seems the most future-proof idea.
I think slicing semantically seems wrong but it might be more elegant. It
might also make catching errors harder (in the case where an int is sent
anon added the comment:
I didn't really consider floats. bit_length() is only provided to ints for
example.
I think a better solution to pick apart floats would be a function similar to
math.frexp, if it isn't already sufficient. float.bits_at(pos, width) seems a
worse solution because
New submission from anon:
For many numeric algorithms it's useful to be able to read individual bits at a
location in an integer. Currently there is no efficient way to do this. The
following function is the closest to this:
def bit_at(i, n): return (in)1
However in computing
New submission from anon unluckykit...@mailinator.com:
Many numeric algorithms require knowing the number of bits an integer has (for
instance integer squareroots). For example this simple algorithm using shifts
is O(n^2):
def bitl(x):
x = abs(x)
n = 0
while x 0:
n = n+1
x = x1
27 matches
Mail list logo
