Paul Ganssle added the comment:
The evidence you have here seems pretty compelling and this change seems
straightforward enough. I don't see an expert listed here, but I'm happy to
merge a docs PR fixing this.
Probably a good idea to make a PR to typeshed in parallel, in case
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue43382>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
Apparently something is wrong with make install for beta 1 and the `zoneinfo`
module is not installed with it (only _zoneinfo).
When I run a local build `./python -c "import zoneinfo"` works, but when I do
`make install` I get ImportError:
$ b
Paul Ganssle added the comment:
I think I found the problem: these directories are not included in the
Makefile.pre.in LIBSUBDIRS variable:
https://github.com/python/cpython/blob/a355a06fcc7ef2232736dceb012ae623335cd7ab/Makefile.pre.in#L1373
PR incoming
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +19520
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20229
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
Victor: Might be worth updating your notes to indicate that any subdirectory
(not just test subdirectories) need to go into LIBSUBDIRS. zoneinfo uses a
subdirectory for both the tests and the zoneinfo module, and *neither* were
included in the installation in
Paul Ganssle added the comment:
New changeset 2abededbc4165d2daa14ae9d74b1f33cce0593d7 by Paul Ganssle in
branch 'master':
bpo-40683: Add zoneinfo to LIBSUBDIRS (#20229)
https://github.com/python/cpython/commit/2abededbc4165d2daa14ae9d74b1f3
Paul Ganssle added the comment:
Victor has confirmed that this is working on Windows, so I think the current
state of the 3.9 and master branches is now fixed.
The last question remaining is whether this justifies a quick b2 release (or if
there's another mechanism for a "fixup&quo
Paul Ganssle added the comment:
No worries Łukasz, I figured it would be worth bringing up because normally the
releases aren't so broken that they aren't usable in the common case. That
said, this won't break any *existing* code, it'll just prevent people on Linux
Paul Moore added the comment:
PR looks good to me. There's a test failure that needs fixing and the PR needs
a news entry, but otherwise looks fine.
--
___
Python tracker
<https://bugs.python.org/is
Change by Paul Ganssle :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue40705>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
This is a duplicate of bpo-40714. It's a bit of an overzealous compiler warning
(as far as I can tell it's not true that the uninitialized value would ever be
used), but we fixed it anyway in GH-20291.
Thanks for the report!
--
nosy:
Paul Ganssle added the comment:
New changeset 06a1b8915d6674e40f0dccc422ca2c06212392d8 by Ammar Askar in branch
'master':
bpo-40705: Fix use-after-free in _zoneinfo's module_free (GH-20280)
https://github.com/python/cpython/commit/06a1b8915d6674e40f0dccc42
New submission from paul rubin :
The IDLE documentation is in https://docs.python.org/3/library/idle.html which
is not where I'd have thought to look for it, since I think of IDLE as an
application rather than a library. So I looked for it on the main docs page,
docs.python.org, and d
New submission from paul rubin :
This is in the standard python 3.7.3 install under Debian 10. It's possible
that this is on purpose, and it's (separately) possible that the Debian
packagers did this for some reason. I'm not sure it's a bug but am reporting
it as it&#x
Change by paul rubin :
--
title: mention IDLE in main python ocs page -> mention IDLE in main python docs
page
___
Python tracker
<https://bugs.python.org/issu
paul rubin added the comment:
I think I used duckduckgo to find the docs. They don't change much between
versions and I was trying to find how to do a specific thing. My installation
has the docs included but it didn't explain how to do what I wanted, so I had
hoped there
paul rubin added the comment:
Matthias, I get the same result you do when I run python from the shell command
line. I see /usr/bin in the path when I import sys and print sys.path from
inside IDLE. In other words this is an IDLE configuration oddity. Again I
don't know if it&#x
paul rubin added the comment:
I'm using Debian 10 MATE live install and have been running IDLE by clicking an
icon on the top panel, but I just tried running IDLE from the shell prompt in a
terminal window, and also see /usr/bin in the path. In both cases, the output
of os.system
paul rubin added the comment:
Yes as mentioned I'm running Debian GNU/Linux, not Windows. By "idle is
installed in /usr/bin" I mean that it is an executable shell script stored at
/usr/bin/idle . Yes, shell prompt is the $ prompt to bash. When I run
"python3 -m idl
Paul Ganssle added the comment:
I basically agree with this — this is one of the reasons I structured the
zoneinfo module the way I did rather than mimicking the pattern in datetime.
I believe that there are other modules that have similar situations like heapq,
but datetime is probably the
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue40777>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +19849
pull_request: https://github.com/python/cpython/pull/20624
___
Python tracker
<https://bugs.python.org/issue40
Paul Moore added the comment:
Because if you open a file in text mode (without "b" in the mode), Python
writes \n (newline) characters as \r\n (carriage return, line feed) which are
the Windows textfile representation of "Newline".
>From the documentation of the b
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue40862>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue40615>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
This is a duplicate of bpo-13305 and is due to platform-specific
implementations of %Y. On Linux, `strftime()` does not zero-pad to 4, and if
you need to represent years <1000, you should use "%4Y" to zero-pad the output.
I think the ideal resolu
New submission from Paul Ganssle :
While developing a shim for deprecating pytz, I discovered this issue with the
Pacific/Rarotonga zone:
>>> from datetime import datetime, timedelta
>>> from backports.zoneinfo import ZoneInfo
>&
New submission from Paul Ganssle :
Apparently in 1938, Madrid had a "double daylight saving time", where they
transitioned from WET (+0) → WEST (+1) → WEMT (+2) → WEST (+1) → WET (+0):
$ zdump -V -c 1938,1940 'Europe/Madrid'
Europe/Madrid Sat Apr 2 22:59:59 1938 UT = Sat
New submission from Paul Ganssle :
Related to bpo-40930 and bpo-40931, it *seems* that in 1942 only,
`zoneinfo.ZoneInfo` returns -01:00 for DST in Europe/Minsk:
>>> from datetime import datetime, timedelta
>>> from backports.zoneinfo import ZoneInfo
>>>
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
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 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, not a
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
Change by Paul Ganssle :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue41059>
___
___
Python-bugs-list mailing list
Unsubscribe:
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_O
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
Change by paul j3 :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41047>
___
___
Python-bugs-
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
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/bc43f6e21244f31d25896875430174
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
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/6c56356109616ea1292aafa48d3053
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 i
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:
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
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:
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
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
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/is
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:
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 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 ask
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&#x
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_co
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 t
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
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 dire
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 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 forma
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
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)
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 arou
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:
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 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:
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 construc
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:
New changeset 87d8287865e5c9f137f6b5cf8c34c2c509eb5e9d by Paul Ganssle in
branch 'master':
bpo-41025: Fix subclassing for zoneinfo.ZoneInfo (GH-20965)
https://github.com/python/cpython/commit/87d8287865e5c9f137f6b5cf8c34c2
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/33d3c64095bcdf9066a3441f6dda5d
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
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:
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
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 a
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 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 par
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
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 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
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 differ
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([
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 imp
Change by Paul Madden :
--
nosy: +paul.madden
___
Python tracker
<https://bugs.python.org/issue33997>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 subp
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 nothi
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
stat
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 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 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
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:
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
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
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 ->
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41684>
___
___
Python-bugs-list
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.ArgumentParse
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/2e4dd336e5b50fd30947fdecb605dd
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 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
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 accept
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:
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
801 - 900 of 3005 matches
Mail list logo
