[issue43858] Provide method to get list of logging level names

[Andrei Kulakov]

Change by Andrei Kulakov :


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

___
Python tracker 

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

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

[Eryk Sun]

Eryk Sun  added the comment:

Michael, thank you for the PR, but please associate it with the existing issue 
bpo-24505.

--
nosy: +eryksun
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> shutil.which wrong result on Windows
versions:  -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

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

[Michael Hirsch, Ph.D.]

Michael Hirsch, Ph.D.  added the comment:

Correction:

Example: on Windows if ./foo.exe exists, then shutil.which('./foo') returns 
None.

--

___
Python tracker 

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

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

[Michael Hirsch, Ph.D.]

Change by Michael Hirsch, Ph.D. :


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

___
Python tracker 

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

[issue44270] shutil.which: does not find path/cmd.ext where ext is not given

[Michael Hirsch, Ph.D.]

New submission from Michael Hirsch, Ph.D. :

The early short-circuit logic in shutil.which() when cmd includes a directory 
component incorrectly gives None on Windows if the correct filename suffix was 
not also given.

Example: on Windows if ./foo.exe exists, then shutil.which('./foo.exe') returns 
None.

--
components: Library (Lib)
messages: 394784
nosy: michael2
priority: normal
severity: normal
status: open
title: shutil.which: does not find path/cmd.ext where ext is not given
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 

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

[issue44206] Add a version number to dict keys.

[Inada Naoki]

Inada Naoki  added the comment:

Can we close this issue?

--

___
Python tracker 

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

[issue43964] ctypes CDLL search path issue on MacOS

[Ned Deily]

Ned Deily  added the comment:

Thanks for the report! I've spent some time investigating it and the story 
behind it turns out to be a bit complicated, so bear with me. It's all tied in 
to Apple's attempts to improve the security of macOS.

As of macOS 10.15 Catalina, Apple introduced new requirements for downloadable 
installer packages, like those we provide for macOS on python.org; in order for 
such packages to be installed with the macOS installer, they would now have to 
be "notarized" by Apple. The notarization process is somewhat similar in 
concept to the process that an app has to go through to be submitted to the Mac 
App Store but with less stringent requirements. In particular, the installer 
package is automatically inspected to ensure that all executables are 
codesigned, are linked with the more-secure "hardened runtime", and do not 
request certain less-secure entitlements. Although originally announced for 
enforcement starting with the release of Catalina in the fall of 2019, Apple 
delayed the enforcement until February 2020 to give application developers more 
time to modify their packages to meet the new requirements. (See, for example, 
https://developer.apple.com/news/?id=12232019a).

The first python.org macOS installers that conformed to the new requirements 
and were notarized were for the 3.8.2 and 3.7.7 releases, staring in 2020-02. 
In those first releases, we used two entitlements:

com.apple.security.cs.disable-library-validation
com.apple.security.cs.disable-executable-page-protection

Some issues were reported (like Issue40198) when using those first releases, so 
we added two additional entitlements for subsequent releases:

com.apple.security.automation.apple-events
com.apple.security.cs.allow-dyld-environment-variables

While we didn't realize it until your issue, that did have an effect on ctype's 
behavior when trying to find shared libraries and frameworks. Using the 
hardened runtime, as now required for notarization, causes the system dlopen() 
interface, which ctypes uses, to no longer search relative paths. The dlopen 
man page (for macOS 11, at least) includes this warning:

  Note: If the main executable is a set[ug]id binary or codesigned with
  entitlements, then all environment variables are ignored, and only a
  full path can be used.

After some experimentation, it looks like that statement isn't exactly correct 
at least on macOS 11 Big Sur: unprefixed paths can still be used to find 
libraries and frameworks in system locations, i.e. /usr/lib and 
/System/Library/Frameworks. But it is true that, when using the hardened 
runtime, dlopen() no longer searches the user-controlled paths /usr/local/lib 
or /Library/Frameworks by default. And there apparently is no way for a 
notarized executable to revert to the previous behavior by adding other 
entitlements (https://developer.apple.com/forums/thread/666066).

With the allow-dyld-environment-variables entitlement included after the 
initial releases, it *is* now possible to change this behavior externally, if 
necessary, by explicitly setting the DYLD_LIBRARY_PATH and/or 
DYLD_FRAMEWORK_PATH environment variables (see man 1 dyld).

To demonstrate using a third-party library in /usr/local/lib (similar results 
with third-party frameworks in /Library/Frameworks):

# -- python.org 3.7.6, not codesigned --
$ /usr/local/bin/python3.7
Python 3.7.6 (v3.7.6:43364a7ae0, Dec 18 2019, 14:18:50)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary('libsodium.dylib')


# -- python.org 3.7.7, first notarized release --
$ /usr/local/bin/python3.7
Python 3.7.7 (v3.7.7:d7c567b08f, Mar 10 2020, 02:56:16)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary('libsodium.dylib')
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py",
 line 442, in LoadLibrary
return self._dlltype(name)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py",
 line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(libsodium.dylib, 6): no suitable image found.  Did find:
file system relative paths not allowed in hardened programs

$ DYLD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python3.7
Python 3.7.7 (v3.7.7:d7c567b08f, Mar 10 2020, 02:56:16)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary('libsodium.dylib')
[...]
OSError: dlopen(libsodium.dylib, 6): no suitable image found.  Did find:
file system relative paths not allowed in hardened programs


# -- python.org 3.7.8 and beyond including 3.9.x --
$ /usr/local/bin/python3.7
Python 3.7.

[issue44262] tarfile: some content different output

[Filipe Laíns]

Filipe Laíns  added the comment:

Yeah, I understand. What you want is achieved by making sure the mtime from the 
tar archive, and files on the archive, is reproducible, like I demonstrated 
here.

Can this be closed?

--

___
Python tracker 

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

[issue44262] tarfile: some content different output

[Vasco Gervasi]

Vasco Gervasi  added the comment:

Dear Filipe,
sorry I did not explaing the use case, obiously this is a toy example to show 
my problem.
So I have pipeline, that from a repository generate a tar file, using a python 
script; if the hash of the tar file is different it will trigger other things.
As you can imagine each time the pipeline is run, the content is the same (if 
same commit) but the files timestamps are different and so the tar is different.

Thanks for pointing out that examples, I will check and let you know.

Thanks

--

___
Python tracker 

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

[issue44269] smtplib AUTH command doesn't handle EAI arguments

[John L]

New submission from John L :

In an EAI (SMTPUTF8) mail session, AUTH usernames and passwords can be UTF-8, 
not just ASCII.

The fix is easy.  In smtplib.py, in three places in the auth() and 
auth_cram_md5() routines change ".encode('ascii')" to 
".encode(self.command_encoding)"

I have tried this with EAI mail servers in India and China to be sure it works.

--
components: Library (Lib)
messages: 394779
nosy: jrlevine
priority: normal
severity: normal
status: open
title: smtplib AUTH command doesn't handle EAI arguments
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Anthony Sottile]

Anthony Sottile  added the comment:

I have also shown that the performance is indeed not better in the nominal 
case, as demonstrated in the first case

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Anthony Sottile]

Anthony Sottile  added the comment:

the toil is still present, the existing, good apis are deprecated and the new, 
bad apis are slow -- and the odd subclasses are still present

--

___
Python tracker 

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

[issue44268] gettext: deprecate selecting plural form by fractional numbers (part 2)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Pablo, can we add these warnings in 3.10?

Thanks for checking! Yeah, I think it makes sense to go ahead adding these 
warnings to 3.10 . Please, add me as a reviewer to the backport PR to 3.10.

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Jason R. Coombs]

Jason R. Coombs  added the comment:

There are known performance concerns. I recommend to set those aside for now or 
move them to a separate issue because

(a) The performance is theoretically better in the nominal case because it 
avoids a sort/group operation.
(b) There are known performance degradations introduced by importlib_metadata 
3.5 to de-duplicate distributions, degradations mitigated somewhat by 
importlib_metadata 4.3.
(c) Compatibility layers may be confounding performance concerns.

May I suggest addressing performance concerns in the importlib_metadata project 
as that project provides much better granularity on the different changes?

> I think my only satisfactory outcome would be:
> - the original api returns actual dicts

The original API returns an actual dict subclass (SelectableGroups).

- the sub-api returns actual lists

With https://github.com/python/importlib_metadata/pull/323, this expectation is 
also met as EntryPoints is a list.

- the new select is implemented as a separate *new* api without changing the 
existing api

The new API is invoked only through opt-in calls not previously available in 
the old API. I believe this achieves your goal without requiring a new name for 
`entry_points` or `Distribution.entry_points` (and thus creating less toil for 
consumers).

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Anthony Sottile]

Anthony Sottile  added the comment:

oops, tiny typo in those code examples, they should say `group=` instead of 
`name=` -- though the performance is unchanged:

(first example)
```console
$ ./venv39/bin/python t.py
0.6641988754272461
$ ./venv310/bin/python t.py
1.3172023296356201
```

(second example)
```console
$ ./venv39/bin/python t.py
0.014233589172363281
$ ./venv310/bin/python t.py
8.910593271255493
```

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Anthony Sottile]

Anthony Sottile  added the comment:

the `.select(...)` api is at least twice as slow as indexing as well:

setup:
```
virtualenv venv39 -p python3.9
venv39/bin/pip install flake8 pytest pytest-randomly
virtualenv venv39 -p python3.10
venv310/bin/pip install flake8 pytest pytest-randomly
```

```python
import importlib.metadata
import sys
import time


def f():
eps = importlib.metadata.entry_points()
if sys.version_info >= (3, 10):
eps.select(name='console_scripts')
else:
eps['console_scripts']


t0 = time.time()
for _ in range(100):
f()
t1 = time.time()
print(f'{t1-t0}')
```

```
$ ./venv39/bin/python t.py
0.687570333480835
$ ./venv310/bin/python t.py
1.3486714363098145
```

it is *way* worse when involving multiple entry points:

```python
import importlib.metadata
import sys
import time


# moved outside of the loop, already showed this component is slower
eps = importlib.metadata.entry_points()
def f():
# common for plugin systems to look up multiple entry points
for ep in ('console_scripts', 'flake8.extension', 'pytest11'):
if sys.version_info >= (3, 10):
eps.select(name=ep)
else:
eps[ep]


t0 = time.time()
for _ in range(1):
f()
t1 = time.time()
print(f'{t1-t0}')
```

```console
$ ./venv39/bin/python t.py
0.01629471778869629
$ ./venv310/bin/python t.py
8.569908380508423
```

--

___
Python tracker 

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

[issue34852] Counter-intuitive behavior of Server.close() / wait_closed()

[Aymeric Augustin]

Aymeric Augustin  added the comment:

Would it make sense to add `await asyncio.sleep(0)` in `Server.wait_closed()` 
to ensure that all connections reach `connection_made()` before `wait_closed()` 
returns?

This would be fragile but it would be an improvement over the current behavior, 
wouldn't it?

--

___
Python tracker 

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

[issue43413] tuple subclasses allow arbitrary kwargs

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +rhettinger

___
Python tracker 

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

[issue44262] tarfile: some content different output

[Filipe Laíns]

Filipe Laíns  added the comment:

tarfile will keep the mtime from the file, the issue is that you are touching 
the files in the beginning of the script. When you write to the files, you 
change the mtime (last modified time), which produces a different TarInfo. If 
you comment out the code that writes to the files, you get the exact same 
output.


#dir0 = Path("/tmp/a")
#dir0.mkdir(parents=True, exist_ok=True)
#fil0 = dir0 / "eph0"
#fil0.write_text("Text 0", encoding="UTF-8")
#fil1 = dir0 / "eph1"
#fil1.write_text("Text 1", encoding="UTF-8")
#fil2 = dir0 / "eph2"
#fil2.write_text("Text 2", encoding="UTF-8")


$ python compress.py
b'cc3bd1bf99edc4f0796e1c466d251b0f808db790cbdd55bc920c041fb405e535  
/tmp/py_gzip.tgz\n'
b'cc3bd1bf99edc4f0796e1c466d251b0f808db790cbdd55bc920c041fb405e535  
/tmp/py_gzip.tgz\n'
$ python compress.py
b'cc3bd1bf99edc4f0796e1c466d251b0f808db790cbdd55bc920c041fb405e535  
/tmp/py_gzip.tgz\n'
b'cc3bd1bf99edc4f0796e1c466d251b0f808db790cbdd55bc920c041fb405e535  
/tmp/py_gzip.tgz\n'


If you are in a situation where the mtime may change, but you want the same 
output, you can reset it. See the last example in 
https://docs.python.org/3/library/tarfile.html#tar-examples.

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Anthony Sottile]

Anthony Sottile  added the comment:

also https://github.com/miurahr/aqtinstall/issues/221

(this links to importlib-metadata tracker, not sure how you missed it)

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Anthony Sottile]

Anthony Sottile  added the comment:

I also need `.sort(key=...)` for what it's worth, the error in this issue was 
just the first encountered

I think my only satisfactory outcome would be:

- the original api returns actual dicts
- the sub-api returns actual lists
- the new select is implemented as a separate *new* api without changing the 
existing api

--

___
Python tracker 

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

[issue43413] tuple subclasses allow arbitrary kwargs

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Surprisingly there were almost no tests for keyword arguments in subclasses.

PR 26456 makes checks for some classes (like tuple, list, frozenset) more 
strict: if subclass does not define __init__ or __new__, it will reject 
arbitrary keyword arguments.

It also makes the check in set.__init__() more lenient for uniformity with 
frozenset and list. Subclass of set can now define a __new__() method with 
additional keyword parameters without overriding also __init__().

Added tests for some of builtin classes.

Raymond, please take a look. It touches classes maintained tracked by you: 
set/frozenset, itertools, random.

--

___
Python tracker 

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

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Thanks Zac for your input.

> Just chiming in with a plea to slow down the rate of changes to 
> importlib.metadata - I understand that you want to tidy up the API, but even 
> deprecations cause substantial work downstream.

It would be difficult to go much slower. Are you suggesting delaying the 
deprecation warning? My rationale for not delaying the deprecation warning is 
because it's possible using the backport to support the newer APIs all the way 
back to some end-of-life Pythons. If the deprecation warning is delayed, that 
seems to only delay the inevitable - that most projects will ultimately have to 
endure the toil of transitioning the code and relying on backports to support 
older Pythons.

Still, projects have the option to use the older APIs indefinitely by pinning 
the backport, or delay their adoption of the newer APIs by suppressing the 
warning. There's a lot of flexibility to limit the toil.

What approach would you recommend?

> Would it really be so bad to support the older APIs until they go end-of-life 
> in CPython?

At this point, I believe the code is compatible with all known use cases and 
it's conceivable the compatibility layer could be supported in Python releases 
until Python 3.9 is EOL. Is that what you're proposing? Would that help the 
Hypothesis case (or others)? My instinct is the value proposition there is 
small.

> For example, in Hypothesis we care a great deal about compatibility with all 
> supported Python versions (including treating warnings as errors) and try to 
> minimize the hard dependencies.  As a result, our entry-points handling looks 
> like this...

Project maintainers are allowed of course to treat warnings like errors, but 
since deprecation warnings are the primary mechanism for an upstream API to 
signal to the downstream that something is changing, projects should expect an 
increased amount of toil by transforming the default behavior of warnings.

I suspect that the hypothesis project could achieve forward compatibility 
within its constraints by vendoring `backports.entry_points_selectable`, and 
thus re-using a shared implementation of the conditional import dance. I've 
added a note to the project's README indicating that option. The implementation 
you have seems suitable, though.

> Change can be worth the cost, but there *is* a cost and the packaging 
> ecosystem is already painfully complex and fragmented.  Compatibility should 
> be a foundational principle, not an optional extra _if someone presents a 
> compelling use case!_

Agreed: compatibility is a foundational principle. Compatibility was built into 
the first release of this new behavior (importlib_metadata 3.6). Thanks to 
Anthony's feedback in the PR and extensive exploration and rewrites, the 
solution presented there has a fairly straightforward transition and clean 
separation of concerns. The case reported above, where compatibility was not 
achieved is an acknowledged missed concern, and I'm happy to invest the time to 
restore that compatibility if it's worth the trouble. The reason I'd thought 
it's not worth the trouble is because contrary to Anthony's claim, no user has 
reported an issue with index-based access on Distribution.entry_points results 
for the three months that this functionality has been in place, which is why a 
note about the incompatibility seemed sufficient (after the fact).

I'll proceed with adding compatibility for this reported case, although I worry 
that won't satisfy the concerns. Is there a satisfactory solution that doesn't 
involve reverting the changes? Is there an approach that meets the goals of the 
change with less disruption?

> I'm also seriously concerned that you take GitHub links as an indication of 
> who is affected.  Python is very very widely used, including in environments 
> that don't feed much back into the GitHub-open-source space, and I think it's 
> important to avoid breaking things for low-visibility users too.

I surely recognize that Github links and reports are only one indicator of one 
segment of the user base, but it's the sole indicator these projects have to 
solicit user concerns. That's why I pinned the issue reported about the 
Deprecation warning and used that forum to express concern and support for the 
users' issues and to present a variety of approaches for any number of users to 
avail themselves. I wanted to increase the visibility of the issue and limit 
the difficulty of addressing the intentional deprecation.

I mainly rely on Github reports and +1s on those reports as an indication of 
the impact of an issue. I use Github links as a means of networking. It was 
Anthony who suggested the links were an indication of a widespread issue. I 
only meant to contrast that concern to other breakages (in my experience) that 
showed dozens of links to affected issues. Linked issues are a secondary 
indicator at best.

I do expect that if users have an issue that th

[issue43413] tuple subclasses allow arbitrary kwargs

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue44262] tarfile: some content different output

[Vasco Gervasi]

Vasco Gervasi  added the comment:

Dear Filipe,
thanks for your answer.
Following your suggestion, I have tried the attached file.

The output is:
$ python /data/compress.py
b'68963e137ced6ee2aa5a93e155b201a3c172e2683d4b15a0eab7c1d8d43e48b4  
/tmp/py_gzip.tgz\n'
b'68963e137ced6ee2aa5a93e155b201a3c172e2683d4b15a0eab7c1d8d43e48b4  
/tmp/py_gzip.tgz\n'
$ rm -rf a/
$ mv py_gzip.tgz py_gzip.tgz0
$ python /data/compress.py
b'9c897d82c332f0d5443fe66112abe5f318bf6e6574e44c5c3c385f398784ac35  
/tmp/py_gzip.tgz\n'
b'9c897d82c332f0d5443fe66112abe5f318bf6e6574e44c5c3c385f398784ac35  
/tmp/py_gzip.tgz\n'
$ diffoscope py_gzip.tgz0 py_gzip.tgz
--- py_gzip.tgz0
+++ py_gzip.tgz
│   --- py_gzip.tgz0-content
├── +++ py_gzip.tgz-content
│ ├── file list
│ │ @@ -1,4 +1,4 @@
│ │ -drwxr-xr-x   0 root (0) root (0)0 2021-05-30 
15:32:56.566535 a/
│ │ --rw-r--r--   0 root (0) root (0)6 2021-05-30 
15:32:56.566535 a/eph0
│ │ --rw-r--r--   0 root (0) root (0)6 2021-05-30 
15:32:56.566535 a/eph1
│ │ --rw-r--r--   0 root (0) root (0)6 2021-05-30 
15:32:56.566535 a/eph2
│ │ +drwxr-xr-x   0 root (0) root (0)0 2021-05-30 
15:33:16.956535 a/
│ │ +-rw-r--r--   0 root (0) root (0)6 2021-05-30 
15:33:16.956535 a/eph0
│ │ +-rw-r--r--   0 root (0) root (0)6 2021-05-30 
15:33:16.956535 a/eph1
│ │ +-rw-r--r--   0 root (0) root (0)6 2021-05-30 
15:33:16.966535 a/eph2

Even if I am specifing an mtime, it is not correctly applied.

Thanks

--
Added file: https://bugs.python.org/file50073/compress.py

___
Python tracker 

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

[issue43858] Provide method to get list of logging level names

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I can add getLevelNamesDict() which would return a copy of _nameToLevel

That seem like the best approach.

--
assignee:  -> vinay.sajip
nosy: +rhettinger

___
Python tracker 

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

[issue43858] Provide method to get list of logging level names

[Andy Lowry]

Andy Lowry  added the comment:

@andrei.avk Yes, that sounds just fine. Many thanks.

--

___
Python tracker 

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

[issue44265] Create an MSI Package

[Eric V. Smith]

Eric V. Smith  added the comment:

See https://bugs.python.org/issue25124 for a discussion on why MSI won't be 
supported going forward.

--
nosy: +eric.smith

___
Python tracker 

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

[issue21550] Add Python implementation of the tar utility

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: test needed -> 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

[issue44260] _Random.seed() is called twice

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue44268] gettext: deprecate selecting plural form by fractional numbers (part 2)

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Non-integer numbers in GNUTranslations.ngettext() are deprecated since 3.7 (see 
issue28692 for rationale). But I forget to add deprecation warning for default 
implementation (which just tests n == 1) and forget to add the "deprecated" 
directive in the module documentation. So currently

gettext("Elapsed: %s second", "Elapsed: %s seconds", 1.25)

will emit a warning if there is a translation for these strings, and no 
warnings if it is not translated yet, or translation file is not found, or null 
translation is used.

It is now time to convert warnings to errors, but it would be error-prone since 
many developers do not have translations yet when write a code or use no 
translation (and fallback to hard-coded English).

The safest way is to add deprecation warnings also for default and fallback 
implementation before turning all of them into errors. Pablo, can we add these 
warnings in 3.10?

--
components: Library (Lib)
messages: 394762
nosy: pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: gettext: deprecate selecting plural form by fractional numbers (part 2)
type: enhancement
versions: Python 3.10, Python 3.11

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Sergey B Kirpichev]

Sergey B Kirpichev  added the comment:

On Sun, May 30, 2021 at 08:58:56AM +, Mark Dickinson wrote:
> Yep, you're absolutely right. I should have said "after the PEP is final"

Unfortunately, neither correction can fix that the PEP does not
"accurately describes the state of the implementation at the point where
it is marked Final."

> It would also be a backwards incompatible change at this point to
> start refusing strings that were previously accepted.

I'm not sure...

Well, it's not so clear which strings are accepted previously (i.e.
what's was documented).  PEP 515 claims one.  The docs says something
different:
>8---
If value is a string, it should conform to the decimal numeric string
syntax after leading and trailing whitespace characters, as well as
underscores throughout, are removed
>8---

and
--->8--
Underscores are allowed for grouping, _as with integral and
floating-point literals in code_.
-->8---

The 1-st sentence doesn't specify the way underscores are removed.  And
given the 2-nd sentence: it's clearly can't be like the current
behaviour of the Decimal constructor.

--

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Mark Dickinson]

Change by Mark Dickinson :


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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Mark Dickinson]

Mark Dickinson  added the comment:

> Regarding mail thread: I don't think that following the PEP will
slow down string conversion.

Sorry, I just don't think it's worth re-opening this discussion; Stefan Krah 
had good reasons (not just speed) to avoid implementing a precise 
interpretation of PEP 515 for Decimal.

It would also be a backwards incompatible change at this point to start 
refusing strings that were previously accepted. As I said, it's probably best 
left alone at this point.

--

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Mark Dickinson]

Mark Dickinson  added the comment:

> Well, then I something misunderstood in PEP 0

Yep, you're absolutely right. I should have said "after the PEP is final", not 
"after the PEP is accepted". PEP 515 was marked final on April 28th, 2017.

> The current behaviour is documented.

Thanks; I missed that. In that case, I don't think there's anything to do here 
documentation-wise.

--

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Sergey B Kirpichev]

Sergey B Kirpichev  added the comment:

On Sun, May 30, 2021 at 08:32:40AM +, Mark Dickinson wrote:
> Standards Track PEPs are historical documents; it's quite common that an
> actual implementation ends up diverging from a PEP in small ways after
> the PEP is accepted, and we don't usually do post-hoc updates in those 
> situations.

Well, then I something misunderstood in PEP 0:
--->8--
If changes based on implementation experience and user feedback are made
to Standards track PEPs while in the Accepted or Provisional State,
those changes should be noted in the PEP, such that the PEP accurately
describes the state of the implementation at the point where it is
marked Final.
>8
I don't think that PEP describes the state of art in the decimal module.

> Possibly the decimal documentation could be updated, though.

The current behaviour is documented.  Do you mean we should document
disagreement with PEP as well?

Regarding mail thread: I don't think that following the PEP will
slow down string conversion.  Also, probably we want that strings
that supported by float() and Decimal() were interchangeable.

--

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Mark Dickinson]

Mark Dickinson  added the comment:

> If this is not a bug - it should be adjusted

Standards Track PEPs are historical documents; it's quite common that an actual 
implementation ends up diverging from a PEP in small ways after the PEP is 
accepted, and we don't usually do post-hoc updates in those situations.

Possibly the decimal documentation could be updated, though.

--

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Sergey B Kirpichev]

Sergey B Kirpichev  added the comment:

On Sun, May 30, 2021 at 08:20:14AM +, Mark Dickinson wrote:
> There was some discussion of this on the python-dev mailing list at the time

I see.

> It's probably best left alone.

PEP 515 is clear.  If this is not a bug - it should be adjusted (as it
claims to cover Decimal's among other stuff).

--

___
Python tracker 

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

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

[Mark Dickinson]

Mark Dickinson  added the comment:

There was some discussion of this on the python-dev mailing list at the time - 
see https://mail.python.org/pipermail/python-dev/2016-March/143556.html and the 
surrounding thread. It's probably best left alone.

--

___
Python tracker 

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

[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules

[Ken Jin]

Change by Ken Jin :


--
nosy: +kj

___
Python tracker 

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