date:20191110



Brandt Bucher  added the comment:

I went ahead and opened a PR, since it's been a month.

--

___
Python tracker 

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

[issue38438] argparse "usage" overly-complex with nargs="*"



Change by Brandt Bucher :


--
keywords: +patch
pull_requests: +16612
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17106

___
Python tracker 

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

[issue38764] Deterministic globbing.

2019-11-10 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue38762] Logging displays wrong "processName" if "sys.modules" is cleared in child process

2019-11-10 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue38763] mock with side effect : assert_called_once returns None while call_count returns 1

2019-11-10 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

assert_called_once is supposed to raise an AssertionError if the mock is not 
called and to return None like other assert_* helpers. The return value is not 
supposed to be used and it's more of an assertion action where if it's None 
then it's implied to be True.

>>> from unittest.mock import Mock
>>> def side_effect(*args, **kwargs): print("side_effect called")
...
>>> m = Mock(side_effect=side_effect)
>>> m.call_count
0
>>> m.assert_called_once()
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/kasingar/stuff/python/cpython/Lib/unittest/mock.py", line 881, 
in assert_called_once
raise AssertionError(msg)
AssertionError: Expected 'mock' to have been called once. Called 0 times.
>>> m()
side_effect called
>>> m.call_count
1
>>> m.assert_called_once()
>>> m.assert_called()
>>> m.assert_has_calls([call()])

--
nosy: +xtreak

___
Python tracker 

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

[issue38764] Deterministic globbing.



Brandt Bucher  added the comment:

I disagree somewhat with the assessment that glob provides "thin" access to OS 
services. It is composed of a few low-level utilities, but it exposes them 
through what I consider to be a fairly high-level, abstract, friendly interface 
that (aside from ordering, and some symlink stuff) is surprisingly 
cross-platform.

I originally felt that this was "their own fault", since the behavior is 
well-documented and the data pipeline was so susceptible to error. But I 
started thinking more about the fact that the bad globbing made it into 
peer-reviewed cancer research over a hundred times. Python is a friendly 
language and glob is a friendly library, so it would be natural for someone 
without formal engineering experience to reach for both. I'm becoming more and 
more surprised that glob exposes this type of quirk, for trivial gain.

I respect your opinion though. Another option would be to leave the patch in, 
but not document the new traversal order. That way we rid ourselves of a class 
of user errors without exposing implementation details like the type of search 
used.

--

___
Python tracker 

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

[issue38764] Deterministic globbing.

2019-11-10 Thread Nathaniel Smith


Nathaniel Smith  added the comment:

> I saw the article as well, but think auto-sorting would have just provided a 
> thin mask over their serious data pipeline bugs.

This seems like an inappropriately elitist attitude. I'm sure their code has 
bugs; so does mine and yours. But in fact they did test their code thoroughly, 
demonstrated that it produced correct results on their system, and it would 
have produced correct results for their downstream users too if Python's 'glob' 
had behaved consistently across platforms. Python isn't just for folks who can 
"git gud" to meet your arbitrary standards.

In addition, auto-sorting has a number of ergonomic benefits, beyond this one 
case: it makes output more deterministic, makes it easy to estimate progress 
given just a list of filenames being processed ("hmm, this script has been 
running for ten minutes and it's only on the Cs, I guess this will take a few 
hours"), and so on.

> Also, this isn't the only pathway to seeing file lists:  os.listdir, fnmatch, 
> etc.

os.listdir is a genuinely low-level OS-level tool, as indicated by the name, 
versus 'glob' which is designed as a convenient interface for high-level 
scripting.

fnmatch doesn't deal with either files or lists, so I'm not sure why you're 
bringing it up here.

> The reasons for the previous rejections still apply.

The reasons I see in the previous issues are:

- Sorting adds overhead
- It's hard to implement, esp. if iglob uses scandir internally
- iglob can't sort, so glob should be consistent
- it's easy to sort after the fact

But these are all false.

- The overhead added by sorting is negligible. In some informal benchmarks I 
measured it as ~4% extra CPU time in the worst case, if you're (a) running on 
Linux with it's ultra-optimized VFS caching, (b) all the directories are 
already cached in RAM, (c) you're not actually doing anything with the files 
except calling glob() and then discarding the result. Of course, it's always 
possible my benchmarks missed an important case; if you have benchmarks that 
show otherwise please post them so we can discuss.

- The implementation is trivial, as shown from the PR – literally just 
replacing two calls to 'list' with calls to 'sorted'.

- iglob being incremental doesn't actually pose any obstacles to sorting. Even 
if it's using scandir(), it still has to load each individual directory list 
into memory in one batch, to avoid the risk of leaking file descriptors.

- It's actually not trivial to sort filenames in the natural order afterwards, 
because you have to split each filename into components. It's also 
asymptotically slower than doing the sort as-you-go, O(total-files log 
total-files), versus O(total-files log maximum-individual-directory).

Given that there's at least one extremely clear case where not-sorting caused 
substantial harm, that there are lots of other minor cases where it's a nice 
win, and that the costs are negligible, sorting seems like the obviously 
correct default.

--

___
Python tracker 

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

[issue38761] weakref.WeakSet not instanceof collections.abc.Set



Raymond Hettinger  added the comment:

Nils, thanks for the report.

Guido, thanks for the clarification.

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

[issue38761] weakref.WeakSet not instanceof collections.abc.Set



Raymond Hettinger  added the comment:


New changeset 84ac4376587e35d16b4d0977c4f330d9d04b690a by Raymond Hettinger in 
branch 'master':
bpo-38761: Register WeakSet as a MutableSet (GH-17104)
https://github.com/python/cpython/commit/84ac4376587e35d16b4d0977c4f330d9d04b690a


--

___
Python tracker 

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

[issue38673] REPL shows continuation prompt (...) when comment or space entered



Guido van Rossum  added the comment:

> But is the 'fix' in _maybe_compile at all applicable to the REPL?  Or might a 
> parser change REPL fix make the code in _maybe_compile unneeded?

I don't know.  Most of the contortions in code.py codeop.py are meant to 
emulate what the parser does without help in the REPL: keep asking for input 
until one of the following happens:

- a syntax error is found;

- a simple statement is parsed till completion;

- an empty line is found at a point where a compound statement is potentially 
complete.

The bug here is that apparently the above conditions aren't quite enough, and 
it seems we need to add:

- a line that contains just whitespace and/or a comment is seen before anything 
else.

The reason that IDLE has to reimplement similar logic is that the parser 
(actually, the tokenizer) isn't written as a coroutine to which you send lines 
you read -- it's written as a blocking function that you pass a file and the 
function will attempt to read lines from the file.  The function returns a 
parse tree or raise an error.  That model doesn't work in IDLE, which needs to 
stay reactive while the shell window is in the middle of a statement.

I think we'll find that the bug is *very* old.  IIRC the initial releases of 
Python didn't have the rule that indentation is ignored between matching 
parentheses/brackets/braces.  In those days the tokenizer also didn't 
gracefully skip blank lines, or lines with comments that weren't aligned with 
the current indentation level.  So then checking for empty lines was good 
enough.

--

___
Python tracker 

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

[issue38764] Deterministic globbing.



Raymond Hettinger  added the comment:

I saw the article as well, but think auto-sorting would have just provided a 
thin mask over their serious data pipeline bugs.

Also, this isn't the only pathway to seeing file lists:  os.listdir, fnmatch, 
etc.

I say that we leave it alone and not unnecessarily introduce a breadth-first, 
recursive sort.  The reasons for the previous rejections still apply.  For the 
most part our tools that access os services only provide a thin pass-through 
and tend to neither promise nor do anything extra (even SQL only gives sorted 
data when the user explicitly requests ORDER By -- the could have provided a 
default sort but choose not to).

--
nosy: +rhettinger

___
Python tracker 

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

[issue38673] REPL shows continuation prompt (...) when comment or space entered

2019-11-10 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

Fix corner case bugs in IDLE would definitely be a separate issue.  But is the 
'fix' in _maybe_compile at all applicable to the REPL?  Or might a parser 
change REPL fix make the code in _maybe_compile unneeded?

--

___
Python tracker 

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

[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode

2019-11-10 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Stephen, I think *you* were the one over-anxious to be dismissive.  In the 
title Marco refers to "Jupyter console (IPython)" features and in his opening, 
to "Jupyter console, aka IPython".  Jupyter Console is, I read, QT based.  
IPython/Jupyter Notebooks are GUI-based also.  

However, I agree that single process terminal IPython, such as illustrated near 
the top of
https://ipython.readthedocs.io/en/stable/index.html
is the better reference for comparison.  As pictured, it requires a color 
terminal with full screen edit.

An important constraint is that instead of users talking to the UI program with 
menu clicks, they must use "‘magic’ commands" entered after the '>>>' prompt 
instead of code.  Guido specifically vetoed the idea of allowing these into 
IDLE, so he must not want them in the REPL either.

Skipping the rest of your post, I will just restate why I closed this issue.

1. It introduces too many features not directly related.  The existing 
unix-only completions uses two modules.  I suspect some of the other features 
would also need new modules.  (But Marco, please don't rush to immediately open 
8 new issues.)

Furthest removed, no new module needed: Adding builtins that can be used in 
REPL as it is. I suspect the answer to that proposal would be to use a 
PYTHONSTARTUP module with code such as "import pprint as _; pprint = _.pprint"

2. It introduces policy issues that might require a policy change, and that I 
think should better be discussed on, say, pydev.  Steven and I have obviously 
gotten different policy impressions from Brett and Guido respectively. I will 
try to ask on pydev what the current REPL feature policy is, and what people 
think it should be.  For instance, how far do we want to go is adding features 
that only work on a subset of systems?

3. I believe that some of the concrete proposals have even more implementation 
problems than Marco himself acknowledged.  Difficult does not mean prohibited, 
but coredevs are mostly not interested in working on UIs and it has been 
Guido's stated-to-me policy that 'advanced' UI/IDE features (not defined) 
should be left to other projects.

One communication problem is that once python is running in interactive mode, 
the only thing the user can send to it is lines of Python code.  Consider 
pasting multiline code with blank lines.  The console feeds pasted lines *1 at 
a time* to interactive Python, the same as if the user typed them.  So Python 
does not know if they were typed or pasted.  Nor does it know that there might 
be a next line already waiting, and if so, what it is (dedented?).  If it does 
not execute on receiving '\n', when will it?

There are also communication issues in the other direction.  When REPL sends a 
prompt, everything up to and including a prompt is somehow marked read-only.  
But autoindents must be left erasable so a user can dedent.

If that can be solved, including on Windows, I would like IDLE's autoindent 
code moved to an stdlib module (and polished, if need be) to be used by REPL, 
IDLE, and anyone else who wishes.  The main function would map a sequence of 
lines to a PEP-8 compliant indent for the next line.

Syntax-coloring opens a much bigger can of worms.  It requires full screen 
editing to overwrite existing input.  It also needs to be configurable as part 
of a configuration system.  IPython requires the user to write "a dictionary 
mapping Pygments token types to strings defining the style." in a python file 
with other needed code in a place where IPython can find it.  IDLE lets one 
modify an existing scheme by clicking on an element in sample code and then a 
new color and let IDLE handle the storage.

Marco, you said "I *really* hope that IDLE is simply a GUI wrapper of REPL".  
Nope.  In a single process, python cannot simultaneous execute a file in batch 
mode and input lines in interactive mode.  IDLE uses "exec(code, 
simulated_main_namespace)" and I suspect other simulated shells do something 
similar.  An advantage is that 'code' can represent complete multiline 
statements or even an entire module.

--

___
Python tracker 

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

[issue38764] Deterministic globbing.



Change by Brandt Bucher :


--
keywords: +patch
pull_requests: +16611
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17105

___
Python tracker 

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

[issue38764] Deterministic globbing.

New submission from Brandt Bucher :

This has been discussed before, but we now have examples in the news of glob's
non-deterministic behavior causing some real headaches for hundreds of people
in the scientific community. After some cursory discussion
(https://discuss.python.org/t/a-code-glitch-may-have-caused-errors-in-more-than-100-published-studies/2583)
it was suggested that this issue would at least be worth revisiting, given the
damage... bad programming practices aside.

The attached patch guarantees glob/iglob traversal order across all platforms,
and modifies all of the existing tests to check for this.

One reason this was rejected twice before (in both issue 21748, four years ago,
and issue 30461, two years ago) was the argument that the user could always
just call "sorted" on the returned list if they wanted ordered results. Aside
from losing the laziness of iglob, this solution also loses the traversal
order, since recursive globs use a breadth-first search. In the attached patch,
iglob is still just as lazy as ever, and the traversal is unchanged for anyone
using a platform that already returns sorted results.

--
components: Library (Lib)
messages: 356344
nosy: brandtbucher, njs
priority: normal
severity: normal
status: open
title: Deterministic globbing.
type: enhancement
versions: Python 3.9

___
Python tracker

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

[issue38761] weakref.WeakSet not instanceof collections.abc.Set



Guido van Rossum  added the comment:

As I wrote between the lines in the PR, this would be a bug in the weakref 
module, not a bug in collections.abc.

--

___
Python tracker 

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

[issue38756] Add generic versions of weakref types to typing module



Guido van Rossum  added the comment:

PEP 585 says

Discussions-To: Typing-Sig 

So I'd start there.

(But honestly I think what Ivan meant is that it would automatically work. Read 
the PEP carefully before posting if you disagree.)

--

___
Python tracker 

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

[issue38763] mock with side effect : assert_called_once returns None while call_count returns 1

2019-11-10 Thread Troulet-lambert Odile



New submission from Troulet-lambert Odile :

Using a mock with side_effect, I would expect that assert_called_once returns 
True if the mock has been called.
Yet it returns None while call_count== 1 returns True.

If this is not a bug, I would welcome some explanation in the documentation.

--
components: Tests
files: bugmock.tar
messages: 356341
nosy: piscvau
priority: normal
severity: normal
status: open
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48706/bugmock.tar

___
Python tracker 

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

[issue32879] Race condition in multiprocessing Queue

2019-11-10 Thread Eric Meyer



Eric Meyer  added the comment:

The problem I was seeing ended up being improper GIL management in a c++ 
extension. It seems putting items that were created without the GIL on the 
queue causes a seg fault.

--

___
Python tracker 

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

[issue38751] Document maximum JSON depth or remove it.



Change by Raymond Hettinger :


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

[issue38751] Document maximum JSON depth or remove it.



Raymond Hettinger  added the comment:

There is nothing here specific to JSON.  It is Python's normal (and documented) 
limit on recursion. 

If needed, you can change the limit to as large as needed:

import json
import sys
sys.setrecursionlimit(50_000)

foo = {}

for i in range(10_000):
foo = {'bar': foo}
s = json.dumps(foo)
print(len(s))

--
nosy: +rhettinger

___
Python tracker 

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

[issue38762] Logging displays wrong "processName" if "sys.modules" is cleared in child process

2019-11-10 Thread Delgan



New submission from Delgan :

Hi.

In order to display the process name in logs, the "logging" module checks for 
the presence of "multiprocessing" in "sys.modules" before calling 
"current_process()". If "multiprocessing" is not found in "sys.modules", it 
assumes that the current process is the main one.

See : 
https://github.com/python/cpython/blob/af46450bb97ab9bd38748e75aa849c29fdd70028/Lib/logging/__init__.py#L340-L341

However, nothing prevents a child process to delete 
"sys.module['multiprocessing']", which causes the process name to be wrongly 
displayed as "MainProcess".

I attached a reproducible example, but this is straightforward to understand. 
Although it should not happen very often in practice, it is still theoretically 
possible. Obviously, one could say "just don't clear sys.modules", but I 
suppose there might exist tools doing such thing for good reasons (like 
resetting the test environment).

Issues which lead to the current implementation:
- issue4301
- issue7120
- issue8200

Possible fixes: 
- Force import "multiprocessing.current_process()" even if not already loaded
- Add function "os.main_pid()" and set "processName" to "MainProcess" only if 
"os.getpid() == os.main_pid()"

--
components: Library (Lib)
files: test.py
messages: 356338
nosy: Delgan
priority: normal
severity: normal
status: open
title: Logging displays wrong "processName" if "sys.modules" is cleared in 
child process
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48705/test.py

___
Python tracker 

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

[issue38761] weakref.WeakSet not instanceof collections.abc.Set



Change by Raymond Hettinger :


--
keywords: +patch
pull_requests: +16610
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17104

___
Python tracker 

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

[issue38761] weakref.WeakSet not instanceof collections.abc.Set



Raymond Hettinger  added the comment:

We could register the WeakSet in _collections_abc, right after MutableSet is 
defined.  That module only registered builtins so that it can avoid imports; 
however, since we know that WeakSet is already loaded, it is reasonable to add 
an import for registration purposes.

This was likely omitted because WeakSet is used in the implementation of the 
ABC.

Marking this as a proposed enhancement rather than as a bug because the 
collections ABCs are under no obligation to register anything more than the 
builtins.

--
assignee:  -> rhettinger
nosy: +gvanrossum, rhettinger
type:  -> enhancement
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue37564] ArgumentParser should support bool type according to truth values



Change by Raymond Hettinger :


--
Removed message: https://bugs.python.org/msg356334

___
Python tracker 

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

[issue37564] ArgumentParser should support bool type according to truth values



Raymond Hettinger  added the comment:

Right now "type" has a clear and understandable action of invoking a callable.  
 Imbuing "type" with other semi-magical capabilities opens a new can of worms.

Unless some persuasive new commentary appears in the next few days, I'm going 
to close this feature request and the associated PR.

At some point, we should consider adding a recipes/faq section to the docs.  
That would help people bridge from their goals to the actual capabilities 
offered by the module.

Also, we should make strong suggestions about the separation of 
responsibilities between the parser and the downstream code that acts on the 
parsed variables (much like the discussion in the templating world about 
keeping business logic outside of the template and instead focusing on 
formatting logic).

For the case at hand, there are several ways to go:

  # Proposed new magic with hard-wired
  # truthy/false words: yes True 1 true Y si oui ...
  parser.add_argument("--mybool", type='bool')

  # Existing capability where the user controls
  # exactly which logic to apply
  parser.add_argument("--mybool", type=str_to_bool)

  # Existing capability with downstream processing
  parser.add_argument("--mybool", choices={'True', 'False', 'Yes', 'No'}
  args = parser.parse_args()
  mybool = args.mybool in {'True', 'Yes'}

  # Existing capability with explicit flag arguments
  # (the highly upvoted "canonical" solution StackOverflow)
  parser.add_argument('--feature', dest='feature', action='store_true')
  parser.add_argument('--no-feature', dest='feature', action='store_false')
  parser.set_defaults(feature=True)

--

___
Python tracker 

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

[issue38756] Add generic versions of weakref types to typing module



Nils Kattenbeck  added the comment:

Okay, if I want to start a discussion about adding weakref types to PEP 585 
where should do it? The mailing list or as an issue in the PEP repo?

--

___
Python tracker 

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

[issue37564] ArgumentParser should support bool type according to truth values



Raymond Hettinger  added the comment:

Right now "type" has a clear and understandable action of invoking a callable.  
 Imbuing "type" with other semi-magical capabilities opens a new can of worms.

Unless some persuasive new commentary appears in the next few days, I'm going 
to close this feature request and the associated PR.

At some point, we should consider adding a recipes/faq section to the docs.  
That would help people bridge from their goals to the actual capabilities 
offered by the module.

Also, we should make strong suggestions about the separation of 
responsibilities between the parser and the downstream code that acts on the 
parsed variables (much like the discussion in the templating world about 
keeping business logic outside of the template and instead focusing on 
formatting logic).

For the case at hand, there are several ways to go:

  # proposed new magic with hard-wired
  # truthy/false words: yes True 1 true Y si oui ...
  parser.add_argument("--mybool", type='bool')

  # existing capability where the user controls
  # exactly which logic to apply
  parser.add_argument("--mybool", type=str_to_bool)

  # Existing capability with downstream processing
  parser.add_argument("--mybool", choices={'True', 'False', 'Yes', 'No'}
  args = parser.parse_args()
  mybool = args.mybool in {'True', 'Yes'}

--
assignee:  -> rhettinger
nosy: +rhettinger
type: behavior -> enhancement
versions:  -Python 2.7, 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

[issue38756] Add generic versions of weakref types to typing module

2019-11-10 Thread Ivan Levkivskyi



Ivan Levkivskyi  added the comment:

We already have https://github.com/python/typing/issues/508 for "smart" 
`get_type_hints()` that would use LBYL. Also we had a similar discussion about 
PathLike, and ultimately decided not to make `typing` a place for generic 
versions of everything.

Finally, in view of PEP 585 some of these things may actually become 
subscriptable at runtime. So I propose to just close this issue.

--
resolution:  -> wont fix
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

[issue37564] ArgumentParser should support bool type according to truth values

2019-11-10 Thread Daniel Kahn Gillmor



Daniel Kahn Gillmor  added the comment:

this is a common enough question, and enough people want this behavior, that 
argparse should supply it.

I'm imagining that:  

   type='bool'

would be fine for triggering this behavior, instead of the shadowing that could 
happen with:

   type=bool

so if type='bool' is supplied, the following things would happen:

 * argparse could use strtobool to interpret the incoming string
 * the default metavar would look something like "{true,false}"
 * followon packages like argcomplete could enumerate the range of different 
values that strtobool accepts

This is still english-specific -- but it's because strtobool is 
english-specific, and fixes in strtobool would automatically fix type='bool' 
here.

--
nosy: +dkg

___
Python tracker 

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

[issue38756] Add generic versions of weakref types to typing module


Guido van Rossum  added the comment:

@ilevkivskyi Is this important enough to change get_type_hints()?

Otherwise let’s close this issue.

--

___
Python tracker 

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

[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode

2019-11-10 Thread Marco Sulla



Marco Sulla  added the comment:

@Eryk: why a C extension apart and not a patch to `readline`?

--

___
Python tracker 

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

[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)

2019-11-10 Thread Dong-hee Na



Dong-hee Na  added the comment:

According to 
https://www.gnu.org/software/libc/manual/html_node/Open-File-Description-Locks.html

It is important to distinguish between the open file description (an instance 
of an open file, usually created by a call to open) and an open file 
descriptor, which is a numeric value that refers to the open file description. 
The locks described here are associated with the open file description and not 
the open file descriptor

--

___
Python tracker 

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

[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)

2019-11-10 Thread Dong-hee Na



Dong-hee Na  added the comment:

One question:
Is there any reason to choose the name is `open_file_descriptor` not 
`open_file_description`?

--

___
Python tracker 

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

[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode

2019-11-10 Thread Eryk Sun



Eryk Sun  added the comment:

> For example, I would be shocked if it wasn't absolutely trivial 
> for the current implementation to add auto-indenting following 
> a colon. That feature alone would be a win for usability.

That would be a non-trivial change in Windows. I think it's at least possible 
using the high-level console API. It could be implemented with the 
pInputControl parameter of ReadConsoleW in combination with WriteConsoleW. This 
is how the CMD shell implements tab completion for file paths. That said, many 
of the proposed UI enhancements cannot be implemented in Windows using the 
high-level console API. 

IPython used to depend on readline. (5.0 switched to prompt_toolkit instead.) 
In Windows this was via the pyreadline package, which uses the low-level 
console API via ctypes. pyreadline is apparently abandoned (last updated in 
2015). Maybe CPython could incorporate a fork of pyreadline that fixes bugs 
(Unicode support in particular) and updates it to use a C extension instead of 
ctypes.

--
nosy: +eryksun

___
Python tracker 

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

[issue38761] weakref.WeakSet not instanceof collections.abc.Set



New submission from Nils Kattenbeck :

Instances of weakref.WeakSet are not instances of Set and therefore not of 
MutableSet but they are instances of Collection.
They however implement all required methods for a MutableSet and 
Weak(Key|Value)Dictionary are correctly identified.
Is this just an oversight or am I missing something?


from weakref import WeakKeyDictionary, WeakValueDictionary, WeakSet
from collections.abc import MutableMapping, Collection, Set, MutableSet

wkdict = WeakKeyDictionary()
wvdict = WeakValueDictionary()
ws = WeakSet()

assert isinstance(wkdict, MutableMapping)
assert isinstance(wvdict, MutableMapping)
assert isinstance(ws, Collection)
assert not isinstance(ws, Set)
assert not isinstance(ws, MutableSet)

--
components: Library (Lib)
messages: 356326
nosy: Nils Kattenbeck
priority: normal
severity: normal
status: open
title: weakref.WeakSet not instanceof collections.abc.Set
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

[issue38756] Add generic versions of weakref types to typing module



Nils Kattenbeck  added the comment:

Okay nevermind, after looking in the PEP again and inspecting the 
__annotations__ property I learned that annotations are never evaluated and 
just saved as a string when using said future statement.

However this may still be relevant as typing.get_type_hints will still fail. 
For my use case however this is sufficient.

--

___
Python tracker 

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

[issue38756] Add generic versions of weakref types to typing module