Response inline.
On Mon, 2021-05-03 at 23:30 +0100, Matt del Valle wrote:
> @Paul Bryan, I'll try to address your questions one-by-one
>
> > 1. It seems that I could get close to what you're aiming for by
> > just using underscores in names, and grouping them together in the
> > class definition.
On 04/05/2021 14:39, Paul Bryan wrote:
A problem I sense here is the fact that the interpreter would always
need to attempt to resolve "A.B.C" as getattr(getattr(A, "B"), "C")
and getattr(A, "B.C"). Since the proxy would be there to serve up the
namespace's attributes, why not just let i
Most of programming languages out there have switch-case statements. Python
doesn't have support for switch-case statements though. switch-case statements
can sometimes be nice and tidy and sometimes it may be a horrible nightmare.
But that also applies to if-elif-else statements. It would be ni
How is this differs from PEP 634
(https://docs.python.org/3.10/whatsnew/3.10.html#pep-634-structural-pattern-matching)?
On 2021. 05. 04. 20:33, Shreyan Avigyan wrote:
Most of programming languages out there have switch-case statements. Python
doesn't have support for switch-case statements t
Isn't PEP 643 for PEG grammar pattern matching? (I'm talking about switch
statements in Python)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/
Sorry PEP 634 not PEP 643
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/a
> Most of programming languages out there have switch-case statements.
> Python doesn't have support for switch-case statements though.
> switch-case statements can sometimes be nice and tidy and sometimes it
> may be a horrible nightmare. But that also applies to if-elif-else
> statements. It
> Isn't PEP 643 for PEG grammar pattern matching? (I'm talking about
> switch statements in Python)
I think you are referring to PEP 634, the one I linked to. I suggest you
read it (and the other link I sent).
I copy from PEP 636, marked as a sort of "tutorial" for PEP 634:
```
A match stateme
I'm confused. PEP 634 is about switch statements in Python or PEG?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Messa
Ok. Now I'm able to understand. PEP 634 should have a reference to PEP 636 or
else it's pretty hard to understand because the syntax section demonstrates
PEG implementation of this.
___
Python-ideas mailing list -- [email protected]
To unsubscrib
It does, right at the top: https://www.python.org/dev/peps/pep-0634/#abstract
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python
Ok.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-id
Ooops...Didn't notice it. Anyway this thread is considered closed.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Messa
This thread is closed therefore. (It was mistakenly opened due to
misunderstanding.)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-idea
I'm not sure if you're reading the right document, but PEP 634 refers to
636 in its second paragraph
On Tue, 4 May 2021, 19:56 Shreyan Avigyan,
wrote:
> Ok. Now I'm able to understand. PEP 634 should have a reference to PEP 636
> or else it's pretty hard to understand because the syntax section
Got it
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python
>
> I don't pretend to fully understand the proposal and how it would be
> implemented, but IMO adding an overhead (not to mention more complicated
> semantics) to *every* chained attribute lookup...
It's a good thing that isn't the case then :p
Sorry, couldn't resist that quip. But more serious
On Wed, May 5, 2021 at 11:34 AM Matt del Valle wrote:
> The only way you could ever resolve D in a single attribute lookup like
> getattr(A, "B.C.D") is if you literally typed that statement out verbatim:
>
> >>> getattr(A, "B.C.D")
>
> That would actually work, because `namespace A` would prepen
On 4/29/21 11:06 PM, Abdur-Rahmaan Janhangeer wrote:
> Greetings,
>
> A proposal to change the theme of the
> Python docs.
The current docs theme is decent I think. Liked your link to the masonite docs
theme slightly better, though not hugely different. However!
One thing that drives me
On Tue, May 4, 2021 at 11:05 PM Mike Miller
wrote:
> One thing that drives me nuts about the current Python docs
> theme is
> the FULL JUSTIFICATION that adds random spaces into each line to make
> the
> edges line
> up!
>
> Whatever y'all do, please remove that.
My comments follow, interleaved with Matt's.
On Mon, May 03, 2021 at 11:30:51PM +0100, Matt del Valle wrote:
> But you've pretty much perfectly identified the benefits here, I'll just
> elaborate on them a bit.
>
> - the indentation visually separates blocks of conceptually-grouped
> attributes
21 matches
Mail list logo
