[Python-Dev] Re: Stable ABI question.

[Inada Naoki]

Thanks.  I will do it.

On Wed, Jul 1, 2020 at 5:50 PM Serhiy Storchaka  wrote:
>
> 01.07.20 04:35, Inada Naoki пише:
> > Hi, folks.
> >
> > I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since
> > Python 3.2.
> > But the same time, stable ABI is defined in Python 3.2 too.
> > The deprecated APIs are stable ABI too because `ceval.h` is not
> > excluded from the stable ABI PEP.
> >
> > As far as my understanding, we can not remove them until Python 4.0. Am I 
> > right?
> >
> > I will add comment like this.
> > /* This is a part of stable ABI. Do not remove until Python 4.0 */
>
> We can remove them from public headers, but should keep their
> implementation and export their names to preserve the binary compatibility.
> ___
> 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/255WEQX2JTSNJHHZJ7NYGSAS5WPN7NI5/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Inada Naoki  
___
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/JDSJIRJP3ENTIM6AHWKLH255ZPQL2FB3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Elliott Chen]

I don't think my proposal should be off the table for scope reasons because it 
requires the syntaxes to be completely unified and interchangeable, which will 
be impossible if the current PEP is accepted. I guess it's technically possible 
to still have the pattern-matching syntax be slightly different from extended 
assignment statements, but I think that would just unnecessarily complicate the 
language, force users to be aware of the subtle differences when writing code, 
and potentially cause users to make mistakes.
___
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/HF3ALPHOKKCT4ZNI5JV54L5QLDBGWRFQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Guido van Rossum]

On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan  wrote:

> The key thing I'm hoping for in PEP 622 itself is that "Syntactic
> compatibility with a possible future enhancement to assignment
> statements" be considered as a constraint on the syntax for case
> patterns.
>

That would certainly rule out ideas like writing stores as $x or x? or 
etc., since it would be syntactically incompatible with *current*
assignment statements.


> Some of the ideas currently on the table would rule that out, since
> they re-use syntax that is already legal in assignment statements to
> mean something else (most notably, "x.y = z" means something entirely
> different from the initially proposed meaning of "case x.y:"). If PEP
> 622 were to be accepted in that form, then it would foreclose the
> possibility of ever allowing destructuring assignment statements.
>

I'm not worried. Even if these didn't *exactly* the same syntax users would
still benefit from similarities, e.g. `a, b, *rest = value` vs. `case a, b,
*rest:`.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/PXGCSATPVP23URNKWYXDUBRUBKPNBPDZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Nick Coghlan]

On Thu, 2 Jul 2020 at 00:50, Guido van Rossum  wrote:
>
> Before we all get a little too excited here, I think that allowing
> ```
> 1 = x
> ```
> as a sneaky way of writing
> ```
> assert x == 1
> ```
> would be a terrible mistake.

The "two ways to do it" possibilities give me pause too, but it
wouldn't be exactly the same as assertions or type annotations, since
it would still be executed even when optimisations were enabled, and
would impose a runtime check, not just a static type analysis check.

The structurally split nature of the construct would also allow the
default error message to be along the lines of `"AssertionError: Value
{:100!r} does not match constraint {!100:!r}".format(rhs_value,
lhs_literal_text)`, and still allow type analysers to make relevant
inferences.

(Although whether the exception should be AssertionError, ValueError,
or a new exception type entirely would be open to discussion)

> As to allowing object destructuring syntax like
> ```
> Point(x, y) = p
> ```
> that definitely has merit, but it is a complex subject that should be a 
> separate PEP.

This is the main point I'm actually interested in, and I agree it
should be a separate PEP.

The key thing I'm hoping for in PEP 622 itself is that "Syntactic
compatibility with a possible future enhancement to assignment
statements" be considered as a constraint on the syntax for case
patterns.

Some of the ideas currently on the table would rule that out, since
they re-use syntax that is already legal in assignment statements to
mean something else (most notably, "x.y = z" means something entirely
different from the initially proposed meaning of "case x.y:"). If PEP
622 were to be accepted in that form, then it would foreclose the
possibility of ever allowing destructuring assignment statements.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/ASBBZAMY2GMOZEZHE5EBWKQJT53LCOW3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Henk-Jaap Wagenaar]

I agree with you it is over the top, but let's enjoy the popcorn together!

On Wed, 1 Jul 2020 at 01:35, Greg Ewing  wrote:

> Sorry for fanning the flames, but this whole thread is so over
> the top I'm finding it kind of entertaining.
>
> On 1/07/20 2:23 am, Piper Thunstrom wrote:
> > The grammarian movement, in general, was built on
> > elevating a very specific form of English over others. It specifically
> > was chosen to avoid "lower class" usages
>
> This argument seems to rest on the assumption that "lower
> class" equates to "non-white". This is an extremely US-centric
> idea. It could possibly even be described as exhibiting a
> "breathtaking level of ignorance"...
>
> > the
> > Elements of Style (And many works like it) are built on a system of
> > white supremacy.
>
> If that's true, then the entirety of Western culture is built
> on a system of white supremacy. That includes all our modern
> technology. It includes the Python programming language. We'd
> better stop recommending Python to people!
>

I kind of of agree with your (attempt) at reductio ad absurdum: Python and
Western culture is built on a system of white supremacy (read: white
privilege, academic definition of the word), and if we were not trying to
fix this (by changes like the one in this commit, or the PSFs stance on
inclusivity in the CoC and active work towards this) I would probably
actually recommend people to stop using Python: I have stopped watching
content because I do not agree with the stances taken by its creator, even
when it has not directly affected the content (insofar as I can tell). To
take your argument itself to the extreme and Godwin myself, if a neonazi
group developped an amazing programming language that had a swastika for
its symbol and was littered with references to the Nazis and their
ideology, would you recommend it?


>
> > Each individual who likes
> > Elements of Style is not wrong for liking the book, you can keep it on
> > your shelf and no one will be angry.
>
> Okay, I'm confused. S is a symbol of white supremacy that
> shall never be recommended or mentioned in polite company, but
> it's all right to have one on your shelf, as long as you keep it
> to yourself... or something?
>
> You can't have it both ways.
>

What I think was meant here: S is inappropriate to use as a community
guideline for a diverse community like Python because it is not inclusive
and forces (a particular version of) "Standard English" on others, however,
you using it for your own writing (while not imposing it on others) is not
an issue. As an analogy, in the US it is illegal (as determined by the
Supreme Court) for state officials to compose an official school prayer and
require its recitation in school, even when those who wish can excuse
themselves from reciting it, on the other hand, if a state official
composed an official before-school prayer but that was not required to be
recited in school, this would be legal and it would be fine for a parent to
frame it, display it and have their child pray it before leaving for
school: it would then even be ok for the kid to tell the others and their
teacher that that's what they do at home!


>
> --
> Greg
> ___
> 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/MQK33M4FPH2HGOSA6FO7SOI65C577WMH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/FEV7GJCOMTUI53PE3OYXICYBJLZ4FB4F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Henk-Jaap Wagenaar]

To paraphrase the Bible: "For where two or three gather, there is politics
with them."

Changing the commit message, as it has been merged, is now practically hard
and highly unusual. If you use GitHub search, you can find other examples
of commit messages that would be rewritten if that was doable without cost:
https://github.com/python/cpython/search?q=fuck=Commits: such commits
would not be merged now I imagine *if it was caught before merging* (of
course, the repo was not even in git at the time, so there were no pull
requests et cetera at the time...) but would have to stay in if already
merged. In this case, as is common I think for most software developers or
anyone writing any text: I think the main reason all messages are
different: commit, email and PR is because they were written at different
times and the writer found better ways of distilling their thought process
and also got external input through the email thread. In particular, I
think it is common for commit messages to be different from the PR messages
(precisely because of this!) and as many has said, and as we should
remember, this commit (the actual change) was brought by a volunteer in
their own time, and had broad agreement (though not unanimous) on the
mailing list, yet now we have ended up having a massive mail thread
discussing their particular contribution and I am sure they feel obliged to
read all these messages. So let's compare the three:

*Commit*
"Instead of requiring that comments be written in Strunk & White Standard
English, require instead that English-language comments be clear and easily
understandable by other English speakers. This accomplishes the same goal
without upholding relics of white supremacy. Many native English speakers
do not use Standard English as their native dialect, so requiring
conformation to Standard English centers whiteness in an inappropriate and
unnecessary way, and can alienate and put up barriers for people of color
and those whose native dialect of English is not Standard English. This
change is a simple way to correct that while maintaining the original
intent of the requirement."

*Email*
"[...] Instead of requiring that comments be written in Strunk & White
Standard English, PEP-8 should require instead that English-language
comments be clear and easily understandable by other English speakers. This
accomplishes the same goal without alienating or putting up barriers for
people (especially people of color) whose native dialect of English is not
Standard English. This change is a simple way to correct that while
maintaining the original intent of the requirement."

*Pull Request*
"Instead of requiring that comments be written in Strunk & White Standard
English, require instead that English-language comments be clear and easily
understandable by other English speakers. This accomplishes the same goal
without alienating or putting up barriers for people (especially people of
color) whose native dialect of English is not Standard English. This change
is a simple way to correct that while maintaining the original intent of
the requirement. This change also makes the requirement more clear to
people who are not familiar with Strunk & White, since for programmers, the
main relevant aspect of that standard is "be clear and concise;" simply
saying that instead of referencing Strunk & White communicates this more
effectively."

Clearly, the last sentence (starting "This change also") was added after
the email thread, *however* note the commit (message) was written before
that discussion took place or the PR was made. I think all three texts
(barring the addition in the third one) have the same spirit because
- "a person of color" is anybody who is not Caucasian/white according to
the definition as I understand it and so does Wikipedia:
https://en.wikipedia.org/wiki/Person_of_color
- "white supremacy" has the academic definition similar to/being "white
privilege": https://en.wikipedia.org/wiki/White_supremacy and that's how I
read it here, not an ideology, especially given the context
and so I think working against alienation of "persons of colors" is
aligned/has a similar meaning to with reducing [the relics of] "white
privilege" [in not being alienated in terms of language expected in Python
comments] and are similarly "political" (I would say "inclusive" and
"uncontroversial", but to each their own). I think if you think any one of
these 3 is "political", they all are, so to fall over the commit message in
particular (because it says "white supremacy"?) seems inconsistent to me.

All 3 texts to me are not political, or at least not political beyond what
has already been decided: inclusivity in language is explicit in the CoC:
"Using welcoming and inclusive language. We're accepting of all who wish to
take part in our activities, fostering an environment where anyone can
participate and everyone can make a difference." You might disagree whether
that should be in the Code of Conduct or whether 

[Python-Dev] Re: Flexible assignment targets

[Guido van Rossum]

We're trying to make the PEP's scope *smaller*, not larger. Let's take
changes to assignment off the table. We're fully aware of the resemblance
between `a, b = value` and `case a, b: ...` and we're making them behave as
similar as is reasonable.

On Wed, Jul 1, 2020 at 4:29 PM Daniel Moisset  wrote:

> If I was to do this in Python, rather than the Rust way of forbidding
> refutable patterns, I would put as a rule that the target must have at
> least one variable to bind* . It makes sense in the context that the goals
> of an assignment are the bindings it does, and the ValueError is an
> accident that the binding may be impossible sometimes. It would fit better
> with existing destructuring, and the python philosophy of trusting the
> developer and protecting the semantics with a runtime check.
>
> * only allowing the historical () I mentioned earlier in the thread for
> compatibility with weird programs that no one ever wrote
>
> On Wed, 1 Jul 2020 at 23:24, Devin Jeanpierre 
> wrote:
>
>> On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen 
>> wrote:
>>
>>> I guess it might work in a separate PEP, but I'm also a little worried
>>> because the current PEP would make that impossible with its subtle
>>> incompatibilities with the existing unpacking syntax. Or even more
>>> inconsistent, if the assignment target syntax is extended to become similar
>>> to the match syntax but still slightly different for backwards
>>> compatibility.
>>>
>>
>> In my view 1 = x is a sneaky degenerate case, and what we should really
>> be asking is if it's cool to be able to do, say, (x, 0) = a compared with
>> "x, y = a; if y != 0: raise ValueError".
>>
>> BTW, +100% to the idea that match should extend assignment semantics
>> (e.g. to allow multiple clauses). The totally new match semantics have come
>> up a lot when I discussed this PEP with my friends at work. Even if we get
>> awkward corner cases out of unifying the two, the simplicity of only having
>> one notion of lvalue, instead of two lvalue-like things, is IMO an
>> overriding benefit. This is also more or less how match and assignment tend
>> to work in the languages that have pattern matching, .
>>
>> If we are repulsed by "1 = x" and (x, 0) = y, one solution is to do what
>> Rust did and forbid refutable patterns on the left-hand side of an
>> assignment, but allow them on the left hand side of a match case. (With the
>> historically-minded exception of list and tuple literals). This still makes
>> match an extension of assignment (it's assignment + multiple cases +
>> refutable patterns) and gives us the simplicity benefits, while forbidding
>> "1 = x".
>>
>> -- Devin
>> ___
>> 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/IM6NZJSZHID46K3QYGG4GUJ5D6GMMX4P/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/UK4BB72KOLGSUUYYJC5CN4PSMEP36XWV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/FD6PC3JTHDQAYQBBVLYLMPCZMGTHWTWW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Greg Ewing]

On 2/07/20 9:25 am, Matthias Bussonnier wrote:

It's still weird user experience as if you swap case .z and case z you don't 
get the Unbound error anymore.


It also won't work as intended, because 'case z' will always match
and it will never get to 'case .z'.

--
Greg
___
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/ULHQQC7RZ32BQIJSISRAE7PZWYQ2J5OV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Inada Naoki]

On Thu, Jul 2, 2020 at 5:20 AM M.-A. Lemburg  wrote:
>
>
> The reasoning here is the same as for decoding: you have the original
> data you want to process available in some array and want to turn
> this into the Python object.
>
> The path Victor suggested requires always going via a Python Unicode
> object, but that it very expensive and not really an appropriate
> way to address the use case.
>

But current PyUnicode_Encode* APIs does `PyUnicode_FromWideChar`.
It is no direct API already.

Additionally, pyodbc, the only user of the encoder API, did
PyUnicode_EncodeUTF16(PyUnicode_AsUnicode(unicode), ...)
It is very inefficient.  Unicode Object -> Py_UNICODE* -> Unicode
Object -> byte object.

And as many others already said, most C world use UTF-8 for Unicode
representation in C,
not wchar_t.

So I don't want to undeprecate current API.


> As an example application, think of a database module which provides
> the Unicode data as Py_UNICODE buffer.

Py_UNICODE is deprecated.  So I assume you are talking about wchar_t.


> You want to write this as UTF-8
> data to a file or a socket, so you have the PyUnicode_EncodeUTF8() API
> decode this for you into a bytes object which you can then write out
> using the Python C APIs for this.

PyUnicode_FromWideChar + PyUnicode_AsUTF8AndSize is better than
PyUnicode_EncodeUTF8.

PyUnicode_EncodeUTF8 allocate temporary Unicode object anyway. So it needs
to allocate Unicode object *and* char* buffer for UTF-8.
On the other hand, PyUnicode_AsUTF8AndSize can just expose internal
data when it is plain ASCII. Since ASCII string is very common, this
is effective
optimization.

Regards,
-- 
Inada Naoki  
___
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/UYOPQDKLSNOVPFGPCR5BIW3GHYB3V3KZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Daniel Moisset]

If I was to do this in Python, rather than the Rust way of forbidding
refutable patterns, I would put as a rule that the target must have at
least one variable to bind* . It makes sense in the context that the goals
of an assignment are the bindings it does, and the ValueError is an
accident that the binding may be impossible sometimes. It would fit better
with existing destructuring, and the python philosophy of trusting the
developer and protecting the semantics with a runtime check.

* only allowing the historical () I mentioned earlier in the thread for
compatibility with weird programs that no one ever wrote

On Wed, 1 Jul 2020 at 23:24, Devin Jeanpierre 
wrote:

> On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen 
> wrote:
>
>> I guess it might work in a separate PEP, but I'm also a little worried
>> because the current PEP would make that impossible with its subtle
>> incompatibilities with the existing unpacking syntax. Or even more
>> inconsistent, if the assignment target syntax is extended to become similar
>> to the match syntax but still slightly different for backwards
>> compatibility.
>>
>
> In my view 1 = x is a sneaky degenerate case, and what we should really be
> asking is if it's cool to be able to do, say, (x, 0) = a compared with "x,
> y = a; if y != 0: raise ValueError".
>
> BTW, +100% to the idea that match should extend assignment semantics (e.g.
> to allow multiple clauses). The totally new match semantics have come up a
> lot when I discussed this PEP with my friends at work. Even if we get
> awkward corner cases out of unifying the two, the simplicity of only having
> one notion of lvalue, instead of two lvalue-like things, is IMO an
> overriding benefit. This is also more or less how match and assignment tend
> to work in the languages that have pattern matching, .
>
> If we are repulsed by "1 = x" and (x, 0) = y, one solution is to do what
> Rust did and forbid refutable patterns on the left-hand side of an
> assignment, but allow them on the left hand side of a match case. (With the
> historically-minded exception of list and tuple literals). This still makes
> match an extension of assignment (it's assignment + multiple cases +
> refutable patterns) and gives us the simplicity benefits, while forbidding
> "1 = x".
>
> -- Devin
> ___
> 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/IM6NZJSZHID46K3QYGG4GUJ5D6GMMX4P/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/UK4BB72KOLGSUUYYJC5CN4PSMEP36XWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Greg Ewing]

On 2/07/20 4:54 am, Brandt Bucher wrote:

It sounds like you want to add "global z" to the top of the function definition.


Or more likely, change the last case to 'case _'.

--
Greg
___
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/OFTPNYVV2JSXN2R6ZYH6PYATOXBP37UO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Devin Jeanpierre]

 On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen 
wrote:

> I guess it might work in a separate PEP, but I'm also a little worried
> because the current PEP would make that impossible with its subtle
> incompatibilities with the existing unpacking syntax. Or even more
> inconsistent, if the assignment target syntax is extended to become similar
> to the match syntax but still slightly different for backwards
> compatibility.
>

In my view 1 = x is a sneaky degenerate case, and what we should really be
asking is if it's cool to be able to do, say, (x, 0) = a compared with "x,
y = a; if y != 0: raise ValueError".

BTW, +100% to the idea that match should extend assignment semantics (e.g.
to allow multiple clauses). The totally new match semantics have come up a
lot when I discussed this PEP with my friends at work. Even if we get
awkward corner cases out of unifying the two, the simplicity of only having
one notion of lvalue, instead of two lvalue-like things, is IMO an
overriding benefit. This is also more or less how match and assignment tend
to work in the languages that have pattern matching, .

If we are repulsed by "1 = x" and (x, 0) = y, one solution is to do what
Rust did and forbid refutable patterns on the left-hand side of an
assignment, but allow them on the left hand side of a match case. (With the
historically-minded exception of list and tuple literals). This still makes
match an extension of assignment (it's assignment + multiple cases +
refutable patterns) and gives us the simplicity benefits, while forbidding
"1 = x".

-- Devin
___
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/IM6NZJSZHID46K3QYGG4GUJ5D6GMMX4P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Daniel Moisset]

On Wed, 1 Jul 2020 at 15:50, Guido van Rossum  wrote:

> Before we all get a little too excited here, I think that allowing
> ```
> 1 = x
> ```
> as a sneaky way of writing
> ```
> assert x == 1
> ```
> would be a terrible mistake.
>

Well, we'll always have the sneaky way to check if an iterable is empty:

() = x

which admittedly would be useful for entries to the IOPPP (International
Obfuscated Python Program Pageant)


>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/WQCHP4A23CF7HSZTOMJUEFNC2MJPRIST/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/BRY3FJK2IUPXLFUJXPVNS5KDS2ZALMYW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Victor Stinner]

There is the https://github.com/pyhandle/hpy project which is
implemented on top of the existing C API.

But this project doesn't solve problems listed in PEP 620, since
CPython must continue to support existing C extensions.

Victor

Le mer. 1 juil. 2020 à 23:43, Eric V. Smith  a écrit :
>
> On 7/1/2020 3:43 PM, Stefan Behnel wrote:
> > Petr Viktorin schrieb am 30.06.20 um 14:51:
> >> For example, could we only deprecate the bad parts, but not remove them
> >> until the experiments actually show that they are preventing a beneficial
> >> change?
> > Big nod on this one.
>
> At one of the core sprints (maybe at Microsoft?) there was talk of
> adding a new API without changing the existing one.
>
> Eric
> ___
> 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/PF3ZWLIPEZWNYJU33T2MAPZMPBAXKQZM/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/GWKDKB52SX7RYBQKSZDULJZPM3KEUZMZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Robert Collins]

On Thu, 2 Jul 2020 at 09:28, Matthias Bussonnier
 wrote:
>
> It's still weird user experience as if you swap case .z and case z you don't 
> get the Unbound error anymore. SO it can work w/o global.

For some value of work: if z comes before .z, the .z branch will never
get evaluated, because the binding of z will take precedence, making
the .z branch dead code. This is something I would expect linters to
pick up on (eventually), or possibly the compiler itself.

And if you don't put z first, anything that hits the .z branch will
throw the UnboundLocalError.

-Rob
___
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/S5TLBC4G42S5VGPVOT7DIILMSON6MIO7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Eric V. Smith]

On 7/1/2020 3:43 PM, Stefan Behnel wrote:

Petr Viktorin schrieb am 30.06.20 um 14:51:

For example, could we only deprecate the bad parts, but not remove them
until the experiments actually show that they are preventing a beneficial
change?

Big nod on this one.


At one of the core sprints (maybe at Microsoft?) there was talk of 
adding a new API without changing the existing one.


Eric
___
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/PF3ZWLIPEZWNYJU33T2MAPZMPBAXKQZM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Glenn Linderman]

On 7/1/2020 1:20 PM, M.-A. Lemburg wrote:

As an example application, think of a database module which provides
the Unicode data as Py_UNICODE buffer. You want to write this as UTF-8
data to a file or a socket, so you have the PyUnicode_EncodeUTF8() API
decode this for you into a bytes object which you can then write out
using the Python C APIs for this.
But based on Victor's survey of usages in Python extensions, which found 
few to no uses of these APIs, it would seem that hypothetical 
applications are insufficient to justify the continued provision and 
maintenance of these APIs.


After all, Python extensions are written as a way to interface "other 
stuff" to Python, and converting data to/from Python objects seems far 
more likely than converting data from one non-Python format to a 
different non-Python format. Not that such applications couldn't be 
written as Python extensions, but ... are they? ... and why?


A rich interface is nice, but an unused interface is a burden.
___
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/MA7U7A6OCO46TEWXRKHGDRBYH5FMWJUP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Matthias Bussonnier]

It's still weird user experience as if you swap case .z and case z you don't 
get the Unbound error anymore. SO it can work w/o global.
___
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/N7JWYVR3YSO2Z6F46GBGZQVDQXDVHJYS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[M.-A. Lemburg]

On 30.06.2020 15:17, Victor Stinner wrote:
> Le mar. 30 juin 2020 à 13:53, M.-A. Lemburg  a écrit :
>>> I would prefer to analyze the list on a case by case basis. I don't
>>> think that it's useful to expose every single encoding supported by
>>> Python as a C function.
>>
>> (...)
>> This does not mean we have to give up the symmetry in the C API,
>> or that the encoding APIs are now suddenly useless. It only means
>> that we have to replace Py_UNICODE with one of the supported data
>> for storing Unicode.
> 
> Let's agree to disagree :-)
> 
> I don't think that completeness is a good rationale to design the C API.

Oh, if that's your opinion, then we definitely disagree :-)

I strongly believe that the success of Python was in major parts
built on the fact that Python does have a complete and easily
usable C API.

Without this, Python would never have convinced
the "Python is slow" advocates that you can actually build
fast applications in Python by using Python to orchestrate and
integrate with low level C libraries, and we'd be regarded as
yet another Tcl.

> The C API is too large, we have to make it smaller.

That*s a different discussion, but disagree on that perspective
as well: we have to refactor parts of the Python C API to make it
more consistent and remove hacks which developers sometimes added
as helper functions without considering the big picture approach.

The Unicode API has over the year grown a lot of such helpers
and there's certainly room for improvement, but simply ripping out
things is not always the right answer, esp. not when you touch the
very core of the design.

> A specialized
> function, like PyUnicode_AsUTF8String(), can be justified by different
> reasons:
> 
> * It is a very common use case and so it helps to write C extensions
> * It is significantly faster than the alternative generic function
> 
> In C, you can execute arbitrary Python code by calling methods on
> Python str objects. For example, "abc".encode("utf-8",
> "surrogateescape") in Python becomes PyObject_CallMethod(obj,
> "encode", "ss", "utf-8", "surrogatepass") in C. Well, there is already
> a more specialized and generic PyUnicode_AsEncodedObject() function.

You know as well as I do, that the Python call mechanism is by far
the slowest part in the Python C API, so telling developers to
use this as the main way to run tasks which can be run much faster,
easier and with less memory overhead or copying of data by directly
calling a simple C API, is not a good way to advocate for a useful
Python C API.

> We must not add a C API function for every single Python feature,
> otherwise it would be too expensive to maintain, and it would become
> impossible for other Python implementations to implement the fully C
> API. Well, even today, PyPy already only implements a small subset of
> the C API.

I honestly don't think that other Python implementations should
even try to implement the Python C API. Instead, they should build
a bridge to use the CPython runtime and integrate this into their
system.
>> Since the C world has adopted wchar_t for this purpose, it's the
>> natural choice.
> 
> In my experience, in C extensions, there are two kind of data:
> 
> * bytes is used as a "char*": array of bytes
> * Unicode is used as a Python object

Uhm, what about all those applications, libraries and OS calls
producing Unicode data ? It is not always feasible or even desired
to first convert this into a Python Unicode object.

> For the very rare cases involving wchar_t*, PyUnicode_FromWideChar()
> can be used. I don't think that performance justifies to duplicate
> each function, once for a Python str object, once for wchar_t*. I
> mostly saw code involving wchar_t* to initialize Python. But this code
> was wrong since it used PyUnicode function *before* Python was
> initialized. That's bad and can now crash in recent Python versions.

But that*s an entirely unrelated issue, right ? The C lib has
full support for wchar_t and provides plenty of APIs for using
it. The main() invocation is just one small part of the lib C
Unicode system.

> The new PEP 587 has a different design and avoids Python objects and
> anything related to the Python runtime:
> https://docs.python.org/dev/c-api/init_config.html#c.PyConfig_SetString
> 
> Moreover, CPython implements functions taking wchar_t* string by
> calling PyUnicode_FromWideChar() internally...

I mentioned wchar_t as buffer input replacement for the
PyUnicode_Encode*() API as alternative to the deprecated
Py_UNICODE.

Of course, you can convert all whcar_t data into a Python Unicode
object first and then apply operations on this, but the point of
the encode APIs is to have a low-level access to the Python codecs
which works directly on a data buffer - not a Unicode object.

Again, with the main intent to avoid unnecessary copying of data,
scanning, preparing, etc. etc. as is needed for
PyUnicode_FromWideChar().

>> PyUnicode_AsEncodedString() converts Unicode objects to a
>> 

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[M.-A. Lemburg]

On 28.06.2020 16:24, Inada Naoki wrote:
> Hi, Lamburg.
> 
> Thank you for quick response.
> 
>>
>> We can't just remove access to one half of a codec (the decoding
>> part) without at least providing an alternative for C extensions
>> to use.
>>
>> Py_UNICODE can be removed from the API, but only if there are
>> alternative APIs which C extensions can use to the same effect.
>>
>> Given PEP 393, this would be APIs which use wchar_t instead of
>> Py_UNICODE.
>>
> 
> Decoding part is implemented as `const char *` -> `PyObject*` (Unicode 
> object).
> I think this is reasonable since `const char *` is perfect to abstract
> the encoded string,
> 
> In case of encoding part, `wchar_t *` is not perfect abstraction for
> (decoded) unicode
> string.

Note that the PyUnicode_Encode*() APIs are meant to be make the
codec's encoding machinery available to C extensions, so that they
don't have to implement this again.

In that sense, their purpose is not to encode an existing Unicode
object, but instead, to provide access to the low-level buffer to
bytes object encoding.

The reasoning here is the same as for decoding: you have the original
data you want to process available in some array and want to turn
this into the Python object.

The path Victor suggested requires always going via a Python Unicode
object, but that it very expensive and not really an appropriate
way to address the use case.

As an example application, think of a database module which provides
the Unicode data as Py_UNICODE buffer. You want to write this as UTF-8
data to a file or a socket, so you have the PyUnicode_EncodeUTF8() API
decode this for you into a bytes object which you can then write out
using the Python C APIs for this.

>  Converting from Unicode object into `wchar_t *` is not zero-cost.
> I think `PyObject *` (Unicode object) -> `PyObject *` (bytes object)
> looks better signature than
> `wchar_t *` -> `Pyobject *` (bytes object) because for encoders.

See above. The motivation for these APIs is different. They are
not about taking a Unicode object and converting it into bytes,
they are deliberately about taking a data buffer as input and
producing the Python bytes object as output (to implement symmetry
between decoding and encoding).

> * Unicode object is more important than `wchar_t *` in Python.

Right, but as I tried to explain in my reply to Victor, I designed
the Unicode API in Python to be a rich API, which provides all
necessary tools to easily work with Unicode in C extensions as
well as in the CPython interpreter.

The API is not only focused on what the CPython interpreter needs.
It's an API which implements a concise interface to Unicode as
used in Python.

> * All PyUnicode_EncodeXXX APIs are implemented with PyUnicode_FromWideChar.
> 
> For example, we have these private encode APIs:
> 
> * PyObject* _PyUnicode_AsAsciiString(PyObject *unicode, const char *errors)
> * PyObject* _PyUnicode_AsLatin1String(PyObject *unicode, const char *errors)
> * PyObject* _PyUnicode_AsUTF8String(PyObject *unicode, const char *errors)
> * PyObject* _PyUnicode_EncodeUTF16(PyObject *unicode, const char
> *errors, int byteorder)
> ...
> 
> So how about making them public, instead of undeprecate Py_UNICODE* encode 
> APIs?

I'd be fine with keeping just a generic PyUnicode_Encode() API,
but this should then be encoding from a buffer to a bytes object.

The above all take Unicode objects as input and create the same
problem as I described above, with the temporary Unicode object being
created and all the associated malloc and scanning overhead needed
for this.

The reason I mention wchar_t as new basis for the PyUnicde_Encode()
API is that whcar_t has grown to be accepted as the standard for
Unicode buffers in C. If you don't believe that this is good enough,
we could also force Py_UCS4, but this would alienate Windows extension
writers.

> 1. Add PyUnicode_AsXXXBytes public APIs in Python 3.10.
>Current private APIs can become macro (e.g. #define
> _PyUnicode_AsAsciiString PyUnicode_AsAsciiBytes),
>or deprecated static inline function.
> 2. Remove Py_UNICODE* encode APIs in Python 3.12.

FWIW: I don't object to deprecating Py_UNICODE. I just don't
want to lose the symmetry in decoding/encoding and add the cost
of having to go via a Python Unicode object just to decode
to bytes.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Ethan Furman]

On 06/29/2020 06:21 AM, Nathaniel Smith wrote:


It's not Strunk and White per se, it's the idea of enforcing "standard
English", where "standard" here means "talks like a American with an
Ivy league education".


I believe the issue is writing, not talking.


There's nothing wrong with being ignorant – we can't be experts in
everything, and your education probably didn't spend a lot of time
talking about the long history of language "standards" and the many
ways they've been used, intentionally, systematically, and violently
to enforce racist/classist/etc. policies.


You mean like whole languages dying out because the "educators" and governments 
would persecute, prosecute, and even execute those who spoke it?  Elements of Style is a 
tool, and unless there is text in it the supports or encourages such behavior, or its 
authors supported or encouraged such behavior, then equating it with such behavior is 
preposterous.


I'm not going to try to educate you on that history – it's completely
off-topic for this list, and you can do your own work if you care to.


E. B. White was born in New York -- I believe that's in the northern part of the United 
States, otherwise known as "The North" or the side that fought to end slavery.

E. B. White was educated at Cornell.

A morning spent searching was unable to find references to E. B. White being a 
racist, having racist writings, or supporting racism.  Any links I missed would 
be appreciated.

An article that has good things to say about the advice of Elements of Style:

  
https://www.inquirer.com/opinion/grammar-language-racist-racially-charged-angry-grammarian-20181214.html

And an excellent article here:

  https://www.jstor.org/stable/376368?seq=1#metadata_info_tab_contents

talks about the built-in sexism in Elements of Style, but no commentary on 
racism (of course, the point of that article is about sexism).  The article is 
from 1979, so hopefully the newer editions are better on that count (my copy 
hasn't arrived yet).

A not-great article, White Fears of Dispossession: Dreyer's English, The 
Elements of Style,and the Racial Mapping of English Discourse, here:

  http://radicalteacher.library.pitt.edu/ojs/radicalteacher/issue/view/19/25

It start on page 22.  Its "proof" is in excerpts from other similar writings, 
but the excerpts from Elements of Style are only short phrases.

Again, any links to research would be appreciated.  I am happy to learn, but I 
require more than one person's statement that such a thing is so.  As an 
example, the above Enquirer article has plenty of examples proving its 
supposition.

-

I don't think there's much to be gained by discussing this any further; I, for 
one, would much rather discuss the technical details of cPython development.

--
~Ethan~
___
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/MWNSLYKJYRP7I3DAPMSUI7IQU24YIIGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Ethan Furman]

On 06/30/2020 07:07 AM, Giampaolo Rodola' wrote:

On Tue, Jun 30, 2020 at 3:16 PM Thomas Wouters  wrote:



Please report all CoC violations to the CoC WG.


Please don't. As far as I'm concerned, me and Thomas are fine. Also,
as I said, I don't like CoCs nor appealing to them.


This is a public list, and more people than just you and Thomas are involved.

--
~Ethan~
___
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/AS5SXKLZH6NUUV72FCZAMSLPZB6XJL2T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Stefan Behnel]

Petr Viktorin schrieb am 30.06.20 um 14:51:
> For example, could we only deprecate the bad parts, but not remove them
> until the experiments actually show that they are preventing a beneficial
> change?

Big nod on this one.

Stefan
___
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/AUTEISLLD2IGCB2RQVLX74YETCWKGVXH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Elliott Chen]

I guess it might work in a separate PEP, but I'm also a little worried because 
the current PEP would make that impossible with its subtle incompatibilities 
with the existing unpacking syntax. Or even more inconsistent, if the 
assignment target syntax is extended to become similar to the match syntax but 
still slightly different for backwards compatibility.

The sneaky assert wasn't the main point of my idea, it was just a weird 
side-effect I thought looked cool. It also kind of makes sense because to me, 
variable assignment/iterable unpacking is like trying to fit something in a 
box, but idk, it can just become discouraged practice or something. I think 
it's ultimately just a minor drawback. Assigning to an empty tuple is already 
possible.

The main point is that the match syntax would be able to be used in normal 
assignment syntax, which also means it can be used in other places such as for 
loops and with statements. There would be no difference between matching a 
*single* pattern and variable assignment, so there would no longer be two 
different syntaxes for doing the same thing. Flexible object destructuring 
would be able to be done anywhere an assignment can, just like how sequence 
unpacking is already possible. The powerful syntax is no longer exclusively 
reserved for the match statement, which is optimized for *multiple* patterns 
and is just extra boilerplate otherwise.

The match statement would be nothing more than a convenient way to try out 
multiple assignment/match patterns instead of just one, which would help unify 
it with the rest of the language and make the language more consistent with 
itself, while still being just as powerful.

It could even be turned into a variant of the if/elif/else block (something 
like "[or ]match expression as pattern"), which would make it more flexible, 
and more intuitive and easy to read at first glance, since the "as"/"=" 
explicitly spells out that it's variable binding, which would work *exactly* 
the same in a match statement as it does in a "for" or "with" or assignment 
statement. A learner would be able to read a match statement and easily figure 
out what it does. The current "match/case" statement requires extra learning to 
figure out how exactly it works, since it's completely different from the rest 
of the language, and the variable binding semantics between the expression and 
patterns is more implicit.
___
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/XINCSAPKEWVXTAA2F2XLQJJM6YFUDNOS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Brandt Bucher]

Walter Dörwald wrote:
> This looks strange to me. In all other cases of variable lookup the global 
> variable z would be found.

The next case assigns to z, making z local to whereis. This is consistent with 
python's existing scoping rules (for example, try rewriting this as the 
equivalent if-elif chain and you'll get the same error). It sounds like you 
want to add "global z" to the top of the function definition.

> whereis(23) however works.

This branch is hit before the unbound local lookup is attempted.
___
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/CZAZYFSWWEYTXDEXEZ75TNTVKSIZZ27K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Walter Dörwald]

On 1 Jul 2020, at 17:58, Guido van Rossum wrote:


If you are interested in learning more about how PEP 622 would work in
practice, but don't feel like compiling a Python 3.10 fork from 
source,

here's good news for you.

In a hurry?
https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb


If I change the example code to:

---
from dataclasses import dataclass

@dataclass
class Point:
x: int
y: int

z = 42

def whereis(point):
w = 23
match point:
case Point(0, 0):
print("Origin")
case Point(0, y):
print(f"Y={y}")
case Point(x, 0):
print(f"X={x}")
case Point():
print("Somewhere else")
case .w:
print("Not the answer")
case .z:
print("The answer")
case z:
print("Not a point")
---

whereis(42)


gives me:

---
UnboundLocalError Traceback (most recent call 
last)

 in 
> 1 whereis(42)

 in whereis(point)
 10 def whereis(point):
 11 w = 23
 12 match point:
 13 case Point(0, 0):
 14 print("Origin")
 15 case Point(0, y):
 16 print(f"Y={y}")
 17 case Point(x, 0):
 18 print(f"X={x}")
 19 case Point():
 20 print("Somewhere else")
 21 case .w:
 22 print("Not the answer")
---> 23 case .z:
 24 print("The answer")
 25 case z:
 26 print("Not a point")

UnboundLocalError: local variable 'z' referenced before assignment
---

This looks strange to me. In all other cases of variable lookup the 
global variable z would be found.


whereis(23) however works.


[...]


Servus,
   Walter
___
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/6OLWD67D7EFBM6UHGQHZHS7MM22QE4N2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 622 (match statement) playground

[Guido van Rossum]

If you are interested in learning more about how PEP 622 would work in
practice, but don't feel like compiling a Python 3.10 fork from source,
here's good news for you.

In a hurry?
https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb

This will open a Binder instance that runs a Jupyter kernel built from
Brandt Bucher's fork of Python 3.10 that includes the match statement. This
is a complete implementation of the PEP. (Note that we've already made some
design changes in response to feedback, but the basic syntax is still the
same. Expect a new draft within a week.)

The code for the playground was contributed by Fernando Perez, Matthias
Bussonnier and Chris Holdgraf. We also thank the Binder and Jupyter teams
for Binder and Jupyter and all the infrastructure that made this playground
possible, and we thank gesis.org for hosting.

For details, see https://github.com/gvanrossum/patma/tree/master/binder

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/47YR2LUTLWA4SGDHE66AXERVHW5EDK6I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Rhodri James]

On 01/07/2020 15:50, Guido van Rossum wrote:

Before we all get a little too excited here, I think that allowing
```
1 = x
```
as a sneaky way of writing
```
assert x == 1
```
would be a terrible mistake.


+1

One of Python's major virtues is that it's pretty easy to read and get 
the gist of what's going on, even if the details take a bit more work. 
If you have to second-guess every assignment, much of that virtue is lost.


--
Rhodri James *-* Kynesim Ltd
___
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/PF4UPIUEB5QNPVWU3FOSZX26VQOPFTNH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Guido van Rossum]

Before we all get a little too excited here, I think that allowing
```
1 = x
```
as a sneaky way of writing
```
assert x == 1
```
would be a terrible mistake.

We already have a static way to assert that something is a string:
```
self.name: str = value
```
I don't think that we'll need another way to express the same thing at
runtime, so I'm not excited about
```
self.name = str() = value
```

As to allowing object destructuring syntax like
```
Point(x, y) = p
```
that definitely has merit, but it is a complex subject that should be a
separate PEP.

On Wed, Jul 1, 2020 at 7:19 AM Nick Coghlan  wrote:

> On Thu, 2 Jul 2020 at 00:04, Elliott Chen 
> wrote:
> >
> > I saw in the PEP that "Allow more flexible assignment targets instead"
> was rejected, but I actually think it's a good idea. The current PEP means
> there will be two different, subtly incompatible ways to destructure
> objects (match statement and iterable unpacking). The reasoning given was
> that most cases involve an if-statement, but there's no reason we can't
> have both flexible assignment targets and a match statement. I think
> unifying the concepts will make the language more consistent and easy to
> learn.
> >
> > I also think destructuring an object with only one possible pattern can
> be very useful, without the boilerplate to set up an entire match suite and
> manually raise an exception. This will make the variable assignment
> statement much more powerful. I don't see a good reason to arbitrarily
> restrict variable assignment to only allow sequence patterns. This might
> not be a good idea, but it can even potentially be used as an assert
> statement, like this:
> >
> > def __init__(self, version, name, point):
> > self.version = 1 | 2 | 3 = type # assert that "version" is
> between 1 and 3
> > self.name = str() = string # assert that "name" is the correct
> type
> > Point(0, self.y) = point # assert that "point" is on the y-axis
> >
> > The constant value pattern would have to be changed to something else,
> like "@constant", and even though that's also rejected, I think the
> benefits outweigh the costs here. The special treatment of "_" would have
> to go too, but there's no reason it can't be used as a wildcard by
> convention anyway, similar to how it can already be used in for loops. I
> don't see any benefit in treating it specially. Or the question mark can be
> the wildcard instead.
>
> Exactly!
>
> The wildcard spelling idea I suggested in the other thread was that
> "?" could become a general constraint prefix used to introduce
> non-literal and non-keyword constraints.
>
> I was thinking purely in terms of destructuring and not in terms of
> data validation, but you're right that multiple assignments would
> allow for "multi-capture" (albeit with the usual caveats on iterable
> consumption).
>
> (I think match/case is fine as the spelling for the multi-target
> dispatch case, though)
>
> Cheers,
> Nick.
>
>
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/LOLDPPKHE6L75WW2FNEQHONNZK2LM6NI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/WQCHP4A23CF7HSZTOMJUEFNC2MJPRIST/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Nick Coghlan]

On Thu, 2 Jul 2020 at 00:04, Elliott Chen  wrote:
>
> I saw in the PEP that "Allow more flexible assignment targets instead" was 
> rejected, but I actually think it's a good idea. The current PEP means there 
> will be two different, subtly incompatible ways to destructure objects (match 
> statement and iterable unpacking). The reasoning given was that most cases 
> involve an if-statement, but there's no reason we can't have both flexible 
> assignment targets and a match statement. I think unifying the concepts will 
> make the language more consistent and easy to learn.
>
> I also think destructuring an object with only one possible pattern can be 
> very useful, without the boilerplate to set up an entire match suite and 
> manually raise an exception. This will make the variable assignment statement 
> much more powerful. I don't see a good reason to arbitrarily restrict 
> variable assignment to only allow sequence patterns. This might not be a good 
> idea, but it can even potentially be used as an assert statement, like this:
>
> def __init__(self, version, name, point):
> self.version = 1 | 2 | 3 = type # assert that "version" is between 1 
> and 3
> self.name = str() = string # assert that "name" is the correct type
> Point(0, self.y) = point # assert that "point" is on the y-axis
>
> The constant value pattern would have to be changed to something else, like 
> "@constant", and even though that's also rejected, I think the benefits 
> outweigh the costs here. The special treatment of "_" would have to go too, 
> but there's no reason it can't be used as a wildcard by convention anyway, 
> similar to how it can already be used in for loops. I don't see any benefit 
> in treating it specially. Or the question mark can be the wildcard instead.

Exactly!

The wildcard spelling idea I suggested in the other thread was that
"?" could become a general constraint prefix used to introduce
non-literal and non-keyword constraints.

I was thinking purely in terms of destructuring and not in terms of
data validation, but you're right that multiple assignments would
allow for "multi-capture" (albeit with the usual caveats on iterable
consumption).

(I think match/case is fine as the spelling for the multi-target
dispatch case, though)

Cheers,
Nick.



-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/LOLDPPKHE6L75WW2FNEQHONNZK2LM6NI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Flexible assignment targets

[Elliott Chen]

I saw in the PEP that "Allow more flexible assignment targets instead" was 
rejected, but I actually think it's a good idea. The current PEP means there 
will be two different, subtly incompatible ways to destructure objects (match 
statement and iterable unpacking). The reasoning given was that most cases 
involve an if-statement, but there's no reason we can't have both flexible 
assignment targets and a match statement. I think unifying the concepts will 
make the language more consistent and easy to learn.

I also think destructuring an object with only one possible pattern can be very 
useful, without the boilerplate to set up an entire match suite and manually 
raise an exception. This will make the variable assignment statement much more 
powerful. I don't see a good reason to arbitrarily restrict variable assignment 
to only allow sequence patterns. This might not be a good idea, but it can even 
potentially be used as an assert statement, like this:

def __init__(self, version, name, point):
self.version = 1 | 2 | 3 = type # assert that "version" is between 1 
and 3
self.name = str() = string # assert that "name" is the correct type
Point(0, self.y) = point # assert that "point" is on the y-axis

The constant value pattern would have to be changed to something else, like 
"@constant", and even though that's also rejected, I think the benefits 
outweigh the costs here. The special treatment of "_" would have to go too, but 
there's no reason it can't be used as a wildcard by convention anyway, similar 
to how it can already be used in for loops. I don't see any benefit in treating 
it specially. Or the question mark can be the wildcard instead.

If this is done, the "match statement" will become equivalent to trying 
different variable assignments. Maybe it can even be changed to look something 
like this (possibly with a keyword other than "with"):

def is_tuple(node) -> bool:
with Node(children=[LParen(), RParen()]) = node:
return True
or with Node(children=[Leaf(value="("), Node(), Leaf(value=")")]) = 
node:
return True
or with _ = node:
return False
def match_shape(shape):
with Point(x, y) = shape:
...
or with Rectangle(x, y, _, _) = shape:
...
def type_new(cls, *args):
with (obj,) = args:
return obj.__class__
or with (name, bases, namespace) = args:
return cls(name, bases, namespace)
or with number_of_args = len(args):
raise TypeError(f"need 1 or 3 arguments, not {number_of_args}")

which has the benefit that it's obviously the same as a variable assignment 
(which also makes it obvious that "Point(x, y)" isn't a constructor call), 
making the match syntax less confusing. It also makes it more intuitive because 
the similar semantics with existing iterable unpacking become obvious. The 
expression can be seen right next to the pattern, instead of having to be 
searched higher up. It can also have different expressions matched for 
different cases. Maybe it can even be possible to stack "or with" and "elif" 
clauses on top of each other.
___
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/B7PQKBSJANORF5LKN5GFRQBL7OUAY6IE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Emily Bowman]

On Wed, Jul 1, 2020 at 4:09 AM Antoine Pitrou  wrote:

> How does this help third-party extensions?
>

If the cost is high enough, exposing the guts of a function to allow the
compiler to inline it is not unreasonable; all of the major compilers have
ways to inline things that are technically across a dynamic boundary, if
you declare them properly. The trade-off is accepting that it may have to
be rebuilt at some point, but an ABI change is less painful than an API
change. Relying on this kind of "optimized interface" would have to be
opt-in, since most won't need it and it would be actively harmful for
portability. Actually, that's probably an attractive nuisance, better to
just make extension writers copy-paste the function into their own codebase
if they need performance that badly for a specific call.

Better to identify an actual existing case that's degraded by the change
and can be tested against than a hypothetical, though. The macos build is
already getting fixed thanks to that!
___
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/DZBO5HFAYZ57L26GHFKRYCUYOFBOEJT7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Thomas Wouters]

On Tue, Jun 30, 2020 at 3:09 PM Petr Viktorin  wrote:

> On 2020-06-30 02:46, Victor Stinner wrote:
> > You missed the point of the PEP: "It becomes possible to experiment
> > with more advanced optimizations in CPython than just
> > micro-optimizations, like tagged pointers."
>
> I don't think experiments are a good motivation.
>
> When the C API is broken, everyone that uses it pays the price -- they
> have to update their code. They pay the price even if the experiment
> fails, or if it's never started in the first place.
>
> Can we treat the C API not as a place for experiments, but as a stable
> foundation to build on?
>

The C API should indeed not be a place to experiment, but the current C API
leaks so many implementation details, it becomes impossible to have
meaningful experiments with different implementations. For example, the
purpose of the experiments I've done is to improve the implementation of
Python -- speed, memory use, threading, copy-on-write behaviour in forked
processes, etc -- in real world applications, with real-world third-party
dependencies. The specific things Victor is aiming to change are an active
impediment in those experiments, because I end up having to change a lot of
third-party code to be able to build or run the application, and even if I
find a beneficial change, I can't actually use it without incurring a
massive maintenance burden.


>
> For example, could we only deprecate the bad parts, but not remove them
> until the experiments actually show that they are preventing a
> beneficial change?


Well, right now we can show that they're impacting the *search* for a
beneficial change rather negatively :) And what's worse, it will take many
years to actually get rid of the old APIs, so if we do the work only once
we have a specific beneficial change, we won't be able to *use* the
beneficial change until much, much later. I would also argue that not
leaking implementation details (in the API, not the ABI) makes for much
better code all-round. And yes, there will be beneficial changes that
require changing the API that we can't anticipate -- that's fine. The thing
is we can stop leaking implementation details now and make everyone's life
easier in the future.

The main matter is the question of the *cost* of these changes, and how we
measure it. I agree with Victor that for this purpose, we should measure
the run-time cost in meaningful, real-world benchmarks (not
micro-benchmarks) in sensibly optimised builds. The impact of using PGO,
LTO and no-semantic-interpositioning is so big, it doesn't make sense to
care about 5% performance cost if you *aren't* using them.

The cost on developers of CPython and of third-party libraries is a
different matter, and something we can surely debate. We should agree on
whether the change is of benefit to CPython first, though.


>
> ___
> 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/FVATSACB5QPTZS6YLSH5YCHHODJNBLA6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/45QWOPD5MIJ5R5MO4IRE2AHPKQUDTN4I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Antoine Pitrou]

On Wed, 1 Jul 2020 12:50:01 +0200
Victor Stinner  wrote:
> Le mer. 1 juil. 2020 à 03:53, Inada Naoki  a écrit :
> > I confirmed the performance regression, although the difference is 12%.
> > And I find the commit cause the regression.
> >
> > https://github.com/python/cpython/commit/45ec5b99aefa54552947049086e87ec01bc2fc9a
> > https://bugs.python.org/issue40170
> >
> > The regression is not caused by "static inline" function is not
> > inlined by compiler.
> > The commit changed PyType_HasFeature to call regular function
> > PyType_GetFlags always.  
> 
> On Fedora 32 with GCC 10.1.1, even if PyType_GetFlags() is a function,
> the function call is inlined. This is thanks to LTO

How does this help third-party extensions?

___
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/B7NN4YZTD5667OC7NIWYELHMZCJD5JWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Victor Stinner]

Le mer. 1 juil. 2020 à 03:53, Inada Naoki  a écrit :
> I confirmed the performance regression, although the difference is 12%.
> And I find the commit cause the regression.
>
> https://github.com/python/cpython/commit/45ec5b99aefa54552947049086e87ec01bc2fc9a
> https://bugs.python.org/issue40170
>
> The regression is not caused by "static inline" function is not
> inlined by compiler.
> The commit changed PyType_HasFeature to call regular function
> PyType_GetFlags always.

On Fedora 32 with GCC 10.1.1, even if PyType_GetFlags() is a function,
the function call is inlined. This is thanks to LTO (and
-fno-semantic-interposition, since Fedora builds Python with
--enable-shared, which is not the case for the macOS installer).

The python.org macOS installers of Python 3.8.3 and Python 3.9.0b3 are
*not* built with LTO or PGO: see Mac/BuildScript/build-installer.py.
LTO and PGO can make Python between 10 and 30% faster, it's very
significant.

I created https://bugs.python.org/issue41181 with a PR to enable LTO
and PGO in the script building the macOS installer.

I confirm that using LTO+PGO, clang also inlines the PyType_GetFlags()
function call in tuplegetter_descr_get():
https://bugs.python.org/issue41181#msg372744

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/LAQHUDRGLZ73HBWMMQRDML2CSSAGD3GO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Stable ABI question.

[Serhiy Storchaka]

01.07.20 04:35, Inada Naoki пише:

Hi, folks.

I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since
Python 3.2.
But the same time, stable ABI is defined in Python 3.2 too.
The deprecated APIs are stable ABI too because `ceval.h` is not
excluded from the stable ABI PEP.

As far as my understanding, we can not remove them until Python 4.0. Am I right?

I will add comment like this.
/* This is a part of stable ABI. Do not remove until Python 4.0 */


We can remove them from public headers, but should keep their 
implementation and export their names to preserve the binary compatibility.

___
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/255WEQX2JTSNJHHZJ7NYGSAS5WPN7NI5/
Code of Conduct: http://python.org/psf/codeofconduct/