Circular indexing will only extend the range of allowable indices to the set of
all integers !!!
Can you provide some example of the "billions of lines of working code" that
the circular indexing scheme supposedly breaks so that we can have a more
informed discussion?
Deeper mathematical rea
Here's about 9 million lines that would stop working:
https://github.com/search?l=Python&q=except+IndexError&type=Code
On Thu, Nov 26, 2020 at 10:20 AM Mathew M. Noel via Python-ideas <
[email protected]> wrote:
> Circular indexing will only extend the range of allowable indices to the
> se
On Thu, Nov 26, 2020 at 04:56:34AM +, Mathew M. Noel via Python-ideas wrote:
>
> Why not use list_name[-n%N] whenever you need to use negative indices
> and raise an index out of bounds exception with negative indices like
> other programming languages?
If this was Python 0.1 back in 1991,
On Thu, Nov 26, 2020 at 08:20:19AM +, Mathew M. Noel via Python-ideas wrote:
> Circular indexing will only extend the range of allowable indices to the set
> of
> all integers !!!
Is that supposed to be a feature, or a terrible threat?
[...]
> Deeper mathematical reason behind circular ind
On Thu, Nov 26, 2020 at 01:27:46PM +1300, Greg Ewing wrote:
> On 26/11/20 12:41 pm, Steven D'Aprano wrote:
> > a = "abcdef"
> > a[-2] # returns a result
>
> Yes, but did you *intend* that result, or did the -2
> result from a calculation that should have returned a
> positive index but we
On 26/11/20 7:07 pm, Guido van Rossum wrote:
Hmm... In the end I think the language design issue is with functions
(and how they capture variable references rather than values)
Well, every other language I know of that has a notion of closures
captures variables exactly the same way that Python
Hello,
On Thu, 19 Nov 2020 18:53:01 +1300
Greg Ewing wrote:
> Starting a new thread for this as suggested by Guido.
>
> On 18/11/20 7:20 pm, Guido van Rossum wrote:
> > On Tue, Nov 17, 2020 at 22:12 Greg Ewing
> > mailto:[email protected]>>
> > wrote:
> >
> > If there's anything
Every Python program that I have ever written implicitly relies on the current
behavior of list. Changing the builtin list type would be such a massive
breaking change that it simply is not going to happen. As others have noted,
writing your own list subclass would solve your problem here.
I
On Thu, Nov 26, 2020 at 02:11:10PM +0300, Paul Sokolovsky wrote:
> Using "let" will then give natural way to introduce proper block-level
> lexical scoping in Python:
Why would we want to do that?
Block-level scoping is too much of a good thing. The right level of
scoping is the function, not t
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)
print(d[1]) # mistake, using of moved value
_
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.
>
>
> > def foo():
> > let x = 1
> > if bar:
> > let x = 2
> > ...
> > # x is 1 again her
Hello,
On Fri, 27 Nov 2020 00:25:21 +1100
Steven D'Aprano wrote:
> On Thu, Nov 26, 2020 at 02:11:10PM +0300, Paul Sokolovsky wrote:
>
> > Using "let" will then give natural way to introduce proper
> > block-level lexical scoping in Python:
>
> Why would we want to do that?
Because without t
I know what your getting at, this will work if you want to have variables in
the included file in scope in the caller of 'include', just insert it as normal
python.
Though I prefer this version as it is simpler and less error prone.
with open('myfile.py') as f: exec(f.read())
Basically, it inc
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"
_
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 <[email protected]> wrote:
> Add something like Move type hint to typing module. It will tell the
> analyzer
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.
__
On Thu, Nov 26, 2020 at 9:08 AM Steven D'Aprano wrote:
> > and simplifies implementation of the widely used convolution operation
> in signal processing.
>
> For the benefit of the 99.9% of Python programmers who have no idea
> what this "convolution operation" is, can you give an example? It's o
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 project
On Thu, Nov 26, 2020, 5:12 AM Greg Ewing
> Then we just need a way to specify that particular names are
> captured by value. Not sure how to do that in a way that doesn't look ugly
> and/or obscure.
>
Isn't that EXACTLY what you call "default argument abuse"?!
To me, that is concise, obvious, an
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 "
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 c
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 b
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 exha
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, inst
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
On 25Nov2020 22:07, Guido van Rossum wrote:
>Hmm... In the end I think the language design issue is with functions (and
>how they capture variable references rather than values), and fixing it by
>changing the for-loop is still just a band-aid, with other problems and
>inconsistencies. Agreed that
On Thu, Nov 26, 2020 at 5:43 AM <[email protected]> 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 incomp
On 27Nov2020 00:25, Steven D'Aprano wrote:
>Block scoping allows shadowing within a function.
Just to this: it needn't.
You could forbid shadowing of the _static_ outer scope easily enough at
parse/compile time. That would prevent a certain class of easy misuse.
i = 9
{ new scope here
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 ident
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-author who can help you
write a convincing motivation to sway the Steering Council (not me).
(W
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 only
On 27/11/20 12:11 am, Paul Sokolovsky wrote:
On Thu, 19 Nov 2020 18:53:01 +1300
Greg Ewing wrote:
Note that this is *not* the same as introducing a new scope.
And that's very sad. That means instead of solving the root of the
problem, adhoc workarounds are proliferated.
I'd be open to the
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 in
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 subconsciously assume. For example, loop
variables in list comprehensions
On Fri, Nov 27, 2020 at 11:08 AM Greg Ewing wrote:
> > I'd suggest that it should be "for let"
>
> 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 concepts.
How will this "new assi
On 11/26/20 6:44 AM, [email protected] 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)
p
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 mai
On 2020-11-27 01:12, Ned Batchelder wrote:
On 11/26/20 6:44 AM, [email protected] 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:
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, [email protected] 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:
```
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, [email protected] wrote:
Add something like Move type hint to typing module. It will tell the
analyzer that the input parameter of the function is moved an
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
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, [email protected] wrote:
Add something like Move type hint to typing module. It will tell the
analyzer that the input par
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, [email protected] wrote:
> Add something like Move type hint to typing module. It will tell
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 concepts.
Python manages to not be wildly ungrammatical with the bits
of English that i
On Fri, Nov 27, 2020 at 4:34 PM 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 concepts.
>
> Pyt
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
46 matches
Mail list logo
