[issue17908] Unittest runner needs an option to call gc.collect() after each test

[Antoine Pitrou]

Antoine Pitrou added the comment:

I still think that it's something that people can trivially implement and that 
has no place in the standard unittest package.

--
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue24068] statistics module - incorrect results with boolean input

[Wolfgang Maier]

Changes by Wolfgang Maier :


Removed file: http://bugs.python.org/file39220/statistics._sum.patch

___
Python tracker 

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

[issue24068] statistics module - incorrect results with boolean input

[Wolfgang Maier]

Changes by Wolfgang Maier :


Added file: http://bugs.python.org/file39221/statistics._sum.patch

___
Python tracker 

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

[issue24068] statistics module - incorrect results with boolean input

[Wolfgang Maier]

New submission from Wolfgang Maier:

the mean function in the statistics module gives nonsensical results with 
boolean values in the input, e.g.:

>>> mean([True, True, False, False])
0.25

>>> mean([True, 1027])
0.5

This is an issue with the module's internal _sum function that mean relies on. 
Other functions relying on _sum are affected more subtly, e.g.:

>>> variance([1, 1027, 0])
351234.33

>>> variance([True, 1027, 0])
351234.34

The problem with _sum is that it will try to coerce its result to any non-int 
type found in the input (so bool in the examples), but bool(1028) is just True 
so information gets lost.

I've attached a patch preventing the type cast when it would be to bool.
I don't have time to write a separate test though so if somebody wants to take 
over .. :)

--
components: Library (Lib)
files: statistics._sum.patch
keywords: patch
messages: 242169
nosy: steven.daprano, wolma
priority: normal
severity: normal
status: open
title: statistics module - incorrect results with boolean input
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39220/statistics._sum.patch

___
Python tracker 

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

[issue23882] unittest discovery doesn't detect namespace packages when given no parameters

[Alex Shkop]

Changes by Alex Shkop :


Added file: http://bugs.python.org/file39223/issue23882_find_one_level.patch

___
Python tracker 

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

[issue23882] unittest discovery doesn't detect namespace packages when given no parameters

[Alex Shkop]

Alex Shkop added the comment:

I'm still not sure which solution is the best. So I attach two simple patches.

First one enables full recursive scan of start_dir for namespace packages.

Second one loads tests only from top level namespace packages.

--
keywords: +patch
Added file: http://bugs.python.org/file39222/issue23882_find_all.patch

___
Python tracker 

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

[issue18383] test_warnings modifies warnings.filters when running with "-W default"

[Alex Shkop]

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Gareth Rees]

Gareth Rees added the comment:

Not just Iterator, but Container, Hashable, Iterable, and Sized too!

>>> import weakref
>>> class C: pass
>>> o = C()
>>> w = weakref.proxy(o)
>>> from collections.abc import *
>>> isinstance(w, Container)
True
>>> isinstance(w, Hashable)
True
>>> isinstance(w, Iterable)
True
>>> isinstance(w, Sized)
True

--
nosy: +Gareth.Rees

___
Python tracker 

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

[issue17620] Python interactive console doesn't use sys.stdin for input

[Drekin]

Drekin added the comment:

Note that under status quo PyOS_Readline is called from two places: the 
tokenizer during an interactive session and the builtin function input. The 
tokenizer passes promptstring encoded in sys.stdin.encoding while input() 
passes promtstring encoded in sys.stdout.encoding, so it is not possible to 
implement a readline hook correctly in the case the encodings are different. 
This might be considered a bug.

--

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Antoine Pitrou]

Antoine Pitrou added the comment:

Those methods are defined precisely so that they can be delegated. Since 
virtually anything can be proxied, the weakref.proxy *class* cannot tell 
upfront whether the proxied object will be an Iterator or not. I don't really 
see how to get around that.

--
nosy: +benjamin.peterson, gvanrossum
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

[issue24067] Weakproxy is an instance of collections.Iterator

[Gareth Rees]

Gareth Rees added the comment:

Hashable is particularly misleading, because "weakref.Proxy objects are not 
hashable regardless of the referent".

--

___
Python tracker 

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

[issue24056] Expose closure & generator status in function repr()

[Berker Peksag]

Berker Peksag added the comment:

Here is a patch with a test.

--
components: +Interpreter Core
keywords: +patch
nosy: +berker.peksag
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39224/issue24056.diff

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Antoine Pitrou]

Antoine Pitrou added the comment:

> weakref.Proxy objects are not hashable regardless of the referent

Interesting. @fdrake, do you remember why that is?

--

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Gareth Rees]

Gareth Rees added the comment:

The documentation says that weakref.Proxy objects are not hashable because 
"this avoids a number of problems related to their fundamentally mutable 
nature, and prevent their use as dictionary keys".

Hashable objects must be immutable, otherwise the hash might change, 
invalidating the invariants that make dictionaries work, but Proxy objects are 
fundamentally mutable: when there are no more strong references to the proxied 
object, the object gets destroyed and the Proxy object now refers to None. If 
the Proxy object were hashable then its hash would change at this point.

--

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Antoine Pitrou]

Antoine Pitrou added the comment:

Still, weakref.ref objects are hashable, so I don't understand why 
weakref.proxy would be different.

Hashability of weakref.ref has been added in 29aa832b8787, to support weak 
dictionaries. See issue403985. It simply wasn't discussed whether to also add 
hashability to proxy objects.

--

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, PEP 205 explains it a bit more:

"the resulting proxy cannot be used as a dictionary key since it cannot be 
compared once the referent has expired, and comparability is necessary for 
dictionary keys. Operations on proxy objects after the referent dies cause 
weakref.ReferenceError to be raised in most cases."

Perhaps this can be relaxed, and comparison simply made to return false. The 
following behaviour is a bit troubling :-)

>>> p

>>> p == p
Traceback (most recent call last):
  File "", line 1, in 
ReferenceError: weakly-referenced object no longer exists

--

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. added the comment:

I don't see any reason for proxy objects to be less hashable than ref objects.

As for the p == p case, where the referent has expired, returning True if p is 
p seems acceptable (along with False inequalities, and True for other 
comparisons allowing equality), but anything beyond that seems unwise.  Not 
sure whether that would really be enough to help real use cases.

--

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Gareth Rees]

Gareth Rees added the comment:

> I don't see any reason for proxy objects to be less hashable than ref objects.

The difference is that unlike a ref object, a proxy object is supposed to 
forward its method calls to the proxied object. So consider what happens if you 
forward the __hash__ method to the proxied object: the hash will change when 
the object dies.

A proxy object could, of course, not forward the __hash__ method, instead 
computing its own hash. But I think this would do more harm than good: surely 
most attempts to store weakref.Proxy objects in sets or dictionaries are going 
to be mistakes -- the user should have used a WeakKeyDictionary or a WeakSet 
instead.

--

___
Python tracker 

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

[Steve Dougherty]

Steve Dougherty added the comment:

I've added a change to the bytecode magic number as well. I don't see a magic 
tag anymore, either in the code or for recent versions.

There are autogenerated changes to Python/importlibs.h. Is my understanding 
correct that these are not to be committed?

--
Added file: http://bugs.python.org/file39225/issue11205-v2.patch

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. added the comment:

Clearly I've been away from this code for a long time.

The hash support for ref objects is definitely a very special case, only 
intended to support WeakKeyDictionary.  We that class implemented in C, we'd 
probably want the hash support for refs not to be exposed.

You've convinced me hashability for proxies isn't desirable.  Let's stick with 
the status quo on this.

--

___
Python tracker 

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

[issue24056] Expose closure & generator status in function repr()

[Mark Dickinson]

Mark Dickinson added the comment:

I can see that the `generator` information would be useful.  What's the 
use-case for reporting that a function is a closure?  I'm having trouble 
thinking of a case where it's useful to know that a function is a closure 
without also knowing which locals refer to cells.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov
stage:  -> needs patch
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

[issue24067] Weakproxy is an instance of collections.Iterator

[Antoine Pitrou]

Antoine Pitrou added the comment:

> So consider what happens if you forward the __hash__ method to the
> proxied object: the hash will change when the object dies.

ref objects behave differently: they inherit their referent's hash value when 
alive, and remember it.  proxy objects could be made to behave the same way.

> The hash support for ref objects is definitely a very special case, 
> only intended to support WeakKeyDictionary

I've relied several times on the hashability of ref objects, in third-party 
code.
(OTOH, I never use weakref proxies)

--

___
Python tracker 

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

[issue23699] Add a macro to ease writing rich comparisons

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue24067] Weakproxy is an instance of collections.Iterator

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. added the comment:

> ref objects behave differently: they inherit their referent's hash
> value when alive, and remember it.  proxy objects could be made to
> behave the same way.

They could, yes, but that would break the proxy behavior, and the hash <--> 
equality behavior for mutable objects.

In particular, mutable objects can become equal; if the hashes were computed 
for the proxies before that happened, the hashes would be inappropriate later.  
That's pretty important.

--

___
Python tracker 

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

[issue19543] Add -3 warnings for codec convenience method changes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch that backports issue19619 and issue20404 with changing an 
exception to Py3k warning, and makes necessary changes in other modules and 
tests.

$ ./python -3
Python 2.7.10rc0 (2.7:4234b0dd2a54+, Apr 28 2015, 16:51:51) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 'abcd'.decode('hex')
__main__:1: DeprecationWarning: 'hex' is not a text encoding; use 
codecs.decode() to handle arbitrary codecs
'\xab\xcd'

--
Added file: 
http://bugs.python.org/file39226/issue19543_blacklist_transforms_py27.patch

___
Python tracker 

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

[issue24069] Option to delete obsolete bytecode files

[Sworddragon]

New submission from Sworddragon:

The library compileall has the option -f to force the rebuilding of the 
bytecode files so I thought maybe there could also be an option to delete all 
bytecode files which haven't a non-bytecode library anymore.

--
components: Library (Lib)
messages: 242189
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Option to delete obsolete bytecode files
type: enhancement
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

[issue17908] Unittest runner needs an option to call gc.collect() after each test

[Guido van Rossum]

Guido van Rossum added the comment:

It's trivial to add to a single test or even a single TestCase subclass, yes. 
The use case is more that you have a ton of tests and you suspect there's a 
problem due to GC. Being able to call gc.collect() after each test through the 
flip of a flag would be useful.

But I agree it's iffy whether this belongs in the unittest package; we could 
add it to the CPython run_tests.py script, or you could request this as a 
feature from py.test.

If someone wants to add this to run_tests.py I think this issue would be the 
place to review the patch.

--

___
Python tracker 

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

[issue17908] Unittest runner needs an option to call gc.collect() after each test

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See also issue23839 where proposed not only call gc.collect(), but clear all 
caches in test.regrtest.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue24070] Exceptions and arguments disappear when using argparse inside with statement

[Roy Hyunjin Han]

New submission from Roy Hyunjin Han:

Exceptions and arguments disappear when using argparse inside a "with" 
statement.  The behavior was confusing and frustrating because I could not 
pinpoint why certain arguments were missing or unrecognized.

Unhandled exceptions inside the with statement typically trigger a traceback, 
unless __exit__ returns True, in which the exception is "swallowed" 
(https://www.python.org/dev/peps/pep-0343/).

However, the NameError exception and tile_indices argument disappear because of 
a premature sys.exit 
(https://hg.python.org/cpython/file/default/Lib/argparse.py#l2385).

```
"""
$ python exception-in-with.py
EXPECTED
Traceback (most recent call last):
  File "exception-in-with.py", line 51, in 
abc  # !!!
NameError: name 'abc' is not defined
ACTUAL
usage: exception-in-with.py [-h] --image_path PATH
exception-in-with.py: error: argument --image_path is required

$ python exception-in-with.py --image_path x
EXPECTED == ACTUAL
Traceback (most recent call last):
  File "exception-in-with.py", line 51, in 
abc  # !!!
NameError: name 'abc' is not defined

$ python exception-in-with.py --image_path x --tile_indices 1
EXPECTED
Traceback (most recent call last):
  File "exception-in-with.py", line 51, in 
abc  # !!!
NameError: name 'abc' is not defined
ACTUAL
usage: exception-in-with.py [-h] --image_path PATH
exception-in-with.py: error: unrecognized arguments: --tile_indices 1
"""
from argparse import ArgumentParser


class Starter(object):

def __init__(self):
self.argument_parser = ArgumentParser()

def __enter__(self):
return self

def __exit__(self, exception_type, exception_value, exception_traceback):
self.argument_parser.parse_args()

def add_argument(self, *args, **kw):
self.argument_parser.add_argument(*args, **kw)


with Starter() as starter:
starter.add_argument('--image_path', metavar='PATH', required=True)
abc  # !!!
starter.add_argument('--tile_indices', metavar='INTEGER')
```

--
components: Library (Lib)
files: argparse-with-exception.py
messages: 242192
nosy: invisibleroads
priority: normal
severity: normal
status: open
title: Exceptions and arguments disappear when using argparse inside with 
statement
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file39227/argparse-with-exception.py

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Elizabeth Myers]

Elizabeth Myers added the comment:

It seems pretty simple to just make a function that returns a new transport, 
something like "transport = yield from loop.ssl_wrap_transport(transport)". I'm 
not sure how to handle plaintext data left on the wire, though, unless that's 
not really a consideration (given most (all?) real-world protocols can (and 
usually do) wait for the SSL handshake before sending more data when STARTTLS 
has been requested).

For the higher-level API, I'm thinking "reader, writer = 
asyncio.ssl_wrap(reader, writer)" maybe? You can't have half-closed SSL 
connections, so you would have to pass them both in. 

As for replacing the protocol but keeping the transport, what would be the 
semantics of that? I can't really think of how to do that one. I do know SMTP 
clears all state, but some protocols might not (IRC is a key example - this 
isn't usually a problem since you are supposed to negotiate it early on before 
you log onto the server), so this shouldn't be mandatory.

--

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Elizabeth Myers]

Elizabeth Myers added the comment:

Reading the source now (just woke up, sorry!), the new protocol thing makes 
sense. I'm not sure what to do with the waiter argument or how to handle that.

What I'm really trying to think of here is how to handle copying of state. I 
guess users will just have to do it by hand if they want to do that? I don't 
know if keeping the same protocol is practical and just wrapping the transport 
is a good idea :(.

--

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Antoine Pitrou]

Antoine Pitrou added the comment:

> As for replacing the protocol but keeping the transport, what would
> be the semantics of that?

The protocol is not really replaced, it's wrapped.

Before:

  SocketTransport <- UserProtocol

After:

  SocketTransport <- (asyncio.sslproto.SSLProtocol
 <- asyncio.sslproto._SSLProtocolTransport) <- UserProtocol

That way, the same SocketTransport (but it could be something else, e.g. a pipe 
transport) is always bound to the event loop; we simply insert a processing 
layer in the chain between the original transport and the final protocol.  
There are two distinct objects so that the SocketTransport sees a protocol and 
the UserProtocol sees a transport; but those two objects work hand in hand.

--

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Guido van Rossum]

Guido van Rossum added the comment:

That sounds like a good plan for the top-level APIs.

But I think we may need to think about low-level APIs that handle Transports 
and Protocols as well.

The design I had been thinking of does not do any socket-level manipulation (in 
fact it doesn't care if the Transport has a socket or some other way to connect 
to a networking peer) but it does require some cooperation of the Transport and 
Protocol.

Let me draw some ASCII art.

In the initial state (no ssl) we have an App embodied in a Protocol, talking to 
a Transport which abstracts away a network connection:

   data_received()
[ <--- ]
  App <==> Protocol [  ] Transport <==> Network
[ ---> ]
   write()

(I.e., when the app wants to write to the network, it calls transport.write(); 
when the network has data for the app, it calls protocol.data_received().)

In the final state (ssl established) I was thinking the picture would look like 
this (leaving the method names out):


   [ < ][ < ]
  App <=> Protocol [   ] HelperTransport <=> HelperProtocol [   ] 
Transport <=> Network
   [ > ][ > ]

Here the Protocol at the far left and the Transport at the far right are the 
same objects as in the first diagram; however we've inserted a pair of helpers 
that handle SSL. Once the SSL connection is flowing, a write() by the app gives 
the data to the helper, which gives it to the SSL library. When the SSL library 
wants to send some (encrypted etc.) data to the network it calls write() on the 
rightmost Transport (the original one, which still owns the network 
connection). Conversely, when data arrives over the network, it is still given 
to the rightmost Transport via its data_received() method. This Transport then 
gives it to the SSL library, which eventually decrypts it (etc.) and gives it 
to the helper, which then calls data_received() with the decrypted plaintext on 
the leftmost Protocol (i.e. the App).

The clever trick here is that the Protocol on the left still talks to a 
Transport, it's just a different Transport (owned by the helpr); similarly, the 
Transport on the right still talks to a Protocol, it's just a different one 
owned by the helper.

People have proposed general stacks of Protocol/Transport pairs, but so far I 
haven't seen much of a use case for that. This might be that use case. In order 
to switch the arrangements, the helper code (which is ultimately invoked by 
your loop.ssl_wrap_transport() call) must first create the HelperTransport and 
HelperProtocol halves of the SSL helper layer, and then call 
set_transport()/set_protocol() on the existing App Protocol and Network 
Transport to change their respective associated transport and protocol.

Note that the relationship between HelperTransport and HelperProtocol is not 
the same as that between associated Transport/Protocol pairs; the interface 
they use to talk to each other is completely internal to the implementation of 
the helper (and probably determined mostly by the needs of the underlying SSL 
BIO interface).

Hope this helps (and hope others on the issue agree).

--Guido

--

___
Python tracker 

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

[issue24070] Exceptions and arguments disappear when using argparse inside with statement

[Benjamin Peterson]

Benjamin Peterson added the comment:

I'm not sure why this is so surprising. parse_args in __exit__ raises a 
SystmExit, which the Python interpreter takes to mean the program is 
responsibly exiting. I don't think any other behavior would be reasonable. e.g. 
sys.exit() in an except clause shouldn't cause the exception to be printed.

--
nosy: +benjamin.peterson
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Reading the source now (just woke up, sorry!), the new protocol thing makes 
> sense

Good :-)

> I'm not sure what to do with the waiter argument or how to handle that.

I'm not sure. Apparently it's used for create_connection(), so perhaps it's not 
necessary here? Perhaps Victor or Guido can give some insight...

> What I'm really trying to think of here is how to handle copying of state

Well, there shouldn't be any copying necessary. The user just continues using 
the same protocol instance; it just calls a different transport.

--

___
Python tracker 

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

[issue23749] asyncio missing wrap_socket

[Guido van Rossum]

Guido van Rossum added the comment:

Looks like Antoine drew the same diagram but quicker. :-)

Regarding the waiter arg, you can leave that None if you don't need it. It is 
intended to give the caller a way to block (using event loop machinery) until 
the connection is ready. But if your caller doesn't need it that's fine.

--

___
Python tracker 

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

[issue23058] argparse silently ignores arguments

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

[Eric Snow]

Eric Snow added the comment:

Changes to importlib.h should always be committed.  It is the frozen 
importlib._bootstrap module, which is the implementation of the import system 
used by the interpreter.  So failure to commit changes to importlib.h means 
your changes to importlib._bootstrap will not have any effect.

--
nosy: +eric.snow

___
Python tracker 

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

[issue23058] argparse silently ignores arguments

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

> Wouldn't it be safer all around if the subparsers took different arguments, 
> or at least different namespace 'dest', than the main parser?

IMHO, yes.  I agree that the semantics of what the original code is trying to 
do is quite ambiguous.  Since the documentation says that parents= causes all 
the given parsers and adds their options to the parser being constructed, I'd 
take that to mean that the -v before the command, and the command's -v would 
point to the same dest.  The admonition for add_help=False seems to reinforce 
that.

The fact that this used to work should be considered an accident.  I wouldn't 
call it a regression because the documentation does not make it clear that this 
should work.  I think this is not a bug.

Feel free to reopen this if you disagree and and cite a convincing argument for 
sharing dests.  To be totally unambiguous, use different destinations.

FWIW, I've never used parents myself.  I've always done something like what 
honcho eventually landed.

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue17908] Unittest runner needs an option to call gc.collect() after each test

[Robert Collins]

Robert Collins added the comment:

I'm going to disagree with michael and antoine here.

The *internals* should be clean and pluggable for sure, but this is actually a 
pretty common thing to try, so there's no reason to force it to only be done by 
external plugins.

Right now the way to plug this in has been complicated by the addition of 
module / class suites, which already perform extra work around individual 
tests, but in a non-introspectable / extensible fashion.

So you could add this as a hook to the loader (decorate each test with some new 
thing) and a CLI option to use that hook for a gc collect call.

Alternatively, we could face down the class/module stuff and rearrange it to be 
extensible (e.g. something along the lines of testresources internals - generic 
groups pre-post stuff) or via some interaction with TestResult but I really 
dislike using TestResult to control the run - I have a better layout mostly 
sketched in mind but haven't had time to formalise it.

So I recommend the TestLoader hook point - its well within the current 
responsibilities for it to do this, and I don't see any long term maintenance 
issues.

--

___
Python tracker 

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

[issue23882] unittest discovery doesn't detect namespace packages when given no parameters

[Robert Collins]

Robert Collins added the comment:

Ah the user model? 

I think the following:

If I run 'python -m unittest' in a directory, then I expect to run all of the 
tests contained within that directory tree, and no others.

Does that definition help?

--

___
Python tracker 

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

[Steve Dougherty]

Steve Dougherty added the comment:

I've added the importlib.h changes and changed the name of the test to be more 
descriptive.

--
Added file: http://bugs.python.org/file39228/issue11205-v3.patch

___
Python tracker 

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

[issue24071] Python 2.7.8, 2.7.9 re.MULTILINE failure

[Stephen Evans]

New submission from Stephen Evans:

A simple multiline regex fails when just the re.MULTILINE argument is used, but 
works when equivalent alternative methods are used. This was tested on 
Python2.7.8 on FreeBSD and Win32 Python2.7.9

data = re.sub(r'#.*', '', text, re.MULTILINE) # fails

data = re.sub(r'(?m)#.*', '', text) # Ok
data = re.sub(r'#.*', '', text, re.MULTILINE|re.DEBUG) # Ok

All the expressions work correctly with Win64 Python3.4.3
The attached file has the code and with a sample of text that fails.

--
components: Regular Expressions
files: refail.py
messages: 242205
nosy: Stephen.Evans, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Python 2.7.8, 2.7.9  re.MULTILINE failure
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file39229/refail.py

___
Python tracker 

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

[issue24071] Python 2.7.8, 2.7.9 re.MULTILINE failure

[Matthew Barnett]

Matthew Barnett added the comment:

The 4th argument of re.sub is the maximum count (0 means unlimited).

>>> help(re.sub)
Help on function sub in module re:

sub(pattern, repl, string, count=0, flags=0)
Return the string obtained by replacing the leftmost
non-overlapping occurrences of the pattern in string by the
replacement repl.  repl can be either a string or a callable;
if a string, backslash escapes in it are processed.  If it is
a callable, it's passed the match object and must return
a replacement string to be used.

The value of re.MULTILINE is 8:

>>> re.MULTILINE
8

therefore it'll perform a maximum of 8 substitutions.

In summary: not a bug.

--

___
Python tracker 

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

[issue24071] Python 2.7.8, 2.7.9 re.MULTILINE failure

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> not a bug
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

[issue24072] xml.etree.ElementTree.Element does not catch text

[Jérôme Laurens]

New submission from Jérôme Laurens:

text is not catcher in case 3 below

INPUT

import xml.etree.ElementTree as ET
root1 = ET.fromstring('TEXT')
print(root1.text)
root2 = ET.fromstring('TEXT')
print(root2.text)
root3 = ET.fromstring('TEXT')
print(root3.text)

CURRENT OUTPUT

TEXT
TEXT
None <-- ERROR HERE

EXPECTED OUTPUT

TEXT
TEXT
TEXT

--
messages: 242207
nosy: jlaurens
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element does not catch text
type: behavior
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

[issue24072] xml.etree.ElementTree.Element does not catch text

[Raymond Hettinger]

Raymond Hettinger added the comment:

What would you have it do in the general case, should it concatenate all the 
text in:

>>> root4 = ET.fromstring('abcdefghi')
>>> root4.text
'abc'

If I'm interpreting the XML spec correctly ( 
http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags section [43]), the 
optional character data must be a the beginning of the element before any other 
elements, comments, or processing instructions:

content::=  CharData? ((element | Reference | CDSect | PI | 
Comment) CharData?)*

In other words, I'm not sure your XML is considered well-formed.

--
nosy: +rhettinger

___
Python tracker 

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

[issue24072] xml.etree.ElementTree.Element does not catch text

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +eli.bendersky, scoder

___
Python tracker 

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

[issue24072] xml.etree.ElementTree.Element does not catch text

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
Removed message: http://bugs.python.org/msg242208

___
Python tracker 

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

[issue24072] xml.etree.ElementTree.Element does not catch text

[Ned Deily]

Ned Deily added the comment:

While a bit confusing, I don't think this is a bug.  Note the definition of the 
"tail" attribute of an element:

"If the element is created from an XML file the attribute will contain any text 
found after the element’s end tag and before the next tag."

Unlike in root1 and root2 where 'TEXT' is before the end of element a and the 
start of element b (in root2), 'TEXT' in root3 follows the end tag of element b 
and so is associated with it as its tail attribute.

>>> root3

>>> root3[0]

>>> root3[0].tail
'TEXT'

https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.tail

--
nosy: +ned.deily
resolution:  -> not a bug
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

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

Hi Steve:

I have limited expertise in most of these areas, but I looked at 
starunpack40.diff and have these comments:

* tests look to have good coverage of the feature (can't speak to coverage of 
the parser/compiler code)
* parsermodule.c changes comprehension handling, but I thought we pulled this 
out?

There was some code taken common in various places, but there should be no code 
for unpacking comprehensions left in.   Do you have a question about a specific 
line?

* why was dictobject.c.h added? I don't understand clinic thoroughly, but it 
seems a lot of new code for what was changed in dictobject.c

They weren't added.  They were moved by someone else.  The only changes are 
exposing a method.

* can the BUILD_(TUPLE|LIST)_UNPACK code in ceval.c share most of the 
processing? Or is there an unwanted perf impact to that?

Good idea.  I'll make that change.

* whoever applies the patch should regenerate importlib.h themselves - just a 
reminder

Otherwise, I didn't see anything that particularly scared me. Since we 
apparently don't have anyone willing and with the expertise to thoroughly check 
the patch, I'd vote for checking it in asap so it has more releases to bake 
before 3.5 final.

Thanks!

--

___
Python tracker 

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

[issue24073] sys.stdin.mode can not give the right mode and os.fdopen does not check argument

[Xiang Zhang]

New submission from Xiang Zhang:

The problem is what the title tells and can be produced by the snippet below.

import sys
import os

sys.stdout.write("%s\n" % sys.stdin.mode)
sys.stdout.flush()
f = os.fdopen(sys.stdin.fileno(), "r")
f.write("")
f.flush()
f.read()
f.close()

When running this snippet with nohup, which changes the stdin's mode to 
O_WRONLY(which can also be shown below because the write operation will fail), 
this snippet will still give sys.stdin.mode as r, both in 2.7 and 3.4.

In 2.7, the os.fdopen will fail with Invalid Argument error because the mode r 
given to fdopen conflicts with stdin's real mode w. In 3.4, os.fdopen won't 
give any error.

Both in 2.7 and 3.4, if I change the mode given to os.fdopen to w:
f = os.fdopen(sys.stdin.fileno(), "w")
The write operation will succeed and the read operation will fail.

The output produced in nohup.out for 2.7 is:
r
Traceback (most recent call last):
  File "test.py", line 9, in 
f.read()
IOError: File not open for reading
For 3.4:
r
Traceback (most recent call last):
  File "test.py", line 9, in 
f.read()
io.UnsupportedOperation: not readable

I run the snippet with nohup on Gnome Terminal, bash, Ubuntu 15.04. The Python 
version is 2.7.9 and 3.4.3.

--
components: Library (Lib)
messages: 242211
nosy: angwer
priority: normal
severity: normal
status: open
title: sys.stdin.mode can not give the right mode and os.fdopen does not check 
argument
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue2292] Missing *-unpacking generalizations

[Neil Girdhar]

Neil Girdhar added the comment:

All tests pass.  All reviewer comments addressed.  Please let me know if 
anything else needs to be done from my end.

--
Added file: http://bugs.python.org/file39230/starunpack42.diff

___
Python tracker 

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

[issue23882] unittest discovery doesn't detect namespace packages when given no parameters

[Alex Shkop]

Alex Shkop added the comment:

Yes. That is how issue23882_find_all.patch works. I just removed hte condition

if (not namespace and
not os.path.isfile(os.path.join(full_path, '__init__.py'))):
return None, False
 
This makes namespace parameter redundant. Can I remove it?

--

___
Python tracker 

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

[issue24056] Expose closure & generator status in function repr()

[Nick Coghlan]

Nick Coghlan added the comment:

It's mostly pedagogical - similar to "normal functions" vs "generator 
functions", folks talk about functions and closures as different things, even 
though in Python a closure is just a normal function with one or more 
references to cells that were defined in outer scopes.

Having that show up in the repr() then becomes a way of clarifying that some, 
but not all, Python function objects are closures, even though closures aren't 
represented as a distinct type.

That difference also shows up in the bytecode that creates them (note the 
MAKE_FUNCTION vs MAKE_CLOSURE):


>>> def outer():
... x = 1
... def inner_function():
... pass
... def inner_closure():
... return x
... 
>>> import dis
>>> dis.dis(outer)
  2   0 LOAD_CONST   1 (1)
  3 STORE_DEREF  0 (x)

  3   6 LOAD_CONST   2 (", line 3>)
  9 LOAD_CONST   3 ('outer..inner_function')
 12 MAKE_FUNCTION0
 15 STORE_FAST   0 (inner_function)

  5  18 LOAD_CLOSURE 0 (x)
 21 BUILD_TUPLE  1
 24 LOAD_CONST   4 (", line 5>)
 27 LOAD_CONST   5 ('outer..inner_closure')
 30 MAKE_CLOSURE 0
 33 STORE_FAST   1 (inner_closure)
 36 LOAD_CONST   0 (None)
 39 RETURN_VALUE

One particular case where the distinction matters and is known to be genuinely 
confusing for new Python users is the late binding behaviour of closures:

lambda: i # closure
lambda i=i: i # not a closure

--

___
Python tracker 

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

[issue24074] string, center, ljust, rjust, width paramter should accept None

[Glen Fletcher]

New submission from Glen Fletcher:

I've only list python 2.7, as I'm not sure that version 3 doesn't accept None, 
if so this should be changed there too.

If these function are passed None, as the width they should return the string 
unchanged, just as they would for with a width set to 0.

Reasoning, A common use of these would be in list comprehensions and such, i.e. 
(string.center(encode(i), w) for i, w in items, widths), given the that items 
and widths may be of differing length in theory i should be a empty string and 
width 0 it not specified however the best way of dealing with this would be to 
use itertools.izip_longest(items, widths, default=None) and None would be 
encode as No Value, however this would require writing 
(string.center(encode(i), 0 if w is None else w) for i, w in 
itertools.izip_longest(items, widths, default=None)), which is far harder to 
follow, when its quite reasonable to expect these string alignment functions to 
return an unpadded string if passed None as the width.

--
components: Library (Lib)
messages: 242215
nosy: glenflet
priority: normal
severity: normal
status: open
title: string, center, ljust, rjust, width paramter should accept None
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