Vajrasky Kok added the comment:
Here is the preliminary patch.
--
keywords: +patch
nosy: +vajrasky
Added file:
http://bugs.python.org/file33173/fix_tarfile_list_print_lone_surrogate.patch
___
Python tracker rep...@bugs.python.org
Vajrasky Kok added the comment:
I based my implementation on this statement:
Guido pointed out that it may more useful to resolve the path components until
one doesn't exist
until one doesn't exist in this case means P(BASE, 'foo', 'in', 'spam')
resolves until BASE / 'foo'.
If different
Serhiy Storchaka added the comment:
This is new feature and can be added only in 3.5.
--
assignee: docs@python -
components: -Documentation, Tests
stage: patch review - needs patch
type: behavior - enhancement
versions: +Python 3.5 -Python 2.7
___
Serhiy Storchaka added the comment:
I believe Guido meant one of standard strategies. Current posixpath.realpath()
implementation conforms --canonicalize-missing.
It is not clear which two strategies (from three) should be used in
Path.resolve().
--
Claudiu.Popa added the comment:
If we agree that this should be fixed in 3.4, can somebody commit it before the
second beta?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19385
___
Antoine Pitrou added the comment:
get_ca_certs() doesn't return the cert although it is used to
successfully validate a remote cert.
Interesting. Is it because of the way you implemented get_ca_certs()?
I propose to modify and rename the function and to add a check_ca to
the dict that is
New submission from Peter Otten:
I ran into this when trying to trigger rereading the column names with
$ cat tmp.csv
alpha,beta
1,2
gamma,delta,epsilon
3,4,5
$ python
Python 2.7.2+ (default, Jul 20 2012, 22:15:08)
[GCC 4.6.1] on linux2
Type help, copyright, credits or license for more
Claudiu.Popa added the comment:
Thanks, Vajrasky, I forgot about the fact that open can open file descriptors.
Here's a patch which fixes this, also adds a test for BytesIO and uses
os.fsencode instead of .encode().
--
Added file: http://bugs.python.org/file33174/imghdr_files.patch
Nick Coghlan added the comment:
OK, fixed test case attached. Turns out the ipython workaround test was
completely wrong and never even loaded multiprocessing, and hence always
passed, even with the workaround disabled. So I fixed that test case, and used
the same approach for the zipfile,
Serhiy Storchaka added the comment:
patch_indenterror_offset_v2.diff LGTM.
--
stage: - commit review
versions: +Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17825
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file:
http://bugs.python.org/file33161/test_multiprocessing_main_handling.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19946
___
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file:
http://bugs.python.org/file33146/issue19946_pep_451_multiprocessing.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19946
___
Serhiy Storchaka added the comment:
LGTM. But err_flag is not needed, valid error numbers are all nonzero.
--
assignee: - serhiy.storchaka
stage: needs patch - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
Christian Heimes added the comment:
Interesting. Is it because of the way you implemented get_ca_certs()?
Yes, it's the line
http://hg.python.org/cpython/file/b78de8029606/Modules/_ssl.c#l3103
that skips all certs that are not recognized as CA certs. I wasn't aware
that OpenSSL supports
Changes by Antoine Pitrou pit...@free.fr:
--
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2
___
___
Roundup Robot added the comment:
New changeset b6d6f3b4b100 by Nick Coghlan in branch 'default':
Close #19946: use runpy as needed in multiprocessing
http://hg.python.org/cpython/rev/b6d6f3b4b100
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file:
http://bugs.python.org/file33163/test_multiprocessing_main_handling.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19946
___
Changes by Claudiu.Popa pcmantic...@gmail.com:
--
assignee: docs@python
components: Documentation
files: typo_operator.patch
keywords: patch
nosy: Claudiu.Popa, docs@python
priority: normal
severity: normal
status: open
title: Minor typo in operator documentation
versions: Python 3.4
Nick Coghlan added the comment:
On second thoughts, I'm going to close this one - if further runpy changes are
needed to resolve issue 19702 (using __spec__.name for pickle when
appropriate), let's deal with them there.
--
resolution: - fixed
stage: test needed - committed/rejected
Changes by Nick Coghlan ncogh...@gmail.com:
--
title: Update pickle to PEP 451 - Update pickle to take advantage of PEP 451
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19702
___
Roundup Robot added the comment:
New changeset 33c27b76a4d0 by Serhiy Storchaka in branch '2.7':
Issue #17976: Fixed potential problem with file.write() not detecting IO error
http://hg.python.org/cpython/rev/33c27b76a4d0
--
nosy: +python-dev
___
Nick Coghlan added the comment:
Issue 19700 means that runpy now ensures that __main__.__spec__ is set
appropriately when __main__ is executed via the import system.
Issue 19946 means that multiprocessing now ensures that __main__ is configured
correctly in child processes to reference a
Serhiy Storchaka added the comment:
Thank you Jaakko Moisio for your report and patch.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
Nick Coghlan added the comment:
Issue 19982 suggests a different way of refactoring the runpy APIs inspired by
PEP 451: passing in a target module to be used, rather than creating a
temporary one from scratch.
--
___
Python tracker
Nick Coghlan added the comment:
Implementing this is actually likely to require non-trivial restructuring of
the runpy internals. contextlib.ExitStack may prove useful in making it easier
to programmatically select amongst different context managers.
The __mp_main__ helpers in multiprocessing
Roundup Robot added the comment:
New changeset 237deaf9ba64 by Serhiy Storchaka in branch '2.7':
Skip test for issue #17976 if /dev/null is not available.
http://hg.python.org/cpython/rev/237deaf9ba64
--
___
Python tracker rep...@bugs.python.org
Changes by Yongzhi Pan fossi...@users.sourceforge.net:
--
nosy: +fossilet
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
___
Roundup Robot added the comment:
New changeset debdfa44f020 by Serhiy Storchaka in branch '2.7':
Issue #16404: Add checks for return value of PyInt_FromLong() in
http://hg.python.org/cpython/rev/debdfa44f020
New changeset 928c0acf7c09 by Serhiy Storchaka in branch '3.3':
Issue #16404: Add
Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16404
___
Nick Coghlan added the comment:
I'm reopening this, since PEP 451 opens up new options for dealing with it (at
least for loaders that export the PEP 451 APIs rather than only the legacy
loader API, which now includes all the standard loaders other than the ones for
builtins and extension
Nick Coghlan added the comment:
With PEP 451 implemented, note that I have reopened issue 992389 - the patch to
set the parent module attribute at the same time as setting the sys.module
attribute is actually pretty trivial for the PEP 451 loader case, and that now
includes all the standard
New submission from Serhiy Storchaka:
test_weakset often fails on FreeBSD. Fo example see
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%202.7/builds/285/steps/test/logs/stdio.
test test_weakset failed -- Traceback (most recent call last):
File
Eric V. Smith added the comment:
I'm not clear on this: is this a new feature you'd like to see, or is this
documented behavior of a DictReader that's not working?
If it's a new feature, the earliest it can be implemented is in 3.5.
--
nosy: +eric.smith
STINNER Victor added the comment:
(I was trying to report the issue upstream.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
___
___
STINNER Victor added the comment:
I played with fullwrite.c and now think that the fix is incomplete. fwrite()
may succeed to write data into the buffer, but you may get the error on
fflush() or fclose().
Try attached fullwrite2.c: fwrite() succeed (written=len, errno=result=0),
whereas
Antoine Pitrou added the comment:
Does it occur only on 2.7?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20006
___
___
Python-bugs-list
Brett Cannon added the comment:
* Yes, you can commit with the warnings being triggered to get help with
resolving them, just expect to potentially do a lot of work to make sure they
don't leak out into 3.4 final.
* Just don't deprecate load_module() yet in code. If we can't even get rid of
Antoine Pitrou added the comment:
I can't reproduce the failure after more than 2000 test runs.
Also, this failure is weird: the test is supposed to be deterministic.
--
nosy: +koobs
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
Does it occur only on 2.7?
Don't know.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20006
___
___
Serhiy Storchaka added the comment:
Are you have Python code which exposes a bug?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
___
___
R. David Murray added the comment:
Although this is clearly a bug, we've run into backward compatibility issues in
the past with promoting stdlib classic classes to new style, so I'm not sure if
the risk of fixing it is worth the benefit. It is obviously not a problem in
Python3.
Eric: I
Antoine Pitrou added the comment:
Ah, it seems the failure can happen because of hash randomization.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20006
___
New submission from Simon Sapin:
When given a file-like object, html5lib calls .read(0) in order to check if the
result is bytes or Unicode:
https://github.com/html5lib/html5lib-python/blob/e269a2fd0aafcd83af7cf1e65bba65c0e5a2c18b/html5lib/inputstream.py#L434
When given the result of
STINNER Victor added the comment:
The complete fix is maybe to write fflush() before fclose(), or at least
raise an exception if fclose() returns a non-zero result. Correctly,
file.close() returns a number in case of an error...
Oh sorry, I missed the line if (sts == -1) ... which raises
Simon Sapin added the comment:
Adding a proposed patch.
--
keywords: +patch
Added file: http://bugs.python.org/file33179/python-issue20007.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20007
Larry Hastings added the comment:
So all the PyRun_*Object functions are new in 3.4, and none of them are
documented yet?
Option 4 is silly--I don't think we should ship them as public APIs in 3.4 if
we're planning to rename them. I prefer the previous options.
p.s. fwiw I hate ExName.
Larry Hastings added the comment:
So far I agree that this should be postponed to 3.5.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19702
___
Changes by Antoine Pitrou pit...@free.fr:
--
components: +Tests
stage: - patch review
versions: +Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20006
___
Antoine Pitrou added the comment:
Here is a patch. The failure doesn't occur on 3.x because of f189da5bda26,
which clearly looks misled now.
--
assignee: - pitrou
keywords: +patch
Added file: http://bugs.python.org/file33180/issue20006.patch
___
Jaakko Moisio added the comment:
The new patch is fine as it is, but my logic behind using err_flag was the
following: err_flag was set solely based on the inspection of return value of
fwrite and ferror, without referencing to errno. It is of course true that at
the same time errno is set to
Serhiy Storchaka added the comment:
So all the PyRun_*Object functions are new in 3.4, and none of them are
documented yet?
Not all. Only following functions are new in 3.4:
Parser/parsetok.c:PyParser_ParseStringObject
Parser/parsetok.c:PyParser_ParseFileObject
Serhiy Storchaka added the comment:
Ah, it seems the failure can happen because of hash randomization.
Indeed. With -R switch 1/8 of tests are failed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20006
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +orsenthil, serhiy.storchaka
stage: - patch review
versions: +Python 2.7, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20007
Larry Hastings added the comment:
Are all the functions that use Object to indicate Unicode object instead of
string new in 3.4? Of those, how many are undocumented?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19518
Eric V. Smith added the comment:
My (poorly phrased) question really was: is resetting fieldnames documented to
force a re-read of the column headers? I don't see that it is, so I'm going to
call this a 3.5 enhancement request.
I agree with David that we can't change DictReader to inherit
Peter Otten added the comment:
Setting the fieldnames attribute of an existing DictReader is not documented.
Eric, there is no need for an enhancement (other than for the documentation) as
this already works in Python 3 where newstyle classes are the default. The
heart of the bug is really
Simon Sapin added the comment:
html5lib issue: https://github.com/html5lib/html5lib-python/issues/127
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20007
___
Simon Sapin added the comment:
I could reproduce on 3.3.3 and tip, but not 3.2.3 or 2.7.6.
--
versions: +Python 3.5 -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20007
___
Serhiy Storchaka added the comment:
Are all the functions that use Object to indicate Unicode object instead
of string new in 3.4? Of those, how many are undocumented?
Following 5 functions work with PyObject* filenames and have Object-less
variants which works with char * filenames:
Roundup Robot added the comment:
New changeset 24a043355050 by Serhiy Storchaka in branch '2.7':
Circumventing a bug in glibc (issue #17976).
http://hg.python.org/cpython/rev/24a043355050
--
___
Python tracker rep...@bugs.python.org
Larry Hastings added the comment:
Are we proposing renaming any functions that are either
a) not new in 3.4, or
b) were documented as of 3.4 beta 1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19518
Serhiy Storchaka added the comment:
Agree.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17976
___
___
Python-bugs-list mailing list
Larry Hastings added the comment:
Are those five functions new in 3.4 and undocumented?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19518
___
Guido van Rossum added the comment:
AFAIK %i and %d are the same.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
Python-bugs-list
Eric V. Smith added the comment:
Yes, looking through Objects/unicodeobject.c, 'u', 'i', and 'd' are treated the
same everywhere.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
Serhiy Storchaka added the comment:
Are those five functions new in 3.4 and undocumented?
PyErr_SetFromErrnoWithFilenameObject exists even in 2.7. Other 4
PyImport_*Object functions all added in 3.3 (see issue3080). All 5 functions
are documented.
14 new functions were added in 3.4.
Matthew Barnett added the comment:
It takes a long time due to excessive backtracking.
The regex implementation on PyPI finishes quickly because it contains some
extra logic to reduce the chances of that happening, but it could be tricky
trying to incorporate that into the existing re module.
Jens Timmerman added the comment:
sorry for my confusion,
libffi's website stated
libffi-3.0.14 was released on TBD.
I must have missed the TBD part.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4130
Tim Peters added the comment:
Closing this. Since nobody else wants have a go over two decades so far, no
point waiting for that ;-)
--
resolution: invalid - wont fix
stage: - committed/rejected
status: open - closed
___
Python tracker
R. David Murray added the comment:
Here is a proposed comment wording.
--
keywords: +patch
Added file: http://bugs.python.org/file33181/csv_dictread_setter_comment.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20004
R. David Murray added the comment:
Since it isn't easy to figure out that setting fieldnames to None would do
anything useful without looking at the code, I'd say a code comment would be
appropriate. The exception would be someone backporting code from python3, but
I think we'll just quietly
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
stage: committed/rejected -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18283
___
Peter Otten added the comment:
The proposed patch looks fine to me.
And for the record, I don't think setting fieldnames should be promoted in the
3.x documentation. Along the lines of Eric's suggestion I should have written
something like
import csv
with open(tmp.csv) as f:
... for i
R. David Murray added the comment:
Committed. Thanks, Peter.
--
resolution: - wont fix
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20004
PJ Eby added the comment:
The new patch will have weird results in the case of a parent module that
defines an attribute that's later replaced by an import, e.g. if
foo/__init__.py defines a variable 'bar' that's a proxy for the foo.bar module.
This is especially problematic if this proxy is
PJ Eby added the comment:
Unfortunately, this is not quite true: the weird edge cases for that approach
are simply *different*, and harder to diagnose. ;-)
The approach here can only affect execution paths that would currently raise
ImportError; that one can break execution paths that are
Changes by Serhiy Storchaka storch...@gmail.com:
--
versions: -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20007
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20007
___
___
Jim Carroll added the comment:
As requested, I've opened the issue with the libffi project:
https://github.com/atgreen/libffi/issues/63
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19998
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: needs patch - test needed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4492
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: needs patch - test needed
versions: -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7464
___
Richard Oudkerk added the comment:
Thanks for your hard work Nick!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19946
___
___
Python-bugs-list
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: - test needed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12441
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16404
___
___
New submission from Zachary Ware:
This patch makes extensive changes to test_decimal, with the ultimate goal of
making `python -m unittest discover Lib/test/ test_*.py` not choke on
test_decimal (see issue16748). Trying to do so uncovered a few other issues,
such as some tests not properly
Changes by Zachary Ware zachary.w...@gmail.com:
--
dependencies: +Clean up/refactor/make discoverable test_decimal, Fix test
discovery for test_codecmaps*.py, Fix test discovery for
test_concurrent_futures.py, Support ./python -m unittest in test_socket
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17781
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
I can't reproduce issue. Python just hangs on read() when socat is used as test
server. Perhaps I do something wrong.
--
nosy: +orsenthil, serhiy.storchaka
stage: - patch review
versions: +Python 3.4 -Python 3.2
Roundup Robot added the comment:
New changeset ebace0a5a33e by Serhiy Storchaka in branch '2.7':
Issue #20007: HTTPResponse.read(0) no more prematurely closes connection.
http://hg.python.org/cpython/rev/ebace0a5a33e
New changeset 47ae858cd661 by Serhiy Storchaka in branch '3.3':
Issue #20007:
New submission from steven Michalske:
When using the @property decorator the wrapped functions are not exposed for
source introspection. (At least I can't see how they are.)
The issue is then that Ipython %psource will show the source for the
@property as opposed to the function that it
Serhiy Storchaka added the comment:
2.7 is affected too.
Thank you Simon Sapin for your contribution.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: +Python 2.7
___
Python tracker
New submission from Civa Lin:
On windows xp (Taiwanese) platform...
c:\ py -c import time; print(time.strftime('%z', time.localtime()))
It will raise a UnicodeEncodeError in my system.
I think it's not a +HHMM format and has different behavior with document:
Roundup Robot added the comment:
New changeset 226c37c209fc by Antoine Pitrou in branch '2.7':
Issue #20006: Fix sporadic failures in test_weakset.
http://hg.python.org/cpython/rev/226c37c209fc
--
nosy: +python-dev
___
Python tracker
Roundup Robot added the comment:
New changeset a3d86f80c899 by Antoine Pitrou in branch '3.3':
Issue #20006: Fix sporadic failures in test_weakset.
http://hg.python.org/cpython/rev/a3d86f80c899
New changeset 26d92a21f6cf by Antoine Pitrou in branch 'default':
Issue #20006: Fix sporadic failures
Antoine Pitrou added the comment:
This was all my fault :) Thanks for reporting!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20006
R. David Murray added the comment:
As the documentation of the module says, we pass this call through to the
underlying c library. What does the Windows documentation say about %z?
A quick google turns up this hit, which seems to indicate it is a platform
problem:
Civa Lin added the comment:
Oh! Thanks your info!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20010
___
___
Python-bugs-list mailing list
New submission from Antony Lee:
As suggested on python-ideas, this small patch changes the constructor of
inspect.Parameter so that kind defaults to POSITIONAL_OR_KEYWORD, which
should make code that needs to construct Parameter objects slightly less
verbose (as I believe
Martin Panter added the comment:
Thanks for looking at this. Perhaps you weren’t pasting the HTTP response into
“socat”. After the six request lines are printed out, I enter the five lines
between HTTP response start and HTTP response end; I didn’t really make
this obvious. Otherwise,
Roundup Robot added the comment:
New changeset b0fbaed45956 by R David Murray in branch '3.3':
#19855: uuid.get_node now looks on the PATH for executables on unix.
http://hg.python.org/cpython/rev/b0fbaed45956
New changeset 2e856fcb9084 by R David Murray in branch 'default':
Merge: #19855:
1 - 100 of 108 matches
Mail list logo