On Sat, 29 Apr 2023 at 23:36, MRAB wrote:
>
> On 2023-04-29 08:31, Matsuoka Takuo wrote:
> > On Sat, 29 Apr 2023 at 00:52, MRAB wrote:
> >>
> >> What happens if you do '{open}...{close}'.partial_format(open='{close}'?
> >> You get '{close}...{close}', a
On Sat, 29 Apr 2023 at 00:52, MRAB wrote:
>
> What happens if you do '{open}...{close}'.partial_format(open='{close}'?
> You get '{close}...{close}', and you're going to have a problem using
> that as a format string and replacing only the second '{close}'.
>
> Or how about
What if it's done not by format method but by a separete method, say,
format_partially or something? The method is different from format
also in that it should leave "{{" and "}}" unaltered.
On Fri, 28 Apr 2023 at 00:05, Matthias Görgens
wrote:
>
> Does it have any use case that's not already
I would like to propose a new type of pattern for structural pattern
matching. A motivation will be described later below.
The pattern may be written in a form like
{}
(with braces), where is either a literal pattern
or an identifier (or "NAME" in the structural pattern matching
terminology
On Mon, 9 May 2022 at 08:35, Jeremiah Vivian
wrote:
>
> I've always thought of relaxing the restrictions. It's actually easy to
> implement (even including attribute assignment/subscript assignment) and I
> had to modify only two files (plus regenerate the parser).
I think attribute assignment
I've been unable to find a discussion on the following subject.
I think structural pattern matching could sometimes be more useful to
be available to form an expression than to form a statement. To be
specific, given the definition of a function of the form
```
def f():
match :
case
Thanks for your comments!
On Fri, 22 Apr 2022 at 23:27, Steven D'Aprano wrote:
>
> On Fri, Apr 22, 2022 at 08:46:38PM +1100, Matsuoka Takuo wrote:
> >
> > So I may not have been told a refactoring like that shouldn't involve
> > a new instance of overriding, but may I ha
On Fri, 22 Apr 2022 at 15:47, Christopher Barker wrote:
>
> Sure -- but there's nothing special or difficult here -- refactoring can
> create breaking changes. I believe it was part of Hettinger's thesis in
> "Super Considered Super" that the use of super() is part of the API of a
> class
On Thu, 21 Apr 2022 at 02:45, malmiteria wrote:
>
> 4) Lib refactoring are breaking changes
> A Lib author refactoring his code by extracting a class as a parent class of
> multiple of the class provided is introducing a breaking change.
> Because any user's code inheriting from at least 2 of
m(self):
print("my corrupted soul makes me wanna scream")
super().scream()
class ProudGobelin(HighGobelin):
def scream(self):
print("I ... can't ... contain my scream!")
super().scream()
```
Best regards,
Takuo Matsuoka
>
> On Wed, Apr 13,
On Wed, 13 Apr 2022 at 04:28, malmiteria wrote:
>
> Idk, what do you think?
I would need to see more examples to determine the limit of the
current strategy for method resolution and super. For the example at
hand, I can be happy with the following code as a lib user (using your
lib code).
```
On Wed, 13 Apr 2022 at 02:00, Matsuoka Takuo wrote:
>
> Thanks for your answer.
>
> On Mon, 11 Apr 2022 at 00:46, malmiteria wrote:
> >
> > There's a few problems, mainly, if you provide ProudGobelin and
> > CorruptedGobelin as a lib author, you're very likely not
Thanks for your answer.
On Mon, 11 Apr 2022 at 00:46, malmiteria wrote:
>
> There's a few problems, mainly, if you provide ProudGobelin and
> CorruptedGobelin as a lib author, you're very likely not to think of the
> HalfBreed use case, so the lib users wanting to create the HalfBreed class is
For your particular case of a diamond, the solution below seems
simpler to me than yours. What problems may it create which your
solution won't? Or you might refine the problem. It's not easy to
see the real value of your suggestions.
```
class HighGobelin:
def scream(self):
On Fri, 11 Feb 2022 at 04:02, Christopher Barker wrote:
>
> Just one note:
>
> On Thu, Feb 10, 2022 at 6:56 AM Chris Angelico wrote:
>>
>> > (2) For the form of the assignment target, I think an analogy with the
>> > reception of function arguments could also be considered.
>
>
> I think so --
I'm sorry for the inaccuracy, and thank you for the corrections!
On Fri, 11 Feb 2022 at 01:56, Chris Angelico wrote:
>
> On Fri, 11 Feb 2022 at 00:33, Matsuoka Takuo wrote:
> >
..
>
> But the crucial thing is to figure out the syntax. Without good
> syntax, this is not
On Mon, 7 Feb 2022 at 16:43, Chris Angelico wrote:
>
> There have been thoughts thrown around in the past of having a "match
> assignment" concept. The OP is far from the first to notice the
> parallel. Maybe that's what we should be looking at - but the biggest
> question is syntax. What should
I hope the following remarks are constructive to the subject.
It seems what's not liked about f{*x} notation is mainly that it looks
parallel to f(*x) or e.g., often possibly f[(*x, )] , which seems to
be a problem mostly only because of the character "f". If the prefix
were "frozenset", then
On Sun, 26 Dec 2021 at 14:19, Steven D'Aprano wrote:
>
> Using a hypothetical pipeline syntax with an even more hypothetical
> arrow-lambda syntax:
>
> [1, 2, 3] | map(x=>x+1) | filter(a=>a%2) | list
>
What is the pipeline syntax like indeed? It looks as if your ``|`` is
an operator which
On Wed, 1 Dec 2021 at 19:38, Abdulla Al Kathiri
wrote:
>
> number = text -> re.search(pattern1, _)
> -> re.search(pattern2, _.group(0))
> -> re.search(pattern3, _.group(1))
> -> float(_.group(0))
>
> Yeah that can look ugly I agree (here intentionally the placeholder is
> overused).
On Tue, 30 Nov 2021 at 04:55, Chris Angelico wrote:
>
> if this:
>
> 1 |> add(2)
>
> is exactly equivalent to this:
>
> add(1, 2)
>
> then neither the iterator nor the consumer needs to be aware of the
> new protocol.
>
Along with such an operator form of functools.partial:
```
x |> f #
Dear Brendan Barnwell,
On Sun, 5 Sept 2021 at 05:06, Brendan Barnwell wrote:
>
> On 2021-09-04 05:47, Matsuoka Takuo wrote:
..
> > ```
> > from functools import partial
> >
> > curry = partial(partial, partial)
> > F = curry(curry(f))
> > ```
> &
On Sat, 4 Sept 2021 at 16:33, Brendan Barnwell wrote:
>
> In other words, currently `*` can turn what looks like one function
> call with one thing inside it into one function call with several things
> inside it. You are proposing to make it so `*` can turn one indexing
> operation with
Dear Kevin Mills,
I understand your point to some degree, but could you please clarify
it further by answering the following question?
Which of the following expressions will be valid in your model, and as
what currently valid expression will each of the valid ones
evaluated? (For instance, I
On Fri, 3 Sept 2021 at 12:06, Steven D'Aprano wrote:
>
> I think it might be better to start with a *function* that chains
> subscript calls, and perhaps put it in the operator module with
> itemgetter and attrgetter.
>
> # Untested.
> def chained_item(items, obj):
> for key in
Dear 笹原康央,
This sounds interesting. The assignment could be done e.g., like
this.
```python
def assign(variables):
return f'''
for _variable, _value in (lambda {variables}: locals())(
*_values, **_assignments
).items():
exec(f'{{_variable}} = _value')
'''
def
Dear Developers,
Some of you may have noticed I updated my proposal on the subject
yesterday. I'm afraid it was too long without a summary, so here is
one. I hope this will be helpful to some people.
Summary of the refreshed proposal
-
(1) Simplify the syntax:
I have filed this at the issue tracker at
https://bugs.python.org/issue44983
Best regards,
Takuo
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Dear Developers,
After some findings and further thoughts through this thread, I have
formulated a proposal as follows. (I thank everyone who has commented
in this thread). For the necessary definitions, please look at
https://docs.python.org/3/reference/expressions.html#subscriptions
Dear developers,
According to the Language Reference, a starred expression is defined
by
starred_expression ::= expression | (starred_item ",")* [starred_item]
https://docs.python.org/3/reference/expressions.html#expression-lists
However, in view of the definition of an assignment statement
> a = A()
)
Here's another piece of similarity.
>>> [1,] == [1]
True
>>> f(1,) == f(1)
True
>>> (1,) == (1)
False
>>> a[1,] == a[1]
False
Thank you for your suggestion to submit a merge request.
Best regards,
Takuo
On Fri, 20 Aug 2021 at 01:33, Stephen
Dear Steve,
Thank you for your detailed explanation.
> > (i.e., it can be mistyped as "s[1,2,]" but without SyntaxError this
> > time). It would at least be consistent if we got SyntaxError in
> > both cases (namely, the syntax allowed only a single Python
> > expression here), but if we
. Note that it
> was rejected, but the idea of a[*x] is being resurrected for PEP 646.
>
> On Fri, Aug 13, 2021 at 5:43 AM Matsuoka Takuo wrote:
>>
>> Dear Developers,
>>
>> Given a subscriptable object s, the intended rule for the notation for
>> getting a
The error mentioned in the title is this.
>>> *()
File "", line 1
SyntaxError: can't use starred expression here
According to the Language Reference
https://docs.python.org/3/reference/expressions.html#expression-lists
it's not really a starred expression. In the context of defining the
Matsuoka Takuo :
>
> Now, is "1,2," more boxed up than "*(1,2)," is? The *current* rule
> surely says the former is a tuple at some places and the latter
> is not,
Actually, this was wrong. First of all,
>>> *(1,2),
(1, 2)
Moreover, while the Language R
Dear Steve,
Thank you for your thoughts.
To be precise, the sequence of letters "*(1,2)" is not actually a
"starred expression" in the sense of the Python Language, but e.g.,
"*(1,2), "
is. (A comma is trailing.) Please check the definitions here:
Thanks 2QdxY4RzWzUUiLuE for your thoughtful response. I shouldn't have
used the word "expression" since it was going to be taken as a Python
term.
Let me clarify the issue. An optional starred expression (denoted
"[starred_expression]" in the specification of the syntax) is a
natural
Dear Developers,
Given a subscriptable object s, the intended rule for the notation for
getting an item of s seems that, for any expression {e}, such as
"x, ",
s[{e}]
(i.e., s[x, ] if {e} is "x, ") means the same as
s[({e})]
(i.e., s[(x, )] in the considered case), namely, should be evaluated
38 matches
Mail list logo
