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

[Paul Sokolovsky]

Hello,

On Sun, 29 Nov 2020 11:36:45 +1100
Steven D'Aprano  wrote:

> 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.

I agree. I'm just trying A/B testing to reach wider audience. I
prefer the term (and keyword) "const", and the full term "constant
variable". But if spelled like that, we immediately get nitpicks like
"That doesn't sound well in colloquial English! Constant... variable?
That's oxymoron!". These nitpicks miss that it's a term from a
programming language domain, not a colloquial phrase. But we'll cover
those nitpicks in detail elsewhere (in the python-ideas thread).

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

Btw, nowadays "immutable variable" is also a pretty established term,
thanks to a particular proglingo from some media company (forgot it's
name (lingo's, not company's), something like fungus). 

[]

> > 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.

It seems that I didn't convey my message well enough. What you render
is "old way of thinking". The new way of thinking which I promote is:
"'except as e' was an attempt to introduce block-level scoping, with
truly subpar implementation details (like introducing block scope
without real block scope)".

[]

> > *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.

"except as e" already confuses people:

-
e = 2.718281828

try:
if random() < 0.1:
1/0
except Exception as e:
print("Ha-ha! We're are not afraid of: %s" % e)

# Bugreport: phase-of-moon dependent, my e is gone, gone!!11 
print("In e we trust: %f" % e)
-

People already get confused by the "for" behavior, as the parallel
thread on python-idea.

With the bright future foretold for the pattern matching, you want to
take a bet how many people will get confused by the poltergeist effect
failed matches may have on the surrounding namespace? Well, I'd call
that "cowboy attitude in programming language design" ;-).

> > 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?

In theory, the best one is that of lambda calculus ;-). In practice, as
you suggest, detail may vary by practical considerations. We'd certainly
make it blend well with the rest of Python.

> 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.

That's useful opinion to hear, thanks. (But not the only one).

The problem is that we already apply adhoc workarounds which already
lead to annoyance and confusion. So you would need to compare amounts of
existing annoyance with (predicted!) future annoyance for explicit
block-scopes. My bet is that a well-proven technique, applied in a
general fashion (but integrated well with the rest of language) would
only alleviate levels of annoyance and confusion.

> > "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.

Me not useth, PEP634 doth:
https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior

> In Python, it just means implementation defined.

In C it's the same. And you know the tales where it led it. (I'm
personally still not afraid of it, but why purposefully establish it
where it's not due?)

[]

> 
> Let us be clear: failed matches do not affect *surrounding*
> namespaces unless you declare cap

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

[Nick Coghlan]

On Sun., 29 Nov. 2020, 6:31 am Paul Ganssle,  wrote:

> 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).
>

For Linux distros specifically, we do have linux-sig, but we've never had
great general channels for consistently reaching Windows, cloud &
cross-platform distributors - those contacts have generally been more ad
hoc & personal.


We've occasionally had recommendations for redistributors in specific PEPs,
so having some level of structured documentation around CPython
redistribution would likely make sense. For example:

* a page on devguide.python.org 
* a reference to that page from the What's New for each release, that
either mentions any changes since the last release, or else notes that the
recommendations are unchanged

Cheers,
Nick.



Cheers,
Nick.


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

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

[Frederik Rietdijk]

I would subscribe as well for Nixpkgs.

On Tue, Nov 24, 2020 at 6:02 PM 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/MVGTU4WY6VHPBQCWVQTQ3VJ44RWDINYC/
> 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/YCMQMWZW3O44D6WU7IDDYSLESJNXLOBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

 > My suggestion: create the developers by creating group(s) of
 > mentors

Do you know about

https://mail.python.org/mailman3/lists/core-mentorship.python.org/

and if you do, why isn't that what you suggest?
___
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/EC4OGSZGEX3C46LCDMBIHBGTYQJBZK7Y/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Miro Hrončok]

On 11/28/20 9:30 PM, Paul Ganssle wrote:
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).


I totally agree with that. Following a mailing list is simple. Following a 
category on discuss.python.org not so much.


I understand the argument that mailing lists are weird for new contributors 
etc., but I guess that distributors need to know how to handle mailing lists 
already anyway.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/U7RC7PZQXA44B34K7IHSGCLM3LMVZZY3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

Paul Sokolovsky writes:

 > Well, I'd call that "cowboy attitude in programming language
 > design" ;-).

That was uncalled for, especially since you're selling an idea without
an implementation yourself.

 > We'd certainly make it blend well with the rest of Python.

But how long will that take?  People have wanted f-strings since
forever (1.5 is as far back as I go, PEP 215 was July 2000).  We got
them in 3.6 (December 2016), the delay basically due to "blending"
issues.  And that was for a quite self-contained feature.

This one strikes me as likely to be messy.  How does we get
consistency if we don't change for?  How do block locals interact with
global, nonlocal, and locals()?  Do we need a block_locals()?

Currently all suites in a multiarmed statement (if, for, while, try)
are in the same scope.  I suspect that when I'm reading other people's
code I'd almost certainly read a let/const var = init_val as suite-
local in such contexts, while in my own code I'd probably want to use
it as statement-local a lot.  Of course that latter is easy to handle
by creating a new suite with something like "if 1" (as you suggest
elsewhere), but creating unconditional 1-statement suites just to
declare block-locals seems excessively inelegant. :-/  But requiring a
"block" statement to create a slope in common cases like a one-armed
if or for is equally inelegant (and surely more common).

 > The problem is that intuitively (just like with "for"),
 > "case a, b if a != b:" opens a new namespace for "a" and "b".

I don't find a new namespace in either of those contexts intuitive at
all.  Nor do I find it unintuitive at all.  A language will define
rules for scoping, I'll learn them.
___
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/DTNTZ5NKV7RELXOK3DUZ7KLSNI52344O/
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, 30 Nov 2020 01:54:53 +0900
"Stephen J. Turnbull"  wrote:

> Paul Sokolovsky writes:
> 
>  > Well, I'd call that "cowboy attitude in programming language
>  > design" ;-).  
> 
> That was uncalled for, especially since you're selling an idea without
> an implementation yourself.

Ok, I posted my "cowboy" implementation (i.e. a prototype) of
block-level scoping for the "for" now:
https://mail.python.org/archives/list/python-id...@python.org/thread/MMEIYOKGQBVR7KU2Y4WBAATZXLK3GAHV/
 ,
to make that even.

Also to clarify, that referred to difference in approaches in response
to particular issue(s) raised. One thing is to say "it's hard to
implement it better with the limited VM infrastructure and resources we
have" (that of course leads to further questions/discussion), it's
different thing to say to the same matter "issue exists, but it's not
really an issue".

>  > We'd certainly make it blend well with the rest of Python.  
> 
> But how long will that take?  People have wanted f-strings since
> forever (1.5 is as far back as I go, PEP 215 was July 2000).  We got
> them in 3.6 (December 2016), the delay basically due to "blending"
> issues.  And that was for a quite self-contained feature.

If anything, "Unlikely Adventures of Python in 3.x Era", is what
motivates me to continue this discussion. Alternatively, consider what a
conceptual jump happened in 2.1, when function-level nested scoping was
introduced. Maybe one of these years would be good time, after so many
usability changes, to also tighten up theoretical side with
block-level scoping.

> This one strikes me as likely to be messy.  How does we get
> consistency if we don't change for?  How do block locals interact with
> global, nonlocal, and locals()?  Do we need a block_locals()?

The simplest answer is that they don't (interact with existing
overdynamic features). They are new enough, opt-in concepts, and so can
start from blank page. Alternatively, if debuggers, etc. are tied to
locals() (vs more low-level code object introspection), could add
implementation-defined support for them in locals() for simple
implementations like CPython (block-local names will be mangled).

> Currently all suites in a multiarmed statement (if, for, while, try)
> are in the same scope.  

Well, I definitely advocate a solution where a Python suite == block
scope, which for example means that "true" vs "false" suites of the "if"
are different scopes.

> I suspect that when I'm reading other people's
> code I'd almost certainly read a let/const var = init_val as suite-
> local in such contexts, while in my own code I'd probably want to use
> it as statement-local a lot.

It's unclear how block-level scoping can be useful for single-statement
scopes (beyond special cases like comprehensions), because well, that
single statement will be assignment to such a variable (but nothing
will read it). I even suspect we might imagine different things when
talk about this, perhaps examples would help.

>  Of course that latter is easy to handle
> by creating a new suite with something like "if 1" (as you suggest
> elsewhere), but creating unconditional 1-statement suites just to
> declare block-locals seems excessively inelegant. :-/

This is somewhat backwards to the motivation I try to promote. My
motivation is:

1. We have adhoc block-scope-alikes already.
2. We have on the plate cases where block scope may help.
3. So, convert to "real" block scoping there.
4. Don't stop there, and *let* people use explicit block-level vars if
they need.

It's "let", don't "make" people use it. If you *really* need block-level
local, perhaps just being able to use it (without rehashing half of the
language) is good enough, for starters.

That said, if you want my bet for the best block-level introduction
way, not requiring new keywords, it's:

with:  # yeah, empty with!
let x = 1 

> But requiring a
> "block" statement to create a slope in common cases like a one-armed
> if or for is equally inelegant (and surely more common).

Arm on an "if" is already a block scope, per above.

>  > The problem is that intuitively (just like with "for"),
>  > "case a, b if a != b:" opens a new namespace for "a" and "b".  
> 
> I don't find a new namespace in either of those contexts intuitive at
> all.  Nor do I find it unintuitive at all.  A language will define
> rules for scoping, I'll learn them.

In "case a, b if ...:", if the case *doesn't* match, do you expect a
and b be assigned? If you don't, then you intuitively expect special
scoping rules for at least the "case" line itself, and the block scope
is the best well-proven formalism in the proglanguage theory/practice
which matches that requirement.


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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.py

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

[Stephen J. Turnbull]

Paul Sokolovsky writes:

 > Also to clarify, [cowboy attitude] referred to difference in
 > approaches in response to particular issue(s) raised. One thing is
 > to say "it's hard to implement it better with the limited VM
 > infrastructure and resources we have" (that of course leads to
 > further questions/discussion), it's different thing to say to the
 > same matter "issue exists, but it's not really an issue".

Of course those are *different*.  Where I differ with you is on
whether "I understand the case are describing and that you want to do
something about it, but we don't consider that a problem" is "cowboy
attitude".

My experience is that the development community will care when it
perceives that a change serves the greater community (eg, f-strings
and data classes, which are universally loved), or when a sufficiently
large coalition of committers can be convinced.  That's what you need
to do, and accusing the core developers of cowboy attitude is not a
good start IMO.

 > Maybe one of these years would be good time, after so many
 > usability changes, to also tighten up theoretical side with
 > block-level scoping.

Maybe it is.  I certainly hope not, because I like Python as it is,
where I rarely have to deal with declarations separate from
instantiation, and code is highly dynamic without a compiler
complaining, perhaps even going on strike, any time I want to do
something whose semantics I know to be sound even though the compiler
can't prove that from the syntax.

Yes, I know you claim that your proposed syntax won't be in my face,
and quite possibly you're right with respect to the obstreperous
compiler.  But I also know that you make claims that are provably
false, such as not making me use the syntax.  True, short of XKCD 538
you can't make me write it, but if it exists somebody will make me
read it.

 > The simplest answer is that they don't (interact with existing
 > overdynamic features).

You say "overdynamic", I say "works for me".

 > They are new enough, opt-in concepts, and so can start from blank
 > page.

You're BS-ing here -- you back off in the next sentence (quoted
below).  And from the community's point of view, no syntax is truly
opt-in because we often work with Other People's Code.  We need to
read it, and often in open source we are modifying code whose style is
"owned" by someone else -- if I were to work on code you maintain, I'm
pretty sure you wouldn't hesitate to query "shouldn't this variable be
block local" or even refuse to accept code that didn't have the block
locals you think it should have.

A lot of effort and persuasion (and more or less silent acceptance of
the slings and arrows from outraged dynamicists) went into the
introduction of type hints.  I think this will require more of the
same (although maybe not: type hints are intentionally pervasive for
those who use them, these declarations will presumably be occasional).

 > Alternatively, if debuggers, etc. are tied to locals() (vs more
 > low-level code object introspection), could add
 > implementation-defined support for them in locals() for simple
 > implementations like CPython (block-local names will be mangled).

Sure, but we don't have an implementation of that support yet, do we?
And adding the syntax will impose burdens on other implementations
that claim to support the full language, as well as quite possibly
inducing implementation differences here, unless you specify the
debugger support etc.  My point is that these are the kinds of
complications that frequently delay acceptance of features for a
release or two.

 > > I suspect that when I'm reading other people's code I'd almost
 > > certainly read a let/const var = init_val as suite- local in such
 > > contexts, while in my own code I'd probably want to use it as
 > > statement-local a lot.
 > 
 > It's unclear how block-level scoping can be useful for single-statement
 > scopes (beyond special cases like comprehensions), because well, that
 > single statement will be assignment to such a variable (but nothing
 > will read it). I even suspect we might imagine different things when
 > talk about this, perhaps examples would help.

By "if statement" I mean

if foo():
pass
elif bar():
pass
else:
pass

That is a single conditional *statement* with three suites that each
might constitute an individual block or together constitute a single
block (encompassing the if and elif condition expressions as well).  I
believe that's how the Python Language Reference uses "statement".

 > 1. We have adhoc block-scope-alikes already.

Yes, there's the problematic deletion of exception-capture variables,
but I don't think the plural is justified.  Comprehensions are
*expressions*, not suites.  Python is a *high level* language: the
fact that

[x for x in y]

effectively expands to

list((x for x in y)) ,

implicitly defining a generator function and iterating that, doesn't
bother me at all.  It's an expression, and