[Python-ideas] Re: Arrow functions polyfill

On 16/02/21 6:29 am, Guido van Rossum wrote: I can sympathize with trying to get a replacement for lambda, because many other languages have jumped on the arrow bandwagon, and few Python first-time programmers have enough of a CS background to recognize the significance of the word lambda. I

[Python-ideas] Re: Conditional with statements

On 8/02/21 6:59 am, Christopher Barker wrote: I find myself reading entire files into memory and then processing them, so as to avoid having to extra-indent all the processing code. I don't know why some people seem to be so afraid of indentation levels. Remember, you don't *have* to indent

[Python-ideas] Re: List .index() Method

On 30/01/21 3:27 am, Francis O'Hara Aidoo wrote: listy = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] if listy.index(10) == -1:   print("Monty Python") > Although ambiguity will make it difficult to implement, The difficulty isn't just with implementation, it's with *specification*. How is

[Python-ideas] Re: Support reversed(itertools.chain(x, y, z))

On 9/01/21 12:54 pm, Steven D'Aprano wrote: Your proposal would still have the surprising consequences that reversing a chain that includes a string would surprisingly split the string into a sequence of characters in reverse order. Not that surprising, since chain already splits strings into

[Python-ideas] Re: Support reversed(itertools.chain(x, y, z))

On 9/01/21 10:19 am, Ram Rachum wrote: In short, I want `reversed(itertools.chain(x, y, z))` that behaves like `itertools.chain(map(reversed, (z, y, x)))`. I think you mean `itertools.chain(*map(reversed, (z, y, x)))` You can get this with itertools.chain(*map(reversed, reversed(t)))

[Python-ideas] Re: Standard tool for iterating over recursive data structures?

On 2/01/21 6:14 am, Jeff Allen wrote: we may as well say that the required result takes the form of an iterable of the nodes, which may subsequently be iterated by a consumer. In general you need more than that, I think. If you're printing a representation of the graph, you want to know about

[Python-ideas] Re: Unpack operator "**" and Mapping

On 30/12/20 11:20 am, Brendan Barnwell wrote: So, to give an example, the iterator protocol should be documented right where the `for` statement is documented, and it should be explicitly framed as "this is the definition of what the `for` statement does", Not sure about that -- there

[Python-ideas] Re: Unpack operator "**" and Mapping

On 30/12/20 9:44 am, Christopher Barker wrote: So there are dunders, and protocols, and ABCs, and they all overlap a bit in purpose. And "protocols" seem to be the least clearly specified. > there are various protocols described in the C API docs, including > the Mapping protocol: > >

[Python-ideas] Re: Unpack operator "**" and Mapping

On 27/12/20 3:03 pm, Chris Angelico wrote: But that would mean that a lot of iterables would look like mappings when they're not. In the context of ** you're expecting a mapping, not a sequence. -- Greg ___ Python-ideas mailing list --

[Python-ideas] Re: Unpack operator "**" and Mapping

On 27/12/20 10:15 am, Christopher Barker wrote: It does seem like ** could be usable with any iterable that returns pairs of objects. However the trick is that when you iterate a dict, you get the keys, not the items, which makes me think that the only thing you should *need* is an items()

[Python-ideas] Re: Standalone bool?

On 22/12/20 6:24 am, Christopher Barker wrote: What I think the OP wants, and I happen to agree, is for Booleans to not only not BE integers in the subclassing sense, but also to not behave as numbers in the. Duck Typing sense. However, that ship has sailed. I think it would have been

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 18/12/20 1:48 pm, Paul Sokolovsky wrote: So, it's already clear that mod.func() syntax will continue to work as before. I don't foresee any problems with implementing that, do you? What about this: import random class A: def choice(self, stuff): return stuff[0] a = A() def

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 18/12/20 7:01 am, Paul Sokolovsky wrote: Now, what if you have an object attribute which stores a callable (no matter is it's bound method, a function, a class, or whatever)? You will need to call it as "(obj.callable_ref)(arg, kw=val)". So, in strict mode, this: import random n =

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 18/12/20 1:52 am, Paul Sokolovsky wrote: On Fri, 18 Dec 2020 01:23:34 +1300 Greg Ewing wrote: On 17/12/20 11:25 pm, Paul Sokolovsky wrote: a) (a.b)() syntax b) apply() being resurrected I can't answer that without knowing what alternative semantics you have in mind for (a.b)(). You

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 17/12/20 11:25 pm, Paul Sokolovsky wrote: CPython compiles "(a.b)()" using LOAD_METHOD not because it consciously "optimizes" it, but simply because it's *unable* to represent the difference between "a.b()" and "(a.b)()". I'm pretty sure whoever added the optimisation fully intended it to

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 17/12/20 9:56 pm, Paul Sokolovsky wrote: It's about a new exciting (hmm, we'll see) feature which, turned out, was there all this time, ... I'm asking fellow Python programmers if they recognize it. If they do, we can consider how to get more from that feature, I don't see how we can get

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 17/12/20 8:16 am, Paul Sokolovsky wrote: With all the above in mind, Python3.7, in a strange twist of fate, and without much ado, has acquired a new operator: the method call, ".()". > CPython3.6 and below didn't have ".()" operator, and compiled it as > "attr access" + "function call", but

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 16/12/20 12:24 am, Paul Sokolovsky wrote: That's good answer, thanks. But... it doesn't correspond to the implementation reality. Why are we talking about implementation? You said you wanted to keep to the conceptual level. At that level, there is NO difference at all. -- Greg

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 15/12/20 11:28 pm, Paul Sokolovsky wrote: that table is not complete. For example, "," (comma) is a (context-dependent) operator in Python, yet that table doesn't have explicit entry for it. Unary "*" and "**" are other context-dependent operators. (Unary "@" too.) Those things aren't

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 15/12/20 11:16 pm, Paul Sokolovsky wrote: I would suggest us rising up in abstraction level a bit, and think not in terms of "intermediate variables" but in terms of "intermediate storage locations". The fact that it's a *named* intermediate storage location is important, because it means

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 15/12/20 10:49 pm, Paul Sokolovsky wrote: the question is what semantic (not implementational!) shift happened in 3.7 (that's the point when it started to be compiled differently). There was no semantic shift. The change had *nothing* to do with semantics. It was *purely* an optimisation.

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 15/12/20 10:04 pm, Paul Sokolovsky wrote: Example 1: a + b + c vs a + (b + c) Question 1: Do you agree that there's a clear difference between left and right expression? Yes, because the default order of operations in Python is defined so that a + b + c is the same as (a + b) + c.

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

On 2/12/20 6:43 am, Paul Sokolovsky wrote: That's why I don't make such claims, and instead making a very different one: that idea with absolute certainty will remove *one* of 50 problems which keep Python slow. But without an implementation demonstrating an actual speed improvement, you're

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

On 30/11/20 9:46 am, David Mertz wrote: def f(a, b, c=21, _foo=foo, _bar=bar): Of course I know that users COULD call `f(1, 2, _foo=something_else)`. But we have asked them not to politely, and  "we're all consenting adults." This doesn't work so well if the function takes *args or **kwds

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

On 29/11/20 11:02 pm, Paul Sokolovsky wrote: It will be much more obvious if there's a general (standalone) "const", I don't think it will. There's nothing about the problem that points towards constness as a solution, so it doesn't matter how many other places in the language "const" appears.

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

On 29/11/20 4:14 am, Paul Sokolovsky wrote: On Fri, 27 Nov 2020 13:06:56 +1300 Greg Ewing wrote: There was no mix-up on my side, and neither seems there was on yours. Block-level scoping and const'ness are orthogonal, well composable features. Someone (maybe not you) suggested "for co

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

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

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

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

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

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

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

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-ideas] Re: Circular Indexing

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 went wrong? Python has no way to tell. -- Greg

[Python-ideas] Re: Circular Indexing

On 26/11/20 2:30 am, nathan.w.edwa...@outlook.com wrote: At times I heavily rely on index out of bound exceptions to reduce the number of lines necessary for error checking. This is a downside to the negative indexing scheme -- you can't tell the difference between a backwards index and an

[Python-ideas] Re: Adding PyInstaller to the standard library

On 25/11/20 12:14 pm, Chris Angelico wrote: If you want a perfectly out-of-the-box app, you're probably going to have to stick to Tkinter. Which is only bundled with Python on Windows, as far as I know. -- Greg ___ Python-ideas mailing list --

[Python-ideas] Re: Adding PyInstaller to the standard library

On 25/11/20 11:48 am, Steven D'Aprano wrote: In a language without declarations, how do you know that something is unused? Personally, I don't mind if I have to *tell* it what I'm using. I don't insist on the stripping-out being automatic, and I would actually prefer it not to be. To support

[Python-ideas] Re: Adding PyInstaller to the standard library

On 24/11/20 9:05 pm, Chris Angelico wrote: It CAN be a proper point-and-click GUI thing. You can have a fully executable Python script if it has no dependencies (just distribute a single .py file with a shebang at the top) ... But to most people a "proper point and click GUI thing" includes

[Python-ideas] Re: Adding PyInstaller to the standard library

On 23/11/20 11:38 pm, Mathew Elman wrote: I would argue this sounds like a case for a "python_runner", i.e. a lightweight python vm that can run python apps, e.g. zipapps. Something like the blender_runner for blender. Making it explicitly an app that runs via some other engine. How would

[Python-ideas] Re: Adding PyInstaller to the standard library

On 22/11/20 4:31 pm, Christopher Barker wrote: unfortunately, that's not how most python packages are set up -- you install the whole thing at once. As an example, it's really tricky to use even one function from scipy without installing the whole thing. Something needs to change about how

[Python-ideas] Re: Adding PyInstaller to the standard library

On 21/11/20 3:59 pm, Christopher Barker wrote: On Fri, Nov 20, 2020 at 4:18 PM Greg Ewing With venvs, it seems like it should be possible to have a very simple tool that just packages up everything in your venv. > conda is similar -- there is even the "conda con

[Python-ideas] Re: Adding PyInstaller to the standard library

On 21/11/20 3:03 am, Paul Moore wrote: For my own purposes, what I *actually* want is to specify a list of 3rd party packages ... I *don't* want clever logic to decide how to strip out "unused" bits. I concur. With venvs, it seems like it should be possible to have a very simple tool that

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 9:17 pm, Andrew Svetlov wrote: Digging into the problem more, I've figured out that PyInstaller has hooks for a bunch of popular libraries to make them work. I've seen this sort of thing in other app

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 12:24 pm, Paul Moore wrote: I'm not sure about an installer. To me that means integrating with system "installed apps" mechanisms. By "installer" I just mean something that gets installed the way users expect on that platform. On Windows that means something you run that puts the

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 11:32 am, Chris Angelico wrote: It's very tempting to think "oh, I could just make it easier for my users, and then they don't have to think about anything". But what happens when there's a security patch for Python? Are they going to continue to not > think about the dependency?

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 8:17 am, Steven D'Aprano wrote: Firstly, does that matter? And secondly, what would it take to give it those additional properties? It matters because it won't look or behave like a MacOSX app to the user. An app bundle comes with metadata that specifies a bunch of things, such

[Python-ideas] Re: Adding PyInstaller to the standard library

On 20/11/20 12:24 am, Chris Angelico wrote: Have you considered the value of using zipapp You get all the advantages of a single runnable file, and all the advantages of NOT including the full Python interpreter with it. It won't have all the properties of an app bundle on MacOSX, though.

[Python-ideas] Re: Adding PyInstaller to the standard library

On 19/11/20 5:59 pm, Chris Angelico wrote: What's the advantage of having it as an official part, rather than remaining a third-party tool? The advantage is that you know it will always be there and will be compatible with the relevant Python, rather than being at the mercy of a 3rd party to

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

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:greg.ew...@canterbury.ac.nz>> wrote: If there's anything I would change, it would be to have the for statement create a ne

[Python-ideas] Re: Exact decimal multiplication and division operations

On 15/10/20 1:59 pm, Tim Peters wrote: I suggested following the standards' rules (the constructor works the same way as everything else - it rounds) for Python's module too, but Mike Cowlishaw (the decimal spec's primary driver) overruled me on that. Did he offer a rationale for that? --

[Python-ideas] Re: Exceptions as function calls to kill boilerplate

On 14/10/20 6:55 am, jmwar...@gmail.com wrote: Why waste the lines defining them anywhere other than where they are thrown and where they are handled for most of them? If you expect people to catch these exceptions, they need to be documented somewhere. A class statement does a much better job

[Python-ideas] Re: Exceptions as function calls to kill boilerplate

On 13/10/20 10:16 am, jmwar...@gmail.com wrote: class MySpecialException(Exception): def __init__(self, some, variables, i, am, tracking): self.some = some ... ... try: if some_test_that_fails(variables): raise MySpecialException(a, b, c, d, e, f) except MySpecialException

[Python-ideas] Re: 'Infinity' constant in Python

On 12/10/20 10:39 am, Wes Turner wrote: We should not discard the scalar in scalar*infinity expressions. I don't think that would help as much as you seem to imagine it would. Consider f(x) = 1/x**2, g(x) = 1/x**3, h(x) = f(x) / g(x). Keeping a scalar multiplier attached to infinities isn't

[Python-ideas] Re: 'Infinity' constant in Python

On 12/10/20 3:44 pm, Wes Turner wrote: [Microscopic] black holes do deal with infinity in certain regards.) Not really. General relativity predicts that matter will collapse into a point of zero size and infinite density inside a black hole. But that's more likely to mean that GR is wrong

[Python-ideas] Re: Variadic generics PEP draft

On 7/10/20 11:05 pm, Matthew Rahtz via Python-ideas wrote: Something that's on many of our wishlists is support for variadic generics. Here's a first draft of a PEP detailing how they might work. https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXsE318/edit Generally

[Python-ideas] Re: CPP Namespaces For Python

New improved version: def submodule(f): co = f.__code__ i = len(co.co_consts) b = bytes([0x64, i, 0x83, 0x0, 0x53, 0x0]) f.__code__ = co.replace( co_consts = co.co_consts + (locals,), co_code = co.co_code[:-4] + b ) return type(f.__name__, (), f()) @submodule def Stuff():

[Python-ideas] Re: CPP Namespaces For Python

On 7/10/20 2:45 pm, Random832 wrote: I think the feature should allow for the functions to directly access each other from the namespace's scope without requiring an attribute lookup. That got me thinking, and I came up with this: def submodule(f): return type(f.__name__, (), f())

[Python-ideas] Re: CPP Namespaces For Python

In Python 3 you can do this without any decorators. The following works and produces the same output: class AA: def greet(A_instance): print("Hello", A_instance.name) class BB: def greet(A_instance): print("Hi", A_instance.name) class A: def __init__(self, state, name):

[Python-ideas] Re: A new suggestion for Python

On 1/10/20 4:25 pm, David Mertz wrote: In all the years I've used and taught namedtuples, I think I've never used the ._replace() method.  The leading underscore is a hint that the method is "private" Usually that would be true, but namedtuple is a special case. The docs make it clear that

[Python-ideas] Re: PEP 637 and keyword only subscripts

On 27/09/20 7:10 pm, Steven D'Aprano wrote: kw = get_keywords() # oops, this returns an empty dict obj[**kw] = value If an explicit d[] is going to be a compile-time error, maybe anything that has the same effect at run time should be an error too? -- Greg

[Python-ideas] Re: PEP 637 and keyword only subscripts

On 27/09/20 3:43 pm, Ricky Teachey wrote: telling people "either provide a default argument for both index AND value in your __setitem__ method, or neither" is also a perfectly legitimate way forward. Giving the value parameter of a __setitem__ a default seems like a weird thing to do, since

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 7:26 am, Oscar Benjamin wrote: The suggestion ... was not that it would be a type-checking error to call the inverse function without catching the exception. It only becomes a type-checking error if a function calls the inverse function and claims not to raise the exception. This

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 5:27 am, Wes Turner wrote: Safe coding styles (in other languages) do specify that *there may not be any unhandled exceptions*. I don't think a blind rule like that actually makes a program any safer. It encourages a coding style that covers up problems and carries on to produce

[Python-ideas] Re: Suggestion: annotated exceptions

On 26/09/20 4:32 am, Oscar Benjamin wrote: annotations could be used to document in a statically analysable way what the "expected" exceptions are. A type checker could use those to check whether a caller is handling the *expected* exceptions But that would be inappropriate. Even if an

[Python-ideas] Re: Naming Accepted PEPs as PAPs

On 22/09/20 6:39 am, Abdur-Rahmaan Janhangeer wrote: I referred PEP8, a meta-pep as PAP8 in the first mail itself If such PEPs are included under PAPs, the 'authorative' point holds Informational PEPs such as PEP 8 are relatively rare. I don't think the whole PEP process should be warped just

[Python-ideas] Re: Naming Accepted PEPs as PAPs

On 22/09/20 6:13 am, Abdur-Rahmaan Janhangeer wrote: All law projects remain law projects. But we call law projects which has been accepted as law. I take it you're referring to the fact that (in some places at least) a proposed law is called a "bill" and when accepted becomes an "act".

[Python-ideas] Re: Naming Accepted PEPs as PAPs

On 21/09/20 6:59 pm, Steven D'Aprano wrote: On Mon, Sep 21, 2020 at 10:26:45AM +0400, Abdur-Rahmaan Janhangeer wrote: I am thinking of proposing to name accepted PEPs as PAPs namely: Python Accepted Proposals. There's precedent for *not* doing that kind of thing. "RFC" stands for "Request For

[Python-ideas] Re: f-strings as assignment targets

On 20/09/20 9:25 pm, Stephen J. Turnbull wrote: Are you sure that shouldn't be "I was told to expect three things, but I found six?" ;-) And why not parse a_string using the "grammar" "{x}{y}{z}" as {'x': 2345, 'y': 6, 'z': 7}? As a human I tend to expect input formats to be somewhat sensible

[Python-ideas] Re: f-strings as assignment targets

On 20/09/20 7:45 am, Christopher Barker wrote: In [4]: from parse import parse In [5]: parse("{x}{y}{z}", a_string) Out[5]: In [6]: parse("{x:d}{y:d}{z:d}", a_string) Out[6]: So that's interesting -- different level of "greadiness" for strings than integers Hmmm, that seems really

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

On 12/09/20 8:36 pm, Serhiy Storchaka wrote: it is not hard to write your own helper with interface and defaults that suit you. It will take less time than writing a letter in a mailing list. Obviously what's needed is an IDE feature such that whenever you write a 3-line function that you

[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?

On 12/09/20 12:21 pm, Guido van Rossum wrote: I had heard of this concept in another language (C++? Smalltalk?) Probably C++ or Java. Smalltalk doesn't have static methods, only a form of class method. IMO, static methods are a kludge only needed in languages that make classes do double duty

[Python-ideas] Re: 'Infinity' constant in Python

On 7/09/20 6:03 am, Christopher Barker wrote: Would that require that it be a keyword? I don't think so, couldn't it be "just a name" in most contexts, like "True" was in py2, which did work in ast.literal_eval()? There could be a special bytecode that looks it up as a name, and if that

[Python-ideas] Re: 'Infinity' constant in Python

On 6/09/20 8:08 am, David Mertz wrote: The only real goal I've seen is that you hope that `x == eval(repr(x))` for floating point numbers.  But that is doomed to failure since it cannot work for NaN by its very definition. I think that just means the definition needs a bit more finesse. It

[Python-ideas] Re: 'Infinity' constant in Python

On 6/09/20 8:08 am, David Mertz wrote: Lots of people have noted that being able to eval a repr is only a vague goal in Python, that works *often* at most. Still, the fact that it *almost* works for floats, except for certain specific values, is a bit annoying. Maybe the solution is for the

[Python-ideas] Re: 'Infinity' constant in Python

On 5/09/20 10:51 am, Chris Angelico wrote: If you make "inf" a keyword, then even the Python standard library is broken. The OP didn't suggest that, he suggested adding a new name such as Infinity that reprs could use. -- Greg ___ Python-ideas

[Python-ideas] Re: 'Infinity' constant in Python

On 5/09/20 10:15 am, Chris Angelico wrote: Remember that if this matters to you, you can "from math import inf". But you still need to use full eval on your repr, which could be a serious security problem in some contexts. If it were a built-in constant, ast.literal_eval could be used instead.

[Python-ideas] Re: On blessed abuse of operators [was: Changing item dunder ...]

On 2/09/20 8:35 am, Chris Angelico wrote: Maybe we need a different term for this kind of overloading, where we're not even TRYING to follow the normal semantics for that operation, but are just doing something because it "feels right". Operator repurposing? -- Greg

[Python-ideas] Re: Proposed new syntax for subscripting (was PEP 472)

On 2/09/20 5:14 am, Stephan Hoyer wrote: On Tue, Sep 1, 2020 at 9:59 AM David Mertz I think we need this for the same reason why we need **kwargs in normal function calls: it makes it possible to forward dictionaries of arguments to another method. If we don't have dict unpacking, you'd have

[Python-ideas] Re: Proposed new syntax for subscripting (was PEP 472)

On 2/09/20 3:44 am, Steven D'Aprano wrote: (9) Keyword-only subscripts are permitted: obj[spam=1, eggs=2] # calls type(obj).__getitem__(spam=1, eggs=2) del obj[spam=1, eggs=2] # calls type(obj).__delitem__(spam=1, eggs=2) An alternative is to pass an empty tuple as the

[Python-ideas] Re: PEP-0472 revisited - draft

On 2/09/20 3:20 am, Christopher Barker wrote: I think that type hints are used in specific places, and thus the interpreter could know if a given [] was a type hint or an indexing operation, and thus could dispatch it differently. I don't think so. We need to be able to do things like

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 2/09/20 2:24 am, Steven D'Aprano wrote: On Sun, Aug 30, 2020 at 05:49:50PM +1200, Greg Ewing wrote: On 30/08/20 3:06 pm, Steven D'Aprano wrote: On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote: a[17, 42] a[time = 17, money = 42] a[money = 42, time = 17] > Compa

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 4:23 pm, Guido van Rossum wrote: On Sun, Aug 30, 2020 at 2:43 AM Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: On 30/08/20 7:45 pm, Guido van Rossum wrote: > I think we should say no to d[*args], because that will just become > d[(*args)]

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 4:11 pm, Guido van Rossum wrote: Can I write a.__getitem__((1, 2), k=3) and the function will see (i, j, k) == (1, 2, 3)? Yes. Okay, and if I write a.__getitem__((1, 3), k=2) will the function see the same thing? No, it will see (i, j, k) == (1, 3, 2). It's the same as if you

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 3:35 pm, Random832 wrote: x[(1,)] old arg=(1,); new args=((1,),)? > x[(1,2)] old arg=(1,2); new args=((1,2),)? No, I proposed *not* to do those -- putting parens around the arguments would continue to make no difference, regardless of which dunder was being called. Also, do we

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 3:37 am, Guido van Rossum wrote: I recall a law from evolutionary biology that went something like “once a feature is gone it won’t evolve a second time (in the same species)”. I have no interest in restoring argument unpacking. That can't be an absolute law. If a species loses a

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

I've written a decorator to go along with Guido's proposed implementation, to make it easier to write item dunders that take positional args that can also be specified by keyword. #--- from inspect import signature def positional_indexing(m): def

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

A thought just occurred to me. If we hadn't got rid of tuple unpacking in argument lists, we would have been able to write def __getitem__(self, (x, y, z), **kwds): ... -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 30/08/20 7:45 pm, Guido van Rossum wrote: Do we want to support d[**kwargs]? It can be done, alternatively we could just ask the user to write the __getitem__/__setitem__ call explicitly. I thought we usually discouraged directly calling dunders unless there's no alternative, because there

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 30/08/20 3:06 pm, Steven D'Aprano wrote: On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote: a[17, 42] a[time = 17, money = 42] a[money = 42, time = 17] I don't think that something like that is exactly the intended use-case for the feature, I don't see why we need

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 30/08/20 2:10 pm, Steven D'Aprano wrote: > I wrote: So I'd be fine with having to write a[(1,)] to get a one-element tuple in both the old and new cases. But the problem is that this is a change in behaviour, Sorry, I got that backwards! What I should have said was that a[1,] would

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 30/08/20 3:49 am, Adam Johnson wrote: def _parse_subscripts(self, /, x, y): return x, y def __getitem__(self, item=MISSING, /, **kwargs): if item is MISSING: args = () elif isintance(item, tuple): args = item else: args = (item,) x, y =

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

Another idea: Instead of new dunders, have a class attribute that flags the existing ones as taking positional and keyword arguments. class ILikeMyIndexesPositional: __newstyleindexing__ = True def __getitem__(self, i, j, spam = 42): ... Advantages: No new

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 29/08/20 2:07 pm, Steven D'Aprano wrote: Better would be to add a new future directive to change the parsing of subscripts, and allow people to opt-in when they are ready on a per-module basis. from __future__ import subscript_arguments I don't think that would help, at least not on

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 29/08/20 4:50 pm, Ricky Teachey wrote: (however [Greg Ewing was] talking about 3 dunders-- still hoping he and others might come around to the idea of just one) Whereas I'm hoping that you might come around to the idea of three, :-) Your version is simpler in the sense that it uses fewer

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On 29/08/20 12:06 am, David Mertz wrote: I only thought of it because `mydict[foo=bar]` now raises a SyntaxError, so raising something different would technically be a change in behavior. It's going to be a change in behaviour whatever you raise, because it's currently a compile time error.

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 3:56 pm, Steven D'Aprano wrote: On Thu, Aug 27, 2020 at 03:28:07AM +1200, Greg Ewing wrote: > We're falling back to __getitem__ here, which doesn't currently allow keywords, Point of order: **the getitem dunder** already allows keywords, and always has, and always will. It's j

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 10:53 am, Todd wrote: On Wed, Aug 26, 2020, 18:04 Stefano Borini > wrote: On Wed, 26 Aug 2020 at 17:50, David Mertz mailto:me...@gnosis.cx>> wrote: you want this acquired_data[time, detector] to be allowed to be written as

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 8:00 am, Christopher Barker wrote: Translating to: thing.__setitem__(self, (ind1, ind2), value, kwd1=v1, kw2=v2) which is pretty darn weird If we use a new set of dunders, the signature of the one for setting could be def __setindex__(self, value, *args, **kwds) which is

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 4:32 am, Ricky Teachey wrote: class Q:     def __subscript__(self, method_name, *args, **kwargs):          return getattr(self, method_name)(*args, **kwargs)     def __getitem__(self, *args, **kwargs): ...     # Note that I have made the RHS value the first argument in

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 3:51 am, Ricky Teachey wrote: On Wed, Aug 26, 2020 at 11:30 AM Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote: No, it would be done by checking type slots, no MRO search involved. Can you elaborate on this for my understanding? For frequently-used specia

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On 27/08/20 2:32 am, Guido van Rossum wrote: The mixins are part of the contract. You are free to override them, their implementation is just a helpful,default. That doesn't really answer my question. To put it another way: If someone wanted to implement an object that obeys the mapping

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 12:53 am, Steven D'Aprano wrote: Presumably the below method is provided by `object`. If not, what provides it? def __getindex__(self, *args, **kwds): if kwds: raise TypeError("Object does not support keyword indexes") if not args:

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 26/08/20 1:59 pm, Steven D'Aprano wrote: Most existing uses of subscripts already don't fit that key:value mapping idea, starting with lists and tuples. Not sure what you mean by that. Given `obj[spam]`, how does the interpreter know whether to call `__getitem__` or `__getindex__`? What

<    1   2   3   4   5   6   7   8   9   >