[issue32449] MappingView must inherit from Collection instead of Sized

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> After I generate an UML diagram from collections.abc, I found 
> very strange that MappingView inherit from Sized instead
> of Collection (new in python 3.6).

That isn't strange at all.  MappingView predates Collection, so of course it 
didn't inherit from collection.

> Yes, MappingView only define __len__ and not __iter__ 
> and __contains__, but all of its subclasses define them 
> (KeysView, ValuesView and ItemViews).

It is irrelevant what extra behaviors subclasses may or may not add.  The 
MappingView ABC is a public API and users are free to use it in other ways (as 
long as they stick with the publicly document API).  For example, the following 
is allowed (even it seems odd to you):

>>> from collections.abc import MappingView
>>> mv = MappingView(['a', 'b'])
>>> len(mv)# guaranteed
2
>>> repr(mv)   # guaranteed
"MappingView(['a', 'b'])"
>>> 'a' in mv  # not guaranteed 
Traceback (most recent call last):
  File "", line 1, in 
'a' in mv
TypeError: argument of type 'MappingView' is not iterable
>>> list(mv)   # not guaranteed
Traceback (most recent call last):
  File "", line 1, in 
list(mv)
TypeError: 'MappingView' object is not iterable

--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue32449] MappingView must inherit from Collection instead of Sized

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I concur with Raymond. MappingView is a public interface, not just a concrete 
implementation. Changing it will make third-party implementations of this 
interface not conforming it.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Xavier de Gaye]

Change by Xavier de Gaye :


--
keywords: +patch
pull_requests: +4938
stage:  -> patch review

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Xavier de Gaye]

Xavier de Gaye  added the comment:

The Setup files are configuration files, so their handling is different from 
the handling of Makefile.pre.in or the handling of the source files.

The only reference to Setup.local in the Python documentation is at 
https://docs.python.org/3/extending/extending.html#compilation-and-linkage, so 
most users that need to configure the build with a Setup file are probably 
using Modules/Setup instead of Modules/Setup.local and the solution that 
implements this enhancement cannot overwrite an existing Modules/Setup file. 
This solution must also be robust and transparent when switching to/from a 
branch where the solution is not implemented yet (a bpo branch created earlier).

PR 5062 adds the ``--enable-use-setup-dist`` configure option to use 
Modules/Setup.dist instead of Modules/Setup to build the Makefile. The build 
behavior is unchanged when this option is not used.

--
nosy: +xdegaye

___
Python tracker 

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

[issue30449] Improve __slots__ datamodel documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

mpb, I think the docs with respect to strings are fine as-is.  Sometimes if too 
much detail is put in, it makes the docs harder to read and understand (i.e. it 
gets in the way of our primary purpose).

--

___
Python tracker 

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

[issue32462] mimetypes.guess_type() might be return None or a tuple with (type/subtype, encoding)

[Cheryl Sabella]

New submission from Cheryl Sabella :

On a Windows 7 system, entering the following:

>>> mime, encoding = mimetypes.guess_type('Untitled.sql')
>>> mime
'text\\plain'

Meaning, the return value is 'text\\plain' instead of 'text/plain'.  Tracking 
this down, it's due to .sql being loaded from the Windows registry and the 
registry is using the wrong slash.

The mimetypes.guess_type() documentation states:
> The return value is a tuple (type, encoding) where type is None if> the 
> type can’t be guessed (missing or unknown suffix) or a string of
> the form 'type/subtype', usable for a MIME content-type header.

I don't know if guess_type() (or add_types) should check for a valid types, if 
.sql should be added to the valid types (it's on the IANA page), or if the 
documentation should be fixed so it doesn't look like a guarantee.  Or all 
three.  :-)

--
components: Library (Lib)
messages: 309275
nosy: csabella
priority: normal
severity: normal
status: open
title: mimetypes.guess_type() might be return None or a tuple with 
(type/subtype, encoding)
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue32462] mimetypes.guess_type() returns incorrectly formatted type

[Cheryl Sabella]

Change by Cheryl Sabella :


--
title: mimetypes.guess_type() might be return None or a tuple with 
(type/subtype, encoding) -> mimetypes.guess_type() returns incorrectly 
formatted type

___
Python tracker 

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

[issue32463] problems with shutil.py and os.get_terminal_size

[Nick McElwaine]

New submission from Nick McElwaine :

os.get_terminal_size() fails with () or (0) or (1)

shutil.sys fails calling it with (sys.__stdout__.fileno())
 because sys.__stdout__ is type None

--
components: Windows
messages: 309276
nosy: Dhruve, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: problems with shutil.py and os.get_terminal_size
type: behavior
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

[issue32462] mimetypes.guess_type() returns incorrectly formatted type

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +4939
stage:  -> patch review

___
Python tracker 

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

[issue32464] raise NotImplemented vs return NotImplemented

[Srinivas Reddy T]

New submission from Srinivas  Reddy T :

I ran these queries on cpython repo.

➜  cpython git:(master) ✗ grep -r . -e return  --include=\*.py  | grep 
NotImplemented | wc -l
196

➜  cpython git:(master) ✗ grep -r . -e raise   --include=\*.py  | grep 
NotImplemented | wc -l
295

I have always used raise NotImplemented or raise NotImplementedError. But when 
does it make sense to return NotImplemented?

--
messages: 309277
nosy: thatiparthy
priority: normal
severity: normal
status: open
title: raise NotImplemented vs return NotImplemented
type: resource usage
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue32464] raise NotImplemented vs return NotImplemented

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's the documentation, which I think explains all this clearly: briefly, 
`return NotImplemented` and `raise NotImplementedError` are the normal usages. 
`raise NotImplemented` doesn't make sense, and shouldn't be used: it'll end up 
raising a `TypeError`, sine `NotImplemented` is neither a subclass nor an 
instance of BaseException.

NotImplemented: 
https://docs.python.org/3.7/library/constants.html#NotImplemented

NotImplementedError:
https://docs.python.org/3.7/library/exceptions.html#NotImplementedError

Almost all of the grep results you're seeing do follow the expected patterns 
(either `return NotImplemented` or `raise NotImplementedError`, but a quick 
grep does show some questionable uses of `raise NotImplemented` in the standard 
library:

MacBook-Pro:cpython mdickinson$ grep -r . -e raise   --include=\*.py  | 
grep "\bNotImplemented\b"
./Lib/asyncio/transports.py:The implementation here raises 
NotImplemented for every method
./Lib/idlelib/debugger_r.py:raise NotImplemented("dict_keys not 
public or pickleable")
./Lib/ssl.py:raise NotImplemented("Can't dup() %s instances" %

The other way around also turns up an odd-looking `return NotImplementedError` 
(along with a false positive):

MacBook-Pro:cpython mdickinson$ grep -r . -e return   --include=\*.py  | 
grep "\bNotImplementedError\b"
./Lib/ctypes/test/test_simplesubclasses.py:return 
NotImplementedError
./Lib/test/test_asyncio/test_transports.py:
self.assertRaises(NotImplementedError, transport.get_returncode)

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue32463] problems with shutil.py and os.get_terminal_size

[Eryk Sun]

Eryk Sun  added the comment:

The 3.5 branch only gets security fixes at this point. Consider upgrading to 
3.6.

That said, this shouldn't be a problem with shutil.get_terminal_size() in 3.5. 
It handles AttributeError, ValueError, and OSError by returning the `fallback` 
size. And it's expected that `os.get_terminal_size(1)` will fail if there's no 
attached console.

--
components: +Library (Lib)
nosy: +eryksun

___
Python tracker 

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

[issue32449] MappingView must inherit from Collection instead of Sized

[Yahya Abou Imran]

Yahya Abou Imran  added the comment:

Hmm... Okay, I understand. 

So the only objection I have left, it's that ValuesView isn't passing the is 
instance of Collection test whereas it should, since he has the full behavior 
of one. It could be passed in its register to solve this.

But it's not realy the same issue.

Maybe I have to open a new one?

--

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I would hope to simplify the build process, not to complicate it.  In other 
words, I think the PR is a step in the wrong direction, *except* if using 
Setup.dist becomes the default and the other way is clearly marked deprecated.

--

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Note the use case we're trying to preserve here is probably extremely rare.  
I've never needed it myself, and I've never seen it done by anyone else.  We're 
talking about a very small demographics who's probably skilled enough to handle 
a little complexity in their workflow.

--

___
Python tracker 

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

[issue32465] [urllib] proxy_bypass_registry - extra error handling required for ProxyOverride, Windows under proxy environment

[chansol kim]

New submission from chansol kim :

[Problem]
- String value from registry Proxy override is read and incorrectly decides the 
current connection requires not to use proxy.

[Setup]
- Using urllib under proxy environment.
- Proxy bypass settings are in place. ProxyOverride string value in registry 
ends with ;

[Detail]
https://github.com/python/cpython/blob/2.7/Lib/urllib.py
proxy_bypass_registry has an issue
1. It gets registry value from 
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings ProxyEnable 
string value.
2. Splits the string with ;. And as the registry value ends with ; the split 
list contains a zero length string at the end.
3. Use the split string to re.match. And as there is zero length string at the 
end it, and the result of re.match('', 'anystring', re.I) is always not None.
4. Afterwards connection is attempted without using the proxy, hence connection 
cannot be made

>From line 1617

proxyOverride = proxyOverride.split(';')
# now check if we match one of the registry values.
for test in proxyOverride:
if test == '':
if '.' not in rawHost:
return 1
test = test.replace(".", r"\.") # mask dots
test = test.replace("*", r".*") # change glob sequence
test = test.replace("?", r".")  # change glob char
for val in host:
# print "%s <--> %s" %( test, val )
if re.match(test, val, re.I):
return 1

--
components: Library (Lib)
messages: 309284
nosy: chansol kim
priority: normal
severity: normal
status: open
title: [urllib] proxy_bypass_registry - extra error handling required for 
ProxyOverride, Windows under proxy environment
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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Xavier de Gaye]

Xavier de Gaye  added the comment:

> and I've never seen it done by anyone else

In msg294174 Thomas says he intends to use it for Python at Google in order to 
"avoid third-party libraries even when they are available on the build system".

I do not have a strong opinion about this. Implementing the reverse configure 
option '--enable-custom-setup' is straightforward (actually this is what I did 
upon the first shot at this PR), Setup.dist becomes the default then and Thomas 
can still use Setup.local to add the *disabled* modules. It is annoying that 
there is no documentation on the build process that can be modified to describe 
the deprecation in details. Do you think a What'sNew entry is sufficient ?

--

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Antoine Pitrou]

Antoine Pitrou  added the comment:

First, I would count Google in the extremely skilled category :-)
(cc'ing Thomas so that he can chime in)

Second, if someone are doing a custom build of Python, they are very likely 
modifying something else than Modules/Setup (*).  So they already have some 
kind of custom branch or fork of CPython tracking their own customizations.  
Why Modules/Setup can't be handled the same way I'm not sure I understand.

(*) see for example the Anaconda build of Python, which modifies several files 
but *not* Modules/Setup: https://github.com/AnacondaRecipes/python-feedstock/

--
nosy: +twouters

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> It is annoying that there is no documentation on the build process that can 
> be modified to describe the deprecation in details. Do you think a What'sNew 
> entry is sufficient ?

Yes, I think so.  Also my hope is to remove it in 3.8 :-)

--

___
Python tracker 

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

[issue32430] Simplify Modules/Setup{,.dist,.local}

[Xavier de Gaye]

Xavier de Gaye  added the comment:

Yes 3.8 and this leaves plenty of time for writing some documentation on the 
build process :-)

--

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Gordon P. Hemsley]

New submission from Gordon P. Hemsley :

I noticed that there was a single line of Lib/fractions.py that did not have 
test coverage: the normalize step for fractions with non-integer numerators 
and/or denominators.

I initially was going to implement a test for that line, but upon further 
reflection, I cannot envision a scenario where that would be possible. The code 
already requires its initial parameters to be numbers.Rational and then 
normalizes their numerators and denominators to be integers.

So, instead, I propose to remove this check, first introduced in issue22486, 
and to roll the fractions._gcd() function up into the deprecated 
fractions.gcd().

--
components: Library (Lib), Tests
messages: 309288
nosy: gphemsley, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Remove fractions._gcd()
versions: Python 3.7

___
Python tracker 

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

[issue32467] dict_values isn't considered a Collection nor a Container

[Yahya Abou Imran]

New submission from Yahya Abou Imran :

a `dict_values` instance behaves like a Collection (a Sized Iterable Container):

>>> values = {1: 'one', 2: 'two'}.values()
>>> 'two' in values
True
>>> 'three' in values
False
>>> for value in values: print(value)
one
two
>>> len(values)
2

But...

>>> isinstance(values, abc.Collection)
False
>>> isinstance(values, abc.Container)
False

The reason is the lack of __contains__():

>>> '__contains__' in dir(values)
False

The 'in' operator works above because it uses __iter__() to check the presence 
of the value.

I think it's inconsistent with the fact that dict_values is in the registry of 
ValuesView witch passes the test:

>>> issubclass(abc.ValuesView, abc.Collection)
True

A class passed in the registry of ValuesView should guarantee this behaviour 
(witch is the case here by the way, but informally).


I can think about several solutions for this:

1. add a __contains__() to the dict_values class;
2. if an ABC is considered a subclass of another ABC, all the classes in  the 
registry of the first (and recursively all of their subclasses) should be too;
3. pass dict_values in the registry of Container or Collection;
4. make ValuesView inherit from Container or Collection.


IMHO:

1 is out.
2 makes sense, but may be difficult to implement since it implies that a class 
has to know all the registries it's been passed in.
3 and 4 are by far the easiest ways to do it.


I think the inheritance from Collection is the best solution, because KeysView 
and ItemsView are already Collections by inheriting from Set witch inherits 
from Collection. The only fondamental difference between the three views (in 
terms of protocol and API), it's that ValuesView is not a Set.

--
messages: 309289
nosy: yahya-abou-imran
priority: normal
severity: normal
status: open
title: dict_values isn't considered a Collection nor a Container
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Mark Dickinson]

Mark Dickinson  added the comment:

> [...] I cannot envision a scenario where that would be possible [...]

I don't think it can be ruled out. If I'm reading the code right, it's preceded 
by this branch of the initial if/elif chain:

elif (isinstance(numerator, numbers.Rational) and
isinstance(denominator, numbers.Rational)):
numerator, denominator = (
numerator.numerator * denominator.denominator,
denominator.numerator * numerator.denominator
)

I don't think there's any guarantee that if `numerator` is an instance of 
`numbers.Rational`, then `numerator.numerator` and `numerator.denominator` have 
exact type `int`.  (Note that an instance of `numbers.Rational` is not 
necessarily an instance of `fractions.Fraction`.)

--

___
Python tracker 

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

[issue32462] mimetypes.guess_type() returns incorrectly formatted type

[R. David Murray]

R. David Murray  added the comment:

You can get the same "bad" behavior on a posix system by having a mimetypes 
file with an incorrect entry in it.  That would be a system misconfiguration, 
as is your Windows registry case, and is outside of Python's control.  I 
suppose we could make it clearer (ie: in that intro paragraph) that the system 
files are read by default (that is, the built-in tables are only *defaults* 
unless you specify otherwise).

It is unfortunately true that the mime types in the Windows registry are less 
reliable than those on unix systems.  This has nothing to do with the mimetypes 
module itself, though ;)  I wonder if we should have made the default to be 
loading windows registry as non-strict, but that ship has sailed, I think.

Checking for at least minimal validity (xxx/yyy) would at least make things a 
little better on Windows, so I wouldn't object to adding that.

To summarize, my suggestion would be to add a note to the intro paragraph that 
system files/registry are read by default and override the built-in tables, and 
add a minimal sanity check on the mime type values read.  Adding .sql to the 
strict list is a separate issue, and would not change the behavior here (unless 
I'm missing something, which is possible).

There are issues around adding even a minimal validity check, though: do we 
backport that?  Do we silently ignore strings in the wrong format?  Do we "fix" 
a backslash to be a slash?  Do we issue a warning for any problems we find?  
These questions should be discussed if we decide to go this route.

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

[issue32460] don't use tentative declarations

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Sounds like good hygiene to me, though I didn't know that "tentative 
declarations" were legacy (don't they simply mean the variable gets an 
arbitrary initialization value?).

--
nosy: +pitrou

___
Python tracker 

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

[issue30449] Improve __slots__ datamodel documentation

[mpb]

mpb  added the comment:

@rhettinger

I disagree (but you're the boss).  If a function can take type X as a 
parameter, I believe docs should also say what the expected behavior is when 
you call the function and pass it type X, especially when type X is 
fundamentally different from every other type the function accepts.  (And yes, 
__slots__ is not a function, but I still find the metaphor apt.) 
 Cheers!

--

___
Python tracker 

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

[issue32460] don't use tentative declarations

[Benjamin Peterson]

Benjamin Peterson  added the comment:

If no definition provides an initializer, they'll end up initialized to 0. The 
legacy part is that you can have multiple tentative definitions of a symbol and 
most unix linkers will merge them.

--

___
Python tracker 

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

[issue32460] don't use tentative declarations

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 0a37a30037073a4a9ba45e560c8445048e5f2ba2 by Benjamin Peterson in 
branch 'master':
closes bpo-32460: ensure all non-static globals have initializers (#5061)
https://github.com/python/cpython/commit/0a37a30037073a4a9ba45e560c8445048e5f2ba2


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

[issue8525] Display exception's subclasses in help()

[Sanyam Khurana]

Change by Sanyam Khurana :


--
pull_requests: +4940
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

[issue8525] Display exception's subclasses in help()

[Sanyam Khurana]

Sanyam Khurana  added the comment:

I've changed the version to 3.7. Not sure if this would need a backport since 
this is a new feature. So, I'll defer this call to a core developer. I've 
created a PR for the new feature.

--
versions: +Python 3.7 -Python 3.2

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Gordon P. Hemsley]

Gordon P. Hemsley  added the comment:

Indeed, that is the code fragment I was referring to.

Mathematically speaking, a rational number is one that can be expressed as a 
fraction of two integers, so in that regard the numerator and the denominator 
should both be integers.

But let's assume for argument's sake that a type comes through where the 
numerator and the denominator are fractions: 1/2 and 2/3, respectively. This 
code would normalize them by cross-multiplying:

numerator = 1 * 3 = 3
denominator = 2 * 3 = 6

Now they are both integers.

In what scenario would the numerator and denominator be numbers.Rational but 
not an integer or a fraction? If someone could even come up with one, would it 
be worthwhile to allow as a fraction?

And on the flip side, if math.gcd() only accepts integers and not, at least, 
numbers.Integral, wouldn't that be a bug?

--

___
Python tracker 

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

[issue32468] Frame repr should be more helpful

[Antoine Pitrou]

New submission from Antoine Pitrou :

Currently a frame's repr looks like this:

>>> f


It would be more helpful if it displayed something like:

>>> f


--
components: Interpreter Core
messages: 309298
nosy: pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Frame repr should be more helpful
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Mark Dickinson]

Mark Dickinson  added the comment:

> In what scenario would the numerator and denominator be numbers.Rational but 
> not an integer or a fraction

But that's not the issue here. The issue here is having an instance of 
`numbers.Rational` whose numerator and denominator are not specifically of 
concrete type `int`: the test that (IIUC) you're proposing to remove is:

 if type(numerator) is int is type(denominator):
 [...]

Certainly I'd expect the numerator and denominator to be instances of 
`numbers.Integral`, but that's more general than being of exact type `int`.

The `numbers.Integral` and `numbers.Rational` ABCs are deliberately not tied to 
particular concrete classes. It would be perfectly possible (and reasonable) 
for someone to have a `MyFraction` class that behaves like a `Fraction`, and 
whose numerator and denominator are instances of some other concrete class 
`MyInteger` that behaves like an integer.

The branch in the code is necessary to support that situation, so we can't 
simply remove it.

--

___
Python tracker 

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

[issue32453] shutil.rmtree can have O(n^2) performance on large dirs

[Niklas Hambüchen]

Niklas Hambüchen  added the comment:

Serhiy, did you run your benchmark on an SSD or a spinning disk?

The coreutils bug mentions that the problem is seek times.

My tests on a spinning disk with 400k files suggest that indeed rmtree() is 
~30x slower than `rm -r`:

# time (mkdir dirtest && cd dirtest && seq 1 10 | xargs touch)

real  0m0.722s
user  0m0.032s
sys 0m0.680s

# time rm -rf dirtest/

real  0m0.519s
user  0m0.074s
sys 0m0.437s

# time (mkdir dirtest && cd dirtest && seq 1 10 | xargs touch)

real  0m0.693s
user  0m0.039s
sys 0m0.659s

# time python -c 'import shutil; shutil.rmtree("dirtest")'

real  0m0.756s
user  0m0.225s
sys 0m0.499s

# time (mkdir dirtest && cd dirtest && seq 1 10 | xargs touch)

real  0m0.685s
user  0m0.032s
sys 0m0.658s

# time python3 -c 'import shutil; shutil.rmtree("dirtest")'

real  0m0.965s
user  0m0.424s
sys 0m0.528s

# time (mkdir dirtest && cd dirtest && seq 1 40 | xargs touch)

real  0m4.249s
user  0m0.098s
sys 0m2.804s

# time rm -rf dirtest/

real  0m10.782s
user  0m0.265s
sys 0m2.213s

# time (mkdir dirtest && cd dirtest && seq 1 40 | xargs touch)

real  0m5.236s
user  0m0.107s
sys 0m2.832s

# time python -c 'import shutil; shutil.rmtree("dirtest")'

real  3m8.006s
user  0m1.323s
sys 0m3.929s

# time (mkdir dirtest && cd dirtest && seq 1 40 | xargs touch)

real  0m4.671s
user  0m0.097s
sys 0m2.832s

# time python3 -c 'import shutil; shutil.rmtree("dirtest")'

real  2m49.476s
user  0m2.196s
sys 0m3.695s

The tests were done with coreutils rm 8.28, Python 2.7.14, Python 3.6.3,  on 
ext4 (rw,relatime,data=ordered), on a dmraid RAID1 across 2 WDC_WD4000FYYZ 
disks (WD 4 TB Enterprise).

Also note how deleting 100k files takes ~0.5 seconds with `rm -r` and the 
Pythons, but deleting 4x more files takes 20x longer with `rm -r` and ~300x 
longer with the Pythons.

There is clearly some boundary below which we are hitting some nice cached 
behaviour.

--

___
Python tracker 

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

[issue32468] Frame repr should be more helpful

[Antoine Pitrou]

Change by Antoine Pitrou :


--
keywords: +patch
pull_requests: +4941
stage:  -> patch review

___
Python tracker 

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

[issue32468] Frame repr should be more helpful

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue32468] Frame repr should be more helpful

[Yury Selivanov]

Yury Selivanov  added the comment:

+1

--

___
Python tracker 

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

[issue32469] Generator and coroutine repr could be more helpful

[Antoine Pitrou]

New submission from Antoine Pitrou :

Currently, a generator or coroutine's repr looks like this:

>>> gen


It could instead be something like:

>>> gen


(replace "suspended" with "running" or "closed" depending on the generator's 
status -- i.e. gi_running and gi_frame attributes)

--
messages: 309302
nosy: benjamin.peterson, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Generator and coroutine repr could be more helpful
versions: Python 3.7

___
Python tracker 

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

[issue32453] shutil.rmtree can have O(n^2) performance on large dirs

[Niklas Hambüchen]

Niklas Hambüchen  added the comment:

It turns out I was wrong when saying that there's some cache we're hitting.

In fact, `rm -r` is still precisely O(n^2), even with the coreutils patch I 
linked.

Quick overview table of the benchmark:

 nfiles real   user sys

 100.51s  0.07s   0.43s
 202.46s  0.15s   0.89s
 40   10.78s  0.26s   2.21s
 80   44.72s  0.58s   6.03s
160  180.37s  1.06s  10.70s

Each 2x increase of number of files results in 4x increased deletion time.


Full benchmark output:

# time (mkdir dirtest && cd dirtest && seq 1 10 | xargs touch)

real  0m0.722s
user  0m0.032s
sys 0m0.680s

# time rm -rf dirtest/

real  0m0.519s
user  0m0.074s
sys 0m0.437s

# time (mkdir dirtest && cd dirtest && seq 1 20 | xargs touch)

real  0m1.576s
user  0m0.044s
sys 0m1.275s

# time rm -r dirtest/

real  0m2.469s
user  0m0.150s
sys 0m0.890s

# time (mkdir dirtest && cd dirtest && seq 1 40 | xargs touch)

real  0m4.249s
user  0m0.098s
sys 0m2.804s

# time rm -rf dirtest/

real  0m10.782s
user  0m0.265s
sys 0m2.213s

# time (mkdir dirtest && cd dirtest && seq 1 80 | xargs touch)

real  0m10.533s
user  0m0.204s
sys 0m5.758s

# time rm -rf dirtest/

real  0m44.725s
user  0m0.589s
sys 0m6.037s

# time (mkdir dirtest && cd dirtest && seq 1 160 | xargs touch)

real  0m34.480s
user  0m0.382s
sys 0m12.057s

# time rm -r dirtest/

real  3m0.371s
user  0m1.069s
sys 0m10.704s

--

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's a concrete example, using gmpy2 [1], that exercises the code path you're 
proposing to remove. I had to cheat a bit, since the gmpy2 types *don't* 
(currently) buy in to the numbers ABC tower (though there's no good reason that 
they couldn't do so), so I registered them manually.

>>> import fractions, numbers
>>> import gmpy2
>>> x = gmpy2.mpq(2, 3)
>>> numbers.Rational.register(type(x))

>>> numbers.Integral.register(type(x.denominator))

>>> fractions.Fraction(x, x)  # code path exercised here ...
Fraction(1, 1)

Note that the numerator and the denominator of the resulting `Fraction` object 
are still of type `mpz`.

It _would_ be possible to remove the check and always use `math.gcd`, but it 
would result in a behaviour change: for the above code, we'd get a `Fraction` 
whose numerator and denominator were both of actual type `int` instead of 
`mpz`. Whether that's a desirable behaviour change or not is another question 
...

[1] https://gmpy2.readthedocs.io/en/latest/

--

___
Python tracker 

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

[issue32453] shutil.rmtree can have O(n^2) performance on large dirs

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Did you try to sync and flush caches before running `rm -r`?

--

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Mark Dickinson]

Mark Dickinson  added the comment:

> if math.gcd() only accepts integers and not, at least, numbers.Integral, 
> wouldn't that be a bug?

I'd call it an enhancement opportunity rather than a bug. :-) There's no 
general Python-wide requirement that an instance of numbers.Integral should be 
acceptable anywhere an int is (though I agree that it's a nice property to have 
in general).

But as it happens, math.gcd _does_ accept instances of numbers.Integral, since 
any such instance should implement the __index__ method to convert itself to a 
plain old int, and math.gcd passes its arguments through PyNumber_Index.

--

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Mark Dickinson]

Mark Dickinson  added the comment:

> but it would result in a behaviour change: for the above code, we'd get a 
> `Fraction` whose numerator and denominator were both of actual type `int` 
> instead of `mpz`

Ah, sorry. That's not true in this particular case. The returned gcd would be 
of type `int`, but then we end up dividing an `mpz` by an `int` to get an 
`mpz`. So I guess the problem case is where we have something that's like `mpz` 
but that doesn't support division by a plain `int`: I don't think there's any 
requirement that instances of numbers.Integral support mixed-type arithmetic 
with plain ints.

I'd actually be happier if the `fractions.Fraction` type *did* normalise so 
that its numerator and denominator always had exact type `int`, but that's not 
the way that it was designed: it was designed to support arbitrary 
numbers.Integral instances.

--

___
Python tracker 

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

[issue32453] shutil.rmtree can have O(n^2) performance on large dirs

[Niklas Hambüchen]

Niklas Hambüchen  added the comment:

> Did you try to sync and flush caches before running `rm -r`?

Yes, it doesn't make a difference for me, I still see the same O(n²) behaviour 
in `rm -r`.

I've sent an email "O(n^2) performance of rm -r" to bug-coreut...@gnu.org just 
now, unfortunately I can't link it yet because the mailman archive doesn't show 
it yet. It should appear soon on 
http://lists.gnu.org/archive/html/bug-coreutils/2017-12/threads.html.

--

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Gordon P. Hemsley]

Gordon P. Hemsley  added the comment:

Side note: https://github.com/aleaxit/gmpy/issues/127 suggests that the types 
in question were added to the numeric tower for gmpy 2.0.9 and 2.1.0.

--

___
Python tracker 

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

[issue32466] Remove fractions._gcd()

[Gordon P. Hemsley]

Gordon P. Hemsley  added the comment:

So, if I'm understanding your position correctly:

* We're back to needing a test for the line in question.
* We're eschewing the possibility of changing the behavior of 
`fractions.Fraction` to force int numerator and denominator.

Is that correct?

--

___
Python tracker 

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

[issue32468] Frame repr should be more helpful

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset 14709144b521b9916f798a43aac9dc44fd44f6ca by Antoine Pitrou in 
branch 'master':
bpo-32468: Better frame repr() (#5067)
https://github.com/python/cpython/commit/14709144b521b9916f798a43aac9dc44fd44f6ca


--

___
Python tracker 

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

[issue32468] Frame repr should be more helpful

[Antoine Pitrou]

Change by Antoine Pitrou :


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

[issue32470] Unexpected behavior of struct.pack

[Luka Malisa]

Change by Luka Malisa :


--
components: Library (Lib)
nosy: Luka Malisa
priority: normal
severity: normal
status: open
title: Unexpected behavior of struct.pack
type: behavior
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

[issue32470] Unexpected behavior of struct.pack

[Luka Malisa]

New submission from Luka Malisa :

>>> import struct
>>> struct.pack("IB", 1, 1)
b'\x01\x00\x00\x00\x01'
>>> struct.pack("BI", 1, 1)
b'\x01\x00\x00\x00\x01\x00\x00\x00'

--

___
Python tracker 

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

[issue32470] Unexpected behavior of struct.pack

[Benjamin Peterson]

Benjamin Peterson  added the comment:

That's because of alignment. See 
https://docs.python.org/3/library/struct.html#struct-alignment

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

[issue32469] Generator and coroutine repr could be more helpful

[Taras Matsyk]

Change by Taras Matsyk :


--
keywords: +patch
pull_requests: +4942
stage:  -> patch review

___
Python tracker 

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

[issue32469] Generator and coroutine repr could be more helpful

[Taras Matsyk]

Taras Matsyk  added the comment:

I have added a pull request. Hope it makes sense and I've done everything 
correctly :)

Happy New Year!

--
nosy: +tarasmatsyk

___
Python tracker 

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

[issue32445] Skip creating redundant wrapper functions in ExitStack.callback

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think I am missing something because the callbacks are always called with 
(exc_type, exc, tb) (check here 
https://github.com/python/cpython/blob/176baa326be4ec2dc70ca0c054b7e2ab7ca6a9cf/Lib/contextlib.py#L475)
 and therefore a wrapper that just drops these arguments and calls the original 
callback with no arguments is always needed, right?

--
nosy: +pablogsal

___
Python tracker 

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

[issue32453] shutil.rmtree can have O(n^2) performance on large dirs

[Niklas Hambüchen]

Niklas Hambüchen  added the comment:

OK, my coreutils email is at 
http://lists.gnu.org/archive/html/bug-coreutils/2017-12/msg00054.html

--

___
Python tracker 

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

[issue32471] Add an UML class diagram to the collections.abc module documentation

[Yahya Abou Imran]

New submission from Yahya Abou Imran :

>From python-ideas: 
>https://mail.python.org/pipermail/python-ideas/2017-December/048492.html

In this page of the documentation:
https://docs.python.org/3/library/collections.abc.html

The table could be difficult to understand, a diagram help visualize things.

I'm joining the last version of my work, and the .puml I used to generate it.

Opinions about details (fonts, displaying...) are being discussed on the 
mailist right now.

--
assignee: docs@python
components: Documentation
files: base.png
messages: 309318
nosy: docs@python, yahya-abou-imran
priority: normal
severity: normal
status: open
title: Add an UML class diagram to the collections.abc module documentation
type: enhancement
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47357/base.png

___
Python tracker 

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

[issue32471] Add an UML class diagram to the collections.abc module documentation

[Yahya Abou Imran]

Yahya Abou Imran  added the comment:

Here is the .puml

--
Added file: https://bugs.python.org/file47358/base.puml

___
Python tracker 

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

[issue32472] Mention of __await__ missing in Coroutine Abstract Methods

[Yahya Abou Imran]

New submission from Yahya Abou Imran :

In the collections.abc documentation:

https://docs.python.org/3/library/collections.abc.html

__await__() doesn't appear in the abstract methods of Coroutine, we see only 
send() and throw().

But since Coroutine inherit from Awaitable, it's required:


from collections.abc import Coroutine

class MyCoroutine(Coroutine):
def send(self, value):
raise StopIteration
def throw(self, err):
raise err

mc = MyCoroutine()

Traceback (most recent call last):
  File "_tmp.py", line 9, in 
mc = MyCoroutine()
TypeError: Can't instantiate abstract class MyCoroutine with abstract methods 
__await__


To be consistent with the rest of the document, this method should appear here 
to show all the abstract methods, even the inherited ones.

--
assignee: docs@python
components: Documentation
messages: 309320
nosy: docs@python, yahya-abou-imran
priority: normal
severity: normal
status: open
title: Mention of __await__ missing in Coroutine Abstract Methods
type: enhancement
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue32473] Readibility of ABCMeta._dump_registry()

[Yahya Abou Imran]

New submission from Yahya Abou Imran :

>From python-ideas:
https://mail.python.org/pipermail/python-ideas/2017-December/048504.html

In python 2.7, ABCs's caches and registries are sets. But in python 3.6 they 
are WeakSet.
In consequence, the output of _dump_registry() is almost useless:

>>> from collections import abc
>>> abc.Iterator._dump_registry()
Class: collections.abc.Iterator
Inv.counter: 40
_abc_cache: <_weakrefset.WeakSet object at 0x7f4b58fe2668>
_abc_negative_cache: <_weakrefset.WeakSet object at 0x7f4b53283780>
_abc_negative_cache_version: 40
_abc_registry: <_weakrefset.WeakSet object at 0x7f4b58fe2630>

We could convert them into a regular set before printing:

if isinstance(value, WeakSet):
value = set(value)

The result:

>>> abc.Iterator._dump_registry()
Class: collections.abc.Iterator
Inv.counter: 40
_abc_cache: {, , , , , 
, , , , , , , }
_abc_negative_cache: set()
_abc_negative_cache_version: 40
_abc_registry: set()

--
messages: 309321
nosy: yahya-abou-imran
priority: normal
severity: normal
status: open
title: Readibility of ABCMeta._dump_registry()
type: enhancement
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue32474] argparse nargs should support string wrapped integers too

[Shubham Sharma]

Change by Shubham Sharma :


--
components: Library (Lib)
nosy: shubham1172
priority: normal
severity: normal
status: open
title: argparse nargs should support string wrapped integers too
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue32474] argparse nargs should support string wrapped integers too

[Steven D'Aprano]

New submission from Steven D'Aprano :

What do you mean by "string wrapped integers", and how should it support them?

--
nosy: +steven.daprano

___
Python tracker 

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

[issue32474] argparse nargs should support string wrapped integers too

[Shubham Sharma]

Shubham Sharma  added the comment:

Values like "1", "2", "3", should be supported.

--

___
Python tracker 

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

[issue32474] argparse nargs should support string wrapped integers too

[Shubham Sharma]

Shubham Sharma  added the comment:

A simple int(nargs) would be sufficient. I am getting ready with a PR in some 
time.

--

___
Python tracker 

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

[issue32474] argparse nargs should support string wrapped integers too

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Values like "1", "2", "3", should be supported.

You mean you want to call parser.add_argument('--foo', nargs="2") 
instead of parser.add_argument('--foo', nargs=2)?

Why?

--

___
Python tracker 

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

[issue32474] argparse nargs should support string wrapped integers too

[R. David Murray]

R. David Murray  added the comment:

Why?  What's the motivation for supporting this?  There's no reason that I can 
think of, so I'm curious what your use case is.

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

[issue32474] argparse nargs should support string wrapped integers too

[Shubham Sharma]

Shubham Sharma  added the comment:

nargs can take various values like "*", "+", etc. but doesn't support integers 
which are wrapped around in strings. Say, I want to take a user input for the 
nargs value (just a hypothetical situation); now I'll have to check 
additionally whether there's a numeric value inside the input char and then 
cast it to integer manually. An enhancement like this would eliminate this 
hassle and support for these will be helpful.

--

___
Python tracker 

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