[issue22028] Python 3.4.1 Installer ended prematurely (Windows msi)

[Piotr Dobrogost]

Changes by Piotr Dobrogost :


--
nosy: +piotr.dobrogost

___
Python tracker 

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

[issue23209] asyncio: break some cycles

[STINNER Victor]

STINNER Victor added the comment:

I noticed that _ProactorBasePipeTransport doesn't clear its reference to the 
socket when it is closed. I changed this in the following commit (now merged in 
Python 3.4 & 3.5):
https://code.google.com/p/tulip/source/detail?r=61ce7def97272ab1a6488545dc392160c2fbe316

--

___
Python tracker 

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

[issue22560] New SSL implementation based on ssl.MemoryBIO

[Roundup Robot]

Roundup Robot added the comment:

New changeset fb3761de0d3c by Victor Stinner in branch '3.4':
Issue #22560: Fix SSLProtocol._on_handshake_complete()
https://hg.python.org/cpython/rev/fb3761de0d3c

--

___
Python tracker 

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

[issue22560] New SSL implementation based on ssl.MemoryBIO

[STINNER Victor]

STINNER Victor added the comment:

Buildbots are happy. There is no remaining things to do, I close the issue.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue22560] New SSL implementation based on ssl.MemoryBIO

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3c37825d85d3 by Victor Stinner in branch '3.4':
Issue #22560: Fix typo: call -> call_soon
https://hg.python.org/cpython/rev/3c37825d85d3

--

___
Python tracker 

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

Re: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder

[M.-A. Lemburg]

On 15.01.2015 05:43, Martin Panter wrote:
> 
> New patch that also fixes StreamWriter.writelines() in general for the byte 
> codecs

Could you explain this new undocumented class ?

+class _IncrementalBasedWriter(StreamWriter):
+"""Generic StreamWriter implementation.
+
+The _EncoderClass attribute must be set to an IncrementalEncoder
+class to use.
+"""
+
+def __init__(self, stream, errors='strict'):
+super().__init__(stream, errors)
+self._encoder = self._Encoder(errors)
+
+def write(self, object):
+self.stream.write(self._encoder.encode(object))
+
+def reset(self):
+self.stream.write(self._encoder.encode(final=True))
+

Note that the doc-string mentions a non-existing attribute and there
are doc-string missing for the other methods.

The purpose appears to be a StreamWriter which works with
an IncrementalEncoder. A proper name would thus be
IncrementalStreamWriter which provides an .encode()
method which adapts the signature of the incremental encoder
to the one expected for StreamWriters and Codecs.

-- 
Marc-Andre Lemburg
eGenix.com

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

[issue22198] Odd floor-division corner case

[Petr Viktorin]

Petr Viktorin added the comment:

ping, is there anything I can do to help push the patch forward?

--

___
Python tracker 

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

[issue22198] Odd floor-division corner case

[Mark Dickinson]

Mark Dickinson added the comment:

The patch is fine; I just need to find time to look at it properly.  That might 
take a week or two.  Sorry for the delay.

--

___
Python tracker 

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

[issue23242] asyncio: Process must close the transport when the process exit

[Roundup Robot]

Roundup Robot added the comment:

New changeset df493e9c6821 by Victor Stinner in branch '3.4':
Issue #23242: asyncio.SubprocessStreamProtocol now closes the subprocess
https://hg.python.org/cpython/rev/df493e9c6821

--
nosy: +python-dev

___
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

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2f13d53f4680 by Victor Stinner in branch '3.4':
Issue #23243: Fix asyncio._UnixWritePipeTransport.close()
https://hg.python.org/cpython/rev/2f13d53f4680

New changeset aef0f9b4e729 by Victor Stinner in branch '3.4':
Issue #23243: Close explicitly event loops in asyncio tests
https://hg.python.org/cpython/rev/aef0f9b4e729

New changeset f9b127188d43 by Victor Stinner in branch '3.4':
Issue #23243: Close explicitly transports in asyncio tests
https://hg.python.org/cpython/rev/f9b127188d43

--
nosy: +python-dev

___
Python tracker 

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

[issue17546] Document the circumstances where the locals() dict get updated

[R. David Murray]

R. David Murray added the comment:

Your formulation is more concise, thank you.

I suggest dropping the word 'additionally'.  Also, "how it does" would be 
better phrased as "how it changes", I think.  (It really should be "whether and 
how it changes", but in deference to Anatoly's 'advanced English' comment I'm 
willing to let that imprecision slide).

--

___
Python tracker 

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

[issue23245] urllib2: urlopen() gets exception(kwargs bug?)

[R. David Murray]

R. David Murray added the comment:

More likely http_class isn't what you think it is (ie: it might be an 
HTTPSConnection subclass that hasn't been updated to deal with 2.7.9.  Can you 
check that?

--
components: +Library (Lib) -Extension Modules
nosy: +alex, r.david.murray
type: compile error -> behavior

___
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:

I fixed a lot of methods and tests to ensure that all event loops and 
transports are properly closed. These changes were required to prepare the 
integration of this change.

Many changed were real bug fixes: closing explicitly tranports on error avoids 
to leak resources.

Some ResourceWarning are still emited on SSL server tests.

--

___
Python tracker 

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

[issue23242] asyncio: Process must close the transport when the process exit

[STINNER Victor]

STINNER Victor added the comment:

> I'm not sure that it's the most efficient way to close the transport. It may 
> be better to close the transport in the connection_lost() method of the 
> protocol.

"process_exited", not "connection_lost".

I implemented this option which is simpler and more efficient (always and 
immediatly close the transport).

Clearing the reference to the transport in the Process is less important, it 
can be done later in a different issue/changeset. I close this issue.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue17546] Document the circumstances where the locals() dict get updated

[Martin Panter]

Martin Panter added the comment:

What about instead of

'''
Whether changes to one are reflected in the other after the call returns is 
undefined; additionally, the dictionary may change unpredictably after the 
call, and how it does is implementation-specific.
'''

substitue this wording:

'''
Whether changes to one are reflected in the other after the call returns, and 
when such updates occur, is undefined and implementation-specific.
'''

The old wording seems under-specified. It would allow a function call, garbage 
collection, etc, to clobber the dictionary, say overwriting with another 
function’s locals(), before you get a chance to work with the dictionary.

--
nosy: +vadmium

___
Python tracker 

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

[issue18986] Add a case-insensitive case-preserving dict

[Martin Panter]

Martin Panter added the comment:

For the record, this is related to PEP 455 (key-transforming dictionary)

--
nosy: +vadmium

___
Python tracker 

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

[issue17546] Document the circumstances where the locals() dict get updated

[R. David Murray]

R. David Murray added the comment:

Yeah, the question of thread-safety in regards to what we are talking about 
here also occurred to me.  That is, the wording makes one wonder if locals is 
thread safe or not.  I don't see your suggested wording as making it clearer, 
though.

The problem is that it *is* underspecified.

So I think the correct description of the current under-specification is that 
locals() returns a copy of the current locals namespace.  If you modify the 
thing returned by locals it may or may not update the local namespace.  If you 
modify the local namespace (by doing x = y or its equivalents) the change may 
or may not be reflected in the object that was returned by locals().

Now, how do we boil that down?  Or do we just say it more or less that way?

--

___
Python tracker 

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

[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

[Robert Kuska]

Robert Kuska added the comment:

FYI The bug was found in libffi. I have tried and rebuilt python also with 
*bundled libffi* with the *same result* (=test failure). There is more info in 
the bugzilla mentioned in my previous post along with the libffi patch.

--

___
Python tracker 

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

[issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task

[STINNER Victor]

Changes by STINNER Victor :


--
stage: resolved -> 

___
Python tracker 

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

[issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8adf1896712d by Victor Stinner in branch '3.4':
Closes #23219: cancelling asyncio.wait_for() now cancels the task
https://hg.python.org/cpython/rev/8adf1896712d

--
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

[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

[Steve Dower]

Steve Dower added the comment:

You're running on Fedora, not Windows, so this is not the right issue. You 
should open a new one and probably post on python-dev to get some attention 
(since there's no useful nosy lists right now and ctypes has no maintainer).

--

___
Python tracker 

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

[issue23245] urllib2: urlopen() gets exception(kwargs bug?)

[Douman]

Douman added the comment:

Yes, i checked what is http_class. It is passed as httplib.HTTPSConnection
Before submitting this issue i checked httplib.py in my installation of py2 and 
there https://hg.python.org/cpython/file/2.7/Lib/httplib.py

HTTPSConnection has argument "context".

Btw, it would be nice to update comments in urllib2 so that it would be more 
accurate

--

___
Python tracker 

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

[issue23245] urllib2: urlopen() gets exception(kwargs bug?)

[Douman]

Douman added the comment:

Btw, i also tried to replace **kwargs with usual argument and it didn't throw 
exception

--

___
Python tracker 

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

[issue23245] urllib2: urlopen() gets exception(kwargs bug?)

[Douman]

Douman added the comment:

Also according to documentation this class was specifically updated with 
context in 2.7.9
I guess then there should commit related to adding of "context" to 
HTTPSConnection

--

___
Python tracker 

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

[issue23245] urllib2: urlopen() gets exception(kwargs bug?)

[Douman]

Douman added the comment:

It seems to be this one
https://hg.python.org/cpython/rev/1882157b298a

--

___
Python tracker 

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

[issue18835] Add aligned memory variants to the suite of PyMem functions/macros

[Antoine Pitrou]

Antoine Pitrou added the comment:

Due to the realloc() problem, I'm thinking that the best course for Numpy would 
be to use its own allocator wrapper like Nathaniel outligned.
Also, Numpy wants calloc() for faster allocation of zeroed arrays...

--

___
Python tracker 

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

[issue18986] Add a case-insensitive case-preserving dict

[STINNER Victor]

STINNER Victor added the comment:

The API is simple and well defined, the addition is small, I don't understand 
what is the problem with this enhancement.

--

___
Python tracker 

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

[issue23245] urllib2: urlopen() gets exception(kwargs bug?)

[Douman]

Douman added the comment:

I made additional experiments and now i'm confused
When i tried to execute urlopen in python interpeter it worked fine.
But it fails for me when i attempt to do so via some helper function in search 
engine of qBittorent it throw exception

https://github.com/qbittorrent/qBittorrent/blob/master/src/searchengine/nova/helpers.py

What is curious... all exceptions should be passed without notices, but for 
some reason python does throw exception even though all are catched and passed

--
Added file: http://bugs.python.org/file37715/callstack_urllib2_full

___
Python tracker 

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

[issue23018] Add version info to python

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3f7e483cebef by Steve Dower in branch 'default':
Issue 23018: Add version info to python[w].exe
https://hg.python.org/cpython/rev/3f7e483cebef

--
nosy: +python-dev

___
Python tracker 

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

[issue23160] Respect the environment variable SVNROOT in external-common.bat

[Roundup Robot]

Roundup Robot added the comment:

New changeset 294501835890 by Steve Dower in branch '2.7':
Closes #23160: Respect the environment variable SVNROOT in external-common.bat 
(patch by anselm.kruis)
https://hg.python.org/cpython/rev/294501835890

--
nosy: +python-dev
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

[issue23018] Add version info to python

[Steve Dower]

Changes by Steve Dower :


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

___
Python tracker 

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

[issue23160] Respect the environment variable SVNROOT in external-common.bat

[Roundup Robot]

Roundup Robot added the comment:

New changeset 45e2c95bb802 by Steve Dower in branch '3.4':
Closes #23160: Respect the environment variable SVNROOT in external-common.bat 
(patch by anselm.kruis)
https://hg.python.org/cpython/rev/45e2c95bb802

--

___
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:

Victor, I've been testing your patch and it's mostly good (a few obscure errors 
you'd never find without a compiler), but I think we also need to update the 
win32_xstat functions in posixmodule.c, since they all try and use the same 
struct.

I don't know how familiar you are with the posixmodule functions, so I can 
study up on them if needed. It's probably due for some simplifications anyway, 
since we can now assume that Vista's APIs are always available. I think a lot 
of the functionality there is now in fileutils.c too, so we don't need so much 
duplicated code.

--

___
Python tracker 

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

[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

[mattip]

mattip added the comment:

it seems the problem is that the bundled libffi version in 
Modules/_ctypes/libffi needs updating. The fix for aarch64 is a simple 
one-liner (tested on 2.7 in a aarch64 vm), for both HEAD and 2.7 (attached), 
but perhaps a better fix would be to update the bundled libffi?

--
Added file: http://bugs.python.org/file37716/libffi.patch

___
Python tracker 

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

[issue11835] python (x64) ctypes incorrectly pass structures parameter

[mattip]

mattip added the comment:

This is a duplicate of issue 20160, and has been fixed. Can someone mark it as 
a duplicate and close it?

--
nosy: +mattip

___
Python tracker 

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

[issue20898] Missing 507 response description

[Demian Brecht]

Demian Brecht added the comment:

Ping. Would be nice to get this change in before 3.5.0a1.

--

___
Python tracker 

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

[issue1602] windows console doesn't print or input Unicode

[Drekin]

Drekin added the comment:

File redirection has nothing to do with win-unicode-console and this issue. 
When stdout is redirected, it is not a tty so win-unicode-console doesn't 
replace the stream object, which is the right thing to do. You got 
UnicodeEncodeError because Python creates sys.stdout with encoding based on 
your locale. In my case it is cp1250 which cannot encode whole Unicode. You can 
control the encoding used by setting PYTHONIOENCODING environment variable. For 
example, if you have a script producer.py, which prints some Unicode 
characters, and consumer.py, which just does print(input()), then "py 
producer.py | py consumer.py" shows that redirection works (when 
PYTHONIOENCODING is set e.g. to utf-8).

--

___
Python tracker 

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

[issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard

[Ned Deily]

Ned Deily added the comment:

Yes, this has the same root cause as the failure in Issue20605 since SMTPServer 
in smtpd.py uses getaddrinfo.  I'm now able to reliably reproduce the failure.  
The system getaddrinfo failure is seen when the OS X 10.6 system's network 
configuration is *not* using the local mdns for its primary domain service 
(which can be checked with "scutil --dns"); it fails when using an external dns 
as its primary dns service.  At least that's one failure scenario.  In any 
case, this seems to have been fixed in later versions of OS X, the problem 
appears to be unique to getaddrinfo (gethostbyname works OK), and it's only 
this one test.  I'm tempted to just close this as "won't fix"; on the other 
hand, it's easy enough to change this test to use '127.0.0.0' instead of 
'localhost'; there are precedents for doing that for other reasons (Issue18792, 
for example).  Here's a patch that does so and thus avoids the potential 
problem on 10.6.  I'll apply it if there are no objections.

--
keywords: +patch
nosy: +vinay.sajip
stage:  -> patch review
versions: +Python 3.4
Added file: http://bugs.python.org/file37717/issue23211.patch

___
Python tracker 

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

[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell

[Roundup Robot]

Roundup Robot added the comment:

New changeset 992ce0dcfb29 by Victor Stinner in branch '3.4':
Issue #22685: Fix test_pause_reading() of asyncio/test_subprocess
https://hg.python.org/cpython/rev/992ce0dcfb29

--

___
Python tracker 

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

[issue20132] Many incremental codecs don’t handle fragmented data

[Martin Panter]

Martin Panter added the comment:

I opened Issue 23231 about fixing iterencode() and iterdecode() in the general 
case. I added a patch to Issue 13881 to fix StreamWriter for zlib and bz2, and 
to fix StreamWriter.writelines() in general.

I am adding a patch here to clarify the StreamReader API and fix the 
StreamReader for the zlib-codec.

Plan of other things to do:

bz2 StreamReader: Should be implemented similar to the zlib patch above, after 
Issue 15955 is resolved and we have a max_length parameter to use. Or could be 
based on Bz2File now.

hex decoder: Shouldn’t be too hard to hack a stateful IncrementalDecoder that 
saves the leftover digit if given an odd number of digits. Create a generic 
codecs._IncrementalStreamReader class that uses an IncrementalDecoder and 
buffers unread decoded data, similar to my _IncrementalStreamWriter for Issue 
13881.

base64 encoder: IncrementalEncoder could encode in base64.MAXBINSIZE chunks

base64 decoder: IncrementalDecoder could strip non-alphabet characters using 
regular expressions, decode in multiples of four characters

quopri encoder: would require new implementation or major refactoring of quopri 
module

quopri decoder: check for incomplete trailing escape codes (=, =, =\r) and newlines (\r)

uu encoder: write header and trailer via uu module; encode using b2a_uu()

uu decoder: factor out header parsing from uu module; buffer and decode line by 
line based on encoded length

unicode-escape, raw-unicode-escape: Stateful decoding would probably require a 
new -Stateful() function at the C level, though it might be easy to build from 
the existing implementation. I suggest documenting that stateful decoding is 
not supported for the time being.

utf-7: As Walter said, proper stateful codec is not supported by the C API, 
despite PyUnicode_DecodeUTF7Stateful(); doing so would probably require 
significant changes. I suggest documenting a warning for stateful mode 
(including with TextIOWrapper) about suboptimal encoding and unlimited data 
buffering for the time being.

punycode, unicode_internal: According to test_codecs.py, these also don’t work 
in stateful mode. Not sure on the details though.

--
keywords: +patch
Added file: http://bugs.python.org/file37718/zlib-reader.patch

___
Python tracker 

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

[issue20132] Many incremental codecs don’t handle fragmented data

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 15.01.2015 23:46, Martin Panter wrote:
> 
> I opened Issue 23231 about fixing iterencode() and iterdecode() in the 
> general case. I added a patch to Issue 13881 to fix StreamWriter for zlib and 
> bz2, and to fix StreamWriter.writelines() in general.
> 
> I am adding a patch here to clarify the StreamReader API and fix the 
> StreamReader for the zlib-codec.

Martin, I must be missing some context: what's your master plan with
all these codec patches and open tickets ?

They are very hard to follow and you're making design changes which
need more review and discussion than can easily be done on a few tickets.

Regarding the patch:

The doc patch seems to just change ordering of sentences and paragraphs.
Without additional explanation, it's difficult to determine whether
you are changing semantics or not.

The "strict" error change is not correct. Most codecs raise a UnicodeError
(which is a ValueError subclass) and code expects codecs that work
on Unicode to return a UnicodeError, not a ValueError. Only codecs that
do not work on Unicode are allowed to raise ValueErrors.

--

___
Python tracker 

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

[issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder

[Martin Panter]

Martin Panter added the comment:

Sorry, I changed the name of the attribute and forgot to update the doc string. 
Its new name was _Encoder.

Your description was fairly accurate. I am adding patch v3, with an expanded 
the doc string. Hopefully that explains it a bit better. Since it is just 
implementing the documented StreamWriter API, I only added brief descriptions 
of the methods pointing back to the StreamWriter methods.

--
Added file: http://bugs.python.org/file37719/zlib-bz2-writer.v3.patch

___
Python tracker 

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

[issue20132] Many incremental codecs don’t handle fragmented data

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

This addition is wrong as well:

The *stream* argument must be a file-like object open for reading
-   text or binary data, as appropriate for the specific codec.
+   text or binary data, as appropriate for the specific codec. This stream is
+   assumed to have ended as soon as a read from it returns no data.

Where did you get this idea from ?

--

___
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:

> Some ResourceWarning are still emited on SSL server tests.

Attached server_close.patch is a work-in-process patch to fix this issue on 
Linux.

If I understood correctly, there are two issues:

- SelectorEventLoop._accept_connection() doesn't care of the creation of the 
transport failed
- SSLProtocol.eof_received() does not notify the waiter that EOF was received

So an application cannot control SSL incoming connections which fail during the 
handshake? Control: log errors, do something with the socket, etc.

See also the STARTTLS feature request:
https://code.google.com/p/tulip/issues/detail?id=79

--
Added file: http://bugs.python.org/file37720/server_close.patch

___
Python tracker 

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

[issue20132] Many incremental codecs don’t handle fragmented data

[Martin Panter]

Martin Panter added the comment:

My “master plan” is basically to make most of the bytes-to-bytes codecs work as 
documented in the incremental (stateful) modes. I’m less interested in fixing 
the text codecs, and the quopri and uu codecs might be too hard, so I was going 
to propose some documentation warnings for those.

If you have a suggestion on how to go about this better, let me know.

With my doc change to StreamReader, I wanted to document the different modes 
that I saw in the base codecs.StreamReader.read() implementation:

* read() or read(-1) reads everything
* read(size) returns an arbitrary amount of data
* read(size, chars) returns exactly *chars* length of data (unless EOF or 
similar)

Previously the case of read(-1, chars) was ambiguous. Also I did not find the 
description “an approximate maximum number of decoded bytes” very helpful, 
considering more than this maximum was read if necessary to get enough *chars*.

Regarding the end-of-stream behaviour, I made an assumption but I now realize 
it was wrong. Experimenting with the UTF-8 codec shows that its 
StreamReader.read() keeps returning "" when the underlying stream returns no 
data. But if it was in the middle of a multi-byte sequence, no “end of data” 
error is raised, and the multi-byte sequence can be completed if the underlying 
stream later returns more data. I think the lack of end-of-data checking should 
be documented.

The different cases of ValueError and UnicodeError that you describe make 
sense. I think the various references to ValueError and UnicodeError should be 
updated (or replaced with pointers) to match.

--

___
Python tracker 

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

[issue8450] httplib: false BadStatusLine() raised

[Demian Brecht]

Demian Brecht added the comment:

This should likely be closed as a duplicate of #3566, which has additional 
detail.

--

___
Python tracker 

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

[issue20898] Missing 507 response description

[Berker Peksag]

Berker Peksag added the comment:

This is mostly a documentation update. Documentation updates can be committed 
anytime. Also, feature freeze for 3.5 will be started by Beta 1, not Alpha 1 
(see PEP 478).

I'll commit the patch this weekend. Thanks!

--

___
Python tracker 

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

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

[Demian Brecht]

Demian Brecht added the comment:

Trying to reproduce this on my own in 3.5, 2.7 and 2.5 yields a 
ConnectionResetError (ECONNRESET), which seems to be correct. That said, this 
could be due to varying TCP implementations on the server so might still be 
valid. It could also be due to an older kernel which has been fixed since this 
was originally reported. Is this still reproducible? If so, can an example be 
provided?

If the error as written is reproducible, I think that the error message should 
be fixed, but I'm not so sure that any more than that should be done.


As far as the RFC goes, I think the MUST clause pointed out can be left to the 
interpretation of the reader. You /could/ consider http.client as the client, 
but you could also consider the application that a user is interacting with as 
the client.

Offhand, I think that the library as it is does the right thing in allowing the 
application code to handle the exceptions as it sees fit. Because http.client 
in its current state doesn't allow for request pipelining, retries from calling 
code should be trivial, if that is what the caller intends to do.

--

___
Python tracker 

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

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

[Martin Panter]

Martin Panter added the comment:

I believe the BadStatusLine can still happen, depending on the circumstances. 
When I get a chance I will see if I can make a demonstration. In the meantime 
these comments from my persistent connection handler 
 
might be useful:

# If the server closed the connection,
# by calling close() or shutdown(SHUT_WR),
# before receiving a short request (<= 1 MB),
# the "http.client" module raises a BadStatusLine exception.
#
# To produce EPIPE:
# 1. server: close() or shutdown(SHUT_RDWR)
# 2. client: send(large request >> 1 MB)
#
# ENOTCONN probably not possible with current Python,
# but could be generated on Linux by:
# 1. server: close() or shutdown(SHUT_RDWR)
# 2. client: send(finite data)
# 3. client: shutdown()
# ENOTCONN not covered by ConnectionError even in Python 3.3.
#
# To produce ECONNRESET:
# 1. client: send(finite data)
# 2. server: close() without reading all data
# 3. client: send()

I think these behaviours were from experimenting on Linux with Python 3 
sockets, and reading the man pages.

I think there should be a new documented exception, a subclass of BadStatusLine 
for backwards compatibility. Then user code could catch the new exception, and 
true bad status lines that do not conform to the specification or whatever 
won’t be caught. I agree that the library shouldn’t be doing any special 
retrying of its own, but should make it easy for the caller to do so.

--

___
Python tracker 

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

[issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code

[Gregory P. Smith]

Gregory P. Smith added the comment:

thanks for the cleanup refactoring!

--

___
Python tracker 

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

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

[Gregory Szorc]

New submission from Gregory Szorc:

distutils as of Python 2.7.9 is unable to locate vcvarsall.bat if Visual C++ 
Compiler for Python is the only Visual Studio "distribution" installed.

STR:

1) Do a fresh install of Windows + all updates
2) Install Microsoft Visual C++ Compiler for Python from 
http://www.microsoft.com/en-us/download/details.aspx?id=44266
3) Enter a Visual C++ 2008 command prompt via start menu 
4) Attempt to run any |python.exe setup.py| that contains C extensions
5) "Unable to find vcvarsall.bat"

Examining the behavior of MSVC for Python's bat scripts and filesystem layout, 
it is different enough from "full" "distributions" that it confused distutils.

First, MSVC for Python doesn't appear to set any meaningful registry entries. 
So, the registry checking in msvc9compiler fails to find anything.

Second, the command environment for MSVC for Python doesn't export 
VS90COMNTOOLS, so msvc9compiler has no clue where to go looking for files.

Third, even if VS90COMNTOOLS is set, msvc9compiler isn't able to find 
vcvarsall.bat because it is installed in %installdir%/vcvarsall.bat and not 
%installdir%/VC/vcvarsall.bat, unlike every other Visual Studio AFAICT.

Another concern is that distutils.msvc9compiler.find_vcvarsall() first attempts 
to read from the registry, not the environment. If you are in a MSVC for Python 
command shell and you also have Visual Studio 2008 installed, distutils will 
use vcvarsall.bat from the full Visual Studio installation instead of the 
Python one. I think this is wrong.

The MSVC for Python command prompt does have an environment variable that can 
be used: VCINSTALLDIR. It is set to %installdir%\VC\, which is equivalent to 
~/AppData/Local/Programs/Common/Microsoft/Visual C++ for Python/9.0/VC/ if you 
launch the installer with default options. distutils could be patched to find 
vcvarsall.bat in %VCINSTALLDIR%\..\vcvarsall.bat

Fortunately, a workaround is available:

1) Enter MSVC for Python command prompt
2) SET DISTUTILS_USE_SDK=1
3) SET MSSdk=1
4) python.exe setup.py ...

--
components: Distutils
messages: 234110
nosy: Gregory.Szorc, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils fails to locate vcvarsall with Visual C++ Compiler for Python
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

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

[Gregory Szorc]

Gregory Szorc added the comment:

The first sentence in my original report is ambiguous. I tested with distutils 
on Python 2.7.9. But considering the code in question hasn't changed since 
2011, I think it's safe to say this isn't a regression in CPython.

--

___
Python tracker 

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

[issue11835] python (x64) ctypes incorrectly pass structures parameter

[Berker Peksag]

Changes by Berker Peksag :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> broken ctypes calling convention on MSVC / 64-bit Windows 
(large structs)

___
Python tracker 

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

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

[Zachary Ware]

Changes by Zachary Ware :


--
nosy: +steve.dower

___
Python tracker 

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

[issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows

[James Teh]

Changes by James Teh :


--
nosy: +jteh

___
Python tracker 

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

[issue23247] Multibyte codec StreamWriter.reset() crashes

[Martin Panter]

New submission from Martin Panter:

$ python3 -c 'import codecs; from io import BytesIO; 
codecs.getwriter("big5")(BytesIO()).reset()'
Segmentation fault (core dumped)
[Exit 139]

Happens for all the multibyte codecs:
broken_stream_codecs = {
"big5", "big5hkscs", "cp932", "cp949", "cp950",
"euc_jp", "euc_jis_2004", "euc_jisx0213", "euc_kr",
"gb2312", "gbk", "gb18030", "hz",
"iso2022_jp", "iso2022_jp_1", "iso2022_jp_2", "iso2022_jp_2004",
"iso2022_jp_3", "iso2022_jp_ext", "iso2022_kr",
"johab", "shift_jis", "shift_jis_2004", "shift_jisx0213",
}

These codecs also share the property that their StreamReader.read() methods do 
not accept the second “chars” parameter:

>>> codecs.getreader("big5")(BytesIO()).read(1, 1)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: read expected at most 1 arguments, got 2

--
components: Unicode
messages: 234112
nosy: ezio.melotti, haypo, vadmium
priority: normal
severity: normal
status: open
title: Multibyte codec StreamWriter.reset() crashes
type: crash
versions: Python 3.4

___
Python tracker 

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

[issue22932] email.utils.formatdate uses unreliable time.timezone constant

[Dmitry Shachnev]

Dmitry Shachnev added the comment:

Now the patch works with tzdata >= 2011k, which is quite old.

@David: yes, with the unpatched version only one of the tests should fail.

--
Added file: http://bugs.python.org/file37721/issue22932_combined_v2.diff

___
Python tracker 

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