Daniel Stutzbach added the comment:
With regret, I have not had time to work on patches and am unlikely to have
time in the near future.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9859
New submission from Daniel Stutzbach:
local_clear in _threadmodule.c walks the list of threads without holding
head_mutex. Since the list of threads can change when holding only head_mutex
and not on the GIL, the list can change while local_clear is executing, which
may cause Bad Things
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19081
___
___
Python-bugs-list
Daniel Stutzbach added the comment:
As the person originally trying to take the mean of timedelta objects, I'm
personally fine with the workaround of:
py m = statistics.mean([x.total_seconds() for x in data])
py td(seconds=m)
datetime.timedelta(2, 43200)
At the time I was trying to take
Changes by Daniel Stutzbach stutzb...@google.com:
--
assignee: stutzbach - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2226
Daniel Stutzbach stutzb...@google.com added the comment:
On Tue, Apr 17, 2012 at 4:08 AM, Antoine Pitrou rep...@bugs.python.org wrote:
has_finalizer() in gcmodule.c doesn't check for weakref callbacks, so a
weakref callback can still be invoked from tp_dealloc.
Unless I'm mistaken, weakrefs
Daniel Stutzbach stutzb...@google.com added the comment:
Wouldn't the subclass inherit the False value? Then the user would need to
remember to override the value again in the subclass, which is error prone.
Antoine: I've used the pattern you describe on a couple of occasions
Daniel Stutzbach stutzb...@google.com added the comment:
On Fri, Apr 6, 2012 at 12:51 PM, Jim Jewett rep...@bugs.python.org wrote:
__del__ methods do run, even if an object was collected by the cycle
detector. And they can't do any harm that couldn't also be done by a C
finalizer
Daniel Stutzbach stutzb...@google.com added the comment:
Are __del__ and tp_del getting conflated in this conversation? I don't see a
__del__ method on generator objects:
filfre:$ python3.1
Python 3.1.2 (r312:79147, Dec 9 2011, 20:47:34)
[GCC 4.4.3] on linux2
(i for i in range(5)).__del__
Daniel Stutzbach stutzb...@google.com added the comment:
Ah - in your first example (the one with 3 lines) did you mean to use .extend
instead of .append?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13804
Daniel Stutzbach stutzb...@google.com added the comment:
If I'm understanding Martin Häcker's code correctly, the list comprehension
equivalent is:
self.questions = [topic.questions for topic in self.topics]
The reduce() variants are not only much harder to read, but they will take
O(n**2
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13742
___
___
Python-bugs-list
Daniel Stutzbach stutzb...@google.com added the comment:
Gladly. :-)
--
resolution: - out of date
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8654
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12682
___
___
Python-bugs-list
Daniel Stutzbach stutzb...@google.com added the comment:
Could you add a comment above the lines defining self._BytesIO, describing why
they're being set? Someone else might see them as unnecessary and rip them out
if there's no explanation.
Can a test launch Python in a subprocess, set up
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12612
___
___
Python-bugs-list
Daniel Stutzbach stutzb...@google.com added the comment:
On Sat, Jul 16, 2011 at 2:04 AM, Eli Bendersky rep...@bugs.python.orgwrote:
Therefore, I propose to change this error message to:
unicode argument expected, got '%s'
as Terry suggested.
Sounds good to me.
--
Added file
Daniel Stutzbach stutzb...@google.com added the comment:
On Wed, Jun 15, 2011 at 8:10 PM, Nick Coghlan rep...@bugs.python.orgwrote:
I'd like to add a new constant to the math module:
tau = 2*math.pi
Rather than repeating all the reasons for why tau makes more sense than pi
Daniel Stutzbach stutzb...@google.com added the comment:
Comment: This rule applies to special methods like __getitem__
and __setitem__. 'lis.append(item)' is equivalent to
lis.__setitem__(len(lis):len(lis), item), so it should not be so
surprising that it has the same return.
It's not true
Changes by Daniel Stutzbach stutzb...@google.com:
--
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8777
Daniel Stutzbach stutzb...@google.com added the comment:
SGTM. I've written code where this would have been useful.
Could you write a patch?
--
nosy: +stutzbach
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Daniel Stutzbach stutzb...@google.com added the comment:
-0 on making it valid ever, due to the different meaning in many other
languages.
-1 on making it valid while many still use a version of python where it's valid
with a different meaning. Maybe for Python 4. ;-)
--
nosy
Daniel Stutzbach stutzb...@google.com added the comment:
I misread the original request. I'm +1 on making the following work, if it
doesn't work already:
class MySubClass(MyAbstractClass):
SOME_LIMIT = 5 # Implements abstract property with fixed value
We should be able to check
Daniel Stutzbach stutzb...@google.com added the comment:
Daniel, the behavior you describe is already present in Python 3.2.
Awesome. :)
Do you have a compelling use-case for making self.x = 5 satisfy an
abstractproperty requirement? One of the problems with that approach
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11994
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11335
Daniel Stutzbach stutzb...@google.com added the comment:
Looking at this again, I agree with John. For BufferedIOBase, read() is
abstract while readinto() is concrete. That seems backward, and, indeed, it's
the opposite of RawIOBase, where readinto() is abstract and read() is concrete
Daniel Stutzbach stutzb...@google.com added the comment:
I checked in a fix to 3.3 just before the transition to hg. I confess that
I've been procrastinating on getting hg set up properly, which is why I haven't
gotten to checking this in to 3.2.
Georg, if I get this in by Wednesday
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11854
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6634
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11845
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11707
___
___
Python-bugs-list
Daniel Stutzbach stutzb...@google.com added the comment:
I'm confused by the patch (ed0259230611). The patch comment and the NEWS item
state the returned socket is now always non-blocking but the code change adds
sock.setblocking(True).
--
nosy: +stutzbach
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11674
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11635
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11640
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11628
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11608
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11583
___
___
Python-bugs-list
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
stage: - test needed
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11562
Changes by Daniel Stutzbach stutzb...@google.com:
--
keywords: +needs review
nosy: +alexandre.vassalotti, stutzbach
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11480
Daniel Stutzbach stutzb...@google.com added the comment:
For what it's worth, I believe this could be implemented easily by calling
_PyDict_HasOnlyStringKeys at the end of the class creation process.
--
nosy: +stutzbach
___
Python tracker rep
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1553375
Changes by Daniel Stutzbach stutzb...@google.com:
--
dependencies: +Add traceback.print_full_exception()
nosy: +stutzbach
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9427
New submission from Daniel Stutzbach stutzb...@google.com:
By the time _PyUnicode_Init is called and does the following:
/* Init the implementation */
free_list = NULL;
numfree
Changes by Daniel Stutzbach stutzb...@google.com:
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file20999/unicode-leak.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11402
Daniel Stutzbach stutzb...@google.com added the comment:
I'm not sure. What infrastructure do we have to leaked memory that was
allocated with PyMem_MALLOC?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11335
Daniel Stutzbach stutzb...@google.com added the comment:
I meant to *detect* leaked memory, of course. :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11335
Daniel Stutzbach stutzb...@google.com added the comment:
I played around with this a little. That code path doesn't appear to be
exercised during the existing unit tests. I'll add a test so the leak at least
shows up when the tests are run under valgrind
Changes by Daniel Stutzbach stutzb...@google.com:
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4600
___
___
Python-bugs-list
Daniel Stutzbach stutzb...@google.com added the comment:
+1. I've bumped into exactly this problem
(https://github.com/DanielStutzbach/blist/issues/closed#issue/29)
I'm not intimately familiar with how __slots__ works. Are there any drawbacks
to adding an empty __slots__ to the ABCs
Daniel Stutzbach stutzb...@google.com added the comment:
Sounds good to me. Thanks for the clarifications and satisfying my curiosity!
:-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10868
New submission from Daniel Stutzbach stutzb...@google.com:
In list.sort, if a key function throws an exception, the memory to store the
keys is never freed. I introduced the bug in r86937. I'll upload a patch for
review shortly.
--
assignee: stutzbach
components: Interpreter Core
Daniel Stutzbach stutzb...@google.com added the comment:
Below is a link to the code where leak occurs and the patch goes:
http://svn.python.org/view/python/branches/py3k/Objects/listobject.c?view=markuppathrev=88554#l1944
--
keywords: +3.2regression, needs review, patch
Added file
Daniel Stutzbach stutzb...@google.com added the comment:
In what use-cases would you want to call MyABC.register() when defining a class
instead of inheriting from MyABC?
I always thought of the register() as hack to make it possible to support types
written in C, which can't inherit from
Daniel Stutzbach stutzb...@google.com added the comment:
That's an interesting point.
Do you know of places where we use fd 2 instead of sys.stderr?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7111
Daniel Stutzbach stutzb...@google.com added the comment:
On Thu, Feb 3, 2011 at 11:56 AM, Alexander Belopolsky
rep...@bugs.python.org wrote:
3rd party extensions. What is the use case for python -? Is
it important enough to justify the risk of accidental data loss?
I don't think closing
Daniel Stutzbach stutzb...@google.com added the comment:
On Thu, Feb 3, 2011 at 12:18 PM, Antoine Pitrou rep...@bugs.python.org wrote:
I just took a look at http://pypi.python.org/pypi/python-daemon/, and it
uses dup2() to redirect standard streams, which is far nicer.
I'm more worried about
Daniel Stutzbach stutzb...@google.com added the comment:
Committed in r87339. Thanks everyone for the feedback!
--
assignee: eric.araujo - stutzbach
keywords: -needs review
resolution: - accepted
stage: patch review - committed/rejected
status: open - closed
versions: -Python 2.7
Daniel Stutzbach stutzb...@google.com added the comment:
Raymond,
Do you have around 10 minutes today to look at the patch I submitted in Issue
8743? It appears to solve both this issue and that one, which have priorities
critical and high, respectively.
It's a reasonably small patch
Daniel Stutzbach stutzb...@google.com added the comment:
Doc change committed to py3k in r87346. Thanks, SilentGhost!
I also committed r87349 to reverse r87162 (which was in the wrong branch).
--
___
Python tracker rep...@bugs.python.org
http
Daniel Stutzbach stutzb...@google.com added the comment:
On Fri, Dec 17, 2010 at 2:17 PM, Amaury Forgeot d'Arc wrote wrote:
Err... in r87339 there is a typo in all occurrences of
'Py_ReprEntr': Py_ReprEnter of course!
Well, that's embarrassing. Fixed in r87354
Changes by Daniel Stutzbach stutzb...@google.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8753
___
___
Python-bugs
Daniel Stutzbach stutzb...@google.com added the comment:
On Tue, Dec 14, 2010 at 7:22 PM, Ezio Melotti rep...@bugs.python.org wrote:
If you want to work on this you should also consider that the URLs used on
docs.python.org don't necessary match the directory structure present when
building
New submission from Daniel Stutzbach stutzb...@google.com:
Attached is a patch to add documentation for Py_ReprEnter and Py_ReprLeave.
Assigning to d...@python for review.
--
assignee: stutzbach - d...@python
keywords: +needs review, patch
nosy: +d...@python
stage: needs patch - patch
Daniel Stutzbach stutzb...@google.com added the comment:
Would it be worth keeping (but modifying) test_http_0_9 to verify that the
server complains in the expected way?
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
http
Daniel Stutzbach stutzb...@google.com added the comment:
At minimum, I think we should apply this part of Antoine's patch:
-# Most web servers default to HTTP 0.9, i.e. don't send a status line.
-default_request_version = HTTP/0.9
+default_request_version = HTTP/1.0
Daniel Stutzbach stutzb...@google.com added the comment:
Good point. My perspective is skewed by all of the time that I spend working
on container types. :-)
How about if I change the first sentence to the following?
Properly implementing :attr:`tp_repr` for container types requires
Changes by Daniel Stutzbach stutzb...@google.com:
Added file: http://bugs.python.org/file20071/repr-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8753
Daniel Stutzbach stutzb...@google.com added the comment:
Thanks. New patch attached with a cross-reference to reprlib.recursive_repr.
--
Added file: http://bugs.python.org/file20072/repr-3.patch
___
Python tracker rep...@bugs.python.org
http
Changes by Daniel Stutzbach stutzb...@google.com:
--
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8040
___
___
Python-bugs
Daniel Stutzbach stutzb...@google.com added the comment:
Minor point of clarity: you mean __rand__ not __radd__, right? Set objects do
not support addition at all.
Adding the __rand__ methods to collections.Set in and of itself is
straightforward:
def __rsub__(self, other
Daniel Stutzbach stutzb...@google.com added the comment:
Would it be sufficient to:
1) Restrict collections.Set()'s operators to accept collection.Set but not
arbitrary iterables, and
2) Fix Issue2226 and let set() | MySimpleSet() work via collections.Set.__ror__
Attached is a patch
Daniel Stutzbach stutzb...@google.com added the comment:
In bltinmodule.c, it looks like some of the indentation doesn't line up?
Bikeshedding aside, it looks good to me.
I agree with Eric Smith that the first part macro name usually refers to the
type of the first argument (or the type
Daniel Stutzbach stutzb...@google.com added the comment:
+1 on the general idea of abstracting out repeated code.
I will take a closer look at the details within the next few days.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Daniel Stutzbach stutzb...@google.com added the comment:
(I also noticed that the new methods from issue #9213 are not mentioned
in the range() docs
Wasn't that fixed in Issue9746?
--
___
Python tracker rep...@bugs.python.org
http
Daniel Stutzbach stutzb...@google.com added the comment:
The descriptions of range's limitations there is no longer accurate
(slicing is supported following this patch and containment testing is
now efficient)
Want to open a new issue for that? (or is there one already
Daniel Stutzbach stutzb...@google.com added the comment:
The descriptions of range's limitations in the docs still needs an update.
--
assignee: georg.brandl - ncoghlan
status: closed - open
___
Python tracker rep...@bugs.python.org
http
Daniel Stutzbach stutzb...@google.com added the comment:
Committed as r86937. Thanks again for reviewing! Although I do not anticipate
any problems, I will keep an eye on the buildbots just in case.
Antoine, regarding ms-alloced = (list_size + 1) / 2;, I ended up adding an
extensive comment
Changes by Daniel Stutzbach stutzb...@google.com:
--
components: +Interpreter Core -Library (Lib)
resolution: - accepted
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Daniel Stutzbach stutzb...@google.com added the comment:
The use of Py_LOCAL_INLINE is new to me since we usually use #define
instead, but this has a cleaner look to it. I am unclear on whether
all the our target compilers support an inline keyword. If you're
sure it works everywhere
Daniel Stutzbach stutzb...@google.com added the comment:
Just wanted to post this so there weren't any illusions about the
patch being a big win.
When a key function is defined, this is all you can possibly shave
off the time for a comparison.
I don't want to argue whether the patch
Daniel Stutzbach stutzb...@google.com added the comment:
How about a string and a dict? the string can be start and stop
and we can add interesting information to the dict as you suggest.
I like where this is headed. How about putting the string in the dict, too?
d['phase'] = 'start
New submission from Daniel Stutzbach stutzb...@google.com:
The I/O ABC documentation has a blanket disclaimer at the top:
The abstract base classes also provide default implementations of some
methods in order to help implementation of concrete stream classes. For
example, BufferedIOBase
Daniel Stutzbach stutzb...@google.com added the comment:
+io and doc people
Attached is a simple patch to add a table to the documentation summarizing the
I/O ABCs.
--
keywords: +patch
nosy: +benjamin.peterson, ezio.melotti, georg.brandl
Added file: http://bugs.python.org/file19885/io
Daniel Stutzbach stutzb...@google.com added the comment:
What does unsupported mean? Abstract would look more exact.
It means they raise io.UnsupportedOperation when called (unless the subclass
overrides them to do something else).
They are not marked with @abstractmethod, so Abstract
Daniel Stutzbach stutzb...@google.com added the comment:
Other suggestions for a better name for that column are certainly welcome. :-)
Stub Methods?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10589
Daniel Stutzbach stutzb...@google.com added the comment:
Yes, I can take a stab at it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8743
Daniel Stutzbach stutzb...@google.com added the comment:
These functions will be very useful for any long-running program. Thank you
for the patch.
Would you be willing to write tests and documentation?
Would it make more sense for the callback to take a boolean instead of an
integer
Daniel Stutzbach stutzb...@google.com added the comment:
Antoine Pitrou wrote:
Next time, please upload a single patch. Really.
I haven't used Rietveld that much yet, and I'm still learning best-practices.
I apologize for the painful experience.
For anyone else planning to take a look
Daniel Stutzbach stutzb...@google.com added the comment:
Antoine,
My original patch was much more focused, but had a slightly larger performance
penalty for sorting random keys (see http://bugs.python.org/msg122178). Do you
think the performance tradeoff there was still worthwhile?
Ihave
Daniel Stutzbach stutzb...@google.com added the comment:
Amaury Forgeot d'Arc said:
pypy does have a GIL!
D'oh. That shows you how much I know about PyPy. Make that keep in mind that
IronPython doesn't have a GIL. ;)
Brian Quinlan said:
I think that using the number of CPUs
Daniel Stutzbach stutzb...@google.com added the comment:
I'm starting to get settled in here at Google and finding time to follow up on
everything that got put on hold while moving.
Based on the feedback everyone gave me (thanks!), I greatly revised my script
for comparing the speed of sort
Changes by Daniel Stutzbach stutzb...@google.com:
Added file: http://bugs.python.org/file19780/sort-faster.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9915
Changes by Daniel Stutzbach stutzb...@google.com:
Added file: http://bugs.python.org/file19781/detailed-speed-results.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9915
Daniel Stutzbach stutzb...@google.com added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Why don't you contribute a list sorting benchmark to the suite in
http://hg.python.org/benchmarks/?
I considered that, but I want to separately benchmark sorting different kinds
Daniel Stutzbach stutzb...@google.com added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Right, that wouldn't suit your present purposes. But apparently you
are proposing to add a list sorting benchmark to the Tools directory,
with lots of duplicated code from that repo...
Oh
Daniel Stutzbach stutzb...@google.com added the comment:
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
That result is surprising though -- I thought the concept was
manipulate the key and value arrays at the same time instead of just
the keys
If the key parameter
Daniel Stutzbach stutzb...@google.com added the comment:
How did it get *faster* than the original (in the case with no
key-function)?
I was able to shave off some instructions in countrun(), binarysort(), and the
setup and cleanup code in listsort() proper. For small n, these made
Daniel Stutzbach stutzb...@google.com added the comment:
In my case, each thread launches a CPU-intensive process via subprocess, then
waits for it to report output and exit.
Also, keep in mind that PyPy and IronPython don't have a GIL (although I'm not
a PyPy or IronPython user myself
1 - 100 of 453 matches
Mail list logo
