[issue23290] Faster set copying

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Actually set_find_free_slot() is not needed because there is 
set_insert_clean(). Results with using set_insert_clean():

$ ./python -m timeit -s "s = set(range(10**4))" -- "frozenset(s)"
Unpatched: 1000 loops, best of 3: 700 usec per loop
Patched:   1000 loops, best of 3: 570 usec per loop
Speed up: 23%

$ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**4//2) for j in 
range(2)}" -- "frozenset(s)"
Unpatched: 100 loops, best of 3: 2.2 msec per loop
Patched:   1000 loops, best of 3: 765 usec per loop
Speed up: 188%

$ ./python -m timeit -s "s = set(range(10**4)); s.add(-1); s.discard(-1)" -- 
"frozenset(s)"
Unpatched: 1000 loops, best of 3: 700 usec per loop
Patched:   1000 loops, best of 3: 605 usec per loop
Speed up: 16%

$ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**4//2) for j in 
range(2)}; s.add(-1); s.discard(-1)" -- "frozenset(s)"
Unpatched: 100 loops, best of 3: 2.2 msec per loop
Patched:   1000 loops, best of 3: 1.06 msec per loop
Speed up: 108%

Note that unpatched version is 6% slower now than before, perhaps due to 
issue23119.

--
Added file: http://bugs.python.org/file37878/set_faster_copy_3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

[Antoine Pitrou]

Antoine Pitrou added the comment:

It's tedious and complicated compared to the natural way.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22286] Allow backslashreplace error handler to be used on input

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14465] xml.etree.ElementTree: add feature to prettify XML output

[Matej Cepl]

Changes by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23191] fnmatch regex cache use is not threadsafe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23191] fnmatch regex cache use is not threadsafe

[Roundup Robot]

Roundup Robot added the comment:

New changeset fe12c34c39eb by Serhiy Storchaka in branch '2.7':
Issue #23191: fnmatch functions that use caching are now threadsafe.
https://hg.python.org/cpython/rev/fe12c34c39eb

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23191] fnmatch regex cache use is not threadsafe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN

[STINNER Victor]

New submission from STINNER Victor:

Recently, the issue #20188 "ALPN support for TLS" was fixed. The problem is 
that the check for the ALPN feature doesn't work with LibreSSL:

/* ALPN added in OpenSSL 1.0.2 */
#if OPENSSL_VERSION_NUMBER >= 0x1000200fL && !defined(OPENSSL_NO_TLSEXT)
# define HAVE_ALPN
#endif

On the buildbot OpenBSD 5.5 with LibreSSL, OPENSSL_VERSION_NUMBER is 2.x 
instead of 1.0.x. See also the issue #23177.

A workaround would be to disable the feature if LIBRESSL_VERSION_NUMBER is 
defined.

http://buildbot.python.org/all/builders/x86%20OpenBSD%205.5%203.x/builds/1333/steps/test/logs/stdio

 using PTY: False
running build
running build_ext
ldd: /usr/lib/libreadline.a: not an ELF executable
INFO: Can't locate Tcl/Tk libs and/or headers
building '_ssl' extension
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall 
-Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. 
-IInclude -I/usr/local/include 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Include 
-I/home/python-builds/3.x.borja-openbsd-x86/build -c 
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c -o 
build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.o
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c: In function 
'PySSL_selected_alpn_protocol':
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c:1481: warning: 
implicit declaration of function 'SSL_get0_alpn_selected'
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c: In function 
'_set_alpn_protocols':
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c:2404: warning: 
implicit declaration of function 'SSL_CTX_set_alpn_protos'
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c:2406: warning: 
implicit declaration of function 'SSL_CTX_set_alpn_select_cb'
gcc -pthread -shared -fPIC 
build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.o
 -L/usr/local/lib -lssl -lcrypto -o 
build/lib.openbsd-5.6-i386-3.5-pydebug/_ssl.so
building '_ctypes' extension
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall 
-Wstrict-prototypes -Werror=declaration-after-statement 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src 
-I./Include -I. -IInclude -I/usr/local/include 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Include 
-I/home/python-builds/3.x.borja-openbsd-x86/build -c 
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/_ctypes.c -o 
build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/_ctypes.o
 -Wall -fexceptions
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall 
-Wstrict-prototypes -Werror=declaration-after-statement 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src 
-I./Include -I. -IInclude -I/usr/local/include 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Include 
-I/home/python-builds/3.x.borja-openbsd-x86/build -c 
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callbacks.c -o 
build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callbacks.o
 -Wall -fexceptions
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall 
-Wstrict-prototypes -Werror=declaration-after-statement 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src 
-I./Include -I. -IInclude -I/usr/local/include 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Include 
-I/home/python-builds/3.x.borja-openbsd-x86/build -c 
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callproc.c -o 
build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callproc.o
 -Wall -fexceptions
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall 
-Wstrict-prototypes -Werror=declaration-after-statement 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include 
-Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src 
-I./Include -I. -IInclude -I/usr/local/include 
-I/home/python-builds/3.x.borja-openbsd-x86/build/Include 
-I/home/python-builds/3.x.borja-openbsd-x86/build -c 
/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/stgdict.c -o 
build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/stgdict.o
 -Wall -fexceptions
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall 
-Wstrict-prototypes -Werror=declaration-after-statement 
-Ibuild/temp.

[issue23177] test_ssl: failures on OpenBSD with LibreSSL

[STINNER Victor]

STINNER Victor added the comment:

_ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN: 
see issue #23329.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20188] ALPN support for TLS

[STINNER Victor]

STINNER Victor added the comment:

_ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN: 
see issue #23329.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14465] xml.etree.ElementTree: add feature to prettify XML output

[Martin Panter]

Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23330] h2py.py regular expression missing

[Thomas Roos]

New submission from Thomas Roos:

Hi,
my issue was that SO_BINDTODEVICE symbol was not defined in 
/Lib/plat-linux2/IN.py which is generated by h2py.py.
This is because the regex is missing out include dirs with "-" in the name.
In my yocto cross build system this define is in asm-generic, don't know about 
other build systems. 
.../usr/include/asm-generic/socket.h:#define SO_BINDTODEVICE   25
so could you please change following regex in h2py.py (patch attached)
-p_include = re.compile('^[\t ]*#[\t ]*include[\t ]+<([a-zA-Z0-9_/\.]+)')
+p_include = re.compile('^[\t ]*#[\t ]*include[\t ]+<([a-zA-Z0-9_/\.-]+)')

--
components: Cross-Build
files: IN.py.patch
keywords: patch
messages: 234817
nosy: Thomas.Roos
priority: normal
severity: normal
status: open
title: h2py.py regular expression missing
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file37879/IN.py.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23322] parser module docs missing second example

[Vipul Sharma]

Vipul Sharma added the comment:

Should I just remove the "See also" segment or just update its content like 
"See also: module parser.. Provides an interface to Python’s internal parser 
and byte-code compiler" ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23331] Add non-interactive version of Bdb.runcall

[Isaac Jurado]

New submission from Isaac Jurado:

The Bdb.runcall method shows a prompt right at the beginning of the function.  
If breakpoints are defined, it is sometimes handy to skip the prompt until the 
next breakpoint, if any.

This use case came up in our development environment for a Django application, 
from where we needed to set breakpoints only for certain request, allowing 
other request to run without interruption.  Our solution was to wrap with a 
WSGI middleware, something like this:

import sys
from bdb import BdbQuit
from pdb import Pdb

class DebuggingMiddleware(object):

def __init__(self, app):
self.aplicacion = app
self.debugger = Pdb()
our_setup_breakpoints_function(self.debugger)

def __call__(self, environ, start_response):
environ['DEBUGGER'] = self.debugger
frame = sys._getframe()
self.debugger.reset()
frame.f_trace = self.debugger.trace_dispatch
self.debugger.botframe = frame
self.debugger._set_stopinfo(frame, None, -1)
sys.settrace(self.debugger.trace_dispatch)
try:
return self.aplicacion(environ, start_response)
except BdbQuit:
pass  # Return None implicitly
finally:
self.debugger.quitting = 1
sys.settrace(None)

As you can see, it is basically a mix of Bdb.set_trace and Bdb.set_continue 
which we came up by trial and error.  If there was something like 
Bdb.runcall_no_prompt or an extra flag to Bdb.runcall to trigger this 
behaviour, this copy and paste would not be necessary.

--
components: Library (Lib)
messages: 234819
nosy: etanol
priority: normal
severity: normal
status: open
title: Add non-interactive version of Bdb.runcall
type: enhancement
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

[Nick Coghlan]

Nick Coghlan added the comment:

Most of the time when I'm working heavily with exceptions it's something 
related to contextlib, so I'm likely getting my exception details from either 
sys.exc_info() or the arguments to __exit__. That means I start out with an 
exception triple, and the only time I need to look at type(exc) or 
exc.__traceback__ is when I'm following exception chains.

However, Antoine's right that if you got your exception from an *except clause* 
rather than one of the more indirect APIs, then you're just going to have the 
exception, rather than an exception triple.

So I think that's where the argument for accepting "exception-or-triple" comes 
from: handling an exception directly is for use with except clauses, while 
handling triples is convenient for use with sys.exc_info(), __exit__ methods 
and for general backwards compatibility.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23324] Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown

[Alan Yorinks]

Alan Yorinks added the comment:

Additional information:
When using another example from PyMata, 
examples/digital_analog_io/callback_digital_analog_io.py, by adding the line:
if sys.platform == 'linux':
# noinspection PyUnresolvedReferences
self.arduino.nonblocking()
Allowed the program to run without much noticeable lag. This program is a lot 
less io intensive.

Also, setting the pyserial init option, writeTimeout, did not seem to affect 
performance when running either test program.

I have run cProfile and ran the output through pyprof2calltree for the 
polling_digital_analog_io.py example.

I am attaching the result of pyprof2calltree to a file called 3. I will provide 
a similar file for the run with python 2.7.8 in an addtional comment (I can't 
attach more than 1 file per comment).

--
Added file: http://bugs.python.org/file37880/3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23324] Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown

[Alan Yorinks]

Alan Yorinks added the comment:

I don't see the file I attached in the previous comment, so I have uploaded 4 
files to google drive at:

https://drive.google.com/folderview?id=0B0adDMMjxksDRGtiWFowVUh0RlE&usp=sharing

These files are the result of running a cProfile for 
polling_digital_analog_io.py through pyprof2calltree. The file "2" is for 
python 2.7.8 and "3" is for python 3.4.2

They can be viewed using kcachegrind.

I have also included "2c" and "3c" for the results of running 
callback_digital_analog_io.py

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23328] urllib2 fails for proxy credentials that contain a '/' character

[Senthil Kumaran]

Senthil Kumaran added the comment:

Yup, can confirm that this is problem. As Andy recognized, there is parsing 
error that fails on '/' character in the password.

The environ based proxies are used by urllib rather than urllib2. (The test 
case if relies on environ proxy, should use urllib.urlopen()), but the failure 
is coming from parsing done in httplib, so it affects both urllib and urllib2.

--
assignee:  -> orsenthil
nosy: +orsenthil
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones

[Walter Dörwald]

Walter Dörwald added the comment:

That analysis seems correct to me.

Stateless and stream codecs were the original implementation. 2006 I 
implemented incremental codecs: http://bugs.python.org/issue1436130

The intent was to have stateful codecs that can work with iterators and 
generators.

When Guido began reimplementing the io machinery for Python 3 he used 
incremental codecs as the basis.

--
nosy: +doerwalter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN

[Roundup Robot]

Roundup Robot added the comment:

New changeset 53e94a687570 by Benjamin Peterson in branch 'default':
disable ALPN on LibreSSL, which has a large version number, but not ALPN 
support (closes #23329)
https://hg.python.org/cpython/rev/53e94a687570

New changeset f7fd2776e80d by Benjamin Peterson in branch '2.7':
disable ALPN on LibreSSL, which has a large version number, but not ALPN 
support (closes #23329)
https://hg.python.org/cpython/rev/f7fd2776e80d

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22668] memoryview.format is corrupted due to dangling shared pointer

[Stefan Krah]

Stefan Krah added the comment:

Thanks for the detailed report!  Making a private copy of 'format' for
each memoryview generally sounds like the best solution.  However, format
strings can be arbitrarily large, so we'd need to store the copy in the
ob_array after shape, strides and suboffsets.

This of course would slow down memoryview creation in the general case.

Given that the disappearing format strings are only created during casting,
I think we can get away with a local solution (see patch).

--
Added file: http://bugs.python.org/file37881/issue22668-2.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN

[STINNER Victor]

STINNER Victor added the comment:

Cool, the issue looks like the issue has been fixed: the _ssl module can be 
build again.
http://buildbot.python.org/all/builders/x86%20OpenBSD%205.5%203.x/builds/1334/steps/compile/logs/stdio

Thanks for the quick fix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN

[Benjamin Peterson]

Benjamin Peterson added the comment:

(Thanks for pointing out the problem and the fix.)

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Mirko Vogt]

New submission from Mirko Vogt:

I trapped into a pitfall today with web programming using DateTime.isoformat() 
in the backend and Javascript on the frontend side.

isoformat() string'yfies a DateTime-object according to ISO 8601, which states 
that, if no timezone is specified, the string is supposed to be interpreted as 
UTC implicitly. isoformat() doesn't append any TZ if the object is UTC - so far 
so good.

However when interacting with JavaScript that leads to errors, as the 
ECMAScript ed 6 draft states (and most browser act like that): "date time 
strings without a time zone are to be treated as local, not UTC)."[1]

That is not Python's fault - however considering the issues this behaviour 
could cause as well as following the philosophy 'explicit is better than 
implicit', I'd suggest explicitly marking UTC-strings as such by adding a 
trailing 'Z'. According ISO 8601 that is totally fine, optional though.

[1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse

--
messages: 234829
nosy: mirkovogt
priority: normal
severity: normal
status: open
title: datetime.isoformat() -> explicitly mark UTC string as such
type: behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23255] SimpleHTTPRequestHandler refactor for more extensible usage.

[Ent]

Ent added the comment:

Latest patch with simpler(?) logic?

@Demian: This is a tough task! And I appreciate your kind words.

I have gone through your comments and I have made a few changes as per your 
suggestion but I have refrained from a few as well.

> get_status_type, apply_success_headers, apply_headers
The reason I wrote these three methods is that when a new dev wants to try out 
the library, he shouldn't have to handcode all the boilerplate. It makes no 
sense to to re-write this part of code for each new implementation. It can 
always be overwritten when required and it follows existing functionality. 

But I understand your idea of what should be part of Public API and I have 
changed the access levels of most of such methods to class methods.

I have updated `get_status_type` to be of O(1) (hopefully) and removed 
HTTPStatusType. 

I think since it is quite easy to overwrite `apply_headers` & 
`_get_status_type`, the default implementation can be straight up used by 
anyone with no modification and still yield satisfactory behaviour.

As for Doc, I really have no idea how to make it better. Maybe someone else can 
submit a patch later on? Or if you are fine, I will include your own Doc.

Thanks again.

--
Added file: http://bugs.python.org/file37882/jan27th.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[R. David Murray]

R. David Murray added the comment:

I wonder what the chances are that doing that would break other software with 
the opposite assumption (an assumption based on past Python behavior).

--
nosy: +belopolsky, r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Mirko Vogt]

Mirko Vogt added the comment:

Both implementations behave according the standard. If you assume otherwise you 
violate the standard - as JavaScript does.

If that change would break software, that software was broken from the 
beginning.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23255] SimpleHTTPRequestHandler refactor for more extensible usage.

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the updated patch. I will tweak the docs before I commit the patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Mirko Vogt]

Mirko Vogt added the comment:

Actually I'm not sure anymore whether NOT specifying a timezone is valid at all.

Even though the Spidermonkey documentation itself states, that it doesn't 
behave according to the ISO standard, several documents say that specifying the 
timezone is crucial (either "Z" or "+/-XX:XX").

I also found documents describing the standard which explicitly state that by 
default the local time is assumed, as JavaScript does.

Either way - there's so much different information and therewith confusion out 
there, that I highly recommend always specifying the timezone and would 
consider behaving otherwise as a bug.

Implementations usually don't throw an error but just assume something when the 
TZ designator is missing, which results in just different meanings. Needless to 
say that doesn't make the situation any better.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Do I understand correctly that the request is to append '+00:00' to the result 
of dt.isoformat() when dt is naive?  If so, -1.  Python's datetime module does 
not dictate how naive datetime instances should be interpreted.  UTC by default 
and local by default are both valid choices, but local by default is often 
preferable.  There are at least two reasons for that:

1. Local time is the "naïve" time.  Using UTC implies certain amount of 
sophistication.

2. Interpreting naive times as UTC is unnecessary because it is very easy to 
create aware instances with tzinfo=timezone.utc.

When communicating with javascript and in general when writing software for the 
Internet, I recommend using aware datetime instances.  For example,

>>> from datetime import *
>>> datetime.now(timezone.utc).isoformat()
'2015-01-27T18:27:33.216857+00:00'

--
type: behavior -> enhancement
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Mirko Vogt]

Mirko Vogt added the comment:

from datetime import *
In [4]: datetime.utcnow().isoformat()
Out[4]: '2015-01-27T18:51:18.332566'

When using utcnow() e.g. I would expect the result definitely being marked as 
UTC.

--
type: enhancement -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> I highly recommend always specifying the timezone and would consider behaving 
> otherwise as a bug.

I agree, and the datetime module lets you do that already:

>>> dt = datetime.now(timezone.utc)
>>> dt.isoformat()
'2015-01-27T18:53:40.380075+00:00'

or if you prefer local timezone,

>>> dt.astimezone().isoformat()
'2015-01-27T13:53:40.380075-05:00'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> When using utcnow() e.g. I would expect the result definitely being marked as 
> UTC.

Don't use utcnow().  This is a leftover from the times when there was no 
timezone support in datetime.

The documentation for utcnow [1] already points you in the right direction, but 
we can consider formally deprecating it together with utcfromtimestamp.

[1] https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Mirko Vogt]

Mirko Vogt added the comment:

I never said there is no way to result in an ISO 8601 string with UTC stated 
explicitly.

I showed a case where I think it is correct to assume UTC is stated ( e.g. 
utcnow()), however the result of isoformat() doesn't do so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23327] zipimport to import from non-ascii pathname on Windows

[Swapneel Ambre]

Swapneel Ambre added the comment:

Attaching a combined patch. I updated testUnencodable testcase from 
test_zipimport.py. Verified that without my fix, the testcase fails and it 
passes with my fix.

--
Added file: http://bugs.python.org/file37883/zipimport_fix_withtest.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

What is your specific proposal?

As I explained, we cannot assume that naive timezone instances are in UTC 
because while sometimes they are (as in datetime.utcnow()), more often they are 
not (as in datetime.now()).  So changing dt.isoformat() when dt is naive is 
wrong.

Another alternative would be to return aware instances from utcnow(), but that 
would break a lot of code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

s/timezone instances/datetime instances/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Mirko Vogt]

Mirko Vogt added the comment:

I got that - so marking utcnow() as deprecated seems like a good idea.
But it's not just about utcnow() but also now().

now() also doesn't return any timezone stated by default - which I would still 
consider as a bug. However making now() require a TZ being specified would 
probably also break a lot of code. But then, using function called isoformat() 
- on whatever object, naive or not - I'd expect a timezone being specified - 
since that's what I finally think the ISO-standard actually says.

I see that my initial proposal doesn't work out, but I'm still not happy with 
the current situation I'm however also not sure how to change properly without 
breaking existing code using those functions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Mirko,

You may want to review #9527.  I don't think we left any stone unturned in this 
area.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23332] datetime.isoformat() -> explicitly mark UTC string as such

[Mirko Vogt]

Mirko Vogt added the comment:

Just to clarify my problem - then I'll just happily use 
datetime.now(tzutc()).isoformat()

 - There is datetime.now() which is supposed to be used (no utcnow() anymore)
 - datetime.now() might return a naive object, when no TZ is specified
 - *However* also the naive variant implements the class isoformat() which is 
described as "Return a string representing the date in ISO 8601 format"
 - ISO 8601 can and should be understood such as the TZ-designator is required 
(I think we agreed on that).
 - However isoformat() called on a naive object returns a string with no TZ 
designator

I would at least suggesting adding a note for isoformat() about being called on 
naive datetime objects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23055] PyUnicode_FromFormatV crasher

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Georg, what is your word as release manager of 3.2/3.3? I would commit the 
patch in 2.7 if there are no objections.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23055] PyUnicode_FromFormatV crasher

[Georg Brandl]

Georg Brandl added the comment:

It's fine to commit it to both branches.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23055] PyUnicode_FromFormatV crasher

[Roundup Robot]

Roundup Robot added the comment:

New changeset e6b9e277fbf4 by Serhiy Storchaka in branch '2.7':
Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV.  Analysis
https://hg.python.org/cpython/rev/e6b9e277fbf4

New changeset f849f937f78c by Serhiy Storchaka in branch '3.2':
Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV.  Analysis
https://hg.python.org/cpython/rev/f849f937f78c

New changeset 6caed177a028 by Serhiy Storchaka in branch '3.3':
Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV.  Analysis
https://hg.python.org/cpython/rev/6caed177a028

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19949] Explicitly skip or mask skipped/disabled tests in test_xpickle

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23055] PyUnicode_FromFormatV crasher

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19949] Explicitly skip or mask skipped/disabled tests in test_xpickle

[Roundup Robot]

Roundup Robot added the comment:

New changeset 94d8524086bd by Serhiy Storchaka in branch '2.7':
Issue #19949: The test_xpickle test now tests compatibility with installed
https://hg.python.org/cpython/rev/94d8524086bd

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19949] Explicitly skip or mask skipped/disabled tests in test_xpickle

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11145] '%o' % user-defined instance

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Hey, Armin. Do you want to continue bug hunting?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19681] test_repr (test.test_functools.TestPartialC) failures

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping.

--
keywords: +needs review
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22079] Ensure in PyType_Ready() that base class of static type is static

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2504] Add gettext.pgettext() and variants support

[Hanno Zulla]

Hanno Zulla added the comment:

Can we please get pgettext for Python?

--
nosy: +Hanno.Zulla

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2504] Add gettext.pgettext() and variants support

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19681] test_repr (test.test_functools.TestPartialC) failures

[Berker Peksag]

Berker Peksag added the comment:

issue19681_2.patch LGTM.

--
nosy: +berker.peksag
stage: patch review -> commit review
versions: +Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11145] '%o' % user-defined instance

[Armin Rigo]

Armin Rigo added the comment:

Sorry, your patch still contains similar issues.  I postponed continuing to 
bounce it back and forth, but it seems that someone else needs to take my place 
now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed

[STINNER Victor]

New submission from STINNER Victor:

While working on the issue #23243 ("asyncio: emit ResourceWarning warnings if 
transports/event loops are not explicitly closed"), I saw that 
SelectorEventLoop._accept_connection() currently ignores errors on the creation 
of a transport.

When a server gets an incoming connection: it calls sock.accept(), creates a 
protocol, and then create the transport. It doesn't wait until the 
connection_made() of the protocol is called (until the transport was 
successfully created).

For example, for a SSL server, the client may decide to close the connection 
because it doesn't trust the server certificate. In this case, the SSL 
handshake fails at server side.

Currently, the user of the asyncio API cannot decide how to handle this failure.

I propose to call the connection_lost() method of the protocol with the 
exception, even if the connection_made() method of the protocol was not called 
(and will never be called). Attached patch implements this idea.

It's a change in the undocumented "state machine" of protocols. Before, it was 
not possible to switch directly to connection_lost(): there is even an 
assertion which ensures that it never occurs in some unit tests.

A server may log the connection failure, blacklist temporarely the client IP, 
etc.

Problem: Since the protocol doesn't know the transport yet, it doesn't have 
access to the socket, and so cannot retrieve the IP address of the client.

Maybe a new method should be added to protocols to handle this case?

How do other event loops (Twisted, eventlet, Tornado, etc.) handle failures on 
incoming connection?

--
components: asyncio
files: accept_error.patch
keywords: patch
messages: 234856
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: call protocol.connection_lost() when the creation of transport 
failed
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37884/accept_error.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed

[Antoine Pitrou]

Antoine Pitrou added the comment:

IMO, connection_lost() should never be called if connection_made() wasn't 
called. That's a breach of the API contract.

(at one point, I suggested a connection_failed() for that purpose, but it was 
shut down - it was in relationship to the idea of a reconnecting client, but 
can still be more broadly useful)

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed

[STINNER Victor]

STINNER Victor added the comment:

> - SelectorEventLoop._accept_connection() doesn't care of the creation of the 
> transport failed

Fixing this issue requires to change the design of asyncio, so I chose to open 
a new issue: issue #2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13128] httplib debuglevel on CONNECT doesn't print response headers

[Demian Brecht]

Demian Brecht added the comment:

Ping.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed

[STINNER Victor]

STINNER Victor added the comment:

FYI I opened a thread about this issue on the Tulip mailing list.

Antoine Pitrou added the comment:
> IMO, connection_lost() should never be called if connection_made() wasn't 
> called. That's a breach of the API contract.

Yes, I agree.

> (at one point, I suggested a connection_failed() for that purpose, but it was 
> shut down - it was in relationship to the idea of a reconnecting client, but 
> can still be more broadly useful)

I like the "connection_failed" name. We may call
protocol.connection_failed(transport), so the protocol gets access to
the socket and so to the IP addres.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13128] httplib debuglevel on CONNECT doesn't print response headers

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the patch! Could you revert unrelated changes (whitespaces, PEP 8 
etc.) if you have time?

--
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13128] httplib debuglevel on CONNECT doesn't print response headers

[Demian Brecht]

Demian Brecht added the comment:

Sure, I should have some time later today to do so.

Should such changes not be made as they're encountered in order to clean
up the older code that isn't up to spec? Or should they only be made as
the code is modified?

On 2015-01-27 2:58 PM, Berker Peksag wrote:
> 
> Berker Peksag added the comment:
> 
> Thanks for the patch! Could you revert unrelated changes (whitespaces, PEP 8 
> etc.) if you have time?
> 
> --
> stage: patch review -> commit review
> 
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21862] cProfile command-line should accept "-m module_name" as an alternative to script path

[Mayank Tripathi]

Mayank Tripathi added the comment:

Updated the patch and added docs and tests.

--
Added file: http://bugs.python.org/file37885/cProfile_module_option_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed

[STINNER Victor]

STINNER Victor added the comment:

Oh, accept_error.patch causes issues with the new SSL implementation. 
SSLProtocol.feed_data() is called before SSLProtocol.connection_made() is 
called. _SelectorSocketTransport constructor calls loop.add_reader() 
immediatly, but it only schedules a call to protocol.connection_made() with 
loop.call_soon().

The call to loop.add_reader() should maybe be scheduled after the call to 
connection_made()? To ensure that protocol methods (feed_data) are not called 
before connection_made() has been called.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23208] asyncio: add BaseEventLoop._current_handle (only used in debug mode)

[Roundup Robot]

Roundup Robot added the comment:

New changeset d61d1e73674f by Victor Stinner in branch '3.4':
asyncio: sync with Tulip
https://hg.python.org/cpython/rev/d61d1e73674f

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Demian Brecht]

New submission from Demian Brecht:

This is an attempt to bring a little more sanity to the http.client module 
through improvements to the architecture. The overarching intention of the 
patch is to modularize the HTTP versions, providing the following benefits:

* Make each protocol easier to work on independent of one another
* Make integrating future versions easier. This is intended as a stepping stone 
to integrating support for HTTP 2
* Separation of concerns between connection and application protocol

Immediate issues that this solves:
* Content-Length when a list is passed in. Currently the content length is set 
to the size of the list rather than the sum of the elements of the list
* Provides a little more user-friendly errors when invalid objects are passed 
in as header values


Note: This is still in a WIP progress state but shouldn't take much longer to 
get into a commit-able state. There's some work to be done on deserialization 
and it's entirely documentation. However, tests are passing so I figured now 
would be a good time to get initial feedback on the work. In hindsight, a PEP 
would likely have been best (it was initially intended to be put into httplib3, 
but I thought I might as well try it as a patch submission given it's largely 
backwards compatible).

--
components: Library (Lib)
files: http_proto.patch
keywords: patch
messages: 234866
nosy: demian.brecht
priority: normal
severity: normal
status: open
title: http.client refactor
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file37886/http_proto.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Demian Brecht]

Demian Brecht added the comment:

Note that this patch also depends on Antoine's TransformDict patch in #18986.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +orsenthil

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Demian Brecht]

Demian Brecht added the comment:

Attaching a file /with/ http.proto this time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Ethan Furman]

Changes by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Demian Brecht]

Changes by Demian Brecht :


Added file: http://bugs.python.org/file37887/http_proto_1.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[Martin Panter]

Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23334] http.client refactor

[R. David Murray]

R. David Murray added the comment:

Quantifying "largely" will be important.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23152] fstat64 required on Windows

[Steve Dower]

Steve Dower added the comment:

Looks like it was only the _io module needing more updates. New patch attached.

--
Added file: http://bugs.python.org/file37888/py_fstat_3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23335] _ssl.c cannot be compiled with older versions of OpenSSL

[Ned Deily]

New submission from Ned Deily:

_ssl.c compilation is broken on default and 27 when building with older 
(pre-1.0.1 ?) versions of OpenSSL:
  
/py/dev/3x/source/Modules/_ssl.c:2296:24: error: use of undeclared identifier
  'OPENSSL_NPN_NEGOTIATED'
if (alpn && ret != OPENSSL_NPN_NEGOTIATED)

The code added by eaa38b75cc78 (default) and 94ec4d8cf104 (2.7) doesn't account 
for the possibility that NPN is not available.  (The Snow Leopard buildbots are 
down at the moment but I would expect them to be failing with this.)

--
messages: 234871
nosy: benjamin.peterson, ned.deily
priority: critical
severity: normal
stage: needs patch
status: open
title: _ssl.c cannot be compiled with older versions of OpenSSL
versions: Python 2.7, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20188] ALPN support for TLS

[Ned Deily]

Ned Deily added the comment:

_ssl.c cannot be compiled with pre-NPN versions of OpenSSL: see Issue23335.

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23336] Thread.LockType is misnamed

[cindykrafft]

New submission from cindykrafft:

The tp_name field in thread.LockType is set as "thread.lock". This is incorrect 
and conflicts with the value set in dummy_thread.

Python 2.7.6 (default, Sep  9 2014, 15:04:36) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import thread
>>> import dummy_thread
>>> thread.LockType.__name__
'lock'
>>> dummy_thread.LockType.__name__
'LockType'

Code which depends on the ability to look up a class based on module and name 
(see the following code taken from pickle.py) breaks due to this behavior, so 
my preferred fix would be to change tp_name to a value consistent with 
dummy_thread.

try:
__import__(module)
mod = sys.modules[module]
klass = getattr(mod, name)
except (ImportError, KeyError, AttributeError):
raise PicklingError(
"Can't pickle %r: it's not found as %s.%s" %
 (obj, module, name))

Happy to submit a patch if someone could confirm.

--
components: Library (Lib)
messages: 234873
nosy: cindykrafft
priority: normal
severity: normal
status: open
title: Thread.LockType is misnamed
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23285] PEP 475 - EINTR handling

[Ned Deily]

Ned Deily added the comment:

I added a few prints to the send and receive loops of _test_send.  When running 
on a reasonably current Debian testing Linux:

./python Lib/test/eintrdata/eintr_tester.py
test_read (__main__.OSEINTRTest) ... ok
test_wait (__main__.OSEINTRTest) ... ok
test_wait3 (__main__.OSEINTRTest) ... ok
test_wait4 (__main__.OSEINTRTest) ... ok
test_waitpid (__main__.OSEINTRTest) ... ok
test_write (__main__.OSEINTRTest) ... ok
test_accept (__main__.SocketEINTRTest) ... ok
test_recv (__main__.SocketEINTRTest) ... ok
test_recvmsg (__main__.SocketEINTRTest) ... ok
test_send (__main__.SocketEINTRTest) ... len(data) = 50331651
 sent = 183360, written = 183360
 sent = 50148291, written = 50331651
 chunk = 50331651, total read = 50331651
ok
test_sendall (__main__.SocketEINTRTest) ... len(data) = 50331651
 chunk = 49323840, total read = 49323840
 sent = None, written = 50331651
 chunk = 1007811, total read = 50331651
ok
test_sendmsg (__main__.SocketEINTRTest) ... len(data) = 50331651
 sent = 183360, written = 183360
 sent = 50148291, written = 50331651
 chunk = 50331651, total read = 50331651
ok

--
Ran 12 tests in 10.139s

OK

When run on OS X (10.10.1):

test_read (__main__.OSEINTRTest) ... ok
test_wait (__main__.OSEINTRTest) ... ok
test_wait3 (__main__.OSEINTRTest) ... ok
test_wait4 (__main__.OSEINTRTest) ... ok
test_waitpid (__main__.OSEINTRTest) ... ok
test_write (__main__.OSEINTRTest) ... ok
test_accept (__main__.SocketEINTRTest) ... ok
test_recv (__main__.SocketEINTRTest) ... ok
test_recvmsg (__main__.SocketEINTRTest) ... ok
test_send (__main__.SocketEINTRTest) ... len(data) = 50331651
 sent = 8192, written = 8192
 chunk = 8192, total read = 8192
 chunk = 8192, total read = 16384
 sent = 16384, written = 24576
 chunk = 8192, total read = 24576
 chunk = 8192, total read = 32768
 chunk = 8192, total read = 40960
 chunk = 8192, total read = 49152
 sent = 32768, written = 57344
 chunk = 8192, total read = 57344
 chunk = 8192, total read = 65536
 chunk = 8192, total read = 73728
 chunk = 8192, total read = 81920
 chunk = 8192, total read = 90112
 sent = 40960, written = 98304
 chunk = 8192, total read = 98304
 chunk = 8192, total read = 106496
 chunk = 8192, total read = 114688
 chunk = 8192, total read = 122880
 sent = 32768, written = 131072
 chunk = 8192, total read = 131072
 chunk = 8192, total read = 139264
 chunk = 8192, total read = 147456
 chunk = 8192, total read = 155648
 chunk = 8192, total read = 163840
 sent = 40960, written = 172032
 chunk = 8192, total read = 172032
 chunk = 8192, total read = 180224
 chunk = 8192, total read = 188416
 chunk = 8192, total read = 196608
 sent = 32768, written = 204800
 chunk = 8192, total read = 204800
 chunk = 8192, total read = 212992
 chunk = 8192, total read = 221184
 chunk = 8192, total read = 229376
 chunk = 8192, total read = 237568
 sent = 40960, written = 245760
 chunk = 8192, total read = 245760
 chunk = 8192, total read = 253952
 chunk = 8192, total read = 262144
 chunk = 8192, total read = 270336
 sent = 32768, written = 278528
 chunk = 8192, total read = 278528
 chunk = 8192, total read = 286720
 chunk = 8192, total read = 294912
 chunk = 8192, total read = 303104
 chunk = 8192, total read = 311296
 sent = 40960, written = 319488
[... and so on]

When run standalone, the tests do eventually finish without error but take a 
*long* time to do so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com