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
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
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
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
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.
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
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
> >
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?
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
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
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
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
> 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
> 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@
> 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
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)
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.
> 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
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
> 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
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
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
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
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
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
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
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
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
> >
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
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
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
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
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
> 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
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
> > 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
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
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
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
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-
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
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
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
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
.
> 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
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
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
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
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 :-
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:
>
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
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
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
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
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
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
56 matches
Mail list logo