[Python-Dev] Re: Enhancement request for PyUnicode proxies

2020-12-27 Thread Ronald Oussoren via Python-Dev 


> On 26 Dec 2020, at 18:43, Guido van Rossum  wrote:
> 
> On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev 
> mailto:[email protected]>> wrote:
> It's worth comparing the situation with byte arrays. There is no problem 
> of translating different representations of an element, but there is 
> still the issue of who owns the memory. The Python buffer protocol 
> usually solves this problem, so something similar for unicode "arrays" 
> might suffice.
> 
> Exactly my thought on the matter. I have no doubt that between all of us we 
> could design a decent protocol.
> 
> The practical problem would be to convince enough people that this is worth 
> doing to actually get the code changed (str being one of the most popular 
> data types traveling across C API boundaries), in the CPython core (which 
> surely has a lot of places to modify) as well as in the vast collection of 
> affected 3rd party modules. Like many migrations it's an endless slog for the 
> developers involved, and in open source it's hard to assign resources for 
> such a project.

That’s a problem indeed.  An 80% solution could be reached by teaching 
PyArg_Parse* about the new protocol, it already uses the buffer protocol for 
bytes-like objects and could be thought about a variant of the protocol for 
strings.  That would require that the implementation of that new variant 
returns a pointer in the Py_view that can used after the view is released, but 
that’s already a restriction for the use of new style buffers in the 
PyArg_Parse* APIs.

That wouldn’t be a solution for code using the PyUnicode_* APIs of course, nor 
Python code explicitly checking for the str type.

In the end a new string “kind” (next to the 1, 2 and 4 byte variants) where 
callbacks are used to provide data might be the most pragmatic.  That will 
still break code peaking directly in the the PyUnicodeObject struct, but anyone 
doing that should know that that is not a stable API.

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
>  
> -- 
> --Guido van Rossum (python.org/~guido )
> Pronouns: he/him (why is my pronoun here?) 
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/2FO5LQIO7UV4HKLROHUTPFKCBT2MH6DJ/
> Code of Conduct: http://python.org/psf/codeofconduct/

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

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

2020-12-27 Thread Dave Halter 
I'm late, but I still wanted to add that I share some of the criticism
that Mark has brought up.

I'm in love with Rust's pattern matching, so I feel like I'm not
against pattern matching generally. However I feel like while the PEP
is well written, there are some things that it does not tackle:

- Sum Types aka Tagged Unions are what makes pattern matching
necessary. I think we should rather have a discussion about inclusion
of Sum Types.
- Match in Python would not be an expression, which would be the most
useful application in Python IMO.
- It's quite a lot of additional syntax and complexity for a feature
that does not enable something fundamental.

I feel like in my 10 years of Python I have rarely wished to have
pattern matching. I would have wished to have Sum Types, because that
would have enabled me to structure my code in a more readable way.
Python enums are unfortunately not as useful and
dataclasses/namedtuples don't feel right either.

I also think that using isinstance is usually a sign of code smell and
I'm trying to avoid it whenever I can (except for `assert
isinstance`). Many of the examples in PEP 635 (Motivation & Rationale)
I would consider to be a bit smelly. The examples about tree traversal
are useful, but it's exactly where I wished I had Sum Types to make my
code more readable. Pattern matching wouldn't even be necessary in
these cases, because something like Rust's `if let ...` would be good
enough.

Since I'm obviously quite late for this discussion, I can understand
if this comment is ignored. I also understand that not everyone can be
happy with the final decision about pattern matching. I just think
that this is not the best addition. Thanks anyway to the people
working on this and continue to have a civil discussion.

Happy New Year & Stay Safe!
~ Dave

Am Fr., 30. Okt. 2020 um 15:43 Uhr schrieb Mark Shannon :
>
> Hi everyone,
>
> PEP 634/5/6 presents a possible implementation of pattern matching for
> Python.
>
> Much of the discussion around PEP 634, and PEP 622 before it, seems to
> imply that PEP 634 is synonymous with pattern matching; that if you
> reject PEP 634 then you are rejecting pattern matching.
>
> That simply isn't true.
>
> Can we discuss whether we want pattern matching in Python and
> the broader semantics first, before dealing with low level details?
>
>
>
> Do we want pattern matching in Python at all?
> -
>
> Pattern matching works really well in statically typed, functional
> languages.
>
> The lack of mutability, constrained scope and the ability of the
> compiler to distinguish let variables from constants means that pattern
> matching code has fewer errors, and can be compiled efficiently.
>
> Pattern matching works less well in dynamically-typed, functional
> languages and statically-typed, procedural languages.
> Nevertheless, it works well enough for it to be a popular feature in
> both erlang and rust.
>
> In dynamically-typed, procedural languages, however, it is not clear (at
> least not to me) that it works well enough to be worthwhile.
>
> That is not say that pattern matching could never be of value in Python,
> but PEP 635 fails to demonstrate that it can (although it does a better
> job than PEP 622).
>
>
> Should match be an expression, or a statement?
> --
>
> Do we want a fancy switch statement, or a powerful expression?
> Expressions have the advantage of not leaking (like comprehensions in
> Python 3), but statements are easier to work with.
>
>
> Can pattern matching make it clear what is assigned?
> 
>
> Embedding the variables to be assigned into a pattern, makes the pattern
> concise, but requires discarding normal Python syntax and inventing a
> new sub-language. Could we make patterns fit Python better?
>
> Is it possible to make assignment to variables clear, and unambiguous,
> and allow the use of symbolic constants at the same time?
> I think it is, but PEP 634 fails to do this.
>
>
> How should pattern matching be integrated with the object model?
> 
>
> What special method(s) should be added? How and when should they be called?
> PEP 634 largely disregards the object model, meaning it has many special
> cases, and is inefficient.
>
>
> The semantics must be well defined.
> ---
>
> Language extensions PEPs should define the semantics of those
> extensions. For example, PEP 343 and PEP 380 both did.
> https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement
> https://www.python.org/dev/peps/pep-0380/#formal-semantics
>
> PEP 634 just waves its hands and talks about undefined behavior, which
> horrifies me.
>
>
> In summary,
> I would ask anyone who wants pattern matching adding to Python, to not
> support PEP 634.
> PEP 634 just isn't a good fit for Python, and we deserve so

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

2020-12-27 Thread Paul Sokolovsky 
Hello,

On Sun, 27 Dec 2020 14:10:59 +0100
Dave Halter  wrote:

> I'm late, but I still wanted to add that I share some of the criticism
> that Mark has brought up.
> 
> I'm in love with Rust's pattern matching, so I feel like I'm not
> against pattern matching generally. However I feel like while the PEP
> is well written, there are some things that it does not tackle:
> 
> - Sum Types aka Tagged Unions are what makes pattern matching
> necessary. I think we should rather have a discussion about inclusion
> of Sum Types.

Python had sum types (well, superset of them) since ~forever (just like
any other object-oriented language). Your typical Haskell sum datatype:

data Tree a = Leaf a | Branch (Tree a) (Tree a)

directly translates to:

class Tree: pass
class Leaf(Tree):
def __init__(self, val): ...
class Branch(Tree):
def __init__(self, l, r): ...

"Leaf" and "Branch" are the tags you're looking for.

Recent dataclasses cut on the amount of boilerplate required.



-- 
Best regards,
 Paul  mailto:[email protected]
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/YNFTRO3FAJ3CIIC4NQOVOMYPR2QPALIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

2020-12-27 Thread Guido van Rossum 
On Sun, Dec 27, 2020 at 3:19 AM Ronald Oussoren 
wrote:

>
>
> On 26 Dec 2020, at 18:43, Guido van Rossum  wrote:
>
> On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev <
> [email protected]> wrote:
>
>> It's worth comparing the situation with byte arrays. There is no problem
>> of translating different representations of an element, but there is
>> still the issue of who owns the memory. The Python buffer protocol
>> usually solves this problem, so something similar for unicode "arrays"
>> might suffice.
>>
>
> Exactly my thought on the matter. I have no doubt that between all of us
> we could design a decent protocol.
>
> The practical problem would be to convince enough people that this is
> worth doing to actually get the code changed (str being one of the most
> popular data types traveling across C API boundaries), in the CPython core
> (which surely has a lot of places to modify) as well as in the vast
> collection of affected 3rd party modules. Like many migrations it's an
> endless slog for the developers involved, and in open source it's hard to
> assign resources for such a project.
>
>
> That’s a problem indeed.  An 80% solution could be reached by teaching
> PyArg_Parse* about the new protocol, it already uses the buffer protocol
> for bytes-like objects and could be thought about a variant of the protocol
> for strings.  That would require that the implementation of that new
> variant returns a pointer in the Py_view that can used after the view is
> released, but that’s already a restriction for the use of new style buffers
> in the PyArg_Parse* APIs.
>
> That wouldn’t be a solution for code using the PyUnicode_* APIs of course,
> nor Python code explicitly checking for the str type.
>
> In the end a new string “kind” (next to the 1, 2 and 4 byte variants)
> where callbacks are used to provide data might be the most pragmatic.  That
> will still break code peaking directly in the the PyUnicodeObject struct,
> but anyone doing that should know that that is not a stable API.
>

That's an attractive idea. I've personally never had to peek inside the
implementation, and I suspect there's not that much code that does so (even
in the CPython code base itself, outside the PyUnicode implementation of
course).

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

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4H5LKE3A7RVE2Q24M5YT22LXHCD4QDLI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

2020-12-27 Thread MRAB 

On 2020-12-27 19:15, Guido van Rossum wrote:
On Sun, Dec 27, 2020 at 3:19 AM Ronald Oussoren > wrote:





On 26 Dec 2020, at 18:43, Guido van Rossum mailto:[email protected]>> wrote:

On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev
mailto:[email protected]>> wrote:

It's worth comparing the situation with byte arrays. There is
no problem
of translating different representations of an element, but
there is
still the issue of who owns the memory. The Python buffer
protocol
usually solves this problem, so something similar for unicode
"arrays"
might suffice.


Exactly my thought on the matter. I have no doubt that between all
of us we could design a decent protocol.

The practical problem would be to convince enough people that this
is worth doing to actually get the code changed (str being one of
the most popular data types traveling across C API boundaries), in
the CPython core (which surely has a lot of places to modify) as
well as in the vast collection of affected 3rd party modules. Like
many migrations it's an endless slog for the developers involved,
and in open source it's hard to assign resources for such a project.


That’s a problem indeed.  An 80% solution could be reached by
teaching PyArg_Parse* about the new protocol, it already uses the
buffer protocol for bytes-like objects and could be thought about a
variant of the protocol for strings.  That would require that the
implementation of that new variant returns a pointer in the Py_view
that can used after the view is released, but that’s already a
restriction for the use of new style buffers in the PyArg_Parse* APIs.

That wouldn’t be a solution for code using the PyUnicode_* APIs of
course, nor Python code explicitly checking for the str type.

In the end a new string “kind” (next to the 1, 2 and 4 byte
variants) where callbacks are used to provide data might be the most
pragmatic.  That will still break code peaking directly in the the
PyUnicodeObject struct, but anyone doing that should know that that
is not a stable API.


That's an attractive idea. I've personally never had to peek inside the 
implementation, and I suspect there's not that much code that does so 
(even in the CPython code base itself, outside the PyUnicode 
implementation of course).



The re module does it extensively for speed reasons.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/4LUBFUFQL6TNIX6CGTTF3O5M6IFXOME3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Where is the SQLite module maintainer

2020-12-27 Thread Erlend Aasland 
Hi, everyone.

I'm trying to find a reviewer for this trivial PR: 
https://github.com/python/cpython/pull/20530
(The PR fixes CheckTraceCallbackContent (in the sqlite3 test suite) for SQLite 
pre 3.7.15.)


I've given up hunting for alternative reviewers (a process I find very 
uncomfortable, since I feel I'm just bugging people who have too much to do 
with things they're not interested in), so as a last resort, I'm trying the 
mailing list:

Who can help me review code that touches the sqlite3 module code base?


I've received a lot of constructive reviews from Victor Stinner, Dong-he Na and 
Pablo Galindo on my past sqlite3 PR's; thank you so much! I still feel 
uncomfortable requesting their review, as none of them are sqlite3 module 
maintainers.



Erlend
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/CF4AYW4NOLLPQ5GLXDT5D3SNFIKKFGXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where is the SQLite module maintainer

2020-12-27 Thread Christian Heimes 
On 27/12/2020 21.20, Erlend Aasland wrote:
> Hi, everyone.
> 
> I'm trying to find a reviewer for this trivial
> PR: https://github.com/python/cpython/pull/20530
> 
> (The PR fixes /CheckTraceCallbackContent/ (in the sqlite3 test suite)
> for SQLite pre 3.7.15.)
> 
> 
> I've given up hunting for alternative reviewers (a process I find very
> uncomfortable, since I feel I'm just bugging people who have too much to
> do with things they're not interested in), so as a last resort, I'm
> trying the mailing list:
> 
> Who can help me review code that touches the sqlite3 module code base?
> 
> 
> I've received a lot of constructive reviews from Victor Stinner, Dong-he
> Na and Pablo Galindo on my past sqlite3 PR's; thank you so much! I still
> feel uncomfortable requesting their review, as none of them are sqlite3
> module maintainers.

Hi Erlend,

as far as I know we don't have an active module owner and maintainer any
more. Gerhard Häring, the original author of pysqlite, is still listed
as expert. But he hasn't been active in many years. I haven't seen him
in quite some time, too.

How about you put your name in the expert index instead of him? :)

Christian

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

[Python-Dev] Enum bug?

2020-12-27 Thread Paul Bryan via Python-Dev 
Should this be considered a bug in the Enum implementation?

>>> class Foo(enum.Enum):
...   A = True
...   B = 1
...   C = 0
...   D = False
... 
>>> Foo.A

>>> Foo(True)

>>> Foo(1)


Seems to me like it should store and compare both type and value.

Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/5IJPHFRLPZE5CGYZH6IXCDH2V4ODXMTB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

2020-12-27 Thread Inada Naoki 
On Sun, Dec 27, 2020 at 8:20 PM Ronald Oussoren via Python-Dev
 wrote:
>
> On 26 Dec 2020, at 18:43, Guido van Rossum  wrote:
>
> On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev 
>  wrote:
>>
>
> That wouldn’t be a solution for code using the PyUnicode_* APIs of course, 
> nor Python code explicitly checking for the str type.
>
> In the end a new string “kind” (next to the 1, 2 and 4 byte variants) where 
> callbacks are used to provide data might be the most pragmatic.  That will 
> still break code peaking directly in the the PyUnicodeObject struct, but 
> anyone doing that should know that that is not a stable API.
>

I had a similar idea for lazy loading or lazy decoding of Unicode objects.
But I have rejected the idea and proposed to deprecate
PyUnicode_READY() because of the balance between merits and
complexity:

* Simplifying the Unicode object may introduce more room for
optimization because Unicode is the essential type for Python. Since
Python is a dynamic language, a huge amount of str comparison happened
in runtime compared with static languages like Java and Rust.
* Third parties may forget to check PyErr_Occurred() after API like
PyUnicode_Contains or PyUnicode_Compare when the author knows all
operands are exact Unicode type.

Additionally, if we introduce the customizable lazy str object, it's
very easy to release GIL during basic Unicode operations. Many third
parties may assume PyUnicode_Compare doesn't release GIL if both
operands are Unicode objects. It will produce bugs hard to find and
reproduce.

So I'm +1 to make Unicode simple by removing PyUnicode_READY(), and -1
to make Unicode complicated by adding customizable callback for lazy
population.

Anyway, I am OK to un-deprecate PyUnicode_READY() and make it no-op
macro since Python 3.12.
But I don't know how many third-parties use it properly, because
legacy Unicode objects are very rare already.

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/YQAWPENXXSRTEXOFUAWAUPXXJKFFAMIU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

2020-12-27 Thread Greg Ewing 

Rather than a full-blown buffer-protocol-like thing, could we
get by with something simpler? How about just having a flag
in the unicode object indicating that it doesn't own the
memory that it points to?

--
Greg
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/UJTXHTVGG63F6GMGIL4TW6KKLHU7V4DN/
Code of Conduct: http://python.org/psf/codeofconduct/