Changes by koobs koobs.free...@gmail.com:
--
nosy: +koobs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11973
___
___
Python-bugs-list mailing
Charles-François Natali added the comment:
The test is failing on Tiger buildbots:
==
FAIL: test_parse_cert_CVE_2013_4238 (test.test_ssl.BasicSocketTests)
--
Drekin added the comment:
Related stackoverflow question:
http://stackoverflow.com/questions/18419787/where-does-pythons-interactive-prompt-output-to
.
--
nosy: +Drekin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12869
Charles-François Natali added the comment:
The first patch looks good, as for the second one, it'll take some time :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18808
___
Changes by Donald Stufft don...@stufft.io:
--
nosy: +dstufft
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18709
___
___
Python-bugs-list mailing
Stefan Behnel added the comment:
1. Why have the event builder wrap a tree builder? Can't it just be a
separate target?
You need a TreeBuilder in order to build the tree for the events.
If you want to use a different target than a TreeBuilder, you're free to do so.
That's the idea of
Charles-François Natali added the comment:
Alright, I think I know what's happening.
The Python implementation uses a TCP socket, whereas the native
implementation uses AF_UNIX socket.
The maximum size of data that can be written to a socket without
blocking is given by its send/receive
Changes by Charles-François Natali cf.nat...@gmail.com:
Added file: http://bugs.python.org/file31458/sendall_write.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18643
___
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +lars.gustaebel
versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18819
___
Martin Mokrejs added the comment:
Hi Ramchandra and Christian,
I am using numpy, matplotlib, expat/cElementTree, doing a lot of os.Popen
calls. But I think the problem is taht I have huge lists and when I do not need
them I do del(_mylist) in the code ASAP. That probably causes a lot of
Ramchandra Apte added the comment:
Here is one stacktrace I just got with the faulthandler installed. It does
not show in the trace any 3rd-party module so can I conclude it is a core
python bug? Just recompiling with -ggdb so eventually will have better
stacktraces.
I'm a C noob but I
Drekin added the comment:
Why are there actually more codepaths which may raise this issue? My naive idea
would be that input() is just thin wrapper around sys.stdout.write() (for
prompt) and sys.stdin.readline() which leads to sys.stdin.buffer.raw.read*
where is the place where some low
Roundup Robot added the comment:
New changeset 004743d210e4 by Christian Heimes in branch '3.3':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/004743d210e4
New changeset 577e9402cadd by Christian Heimes in branch 'default':
Issue
Christian Heimes added the comment:
Tiger has OpenSSL 0.9.7 which doesn't support IPv6 addresses. I have added a
workaround.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18709
___
Roundup Robot added the comment:
New changeset 8b962e831ff0 by Christian Heimes in branch '3.3':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/8b962e831ff0
New changeset 7b1da249ab6d by Christian Heimes in branch 'default':
Issue #18747:
Christian Heimes added the comment:
The patch looks good to me.
--
nosy: +christian.heimes
versions: +Python 3.4 -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11973
New submission from Mher Movsisyan:
urljoin('redis://localhost:6379/0', '/1')
'/1'
urljoin('http://localhost:6379/0', '/1')
'http://localhost:6379/1'
--
messages: 196125
nosy: mher.movsisyan
priority: normal
severity: normal
status: open
title: urljoin behaves differently with custom
New submission from Thibault Kruse:
To reproduce
$ python --version
Python 2.7.3
$ python -c 'from __future__ import unicode_literals; import csv; reader =
csv.reader(foo, delimiter=,)'
Traceback (most recent call last):
File string, line 1, in module
TypeError: delimiter must be an
Roundup Robot added the comment:
New changeset d5334d8907dc by Christian Heimes in branch '3.3':
Issue #11973: Fix a problem in kevent. The flags and fflags fields are now
http://hg.python.org/cpython/rev/d5334d8907dc
New changeset 8345fb616cbd by Christian Heimes in branch 'default':
Issue
Christian Heimes added the comment:
Does somebody want to write a test for the issue, too?
--
resolution: - fixed
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11973
Changes by Gökcen Eraslan gokcen.eras...@gmail.com:
--
nosy: +gkcn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18323
___
___
Python-bugs-list
Claudiu.Popa added the comment:
Here's a basic patch. I have two issues with it: the flag name used for
enabling the exceptions seems too verbose (use_python_exceptions, I'm opened to
new suggestions) and I don't know if the fallback to Fault exception if the
remote exception is not known is
Donald Stufft added the comment:
-1
This essentially gives the ability for an XMLRPC server to crash any python
code that interfaces with them unless you catch _every_ single exception
including ones like SystemExit, KeyboardInterupt, SyntaxError, StopIteration
etc.
An XMLRPC server is not
R. David Murray added the comment:
I agree that the 2.7 message is somewhat confusing, but I'm not sure it is
worth changing at this point in 2.7's life cycle.
For Python3, the message is correct and unambiguous: a bytes object is not a
string.
However, in 3.3, we have a regression:
R. David Murray added the comment:
I forgot to address the comment about accepting bytes in python3: the delimiter
really is a unicode character. In python3, non-ASCII delimiters are handled
correctly. So no, it isn't a byte anymore, it really is a string. Terry's
comment about 'char' in
Eli Bendersky added the comment:
Looking at this more, the Parser/Builder abstraction in ET leaks badly,
especially when it comes to incremental parsing. This manifests in (at least)
two ways:
1. The parser accepted by iterparse has to use the ET-provided TreeBuilder,
because the C
Stefan Behnel added the comment:
I attached a patch that removes the IncrementalParser class and merges its
functionality into the _IterParseIterator. It thus retains most of the
refactoring without adding new functionality and/or APIs.
I did not take a look if anything else from later
Eli Bendersky added the comment:
Thanks for the effort, Stefan, but I still think IncrementalParser is worth
keeping. It provides functionality that doesn't currently exist in ET, and IMHO
this functionality is both important and useful.
Renaming its methods to feed close kills the API
Stefan Behnel added the comment:
TreeBuilder has to support an explicit API for collecting and reporting events.
XMLParser has to call into this API and either not have _setevents at all or
have something public and documented. Note also that event hookup in the parser
makes sense in a way,
Stefan Behnel added the comment:
I still think IncrementalParser is worth keeping.
If you want to keep it at all cost, I think we should at least hide it behind a
function (as with iterparse()). If it's implemented as a class, chances are
that people will start relying on internals by
New submission from Serhiy Storchaka:
inspect.getclasstree() produces duplicated entities when it's argument contains
duplicated classes. This happened when a module contains class aliases. For
example `pydoc zipfile` outputs three entities for BadZipFile (BadZipfile and
error are aliases of
Eli Bendersky added the comment:
Stefan Behnel added the comment:
I still think IncrementalParser is worth keeping.
If you want to keep it at all cost, I think we should at least hide it
behind a function (as with iterparse()). If it's implemented as a class,
chances are that people will
Roundup Robot added the comment:
New changeset 0dbe45697efc by R David Murray in branch '3.3':
#16611: BaseCookie now parses 'secure' and 'httponly' flags.
http://hg.python.org/cpython/rev/0dbe45697efc
New changeset f81846c2b746 by R David Murray in branch 'default':
Merge #16611: BaseCookie
Vajrasky Kok added the comment:
This is the preliminary patch to fix the error message.
--
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31462/fix_error_message_reader_csv.patch
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
Fix committed. Thanks, Julien.
If you want to propose a new patch the makes the behavior more
consistent/useful with respect to what browsers and servers actually do, feel
free to propose one. I'm going to close this issue, though.
--
resolution:
Stefan Behnel added the comment:
Actually, let me revise my rpevious comment. I think we should fake the new
interface for now by adding a TreeEventBuilder that requires having its own
TreeBuilder internally, instead of wrapping an arbitrary target. That way, we
can avoid having to clean up
New submission from Brett Cannon:
Not sure if anyone really cares about this (I don't, but I figured I should at
least let it be known), but I realized that importlib.import_module() bypasses
builtins.__import__ by calling directly into the innards of importlib
(specifically _gcd_import()
Vajrasky Kok added the comment:
This is the second alternative of the patch to fix the error message using
different approach. I am not sure which one is better.
--
Added file:
http://bugs.python.org/file31463/fix_error_message_reader_csv_alternative_1.patch
Eli Bendersky added the comment:
Stefan, I don't mind looking at a working patch; however, it's not clear to me
how you intend to solve the iterparse-accepting-a-custom-XMLParser problem. As
for faking the new API, I don't know if that's a good idea because we're not
yet sure what that new
Serhiy Storchaka added the comment:
We can add in readline() the check that GzipFile is opened in read mode.
However it will slowdown readline(). See alse issue18003.
Note that the original example is not correct. zlib.compress() doesn't produce
legal Gzip file.
--
nosy:
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
nosy: +serhiy.storchaka
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18829
Stefan Behnel added the comment:
fully working patches will be considered
Let me remind you that it's not me who wants this feature so badly.
As for faking the new API, I don't know if that's a good idea because we're
not yet sure what that new API is.
If that's your concern, then I
Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18647
Eli Bendersky added the comment:
As for faking the new API, I don't know if that's a good idea because
we're not yet sure what that new API is.
If that's your concern, then I suggest not adding the feature at all, as
long as we don't know if we can (or should) keep up the IncrementalParser
Roundup Robot added the comment:
New changeset e3eec06aa12e by Serhiy Storchaka in branch '2.7':
Issue #18817: Fix a resource warning in Lib/aifc.py demo.
http://hg.python.org/cpython/rev/e3eec06aa12e
New changeset e0c33e0c0483 by Serhiy Storchaka in branch '3.3':
Issue #18817: Fix a resource
Serhiy Storchaka added the comment:
Thank you for your patch Vajrasky.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: +Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset f2b023135b1b by Charles-François Natali in branch '2.7':
Issue #18763: subprocess: The file descriptors are now closed after calling the
http://hg.python.org/cpython/rev/f2b023135b1b
New changeset 4c52d4bac03c by Charles-François Natali in branch
Changes by Tal Weiss t...@evature.com:
--
nosy: +Tal.Weiss
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18685
___
___
Python-bugs-list mailing
New submission from Tal Weiss:
All tests I ran comparing timing of the new regex module relative to the old re
module showed significant slower performance.
I'm attaching test code with regular expressions from our production server.
Tested on Python 2.7, 64 bit Linux + 64 bit Windows 7.
regex
Roundup Robot added the comment:
New changeset becbb65074e1 by Antoine Pitrou in branch 'default':
Issue #18808: Non-daemon threads are now automatically joined when a
sub-interpreter is shutdown (it would previously dump a fatal error).
http://hg.python.org/cpython/rev/becbb65074e1
--
Stefan Behnel added the comment:
Also, even if the new approach is implemented in the next release,
IncrementalParser can stay as a simple synonym to
XMLParser(target=EventBuilder(...)).
No it can't. According to your signature, it accepts a parser instance as
input. So it can't just create a
Antoine Pitrou added the comment:
Ok, I've committed the first patch.
--
versions: -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18808
___
Alex Volkov added the comment:
HI Vajrasky,
I fixed the typo in a comment and removed WIN32 constant definition from the
code.
I looked at the existing tearDown method, on line 79, it calls shutil.rmtree on
a directory above the files/directories I'm writing my test files, so the
statements
New submission from Alex Volkov:
This issue splits up an unrelated patch from issue 18731
http://bugs.python.org/issue18731
Added a test for telnetlib increasing test coverage.
Updated with the changes from code review of issue 18731
http://bugs.python.org/review/18731/patch/8923/33000
Changes by Charles-François Natali cf.nat...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
versions: +Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
Matthew Barnett added the comment:
The 'regex' module is not part of the CPython distribution, so it's not covered
by this tracker.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18832
Changes by Ned Deily n...@acm.org:
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18832
___
New submission from Ryan Gonzalez:
A have created to patches(for ccompiler.py and cygwinccompiler.py) to add Clang
as a compiler in distutils. The patches are here:
ccompiler.py: http://pastebin.com/yMGYys0P
cygwinccompiler.py: http://pastebin.com/a49qNP6n
I used the distutils version from
Ezio Melotti added the comment:
Apparently this has been fixed upstream in glibc:
http://sourceware.org/bugzilla/show_bug.cgi?id=15339
There's also a related discussion at
http://sourceware.org/bugzilla/show_bug.cgi?id=15726
Barry, can this be closed?
--
nosy: +ezio.melotti
type: -
Antoine Pitrou added the comment:
Works here on 13.04.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17759
___
___
Yavor added the comment:
Within this note https://sourceware.org/glibc/wiki/NameResolver about
getaddrinfo():
In case there was a *negative* answer it's unclear what should be returned.
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 6b33d786b46d by Ezio Melotti in branch '2.7':
#18833: add a test for test_telnetlib. Patch by Alex Volkov.
http://hg.python.org/cpython/rev/6b33d786b46d
New changeset 1b42e483e520 by Ezio Melotti in branch '3.3':
#18833: add a test for
Ezio Melotti added the comment:
Fixed, thanks for the report and the patch!
Could you also sign the contributor agreement?
http://www.python.org/psf/contrib/contrib-form/
--
assignee: - ezio.melotti
nosy: +ezio.melotti
resolution: - fixed
stage: - committed/rejected
status: open -
Ezio Melotti added the comment:
FTR this got fixed (i.e. the timeout is ignored) in 3.3 (b17662fc41af) and
default (6f8fef208958), but on 2.7.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17759
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com:
--
nosy: +jkloth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17741
___
___
Ezio Melotti added the comment:
The new tests produce a few warnings:
$ ./python -m test -uall test_multiprocessing_spawn
[1/1] test_multiprocessing_spawn
Using start method 'spawn'
Warning -- threading._dangling was modified by test_multiprocessing_spawn
Warning --
Eli Bendersky added the comment:
I actually have another idea. Since we all agree that passing a custom parser
to iterparse is dubious, IncrementalParser does not have to do that at all.
This will make it a much more future-proof API. So its signature can be:
class
Roundup Robot added the comment:
New changeset 33b156e118c0 by Ezio Melotti in branch '2.7':
#18803: fix more typos. Patch by Févry Thibault.
http://hg.python.org/cpython/rev/33b156e118c0
New changeset c57d99a8fc42 by Ezio Melotti in branch '3.3':
#18803: fix more typos. Patch by Févry
Ezio Melotti added the comment:
Fixed, thanks for the report and the patch!
--
assignee: docs@python - ezio.melotti
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
versions: +Python 2.7, Python 3.3
___
Python
Vajrasky Kok added the comment:
I realized there was a test that was similar with my test. I merged them into
one test.
I think the alternative is better than the original patch so I updated the
alternative patch only.
--
Added file:
Raymond Hettinger added the comment:
Do you have a suggestion for white-listing or a fault-to-exception mapper?
The current API makes faults difficult to use in Python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13397
Eli Bendersky added the comment:
Serhiy, patch 5 addresses your latest review. Thanks. As for _family_converter,
let's see how common this really becomes. Based on one use-case I wouldn't add
it to Enum itself. But if we see it gets repeated in many places, we can.
--
Added file:
New submission from Raymond Hettinger:
Currently, we have little to no control over the alignment of memory returned
by the PyMem functions.
I suggest variants such as PyMem_Alloc32(n) and PyMem_Alloc64(n) to return
suitably aligned data blocks.
GNU C provides memalign() for this purpose:
Donald Stufft added the comment:
Well you could possibly whitelist some exceptions although I still think that's
ultimately a bad idea because it means to prevent the remote server (or someone
in the middle of the connection) from being able to crash your program with an
arbitrary exception
Raymond Hettinger added the comment:
I should also mention posix_memalign() for Unix/Linux systems.
On systems without a clean way to provide aligned memory, we can always fall
back to regular malloc(). The API wouldn't guarantee alignment but would
comply when possible.
--
Eli Bendersky added the comment:
I had a chat with Nick about this, and a variation of the proposal in
http://bugs.python.org/msg196133 seems acceptable to us both. To summarize,
here's what goes into 3.4.
* The class will be named EventParser.
Rationale: The Incremental in IncrementalParser
Nick Coghlan added the comment:
Sounds good to me :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17741
___
___
Python-bugs-list mailing list
Nick Coghlan added the comment:
The event generation API for ElementTree being discussed in issue 17741 is
potentially relevant here.
I think that style of API is preferable, as it doesn't alter how data is fed
into the parser, just how it is extracted.
--
nosy: +ncoghlan
Stefan Behnel added the comment:
Hmm, did you look at my last comment at all? It solves both the technical
issues and the API issues very nicely and avoids any problems of potential
future changes. Let me quickly explain why.
The feature in question depends on two existing parts of the API:
79 matches
Mail list logo
