[Python-ideas] Re: Move semantics

26.11.20 19:07, Guido van Rossum пише: > This reminds me of something in C++. Does it exist in other languages? Indeed, this is a term from C++. In older C++ you could pass argument by value, which makes a copy, and by reference, which is equivalent to passing a pointer by value plus syntax sugar.

[Python-ideas] Re: Move semantics

Actually, there is more examples, like working with thread-unsafe objects or file-like protocols. https://pastebin.com/nrRNjFsN ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https:/

[Python-ideas] Re: Making the for statement work better with nested functions

Hello, On Fri, 27 Nov 2020 18:32:54 +1300 Greg Ewing wrote: > On 27/11/20 1:23 pm, Chris Angelico wrote: > >> > >> That makes no sense as a phrase in English. > > > > Nor do lots of other constructs when they get combined. English > > doesn't really have good parallels for most computing conc

[Python-ideas] Re: Making the for statement work better with nested functions

Hello Guido, On Thu, 26 Nov 2020 14:18:20 -0800 Guido van Rossum wrote: > On Thu, Nov 26, 2020 at 3:11 AM Paul Sokolovsky > wrote: > > > [...] > > > > Hi Paul, > > I think there is a case to be made for adding "let" to Python. Would > you like to write a PEP? I recommend that you find a co

[Python-ideas] Re: Making the for statement work better with nested functions

On Fri, Nov 27, 2020 at 08:32:04AM +1100, Cameron Simpson wrote: > On 27Nov2020 00:25, Steven D'Aprano wrote: > >Block scoping allows shadowing within a function. > > Just to this: it needn't. Yes, I'm aware of that, and discussed languages such as Java which prohibit name shadowing within a fu

[Python-ideas] Re: Making the for statement work better with nested functions

On Fri, Nov 27, 2020 at 01:17:07PM +1300, Greg Ewing wrote: > On 27/11/20 2:25 am, Steven D'Aprano wrote: > >Block scoping adds semantic and implementation complexity and annoyance, > >while giving very little benefit. > > Yet in *certain situations* it seems that block scoping > is what people su

[Python-ideas] Re: Making the for statement work better with nested functions

Hello, On Fri, 27 Nov 2020 21:21:48 +1100 Steven D'Aprano wrote: [] > We can have too many scopes as well as too few: > > - a single process-wide global scope is too few; > > - every (sub-)expression being its own scope is too many; > > so we're just arguing about where the Goldilocks Zone i

[Python-ideas] Re: Move semantics

This thread is a mess. Move semantics is nothing more than creating a shallow copy that steals the inner state of a previous instance. It's an optimization, and moving out of a variable never makes the previous instance unusable: void f1(std::vector&& vec); void f2() { std::vect

[Python-ideas] Re: Making the for statement work better with nested functions

On Fri, Nov 27, 2020 at 01:05:45AM +1100, Chris Angelico wrote: > On Fri, Nov 27, 2020 at 12:28 AM Steven D'Aprano wrote: > > Block scoping adds semantic and implementation complexity and annoyance, > > while giving very little benefit. No thank you. [...] > > Is there a shortage of variable names

[Python-ideas] Re: Move semantics

On 11/26/20 11:45 PM, Guido van Rossum wrote: On Thu, Nov 26, 2020 at 7:45 PM MRAB > wrote: > It's not discarded, it's still referenced by d in the outer scope. > No, it's not any more, and that's the point. It was _moved_ into the function, and

[Python-ideas] Re: Move semantics

Your example is specific to C++ only. In Rust it is not just an optimization, it's about ownership. Example from Rust: fn f1(vec: Vec) {} fn f2() { let mut vec = vec![1]; f1(vec); vec.push(2); // This will not compile (borrow of moved value), because f1 took ownership of vec } ___

[Python-ideas] Re: Making the for statement work better with nested functions

On Fri, Nov 27, 2020 at 01:36:00PM +0300, Paul Sokolovsky wrote: > So, the alternative opinion you hear is that we could allow *optional* > block-level scoping. No such thing. Even if I don't use it myself, I still have to read code that uses it, I need to learn about it, there will surely be t

[Python-ideas] Re: Making the for statement work better with nested functions

On Fri, Nov 27, 2020 at 10:33:17PM +1100, Steven D'Aprano wrote: > On Fri, Nov 27, 2020 at 01:36:00PM +0300, Paul Sokolovsky wrote: > > > So, the alternative opinion you hear is that we could allow *optional* > > block-level scoping. > > No such thing. That dismissal (which made sense in my head

[Python-ideas] Re: Move semantics

27.11.20 13:25, Ned Batchelder пише: > On 11/26/20 11:45 PM, Guido van Rossum wrote: > Yes, I see that now.  As Chris points out elsewhere in the thread, this > proposal would have the type annotations change the actual behavior of > the code. No, it will not change the runtime behavior. But it can

[Python-ideas] Re: Move semantics

The C++ example specifically shows that if you're talking about ownership and lifetimes, you're not talking about move semantics. As you pointed out, the example wouldn't work in Rust specifically because Rust has a borrow checker, and not just move semantics. A compiler with a borrow checker w

[Python-ideas] Re: Move semantics

26.11.20 13:44, [email protected] пише: > Add something like Move type hint to typing module. It will tell the analyzer > that the input parameter of the function is moved and can not be used after. > For example: > ``` > def f(d: Move[dict]) -> dict: > d['a'] = 2 > return d > > d = {1: 2

[Python-ideas] Re: Move semantics

On 11/27/20 6:54 AM, Serhiy Storchaka wrote: 27.11.20 13:25, Ned Batchelder пише: On 11/26/20 11:45 PM, Guido van Rossum wrote: Yes, I see that now.  As Chris points out elsewhere in the thread, this proposal would have the type annotations change the actual behavior of the code. No, it will no

[Python-ideas] Re: Move semantics

On 2020-11-27 at 10:38:06 +0200, Serhiy Storchaka wrote: > 26.11.20 19:07, Guido van Rossum пише: > > This reminds me of something in C++. Does it exist in other languages? > Indeed, this is a term from C++. In older C++ you could pass argument > by value, which makes a copy, and by reference, w

[Python-ideas] Re: Move semantics

On Fri, 27 Nov 2020 07:32:17 -0500 [email protected] wrote: > > I come from old(er) school (1980s, 1990s) embedded systems, and who > "owns" a particular mutable data structure and how/where it gets mutated > always came up long before we wrote any code. No, I'm not claiming that

[Python-ideas] Re: Move semantics

On 11/27/20 8:32 AM, Antoine Pitrou wrote: On Fri, 27 Nov 2020 07:32:17 -0500 [email protected] wrote: I come from old(er) school (1980s, 1990s) embedded systems, and who "owns" a particular mutable data structure and how/where it gets mutated always came up long before we wrote

[Python-ideas] Re: Move semantics

On Fri, 27 Nov 2020 08:56:18 -0500 Ned Batchelder wrote: > On 11/27/20 8:32 AM, Antoine Pitrou wrote: > > On Fri, 27 Nov 2020 07:32:17 -0500 > > [email protected] > > wrote: > >> I come from old(er) school (1980s, 1990s) embedded systems, and who > >> "owns" a particular mutable

[Python-ideas] Re: Move semantics

On 2020-11-27 at 14:32:11 +0100, Antoine Pitrou wrote: > On Fri, 27 Nov 2020 07:32:17 -0500 > [email protected] > wrote: > > > > I come from old(er) school (1980s, 1990s) embedded systems, and who > > "owns" a particular mutable data structure and how/where it gets mutated > > a

[Python-ideas] adding a timeit.Timer context manager and decorator to time code/functions

When optimizing code, I often need to timeit a part of code or a function. I am using then the following class ``` import logging import time from functools import wraps from typing import Optional _logger = logging.getLogger("Timer") class Timer: def __init__(self, description: Optional[str]

[Python-ideas] Re: Making the for statement work better with nested functions

> bow = Ribbon(colour='yellow') > tie(bow, old_oak_tree) > for archer in troop: > let bow = get_weapon() > archer.take(bow) > assert bow.colour = 'yellow' > I had just this problem yesterday, and on many other days. However, I don't think the opt-in block scoping w

[Python-ideas] Re: Move semantics

On Fri, Nov 27, 2020 at 06:59:40AM -, [email protected] wrote: > Some examples for what I have in mind: [...] > file = open('move.py') > read_and_close_file(file) > file.read() # Mistake, file is already closed, static analyzer cah check that That's not a good example for this proposed Move

[Python-ideas] Re: Making the for statement work better with nested functions

On 27Nov2020 21:13, Steven D'Aprano wrote: >On Fri, Nov 27, 2020 at 08:32:04AM +1100, Cameron Simpson wrote: >> On 27Nov2020 00:25, Steven D'Aprano wrote: >> >Block scoping allows shadowing within a function. >> >> Just to this: it needn't. > >Yes, I'm aware of that, and discussed languages such