Changes by John O'Connor <j...@uber.com>:
--
nosy: +jcon
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21423>
___
___
Python
John O'Connor added the comment:
I encountered the same problem w/ 2.7.7.
Temporary workaround:
SVNVERSION=Unversioned directory ./configure
make
...
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6094
John O'Connor added the comment:
Looking at the implementation (rather quickly)[1]. I'm wondering if there is a
reason why the appendleft(pop()) loop is required. It would seem the best way
would be to determine the new head link, make the previous link the new end
link and concatenate
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16398
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16465
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1508475
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11695
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16445
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15948
___
___
Python-bugs-list mailing
John O'Connor added the comment:
I think that's a good compromise and much better than what I had originally.
- John
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12805
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15381
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13903
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13521
___
___
Python-bugs-list mailing
New submission from John O'Connor tehj...@gmail.com:
I think ucs{1,2,4}lib.h, asciilib.h and a few other files should be in the
Makefile deps list for unicodeobject.c.
Patch included.
--
components: Build
files: makefile.patch
keywords: patch
messages: 145881
nosy: haypo, jcon
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13150
___
___
Python-bugs-list mailing
John O'Connor tehj...@gmail.com added the comment:
New patch.
Please double check the removal of _PyUnicode_XStrip.
--
Added file: http://bugs.python.org/file23383/stringlib_strip2.patch
___
Python tracker rep...@bugs.python.org
http
Changes by John O'Connor tehj...@gmail.com:
--
title: Optimization/refactoring for {bytearray, bytes, unicode}.strip() - Move
strip() to stringlib
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12807
John O'Connor tehj...@gmail.com added the comment:
Here is an update with the C implementation. I think a working prototype will
be helpful before another round on python-dev.
I'm not sure how to handle unseekable, non-blocking streams where the read
returns before `skip` bytes
New submission from John O'Connor tehj...@gmail.com:
The C implementation of BufferedReader.seek() does not throw an
UnsupportedOperation exception when its underlying stream is unseekable IF the
current buffer can accommodate the seek in memory. It probably saves a few
cycles
John O'Connor tehj...@gmail.com added the comment:
The patch no longer applies cleanly. Is there enough interest in this to
justify rebasing?
--
title: Optimizations for {bytearray,bytes,unicode}.strip() -
Optimization/refactoring for {bytearray,bytes,unicode}.strip
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12911
___
___
Python-bugs-list mailing
John O'Connor tehj...@gmail.com added the comment:
Moved {l,r,}strip to stringlib as well as the bloom filters from unicodeobject.
I think it cleans things up nicely. Now there is one implementation for all 3
types. This patch also improves performance for bytearray and slightly for
bytes. I
Changes by John O'Connor tehj...@gmail.com:
Removed file: http://bugs.python.org/file22982/strip_perf.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12807
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10408
___
___
Python-bugs-list mailing
John O'Connor tehj...@gmail.com added the comment:
You are right about those lines in particular; 'dubious' as you say.
Though, the point overall was that the general implementation was noticeably
faster (regardless of those smaller changes).
However, I do think that the single check for len
Changes by John O'Connor tehj...@gmail.com:
Removed file: http://bugs.python.org/file23040/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12807
John O'Connor tehj...@gmail.com added the comment:
Antoine Pitrou pit...@free.fr added the comment:
This looks like a dubious micro-optimization. If len == 0,
all loops will exit early anyway (same for similar snippets in bytesobject.c
and unicodeobject.c).
You are right about those lines
New submission from John O'Connor tehj...@gmail.com:
I noticed there are a few more common cases that can be sped up in bytes.join().
When:
- The sequence length and separator length are both 0
- The separator length is 0 or 1
- The separator string contains only 1 distinct byte
These could
Changes by John O'Connor tehj...@gmail.com:
--
title: Optimzations for bytes.join() et. al - Optimizations for bytes.join()
et. al
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12805
New submission from John O'Connor tehj...@gmail.com:
bytearray() is using a less efficient implementation of split() than its
similar friends bytes and unicode.
I added a couple extra checks to return early in {bytes,unicode} split().
- if length is 0
- if left strip removed all bytes
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11549
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5231
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10181
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12268
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9858
___
___
Python-bugs-list mailing
New submission from John O'Connor tehj...@gmail.com:
Remove second (unused) argument to _bufferedreader_peek_unlocked()
--
components: IO
files: bufferedreader_peek.patch
keywords: patch
messages: 137391
nosy: haypo, jcon, pitrou
priority: normal
severity: normal
status: open
title
John O'Connor tehj...@gmail.com added the comment:
It seems to me that adding the proper check is a good idea. It also may not be
obvious to some that 'U' is now more or less an alias for 'r'. I have updated
the patch so that it at least applies.
I also removed a redundant `reading = 1
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11197
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8578
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10399
___
___
Python-bugs-list mailing
John O'Connor tehj...@gmail.com added the comment:
I started a draft in python. I am attaching the _pyio version along with tests.
I will continue work on the C implementation and eventually documentation if
this is well received. It seems straightforward, I am interested to see what
you guys
Changes by John O'Connor tehj...@gmail.com:
Added file: http://bugs.python.org/file22169/issue12053-tests.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12053
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12062
___
___
Python-bugs-list mailing
John O'Connor tehj...@gmail.com added the comment:
I've attached the latest changes based on feedback (issue9971-v5.patch)
for i in 1 4 128 256 1024 2048 4069 8192 16384; do echo -n buffer_size=$i ;
./python -m timeit -s f=open('LICENSE','rb');b=bytearray($i) f.seek(0)
while f.readinto(b
John O'Connor tehj...@gmail.com added the comment:
Victor: AFAIK its not actually downcasting. The safe downcast just uses an
assertion when debugging is enabled. I chose to use it because it seems to be a
convention in the file.
Antoine: You say quirky, I say elegant :) Though I have
New submission from John O'Connor tehj...@gmail.com:
A prefetch() method for Buffered IO may greatly assist 3rd party buffering
among other gains. If nothing else, it is worth experimenting with.
Discussion on the topic is here:
http://mail.python.org/pipermail/python-ideas/2010-September
John O'Connor tehj...@gmail.com added the comment:
No problem for me either way.
I created issue12053 to track that.
- John O'Connor
On Tue, May 10, 2011 at 3:19 PM, Antoine Pitrou rep...@bugs.python.orgwrote:
Antoine Pitrou pit...@free.fr added the comment:
Also, while we're
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12049
___
___
Python-bugs-list mailing
Changes by John O'Connor tehj...@gmail.com:
Removed file: http://bugs.python.org/file21957/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9971
John O'Connor tehj...@gmail.com added the comment:
I experimented with a bunch of different options.
All benchmarks performed with:
$ for i in 1 4 128 256 1024 2048 4069 8192; do
echo -n buffer_size=${i} ;
./python -m timeit -s f=open('LICENSE','rb');b=bytearray(${i}) \
f.seek(0) while
Changes by John O'Connor tehj...@gmail.com:
Added file: http://bugs.python.org/file21941/issue9971-like-java.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9971
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12021
___
___
Python-bugs-list mailing
John O'Connor tehj...@gmail.com added the comment:
It seems to me that the point of using readinto() is to avoid double-buffering
(and the extra alloc/free that comes with read()). The slowness of using a
small buffer size seems like only a natural and expected consequence.
The trade-off
John O'Connor tehj...@gmail.com added the comment:
FWIW, It seems Java does something similar. They write directly into caller's
buffer if outstanding bytes needed (after emptying internal buffer) is greater
than internal buffer len.
--
___
Python
Changes by John O'Connor tehj...@gmail.com:
Removed file: http://bugs.python.org/file21899/buffered_readinto.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9971
Changes by John O'Connor tehj...@gmail.com:
Removed file: http://bugs.python.org/file21900/buffered_readinto2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9971
John O'Connor tehj...@gmail.com added the comment:
Good catch. v3 attached.
--
Added file: http://bugs.python.org/file21912/buffered_readinto3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9971
John O'Connor tehj...@gmail.com added the comment:
Attached patch draft for buffered_readinto(). patchcheck removed some
whitespace as well.
Daniel, I agree. BufferedReader.readinto seemingly defeats the purpose of using
a BufferedReader to begin with. Though, for the difference Antoine
John O'Connor tehj...@gmail.com added the comment:
Thanks for the feedback. I made the changes, PTAL.
--
Added file: http://bugs.python.org/file21900/buffered_readinto2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9971
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1677872
___
___
Python-bugs-list mailing
John O'Connor tehj...@gmail.com added the comment:
I am new to the community but hoping to start contributing or at least
following issues and learning :)
I'm looking at bufferediobase_readinto(). What I haven't yet figured out is why
.readinto() is (currently) implemented at this layer
62 matches
Mail list logo
