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 patter
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 t
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 mai
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
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
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
HTTPStatu
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 att
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
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 m
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
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
> 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
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 othe
> 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 rear
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
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 --
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
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 j
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
___
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 -
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
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 PEP
22 matches
Mail list logo
