Raymond Hettinger added the comment:
+1 This seems like a reasonable solution.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9548
___
___
STINNER Victor added the comment:
Being strict this would be 3.4 material,
Why? The patch is trivial, I don't how it could cause a regression.
If you don't want regression, add a unit test to test_lzma.py.
--
nosy: +haypo
___
Python tracker
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15805
___
Roundup Robot added the comment:
New changeset 63a1ee94b3ed by Raymond Hettinger in branch 'default':
Issue #15805: Add contextlib.redirect_stdout()
http://hg.python.org/cpython/rev/63a1ee94b3ed
--
nosy: +python-dev
___
Python tracker
STINNER Victor added the comment:
The io module doesn't need to set temporarly the LC_CTYPE locale (which is a
good thing because the change is process-wide!). If we ignore systems where
CODESET is not available, the _bootlocale can be simplified to a few lines:
if
Raymond Hettinger added the comment:
So, is deque a faster replacement for Queue.Queue or not?
Yes, it is faster. The Queue module itself uses the deque internally.
And the Queue is slowed down a bit through locks, function indirection, and
additional features such as maxsize, join, and
STINNER Victor added the comment:
Can't we modify the qualified name instead?
Attached os_stat_statvfs_pickle.patch implements this idea. IMO it's much
simpler because it removes completly the need of the copyreg module.
Example with the patch on Linux:
$ ./python
Python 3.4.0a3+
STINNER Victor added the comment:
Unfortunately, the traceback.py module reads from files to load the source
lines for the traceback (using linecache.py).
linecache is supposed to cache the result. When all files generating tracebacks
of your project are cached, only os.stat() is called on
STINNER Victor added the comment:
I tested utf_16_32_surrogates_4.patch: surrogateescape with as encoder does not
work as expected.
b'[\x00\x80\xdc]\x00'.decode('utf-16-le', 'ignore')
'[]'
b'[\x00\x80\xdc]\x00'.decode('utf-16-le', 'replace')
'[�]'
b'[\x00\x80\xdc]\x00'.decode('utf-16-le',
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15329
___
Vajrasky Kok added the comment:
Nice.
My only complain is the dis.dis example. We don't have to use redirect_stdout
context manager.
+# How to capture disassembly to a string
+
+import dis
+import io
+
+f = io.StringIO()
+with redirect_stdout(f):
+
New submission from Andreas Hilboll:
shutil.make_archive should be able to automatically determine the desired
*format* from the given filename. It would make life easier, because the
programmer wouldn't need to strip the extension from the filename before
passing it to make_archive. I'm
Stephen Tucker added the comment:
Dear All (Eric Smith in particular),
I see the issue has been closed - I guess that I have to use e-mail to
continue this discussion.
I attach a source file that demonstrates the feature, and the output from
IDLE that it generated.
Yours,
Stephen Tucker.
On
STINNER Victor added the comment:
Could you please review this not so simple patch instead?
I did a first review of your code on rietveld.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12892
New submission from Zdeněk Pavlas:
The behavior contradicts documentation and is inconsistent with both cStringIO
and File objects. Patch attached.
StringIO.StringIO('foo').readline(0)
'foo'
cStringIO.StringIO('foo').readline(0)
''
open('/etc/passwd').readline(0)
''
--
components:
Vajrasky Kok added the comment:
Here is the unit test for Tim Heaney's work. There is a test that explicitly
tests that we get error when opening in 'x' mode. Also, this test is only for
lzma. I think we should create separate tickets for other compression methods.
--
keywords: +patch
Changes by Vajrasky Kok sky@speaklikeaking.com:
Removed file: http://bugs.python.org/file32030/add_x_mode_to_lzma.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19201
___
Changes by Vajrasky Kok sky@speaklikeaking.com:
Added file: http://bugs.python.org/file32031/add_x_mode_to_lzma.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19201
___
New submission from Christian Heimes:
The import library uses excessive stat() calls. I've implemented a simple cache
for the bootstrap module that reduces the amount of stat() calls by almost 1/3
(236 - 159 on Linux).
--
assignee: brett.cannon
files: import_stat_cache.patch
keywords:
Martin v. Löwis added the comment:
Stephen: do you agree that your example actually doesn't demonstrate the issue
you originally reported?
Your first to print statements don't actually print a tuple, whereas the latter
two do, and the string gets always escaped in the tuple, and never when
Eric V. Smith added the comment:
As Martin points out, your first example is printing a string, not a tuple. The
parens here are not building a tuple, they are just used for grouping in the
expression, and are not doing anything in this example.
So my explanation still holds: everything is
Ronald Oussoren added the comment:
A problem with __objclass__ is that it is undocumented other than in PEP 252.
That why I called it a workaround, at the time I created this issue I had just
found the problem and workaround and as far as I knew __objclass__ was an
undocumented feature of
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19215
___
___
Python-bugs-list
R. David Murray added the comment:
Oops, I was too quick with that nosy. This bug is fixed in io.StringIO, which
means it is fixed in Python3. And sorry to say, it shouldn't be fixed in a
maintenance release, since it is a behavior change that could break working
programs.
--
nosy:
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19216
___
___
New submission from Jacek Bzdak:
Call to assertEquals(list1, list2) does not finish (takes more than couple of
minutes), for lists that containt 1 elements if all list elements are
different. The same call in python2.6 finishes instanteneously.
This occours even if error message is
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19216
___
___
Python-bugs-list mailing
Jacek Bzdak added the comment:
I have attached a simple test case.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19217
___
___
Python-bugs-list
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti, michael.foord
stage: - needs patch
versions: +Python 3.4 -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19217
Changes by Christian Heimes li...@cheimes.de:
--
nosy: +christian.heimes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14604
___
___
STINNER Victor added the comment:
See also #14604.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19216
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset bea4447c22bf by Victor Stinner in branch 'default':
Issue #18874: PyCode_New() now ensures that the filename is a ready Unicode
http://hg.python.org/cpython/rev/bea4447c22bf
New changeset ba27cba3ae20 by Victor Stinner in branch 'default':
Issue
Antoine Pitrou added the comment:
Benchmarks?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19216
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset 98dbe677dfe7 by Victor Stinner in branch 'default':
Close #16742: Fix misuse of memory allocations in PyOS_Readline()
http://hg.python.org/cpython/rev/98dbe677dfe7
--
nosy: +python-dev
resolution: - fixed
stage: needs patch -
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19217
___
___
Richard Oudkerk added the comment:
BTW, the context objects are singletons.
I could not see a sensible way to make ctx.Process be a picklable class (rather
than a method) if there can be multiple instances of a context type. This
means that the helper processes survive until the program
R. David Murray added the comment:
Added some review comments. Summary: I think we should just make it a dotted
attribute test, and forget about the 'time' thing, which was just used because
that's what the available network test used. (I find it odd that
allow_dotted_names does not appear
Richard Oudkerk added the comment:
Attached is a patch which allows the use of separate contexts. For example
try:
ctx = multiprocessing.get_context('forkserver')
except ValueError:
ctx = multiprocessing.get_context('spawn')
q = ctx.Queue()
p =
R. David Murray added the comment:
It occurs to me, looking at the docs, that there are doc changes also required
for this patch. And given that there are doc changes, this clearly can't be
treated as a bug fix.
If there is no objection to fixing it in 3.4, though, I'd like to do that in
R. David Murray added the comment:
There is definitely a bug in set_payload here, and (obviously :) no test for
that case (passing an 8bit charset to set_payload).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19063
Vajrasky Kok added the comment:
Attached the second version patch to address R. David Murray's concerns.
1. test_dotted_attribute name has been taken, so I use
test_instance_with_allow_dotted_names name. Or should I use
test_instance_with_dotted_attribute name? Or maybe
Vajrasky Kok added the comment:
Only doc fix? What about unit test confirming that getcomments and getsource
return None if inspect can not find the source code?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16355
Eric Snow added the comment:
Though I can't speak regarding the patch, your justification for breaking
backward compatibility seems good enough to me (but I may not be the best judge
:). However, backward compatibility is a funny thing. I've spent not
insignificant time thinking about it
R. David Murray added the comment:
Yes, good point, those tests should definitely be added, which means the test
work doesn't go to waste :)
Note, however, that getsource *does* raise.
--
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
Well, I'm not certain, to tell you the truth.
However, the only non-backward-incompatible change that will work is to
introduce a new command that gives one access to the real print function, and
that to me feels really really ugly and, if I may be
Eric Snow added the comment:
Sounds good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18764
___
___
Python-bugs-list mailing list
Brett Cannon added the comment:
A cursory look at the patch suggests that the cache use is permanent and so any
dynamic changes to a file or directory after an initial caching will not be
picked up. Did you run the test suite with this patch as it should have failed.
--
Christian Heimes added the comment:
Is the content of the bootstrap module used after the interpreter is boot
strapped? I see ... that's a problem. It's a proof of concept anyway and the
speed up is minimal. On my computer with a SSD the speedup barely measurable.
I'd like to see if it makes
New submission from Eric Snow:
There has been some discussion on python-dev about improving interpreter
startup time. Christian Heimes brought up how the os module imports
collections (so _Environ can inherit from it) [1], and mentioned a couple of
solutions [2].
Georg Brandl added the comment:
patch looks good for 3.4; I probably didn't realize that p uses repr when I
added print.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18764
___
Eric Snow added the comment:
Here is a patch for an alternate approach. It does not require re-implementing
MutableMapping (could get out of sync) and does not require rearranging
collections.abc. Instead it uses a metaclass to resolve the import issue
lazily.
--
keywords: +patch
Christian Heimes added the comment:
Nice trick :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19218
___
___
Python-bugs-list mailing list
Eric Snow added the comment:
And when the lazy base class gets resolved, the metaclass gets to say You
didn't see anything and I was never here. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19218
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19218
___
___
Python-bugs-list mailing
Changes by Vladimir Rutsky altsy...@gmail.com:
--
nosy: +rutsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18243
___
___
Python-bugs-list
Stephen Tucker added the comment:
Martin: Yes, I agree this does not demonstrate the issue I reported - so
far as print is concerned. The other issue in my original report was that
the same behaviour is exhibited when tuples are read from a utf-8 - encoded
file where a tuple which has a
New submission from Antoine Pitrou:
This patch contains assorted improvements for unmarshalling pyc files. It will
also make them ~10% smaller.
$ ./python -m timeit -s import marshal; d=marshal.dumps(tuple((i, str(i)) for
i in range(1000))) marshal.loads(d)
- 3.4 unpatched: 232 usec per loop
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +kristjan.jonsson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19219
___
___
Python-bugs-list
R. David Murray added the comment:
python-list is a mailing list, so you would subscribe and post your questions
and examples there. There are very good reasons for the existing behavior, and
python-list would be a good place for you to learn about them (by asking
questions).
The file case
Brett Cannon added the comment:
importlib/_bootstrap.py is importlib, period, so there is no separation of what
is used to start Python and what is used after interpreter startup is completed.
As for adding a 'stat' argument to the loaders, it's possible but as always it
comes down to whether
New submission from Arfrever Frehtes Taifersar Arahesis:
Unicode version was updated in 3.3 and 3.4, but unicodedata.__doc__ was not
updated.
$ for version in 3.2 3.3 3.4; do python${version} -c 'import unicodedata;
print(%s\n\%s\\n % (unicodedata.unidata_version, unicodedata.__doc__))';
New submission from Arfrever Frehtes Taifersar Arahesis:
Unicode 6.3.0 was released on 2013-09-30.
Please remember to update unicodedata.__doc__.
New URL for unicodedata.__doc__:
http://www.unicode.org/reports/tr44/tr44-12.html
--
messages: 199412
nosy: Arfrever
priority: normal
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +benjamin.peterson, ezio.melotti, lemburg, loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19221
___
Changes by Benjamin Peterson benja...@python.org:
--
assignee: - benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19221
___
___
Piotr Dobrogost added the comment:
I guess extracting Richard's patch to a package and placing it on PyPI would be
a good move. I recalled reading this bug after I saw Does Python IO allow
opened file to be deleted/renamed on Windows? question on Stackoverflow
Connor Osborn added the comment:
Here is the documentation patch:
I defaulted to the docs that were in 2.7.5, by noting that beside the p command
the builtin print function could be used.
I also fixed a small code sample that still used print ... syntax.
--
Added file:
Roundup Robot added the comment:
New changeset 97df7404f39c by Benjamin Peterson in branch 'default':
upgrade unicode db to 6.3.0 (closes #19221)
http://hg.python.org/cpython/rev/97df7404f39c
--
nosy: +python-dev
resolution: - fixed
stage: - committed/rejected
status: open - closed
New submission from Tim Heaney:
This is analogous to issue19201, but for gzip. Recent versions of Python have
an 'x' mode for open, but gzip doesn't support it. It looks like everything is
passed to builtins.open eventually, so if we just allow the 'x' option to pass
through, all will be
Roundup Robot added the comment:
New changeset 592579b89d8c by R David Murray in branch 'default':
#18764: p(rint) - p in pdb docs.
http://hg.python.org/cpython/rev/592579b89d8c
--
nosy: +python-dev
___
Python tracker rep...@bugs.python.org
New submission from Tim Heaney:
This is analogous to issue19201, but for bz2. Recent versions of Python have an
'x' mode for open, but bz2 doesn't support it. It looks like everything is
passed to builtins.open eventually, so if we just allow the 'x' option to pass
through, all will be well.
R. David Murray added the comment:
I applied the patch (with doc and test changes) in d4d886620a00, before I saw
your patch. But your patch fixes the main 'p' docs, which I somehow missed, so
I applied it, too.
So, thanks Connor, and I think this is done.
A couple notes if you are going to
Arfrever Frehtes Taifersar Arahesis added the comment:
Issue #19221 has been fixed, but URL in unicodedata.__doc__ in default branch
was not updated :( .
Now it should be http://www.unicode.org/reports/tr44/tr44-12.html
--
assignee: - benjamin.peterson
nosy: +benjamin.peterson
Roundup Robot added the comment:
New changeset 4e301c80f5d1 by Benjamin Peterson in branch '3.3':
remove url from docstring (closes #19220)
http://hg.python.org/cpython/rev/4e301c80f5d1
New changeset f38edb58fefb by Benjamin Peterson in branch 'default':
merge 3.3 (#19220)
Tim Heaney added the comment:
Okay, I just made similar issues for gzip (issue19222) and bz2
(issue19223). It's weird how different these three patches are! We're
essentially doing the same thing: please allow the x option to pass
through to builtins.open. Why don't these three modules look more
Connor Osborn added the comment:
I'm hoping to ease into more involvement. Thanks for the review and tips, and I
submitted the agreement(e-sign version).
--
nosy: -eric.snow, ezio.melotti, georg.brandl
___
Python tracker rep...@bugs.python.org
Eric Snow added the comment:
With ModuleSpec (PEP 451), the finder creates the spec object (where it stores
the loader). At that point the finder is free to store any stat object you
like in spec.loader_state. The spec is made available to the loader during
exec (if the loader supports it,
STINNER Victor added the comment:
Why adding ASCII strings, whereas you can add Latin1 (UCS1, U+-U+00FF)
strings?
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19219
___
STINNER Victor added the comment:
@Crys: ping!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18754
___
___
Python-bugs-list mailing list
Changes by STINNER Victor victor.stin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18664
___
STINNER Victor added the comment:
issue18281.stoneleaf.01.patch looks good to me, please commit it!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18281
___
STINNER Victor added the comment:
This issue is maybe a new usecase of the PEP 445.
Try attached Python module fatalmalloc.c, use attached setup.py script to build
it.
$ python3.4 -c 'import fatalmalloc; x=x*(50*1024*1024); print(len(x))'
Traceback (most recent call last):
File string, line
Changes by STINNER Victor victor.stin...@gmail.com:
Added file: http://bugs.python.org/file32042/setup.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16381
___
STINNER Victor added the comment:
@ichael Herrmann: ping? Without feedback, I will close the issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19046
___
Eric Snow added the comment:
For interpreter startup, stats are not involved for builtin and frozen
modules[1]. They are tied to imports that involve traversing sys.path (a.k.a.
PathFinder). Most stats happen in FileFinder.find_loader. The remainder are
for source (.py) files (a.k.a.
Brett Cannon added the comment:
So the 2 stat calls in the general case are superfluous, it's just a question
of whether they make any performance difference. Turns out that at least on my
Macbook their is no performance difference and thus not worth the cost of
breaking semantics over it:
Ezio Melotti added the comment:
You can use sys.stdout.buffer.write.
Note that there's no guarantee that sys.stdout.buffer exists, e.g. if
sys.stdout has been replaced with a StringIO.
--
___
Python tracker rep...@bugs.python.org
Ezio Melotti added the comment:
Should this be moved to the Sphinx bug tracker?
--
nosy: +georg.brandl
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18177
___
Dustin Oprea added the comment:
I was about to submit a feature request to add exactly this. The [second] patch
works like a charm. When are you going to land on a particular resolution so
that it can get committed in?
Dustin
--
nosy: +dsoprea
Ezio Melotti added the comment:
I think this should also be added to the whatsnew.
Regarding the examples, isn't it easier to say that:
with redirect_stdout(sys.stderr):
print('error')
is equivalent to
print('error', file=sys.stderr)
?
I think that in most of the cases users are
Eric Snow added the comment:
I realized those two stats are not superfluous in the case that a directory
name has a .py suffix or a file doesn't have any suffix. However, I expect
that's pretty uncommon.
Worst case, these cases cost 2 stats per path entry. In practice they cost
nothing due
Eric Snow added the comment:
I forgot to mention that optimizing the default composition of sys.path (from
site) could help speed things up, though it might already be optimized in that
regard.
I also forgot to mention the idea of zipping up the stdlib.
Sorry for the sidetrack. Now, back to
Glyph Lefkowitz added the comment:
Tempting as it is to reply to the comment about 'buffer' not existing, we're
way off topic here. Let's please keep further comments on this bug to issues
about a 'format' methods on the 'bytes' object.
--
___
Changes by Qiangning Hong hon...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file32043/hash_of_none.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19224
___
New submission from Qiangning Hong:
Integers, strings, and bool's hash are all consistent for processes of a same
interpreter. However, hash(None) differs.
$ python -c print(hash(None))
272931276
$ python -c print(hash(None))
277161420
It's wired and make difficulty for distributed systems
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19218
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19218
___
Raymond Hettinger added the comment:
Instead of 0, pick some large random number that is less likely to collide with
other hashes such as hash(0).
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19224
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - michael.foord
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19217
___
Christian Heimes added the comment:
How about
(78 24) + (111 16) + (110 8) + 101
1315925605
The output of hash() is not guaranteed to be consistent between processes. The
outcome depends on the hash randomization key, architecture, platform, Python
version and perhaps other flags. 32bit
Qiangning Hong added the comment:
Return 1315925605 now :)
--
Added file: http://bugs.python.org/file32044/hash_of_none.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19224
___
100 matches
Mail list logo
