[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`
Matt Wozniski added the comment: > My main hesitation with this name is that I suspect users may think that > `use_utc_designator` means that they *unconditionally* want to use `Z` — > without reading the documentation (which we can assume 99% of users won't do) I was thinking along similar lines when I used `use_utc_designator` in the PR, but I drew a different conclusion. I was thinking that the name `use_utc_designator` is sufficiently abstruse that no one would even be able to guess that it's referring to "Z" without actually reading the documentation for the parameter. In particular, I worry that `zulu=True` or `allow_Z=True` might lead people to make the mistake of thinking that they'll always get "Z" instead of "+00:00". > A name like `utc_as_z` is definitely less... elegant, but conveys the concept > a bit more clearly. This would definitely be more memorable and more approachable. If we stick with making it conditional on `tzname() == "UTC"`, I definitely think we want to have "utc" in the name of the parameter, and `utc_as_z` satisfies that. `utc_as_z` seems reasonable to me. Let me know if you'd like me to update the PR. -- ___ Python tracker <https://bugs.python.org/issue46614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`
Change by Matt Wozniski : -- keywords: +patch pull_requests: +30131 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32041 ___ Python tracker <https://bugs.python.org/issue46614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39829] __len__ called twice in the list() constructor
Matt Wozniski added the comment: Pardon me for necroing an old issue, but someone pointed out the surprising behavior of `__len__` being called twice by `list(iterable)`, and it caught my curiosity. https://github.com/python/cpython/commit/372d705d958964289d762953d0a61622755f5386 made it so that `list.__init__(iterable)` calls `iterable.__len__()` before calling `list.extend()`, to preallocate exactly the right amount of space, rather than allowing `list.extend()` to grow the array. That's because `list.extend()` can over-allocate. What if instead, we made it so that `list.extend(iterable)` doesn't over-allocate when called on an empty list? In the two places where `list_extend` calls `list_resize` to grow the array, we'd check if `self->ob_item == NULL` and if so call `list_preallocate_exact` instead, and we'd remove the call to `list_preallocate_exact` from `list___init___impl`. It seems like that ought to achieve the same goal as making `__init__` call preallocate exactly, without requiring the extra call to `__len__`. -- nosy: +godlygeek ___ Python tracker <https://bugs.python.org/issue39829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`
Matt Wozniski added the comment:
> I feel like "If the offset is 00:00, use Z" is the wrong rule to use
> conceptually
This is a really good point that I hadn't considered: `+00:00` and `Z` are
semantically different, and just because a datetime has a UTC offset of 0
doesn't mean it should get a `Z`; `Z` is reserved specifically for UTC.
It seems like the most semantically correct thing would be to only use `Z` if
`tzname()` returns exactly "UTC". That would do the right thing for your London
example for every major timezone library I'm aware of:
>>> datetime.datetime.now(zoneinfo.ZoneInfo("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(zoneinfo.ZoneInfo("UTC")).tzname()
'UTC'
>>> datetime.datetime.now(datetime.timezone.utc).tzname()
'UTC'
>>> datetime.datetime.now(dateutil.tz.gettz("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(dateutil.tz.UTC).tzname()
'UTC'
>>> datetime.datetime.now(pytz.timezone("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(pytz.UTC).tzname()
'UTC'
I think the right rule to use conceptually is "if `use_utc_designator` is true
and the timezone name is 'UTC' then use Z". We could also check the offset, but
I'm not convinced we need to.
--
nosy: +godlygeek
___
Python tracker
<https://bugs.python.org/issue46614>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
Matt Wozniski added the comment: I agree with Brett. Adding `allow_z` (or perhaps `compact` or `use_utc_designator` if we're bikeshedding) as an optional keyword only argument to `.isoformat()` would allow us to keep the explanation that what `.fromisoformat()` can parse is exactly what `.isoformat()` can produce, while giving a feature to `.fromisoformat()` that many have asked for and that would have minimal overhead in terms of code complexity or runtime performance. Would you accept a PR that implements that, Paul? -- nosy: +godlygeek ___ Python tracker <https://bugs.python.org/issue35829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45982] Bug in Error messages
Matt Wozniski added the comment: > Syntactically, this could be many possible errors: missing comma, missing > period, missing parens, missing brackets, etc. Syntactically, it cannot be a missing comma. Adding the comma is a syntax error. $ python3 -c 'if datetime.now(),strftime(...) != "19:50:00": pass' File "", line 1 if datetime.now(),strftime(...) != "19:50:00": pass ^ SyntaxError: invalid syntax Granted this is a heuristic, but it would be nice if it was able to not suggest a change that it would reject as syntactically incorrect. -- nosy: +godlygeek ___ Python tracker <https://bugs.python.org/issue45982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45675] pkgutil.get_data() doesn't add subpackages to parent packages when importing
Matt Wozniski added the comment:
I wondered if it would be backwards compatible to make `pkgutil.get_data()`
delegate to `importlib.resources.read_binary()`. It isn't, because
`pkgutil.get_data()` accepts a relative path for the resource, and
`importlib.resources.read_binary()` accepts only a filename. That is, you can
do:
pkgutil.get_data(__name__, "subdir/some_file")
but not:
importlib.resources.read_binary(__name__, "subdir/some_file")
The latter fails with:
File "/opt/bb/lib/python3.10/importlib/_common.py", line 34, in
normalize_path
raise ValueError(f'{path!r} must be only a file name')
--
___
Python tracker
<https://bugs.python.org/issue45675>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45675] pkgutil.get_data() doesn't add subpackages to parent packages when importing
Matt Wozniski added the comment: The original case where I encountered this was with a namespace package, but the behavior appears to be the same for a subpackage of a regular package. -- title: pkgutil.get_data() doesn't add subpackages to namespaces when importing -> pkgutil.get_data() doesn't add subpackages to parent packages when importing ___ Python tracker <https://bugs.python.org/issue45675> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45675] pkgutil.get_data() doesn't add subpackages to namespaces when importing
New submission from Matt Wozniski :
If a module hasn't yet been imported, `pkgutil.get_data(pkg_name, data_file)`
will import it, but when it does, it doesn't add the submodule to its parent
package when the parent package is a PEP 420 implicit namespace package.
```
$ mkdir -p namespace/package
$ touch namespace/package/__init__.py
$ echo data >namespace/package/data_file
$ python3.10 -c 'import namespace.package, pkgutil;
print(pkgutil.get_data("namespace.package", "data_file")); import namespace;
print(namespace.package)'
b'data\n'
$ python3.10 -c 'import pkgutil; print(pkgutil.get_data("namespace.package",
"data_file")); import namespace.package; import namespace;
print(namespace.package)'
b'data\n'
Traceback (most recent call last):
File "", line 1, in
AttributeError: module 'namespace' has no attribute 'package'
$
```
In this reproducer, we've got an implicit namespace package called "namespace"
and a regular package inside it called "namespace.package". The regular package
has a data file called "data_file".
If we import the regular package and then call pkgutil.get_data() to access the
data file, it successfully retrieves the data file, and the module object for
the namespace package winds up with an attribute referencing the module object
for the regular package.
If we call pkgutil.get_data() to access the data file before importing the
regular package, it successfully retrieves the data file, but the module object
for the namespace package doesn't have an attribute referencing the module
object for the regular package, even if we later do a normal import for the
regular package.
It looks like pkgutil is importing the module when it hasn't already been
imported (which I would expect) and adding it and any parent packages to
sys.modules (which I would also expect), but then not adding submodules as
attributes to their parent modules like `import` would (which seems like a bug).
--
components: Library (Lib)
messages: 405331
nosy: godlygeek, pablogsal
priority: normal
severity: normal
status: open
title: pkgutil.get_data() doesn't add subpackages to namespaces when importing
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45675>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45325] Allow "p" in Py_BuildValue
Matt Wozniski added the comment: > "!value" or "!!value" also has the issue if I understood correctly. No, just as "value != 0" is an int, so is "!value". -- ___ Python tracker <https://bugs.python.org/issue45325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45325] Allow "p" in Py_BuildValue
Matt Wozniski added the comment: The leftmost argument of the ternary is an int for every example that Victor and I found in the stdlib, so no casting would be required in any of these cases. -- ___ Python tracker <https://bugs.python.org/issue45325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45325] Allow "p" in Py_BuildValue
Matt Wozniski added the comment:
I spotted three other uses in the stdlib:
Modules/_io/_iomodule.c
raw = PyObject_CallFunction(RawIO_class, "OsOO",
path_or_fd, rawmode,
closefd ? Py_True : Py_False,
opener);
wrapper = PyObject_CallFunction((PyObject *)_Type,
"OsssO",
buffer,
encoding, errors, newline,
line_buffering ? Py_True : Py_False);
Modules/_sqlite/connection.c
if (PySys_Audit("sqlite3.enable_load_extension",
"OO", self, onoff ? Py_True : Py_False) < 0) {
return NULL;
}
--
___
Python tracker
<https://bugs.python.org/issue45325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45325] Allow "p" in Py_BuildValue
Matt Wozniski added the comment: > but there is a catch -- the arguments should be a C int Or a type that promotes to int. If you pass a C short or char, or a C++ bool, it is implicitly promoted to int. > so you will need to write "expr ? 1 : 0" Or alternatively "!!expr" > which is not much better than "expr ? Py_True : Py_False" I had to write that recently after reading through the Py_BuildValue docs twice to make sure I wasn't missing a format code I could use. It's a strange omission, especially because 'p' exists for PyArg_Parse. I'd very much like to see this change. -- nosy: +godlygeek ___ Python tracker <https://bugs.python.org/issue45325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17140] Document multiprocessing.pool.ThreadPool
Change by Matt Wozniski : -- keywords: +patch nosy: +godlygeek nosy_count: 7.0 -> 8.0 pull_requests: +22673 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23812 ___ Python tracker <https://bugs.python.org/issue17140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38894] Path.glob() sometimes misses files that match
Matt Wozniski added the comment:
A simple test case for this issue:
~>mkdir tmp
~>cd tmp
tmp>touch 1.txt
tmp>ln -s subdir/file 2.txt
tmp>touch 3.txt
tmp>ls -l
total 0
-rw-rw-r-- 1 mwoznisk general 0 Mar 6 14:52 1.txt
lrwxrwxrwx 1 mwoznisk general 11 Mar 6 14:52 2.txt -> subdir/file
-rw-rw-r-- 1 mwoznisk general 0 Mar 6 14:52 3.txt
tmp>python3.8 -c "import pathlib; print(list(pathlib.Path('.').glob('*')))"
[PosixPath('1.txt'), PosixPath('2.txt'), PosixPath('3.txt')]
tmp>mkdir subdir
tmp>python3.8 -c "import pathlib; print(list(pathlib.Path('.').glob('*')))"
[PosixPath('1.txt'), PosixPath('2.txt'), PosixPath('3.txt'),
PosixPath('subdir')]
So far so good, but if the subdirectory isn't readable, things fall apart:
tmp>chmod 000 subdir
tmp>python3.8 -c "import pathlib; print(list(pathlib.Path('.').glob('*')))"
[PosixPath('1.txt')]
Looks like this is caused by entry.is_dir() in pathlib._WildcardSelector
raising a PermissionError when trying to check if a symlink pointing into an
unreadable directory is or isn't a directory. EACCESS isn't in IGNORED_ERROS
(sic) and so the loop over directory entries is broken out of, and the "except
PermissionError:" block in _select_from swallows the exception so that the
failure is silent.
--
nosy: +Matt Wozniski
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue38894>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
