On Sun, 8 May 2022 at 20:52, Steven D'Aprano wrote:
> Just a quick straw poll, how would people feel about relaxing the
> restriction on the walrus operator so that iterable unpacking is
> allowed?
>
> # Currently a syntax error.
> results = (1, 2, (a, b) := (3, 4), 5)
>
> which would
> Doesn't ':=' have a lower precedence than ','
No it doesn't. Its precedence is between ',' and a single non-name expression,
so you can effectively do this:
\>>> (1, 2, a := 3, 4)
(1, 2, 3, 4)
\>>> a
3
___
Python-ideas mailing list --
> We're talking about tuples here, not strings.
>
> Saying that a method's API differs for a completely different type,
> especially when such a difference would be expected given the difference in
> types, is not a valid objection.
I agree with this. It was also earlier specified:
>
Chris Angelico wrote:
> On Sun, Dec 26, 2021 at 11:32 AM Jeremiah Vivian
> nohackingofkrow...@gmail.com wrote:
> > Steven D'Aprano wrote:
> > On Thu, Dec 23, 2021 at 05:53:46PM -, Stefan Pochmann wrote:
> > Chris Angelico wrote:
> > If you're removing multipl
Steven D'Aprano wrote:
> On Thu, Dec 23, 2021 at 05:53:46PM -, Stefan Pochmann wrote:
> > Chris Angelico wrote:
> > If you're removing multiple, it's usually best to filter. This is a
> > great opportunity to learn about list comprehensions and the
> > difference between O(n) and O(n²) :)
> >
> When called with the count argument, should it raise ValueError if there
> are fewer than `count` occurrences of the element in the list?
No, it shouldn't. It would raise ValueError if the element is not found within
the list though.
___
Python-ideas
I expect some sort of "there's no benefit in this, just write the current
implementation", indirectly or directly.
Currently, this is the way to remove `num` occurrences of an element from a
list:
> idx = 0
> while idx < len(the_list) and num:
> if the_list[idx] == element_to_remove:
>
To be honest, I like the `@param=value` syntax. It is sort of easier to read
than `param=>value`, though I do not have problems with distinguishing the
arrow `=>` from other things.
___
Python-ideas mailing list -- python-ideas@python.org
To
> I'll reply to this comment once I've done so.
I just realized that this message replied on a comment instead of the thread.
Anyways, it's a really impressive implementation (hope this statement doesn't
spark some sort of debate).
___
Python-ideas
Answering questions:
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
I would definitely use it.
> 2) Independently: Is the syntactic distinction between "=" and "=>" a
> cognitive burden?
No, it isn't much of a cognitive burden.
> 3) If "yes" to question 1,
Side note: I've added operators and even a whole new builtin object for fun.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
> Still interested in coauthors who know CPython internals. That hasn't changed.
I know some part of CPython internals, but I'm not quite sure how would a
coauthor be recruited. I'm studying your implementation to understand more
about how parsing to executing bytecode works in Python.
> On Thu, Oct 28, 2021 at 05:25:52PM +1100, Chris Angelico wrote:
>> But the "in" operator isn't built on iteration, so that would be
>> in-consistent.
>
> "In-"consistent, heh :-)
>
> \>\>\> a = iter("abcde")
> \>>> a.__contains__
> Traceback (most recent call last):
> File "",
I don't quite understand completely the major first part of your reply...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
> What you're asking for can best be spelled with any/all and iteration,
> not a new operator.
I can settle with this.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
All containers do have a concept of iterators though, and the `is in` operator
can check using the iterator of the container.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
> It's worth noting that "in" is defined by the container. Object
> identity and equality aren't actually part of the definition. A lot of
> containers will behave as the OP describes, but strings, notably, do
> not - if you iterate over "caterpillar", you will never see "cat", yet
> it is most
*It should be obvious
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
It should make sense that if an operation is grammatically correct in a
programming language, there's something wrong there. There could be alternative
syntax,
> 'is `object` in `iterable`'
or
> 'is `object` not in `iterable`'
but I feel like there's some disadvantage to this alternative syntax.
For quick checking if a `Movement` object is inside of an iterable.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Something like this:
> \>\>\> class Movement:
> ... def __eq__(self, x):
> ... return type(x) is Movement
> ...
> \>\>\> dummy = Movement()
> \>\>\> # suppose `bar` is a list of every recorded action in a game
> \>\>\> if dummy in bar:
> ... if dummy is in bar: # check if the
I DO expect this thread to be bombarded with negative replies.
Currently, there are `in`/`not in` operators which work like this in Python:
> def contains(contains_value, iterable, not_in):
> for element in iterable:
> if element == contains_value:
> return True ^ not_in
>
I am gonna think about that, but all of these operators (though I think you are
calling it "confusing") are basically the equivalent of `iter(dict_object)[x]`.
So they're fast, and can also extract something from the middle of a 'dict'
object.
___
Results are in (tested
`next(iter(d))`/`next(iter(d.values())`/`next(iter(d.items())` and their
`next(reverse())` counterparts):
`*` / `/` implemented is 2x faster than `next(iter(d))`/`next(reversed(d))`
`+` / `-` implemented is approximately 3x faster than
> I implemented these functions as operators in a downloaded source of CPython
And Chris is probably right, but I can't test it now at the time of writing
this reply.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email
Fixed reply:
So I implemented these functions as operators in CPython... the differences are
insane!
> \>\>\> import timeit
>
> # d + 1 vs list(d.values())[0]: 2133x speedup
> \>\>\> timeit.main(['-s', "d = {x: x+1 for x in range(1)}", "d + 1"])
> 200 loops, best of 5: 165 nsec per loop
(gonna test highlighting)
\>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
So I implemented these functions as operators in a downloaded source of
CPython... the differences are insane! (Sorry if this produces nested quotes)
> >>> import timeit
> # d + 1 vs list(d.values())[0]: 2133x speedup
> >>> timeit.main(['-s', "d = {x: x+1 for x in range(1)}", "d + 1"])
>
Now I didn't expect this thread to blow up in replies with alternatives,
specifically `str1 / str2` for 'str1.split(str2)' and `seq1 * str` for
'str.join(seq1)'.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
> "inverting" the string to another type
...That doesn't make any sense.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
So I guess I'll just have to keep this to myself.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
I posted a previous thread about overloading the unary `+` operator in strings
with `ord`, and that expanded to more than just the unary `+` operator. So I'm
saying now, there should be these implementations:
> +string - `int(string, 10)` (or just `int(string)`)
> -string - `int(string, 8)`
>
So I'll post another thread about unary operators for strings. Everything
expanded from just unary positive to all unary operators.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Using the caret as a prefix unary operator would require changes in python
grammar. For now, stick to implementing existing operators. But the rest of the
ideas are good though.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
You all have been giving pretty great ideas. But this is the one I'm
considering the most:
On 2021-10-12 13:49, Steven D'Aprano wrote:
> On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
>> You haven't given any reason why unary plus should imply ord().
> I think the question Chris
the unary `+` for a string doesn't really exist.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
> And also, the unary `+` of
> strings only copies strings, which should be redundant in most cases.
Oh yeah. I got this from the behavour of the unary `+` of an `int`.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an
> -1. It's unnecessary optimization for an uncommon case, abuse of syntax
Good point. But what else can the unary positive do? I'm just trying to add a
use for it.
> illogical - why should +"a" be the integer 97?
Because `ord("a")` is `97`. Have you read the last question at the end of the
post?
So `ord` is already a really fast function with (last check before this thread
was posted) 166 nsec per loop. But I'm wondering... doing `ord(a)` produces
this bytecode:
> 2 4 LOAD_NAME1 (ord)
> 6 LOAD_NAME0 (a)
> 8
If "barry_as_FLUFL" is a joke, I see no reason why there shouldn't be another
joke disabling it.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
NEW_FEATURE = "remove_barry_from_BDFL" or
"barry_resign_as_FLUFL"/"barry_resign_as_BDFL";
Add a new future import NEW_FEATURE. This reverts the effects of the future
import "barry_as_FLUFL" easter egg IF it is ever imported. This is absolutely
unnecessary when "barry_as_FLUFL" isn't imported.
41 matches
Mail list logo
