[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Paul Sokolovsky]

Hello,

On Thu, 12 Nov 2020 12:51:19 -0800
Guido van Rossum  wrote:

> I have a meta-observation. Clearly there are too many cooks here. The
> same suggestions keep getting brought up. We will never converge on a
> design this way.

Right, it's not a Python decision unless it's forced thru like PEP572,
aka the ":=" (https://lwn.net/Articles/757713/ , etc.). Can also
remember the whole Python3 migration business
(https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/
 ,
etc).

> At this point the only thing to do is to wait for
> the Steering Council. I am not going to argue about the merits of any
> more specific ideas -- everything has already been proposed and the
> PEP authors have come up with a design that carefully weighs a *lot*
> of different requirements.

Right, PEP622, PEP634, PEP635, PEP636 are very well written and discuss
many options thoroughly. The sentiment that many people on the list
have is that they then make a particular choice (like a PEP has to do
of course), while there're other very viable choices (and one proposed
by PEP has glaring adhockery). So, maybe, just maybe, it's too early
yet to shut on one option, and would be beneficial to keep considering
other options open-mindedly (for the PEP authors first of all, as
clearly, there won't a competing PEP proposal).


So, while we keep waiting for SC, we can remember the short history of
the mentioned PEP572. At times of PEP622, ":=" was touted as something
like enabler for the whole pattern matching business, as that's what
allows to do things like: "case [1, y := (1, x), 2]".

The suddenly, PEP634 silently (well, without much ado) replaces it with
the "as" keyword. So much for the great enabler. And now ":=" keeps
sticking a square peg in a round hole of the language, with this:

(a, b) = (1, 2)

- possible, and this:

((a, b) := (1, 2))

- oopsing:

  File "", line 1
SyntaxError: cannot use assignment expressions with tuple


Current PEP634 offers the same level of the language consistency and
generality, with random (but practical, if you believe the PEP authors)
hacks sprinkled around instead.


-- 
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YN7QQXNSWDFZNP75MRZC7AQPGBRU2H7S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Paul Sokolovsky]

Hello,

On Thu, 12 Nov 2020 20:19:13 +
MRAB  wrote:

[]

> > Question of "what to mark with sigils - terms-used-as-values or
> > terms-used-for-capturing" is orthogonal to the question of "what to
> > use as match-all symbol", though I understand the desire to
> > repurpose the same symbol for both.
> > 
> > For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were
> > or can be proposed. The benefit of "->", ">", ">>" is that they're
> > very intuitive. I'd also have preference for shorter one, because
> > 2-chars are really verbose IMHO. OTOH, ">" has issue with parsing
> > ambiguity unless separated by spaces ("Cls(kw1=>var)"). "$" is the
> > worst choice IMHO, because intuitively (based on other languages -
> > shell, etc.) it says "use the value of variable".
> >   
> I'd still want to list "as" as another possibility, the advantage
> being that it's already used for binding elsewhere.

Well, the whole idea is that ">foo" syntax is a shortcut of "_ as foo"
syntax of PEP634 or "foo := _" of PEP622. Such syntaxes otherwise would
be rather verbose, why syntactic sugar for them would be beneficial.


-- 
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GELIXN4O7C72E6QSVT3U2BXBY7GDFBRM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Guido van Rossum]

On Thu, Nov 12, 2020 at 4:25 PM Greg Ewing 
wrote:

> On 13/11/20 8:21 am, Paul Sokolovsky wrote:
> > The current stage is to accept
> > the fact that "mark capturing terms" is *very viable* alternative to
> > "mark terms to use as values" ... But people
> > behind PEPs keep ignoring that choice - silently, or with minimal
> > consideration/commentary.
>
> Their stated justification for this is that capturing will be
> used much more often than value matching. I'm not convinced about
> that -- how do they know? This is a feature unlike anything
> Python has had before. I don't think we can predict how people
> will use it.
>

Not too differently from how it's used in other languages that have it.


> Even if it's true, this seems to be prioritising writability
> over readability.
>

No, that was never on our mind.


> Marking the captures would be my preferred choice. I don't like
> the idea of DWIM heuristics for distinguishing values from
> captures, I'd prefer everything to be explicit. And it seems
> more logical to me to mark the captures rather than the values.
>
> The vast majority of expressions in Python are interpreted as
> values, and assignment targets only occur in a few specially
> marked places -- on the LHS of an assignment, after "as", etc.
> I think the same principle should apply in match statements.
>

Not so few; there are many syntactic positions representing assignments or
definitions. If you're looking for "what is x" you have to look at all of
them, including def/class, parameters, import without 'as', for.

>
> The only real disadvantage I can see is that it would make
> pattern matching substantially different from unpacking, but
> it's been stated that making these compatible is a non-goal,
> maybe even an anti-goal, and I'm fine with that.
>

We don't want to make them identical (because we can't, really), but we do
like that they are pretty similar, since it will smooth learning (things
don't have to be equal for learning by similarity to happen). This kind of
syntactic "rhyme" is pretty important to me. Marking captures with sigils
would destroy this.

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Greg Ewing]

On 13/11/20 9:19 am, MRAB wrote:
I'd still want to list "as" as another possibility, the advantage being 
that it's already used for binding elsewhere.


Only where it makes English grammatical sense, though, which
it doesn't unless there's something on both sides.

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Greg Ewing]

On 13/11/20 8:21 am, Paul Sokolovsky wrote:

The current stage is to accept
the fact that "mark capturing terms" is *very viable* alternative to
"mark terms to use as values" ... But people
behind PEPs keep ignoring that choice - silently, or with minimal
consideration/commentary.


Their stated justification for this is that capturing will be
used much more often than value matching. I'm not convinced about
that -- how do they know? This is a feature unlike anything
Python has had before. I don't think we can predict how people
will use it.

Even if it's true, this seems to be prioritising writability
over readability.

Marking the captures would be my preferred choice. I don't like
the idea of DWIM heuristics for distinguishing values from
captures, I'd prefer everything to be explicit. And it seems
more logical to me to mark the captures rather than the values.

The vast majority of expressions in Python are interpreted as
values, and assignment targets only occur in a few specially
marked places -- on the LHS of an assignment, after "as", etc.
I think the same principle should apply in match statements.

The only real disadvantage I can see is that it would make
pattern matching substantially different from unpacking, but
it's been stated that making these compatible is a non-goal,
maybe even an anti-goal, and I'm fine with that.

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

[Python-Dev] Words rather than sigils in Structural Pattern Matching

[David Mertz]

I have read a great deal of discussion on the pattern matching PEPs and
less formal discussions.  It is possible I have overlooked some post in all
of that, of course.

... OK, just saw Guido's "wait for new SC" comment, which I suppose applies
to this too :-).

One idea that I cannot recall seeing, but that seems to make sense to me
and fit with Python's feel is using a WORD to distinguish between a
variable value and a binding target.  That is, instead of a special symbol
prefixing or suffixing a name, either to indicate it is or is not a binding
target.  Of course, whether the extra word would be used for binding or for
NOT binding is a question still.

NOT_FOUND = 404
match http_code:
case 200:
print("OK document")
case value NOT_FOUND:  # use the variable value
print("Document not found")
case OTHER_CODE:  # bind this name
print("Other HTTP code", OTHER_CODE)

Of course, this would require a soft keyword, which is a disadvantage.
Going the other direction:

NOT_FOUND = 404
match http_code:
case 200:
print("OK document")
case NOT_FOUND:  # use the variable value
print("Document not found")
case bind OTHER_CODE:  # bind this name
print("Other HTTP code")

To me these read better than the punctuation characters.  But I guess some
folks have suggested enlisting 'as', which is a word, of course.




-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/5YUWE7K6LX3VZIISURABRBCEIGMYDUCS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Guido van Rossum]

I have a meta-observation. Clearly there are too many cooks here. The same
suggestions keep getting brought up. We will never converge on a design
this way. At this point the only thing to do is to wait for the Steering
Council. I am not going to argue about the merits of any more specific
ideas -- everything has already been proposed and the PEP authors have come
up with a design that carefully weighs a *lot* of different requirements.
The SC has indicated that they feel it's too close to the election date to
decide, but they will come up with a recommendation for the next SC (which
will likely have a significant overlap with the current SC). I will wait
for that.

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

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Guido van Rossum]

The correct place for the docs for __cause__ and __context__ is in the
section in the library reference about exceptions. There's quite a bit
about them there already. That's where the tutorial should link as well.

And now I ask you to stop complaining (your "the PEPs are the worst" does
not help your cause).

On Thu, Nov 12, 2020 at 12:30 PM Riccardo Polignieri via Python-Dev <
python-dev@python.org> wrote:

> > There is value in having non-trivial coverage of the language.  When
> people ask how
> > __cause__ works, we can link to the tutorial.
>
> I don't necessarily agree with the rest, but I think this is very
> important - at least, in the
> current situation. Maybe in the future we will be able to rearrange and
> move some parts
> of the tutorial into the "how to" section, and/or to write more
> introductions to the various
> sections of the documentation... but for now, the tutorial is all we have.
>
> > Otherwise, we have to throw them to the
> > wolves by linking to the unfriendly, highly technical reference guide or
> to a PEP.
>
> Indeed. The PEPs are the worst, more often than not. I remember when I
> first learned Pyhton,
> every time the documentation linked to a PEP, I felt a shiver down my
> spine.
>
> r.
> ___
> 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/LHGZNTRKU2Z2OD3W7DPFEDS274OBFE7F/
> 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/ILOS6URJIPNVV7XKBVPUR6FYEBVLZGIZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Riccardo Polignieri via Python-Dev]

> There is value in having non-trivial coverage of the language.  When people 
> ask how
> __cause__ works, we can link to the tutorial.  

I don't necessarily agree with the rest, but I think this is very important - 
at least, in the 
current situation. Maybe in the future we will be able to rearrange and move 
some parts 
of the tutorial into the "how to" section, and/or to write more introductions 
to the various 
sections of the documentation... but for now, the tutorial is all we have. 

> Otherwise, we have to throw them to the
> wolves by linking to the unfriendly, highly technical reference guide or to a 
> PEP.

Indeed. The PEPs are the worst, more often than not. I remember when I first 
learned Pyhton, 
every time the documentation linked to a PEP, I felt a shiver down my spine.

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[MRAB]

On 2020-11-12 19:21, Paul Sokolovsky wrote:

Hello,

[Re-routed back to python-dev.]

On Thu, 12 Nov 2020 20:04:57 +0100
Piotr Duda  wrote:

[]


> match foo:
> case ("foo", >val1):
> ...
> case ("bar", >val2):
> ...
>  


I agree with that, though I would prefer using other symbol than > (?
or $), one of reasons would by it would look better as "match all"
target, other one that in future. it would allow extending syntax for
simple guards like ?x < 100.


Question of "what to mark with sigils - terms-used-as-values or
terms-used-for-capturing" is orthogonal to the question of "what to use
as match-all symbol", though I understand the desire to repurpose the
same symbol for both.

For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were or
can be proposed. The benefit of "->", ">", ">>" is that they're very
intuitive. I'd also have preference for shorter one, because 2-chars
are really verbose IMHO. OTOH, ">" has issue with parsing ambiguity
unless separated by spaces ("Cls(kw1=>var)"). "$" is the worst choice
IMHO, because intuitively (based on other languages - shell, etc.) it
says "use the value of variable".

I'd still want to list "as" as another possibility, the advantage being 
that it's already used for binding elsewhere.



That said, those are 2nd-level choices. The current stage is to accept
the fact that "mark capturing terms" is *very viable* alternative to
"mark terms to use as values" (3rd choices - "use adhoc interpretation
of non-orthogonal syntactic conventions" - being the worst). But people
behind PEPs keep ignoring that choice - silently, or with minimal
consideration/commentary.


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

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Riccardo Polignieri via Python-Dev]

> I suspect that future documentation will have "How Tos" being more often
> written to cover more technical topics in detail. These more standalone
> "How Tos" can then be linked to from contents and search pages.

Indeed. Take for instance the most recent addition, regarding special 
parameters 
syntax. Now the entire section 4.7 has become long and complex, way beyond 
the limits of a beginner's tolerance. But a well-calibrated "functions 
parameters 
how to" could be an excellent remedy, even leading to the removal of this 
entire 
section from the tutorial. Now, this would be a deletion that I would welcome. 
I suspect there are quite a few (relatively) low hanging fruits like this one 
out there. 

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Paul Sokolovsky]

Hello,

[Re-routed back to python-dev.]

On Thu, 12 Nov 2020 20:04:57 +0100
Piotr Duda  wrote:

[]

> > match foo:
> > case ("foo", >val1):
> > ...
> > case ("bar", >val2):
> > ...
> >  
> 
> I agree with that, though I would prefer using other symbol than > (?
> or $), one of reasons would by it would look better as "match all"
> target, other one that in future. it would allow extending syntax for
> simple guards like ?x < 100.

Question of "what to mark with sigils - terms-used-as-values or
terms-used-for-capturing" is orthogonal to the question of "what to use
as match-all symbol", though I understand the desire to repurpose the
same symbol for both.

For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were or
can be proposed. The benefit of "->", ">", ">>" is that they're very
intuitive. I'd also have preference for shorter one, because 2-chars
are really verbose IMHO. OTOH, ">" has issue with parsing ambiguity
unless separated by spaces ("Cls(kw1=>var)"). "$" is the worst choice
IMHO, because intuitively (based on other languages - shell, etc.) it
says "use the value of variable".

That said, those are 2nd-level choices. The current stage is to accept
the fact that "mark capturing terms" is *very viable* alternative to
"mark terms to use as values" (3rd choices - "use adhoc interpretation
of non-orthogonal syntactic conventions" - being the worst). But people
behind PEPs keep ignoring that choice - silently, or with minimal
consideration/commentary.


-- 
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UATW726HVSS4R6WPVFDHRXFIGYFRVZ3B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Piotr Duda]

czw., 12 lis 2020 o 19:41 Paul Sokolovsky  napisał(a):
>
> Hello,
>
> On Thu, 12 Nov 2020 09:55:10 -0800
> Guido van Rossum  wrote:
>
> > The position of PEP 622/634/535/636 authors is clear: we see this as a
> > necessary feature to support using enums (e.g. Color.RED) or constants
> > defined in other modules (e.g. re.I) when simple switch functionality
> > is being migrated from literals (e.g. case 404) to named constants
> > (e.g. case HTTPStatus.NOT_FOUND). Bothering users with the
> > technicality of needing to use '==' here is a big usability hit.
>
> As was pointed out many times on the mailing list, there's a very
> obvious way around needing to use '==' there. It's explicitly marking
> capturing terms in case's:
>
> match foo:
> case ("foo", >val1):
> ...
> case ("bar", >val2):
> ...

I agree with that, though I would prefer using other symbol than > (?
or $), one of reasons would by it would look better as "match all"
target, other one that in future. it would allow extending syntax for
simple guards like ?x < 100.


-- 
闇に隠れた黒い力
弱い心を操る
___
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/PF5NNAXG2RKR3WFBEQ65JHZVI73Z7CYB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Paul Sokolovsky]

Hello,

On Thu, 12 Nov 2020 09:55:10 -0800
Guido van Rossum  wrote:

> The position of PEP 622/634/535/636 authors is clear: we see this as a
> necessary feature to support using enums (e.g. Color.RED) or constants
> defined in other modules (e.g. re.I) when simple switch functionality
> is being migrated from literals (e.g. case 404) to named constants
> (e.g. case HTTPStatus.NOT_FOUND). Bothering users with the
> technicality of needing to use '==' here is a big usability hit.

As was pointed out many times on the mailing list, there's a very
obvious way around needing to use '==' there. It's explicitly marking
capturing terms in case's:

match foo:
case ("foo", >val1):
...
case ("bar", >val2):
...

Besides solving the chore of needing "==" prefix, it allows for
the following benefits:

1. Much more intuitive for beginners. (If Python adopts it, I see
other "user-friendly" languages adopting the same pattern in the
coming decades).

2. Upholds the rights of people who see "match" as glorified "switch"
statement, and not keen on it doing assignments behind their backs. (The
topic which was recently mentioned on the list.)

3. Solves discrepancy with cases like:

# Why is this possible?
obj.foo, obj.bar = val

# And this is not?
match val:
case obj.foo, obj.bar:

4. Most uses of pattern matching known to people ("mental background")
are from languages with strong culture of immutability. And that's why
those languages manage to do it without much of sigils. For a language
with a looming conceptual debt of not having constness/immutability in
the core language semantics (aka, "Please move this subtopic to a
subject that doesn’t have “PEP 622” in its topic."
"https://mail.python.org/archives/list/python-dev@python.org/message/GFMOZ6XFIJKQ4ST7TFTCMRUGICZASE5G/
 ),
the idea to mark capturing terms, seems like a very smart way to route
around this conceptual deficiency, yet improve readability.


pp.3 and 4 also explain why it's

obj.foo, obj.bar = val

but would be:

match val:
case >obj.foo, >obj.bar:

With destructuring assignment, the *assignment* operator is right
there, and terms are on the left side of it, so it's all clear to
a reader.

With "match", there's no obvious assignment operator, and terms can be
also used as values, so adding explicit "assign here" marker looks like
rather natural idea to keep a reader in loop of what's happening there.


[]


-- 
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.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WEDBWEFGFL4VLNWP6V63RJ7TM4OKRIII/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Riccardo Polignieri via Python-Dev]

Hi Kyle, 

> ... I think that we should use the
> guideline of: "Is this useful information in 95% of real-world use cases or
> does it have a strong niche purpose that will be useful at some point for
> significant number of Python users?" If not, my opinion is that it should
> be removed ...

I'm afraid it might be just a little more complicated than expected to draw 
such a line. Of course "metaclasses are deeper magic than 99% of users 
should ever worry about" (and we don't have those in the tutorial indeed), 
but I would argue that 95% of python code out there makes use of 50-60% 
of what is now covered in the tutorial. (And 95% of code *by beginners* 
wouldn't reach the 30% threshold.)

> There shouldn't be a concern that we'll be "removing random bits of
> information from the tutorial",  (...) 
> I would personally wait until having 3+ opinions prior to merging any
> removals (...)

Thanks for this. Besides, I can see from the Git log that the tutorial is 
indeed 
seldom updated anyway, which is a pity on the one hand, a relief on the other. 

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

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Riccardo Polignieri via Python-Dev]

Inada, 
as I said before, mine was more a general consideration than a criticism of a 
particular change (let alone a particular committer!).

> But the tutorial isn't a "special attribute showcase".
> It doesn't cover all special attributes and describe how Python
> interpreter use the special attributes under the ground.
> So removing __cause__ made the tutorial more consistent right now.

Eh... as you know very well, at some point the tutorial lists *all* the methods 
of a list... and at another point, when presenting "sys" in the standard 
library 
tour, the really important thing it feels the need to say is that we have 
"sys.ps1" 
and "sys.ps2" to customize the prompt... and at another point, while dealing 
with the very simple task of telling us what is a docstring, it is keen to 
explain 
also how a docstring parser tool should work... 

So, let's just say that there are quite a few quirks in the tutorial, and 
establishing 
what is "consistent" is anyone's guess, ok? 

> I said I considered removing "explicit" chaining (e.g. from exc).
> But I said "implicit chaining is enough for 99% use cases".
> Definitely, I never tried to "remove an entire important concept from
> the tutorial."

Look, we are really trading in hypotheticals here, because no one has actually 
deleted anything important at the end of the day...
But for the sake of the argument, I venture that it might be slightly more 
complicated than expected to draw a line and say what is enough for 99% use 
cases, in a language as widely used as Python. 
This is not to say that I wouldn't gloss over exception chaining myself... if I 
were 
writing a tutorial for beginners. And I would certainly advocate for such a 
document 
to be added to the Python documentation, at some point in the future. 
My point, however, is that the document we have right now is *not* this 
tutorial, 
and yet it can still be of use to many people (who may or may not be 
"beginners"), 
just as it is now. And, that if you start removing things, on the one hand 
you are not doing beginners a favor big enough, while you might be damaging 
(even if only scratching) something useful for others.

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Guido van Rossum]

The position of PEP 622/634/535/636 authors is clear: we see this as a
necessary feature to support using enums (e.g. Color.RED) or constants
defined in other modules (e.g. re.I) when simple switch functionality is
being migrated from literals (e.g. case 404) to named constants (e.g. case
HTTPStatus.NOT_FOUND). Bothering users with the technicality of needing to
use '==' here is a big usability hit.

On Thu, Nov 12, 2020 at 7:38 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hi,
>
> Le 08/11/2020 à 07:47, Nick Coghlan a écrit :
> > Hi folks,
> >
> > I have updated PEP 642 significantly based on the feedback received
> > over the past week.
> >
> > [...]
> a change that I feel is insufficiently discussed is the choice to have
> "attr_constraint" as an inferred constraint. I can think of arguments to
> defer it for now at least:
>
> * it is a one way door (if dotted names are made a constraint pattern
> now, they can't become a capture pattern later);
>
> * it makes a difference from assignment target syntax, where you can
> assign to a dotted name;
>
> * the shorthand notation is less valuable than for literals, as dotted
> names are verbose already, 3 more characters make little difference;
>
> * the user has no explicit syntax to override the inferred semantics.
>
> I feel like some discussion of this choice in the PEP would make sense.
>
> Cheers,
> Baptiste
> ___
> 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/RQPUV7PABLBNYJ7FI7QYCS6TKJ4H2Q2A/
> 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/DPDHLPKAG3ATDH47NZNWGPK2FKBCY7WR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python.org downloads page and javascript

[Florian Bruhin]

Hey Michael,

On Thu, Nov 12, 2020 at 01:50:12PM +0100, Michael Felt wrote:
> Not clear on where to report this - so I hope someone else sees the same and
> can notify whoever needs to be notified.

There's a "Submit Website Bug" in the footer of the website, taking you
to the respective bugtracker: https://github.com/python/pythondotorg/issues

I took the freedom to open an issue about it there:
https://github.com/python/pythondotorg/issues/1672

Thanks for the report!

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
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/FBAMLHS7TWURKOCSMUJMD7WN3GLDRIX2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Baptiste Carvello]

Hi,

Le 08/11/2020 à 07:47, Nick Coghlan a écrit :
> Hi folks,
> 
> I have updated PEP 642 significantly based on the feedback received
> over the past week.
> 
> [...]
a change that I feel is insufficiently discussed is the choice to have
"attr_constraint" as an inferred constraint. I can think of arguments to
defer it for now at least:

* it is a one way door (if dotted names are made a constraint pattern
now, they can't become a capture pattern later);

* it makes a difference from assignment target syntax, where you can
assign to a dotted name;

* the shorthand notation is less valuable than for literals, as dotted
names are verbose already, 3 more characters make little difference;

* the user has no explicit syntax to override the inferred semantics.

I feel like some discussion of this choice in the PEP would make sense.

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

[Python-Dev] Re: Python.org downloads page and javascript

[Mariatta]

Thanks for the report. Can you please open an issue in
https://github.com/python/pythondotorg ?

Thanks.

On Thu, Nov 12, 2020, 5:18 AM Michael Felt  wrote:

> Hi,
>
> Not clear on where to report this - so I hope someone else sees the same
> and can notify whoever needs to be notified.
>
> The main URL for downloads: https://www.python.org/downloads/ Opens with
> message :
>
> *Notice:* While Javascript is not essential for this website, your
> interaction with the content will be limited. Please turn Javascript on for
> the full experience.
>
> However, javascript is enabled in my browser (FF latest). Also tried with
> Chrome - same (messy) layout.
>
> The main page, and selected pages (e.g., https://www.python.org/doc/)
> work as expected.
>
> Hope this helps!,
>
> Michael
> ___
> 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/6TFD7LVJOA33YFXSI4RGLBWRC7STFYCV/
> 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/6VI5NBS7BYCJCGB4AXMXHXZT7HA4CIPD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python.org downloads page and javascript

[Michael Felt]

Hi,

Not clear on where to report this - so I hope someone else sees the same 
and can notify whoever needs to be notified.


The main URL for downloads: https://www.python.org/downloads/ Opens with 
message :


*Notice:* While Javascript is not essential for this website, your 
interaction with the content will be limited. Please turn Javascript on 
for the full experience.


However, javascript is enabled in my browser (FF latest). Also tried 
with Chrome - same (messy) layout.


The main page, and selected pages (e.g., https://www.python.org/doc/) 
work as expected.


Hope this helps!,

Michael



OpenPGP_0x722BFDB61F396FC2.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
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/6TFD7LVJOA33YFXSI4RGLBWRC7STFYCV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My thoughts on Pattern Matching.

[Nick Coghlan]

On Wed., 11 Nov. 2020, 8:10 am Brett Cannon,  wrote:

>
>
> On Mon, Nov 9, 2020 at 10:40 PM Tobias Kohn  wrote:
>
>> One of the simplest patterns is without doubt the literal pattern that
>> essential only matches itself (e.g., ``case 123:`` or ``case
>> 'abc':``).  Any future unification of patterns and assignments would
>> therefore necessarily allow for statement such as::
>>
>> 1 = x
>>
>
> I don't think that's true. There isn't anything that "necessarily" *has*
> to happen; practicality beats purity. Thomas' statement is more about the
> fact that there are so *many *concepts fully contained within the world
> of pattern matching which do not apply outside of it. He didn't seem to
> imply to me that *all* concepts had to be brought out to the general
> language, just that there were ones that seem to make sense to pull out for
> assignment unpacking.
>

And this is the view that PEP 642 takes as well: that we want to preserve
the *option* of lifting aspects of pattern matching out to be more general,
rather than committing up front to it always being an all-or-nothing
proposition.

For my mind, the flavour of assignment statement that I think would be the
most plausible follow-up to matching against multiple patterns would take
the form "try pattern = subject", and even accepting PEP 634 exactly as
written wouldn't lock us out of that specific option. However the inferred
constraint patterns would give me even more pause there than they do in the
match statement proposals, so it would be nice to have the freedom to
disallow them without reducing the overall expressiveness of the construct.

There are limits to how much immediate complexity we'd want to incur to
preserve that optionality (YAGNI and all that), but the way PEP 634 is
currently defined creates *complications* that leak all the way from the
parser through to the code generator, rather than building a cleaner
conceptual abstraction layer at the AST level.

Cheers,
Nick.



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