[issue45641] Error In opening a file through tkinter on macOS Monterey

2021-10-30 Thread Dev Kumar


Dev Kumar  added the comment:

What happened?
when is the new version is coming for tackling this problem?

--

___
Python tracker 

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



[issue45666] Warning: "'swprintf' : format string '%s' requires an argument of type 'unsigned short *', but variadic argument 1 has type 'const char *'"

2021-10-30 Thread Ken Jin


Ken Jin  added the comment:


New changeset aad48062ef8f983fbb95f9dc0c3c3cef9c89df02 by Nikita Sobolev in 
branch 'main':
bpo-45666: fixes warning with `swprintf` and `%s` (GH-29307)
https://github.com/python/cpython/commit/aad48062ef8f983fbb95f9dc0c3c3cef9c89df02


--
nosy: +kj

___
Python tracker 

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



[issue45653] Freeze the encodings module.

2021-10-30 Thread Filipe Laíns

Change by Filipe Laíns :


--
stage: needs patch -> patch review

___
Python tracker 

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



[issue45653] Freeze the encodings module.

2021-10-30 Thread Filipe Laíns

Filipe Laíns  added the comment:

I have already opened up the PR, but I can change if desired.

--
stage: patch review -> needs patch

___
Python tracker 

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



[issue2628] ftplib Persistent data connection

2021-10-30 Thread Jonathan Bell


Change by Jonathan Bell :


--
pull_requests: +27604
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/29337

___
Python tracker 

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



[issue45669] An 'ascii_alphanumerics' variable is missing in the 'strings' lib

2021-10-30 Thread Paolo Melchiorre


Paolo Melchiorre  added the comment:

Thank you all for the feedback, also I have been using python for years and 
contributing to other python-based projects it is my first PR to Cpython and I 
don't know if my contribution to the discussion is foreseen.

It seems to me that adding this constant does not cause any damage in fact it 
is an easy victory. However, I try to clarify some doubts raised.

I proposed this new variable to simplify the code in a use case that occurs 
very often, not so much to save some characters.

I think every single new variable, constant and function needed a waiting 
period before being used in packages that support different versions of python 
(ex: f-string in Python 3.6) but can be used in the code of projects that use 
the latest version of python or in the python code itself.

The definition of the alphanumeric constant in the standard libraries I believe 
can help to have a clearly defined common variable[1], which could be used as a 
basis for alphabets containing additional symbols (ex: _- =)

[1] https://en.wikipedia.org/wiki/Alphanumeric

--

___
Python tracker 

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



[issue2628] ftplib Persistent data connection

2021-10-30 Thread Ethan Furman


Ethan Furman  added the comment:

If you're familiar with git and GitHub, can you create a PR?  Otherwise, an 
updated patch here and we'll work on getting it merged.

--

___
Python tracker 

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



[issue45625] Add support for top-level await

2021-10-30 Thread Fred


Fred  added the comment:

No, I was not aware of that.

After I started Python by running "python3 -m asyncio" then it behaved as I 
expected it should behave by default.

But this seems to work only in the REPL. I would like to write Python scripts 
stored in files where I can easily await at the top level as in the example in 
my first post.

--

___
Python tracker 

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



[issue2628] ftplib Persistent data connection

2021-10-30 Thread Jonathan Bell


Jonathan Bell  added the comment:

The CLA is signed, and I'm again able to work on this.

I was able to update this locally for Python 3 with a minimal test case. What 
specifically were you looking for?

--

___
Python tracker 

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



[issue45680] Documentation on `GenericAlias` objects could be improved

2021-10-30 Thread Alex Waygood


Alex Waygood  added the comment:

This issue is related, but distinct, to previous issue 
https://bugs.python.org/issue42280.

--

___
Python tracker 

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



[issue45680] Documentation on `GenericAlias` objects could be improved

2021-10-30 Thread Alex Waygood


Change by Alex Waygood :


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

___
Python tracker 

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



[issue45680] Documentation on `GenericAlias` objects could be improved

2021-10-30 Thread Alex Waygood


New submission from Alex Waygood :

The documentation on `GenericAlias` objects implies at multiple points that 
only container classes can implement `__class_getitem__`, and goes into very 
little detail about what it means for a non-container class to be parameterized.

--
assignee: docs@python
components: Documentation
messages: 405384
nosy: AlexWaygood, docs@python, gvanrossum, kj, lukasz.langa
priority: normal
severity: normal
status: open
title: Documentation on `GenericAlias` objects could be improved
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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



[issue45679] typing.Literal[True] is implicitly converted to typing.Literal[1]

2021-10-30 Thread Serhiy Storchaka


Change by Serhiy Storchaka :


--
pull_requests: +27602
pull_request: https://github.com/python/cpython/pull/29334

___
Python tracker 

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



[issue45625] Add support for top-level await

2021-10-30 Thread Éric Araujo

Éric Araujo  added the comment:

Do you know about using "python -m asyncio" instead of "python"?

--
nosy: +eric.araujo

___
Python tracker 

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



[issue45617] sys.stdin does not iterate correctly on '\r' line separator

2021-10-30 Thread Éric Araujo

Éric Araujo  added the comment:

> '\r' support is implicitly documented under the sys.stdin section[0]:
> "These streams are regular text files like those returned by the open() 
> function"

I read that to mean that the streams are file-like objects (or TextIOWrappers) 
without using that term, not to mean that they behave 100% similarly.

--
nosy: +eric.araujo

___
Python tracker 

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



[issue45653] Freeze the encodings module.

2021-10-30 Thread Marc-Andre Lemburg

Marc-Andre Lemburg  added the comment:

On 30.10.2021 17:54, Filipe Laíns wrote:
> 
> I just tested partially freezing the package, and it seems to working fine :)
FWIW: I think it's best not bother and simply freeze the whole thing.

It's mostly char mappings which compress well and there's a benefit
in sharing these using mmap (which the OS does for you with static
C data).

--

___
Python tracker 

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



[issue45610] Cookies with longer paths are listed before cookies with shorter paths.

2021-10-30 Thread Éric Araujo

Éric Araujo  added the comment:

I don’t know that longer is the right think to look at here, but rather more 
specific.  Unless I’m mistaken, a cookie for test.com is not read on 
demo.test.com; it would need to be for .test.com to be read (and in that case 
the specificity rules in the spec should be followed).

--
nosy: +eric.araujo

___
Python tracker 

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



[issue45598] setup.py grep_headers_for() is broken by design

2021-10-30 Thread Éric Araujo

Éric Araujo  added the comment:

We could look in distro patch trackers to see they patch CPython’s setup.py to 
evaluate the impact of removing this function.

--
nosy: +eric.araujo

___
Python tracker 

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



[issue45588] cached_method similar to cached_property to cache with classes

2021-10-30 Thread Éric Araujo

Éric Araujo  added the comment:

The feature proposed here is not clear to me.

Is it about caching the method object on the instance to optimize the creation 
of the bound method, as the name suggests?  Or is it about caching the result 
of calling the method, which is consistent with the references to lru_cache and 
cachedproperty?

--
nosy: +eric.araujo

___
Python tracker 

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



[issue45679] typing.Literal[True] is implicitly converted to typing.Literal[1]

2021-10-30 Thread Nikita Sobolev


Change by Nikita Sobolev :


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

___
Python tracker 

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



[issue45679] typing.Literal[True] is implicitly converted to typing.Literal[1]

2021-10-30 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

I agree. lru_cache(typed=True) itself should not look into iterable internals. 
It would be not only slow, but a change of semantic.

The simplest way to solve this issue is to remove caching of __getitem__(). The 
more sophisticated way is to move caching to lower level and apply it to a 
function with a var-positional parameter.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue45679] typing.Literal[True] is implicitly converted to typing.Literal[1]

2021-10-30 Thread Nikita Sobolev


Nikita Sobolev  added the comment:

I see several ways of solving this:
1. Make `lru_cache(typed=True)` to look into iterable internals. This might be 
slow. And very slow for large iterables. Maybe even infinite for infinite ones
2. Adapt `Literal` / possibly other types to be treated differently. Because, 
most of the time, `Literal` take a small amount of args

I am going to send a PR with the second option.

--

___
Python tracker 

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



[issue45679] typing.Literal[True] is implicitly converted to typing.Literal[1]

2021-10-30 Thread Nikita Sobolev


Nikita Sobolev  added the comment:

This happens to all `lru_cache` calls, where we deal with container types.

Example:

```
from functools import lru_cache

@lru_cache(typed=True)
def test(arg):
return str(arg)

print(test((1, 'a')))  # (1, 'a')
print(test((True, 'a')))  # (1, 'a')
```

Moveover, this behavior is not tested in `test_functools`: 
https://github.com/python/cpython/blame/aae18a17401dc36917c0f64f971d60ab1a5b477e/Lib/test/test_functools.py#L1482-L1496

Original issue: https://bugs.python.org/issue13227
Original commit: 
https://github.com/python/cpython/commit/cd9fdfd652cdaca959b1c5d4cddf60d90a331b47

--
nosy: +gvanrossum, kj, rhettinger, sobolevn

___
Python tracker 

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



[issue45578] Missing tests for the dis module

2021-10-30 Thread Joannah Nanjekye


Joannah Nanjekye  added the comment:

Yes, it is that's why I added the clarity "It looks like it *is* actually" above

--

___
Python tracker 

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



[issue45578] Missing tests for the dis module

2021-10-30 Thread Nikita Sobolev


Nikita Sobolev  added the comment:

Looks like `findlabels` is documented: 
https://docs.python.org/3/library/dis.html#dis.findlabels

--

___
Python tracker 

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



[issue45578] Missing tests for the dis module

2021-10-30 Thread Nikita Sobolev


Change by Nikita Sobolev :


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

___
Python tracker 

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



[issue45653] Freeze the encodings module.

2021-10-30 Thread Filipe Laíns

Change by Filipe Laíns :


--
keywords: +patch
pull_requests: +27599
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29331

___
Python tracker 

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



[issue45653] Freeze the encodings module.

2021-10-30 Thread Filipe Laíns

Filipe Laíns  added the comment:

I just tested partially freezing the package, and it seems to working fine :)

--

___
Python tracker 

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



[issue45679] typing.Literal[True] is implicitly converted to typing.Literal[1]

2021-10-30 Thread Van Burgerberg


New submission from Van Burgerberg :

When you create `Literal[1]` annotation and then create `Literal[True]` 
annotation, in the second case you will actually get `Literal[1]` instead. This 
is happening because `typing` performs caching of the outcome of parameterizing 
generics and `hash(True)` is equal to `hash(1)`. I think this behavior is 
incorrect and may lead to unexpected results.

Why is this inaccuracy important?
Consider the following example:

```python
from typing import Literal

SomeUsefulAlias = Literal[1, "abc"]

def func(arg: Literal[True, "abc"]):
if arg is not True:
arg.capitalize()
```

If we look at `func.__annotations__["arg"]`, we will see `Literal[1, 'abc']`. 
According to the new annotation, we can pass the value `1` to `func`, and this 
will lead to an attribute error, as you've already understood. Thus, proper 
runtime type checking cannot be performed.

--
components: Library (Lib)
messages: 405371
nosy: vanburgerberg
priority: normal
severity: normal
status: open
title: typing.Literal[True] is implicitly converted to typing.Literal[1]
type: behavior
versions: Python 3.10, 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



[issue45578] Missing tests for the dis module

2021-10-30 Thread Nikita Sobolev


Nikita Sobolev  added the comment:

I would like to work on it! :)

Going to send a PR today.

--
nosy: +sobolevn

___
Python tracker 

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



[issue45272] 'os.path' should not be a frozen module

2021-10-30 Thread Filipe Laíns

Change by Filipe Laíns :


--
keywords: +patch
pull_requests: +27598
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29329

___
Python tracker 

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



[issue45669] An 'ascii_alphanumerics' variable is missing in the 'strings' lib

2021-10-30 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

I was also against this feature. My reasons:

1. There will be not much benefit. ascii_alphanumerics is too long, so there is 
no much saving of typing. There is larger chance of typo. You will be not able 
to use it for several years, until support of Python 3.10 be dropped, without 
making the code uglier.

2. What exactly should it include? In virtually all use cases in the stdlib and 
tests (except two tests) you need a set which contains ascii_letters, digits, 
and some other characters (usually "_", but sometimes more). Should "_" be 
included in ascii_alphanumerics? Whatever we choose, it will be less explicit 
than ascii_letters + digits and people will need to look in the documentations 
or make errors. And every reader of the code would have doubts.

Lib/http/cookies.py:162:_LegalChars = string.ascii_letters + string.digits + 
"!#$%&'*+-.^_`|~:"
Lib/crypt.py:19:_saltchars = _string.ascii_letters + _string.digits + './'
Lib/email/_encoded_words.py:75:safe = b'-!*+/' + 
ascii_letters.encode('ascii') + digits.encode('ascii')
Lib/email/quoprimime.py:60:for c in b'-!*+/' + ascii_letters.encode('ascii') + 
digits.encode('ascii'):
Lib/cmd.py:50:IDENTCHARS = string.ascii_letters + string.digits + '_'
Lib/idlelib/autoexpand.py:20:wordchars = string.ascii_letters + 
string.digits + "_"
Lib/idlelib/undo.py:254:alphanumeric = string.ascii_letters + string.digits 
+ "_"
Lib/idlelib/editor.py:809:IDENTCHARS = string.ascii_letters + string.digits 
+ "_"
Lib/idlelib/hyperparser.py:13:_ASCII_ID_CHARS = frozenset(string.ascii_letters 
+ string.digits + "_")
Lib/idlelib/autocomplete.py:33:ID_CHARS = string.ascii_letters + string.digits 
+ "_"
Lib/test/test_re.py:1011:LITERAL_CHARS = string.ascii_letters + 
string.digits + '!"%\',/:;<=>@_`'
Lib/test/test_email/test__header_value_parser.py:50:rfc_atext_chars = 
(string.ascii_letters + string.digits +
Lib/test/test_importlib/test_util.py:654:valid_characters = 
string.ascii_letters + string.digits
Lib/test/test_secrets.py:115:legal = string.ascii_letters + 
string.digits + '-_'
Lib/test/string_tests.py:1219:s = string.ascii_letters + string.digits
Lib/test/test_shlex.py:328:safeunquoted = string.ascii_letters + 
string.digits + '@%_-+=:,./'
Lib/ntpath.py:359:varchars = bytes(string.ascii_letters + string.digits 
+ '_-', 'ascii')
Lib/ntpath.py:370:varchars = string.ascii_letters + string.digits + '_-'
Lib/msilib/__init__.py:177:identifier_chars = string.ascii_letters + 
string.digits + "._"
Tools/scripts/texi2html.py:1975:goodchars = string.ascii_letters + 
string.digits + '!@-=+.'

But if other core developers support it, it is okay to me.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue45669] An 'ascii_alphanumerics' variable is missing in the 'strings' lib

2021-10-30 Thread Dong-hee Na


Dong-hee Na  added the comment:

@skip.montanaro

I agree with your concern, if authors want to use this constant,
they need to use the mentioned workaround to import it.
But we already have cases that add such constants if we considered them as 
useful constants.

So I think that the main concern of this issue is that how it will be useful.
In my case, if I should write the utility to generate random tokens for 
authentication in python, I always write a single trivial code to use 
ascii_alphanumerics, that's why I thought that this constant can be useful.
FYI We already have the same use case in official documentation[1] also.

But if other core devs also thought that this is not that commonly well-used 
case, I will change my mind to -1 since we can not support all ASCII 
variations(e.g ascii_number_special) and I agree with that point.

[1] https://docs.python.org/3/library/secrets.html#recipes-and-best-practices

--

___
Python tracker 

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



[issue45097] "The loop argument is deprecated" reported when user code does not use it

2021-10-30 Thread Chih-Hsuan Yen


Change by Chih-Hsuan Yen :


--
nosy:  -yan12125

___
Python tracker 

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



[issue32453] shutil.rmtree can have O(n^2) performance on large dirs

2021-10-30 Thread Niklas Hambüchen

Niklas Hambüchen  added the comment:

A small update / summary so far:

>From here this developed into coreutils discussion:

#29921 O(n^2) performance of rm -r
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29921

and finally a `linux-fsdevel` discussion:

O(n^2) deletion performance

https://lore.kernel.org/linux-fsdevel/5ca3808d-4eea-afec-75a6-2cc41f44b...@nh2.me/t/#u

Dave Chinner (xfs dev) suggests that on XFS there is no quadratic behaviour 
once  the problem is bound by seek-time of the spinning disk.

Somebody should try to confirm that it becomes linear in even larger tests, 
e.g. way larger than 21 minutes deletion time.

--

___
Python tracker 

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



[issue45097] "The loop argument is deprecated" reported when user code does not use it

2021-10-30 Thread Matej Cepl


Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

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



[issue45678] `functools.singledispatchmethod` is missing tests

2021-10-30 Thread Alex Waygood


Change by Alex Waygood :


--
components: +Tests -Library (Lib)

___
Python tracker 

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



[issue45678] `functools.singledispatchmethod` is missing tests

2021-10-30 Thread Alex Waygood


Change by Alex Waygood :


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

___
Python tracker 

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



[issue45678] `functools.singledispatchmethod` is missing tests

2021-10-30 Thread Alex Waygood


New submission from Alex Waygood :

`test_functools` includes a test to check that `functools.singledispatch` 
correctly wraps the attributes of the target function. However, there is no 
equivalent test for `functools.singledispatchmethod`. There should be, as this 
is done separately in the `__get__` method of `functools.singledispatchmethod`; 
it is a different mechanism to `functools.singledispatch`.

Additionally, `test_abstractmethod_register` tests that the return value of 
`singledispatchmethod.__get__` wraps the target function's 
`__isabstractmethod__` attribute. However, the `__isabstractmethod__` property 
of the `singledispatchmethod` class is untested.

--
components: Library (Lib)
messages: 405366
nosy: AlexWaygood, lukasz.langa, rhettinger
priority: normal
severity: normal
status: open
title: `functools.singledispatchmethod` is missing tests
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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



[issue45669] An 'ascii_alphanumerics' variable is missing in the 'strings' lib

2021-10-30 Thread Skip Montanaro


Skip Montanaro  added the comment:

I'll be the wet blanket here and say -1. This doesn't seem at all necessary. 81 
occurrences in ~3.5k PyPI packages? That's a hardly overwhelming endorsement. 
To top it off, since this can't be backported to 3.10 and earlier, it creates a 
needless (trivial) difference. Package authors who would like to use this but 
support earlier versions of Py3 will need to do something like this:

try:
from string import ascii_alphanumerics
except ImportError:
ascii_alphanumerics = string.ascii_letters + string.digits

They get no benefit from the addition. In fact, their code gets marginally 
harder to read.

--
nosy: +skip.montanaro

___
Python tracker 

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



[issue5004] socket.getfqdn() doesn't cope properly with purely DNS-based setups

2021-10-30 Thread Stijn Hoop


Stijn Hoop  added the comment:

I hereby put my patch in the public domain and/or under any desired
copyright license as required by the Python project to accept it.

Regards,

Stijn Hoop

On Fri, 22 Oct 2021 21:03:26 +
Richard van den Berg  wrote:

> Richard van den Berg  added
> the comment:
> 
> In that case Stijn Hope should create the PR since he wrote the
> patch. Anyone else could get in trouble for using his code without
> proper permission.
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--
nosy: +shoop

___
Python tracker 

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



[issue45671] str(CancelledError()) is empty

2021-10-30 Thread lilydjwg


lilydjwg  added the comment:

OK, I see.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue30082] hide command prompt when using subprocess.Popen with shell=False on Windows

2021-10-30 Thread Eryk Sun


Eryk Sun  added the comment:

Here's an example test that calls WinAPI GetConsoleWindow() and 
IsWindowVisble() in a child process.

if mswindows:
try:
import ctypes
except ImportError:
ctypes = None

# added in Win32ProcessTestCase
def test_force_hide(self):
if ctypes:
script = textwrap.dedent(r'''
import sys, ctypes
GetConsoleWindow = ctypes.WinDLL('kernel32').GetConsoleWindow
IsWindowVisible = ctypes.WinDLL('user32').IsWindowVisible
sys.exit(IsWindowVisible(GetConsoleWindow()))
''')
else:
script = 'import sys; sys.exit(0)'
rc = subprocess.call([sys.executable, '-c', script], force_hide=True)
self.assertEqual(rc, 0)

This test will work reliably even if the user has Windows Terminal set as the 
default terminal (available with recent builds of Windows and Windows Terminal 
Preview). The proxy does not hand off to Windows Terminal if the STARTUPINFO 
wShowWindow is SW_HIDE or SW_SHOWMINIMIZED, or if the process is created with 
the CREATE_NO_WINDOW flag. In these cases, it just creates a system conhost.exe 
session.

--

___
Python tracker 

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



[issue45671] str(CancelledError()) is empty

2021-10-30 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

Then you would get

>>> raise asyncio.CancelledError
Traceback (most recent call last):
  File "", line 1, in 
asyncio.exceptions.CancelledError: CancelledError

instead of

>>> raise asyncio.CancelledError
Traceback (most recent call last):
  File "", line 1, in 
asyncio.exceptions.CancelledError

Many existing code include both of exception name and message in the report 
about exception. Repeating the exception name as exception message will cause 
confusing.

You should follow common practice and print not just an exception object, but 
its name or repr. It will help in other cases, when the exception has non-empty 
message, but you do not know its type.

--

___
Python tracker 

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