Daniel Stutzbach added the comment:
On Wed, Sep 15, 2010 at 10:51 AM, Benjamin Peterson
wrote:
> I'm not sure if this pickling stuff matters as long as they both pickle.
>
I'm not sure either. Do other Python implementations try to maintain a
compatible pickle format with CP
Changes by Daniel Stutzbach :
Removed file: http://bugs.python.org/file18890/unnamed
___
Python tracker
<http://bugs.python.org/issue9858>
___
___
Python-bugs-list mailin
Daniel Stutzbach added the comment:
Roundup does not play well with Gmail when Gmail is in Rich Format mode ;-)
That example should have read:
>>> f = io.FileIO(1)
>>> f.name
1
--
___
Python tracker
<http://bugs
Daniel Stutzbach added the comment:
> Hmm, none the less other code expects it.
Does that imply that there's some code that will break on FileIO objects that
are created using a file descriptor instead of a filename? If so, where?
--
__
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue9886>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Daniel Stutzbach :
(I've made an educated guess about who to add to the Nosy list)
The attached patch substantially speeds up sorting using the "key" parameter.
It is purely a performance patch; the language and libraries are not changed in
any other way
Daniel Stutzbach added the comment:
Committed in r84961
--
stage: patch review -> committed/rejected
status: open -> closed
type: -> behavior
versions: -Python 3.3
___
Python tracker
<http://bugs.python.o
Daniel Stutzbach added the comment:
Antoine said:
> I don't think there's any point in micro-optimizations such as
> stack_keys.
Good point. I'll try taking that out and see how it impacts the timing.
Raymond said:
> The memmove, memcpy functions are tricky to
Daniel Stutzbach added the comment:
Attached is my script for running a more comprehensive battery of speed tests.
The script itself requires Python 2.6 with argparse installed or Python 2.7
(which includes argparse).
For obvious reasons, please make sure that your unpatched and patched
Daniel Stutzbach added the comment:
> It would be a non-seekable in-memory bytes buffer with distinct
> read and write pointers, so as to act like a system FIFO or a
> socket.makefile() object.
What would it do when the equivalent system FIFO object would block?
> (you may poin
Daniel Stutzbach added the comment:
> Simply buffer everything.
That works for when a write operation would block. What would it do when a
read operation would block?
--
___
Python tracker
<http://bugs.python.org/iss
Daniel Stutzbach added the comment:
Another option would be to have the read-end act like a non-blocking socket
(i.e., raise EAGAIN).
Since it would mostly be for testing, would it make more sense to add it to
test.support or someplace similar instead of io
Daniel Stutzbach added the comment:
> I thought it might be useful for third-party libraries, or even
> non-testing situations
That might be true, but I prefer that we give code a more vigorous exercise
before putting it in the standard library proper. When we try to use it for
som
Daniel Stutzbach added the comment:
> Since the patch is intended to speed up 3.2 and your posted
> experiments were run on that, I am puzzled that you would post a
> test script to run under late 2.x instead of 3.1+.
I had originally written the test script was originally wr
Daniel Stutzbach added the comment:
> Does this help any?
No :-)
The problem is that the random data you run in interpreter 1 won't be the same
data you run in interpreter 2, so the results are not directly comparable. One
of the sets of random data may be more easily sortable
Daniel Stutzbach added the comment:
> what about adding a simple "random.seed(12345)"
That's an excellent suggestion! In fact, I'm embarrassed that it never
occurred to me (especially since I have used it in other projects).
I will have a revised speed_test al
New submission from Daniel Stutzbach :
In Lib/ntpath.py:
# realpath is a no-op on systems without islink support
realpath = abspath
However, Windows Vista and newer support symbolic links and other Python
methods support them.
(noticed this through source code inspection; haven't act
New submission from Daniel Stutzbach :
The readinto() method is intended to offer better performance than read() by
allowing the caller to read into a preallocated buffer rather than constantly
allocate and deallocate buffers.
However, bufferediobase_readinto() calls read(), so the extra
Daniel Stutzbach added the comment:
I know enough about Unicode to have reported this bug, but I don't feel
knowledgeable enough about Python's Unicode implementation to comment on your
suggested solution.
I'm adding the other people listed in Misc/maintainers.rst as interes
Changes by Daniel Stutzbach :
--
nosy: +ezio.melotti, lemburg
___
Python tracker
<http://bugs.python.org/issue9979>
___
___
Python-bugs-list mailing list
Unsub
New submission from Daniel Stutzbach :
The following program should print "0xdead" but instead prints "0x0". This
came from the following stackoverflow question:
http://stackoverflow.com/questions/3824617/python-structure-always-stuck-at-0-no-matter-what-value-you-assign-
Daniel Stutzbach added the comment:
Could be. FWIW, I had tested and observed the problem on a 32-bit Intel
Windows box and 64-bit Intel Linux box.
--
___
Python tracker
<http://bugs.python.org/issue9
Daniel Stutzbach added the comment:
I, too, can't think of any platforms where Py_UNICODE_SIZE == 4 &&
SIZEOF_WCHAR_T == 2 and I'm not sure what the previous policy has been. Have
you noticed any other code that would set a precedent?
If no one else chimes in, perhaps as
Daniel Stutzbach added the comment:
> You can tweak the Windows pyconfig.h to use UCS4, AFAIK, if you want to
> test drive this case.
I seem to recall seeing some other code that assumed Windows implied UCS2.
Proceed with caution. ;-)
> But it's probably easier to confi
Daniel Stutzbach added the comment:
Thanks for working on this!
Since this was a bugfix, it should be merged back into 2.7, yes?
--
stage: unit test needed -> committed/rejected
___
Python tracker
<http://bugs.python.org/iss
Daniel Stutzbach added the comment:
Since I noticed the bug through source code inspection and no one has reported
it occurring in practice, that sounds reasonable to me.
--
versions: -Python 2.7
___
Python tracker
<http://bugs.python.
Daniel Stutzbach added the comment:
For what it's worth, a similar fast path existed in Python 2 for lists (but not
tuples). It was removed for Python 3. I'm not sure why it was removed, but it
may have been part of removing the PyInt type.
--
nosy:
Daniel Stutzbach added the comment:
I did some spelunking. Guido committed the similar optimization in r8306.
The diff is at:
http://svn.python.org/view/python/trunk/Python/ceval.c?r1=8087&r2=8306
His commit message was:
Huge speedup by inlining some common integer operat
Daniel Stutzbach added the comment:
The code was taken from the itertools.izip documentation for Python 2, where it
did work.
In Python 2, next() raises StopIteration which is propagated up and causes the
izip() to stop. In Python 3, map is itself a generator and the StopIteration
Daniel Stutzbach added the comment:
How does performance change if you adjust NSMALLPOSINTS and NSMALLNEGINTS, but
make no other changes?
--
___
Python tracker
<http://bugs.python.org/issue10
Daniel Stutzbach added the comment:
> I suggest removing the "equivalent to" code from the zip section and
> replacing it with an example showing how to use zip with a for loop
> similar to the example illustrating enumerate.
+1
--
___
Daniel Stutzbach added the comment:
> I don't think arbitrary comparisons of pointers give well-defined
> results, unless those pointers both happen to point into the same
> array. (Might be wrong; I don't have a copy of the C standard to
> hand.)
Technically arbitrary
Daniel Stutzbach added the comment:
Hello Simon,
Accessing an arbitrary element of a deque takes O(n) time, making your .index
implementation O(n**2).
If you describe the kinds of operations that you need to perform efficiently,
we may be able to suggest a better data structure for you to
Daniel Stutzbach added the comment:
> Daniel, we need to sync-up on the meaning of marking a report as
> "accepted". Traditionally it denotes an approved patch, not a agreement >
> that the bug is valid.
Woops! Thanks for the correction. For what it's worth, a q
Daniel Stutzbach added the comment:
Hirokazu, could you run Python in a debugger and figure out exactly which line
crashes and what the error is? I'm curious.
If we make this change, the same change should be applied to RegEnumKey, etc.,
since the RegEnumKey docs contain similar lan
New submission from Daniel Stutzbach :
fromfd is marked as Availability: Unix, but in Python 3 it is also available on
Windows:
C:\>c:\python31\python.exe
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", &qu
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue10099>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Stutzbach added the comment:
That fixes the example code, but what about the numerous text that reads
"strings" that should read "byte sequences", "bytes", or similar?
--
___
Python tracker
<
New submission from Daniel Stutzbach :
ProcessPoolExecutor allows the max_workers parameter to the constructor to be
omitted or None, in which case it will set the max_workers based on the number
of CPUs.
It would be nice if ThreadPoolExecutor's constructor worked the same way;
havin
Daniel Stutzbach 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 th
Daniel Stutzbach 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__ t
Daniel Stutzbach added the comment:
Sounds good to me. Thanks for the clarifications and satisfying my curiosity!
:-)
--
___
Python tracker
<http://bugs.python.org/issue10
New submission from Daniel Stutzbach :
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
messages: 129574
Daniel Stutzbach 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=markup&pathrev=88554#l1944
--
keywords: +3.2regression, needs review, patch
Added file:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue4600>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Stutzbach added the comment:
I'm not sure. What infrastructure do we have to leaked memory that was
allocated with PyMem_MALLOC?
--
___
Python tracker
<http://bugs.python.org/is
Daniel Stutzbach added the comment:
I meant "to *detect* leaked memory", of course. :-)
--
___
Python tracker
<http://bugs.python.org/issue11335>
___
___
Daniel Stutzbach 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 unde
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue1553375>
___
___
Python-bug
Changes by Daniel Stutzbach :
--
dependencies: +Add traceback.print_full_exception()
nosy: +stutzbach
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue9
New submission from Daniel Stutzbach :
By the time _PyUnicode_Init is called and does the following:
/* Init the implementation */
free_list = NULL;
numfree = 0
Changes by Daniel Stutzbach :
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file20999/unicode-leak.patch
___
Python tracker
<http://bugs.python.org/issue11
Daniel Stutzbach 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
<http://bugs.py
Changes by Daniel Stutzbach :
--
keywords: +needs review
nosy: +alexandre.vassalotti, stutzbach
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
stage: -> test needed
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue11562>
___
___
Py
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11583>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11608>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11628>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11635>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue11640>
___
___
Python-bugs-list mailin
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11674>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Stutzbach 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)".
--
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue6634>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11845>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11854>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Stutzbach 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, will that be s
Changes by Daniel Stutzbach :
--
nosy: +stutzbach
___
Python tracker
<http://bugs.python.org/issue11994>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Stutzbach :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Daniel Stutzbach 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.
Unfortunately, this
Daniel Stutzbach 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
<http://bugs.python.org
Daniel Stutzbach 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: +stut
Daniel Stutzbach 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 that at instanc
Daniel Stutzbach 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 is that
the inst
Daniel Stutzbach 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 u
Daniel Stutzbach 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 C
Daniel Stutzbach 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(). It's no
Changes by Daniel Stutzbach :
Added file: http://bugs.python.org/file19780/sort-faster.patch
___
Python tracker
<http://bugs.python.org/issue9915>
___
___
Python-bug
Changes by Daniel Stutzbach :
Added file: http://bugs.python.org/file19781/detailed-speed-results.txt
___
Python tracker
<http://bugs.python.org/issue9915>
___
___
Pytho
Daniel Stutzbach added the comment:
Antoine Pitrou 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
and quantities of data. AFAIK, there is
Daniel Stutzbach added the comment:
Antoine Pitrou 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, I just stuck that under
Daniel Stutzbach added the comment:
Raymond Hettinger 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 was not used, then the value
Daniel Stutzbach 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 a
difference.
Daniel Stutzbach 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 at this,
Daniel Stutzbach 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 uploaded my original
Daniel Stutzbach 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 as the first argument
Daniel Stutzbach 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,
New submission from Daniel Stutzbach :
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 pro
Daniel Stutzbach 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-abc.diff
Daniel Stutzbach 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 &q
Daniel Stutzbach added the comment:
Other suggestions for a better name for that column are certainly welcome. :-)
"Stub Methods"?
--
___
Python tracker
<http://bugs.python.o
Daniel Stutzbach added the comment:
Yes, I can take a stab at it.
--
___
Python tracker
<http://bugs.python.org/issue8743>
___
___
Python-bugs-list mailin
Daniel Stutzbach added the comment:
Antoine and Raymond, thank you for the valuable feedback.
Attached is a revised version of the patch, which restricts changes to those
directly related to moving elements in the keys and values arrays at the same
time. I apologize for having gotten a
Daniel Stutzbach 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 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 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 comm
Changes by Daniel Stutzbach :
--
components: +Interpreter Core -Library (Lib)
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Daniel Stutzbach 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
<http://bugs.python
Daniel Stutzbach 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 the
Daniel Stutzbach 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
<http://bugs.python
101 - 200 of 469 matches
Mail list logo
