[Python-ideas] Re: Move semantics

On Fri, Nov 27, 2020 at 06:59:40AM -, 3mi...@gmail.com 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: Move semantics

On 2020-11-27 at 14:32:11 +0100, Antoine Pitrou wrote: > On Fri, 27 Nov 2020 07:32:17 -0500 > 2qdxy4rzwzuui...@potatochowder.com > 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 > >

[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 > > 2qdxy4rzwzuui...@potatochowder.com > > wrote: > >> I come from old(er) school (1980s, 1990s) embedded systems, and who > >> "owns" a particular

[Python-ideas] Re: Move semantics

On 11/27/20 8:32 AM, Antoine Pitrou wrote: On Fri, 27 Nov 2020 07:32:17 -0500 2qdxy4rzwzuui...@potatochowder.com 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

[Python-ideas] Re: Move semantics

On Fri, 27 Nov 2020 07:32:17 -0500 2qdxy4rzwzuui...@potatochowder.com 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

[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,

[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

[Python-ideas] Re: Move semantics

26.11.20 13:44, 3mi...@gmail.com пише: > 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:

[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

[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

[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: 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,

[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() {

[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 -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[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

[Python-ideas] Re: Move semantics

Some examples for what I have in mind: def read_and_close_file(file: Move[FileIO]): """ File will be closed, so we can not use after """ file.read() file.close() @dataclass class Model: x: List[int] def make_list_from_model(model: Move[Model]) -> List[int]: """ This is not

[Python-ideas] Re: Move semantics

On Fri, Nov 27, 2020 at 2:46 PM MRAB wrote: > > On 2020-11-27 02:30, Ned Batchelder wrote: > > On 11/26/20 9:02 PM, MRAB wrote: > >> On 2020-11-27 01:12, Ned Batchelder wrote: > >>> On 11/26/20 6:44 AM, 3mi...@gmail.com wrote: > Add something like Move type hint to typing module. It will

[Python-ideas] Re: Move semantics

On 2020-11-26 19:41, MRAB wrote: On 2020-11-27 02:30, Ned Batchelder wrote: On 11/26/20 9:02 PM, MRAB wrote: On 2020-11-27 01:12, Ned Batchelder wrote: On 11/26/20 6:44 AM, 3mi...@gmail.com wrote: Add something like Move type hint to typing module. It will tell the analyzer that the input

[Python-ideas] Re: Move semantics

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 although the function returned it, it was discarded > because the caller didn't bind it to

[Python-ideas] Re: Move semantics

On 2020-11-27 02:30, Ned Batchelder wrote: On 11/26/20 9:02 PM, MRAB wrote: On 2020-11-27 01:12, Ned Batchelder wrote: On 11/26/20 6:44 AM, 3mi...@gmail.com wrote: Add something like Move type hint to typing module. It will tell the analyzer that the input parameter of the function is moved

[Python-ideas] Re: Move semantics

On 11/26/20 9:02 PM, MRAB wrote: On 2020-11-27 01:12, Ned Batchelder wrote: On 11/26/20 6:44 AM, 3mi...@gmail.com wrote: 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: ```

[Python-ideas] Re: Move semantics

On 2020-11-27 01:12, Ned Batchelder wrote: On 11/26/20 6:44 AM, 3mi...@gmail.com wrote: 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:

[Python-ideas] Re: Move semantics

To help you understand what they're requesting, do you at least understand C++'s move schematics. If not, here's a good place to read about it: https://www.fluentcpp.com/2018/02/06/understanding-lvalues-rvalues-and-their-references/ ___ Python-ideas

[Python-ideas] Re: Move semantics

On 11/26/20 6:44 AM, 3mi...@gmail.com wrote: 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} f(d)

[Python-ideas] Re: Move semantics

On Fri, 27 Nov 2020 07:50:20 +1100 Steven D'Aprano wrote: > On Thu, Nov 26, 2020 at 02:15:50PM -0500, nate lust wrote: > > > It would be convenient if you could mark in source code that you intended a > > resource to be "moved" and any further access through other bindings are > > not what was

[Python-ideas] Re: Move semantics

Sorry I think I was not being clear due to differing understandings or using of the definitions of terms (likely on my part). The second built point is what I was considering, "ownership" of an object is moved out of the scope/frame/however you think about it, into the one you are calling. The

[Python-ideas] Re: Move semantics

On Thu, Nov 26, 2020 at 1:51 PM Bruce Leban wrote: > What might be useful are declarations that: > >- The object is not modified (i.e., read only). If a function that >declares a parameter as read-only passes that parameter to one that does >not use that declaration, that can be

[Python-ideas] Re: Move semantics

On Thu, Nov 26, 2020 at 5:43 AM <3mi...@gmail.com> wrote: > 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: > ``` > You say "moved and cannot be used" which is either

[Python-ideas] Re: Move semantics

Steve, I take your point, and like indicated in another part of this thread, for most parts of our stack its standard practices. It is only when managing certain external resources that we take a bit of extra care, and that is in a library that is not outwardly exposed. I agree with you also that

[Python-ideas] Re: Move semantics

On Thu, Nov 26, 2020 at 02:15:50PM -0500, nate lust wrote: > It would be convenient if you could mark in source code that you intended a > resource to be "moved" and any further access through other bindings are > not what was intended. This would help catch logic bugs during type > checking,

[Python-ideas] Re: Move semantics

I agree that is how python is implemented, and from a memory perspective, this is not needed. What I was talking about was more from a conceptual resource point of view, and not just memory as a resource. Consider a generator, you can have many different bindings to the object, but when it is

[Python-ideas] Re: Move semantics

On 11/26/20 12:07 PM, Guido van Rossum wrote: > This reminds me of something in C++. Does it exist in other languages? > A key point is that C++ needs 'move' behavior as its variables are buckets of bits, and assigning one variable to another, like in a call, requires copying that whole bucket of

[Python-ideas] Re: Move semantics

Yeah, in most places we just use python as you described. In a few localized places it turned out to be useful for detecting issues and working with external resources that were exposed through python objects. I would not say if this proposal were included with typing that it should be taught as

[Python-ideas] Re: Move semantics

Why are you trying to replicate move semantics in Python? The Python ownership model is entirely different from C++. In C++ terms, every Python object is like a shared_ptr<> (but with additional support for tracking and collecting reference cycles). Generally, when a Python function wants to

[Python-ideas] Re: Move semantics

All, Most of rust is based around the idea of move semantics. It's really useful in cases wherever you want the object to be mutable, want to avoid side effects from something else still having a reference unintentionally, and avoid a lot of deep copies of the underlying resources. On the

[Python-ideas] Re: Move semantics

C++ has official move syntax via the R-Value Reference (&&). C#/.NET is the only other language I know of where it can be emulated (via Constructors/Assignment operators). I'm not fluent in Perl and Ruby to try to guess if they can support it or not.

[Python-ideas] Re: Move semantics

This reminds me of something in C++. Does it exist in other languages? Do you have a more realistic example where this would catch an important type error? On Thu, Nov 26, 2020 at 5:42 AM <3mi...@gmail.com> wrote: > Add something like Move type hint to typing module. It will tell the > analyzer

[Python-ideas] Re: Move semantics

A little bit more detail may be required to understand why you want this. As I currently read it, you're suggesting something that is mere visual only. def f(d): d['a'] = 2 return d d = {1: 2} a = f(d) print(f'Is d and a the same? {d is a}') # "Is d and a the same? True"