[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[Steven D'Aprano]

On Sun, Nov 29, 2020 at 12:10:39AM +0300, Paul Sokolovsky wrote:

> And we don't speak about some obscure "innovative" idea. Const'ness
> aka immutability is well-known and widely used feature in programming
> languages.

Constantness and immutability are not synonyms.

Immutability refers to *objects*. "abc" is an immutable object; `[]` is 
not, it is mutable.

Constantness refers to *name bindings*: once the name is bound to an 
object, it cannot be re-bound to a different object.

So you can have:

- variables bound to a mutable object;
- variables bound to an immutable object;
- constants bound to a mutable object;
- constants bound to an immutable object.

and you could have the same object bound to multiple names, some of 
which could be variables and some constants.

A mutable constant could still be mutated:

const spam = []
spam.append(None)  # Allowed.

but not rebound:

spam = [1, 2]  # Forbidden.


> So, let's go over it again. You probably say that C uses following
> syntax to define a variable in a particular scope:
> 
>  ;
> 
> e.g.:
> 
> int var;
> 
> Right, Python doesn't have that syntax. But it has other syntaxes to
> designate that a variable is defined in a particular scope:
> 
> # e is defined in the scope of the following block
> except Exception as e:  

That is incorrect. e is defined in the *current* scope. There is no 
"scope of the following block".

Exception blocks are a special case, because there is dedicated code to 
unbind (delete) the "e" name when the block is left. But the name is 
local to the current scope, the block does not create a new scope.

That same applies to all other blocks.


> # x is defined in the scope of a comprehension
> [x for x in seq]
> 
> Then for pattern matching,
> 
> case a, b:
> 
> *Could* define a, b in the scope of following block (and not beyond).
> That would have pros and cons, an obvious pro is that failing-to-match
> patterns would not litter in surrounding namespace, and con that
> "pattern matching as expression" usage would be more harder. If
> anything, use of block scoping could be considered to alleviate the
> littering problem

The "littering problem" will be a non-problem in practice.


> Let's strive for solutions which follow the best practices in the
> programming language design (const'ness, block-level scoping are 2
> good examples), 

There isn't even a single definition for block-scoping. C block scoping 
and Java block scoping are not the same. So which one is best practice?

At *best* it is a matter of personal taste whether you like or dislike 
block scoping, but I'm going to stick my head out and say that it is an 
unnecessary complication that will cause more annoyance and confusion in 
Python than benefit.


> "Undefined behavior" regarding how failed matches may affect
> surrounding namespace is unlikely something to be proud of.

We should not use the term *undefined behaviour* because that carries 
too much baggage from C, where undefined behaviour is a truly 
frightening thing.

In Python, it just means implementation defined. We have lots of 
implementation defined behaviour:

- caching of small ints and strings;

- whether changes to locals() effects local variables;

- performance of string concatenation;

- many floating point operations, e.g. trig functions, powers;

- presence or absense of many platform-dependent features;

- (in the past) Unicode narrow or wide builds;

- details of precisely when objects will be garbage collected;

- iteration order of sets;

and I expect there are others.

Let us be clear: failed matches do not affect *surrounding* namespaces 
unless you declare capture variables as global or nonglobal. They 
*might* affect the current namespace, but not surrounding namespaces. 
Failed matches will not leak out to surrounding namespaces.


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

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[Paul Sokolovsky]

Hello,


On Mon, 16 Nov 2020 12:21:35 +1300
Greg Ewing  wrote:

[]

> > please explain why you chose to proceed anyway (and apply
> > workarounds), instead of first introducing the concept of constants
> > to the language. (Given that amount of work to implement pattern
> > matching is certainly an order of magnitude larger than to
> > introduce constants)."  
> 
> That's not certain at all, and moreover it's not just a matter of
> work, it's a language design issue that would require its own
> extensive investigation and debate.

Everything would need discussion, maybe even debate. So, currently we
debate various conceptual holes in the pattern matching proposal (like
inability to match against a plain simple constant). We could
discuss/debate things which would allow to resolve that and other
issues in more proper way, that's the whole point.

And we don't speak about some obscure "innovative" idea. Const'ness
aka immutability is well-known and widely used feature in programming
languages. So, we at least can be sure we're on the right path. Whereas
now we're standing on one lag and wonder why our walking that way is
awkward.

> Members of the intended audience
> (people very familiar with Python and its technicalities) can be
> expected to understand this, so the PEP doesn't need to spell it out.

So, the passage you quoted (and the whole original mail) was mostly
related to the DLS'20 paper
(https://gvanrossum.github.io//docs/PyPatternMatching.pdf), not PEP. I
won't argue what PEP should do (under one interpretation, given
that PEPs are accepted by SC, it might be even empty if SC is ready to
accept it like that).

But for a scientific paper which already considers various choices,
omitting more detailed discussion of a pretty obvious choice caught
some attention.

> > How to support multiple variable scopes in one stack frame is not a
> > rocket science at all. One just need to remember how C did that  
> 
> We can't just do it "like C does" because C requires variables to
> be declared and Python doesn't.

Again, my original mail criticized such simplistic write-offs in the
DLS'20 paper, and in a reply to it, we again get the same story.

So, let's go over it again. You probably say that C uses following
syntax to define a variable in a particular scope:

 ;

e.g.:

int var;

Right, Python doesn't have that syntax. But it has other syntaxes to
designate that a variable is defined in a particular scope:

# e is defined in the scope of the following block
except Exception as e:  

# x is defined in the scope of a comprehension
[x for x in seq]

Then for pattern matching,

case a, b:

*Could* define a, b in the scope of following block (and not beyond).
That would have pros and cons, an obvious pro is that failing-to-match
patterns would not litter in surrounding namespace, and con that
"pattern matching as expression" usage would be more harder. If
anything, use of block scoping could be considered to alleviate the
littering problem, because the above should be equivalent to:

case _1, _2:
a, b = _1, _2

Where _1 and _2 *are* block-scoped *variables* (even if a and b aren't).

Since then, "The semantics of pattern matching for Python" topic
presented very similar ideas, except that it again tried to preserve
the tabu on block-level scoping and argued for stack-machine
workarounds. Instead of mentioning the shining-thru idea that it's
perfect usecase for generic block-level scoping. 


Finally (and that's why this thread is brought up again), in a parallel
thread on python-ideas
(https://mail.python.org/archives/list/python-id...@python.org/thread/3ZKYV6WQPPWR7SBPKRWW743OPSI22RDA/),
we see that block scoping would fit the bill to alleviate some issues
with the scoping of "for" loop variables.

> > The only reasons for not implementing the same solution in Python
> > would be intertia of thought and "but it's not done anywhere else in
> > Python".  
> 
> No, other reasons include that it would require making unrelated
> language changes that open various other wormcans.

Let's strive for solutions which follow the best practices in the
programming language design (const'ness, block-level scoping are 2
good examples), and that should increase benefits/effort ratio of the
solutions.

> > nobody del'eted local variables behind users' backs
> > either, before somebody started to do that for exception clause
> > variables.  
> 
> There was a good reason for that having to do with reference cycles.
> Nobody liked it much, but we didn't really have a choice. There is
> no such pressing need for special scope rules in match statements.

"Undefined behavior" regarding how failed matches may affect
surrounding namespace is unlikely something to be proud of.

Whether it's "pressing" or not, I won't debate. The point I want to
show is that we have some history of workarounds for scoping-related
matters. We're about to make workarounds (or just close eyes and say
"there's no problem") in regard to pattern 

[Python-Dev] Re: Ideas for improving the contribution experience

[mikecmcleod]

I was impressed by the good ideas put forward, however, some what not full 
solutions.
My position: I have free time now and I want to contribute to open 
source/freeware. But I don’t have great software in depth experience, however, 
I’m willing to learn.
I was think of contributing to Python but I can't seem to see exactly where I 
can contribute, except for the obvious place: docs. I have persevered reading 
the bug list, emails and I find this helpful after discovering 
https://cpython-core-tutorial.readthedocs.io/en/latest/where_should_i_start.html
Where I will see if I can progress, but I don’t have great hopes.

What I see is that CPython is written at the highest level of software 
development, and found my own experience is difficult to get started, because 
the bar is so high. It seems that you are having difficulty recruiting 
enough/good developers?
So if you are honest about wanting to get new people to help then you need make 
an investment to make it happen. 
My suggestion: create the developers by creating group(s) of mentors from 
across the whole team and actively train newcomers under a formal plan. The 
format/program of course must suit the mentors and mentee. This will mean less 
time for contributing to Python development but it will provide for a steady 
stream of people to add to the team, possibly saving time later on, or adding 
further content.

Regards,
Mike McLeod
___
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/RZ3G2DCO3J4LLX6N2GECF3ZPFKQVLAP5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Filipe Laíns]

On Sat, 2020-11-28 at 12:13 -0800, Brett Cannon wrote:
> So that's two people. If five people involved in the distribution of Python
> speak up I will go ahead and create a category on discuss.python.org (people
> can ask sooner, but my personal threshold here to do the work myself is 5 ).

Count me it :)

Filipe Laíns


signature.asc
Description: This is a digitally signed message part
___
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/WFAJU4M7J5UC7MRJGCTOYGJQKKWJBNXD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Paul Ganssle]

Considering the people involved and the nature of the list, I suspect
that adding a new @python.org mailing list would be better than
discourse. In my experience, it's very difficult to just follow a single
topic on the discourse, and most people complain that the e-mail
integration is not great. For something like, "Here's a head's up about
something affecting distributors", I don't think Discourse offers much
in the way of advantages.

My guess is that distributors would be happiest with a relatively
low-volume e-mail list that would point to discussions happening
elsewhere (or that announces changes relevant to distributors).

Best,
Paul

On 11/28/20 3:13 PM, Brett Cannon wrote:
> So that's two people. If five people involved in the distribution of
> Python speak up I will go ahead and create a category on
> discuss.python.org  (people can ask sooner,
> but my personal threshold here to do the work myself is 5 ).
>
> On Wed., Nov. 25, 2020, 00:18 Petr Viktorin,  > wrote:
>
> On 11/24/20 7:50 PM, Brett Cannon wrote:
> > If enough people were interested we could create a "Distributors"
> > category on discuss.python.org 
> .
>
> I'd join :)
>
> >
> > On Tue, Nov 24, 2020 at 9:08 AM Tianon Gravi
> mailto:admwig...@gmail.com>
> > >> wrote:
> >
> >      > I'd love to have an easy way to keep them in the loop.
> >
> >     I'm one of the maintainers on
> >     https://github.com/docker-library/python
> >     
> >     (which is what results in https://hub.docker.com/_/python
> >     ), and I'd
> >     love to have an easy way to keep myself in the loop too! O:)
> >
> >     Is there a lower-frequency mailing list where things like
> this are
> >     normally posted that I could follow?
> >     (I don't want to be a burden, although we'd certainly really
> love to
> >     have more upstream collaboration on that repo -- we do our
> best to
> >     represent upstream as correctly/accurately as possible, but
> we're not
> >     experts!)
> >
> >      > would it make sense to add a packaging section to our
> >     documentation or
> >      > to write an informational PEP?
> >
> >     FWIW, I love the idea of an explicit "packaging" section in
> the docs
> >     (or a PEP), but I've maintained that for other projects
> before and
> >     know it's not always easy or obvious. :)
> >
> >     ♥,
> >     - Tianon
> >        4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
> >
> >     PS. thanks doko for giving me a link to this thread! :D
> ___
> 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/66HPNHT576JKSFOQXJTCACX5JRNERMWV/
> 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/STBTZ6V525QBCCNRTIOVYXPXBB7Z3CE4/
> 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/Y3GTLEJIVLA7G4SPD3LEDWMPC7ZISHVS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Brett Cannon]

So that's two people. If five people involved in the distribution of Python
speak up I will go ahead and create a category on discuss.python.org
(people can ask sooner, but my personal threshold here to do the work
myself is 5 ).

On Wed., Nov. 25, 2020, 00:18 Petr Viktorin,  wrote:

> On 11/24/20 7:50 PM, Brett Cannon wrote:
> > If enough people were interested we could create a "Distributors"
> > category on discuss.python.org .
>
> I'd join :)
>
> >
> > On Tue, Nov 24, 2020 at 9:08 AM Tianon Gravi  > > wrote:
> >
> >  > I'd love to have an easy way to keep them in the loop.
> >
> > I'm one of the maintainers on
> > https://github.com/docker-library/python
> > 
> > (which is what results in https://hub.docker.com/_/python
> > ), and I'd
> > love to have an easy way to keep myself in the loop too! O:)
> >
> > Is there a lower-frequency mailing list where things like this are
> > normally posted that I could follow?
> > (I don't want to be a burden, although we'd certainly really love to
> > have more upstream collaboration on that repo -- we do our best to
> > represent upstream as correctly/accurately as possible, but we're not
> > experts!)
> >
> >  > would it make sense to add a packaging section to our
> > documentation or
> >  > to write an informational PEP?
> >
> > FWIW, I love the idea of an explicit "packaging" section in the docs
> > (or a PEP), but I've maintained that for other projects before and
> > know it's not always easy or obvious. :)
> >
> > ♥,
> > - Tianon
> >4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
> >
> > PS. thanks doko for giving me a link to this thread! :D
> ___
> 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/66HPNHT576JKSFOQXJTCACX5JRNERMWV/
> 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/STBTZ6V525QBCCNRTIOVYXPXBB7Z3CE4/
Code of Conduct: http://python.org/psf/codeofconduct/