[Python-Dev] Re: When to remove BytesWarning?

[Christian Heimes]

On 24/10/2020 05.19, Inada Naoki wrote:
> Hi, all.
> 
> To avoid BytesWarning, the compiler needs to do some hack when they
> need to store bytes and str constants in one dict or set.
> BytesWarning has maintenance costs. It is not huge, but significant.
> 
> When can we remove it? My idea is:
> 
> 3.10: Deprecate the -b option.
> 3.11: Make the -b option no-op. Bytes warning never emits.
> 3.12: Remove the -b option.
> 
> BytesWarning will be deprecated in the document, but not to be removed.
> Users who want to use the -b option during 2->3 conversion need to use
> Python ~3.10 for a while.

In my experience it would be useful to keep the bytes warning for
implicit representation of bytes in string formatting. It's still a
common source of issues in code. Bytes / str comparison or dict lookup
is a less common issue.

>>> b = b'bytes'
>>> f"{b}"
Traceback (most recent call last):
  File "", line 1, in 
BytesWarning: str() on a bytes instance
>>> str(b)
Traceback (most recent call last):
  File "", line 1, in 
BytesWarning: str() on a bytes instance

Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/M2NJZTGLUA5IAGYDJZOZCPOL4AIXKMY6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

[Nick Coghlan]

On Sat., 24 Oct. 2020, 4:21 am Guido van Rossum,  wrote:

> On Fri, Oct 23, 2020 at 6:19 AM Tin Tvrtković 
> wrote:
>
>> Hi,
>>
>> first of all, I'm a big fan of the changes being proposed here since in
>> my code I prefer the 'union' style of logic over the OO style.
>>
>> I was curious, though, if there are any plans for the match operator to
>> support async stuff. I'm interested in the problem of waiting on multiple
>> asyncio tasks concurrently, and having a branch of code execute depending
>> on the task.
>>
>> Currently this can be done by using asyncio.wait, looping over the done
>> set and executing an if-else chain there, but this is quite tiresome. Go
>> has a select statement (https://tour.golang.org/concurrency/5) that
>> looks like this:
>>
>> select {
>> case <-ch1:
>> fmt.Println("Received from ch1")
>> case <-ch2:
>> fmt.Println("Received from ch2")
>> }
>>
>> Speaking personally, this is a Go feature I miss a lot when writing
>> asyncio code. The syntax is similar to what's being proposed here. Although
>> it could be a separate thing added later, async match, I guess.
>>
>
> Hadn't seen this before. You could propose this as a follow-up for 3.11.
> But aren't Go channels more like asyncio Queues? I guess we'd need way more
> in terms of a worked-out example (using asyncio code, not Go code).
>

I think we'd also want to see how far folks get with using guard clauses
for this kind of "where did the data come from?" check - the only
specifically asynchronous bit would be the "await multiple tasks"
operation, and you can already tell asyncio.wait() to return on the first
completed task rather than waiting for all the results.

Cheers,
Nick.



>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NQWYLFLGLLCEHAXYHUOXQ3M7IOEL65ET/
Code of Conduct: http://python.org/psf/codeofconduct/