[Python-ideas] Re: Protocols Subclassing Normal Classes

2023-04-24 Thread Mathew Elman
Rather than changing Protocols and affecting lots of users, it seems like was you really want is a generic class that is the "and" to Union's "or"? e.g. def foo(thing: All[Thread, SupportsStop]): ... which seems reasonable. If that appeals to you, then you probably want to raise that on the

[Python-ideas] Extending LiteralString or Literal with structural validation

2022-12-20 Thread Mathew Elman
This is somewhat inspired by the "Tagged strings in python" thread, but from a different approach. Specifically, rather than messing with runtime python, using static type analysis to help the usability of specific kinds of string literals. It would be useful to take advantage of the `LiteralStr

[Python-ideas] Re: Void type

2022-07-27 Thread Mathew Elman
Chris Angelico wrote: > On Wed, 27 Jul 2022 at 21:54, Mathew Elman mathew.el...@ocado.com wrote: > > I don't see why you couldn't. I guess what they do depends if any of these > > have defaults? Which I think they do not in this case, right? > > If they were non

[Python-ideas] Re: Void type

2022-07-27 Thread Mathew Elman
I don't see why you couldn't. I guess what they do depends if any of these have defaults? Which I think they do not in this case, right? If they were non vanilla dictionaries that had a default e.g. class SomeDict(dict): def __getitem__(self, item=None): return super().__getitem__(it

[Python-ideas] Re: Void type

2022-07-27 Thread Mathew Elman
To answer how this _could_ work, Undefined would be a new NoneType that is falsey (just like None) can't be reassigned (just like None) and does everything else just like None _except_ that when it is passed as a function argument, the argument name is bound to the default if it has one instead.

[Python-ideas] Re: Void type

2022-07-26 Thread Mathew Elman
I believe this is a rebirth of a request that has come up many times before, which is to have something like javascript's `undefined` where it means "use the default value" if passed to a function that has a default value or "value not provided" (slightly different to "None"). >> def foo(x, y=1

[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating

2022-06-20 Thread Mathew Elman
Chris Angelico wrote: > On Mon, 20 Jun 2022 at 21:11, Mathew Elman mathew.el...@ocado.com wrote: > > This I like - it seems very intuitive, almost like an irreversible io > > stream. > > I don't know if there would be cases where this would lead to unexpected > >

[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating

2022-06-20 Thread Mathew Elman
This I like - it seems very intuitive, almost like an irreversible io stream. I don't know if there would be cases where this would lead to unexpected bugs, but without looking into it it seems nice. Question: What would be the natural behaviour for negative indices? Raising an error?

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

2022-06-15 Thread Mathew Elman
Could this be the behaviour of passing in an Ellipsis? e.g. def foo(defaults_to_one=1): return defaults_to_one assert foo(...) == foo() def bar(something=...): return foo(something) assert bar() == foo() def baz(arg): # no defaults return arg assert baz(...) == ... The only plac

[Python-ideas] Re: Null wildcard in de-structuring to ignore remainder and stop iterating

2022-06-09 Thread Mathew Elman
would it not be possible to have slicing fallback to islice if __iter__ is implemented and __geitem__ is not? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/m

[Python-ideas] Re: Addition to fnmatch.py

2022-06-06 Thread Mathew Elman
oops, you're right, I have ended up with an unnecessary "not" in there, should be: from collections import deque def partition(pred, iterable): results = deque([]), deque([]) def gen_split(only): for thing in iterable: if results[only]: yield results

[Python-ideas] Re: Addition to fnmatch.py

2022-06-06 Thread Mathew Elman
from collections import deque def partition(pred, iterable): results = deque([]), deque([]) def gen_split(only): for thing in iterable: if results[only]: yield results[only].popleft() results[not pred(thing)].append(thing) for thing

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-19 Thread Mathew Elman
> Seems like the docs should cover that (or even `help()`) -- and if not, then > the parameter names could be better. It should, and normally does as do the parameters, but the best documentation should be the code itself, right? So the idea here would be to make it harder to not know the order

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
> Reminds me of some testing/assertion frameworks. I'm not a fan, but > some people like it. > > expect(thing).to.be.numeric() That rings a bell with test a javascript test framework, something like enzyme? ___ Python-ideas mailing list -- python-ideas@

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
> I think that a programming language needs to be different enough from a > natural language to remind you that it's a programming language and that > the computer isn't that smart. The computer will do as you say, not as > you mean. I agree entirely, that's why I am not suggesting putting spac

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
This is interesting, it's not as nice as native syntax support could have been but a decorator like this is also pretty nice. I think I would bikeshed this so the decorator was the full dot separated signature, e.g. @curry_helper('insert.into') def insert(x: Any, y: list): def y.append(x)

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
Not really, I'm not trying to suggest a fully English like language be incepted into python, my main point here was that there are cases where the order of arguments is important and being able to have actually positional arguments would go a long way to improving knowing intuitively that order.

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
> What you are describing is very, very dissimilar to currying. It's simply > multi-argument functions with a different call syntax. It is almost identical to currying, the only differences are: 1. the intermediate return being an object with an attribute (rather than a new function) that you ca

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
Paul Moore wrote: > On Mon, 18 Oct 2021 at 12:49, Mathew Elman mathew.el...@ocado.com wrote: > > The point is that at the moment to set this sort of api up requires a lot > > of work, defeating 50% of the value i.e. to define a new function with the > > attribute acce

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
> Still, I don't want Python to try to be Cobol. I agree, I don't want Python to try and be Cobol, but that doesn't mean there aren't things to learn from Cobol regarding this, if this indeed something found there - I can't comment on that. > I think the intellectual argument for "English synt

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
The point is that at the moment to set this sort of api up requires a lot of work, defeating 50% of the value i.e. to define a new function with the attribute access behaviour requires defining each individual function to return a middle step object that has the attribute of the next function, s

[Python-ideas] Re: Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
That is interesting but is missing the point of what I am really getting at, in order to build a function of multiple args this way would require a lot of these "operators" that would need to be interchangeable, so I don't think what I am looking for is an operator. The key point being having

[Python-ideas] Real Positional Arguments or OO Currying

2021-10-18 Thread Mathew Elman
I don't know if this has been suggested before, or if this is outlandishly impossible (though I would be surprised if it was), so apologies in advance if so. I have on occasion come across a situation where I use/write a signature like this: def insert_x_into_y(x, y): ... or worse

[Python-ideas] Re: Deprecate sum of lists

2021-06-18 Thread Mathew Elman
I don't see how allowing [x, y for x in a] follows from allowing [*chunk for chunk in list_of_lists]. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mail

[Python-ideas] Re: Should PEP 637 legalize "obj[]"?

2020-12-24 Thread Mathew Elman
I am +0.5 on allowing this, unless I misunderstand the implications, this would still raise errors in the cases where an empty tuple was not an intended key/index/argument. I can see that `obj[]` is less explicit than `obj[()]` but is no less clear (if it is allowed). However, I am only +0.5 be

[Python-ideas] Re: Standalone bool?

2020-12-21 Thread Mathew Elman
Christopher Barker wrote: > > Surely what you're looking for is some kind of typed > > hash table? > > Maybe, maybe not. My impression is that the Typed hash table is a kluge to > get around this one issue. > As others have pointed out, 1 and 1.0 are considered equal, and thus hash > the same — a

[Python-ideas] Re: Standalone bool?

2020-12-21 Thread Mathew Elman
Surely what you're looking for is some kind of typed hash table? Maybe you should be suggesting adding a TypedMapping to collections or something like that? But it seems to be your solution is fine, but maybe could abstract away the types in the keys in the class dunders? ``` class TypedMapping

[Python-ideas] Re: Lazy Type Casting

2020-12-10 Thread Mathew Elman
Steven D'Aprano wrote: > On Wed, Dec 09, 2020 at 12:05:17PM -, Mathew Elman wrote: > > Steven D'Aprano wrote: > > On Tue, Dec 08, 2020 at 11:46:59AM -, Mathew > > Elman wrote: > > I would like to propose adding lazy types for > > casting > >

[Python-ideas] Re: Lazy Type Casting

2020-12-09 Thread Mathew Elman
Stestagg wrote: > That makes sense, so these are kind of 'views' over a sequence, but ones > that implement a copy-on-write when the underlying object is modified in > any way? yes, a lazy sequence type would be exactly that, that is a nice way of putting it > I can see this being super hard/imp

[Python-ideas] Re: Lazy Type Casting

2020-12-09 Thread Mathew Elman
I agree that if you are using them as iterables, then the type is usually not important because you are treating their type as just iter-able. The lazy iterable would more or less just be the same as passing in `iter(sequence)`. This is for other use cases where the use of the object is specific

[Python-ideas] Re: Lazy Type Casting

2020-12-09 Thread Mathew Elman
Steven D'Aprano wrote: > On Tue, Dec 08, 2020 at 11:46:59AM -, Mathew Elman wrote: > > I would like to propose adding lazy types for casting > > builtins in a > > lazy fashion. e.g. lazy_tuple which creates a reference to the > > source iterable and a mor

[Python-ideas] Lazy Type Casting

2020-12-08 Thread Mathew Elman
I am not sure if this has been suggested before, so my apologies if it has. I would like to propose adding lazy types for casting builtins in a lazy fashion. e.g. `lazy_tuple` which creates a reference to the source iterable and a morally immutable sequence but only populates the tupular contain

[Python-ideas] Re: Make for/while loops nameable.

2020-12-03 Thread Mathew Elman
I personally am +1 for something like this. What about for use with `continue` as well? e.g. > for i in range(10) as i_loop: > for j in range(i, i + 10) as j_loop: > if i + j == 9: > continue i_loop which will break out of j_loop and go to the next i (as if the `continue

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

2020-11-23 Thread Mathew Elman
> That's essentially like Java's JRE. For what it's worth, on my PC the > JRE is 196M in size. Whereas a full Python distribution is only 94M, > and the embedded distribution is 15M. So I think Python already has > that, more or less. I hadn't realised that, so thanks :) > But my experience with

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

2020-11-23 Thread Mathew Elman
I suppose functionally there may be little difference, but having an explicit "runner" would allow two things: 1. the runner and stdlib for it could be in a compress format itself since it doesn't need to provide any utility for editing or navigating human readable modules. and so lighter 2. it

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

2020-11-23 Thread Mathew Elman
> > Oh, and Chrome itself needs to be updated -- only on > > what, millions of machines? V8 is bundled with Chrome -- you know, kind of > > like a > > PyInstaller app bundles Python ;-) > > Uhhh... no, that's kind of like how Python bundles Python. That's not > bundling an app. You update Chrome o

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

2020-11-19 Thread Mathew Elman
Perhaps there could be something in the std-lib that allowed packaging into an executable but with some limitations, as a toy example: only supporting the std-lib dependencies. There is some precedence for minimal implementations existing in std-lib and third party libraries being more capable e

[Python-ideas] Re: A python_include() for cgi programming

2020-11-04 Thread Mathew Elman
The recommended way to import files this way is rather to use `importlib`. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.or

[Python-ideas] Re: except-try block

2020-10-12 Thread Mathew Elman
This is quite similar to something I suggested on Python Discussions https://discuss.python.org/t/add-way-to-reenter-previous-try-block/4526 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@pytho

[Python-ideas] Re: Make start, stop, step properties on islice

2020-08-13 Thread Mathew Elman
You're absolutely right, I realized that __len__ would be the maximum possible length after posting, and it would likely be more dangerous than helpful ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-

[Python-ideas] Make start, stop, step properties on islice

2020-08-12 Thread Mathew Elman
Is there a reason that itertools.islice does not provide its start, stop and step values as attributes, similar to range? This seems like a sensible and useful thing to have, and would also allow islice's to have a __len__. Mathew ___ Python-ideas mail

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

2020-08-06 Thread Mathew Elman
respond to 5 and 6 but I can indeed see these being sticking points. On Thu, 6 Aug 2020 at 08:57, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Mathew Elman writes: > > > Being able to break multiple loops and having "labelled" breaks > > would

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

2020-08-05 Thread Mathew Elman
Being able to break multiple loops and having "labelled" breaks would be achievable using `except`, i.e. adding `except` to the loop statements before `else` like this: for elem in iterable: > ... > if should_break(elem): > raise SomeException > except SomeException as e: > han

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

2020-07-29 Thread Mathew Elman
On Wed, 29 Jul 2020 at 14:42, Guido van Rossum wrote: > On Wed, Jul 29, 2020 at 02:51 Mathew Elman wrote: > >> >> . >> >>> If it *is* useful, it occurs to me that (1) this looks a lot like the >>> try ... except ... pattern, and (2) breaks are generally

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

2020-07-29 Thread Mathew Elman
. > If it *is* useful, it occurs to me that (1) this looks a lot like the > try ... except ... pattern, and (2) breaks are generally perceived as > exceptional exits from a loop. Instead of "if break [LABEL]", "except > [LABEL]" might work, although the semantic difference between labels > and ex

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-24 Thread Mathew Elman
On Thu, 23 Jul 2020 at 16:25, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Mathew Elman writes: > > > Frankly, saying that a part of a language that is frequently > > misunderstood, is *never* allowed to be improved is disappointing > > when

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-22 Thread Mathew Elman
On Wed, 22 Jul 2020 at 13:45, Paul Moore wrote: > On Wed, 22 Jul 2020 at 13:18, Mathew Elman wrote: > >> Ones that retain else on loops are bad because > >> they end up providing two (typically equally confusing) ways of doing > >> things. > > > > I

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-22 Thread Mathew Elman
On Wed, 22 Jul 2020 at 12:24, Paul Moore wrote: > On Wed, 22 Jul 2020 at 10:54, Stestagg wrote: > > > > I'm (weakly) +1 for the concept of for..else being confusing, weird, and > somehow not quite suitable/useful for many use-cases where it feels like it > should. > > > > I'm -1 for each of the

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-22 Thread Mathew Elman
On Wed, 22 Jul 2020 at 04:47, Paul Sokolovsky wrote: > Hello, > > On Tue, 21 Jul 2020 17:48:35 -0700 > Christopher Barker wrote: > > > how about: > > > > for something in some_iterable: > > some_stuff_with_maybe_a_break > > else if not break: > > something_more > > > > No new keywords :-

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-20 Thread Mathew Elman
On Sun, 19 Jul 2020 at 15:43, Олег Комлев wrote: > Thank to all disputants. > It is possible to borrow the keyword "case" from PEP-622 (when it appears > https://www.python.org/dev/peps/pep-0622). Keyword "case" can be written > instead of "else/elif". I.e. > case COND: > ... > [case COND: >

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-15 Thread Mathew Elman
an be exited > either normally (because all code has been executed) or because it raised > an exception; here `else` means it exited normally. Similarly a `for` loop > can terminate either normally by executing all iterations or because a > `break` occurred; and similarly `else` means it termi

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-14 Thread Mathew Elman
But in `for...else` the `else` call isn't always called, so changing `else` for `finally` doesn't make sense. What you're suggesting is replacing `else` with `on_finish` and adding `finally` and `on_break`. I agree that having `finally` could make the use cases of `else` clearer, but I am not conv

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-14 Thread Mathew Elman
On Tue, 14 Jul 2020 at 12:38, Dominik Vilsmeier wrote: > On 14.07.20 09:54, Mathew Elman wrote: > > What about adding `except` to the compound loop statement? > That way in cases where there needs to be clarity you can raise a specific > exception rather than just `break`. > Ke

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

2020-07-14 Thread Mathew Elman
What about adding `except` to the compound loop statement? That way in cases where there needs to be clarity you can raise a specific exception rather than just `break`. Keeping the logic of why you "break" the loop inside the loop and would also allow multiple reasons for breaking from a for loop

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

2020-06-23 Thread Mathew Elman
Well there you go, good point. I didn't really like it being an operator myself. But I can see having a math.tolerance class being useful. On Tue, 23 Jun 2020 at 13:53, Jonathan Goble wrote: > On Tue, Jun 23, 2020 at 8:44 AM Mathew Elman > wrote: > >> Perhaps a more versati

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

2020-06-23 Thread Mathew Elman
Perhaps a more versatile operator would be to introduce a +- operator that would return an object with an __eq__ method that checks for equality in the tolerance i.e a == b +- 0.5 Although I don't like this either since you could achieve the same thing with something like this: class Tol