I wrote a blog post
<http://paddy3118.blogspot.com/2009/07/case-of-disappearing-over-bar.html>nearly
a decade ago on extending a Rosetta Code task example
<http://rosettacode.org/wiki/Reverse_a_string>to handle the correct
reversal of strings with combining characters.
On checking my blog statistics today I found that it still had a readership
and revisited the code
<http://rosettacode.org/wiki/Reverse_a_string#Python:_Unicode_reversal>
(and updated it to Python3.6)..
I found that amongst the nearly 200 languages that complete the RC
task,there were a smattering of languages that correctly handled reversing
strings having Unicode combining characters,
including Perl 6 <http://rosettacode.org/wiki/Reverse_a_string#Perl_6>
which uses flip.
I would like to propose that Python add a Unicode-aware *str.reverse *method.
The problem is, I'm a Brit, who only speaks English and only very rarely
dips into Unicode.* I don't know how useful this would be!*
Cheers, Paddy.
>
> It’s obvious but there is one easy way to shorten the code: using
> **kwargs. It’s way shorter but the down sides are:
- the “real” function signature gets hidden so IDEs for example won’t pick
> it up
> - the error when you make a mistake when calling is not in your code
> anymore but one level down.
This is confusing. One could imagine solving this specific case by having a
> type annotation of “this function has the types of that function”. Maybe:
> def _open(*args: args_of_(sync_open), **kwargs: kwargs_of(sync_open) ->
> return_of(sync_open): But of course this only solves the case where there
> is a 1:1 mapping. / Anders
These problems could be solved by a decorator that accepts string
representation of the signature. The decorator would then have to parse the
signature at importing time and set it to the __signature__ attribute on
the resultant function. This decorator would also need to bind the
arguments e.g. sig.bind(*args, **kwargs), to handle out of order positional
arguments. Therefore this would raise an error in the decorator,
essentially solving your second point.
This would make the example look like this, a lot clearer in my opionion:
@signature('''(file, mode='r', buffering=-1, encoding=None, errors=None,
newline=None,
closefd=True, opener=None, *, loop=None,
executor=None)''')
def open(*args, **kwargs):
return AiofilesContextManager(_open(*args, **kwargs))
@asyncio.coroutine
def _open(*args, loop=None, executor=None, **kwargs):
"""Open an asyncio file."""
if loop is None:
loop = asyncio.get_event_loop()
cb = partial(sync_open, *args, **kwargs)
f = yield from loop.run_in_executor(executor, cb)
return wrap(f, loop=loop, executor=executor)
Ben Lewis
>
> def foo():
> a, b, c = 1, 2, 3
> function(a=77, **use('b d'))
>
> foo()
> You get the output “77 None 33 None”. So basically it doesn’t work at all.
> For the reason I wrote clearly in my last mail. You have to dig through the
> stack frames to make use() work.
>
OK, you are right. Improved implementation. Still not very hard.
In any case, I'm concerned with the API to *use* the `use()` function, not
how it's implemented. The point is really just that we can accomplish the
same thing you want without syntax added.
>>> import inspect
>>> def reach(name):
... for f in inspect.stack():
... if name in f[0].f_locals:
... return f[0].f_locals[name]
... return None
...
>>> def use(names):
... kws = {}
... for name in names.split():
... kws[name] = reach(name)
... return kws
...
>>> def function(a=11, b=22, c=33, d=44):
... print(a, b, c, d)
...
>>> function(a=77, **use('b d'))
77 None 33 None
>>> def foo():
... a, b, c = 1, 2, 3
... function(a=77, **use('b d'))
...
>>> foo()
77 2 33 None
Op za 8 sep. 2018 13:33 schreef Paddy3118 <paddy3118(a)gmail.com>:
>
> I would like to propose that Python add a Unicode-aware *str.reverse *method.
> The problem is, I'm a Brit, who only speaks English and only very rarely
> dips into Unicode.* I don't know how useful this would be!*
>
To be honest, quite apart from the Unicode issue, I never had a need to
reverse a string in real code.
.ytilibigel edepmi ot sdnet yllareneg tI
Stephan
> Cheers, Paddy.
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas(a)python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> I disagree. Those are examples of people being used to *positional
> arguments* and this expecting that order to carry over. I don’t think
> that’s a good argument because it presupposes that a habit of positional
> arguments is good.
>
If 99% of existing code uses:
pd.read_csv(fname, parse_dates=True, day_first=True)
In preference to:
pd.read_csv(fname, day_first=True, parse_dates=True)
It seems pretty absurd to say that readability isn't harmed by someone
choosing the "non-standard" order. Of course it still works the same for
the library; but it's not the same for humans reading the code.
There is one thing: my proposal wouldn’t result in a NameError at the
> eval() call. You tried it out in a console but didn’t think about the
> scoping properly. For your suggestion to work you have to copy paste that
> helper function into the code at all scopes you want to use it.
>
This is just wrong. Assuming there is no 'd' available in the current
scope, what could this POSSIBLY do other than raise a NameError:
function(a=77, *, b, d)
My little utility function decided to convert the NameError into a None
value for the missing variable; but I mentioned that I'm not sure whether
that's more useful behavior, and I'm not much attached to one or the other.
function(a=77, **use('b d'))
To make that helper function work you need to grab the stack frame and
> extract the variables from there. You could absolutely do that though.
> That’s pretty evil though.
>
Nope, there's absolutely no need to poke into the stack frame. It's just a
regular closure over any variables that might exist in surrounding scopes.
*Exactly* the same thing that your proposal would have to do. It makes
absolutely no difference how deeply or shallowly nested the call to `use()`
might be... A name like `d` simply is or is not available. Since the
utility function doesn't have its own locals or formal parameters, nothing
is changed by being one level deeper.[*]
[*] Actually, that's not true. My implementation potentially steps on the
three names `names`, `name` and `kws`. Perhaps those should be called
`__names`, `__name`, and `__kws` to avoid that issue. If so, that's an
easy change.
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
Paddy wrote
> I would like to propose that Python add a Unicode-aware str.reverse method.
> The problem is, I'm a Brit, who only speaks English and only very rarely
> dips into Unicode. I don't know how useful this would be!
Excellent post and piece of work. Well done!
Here's someone who might know not only how useful, but also the
wrinkles in doing it correctly:
<quote>
https://www.telecom-bretagne.eu/studies/msc/professors/haralambous/
Yannis Haralambous received his Ph.D. in Pure Mathematics from the
Université de Sciences et Techniques de Lille-Flandre-Artois, Lille,
France in 1990. He is currently working as a full-time Professor at
Institut Mines-Telecom/Telecom Bretagne, Brest, in the Computer
Science Department. His research areas include digital typography and
representation of text, electronic documents, internationalization of
documents, character encodings and the preservation of the cultural
heritage of the book in the digital era. He is the author of Fonts &
Encodings, to be published by O'Reilly in 2007 (French version :
Fontes & codages, O'Reilly France, 2003).
</quote>
I know Yannis, so could approach him on behalf of this list.
--
Jonathan
I'd rather have functools.partial() to be added as a new method on
function objects.
>
> fromfunctools importpartial
>
>
> def add(x:int,y:int)->int:
> returnx +y
>
>
> add_2 = partial(add,2)
>
Would become:
add_2 = add.partial(2)
Nothing to change on the parser, no obscure syntax for future readers,
and we can get the opportunity of rewriting partial() in C as right now
it is amazingly way, way slower than a lambda.
What if * and ** forwarded all unnamed arguments to a function? Example:
import traceback
def print_http_response(request, color=True):
...
def print_invalid_api_response(error, *, show_traceback=False, **):
print_http_response(*, **)
if show_traceback:
traceback.print_last()
else:
print(error)
This would essentially allow * and ** to be used to call a function without having to give a name: *args or **kwargs.
However in this scenario, the client function is more likely to be “inheriting from” the behavior of the inner function, in a way where all or most of the arguments of the inner function are valid on the client function. Example: requests.get creates a Request object and immediately sends the response while blocking for it.
> On Sep 6, 2018, at 3:27 PM, python-ideas-request(a)python.org wrote:
>
> Send Python-ideas mailing list submissions to
> python-ideas(a)python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-request(a)python.org
>
> You can reach the person managing the list at
> python-ideas-owner(a)python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
>
> Today's Topics:
>
> 1. Re: On evaluating features [was: Unpacking iterables for
> augmented assignment] (Franklin? Lee)
> 2. Re: On evaluating features [was: Unpacking iterables for
> augmented assignment] (Chris Angelico)
> 3. Re: Keyword only argument on function call (Jonathan Fine)
> 4. Re: On evaluating features [was: Unpacking iterables for
> augmented assignment] (Franklin? Lee)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Sep 2018 14:38:26 -0400
> From: "Franklin? Lee" <leewangzhong+python(a)gmail.com>
> To: Chris Angelico <rosuav(a)gmail.com>
> Cc: Python-Ideas <python-ideas(a)python.org>
> Subject: Re: [Python-ideas] On evaluating features [was: Unpacking
> iterables for augmented assignment]
> Message-ID:
> <CAB_e7iyjcFLCCmnbviUDKZY6mXdv0Hs7-_4kUQEpZe8mVTzvbg(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
>> On Thu, Sep 6, 2018 at 2:23 PM Chris Angelico <rosuav(a)gmail.com> wrote:
>>
>> On Fri, Sep 7, 2018 at 4:11 AM, Franklin? Lee
>> <leewangzhong+python(a)gmail.com> wrote:
>>>> On Tue, Aug 28, 2018 at 6:37 PM Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote:
>>>>
>>>> Guido van Rossum wrote:
>>>>> we might propose (as the OP did) that this:
>>>>>
>>>>> a, b, c += x, y, z
>>>>>
>>>>> could be made equivalent to this:
>>>>>
>>>>> a += x
>>>>> b += y
>>>>> c += z
>>>>
>>>> But not without violating the principle that
>>>>
>>>> lhs += rhs
>>>>
>>>> is equivalent to
>>>>
>>>> lhs = lhs.__iadd__(lhs)
>>>
>>> (Corrected: lhs = lhs.__iadd__(rhs))
>>>
>>> Since lhs here is neither a list nor a tuple, how is it violated? Or
>>> rather, how is it any more of a special case than in this syntax:
>>>
>>> # Neither name-binding or setitem/setattr.
>>> [a,b,c] = items
>>>
>>> If lhs is a Numpy array, then:
>>> a_b_c += x, y, z
>>> is equivalent to:
>>> a_b_c = a_b_c.__iadd__((x,y,z))
>>>
>>> We can translate the original example:
>>> a, b, c += x, y, z
>>> to:
>>> a, b, c = target_list(a,b,c).__iadd__((x,y,z))
>>> where `target_list` is a virtual (not as in "virtual function") type
>>> for target list constructs.
>>
>> What is the virtual type here, and what does its __iadd__ method do? I
>> don't understand you here. Can you go into detail? Suppose I'm the
>> author of the class that all six of these objects are instances of;
>> can I customize the effect of __iadd__ here in some way, and if so,
>> how?
>
> I shouldn't have used jargon I had to look up myself.
>
> The following are equivalent and compile down to the same code:
> a, b, c = lst
> [a, b, c] = lst
>
> The left hand side is not an actual list (even though it looks like
> one). The brackets are optional. The docs call the left hand side a
> target list: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements
>
> "Target list" is not a real type. You can't construct such an object,
> or hold one in memory. You can't make a class that emulates it
> (without interpreter-specific hacks), because it is a collection of
> its names, not a collection of values.
>
> target_list.__iadd__ also does not exist, because target_list does not
> exist. However, target_list can be thought of as a virtual type, a
> type that the compiler compiles away. We can then consider
> target_list.__iadd__ as a virtual operator, which the compiler will
> understand but hide from the runtime.
>
> I was making the point that, because the __iadd__ in the example does
> not refer to list.__iadd__, but rather a virtual target_list.__iadd__,
> there is not yet a violation of the rule.
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 7 Sep 2018 04:46:36 +1000
> From: Chris Angelico <rosuav(a)gmail.com>
> To: Python-Ideas <python-ideas(a)python.org>
> Subject: Re: [Python-ideas] On evaluating features [was: Unpacking
> iterables for augmented assignment]
> Message-ID:
> <CAPTjJmrauU+GD+Utcm=zUGFqWX5QXOhWLg5PL94s5OH_O8jLrQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, Sep 7, 2018 at 4:38 AM, Franklin? Lee
> <leewangzhong+python(a)gmail.com> wrote:
>> The following are equivalent and compile down to the same code:
>> a, b, c = lst
>> [a, b, c] = lst
>>
>> The left hand side is not an actual list (even though it looks like
>> one). The brackets are optional. The docs call the left hand side a
>> target list: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements
>>
>> "Target list" is not a real type. You can't construct such an object,
>> or hold one in memory. You can't make a class that emulates it
>> (without interpreter-specific hacks), because it is a collection of
>> its names, not a collection of values.
>
> A target list is a syntactic element, like a name, or an operator, or
> a "yield" statement. You can't construct one, because it isn't an
> object type. It's not a "virtual type". It's a completely different
> sort of thing.
>
>> target_list.__iadd__ also does not exist, because target_list does not
>> exist. However, target_list can be thought of as a virtual type, a
>> type that the compiler compiles away. We can then consider
>> target_list.__iadd__ as a virtual operator, which the compiler will
>> understand but hide from the runtime.
>>
>> I was making the point that, because the __iadd__ in the example does
>> not refer to list.__iadd__, but rather a virtual target_list.__iadd__,
>> there is not yet a violation of the rule.
>
> What you're suggesting is on par with trying to say that:
>
> for += 5
>
> should be implemented as:
>
> current_loop.__iadd__(5)
>
> where "current_loop" doesn't really exist, but it's a virtual type
> that represents a 'for' loop. That doesn't make sense, because there
> is no object in Python to represent the loop. There is no class/type
> that represents all loops, on which a method like this could be added.
> The word 'for' is part of the grammar, not the object model. And
> "target list" is the same. There's no way to attach an __iadd__ method
> to something that doesn't exist.
>
> So for your proposal to work, you would need to break that rule, and
> give a *different* meaning to this.
>
> ChrisA
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 6 Sep 2018 20:10:49 +0100
> From: Jonathan Fine <jfine2358(a)gmail.com>
> To: Anders Hovm?ller <boxed(a)killingar.net>
> Cc: python-ideas <python-ideas(a)python.org>
> Subject: Re: [Python-ideas] Keyword only argument on function call
> Message-ID:
> <CALD=Yf8Ddn4MQnbLw+ouoac7YQedc_EsK8o5PyKuwetMuNMAbg(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Summary: I addressed the DEFINING problem. My mistake. Some rough
> ideas for the CALLING problem.
>
> Anders has kindly pointed out to me, off-list, that I solved the wrong
> problem. His problem is CALLING the function fn, not DEFINING fn.
> Thank you very much for this, Anders.
>
> For calling, we can use https://docs.python.org/3/library/functions.html#locals
>
>>>> lcls = locals()
>
>>>> a = 'apple'
>>>> b = 'banana'
>>>> c = 'cherry'
>
>>>> dict((k, lcls[k]) for k in ('a', 'b', 'c'))
> {'b': 'banana', 'c': 'cherry', 'a': 'apple'}
>
> So in his example
>
> foo(a=a, b=b, c=c, d=3, e=e)
>
> one could instead write
>
> foo(d=3, **helper(locals(), ('a', 'b', 'c', 'e')))
>
> or perhaps better
>
> helper(locals(), 'a', 'b', 'c', 'e')(foo, d=3)
>
> where the helper() picks out items from the locals(). And in the
> second form, does the right thing with them.
>
> Finally, one might be able to use
>
>>>> def fn(*, a, b, c, d, e): f, g, h = 3, 4, 5
>>>> fn.__code__.co_kwonlyargcount
> 5
>>>> fn.__code__.co_varnames
> ('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h')
>>>> fn.__code__.co_argcount
> 0
>
> to identify the names of all keyword arguments of the function foo(),
> and they provide the values in locals() as the defaults. Of course,
> this is somewhat magical, and requires strict conformance to
> conventions. So might not be a good idea.
>
> The syntax could then be
>
> localmagic(foo, locals())(d=3)
>
> which, for magicians, might be easier. But rightly in my opinion,
> Python is reluctant to use magic.
>
> On the other hand, for a strictly controlled Domain Specific Language,
> it might, just might, be useful. And this list is for "speculative
> language ideas" (see
> https://mail.python.org/mailman/listinfo/python-ideas).
>
> --
> Jonathan
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 6 Sep 2018 15:26:47 -0400
> From: "Franklin? Lee" <leewangzhong+python(a)gmail.com>
> To: Chris Angelico <rosuav(a)gmail.com>
> Cc: Python-Ideas <python-ideas(a)python.org>
> Subject: Re: [Python-ideas] On evaluating features [was: Unpacking
> iterables for augmented assignment]
> Message-ID:
> <CAB_e7iyiM2ByZKxToNumtVRMTZr0S0K8-zyBykUbKYvv7AeQKQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> n Thu, Sep 6, 2018 at 2:47 PM Chris Angelico <rosuav(a)gmail.com> wrote:
>>
>> On Fri, Sep 7, 2018 at 4:38 AM, Franklin? Lee
>> <leewangzhong+python(a)gmail.com> wrote:
>>> The following are equivalent and compile down to the same code:
>>> a, b, c = lst
>>> [a, b, c] = lst
>>>
>>> The left hand side is not an actual list (even though it looks like
>>> one). The brackets are optional. The docs call the left hand side a
>>> target list: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements
>>>
>>> "Target list" is not a real type. You can't construct such an object,
>>> or hold one in memory. You can't make a class that emulates it
>>> (without interpreter-specific hacks), because it is a collection of
>>> its names, not a collection of values.
>>
>> A target list is a syntactic element, like a name, or an operator, or
>> a "yield" statement. You can't construct one, because it isn't an
>> object type. It's not a "virtual type". It's a completely different
>> sort of thing.
>
> I didn't think I gave the impression that I was complaining about not
> being able to construct it. I gave an explanation for how it isn't a
> real type, because you asked how you could modify the behavior, and
> because I wanted to give an explanation for more than just you.
>
> There are constructs that correspond to types (such as slices and
> functions). There are those that don't. We call `3:2` (in the right
> context) a slice, even though it's technically a construct which is
> compiled down to a `slice` object. I see no problem there.
>
> I called it a "virtual type" and explained why I called it that. You
> reject the use of that term, but you don't even acknowledge that I
> gave reasons for it.
>
>>> target_list.__iadd__ also does not exist, because target_list does not
>>> exist. However, target_list can be thought of as a virtual type, a
>>> type that the compiler compiles away. We can then consider
>>> target_list.__iadd__ as a virtual operator, which the compiler will
>>> understand but hide from the runtime.
>>>
>>> I was making the point that, because the __iadd__ in the example does
>>> not refer to list.__iadd__, but rather a virtual target_list.__iadd__,
>>> there is not yet a violation of the rule.
>>
>> What you're suggesting is on par with trying to say that:
>>
>> for += 5
>>
>> should be implemented as:
>>
>> current_loop.__iadd__(5)
>>
>> where "current_loop" doesn't really exist, but it's a virtual type
>> that represents a 'for' loop.
>
> I explained how target_list could be thought of as a special imaginary
> type which only exists in the compiler's "mind", and then extended
> that to an imaginary method on that type. Of course your example shows
> absurdity: you didn't try to say how a for-loop is like an object in
> the first place.
>
>> That doesn't make sense, because there
>> is no object in Python to represent the loop. There is no class/type
>> that represents all loops, on which a method like this could be added.
>> The word 'for' is part of the grammar, not the object model. And
>> "target list" is the same. There's no way to attach an __iadd__ method
>> to something that doesn't exist.
>
> But I'm not using the word `for`. I am using constructs like `[a,b,c]`
> (where it is not a list). At least use `(for x in y: z) += 5` as your
> example. You're effectively accusing me of trying to make `[` (a
> single token, not a full construct) an object.
>
> Your argument here is that there is no Python object to represent a
> loop, but that really means there's no _runtime_ object to represent a
> loop. I already said that target lists don't exist in memory (i.e.
> runtime).
>
> "Target list" does exist, just not as a runtime type. It exists as an
> abstraction not available to the runtime, and we can extend that
> abstraction in ways not available to the runtime. That means that you
> can't attach it during the runtime. It does not mean you can't reason
> with it during compile-time.
>
>> So for your proposal to work, you would need to break that rule, and
>> give a *different* meaning to this.
>
> It is not my proposal. I was questioning how there was a rule
> violation about x+=y translating to `x = x.__iadd__(y)`. You're
> talking about a different, made-up rule about how syntactical
> constructs can't correspond to compile-time imaginary objects or
> runtime objects. But there are syntactical constructs that DO
> correspond to runtime types (slice, list, class), there are those
> which don't but can (let's not get into that), there are those which
> can stay compile-time (f-strings, target lists), and there are those
> which probably can't be thought of as types at all (import).
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas(a)python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> ------------------------------
>
> End of Python-ideas Digest, Vol 142, Issue 22
> *********************************************
On Fri, Sep 7, 2018 at 12:31 AM Anders Hovmöller <boxed(a)killingar.net> wrote:
>
> Yury,
>
> I’m sorry if that came off badly, I was not attempting to be snarky. Text is hard and I know I’m not good in emails but rereading the text below I honestly can’t see why my honest attempt at describing my experience can be considered snarky.
>
> I haven’t sought out to discuss positional only parameters, this is something that has just come up in conversation from time to time over the last few years and this has been the response.
>
> If you would explain how you interpreted my mail in this way I would of course be thankful but I also don’t want to take more of your time.
Sure. (If you choose to reply to this email please do that off-list.)
IMHO your email lacks substance, uses rather strong words like
"disgust" and "disbelief", and ends with "I don't think that's a good
look for Python :P" phrase that doesn't help you to make any point.
You re-surfaced a pretty old email thread where a number of core
developers explained their position and listed quite a few arguments
for having positional-only arguments. You, on the other hand, didn't
add a lot to the discussion except your own opinion with no serious
arguments to support it.
Please don't feel discouraged from posting to python-ideas though,
just try to keep a higher signal-to-noise ratio. ;)
Yury
> As Matthew points out, you could use numpy.array. Or code your own
> class, by providing __add__ and __iadd__ methods.
>
> >>> import numpy
> >>> a = numpy.array([1, 2])
> >>> b = numpy.array([3, 4])
> >>> a + b
> array([4, 6])
> >>> a += b
> >>> a
> array([4, 6])
I could, but I don't think that justifies not having this functionality in
python
standard. From the language experience perspective, numpy is often a
pain to install on most systems. If I'm designing card games and I
just want to run a quick monte carlo simulation, the experience should be
as smooth as possible.
This is something I think most students will expect while learning python,
especially if they're implementing algorithms.
On Mon, Aug 27, 2018 at 4:24 AM <python-ideas-request(a)python.org> wrote:
> Send Python-ideas mailing list submissions to
> python-ideas(a)python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-request(a)python.org
>
> You can reach the person managing the list at
> python-ideas-owner(a)python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
>
> Today's Topics:
>
> 1. Re: Unpacking iterables for augmented assignment (Matthew Einhorn)
> 2. Re: Unpacking iterables for augmented assignment (Jonathan Fine)
> 3. Re: Pre-conditions and post-conditions (Jacco van Dorp)
> 4. Re: Pre-conditions and post-conditions (Ivan Levkivskyi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 Aug 2018 01:29:14 -0400
> From: Matthew Einhorn <moiein2000(a)gmail.com>
> To: python-ideas(a)python.org
> Subject: Re: [Python-ideas] Unpacking iterables for augmented
> assignment
> Message-ID:
> <CALCauYeAjPWek5L=BU-=
> yMM-FNYw3Bza2hJqsGmdgtrvBUa7XA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sun, Aug 26, 2018, 9:24 PM James Lu <jamtlu(a)gmail.com> wrote:
>
> > Hi Johnathan
> >
> > I echo your points. Indeed, the PEP referenced to refers to a "tuple
> > expression" in the grammatical and not the programmatic sense.
> >
> > Finally, here's something that surprised me a little bit
> >
> > >>> x = [1, 2]; id(x)
> > 140161160364616
> > >>> x += [3, 4]; id(x)
> > 140161160364616
> >
> > >>> x = (1, 2); id(x)
> > 140161159928520
> > >>> x += (3, 4); id(x)
> > 140161225906440
> >
> > Notice that '+=' creates uses the same object when the object is
> > a
> > list, but creates a new object. This raises the question: Why and
> > how
> > does Python behave in this way?
> >
> > It's because lists are mutable are tuples are immutable.
> > There's a dunder iadd method and a dunder add method.
> > iadd magic methods, operating on the left hand side, return None and
> > modify the object in-place. add magic methods return the result and
> > don't modify the object it's called on.
> > iadd is mutable add, whereas add is "return a copy with the result
> > added"
> >
> > >>> tuple.__iadd__
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > AttributeError: type object 'tuple' has no attribute '__iadd__'
> > type object 'tuple' has no attribute '__iadd__'
> > >>> tuple.__add__
> > <slot wrapper '__add__' of 'tuple' objects>
> > >>> list.__iadd__
> > <slot wrapper '__iadd__' of 'list' objects>
> > >>> list.__add__
> > <slot wrapper '__add__' of 'list' objects>
> >
> >
> > tuple1 = tuple1.__add__(tuple2)
> >
> > list1.__iadd__(list2)
> >
> > > Does it IN PRACTICE bring sufficient benefits to users?
> >
> > I found myself needing this when I was writing a monte-carlo
> > simulation in python that required incrementing a tallying counter
> > from a subroutine.
> >
>
>
> Wouldn't a numpy array be very suited for this kind of task?
>
> >
>
