On Mon, Jun 18, 2018 at 9:28 AM, Greg Ewing wrote:
> Chris Angelico wrote:
>
>> kwargs.pop("some_key") could plausibly be spelled del
>> kwargs["some_key"] if del were (like yield) upgraded to expression.
>
>
> Except that "delete" is a really misleading name for such
> an operation!
>
Is it?
Chris Angelico wrote:
kwargs.pop("some_key") could plausibly be spelled del
kwargs["some_key"] if del were (like yield) upgraded to expression.
Except that "delete" is a really misleading name for such
an operation!
--
Greg
___
Python-ideas mailing
On Mon, Jun 18, 2018 at 6:52 AM, Jelle Zijlstra
wrote:
>
>
> 2018-06-17 13:09 GMT-07:00 Chris Angelico :
>>
>>
>> kwargs.pop("some_key") could plausibly be spelled del
>> kwargs["some_key"] if del were (like yield) upgraded to expression.
>> Whether that is an improvement or not, I don't know,
2018-06-17 13:09 GMT-07:00 Chris Angelico :
>
> kwargs.pop("some_key") could plausibly be spelled del
> kwargs["some_key"] if del were (like yield) upgraded to expression.
> Whether that is an improvement or not, I don't know, but at least it's
> logical.
>
That already works. It calls the
On Sun, Jun 17, 2018 at 11:38 PM, Steven D'Aprano wrote:
> As for "frequent operation", there are lots of frequent operations in
> Python. Does every one of them deserve special syntax to make it clean?
> I just opened one of my modules at random, and I don't have a single
> append in that
Mikhail, this thread is getting quite long,
and difficult to follow.
It's quite clear that a new operator won't
be introduced for list insertion.
Furthermore, this thread has now become
a hard-to-follow and impossible-to-participate-in
debate.
If you have other ideas, could you maybe
formulate
On Sun, Jun 17, 2018 at 2:52 AM, Steven D'Aprano wrote:
> On Sat, Jun 16, 2018 at 08:21:42PM +0300, Mikhail V wrote:
>
>> By L[] there is some mnemonical hint because [] is used to create
>> new empty list.
>
> How is that a hint? What is the connection between "append an item" and
> "create a
On Sat, Jun 16, 2018 at 08:21:42PM +0300, Mikhail V wrote:
> For example, such code:
>
> L = []
> L[] = x
> L[] = y
Should be written as L = [x, y].
> imo has more chance to be understood correctly than e.g.:
>
> L = []
> L ^= x
> L ^= y
I disagree. The first syntax
On 16Jun2018 20:21, Mikhail V wrote:
On Sat, Jun 16, 2018 at 4:44 AM, Cameron Simpson wrote:
On 16Jun2018 02:42, Mikhail V wrote:
Some things _should_ be syntax errors. Particularly things which may be
typing errors. Suppose I'd meant to type:
L[0] = item
Silent breakage, requiring
On Sat, Jun 16, 2018, 10:22 AM Mikhail V wrote:
> Plus it does not introduce overloading of the operator.
Now you're critizing duck typing.
And overloading has weakness in this - e.g. " var1 += var2 " does not
> have mnemonics, other than + character (it could be two integers as well).
>
On Sat, Jun 16, 2018 at 4:44 AM, Cameron Simpson wrote:
> On 16Jun2018 02:42, Mikhail V wrote:
>>
> Some things _should_ be syntax errors. Particularly things which may be
> typing errors. Suppose I'd meant to type:
>
> L[0] = item
>
> Silent breakage, requiring runtime debugging.
Not sure
On Sat, Jun 16, 2018 at 9:09 PM, Steven D'Aprano wrote:
> On Sat, Jun 16, 2018 at 01:06:45PM +1200, Greg Ewing wrote:
>> Michael Selik wrote:
>> >The += operator was meant as an alias for ``x = x + 1``. The
>> >fact that it mutates a list is somewhat of a surprise.
>>
>> That's very much a matter
On Sat, Jun 16, 2018 at 01:06:45PM +1200, Greg Ewing wrote:
> Michael Selik wrote:
> >The += operator was meant as an alias for ``x = x + 1``. The
> >fact that it mutates a list is somewhat of a surprise.
>
> That's very much a matter of opinion. For every person who
> thinks this is a surprise,
On 16Jun2018 02:42, Mikhail V wrote:
Now I have slightly different idea. How is about special-casing of this
as a shortcut for append:
L[] = item
Namely just use the fact that empty slice is SyntaxError now.
Now we're just making typing errors into working code.
Also, that isn't an empty
On Fri, Jun 15, 2018, 6:18 PM Mikhail V wrote:
> On Sat, Jun 16, 2018 at 3:47 AM, Michael Selik wrote:
>
> > One of those links was discussing extend, not append.
>
> Yes and so what? ... What is different with append?
Luckily for extend, it's similar to the "obvious" semantics of ``a += b``
Mikhail V wrote:
But I see from various posts in the web and SO - people
just want to spell it compact, and keep the 'item' part clean of
brackets.
Where have you seen these posts?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
On Sat, Jun 16, 2018 at 3:47 AM, Michael Selik wrote:
> One of those links was discussing extend, not append.
Yes and so what? Does this makes it automatically not related to
the wish to choose more compact spelling, despite it is not
recommended way. What is different with append?
Similar
On 6/15/2018 8:42 PM, Greg Ewing wrote:
Mikhail V wrote:
It s just very uncommon to see standalone statements like:
x.method()
for me it came into habit to think that it lacks the left-hand part
and =.
You must be looking at a very limited and non-typical
corpus of Python code. Mutating
Michael Selik wrote:
The += operator was meant as an alias for ``x = x + 1``. The
fact that it mutates a list is somewhat of a surprise.
That's very much a matter of opinion. For every person who
thinks this is a surprise, you can find another that thinks
it's obvious that += should mutate a
Mikhail V wrote:
It s just very uncommon to see standalone statements like:
x.method()
for me it came into habit to think that it lacks the left-hand part and =.
You must be looking at a very limited and non-typical
corpus of Python code. Mutating method calls are
extremely common in most
On Sat, Jun 16, 2018 at 3:26 AM, Michael Selik wrote:
>
>
> On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote:
>>
>> there is just nothing against append() method.
>
>
> Then why break the Zen: there should be only one obvious way?
I think the question could be applied to 99% proposals
>> But I
On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote:
> there is just nothing against append() method.
>
Then why break the Zen: there should be only one obvious way?
But I see from various posts in the web and SO - people just want to spell
> it compact, and keep the 'item' part clean of brackets.
On Sat, Jun 16, 2018 at 3:02 AM, Chris Angelico wrote:
> On Sat, Jun 16, 2018 at 9:42 AM, Mikhail V wrote:
>> Now I have slightly different idea. How is about special-casing of this
>> as a shortcut for append:
>>
>> L[] = item
>>
>> Namely just use the fact that empty slice is SyntaxError now.
On Sat, Jun 16, 2018 at 9:42 AM, Mikhail V wrote:
> Now I have slightly different idea. How is about special-casing of this
> as a shortcut for append:
>
> L[] = item
>
> Namely just use the fact that empty slice is SyntaxError now.
>
> I understand this is totally different approach than
Now I have slightly different idea. How is about special-casing of this
as a shortcut for append:
L[] = item
Namely just use the fact that empty slice is SyntaxError now.
I understand this is totally different approach than operator
overloading and maybe
hard to implement, but I feel like it
On 6/15/18 1:25 PM, Mikhail V wrote:
> On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico wrote:
>> On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote:
>>> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
>>>
If you would like to prove the need for this operator, one piece of
On Fri, Jun 15, 2018 at 10:25 AM Mikhail V wrote:
> very uncommon to see standalone statements like: x.method()
>
Python has many such mutation methods. It sounds like you're judging the
frequency of code patterns across all languages instead of just Python.
Even then, I don't think that's
On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico wrote:
> On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote:
>> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
>>
>>> If you would like to prove the need for this operator, one piece of evidence
>>> you can provide is a count of the number of
On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote:
> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
>
>> If you would like to prove the need for this operator, one piece of evidence
>> you can provide is a count of the number of times someone writes
>> "list.append" for an iterable vs "+="
On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
> If you would like to prove the need for this operator, one piece of evidence
> you can provide is a count of the number of times someone writes
> "list.append" for an iterable vs "+=" and encloses a str or other type in a
> throw-away list
Sorry, I forgot that you dropped the suggestion to make it an insert
operator and are only asking for an append operator.
I see no benefit to this, because += already is an elegant way to extend a
list, which is more flexible than append. Yes, if the right-hand is an
iterable and should be
On Thu, Jun 14, 2018, 7:24 PM Mikhail V wrote:
> what haven't we repeated in this thread yet? Motivation was explained.
>
You have repeated your explanations a few times. It isn't convincing.
It seems to me that your main complaint is that strings are iterable,
though you haven't expressed it
On Fri, Jun 15, 2018 at 1:04 AM, Michael Selik wrote:
[..]
> In case I need to clarify:
> 1. You're duplicating current clear and more flexible syntax.
> 2. Your proposed operators are confusing when compared with their meanings
> elsewhere.
what haven't we repeated in this thread yet?
There's nothing wrong with your ideas if you were designing a language from
scratch. However, Python has a long history and many tools and uses for the
same operators you are considering. And even has a current "insert"
operator (slice assignment).
When adding a new feature, you need to consider
On Wed, Jun 13, 2018 at 6:45 PM, Mikhail V wrote:
> Another point is that people do like augmented operators much and for the
> append - there are so many advises like: hey, use L += [item] !
>
another data point -- in teaching, a number of newbie students do exactly
that.
Actually, they do:
On Thu, Jun 14, 2018 at 2:58 AM, Greg Ewing wrote:
> Mikhail V wrote:
>>
>> L ^= item
>> is
>> L.append(item)
>> or
>> L += [item]
>
>
> Okay, that achieves an in-place append, but it's not exactly
> obvious to the unenlightened what it does, whereas append()
> is pretty self-explanatory.
>
Mikhail V wrote:
L ^= item
is
L.append(item)
or
L += [item]
Okay, that achieves an in-place append, but it's not exactly
obvious to the unenlightened what it does, whereas append()
is pretty self-explanatory.
Also, using the slice version to do an insert
L[i:i] ^= item
is not as efficient
Mikhail V wrote:
But if you say that special-casing of [i:j] here would be hard to implement,
then maybe insert() idea should be dropped.
Since I wrote that I realised that it's not true --
given an infix ^ operator like you propose, the in-place
version of it would actually give the desired
On Wed, Jun 13, 2018 at 5:46 PM, Chris Angelico wrote:
> On Thu, Jun 14, 2018 at 12:40 AM, Mikhail V wrote:
>> L1 = L2 ^ item
>> is
>> L1 = L2 + [item]
>>
>> and
>> L ^= item
>> is
>> L.append(item)
>> or
>> L += [item]
>
> Okay. Now it all is coherent and makes perfect sense... but you're
>
On Thu, Jun 14, 2018 at 12:40 AM, Mikhail V wrote:
> On Wed, Jun 13, 2018 at 5:13 PM, Chris Angelico wrote:
>> On Thu, Jun 14, 2018 at 12:04 AM, Mikhail V wrote:
>>> On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing
>>> wrote:
Mikhail V wrote:
>
>>> Sorry for repeating myself, the idea was
On Wed, Jun 13, 2018 at 5:13 PM, Chris Angelico wrote:
> On Thu, Jun 14, 2018 at 12:04 AM, Mikhail V wrote:
>> On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing
>> wrote:
>>> Mikhail V wrote:
>> Sorry for repeating myself, the idea was that the default meaning is
>> append(),
>> i.e. normal
On Thu, Jun 14, 2018 at 12:04 AM, Mikhail V wrote:
> On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing
> wrote:
>> Mikhail V wrote:
>>>
>
>> My feeling is that inserting is not a frequent enough operation
>> to warrant having its own operator, especially not when there
>> is already a syntax that
On Wed, Jun 13, 2018 at 2:15 AM, Greg Ewing wrote:
> Mikhail V wrote:
>>
> My feeling is that inserting is not a frequent enough operation
> to warrant having its own operator, especially not when there
> is already a syntax that does the same thing.
Depends on what you count as 'insert' -
^ is also used in regexes for matching the *beginning* of a string...
Realistically, I don't think this proposal would be added, but if it were,
^ would be a horrible choice.
That being said, I do understand the feeling of half your code being calls
to .append or .extend. You could always do:
On Tue, Jun 12, 2018 at 4:43 PM Mikhail V wrote:
> inserting in the beginning of the list may be also not rare.
>
Inserting in the beginning of a list is *slow* and should be rare.
If you want to append to the left-side of a list, you should use a deque.
Check out ``collections.deque`` for your
Mikhail V wrote:
L[0:0] = ["bb"]
-> ["bb", "aa"]
The trick is to put brackets around the element and so it works as insert().
Though additional brackets look really confusing for this purpose, so I don't
feel like using this seriously.
I don't think it's all that confusing. It looks
On Tue, Jun 12, 2018 at 10:25 PM, Michael Selik wrote:
> On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote:
>>
>> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner
>> wrote:
>>
>> So the idea was about an insert/append operator.
>> Which would use augmented operator. The operator may be
>> /= or ^=.
On Wed, Jun 13, 2018 at 5:25 AM, Michael Selik wrote:
> On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote:
>>
>> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner
>> wrote:
>>
>> So the idea was about an insert/append operator.
>> Which would use augmented operator. The operator may be
>> /= or ^=.
On Tue, Jun 12, 2018 at 11:08 AM Mikhail V wrote:
> On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner
> wrote:
>
> So the idea was about an insert/append operator.
> Which would use augmented operator. The operator may be
> /= or ^=. (I like ^= more, so I'll put here example with it).
>
The "/"
On 6/12/2018 10:54 AM, Mikhail V wrote:
I think it would be logical to have the insert operator for lists.
Similar to list extend operator += , it could use one of augmented
assignment operators, e,g, /=.
...
Note that there is a trick to 'insert' an element with slicing syntax, e.g.:
This
On Tue, Jun 12, 2018 at 7:42 PM, Clint Hepner wrote:
>
>> On 2018 Jun 12 , at 10:54 a, Mikhail V wrote:
>>
>> I think it would be logical to have the insert operator for lists.
>> Similar to list extend operator += , it could use one of augmented
>> assignment operators, e,g, /=.
>>
>>L =
> On 2018 Jun 12 , at 10:54 a, Mikhail V wrote:
>
> I think it would be logical to have the insert operator for lists.
> Similar to list extend operator += , it could use one of augmented
> assignment operators, e,g, /=.
>
>L = ["aa"]
>
>L[0] /= "bb"
>
>-> ["bb", "aa"]
>
>
12.06.18 17:54, Mikhail V пише:
I think it would be logical to have the insert operator for lists.
Similar to list extend operator += , it could use one of augmented
assignment operators, e,g, /=.
L = ["aa"]
L[0] /= "bb"
-> ["bb", "aa"]
L[0] /= [1,2]
-> [[1,2],
On Tue, Jun 12, 2018 at 5:54 PM, Mikhail V wrote:
> I think it would be logical to have the insert operator for lists.
> Similar to list extend operator += , it could use one of augmented
> assignment operators, e,g, /=.
>
> L = ["aa"]
>
> L[0] /= "bb"
>
> -> ["bb", "aa"]
>
>
That's a slice assignment, works great. I think if you use it more often
you'll start to enjoy it.
However, lists are optimized for append. Insert is slow. It should be
discouraged, not encouraged by the language. If inserting is just a tad
more awkward than appending, that's the language design
I think it would be logical to have the insert operator for lists.
Similar to list extend operator += , it could use one of augmented
assignment operators, e,g, /=.
L = ["aa"]
L[0] /= "bb"
-> ["bb", "aa"]
L[0] /= [1,2]
-> [[1,2], "aa"]
etc.
Without index it would work
56 matches
Mail list logo
