paul j3 added the comment:
Provide a minimal reproducible example. I can't reproduce that run on error
message.
Also test with arguments like '--all-logs on', which issues an 'unrecognizeable
argument' error (with a different error reporting path).
Stripping excess newlines is normal
paul j3 added the comment:
Do you realize that `choices` can be a dictionary? And since you want the user
to supply a key, not a value, you might not want to use a type that does the
conversion.
To illustrate consider two ways of using a simple dictionary.
import argparse
adict
paul j3 added the comment:
In the Help formatting,
choice_strs = [str(choice) for choice in action.choices]
The use of `repr` in this check_value() error message was, I think, deliberate.
For simple choices like strings and numbers it doesn't matter. But for other
cases, it may help
Paul Ganssle added the comment:
I'm glad that Terry brought up documentation, though, because I realized that
this is not a documented behavior:
https://docs.python.org/3/library/datetime.html#datetime.date.isocalendar
We should maybe document it? Though if we document it it might
Paul Ganssle added the comment:
Even if it were accidental (and it wasn't — it was actually somewhat difficult
to achieve), I'd still argue for not changing it in 3.9, because it would mean
that pickles created in 3.9.(n+1) would not be readable in 3.9.n.
Still, I don't think I'd
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
Yeah, people are very confused by this, which is why I wrote that article.
Maybe there is a place for big warnings somewhere? I have been mulling over the
possibility of proposing a backwards-incompatible (though minimally so,
hopefully) change to arithmetic
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +21805
pull_request: https://github.com/python/cpython/pull/22863
___
Python tracker
<https://bugs.python.org/issue42
New submission from Paul Ganssle :
Following up on this year's language summit, I would like to propose that we
start integrating property tests into the standard library. Zac Hatfield-Dodds
(along with myself and Carl Friedrich Bolz-Tereick) have put together this
repository of tests
paul j3 added the comment:
argparse : allow_abbrev behavior between 3.7 and 3.8
https://bugs.python.org/issue41534
covers this issue well enough. That latest change to `allow_abbrev` was
prompted by:
argparse: allow_abbrev=False stops -vv from working
https://bugs.python.org/issue26967
Paul Moore added the comment:
New changeset 5ab27cc518f614a0b954ff3eb125290f264242d5 by Paul Moore in branch
'master':
bpo-42041: Clarify how subprocess searches for the executable (GH-22715)
https://github.com/python/cpython/commit/5ab27cc518f614a0b954ff3eb125290f264242d5
Paul Moore added the comment:
I like that, I've updated the PR accordingly.
--
___
Python tracker
<https://bugs.python.org/issue42041>
___
___
Python-bugs-list m
Paul Moore added the comment:
My biggest concern with the suggested wording (which in broad terms looks OK to
me) is that it reintroduces the issue with the redirector.
By specifically saying that the behaviour in `CreateProcess` applies, we lead
the user to the statement that the search
Paul Ganssle added the comment:
That's a reasonable enough objection, though what use case do you have for
storing the IsocalendarDate object? The main reason we switched to using a
named tuple like this was because the vast majority of uses of `isocalendar()`
that I saw were people doing
Paul Moore added the comment:
Exactly. Why isn't the current directory searched? Why isn't foo/bar searched
for on PATH? Why is it possible for the user to accidentally remove system
commands from PATH and lose access to them? Any system is confusing and
surprising to users only familiar
Paul Moore added the comment:
Well, I'm not convinced that using `shutil.which` is the right answer for
anything other than "python". And even there, I'd recommend using
`sys.executable` over `shutil.which` in pretty much every case.
My view is that if we ignore the "weirdn
Paul Moore added the comment:
I don't think we should document this level of detail, both because it's
basically Windows standard behaviour and therefore not up to us to document,
and because it's *way* too overwhelming for the average user
Paul Moore added the comment:
OK, PR updated as per discussion.
--
___
Python tracker
<https://bugs.python.org/issue42041>
___
___
Python-bugs-list mailin
paul j3 added the comment:
A more recent issue shows that the use of a '*' positional in a
multually_exclusive_group is poorly understood and documented.
https://bugs.python.org/issue41854
That's part of why I am not enthusiastic about extending this to include
REMAINDER
paul j3 added the comment:
Give the positional a non-none default:
e.g.
group.add_argument('args', metavar='ARGUMENT', nargs='*', default=[],
help='arguments to PROGRAM')
Since a '*' or '?' positional works with an empty list of arguments, it is
"always
Paul Monson added the comment:
Yes.
On Fri, Oct 16, 2020 at 3:41 PM Irit Katriel wrote:
>
> Irit Katriel added the comment:
>
> Can this be closed?
>
> --
> nosy: +iritkatriel
>
> ___
> Python tracker
> &l
Paul Moore added the comment:
> We'd need Mark to weigh in (or possibly track down and ask a colleague), but
> I expect the assumption is that subprocess.Popen("python") searches PATH
> first.
I'm sure it was, TBH. The executable directory side of things is really jus
Paul Moore added the comment:
Python 3.6.9 and later were source-only security fix releases. We don't provide
*any* binary releases for those versions, the nuget distribution is no
different in that respect.
The release schedule for Python 3.6 is at
https://www.python.org/dev/peps/pep-0494
Paul Moore added the comment:
> This is still true, though, as much as it's ever been.
But it's *not*, if I understand the problem here. Windows resolves a bare
"python" command by searching the directory containing the running executable
first. I would reasonably assume t
Paul Moore added the comment:
Fair enough. I think we have to be careful here - people do rely on how the
"internal" aspects of virtual environments work, like it or not, and we've
definitely broken people's code in the past as a result of taking a hardline
"it's not docu
Paul Moore added the comment:
Eryk - I suggest that we modify (or remove) the note in venv that my PR adds as
part of such a change, rather than try to qualify the text now (which would
probably only make it harder for people to understand the issue
Paul Moore added the comment:
I've created https://github.com/python/cpython/pull/22715 as a suggested
documentation fix. Mark, does this cover what you would have needed to know?
Steve, is what I've written technically accurate?
--
stage: patch review
Change by Paul Moore :
--
keywords: +patch
pull_requests: +21683
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22715
___
Python tracker
<https://bugs.python.org/issu
Paul Moore added the comment:
Agreed, this is just "normal Windows behaviour". It's definitely surprising and
non-obvious (I saw this issue and it never even occurred to me that this was
what was happening) so I'd support documenting it somewhere. My instinct is
that the
paul j3 added the comment:
Some StackOverFlow answers cusomizing this help method:
https://stackoverflow.com/questions/23936145/python-argparse-help-message-disable-metavar-for-short-options
https://stackoverflow.com/questions/18275023/dont-show-long-options-twice-in-print-help-from-argparse
paul j3 added the comment:
That method could be customized in a HelpFormatter subclass. There already are
several subclasses (documented), and writing your own is allowed, if not
actually encouraged.
https://docs.python.org/3/library/argparse.html#formatter-class
Adding an extra parameter
paul j3 added the comment:
I'm not following this request either, especially the colored part.
However, I can imagine adding a variable that gives the user full control over
the action-invocation. In:
argparse.HelpFormatter._format_action_invocation method.
Currently it accepts
Paul Moore added the comment:
I'm inclined to think that creating a venv from within another venv should be
allowed. Tools like pipx can result in *other* tools being run from within a
virtual environment, and I don't think it's good to disallow that usage - as an
example, I have virtualenv
paul j3 added the comment:
For ArgumentParser, prog is defined as:
prog - The name of the program (default: sys.argv[0])
The comment in the `add_subparsers` method is:
# prog defaults to the usage message of this parser, skipping
# optional arguments and with no "
Paul Ganssle added the comment:
New changeset 2e4dd336e5b50fd30947fdecb605ddcd71f7f6f5 by Zackery Spytz in
branch 'master':
bpo-30155: Add macros to get tzinfo from datetime instances (GH-21633)
https://github.com/python/cpython/commit/2e4dd336e5b50fd30947fdecb605ddcd71f7f6f5
paul j3 added the comment:
'store_true/false' are subclasses of 'store_const'. All have a 'nargs=0'
value. It's that value which explains their behavior. ('append_const' would
also fall in this category)
In [2]: parser = argparse.ArgumentParser()
In [3]: parser.add_argument('foo', action
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41684>
___
___
Python-bugs-list
Paul Ganssle added the comment:
Thanks Łukasz. Sorry I forgot to respond last time. We've had no feedback on
this whatsoever, and I think we've probably made the right choice, so we can go
ahead and call this resolved.
--
resolution: -> fixed
stage: patch review -> resolved
Paul Moore added the comment:
Yeah, apologies - I saw the email notification, but Eric removed me from the
nosy list (quite reasonably) and I didn't notice there had been extra
discussion :-(
If someone wants to re-open the issue, feel free
Paul Moore added the comment:
There is a bug in your program. You should not mutate the list while looping
over it.
--
nosy: +paul.moore
___
Python tracker
<https://bugs.python.org/issue41
Change by Paul Moore :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41774>
___
___
Paul Moore added the comment:
I think this reproduces the underlying issue:
>>> import zipfile
>>> from pathlib import Path
>>> p = zipfile.Path("tst.zip")
>>> Path("tst.zip").unlink()
Traceback (most recent call last):
File "&q
Paul Ganssle added the comment:
This is fixed in the 3.9 and master branches, it needs to be cherry-picked into
the 3.9.0 release (at Łukasz's discretion, of course).
Łukasz: If you cherry-pick GH-20965/GH-21876 into the 3.9.0 release, please
also cherry-pick GH-21907/GH-21912, since
Paul Ganssle added the comment:
I agree with Filipe here — I think the b32encode/b32decode tests were
originally written before subtests were available, and this PR has this and
other real improvements.
I understand why you'd want to have a policy of "no refactoring for its own
paul j3 added the comment:
I'm going to close this. 3.8 works as expected/documented, provided we use the
normal double dash protocol for long options. Single dash is best reserved
for single character options, where chaining is allowed.
--
stage: -> resolved
status: o
paul j3 added the comment:
When there are potential conflicts between arguments set by the main parser and
those set by a subparser, I often recommend giving the sub ones different
"dest" parameters. Then you can reconcile the different values after parsing.
There's not
paul j3 added the comment:
I've noted this behavior before.
https://bugs.python.org/issue27859
argparse - subparsers does not retain namespace
https://bugs.python.org/issue9351
argparse set_defaults on subcommands should override top level set_defaults
Due to a change 2012, the subparser
Change by Paul Madden :
--
nosy: +paul.madden
___
Python tracker
<https://bugs.python.org/issue33997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I think that we should re-examine this issue after GH-20472 is merged. I'm not
really sure how that will affect this and indeed *how* it should affect this. I
am not sure whether people are relying on the current behavior, or what use
cases would be improved
paul j3 added the comment:
In your first example:
In [29]: parser = argparse39.ArgumentParser(allow_abbrev=True)
In [30]: parser.add_argument('-o');
In [32]: parser.parse_known_args(['-o','test
Paul Moore added the comment:
Confirmed, CREATE_NO_WINDOW works - in my test I used it *with*
DETACHED_PROCESS.
Is it not a bug that the launcher doesn't respect the value of DETACHED_PROCESS
when calling the Python interpreter, though? If nothing else, it means that
there are differences
Paul Moore added the comment:
Originally discovered in https://github.com/pypa/virtualenv/issues/1928 - see
that issue for more context.
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Paul Moore :
The following code pops up an extra console window when run on Windows 10,
Python 3.8:
from subprocess import DETACHED_PROCESS, Popen
p = Popen(["py", "-c", "from time import sleep; sleep(5)"],
creationflags=DETACHED_PRO
paul j3 added the comment:
I'd say the problem is with the deployment tool. Inputs like that should be
split regardless of who's doing the commandline parsing. With normal shell
input, quotes are used to prevent splitting, or to otherwise prevent
substitutions and special character
Paul Moore added the comment:
I think the key point here is that os.path.join is *meant* to have
platform-native semantics, so it treats '{:' as a drive letter on Windows, but
Linux doesn't have drive letters, so os.path.join treats '{:' as a normal part
of a filename on Linux
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +21023
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21907
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
There are two refleaks here. One is a reference leaking to the weak cache in
`__init_subclass__` (one leak every time a subclass is created), and the other
is that when `subclass.clear_cache()` is called, it sets `ZONEINFO_STRONG_CACHE
= NULL`, thus causing
Paul Ganssle added the comment:
Marking as release blocker to put it on the checklist. Feel free to demote it
if you decide it should be deferred to 3.9.1.
--
priority: high -> release blocker
resolution: -> fixed
___
Python tracker
Change by Paul Ganssle :
--
stage: patch review -> backport needed
___
Python tracker
<https://bugs.python.org/issue41025>
___
___
Python-bugs-list mai
Paul Ganssle added the comment:
Łukasz: Would it be possible to backport / cherry-pick the changes from PR
GH-21876 (https://github.com/python/cpython/pull/21876) into the 3.9.0 branch?
I think this is a fairly severe issue considering that pendulum is planning to
use a zoneinfo subclass
Paul Ganssle added the comment:
New changeset 33d3c64095bcdf9066a3441f6dda5d2e2f4118a8 by Miss Islington (bot)
in branch '3.9':
bpo-41025: Fix subclassing for zoneinfo.ZoneInfo (GH-20965) (GH-21876)
https://github.com/python/cpython/commit/33d3c64095bcdf9066a3441f6dda5d2e2f4118a8
Paul Ganssle added the comment:
New changeset 87d8287865e5c9f137f6b5cf8c34c2c509eb5e9d by Paul Ganssle in
branch 'master':
bpo-41025: Fix subclassing for zoneinfo.ZoneInfo (GH-20965)
https://github.com/python/cpython/commit/87d8287865e5c9f137f6b5cf8c34c2c509eb5e9d
Paul Ganssle added the comment:
By the way, it might be easiest to start with a PR against backports.zoneinfo,
because I have a lot more linting, coverage and format checks set up there:
https://github.com/pganssle/zoneinfo
--
___
Python tracker
Paul Ganssle added the comment:
I think that `ZoneInfo('__init__.py')` is also a problem, but a slightly
different one. That comes from the fact that in order to support
`importlib.resources`, each of the zoneinfo subdirectories needs an
`__init__.py`, but the ZoneInfo constructor should
Paul Ganssle added the comment:
Now that issue #16995 is resolved, I think we can move forward with updating
the text.
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue36
Paul Ganssle added the comment:
Thanks Filipe!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.8
___
Python tracker
<https://bugs.python.or
Paul Moore added the comment:
https://docs.python.org/3.9/using/windows.html should probably be updated:
"""
As specified in PEP 11, a Python release only supports a Windows platform while
Microsoft considers the platform under extended support. This means that Python
3.9 s
Paul Ganssle added the comment:
I think for now skipping the tests when lzma is missing is the easiest thing,
though another option would be to drop the compression on the input test data
so that the tests don't depend on lzma.
Taking a look at the data files, it looks like we get around 50
paul j3 added the comment:
This is the result of how default values are handled with '?' (and '*') nargs.
At the start of nested `take_action` function (which handles all actions) is
this code:
argument_values = self._get_values(action, argument_strings)
# error
Paul Moore added the comment:
Understood that these would be duplicates, and I certainly don't want to put
more pressure on you, but I think there would still be value in having a known
reporting channel for people to say "I am also affected by this":
* MS Developers get a more
Paul Ganssle added the comment:
I think it is unlikely that we'll want to experiment with this directly in
CPython. I don't think a fixed format (other than the annoying one that you
already get from calling `str` on a timedelta) is appropriate, but designing a
modular format for time
Paul Ganssle added the comment:
Hi dh4931 — this is the expected result, assuming that the offsets changed
between those two dates in your system local time.
The .timestamp() method returns an epoch time, which is the number of seconds
since 1970-01-01T00:00:00 UTC, and so it is inherently
Paul Moore added the comment:
I thought that might be the answer. But does anyone know where I can repost
this as an issue against the Store distribution? I'm happy to report there if I
can find out how...
Hopefully Steve can point me in the right direction
Paul Moore added the comment:
See, for example, https://github.com/pypa/packaging-problems/issues/379 as an
illustration of the user (and project maintainer!) confusion this causes.
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Paul Moore :
First of all, I do know that this is an issue with the Windows Store
distribution, rather than the python.org one. But (a) I don't know where to
report a bug against the Store implementation except here, and (b) it's
arguably a case of the Windows
paul j3 added the comment:
I just realized if the subparser argument used
default=argparse.SUPPRESS
it would not clobber values (default or user) set by the main parser.
(a 'store_true' would have to be replaced with a 'store_const' to do
Paul Ganssle added the comment:
Oops, just realized my previous post said `pip install distutils`. I meant to
say that `pip install setuptools` will provide the `distutils` module (right
now you do `import setuptools; import distutils` and you get the
setuptools-provided version; we're
Paul Ganssle added the comment:
> I don't think it's a good idea to replace bad habits from distutils with bad
> habits in setuptools._distutils. And this is exactly what you get with
> pointing directly to setuptools.
These are two different questions. We're not asking people t
Paul Ganssle added the comment:
> So what is the plan to continue to support building cpython itself which
> depends on Distutils? Currently the build bootstraps itself without the aid
> of an existing Python interpreter instance. There would also be major impacts
> across the w
paul j3 added the comment:
The docs could change
"catch errors manually"
to
"catch ArgumentError manually"
But while 'argparse.ArgumentError' is imported, it is not documented. We have
to study the code to learn when it is raised.
Its class def:
def __i
paul j3 added the comment:
For custom handling of unrecognized arguments, use parser_known_args(). You
don't need this new parameter.
--
___
Python tracker
<https://bugs.python.org/issue41
paul j3 added the comment:
I didn't pay attention to the patch that added this "exit_on_error" parameter.
So I don't know exactly what error handling it was supposed to handle or why.
But given the location of the code change, it does not handle every possible
error.
Specifi
Paul Ganssle added the comment:
I think a positional-only argument would be the best option if we could do it,
but it would be a backwards-incompatible change and it's probably not worth the
hassle.
If anyone is using the keyword argument, they're probably using `format=`
rather than `fmt
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue41136>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
As for deciding between moving to `datetime/` and moving to `_pydatetime`, I
think we should send an e-mail to Python-Dev about it to get a wider
perspective, because the import machinery is a lot of black magic, and I know
that there are large proprietary
Paul Ganssle added the comment:
> bout _strptime, I see that the time.strptime() imports internally the
> _strptime module.
Ah, sorry, my remark about including `_strptime` was off the cuff — I thought
it was only used in `datetime`, which is why I said "possibly _strptime"
Paul Ganssle added the comment:
There's a pretty clear warning on the documentation that utcfromtimestamp is
unsuitable for this purpose:
https://docs.python.org/3/library/datetime.html#datetime.datetime.utcfromtimestamp
What you want is a datetime that knows what time zone it's in, so
Paul Ganssle added the comment:
New changeset 6c56356109616ea1292aafa48d30536279ec0937 by Paul Ganssle in
branch '3.9':
[3.9] bpo-41056: Fix a possible MemoryError leak within zoneinfo. (GH-21007)
https://github.com/python/cpython/commit/6c56356109616ea1292aafa48d30536279ec0937
paul j3 added the comment:
No, parameters like `type` let the developer control what his users provides.
Violating that produces a runtime error, and exit.
But in general argparse does not try to control values that the developer uses.
There's plenty of time during development to catch
Paul Ganssle added the comment:
New changeset bc43f6e21244f31d25896875430174cd4ac7604c by Ram Rachum in branch
'master':
bpo-41065: Use zip-strict in zoneinfo (GH-21031)
https://github.com/python/cpython/commit/bc43f6e21244f31d25896875430174cd4ac7604c
Change by Paul Ganssle :
--
nosy: +p-ganssle
nosy_count: 3.0 -> 4.0
pull_requests: +20249
pull_request: https://github.com/python/cpython/pull/21083
___
Python tracker
<https://bugs.python.org/issu
Change by paul j3 :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41047>
___
___
Python-bugs-
paul j3 added the comment:
It is an old unresolved issue (which resurfaced a few months ago)
https://bugs.python.org/issue9625
argparse: Problem with defaults for variable nargs when using choices
--
resolution: -> duplicate
___
Python trac
paul j3 added the comment:
The error is raised in ._get_values with this section:
# when nargs='*' on a positional, if there were no command-line
# args, use the default if it is anything other than None
elif (not arg_strings and action.nargs == ZERO_OR_MORE
Change by Paul Ganssle :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue41059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +20143
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20965
___
Python tracker
<https://bugs.python.org/issu
New submission from Paul Ganssle :
In the C implementation of zoneinfo.ZoneInfo, __init_subclass__ is not declared
as a classmethod, which prevents it from being subclassed. This was not noticed
because the tests for ZoneInfo subclasses in C are actually testing
zoneinfo.ZoneInfo
Paul Menzel added the comment:
Wow, great job in figuring this out. Passing the context, it works here too.
I just wanted to add, that I looked at this with Wireshark, and to not
complicate things, first tried plain HTTP.
```
$ curl http://jitsi.molgen.mpg.de
301 Moved Permanently
301
New submission from Paul Menzel :
Having the TURN server Coturn [1] set up in a Jitsi Meet installation, Python’s
urllib requests fail, while it works with cURL and browsers.
```
$ curl -I https://jitsi.molgen.mpg.de
HTTP/2 200
server: nginx/1.14.2
date: Sat, 13 Jun 2020 11:09:19 GMT
content
301 - 400 of 3183 matches
Mail list logo
