On Tue, 1 Feb 2022 at 09:02, Cameron Simpson wrote:
>
> [... big snip...]
>
> On 22Jan2022 01:41, Chris Angelico wrote:
> >On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno wrote:
> >> At that point, I argue that despite adding still more things to
> >> the sy
On Sat, 22 Jan 2022 at 09:45, Steven D'Aprano wrote:
>
> On Fri, Jan 21, 2022 at 10:56:42PM +1100, Chris Angelico wrote:
>
> > Let's be fair here... The idea of freezing is to make it hashable,
>
> And immutable.
>
> > so there's no point talking about freezing a
On Sat, 22 Jan 2022 at 00:56, Joao S. O. Bueno wrote:
>>
>> I don't understand polynomials as frozensets. What's the point of
>> representing them that way? Particularly if you're converting to and
>> from dicts all the time, why not represent them as dicts? Or as some
>> custom mapping type, if
On Sat, 22 Jan 2022 at 00:30, Joao S. O. Bueno wrote:
>>
>> Yes, but have you _seen_ the bickering about the existing bracket
>>
>> choices just for frozenset? Eww. Hence the going for a distinct operator
>> altogether. Yes, I'd prefer brackets of some kind too, but they're
>> taken.
>
> If one
On Fri, 21 Jan 2022 at 22:52, Oscar Benjamin wrote:
>
> On Thu, 20 Jan 2022 at 10:19, Ricky Teachey wrote:
>>
>> On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull
>> wrote:
>>>
>>> Christopher Barker writes:
>>>
>>> > If this does all come to pass, then:
>>> >
>>> > s = {3,8,2}.frozen()
On Fri, 21 Jan 2022 at 22:52, Ricky Teachey wrote:
>
> On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano wrote:
>>
>> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
>>
>> > Paired with a __freeze__ dunder method, this applies to any type, not
>> > just sets. (Where appropriate of
On Fri, 21 Jan 2022 at 19:53, Cameron Simpson wrote:
>
> On 20Jan2022 19:31, Eric V. Smith wrote:
> >See also the rejected PEP 351.
>
> Ah. So close to my idea as to be indistinguishable. That's a shame.
> Thanks, Cameron Simpson
It's worth noting that a rejected PEP isn't the final and
On Thu, Jan 20, 2022 at 1:47 AM Alexandre Brault
wrote:
>
> On 2022-01-18 6:12 p.m., Chris Angelico wrote:
> > 3) Optional semantic difference: 【1, 2, 3】 is exactly the same as (1,
> > 2, 3), but 【1, 2, 3) would be an error.
>
> What does it say about the viability
On Wed, Jan 19, 2022 at 6:31 PM Ben Rudiak-Gould wrote:
>
> My preferred syntax for a frozenset literal would be something like
>
> {1, 2, 3}.freeze()
>
> This requires no new syntax, and can be safely optimized at compile time (as
> far as I can tell).
>
> set.freeze would be a new method
On Wed, Jan 19, 2022 at 11:10 AM Steven D'Aprano wrote:
>
> On Wed, Jan 19, 2022 at 10:12:23AM +1100, Chris Angelico wrote:
>
> > Not sure about Python, but C and C++ have digraphs and trigraphs as
> > alternatives for certain symbols, specifically because some
>
On Wed, Jan 19, 2022 at 9:47 AM Steven D'Aprano wrote:
>
> On Tue, Jan 18, 2022 at 07:40:40AM -0700, 2qdxy4rzwzuui...@potatochowder.com
> wrote:
> > On 2022-01-18 at 12:07:15 +1100,
> > Steven D'Aprano wrote:
> >
> > > I would be more sympathetic to this idea if:
> >
> > > 1. I knew how to
On Mon, Jan 17, 2022 at 7:12 PM Paul Moore wrote:
>
> On Mon, 17 Jan 2022 at 01:11, Chris Angelico wrote:
> >
> > On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
> > >
> > > On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > > > >&g
On Mon, Jan 17, 2022 at 4:38 PM Christopher Barker wrote:
>
> On Sun, Jan 16, 2022 at 6:34 PM Chris Angelico wrote:
>>
>> > def fun():
>> > return "some string"
>> >
>> > doesn't return the same string, unless it's iterned, which i
On Mon, Jan 17, 2022 at 2:01 PM Steven D'Aprano wrote:
> > Yes. ONLY on strings. That's exactly what I said. Strings are
> > different. For starters, we already have multiple different data types
> > that can come from quoted literals, plus a non-literal form that
> > people treat like a literal
On Mon, Jan 17, 2022 at 1:14 PM Christopher Barker wrote:
> why/how would it do that? It *could* do that -- as above, with interning. but:
>
> def fun():
> return "some string"
>
> doesn't return the same string, unless it's iterned, which is an
> implementation detail, yes?
Not sure what
On Mon, Jan 17, 2022 at 11:18 AM Steven D'Aprano wrote:
>
> On Sun, Jan 16, 2022 at 11:41:52PM +1100, Chris Angelico wrote:
> > On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano
> > wrote:
>
> > > Not to mention:
> > >
> > > r(1, 2, 3) # loo
On Mon, Jan 17, 2022 at 10:14 AM Paul Moore wrote:
>
> On Sun, 16 Jan 2022 at 22:55, Steven D'Aprano wrote:
> > >>> def f():
> > ... return frozenset({1, 2, 3})
> > ...
> > >>> a = f.__code__.co_consts[1]
> > >>> a
> > frozenset({1, 2, 3})
> > >>> b = f()
> > >>> assert a == b
> > >>> a is b
On Mon, Jan 17, 2022 at 9:55 AM Steven D'Aprano wrote:
>
> On Sun, Jan 16, 2022 at 04:50:40PM +, MRAB wrote:
>
> > Not quite as bad as that:
> >
> > >>> f = frozenset({1, 2, 3})
> > >>> f is frozenset(f)
> > True
>
> Mark suggested that on the bug tracker too, but that's not relevant. As
> I
On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano wrote:
>
> On Sun, Jan 16, 2022 at 09:18:40PM +1100, Chris Angelico wrote:
>
> > While it's tempting, it does create an awkward distinction.
> >
> > f(1, 2, 3) # look up f, call it with parameters
> >
On Sun, Jan 16, 2022 at 7:35 PM Steven D'Aprano wrote:
> How does this work for you?
>
> f{1, 2, 3}
>
While it's tempting, it does create an awkward distinction.
f(1, 2, 3) # look up f, call it with parameters
f[1, 2, 3] # look up f, subscript it with paramters
f{1, 2, 3} # construct a
On Tue, Jan 4, 2022 at 3:32 PM elvis kahoro wrote:
>>
>> Reading between the lines, I *think* that you want the match statement
>> to catch the exception that you get when the attribute lookup fails, am
>> I right?
>
> Yes!
>
> I was hoping there could be some syntax to extend pattern matching to
On Wed, Dec 29, 2021 at 4:54 AM Christopher Barker wrote:
>
> On Tue, Dec 28, 2021 at 5:31 AM David Mertz, Ph.D.
> wrote:
>>
>> On Tue, Dec 28, 2021 at 1:15 AM Christopher Barker
>> wrote:
>>>
>>> On Mon, Dec 27, 2021 at 4:07 PM Steven D'Aprano
Julia (if I recall correctly) has a
On Sun, Dec 26, 2021 at 11:32 AM Jeremiah Vivian
wrote:
>
> Steven D'Aprano wrote:
> > On Thu, Dec 23, 2021 at 05:53:46PM -, Stefan Pochmann wrote:
> > > Chris Angelico wrote:
> > > If you're removing multiple, it's usually best to filter. This is a
> > >
On Sun, Dec 26, 2021 at 11:00 AM Steven D'Aprano wrote:
>
> On Thu, Dec 23, 2021 at 05:53:46PM -, Stefan Pochmann wrote:
> > Chris Angelico wrote:
> > > If you're removing multiple, it's usually best to filter. This is a
> > > great opportunity to l
On Fri, Dec 24, 2021 at 12:14 AM Hao Hu wrote:
>- generalize the signature of __hash__(object) to __hash__(object,
> *args, **kwargs). In the default implementation, we discard the keyword
> "salt" and use the default fallback salt if the keyword is not present,
> otherwise we use the salt
On Thu, Dec 23, 2021 at 5:40 PM Stephen J. Turnbull
wrote:
>
> Hao Hu writes:
> > On 12/18/21 08:44, Stephen J. Turnbull wrote:
> > > Hao Hu writes:
>
> > > > >> For instance, if we create a caching programming interface that
> > > > >> relies on a distributed kv store,
> > >
> > > I
On Wed, Dec 22, 2021 at 11:12 AM Jeremiah Vivian
wrote:
>
> I expect some sort of "there's no benefit in this, just write the current
> implementation", indirectly or directly.
> Currently, this is the way to remove `num` occurrences of an element from a
> list:
> > idx = 0
> > while idx <
On Sun, Dec 19, 2021 at 8:10 AM Ethan Furman wrote:
>
> By way of correcting misconceptions:
>
> On 12/18/21 8:39 AM, Chris Angelico wrote:
> >
> > I'm not sure that this is actually possible the way you're doing it.
> > The descriptor protocol (which is wha
On Sun, Dec 19, 2021 at 3:31 AM wrote:
>
> In the following situations:
>
>
> class Data(object):
> @staticmethod
> @property
> def imagesTotal():
> return 10
>
> print(Data.imagesTotal)
>
>
> The "print(Data.imagesTotal)" can't print "10", it print " 0x...>".
>
> It might be
On Sat, Dec 18, 2021 at 2:21 AM Hao Hu wrote:
> Great question. I agree that there could be other factors which slow things
> down much more than the hash function.
> I assume that this is a function that’ll be potentially called a lot of
> times, and the cumulated cost won’t be negligible.
>
On Sat, Dec 18, 2021 at 1:44 AM Hao Hu wrote:
> > For that sort of thing, it may be more practical to use your own
> > hashing function, possibly a cryptographically secure one. The precise
> > hashing function used by Python isn't guaranteed, so if you need it to
> > be stable across different
On Sat, Dec 18, 2021 at 1:21 AM Hao Hu wrote:
>
> Hi,
>
> I am wondering if it would be good to add an additional keyword `seed` to the
> builtin function *hash* to allow us to set arbitrary seed to ensure
> reproducible results.
>
The built-in hash() function is extremely generic, so it can't
On Mon, Dec 13, 2021 at 11:29 AM MRAB wrote:
>
> Hmm.
>
> What about something like this as a bit of syntax:
>
> def my_decorator(f):
> @wraps
> def wrapper(from my_decorator):
> return f(from my_decorator)
> return wrapper
>
> The idea is that in a
On Sun, Dec 12, 2021 at 10:25 PM Steven D'Aprano wrote:
>
> It seems to me that Chris is determined to push forward with his ideas
> for default expressions, regardless of the mostly-negative feedback on
> Python-Ideas. I'm also unsure whether he has tried to get any feedback
> on other forums,
On Sun, Dec 12, 2021 at 8:16 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > By "alternative ideas", do you mean "alternative ways to implement
> > argument defaults",
>
> As you just phrased it, yes. I do not know how I can mak
On Sun, Dec 12, 2021 at 5:02 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
> > On Sat, Dec 11, 2021 at 8:07 PM Stephen J. Turnbull
> > wrote:
>
> > > This isn't about your proposal, it's about more general syntax. Not
> > > everything being
On Sun, Dec 12, 2021 at 1:23 PM Steven D'Aprano wrote:
>
> TL;DR: it is hard, but not impossible, to set function `__globals__`
> dunder to a ChainMap. Let's make it easier!
>
> Attempt 1: set __globals__ directly.
>
> >>> func.__globals__ = ns
> Traceback (most recent call last):
> File "",
On Sun, Dec 12, 2021 at 4:06 AM Christopher Barker wrote:
> Here’s a new (not well thought out) idea:
>
> @dataclasses.dataclass
> class A:
> Input_list: list
> length: int => len(input_list)
>
> So length gets set to a “late bound default expression” that Is an actual
> value. It would
On Sat, Dec 11, 2021 at 8:07 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
> > On Sat, Dec 11, 2021 at 5:35 PM Stephen J. Turnbull
> > wrote:
>
> > > foo(x=>[a])
>
> > I'm not sure what that last line would mean.
>
> This is
On Sat, Dec 11, 2021 at 8:07 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > It's larger than argument defaults, but also smaller:
>
> Aside: I'm quite confused by your whole line of discussion here, but
> I'll let Eric follow up.
>
> > The
On Sat, Dec 11, 2021 at 5:35 PM Stephen J. Turnbull
wrote:
>
> Eric V. Smith writes:
>
> > That's why I think we should have a larger concept that just late-bound
> > parameters: I think there's a general concept here that can be extended
> > beyond parameters.
>
> One advantage of Chris's
On Sat, Dec 11, 2021 at 9:43 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-12-10 at 17:24:22 -0500,
> "Eric V. Smith" wrote:
>
> > [0]: Or arguments, I can never remember which is which: someone needs
> > to invent a memorable mnemonic device.
>
> Pass Arguments
> Accept Parameters
>
On Sat, Dec 11, 2021 at 9:26 AM Eric V. Smith wrote:
>
> On 12/9/2021 10:32 AM, Eric V. Smith wrote:
>
> On 12/6/2021 1:24 AM, Christopher Barker wrote:
>
>
>
> But I honestly don’t get it. My idea of a deferred object would be quite
> different that this, would not be a great replacement for
On Sat, Dec 11, 2021 at 7:44 AM deavid wrote:
> When I said earlier in "compile time", I was just trying to refer to the
> parsing step, or pre-parsing step. Or maybe means that "python a.py" => "mypy
> a.py && python a.py".
> I'm being very ambiguous here on purpose because there are tons of
On Thu, Dec 9, 2021 at 8:45 PM Paul Moore wrote:
>
> On Wed, 8 Dec 2021 at 23:40, Chris Angelico wrote:
> >
> > I have attempted to explain the syntax. What is confusing?
> >
> > def f(x=spam): ...
> >
> > def f(x=>spam): ...
>
> Are we using
On Thu, Dec 9, 2021 at 7:07 PM Brendan Barnwell wrote:
>
> On 2021-12-08 23:12, Chris Angelico wrote:
> > On Thu, Dec 9, 2021 at 5:52 PM Brendan Barnwell
> > wrote:
> >> To try stating this in yet another way, currently if I have:
> >>
> >> d
On Thu, Dec 9, 2021 at 6:01 PM Christopher Barker wrote:
>
>
>> My Option 1 (future statement, deprecation of early binding, and permanent
>> switch to late binding): +
>
>
> I have no authority about this at all, and a negligible amount of influence,
> but I’ve been around Python a long time:
On Thu, Dec 9, 2021 at 5:54 PM Brendan Barnwell wrote:
>
> On 2021-12-08 20:36, Chris Angelico wrote:
> > Remember, though: The comparison should be to a function that looks like
> > this:
> >
> > def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
On Thu, Dec 9, 2021 at 5:52 PM Brendan Barnwell wrote:
>
> On 2021-12-08 20:55, Chris Angelico wrote:
> > (H) This is true. But if the two syntaxes can be sufficiently similar,
> > the cost should be low, and the feature benefit would be high. Early
> > binding lets you
On Thu, Dec 9, 2021 at 3:16 PM Rob Cliffe via Python-ideas
wrote:
>
> Objections to PEP 671 - Summary
> There seems to be a problem understanding what the objections to PEP 671 are.
> Chris A wrote:
> "Part of the problem is that it is really REALLY hard to figure out what the
> actual
On Thu, Dec 9, 2021 at 2:22 PM Brendan Barnwell wrote:
> Your example there is very simple. But for me a lot of it comes down
> to this:
>
> def f(a=[], b@={}, c=some_function(a, b), d@=other_function(a, b, c)):
>
> The PEP envisions a world in which you can have a list of
On Thu, Dec 9, 2021 at 2:10 PM David Mertz, Ph.D. wrote:
>
> Easy! Look at EVERY Python function that uses a sentinel. They all get a
> little bit worse under your proposal.
>
> On Wed, Dec 8, 2021, 9:54 PM Chris Angelico
>>
>> > An obvious reason to oppose it
On Thu, Dec 9, 2021 at 3:15 PM Jonathan Goble wrote:
> My preferences to resolve this are, in order:
>
> 1. Introduce `from __future__ import late_default`. When present, argument
> defaults in that file are late bound instead of early bound. After a suitable
> deprecation period, make the
On Thu, Dec 9, 2021 at 1:49 PM David Mertz, Ph.D. wrote:
>
> That's correct Chris!
>
> No matter how much you try to change the topic, I was asked how a general
> deferred concept would be useful and gave an example.
>
I've never denied that it would be useful in general, just that it has
On Thu, Dec 9, 2021 at 12:41 PM MRAB wrote:
>
> On 2021-12-08 23:39, Chris Angelico wrote:
> > On Thu, Dec 9, 2021 at 10:35 AM Paul Moore wrote:
> >>
> >> On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> >> > Part of the problem is that it is re
On Thu, Dec 9, 2021 at 11:47 AM David Mertz, Ph.D.
wrote:
>
> There are tens of concrete examples at the link I gave, and hundreds more you
> can find easily by searching on Dask Delayed. This feels more like trying to
> believe a contrary than seeking understanding.
>
> Here's a concrete
On Thu, Dec 9, 2021 at 10:35 AM Paul Moore wrote:
>
> On Wed, 8 Dec 2021 at 23:18, Chris Angelico wrote:
> > Part of the problem is that it is really REALLY hard to figure out
> > what the actual objections are. I asked, and the one clear answer I
> > got wa
On Thu, Dec 9, 2021 at 10:07 AM Paul Moore wrote:
>
> On Wed, 8 Dec 2021 at 22:53, Chris Angelico wrote:
>
> > Most of that is a *massive* YAGNI as regards function default
> > arguments. We do not need parallel execution just to figure out the
> > length of a list pas
On Thu, Dec 9, 2021 at 9:44 AM David Mertz, Ph.D. wrote:
>
> On Wed, Dec 8, 2021, 2:58 PM Rob Cliffe via Python-ideas
>>
>> On 08/12/2021 19:27, Paul Moore wrote:
>> > The reason deferred objects keep coming up is because they *do* have a
>> > much more compelling benefit - they help in a much
On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
wrote:
> But the "good idea" of general deferreds is only marginally relevant
> to our -1s. It's those -1s that constitute the main issue for Chris,
> since they're a noisy signal that the SC might think as we do.
Please explain to me *exactly*
On Tue, Dec 7, 2021 at 6:16 AM Brendan Barnwell wrote:
>
> On 2021-12-05 08:14, Chris Angelico wrote:
> > Closures cannot be executed without a context. Consider:
> >
> > def f(x=lambda: (a:=[])):
> > if isinstance(x, FunctionType): x = x()
> >
On Tue, Dec 7, 2021 at 1:28 AM Steven D'Aprano wrote:
>
> On Tue, Dec 07, 2021 at 12:53:39AM +1100, Steven D'Aprano wrote:
>
> > If we can't execute the expression without the context existing, we make
> > it exist. Details to follow in another post.
>
> Here is some handwavy pseudo-code for
On Mon, Dec 6, 2021 at 10:04 PM Paul Moore wrote:
> Here's a prototype implementation, and a demonstration of how it would
> be used to implement late bound arguments. Please note, I understand
> that the syntax here is horrible. That's exactly the point, this needs
> language support to be
On Mon, Dec 6, 2021 at 10:02 PM Steven D'Aprano wrote:
> > You assert that it "belongs in the body", but only because Python
> > currently doesn't allow it to be anywhere else. Other languages have
> > this exact information in the function signature.
>
> This argument about where the evaluation
On Mon, Dec 6, 2021 at 5:51 AM David Mertz, Ph.D. wrote:
>
> On Sun, Dec 5, 2021, 1:48 PM Chris Angelico
>>
>> You: "Keep the status quo, all done"
>> Also you: "Let's wait for something better"
>
>
> Now is better than never.
> Although n
On Mon, Dec 6, 2021 at 5:38 AM David Mertz, Ph.D. wrote:
>
> On Sun, Dec 5, 2021, 12:33 PM Chris Angelico
>>
>> And quite frankly, the tone of this list is sounding like "shut up, go away,
>> don't do anything, because there are other proposals that nobody c
On Mon, Dec 6, 2021 at 5:20 AM Christopher Barker wrote:
>
> On Sun, Dec 5, 2021 at 3:28 AM Chris Angelico wrote:
>>
>> (That said, though: it would be rather nice to be able to do algebra
>> with function signatures. For instance, you could say "my signature is
&
On Mon, Dec 6, 2021 at 4:13 AM Steven D'Aprano wrote:
>
> On Mon, Dec 06, 2021 at 02:08:46AM +1100, Chris Angelico wrote:
>
> > I want to have them syntactically as part of the body
> > of the function, and semantically as part of the function call.
>
> Then you'll l
On Mon, Dec 6, 2021 at 2:56 AM Steven D'Aprano wrote:
> > > What sort of "behave differently" do you think would prevent us from
> > > introspecting the function object? "Differently" from what?
> >
> > Wrapping it in a function means the walrus would assign in that
> > function's context, not
On Mon, Dec 6, 2021 at 1:48 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-12-05 at 20:30:53 +1100,
> Chris Angelico wrote:
>
> > On Sun, Dec 5, 2021 at 5:41 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> > > Also FWIW, I still think that
On Mon, Dec 6, 2021 at 1:45 AM Steven D'Aprano wrote:
>
> On Sat, Dec 04, 2021 at 06:11:08PM +, Barry Scott wrote:
>
> > There are many possible implementation of the late bound idea that
> > could create an object/default expression. But is it reasonable to
> > bother with that added
On Sun, Dec 5, 2021 at 9:58 PM Barry Scott wrote:
>> def inner(timestamp=>time.time()):
> >if timestamp is None: timestamp = time.time()
>
>
> And, obviously, if you end up needing the write the explicit check for None
> there is no
> advantage to using late bound default.
Hmm, I wouldn't
On Sun, Dec 5, 2021 at 5:41 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> Also FWIW, I still think that if you're doing (b) or (c), then you're
> *not* doing default values anymore, you're moving pieces of the logic or
> the design into the wrong place. One example of (b) goes something like
>
On Sun, Dec 5, 2021 at 3:39 PM David Mertz, Ph.D. wrote:
>
> On Sat, Dec 4, 2021 at 11:25 PM Chris Angelico wrote:
>>
>> > def add(a, b):
>> > return a+b
>> > How could you write that differently with your PEP
>>
>> I wouldn't. There are no
On Sun, Dec 5, 2021 at 3:17 PM David Mertz, Ph.D. wrote:
>
> On Sat, Dec 4, 2021, 11:13 PM Chris Angelico
>>
>> Not sure I'm understanding you correctly; in what way are named parameters
>> relevant here?
>
>
> def add(a, b):
> return a+b
>
> How
On Sun, Dec 5, 2021 at 3:08 PM Stephen J. Turnbull
wrote:
>
> Barry Scott writes:
>
> > There are many possible implementation of the late bound idea that
> > could create an object/default expression.
> > But is it reasonable to bother with that added
> > complexity/maintenance burden for a
On Sun, Dec 5, 2021 at 3:03 PM David Mertz, Ph.D. wrote:
> Probably fewer than half of functions I've written use named parameters at
> all.
>
Not sure I'm understanding you correctly; in what way are named
parameters relevant here?
ChrisA
___
On Sun, Dec 5, 2021 at 2:14 PM Rob Cliffe via Python-ideas
wrote:
>
> Thank you for doing this research, Steven.
> The designers of 12 languages have chosen to provide late binding; those
> of 3 or 4 have provided early binding.
> I think this is at least tenuous evidence in favour of my belief
On Sun, Dec 5, 2021 at 11:34 AM Steven D'Aprano wrote:
>
> On Sat, Dec 04, 2021 at 10:50:14PM +1100, Chris Angelico wrote:
>
> > > syntactic sugar for this:
> > >
> > > def f(b, x=lambda b: a+b): ...
> > >
> > > except that the lambd
On Sun, Dec 5, 2021 at 5:29 AM Barry Scott wrote:
>
>
>
> > On 1 Dec 2021, at 06:16, Chris Angelico wrote:
> >
> > I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
> > with some additional information about the reference implementation,
>
On Sun, Dec 5, 2021 at 6:16 AM Brendan Barnwell wrote:
>
> On 2021-12-04 03:50, Chris Angelico wrote:
> > On Sat, Dec 4, 2021 at 8:48 PM Steven D'Aprano wrote:
> >> And third, when the interpreter fetches a default from
> >> func.__defaults__, if it is a LB fu
On Sat, Dec 4, 2021 at 8:48 PM Steven D'Aprano wrote:
>
> On Sat, Dec 04, 2021 at 03:14:46PM +1100, Chris Angelico wrote:
>
> > Lots and lots and lots of potential problems. Consider:
> >
> > def f():
> > a = 1
> > def f(b, x=>a+b):
> >
On Sat, Dec 4, 2021 at 2:34 PM Steven D'Aprano wrote:
>
> On Fri, Dec 03, 2021 at 10:40:42AM +1100, Chris Angelico wrote:
>
> > Here's what you get:
> >
> > >>> def f(lst=>[], n=>len(lst)): ...
> > ...
> > >>> f.__defaults_extra__
&g
On Sat, Dec 4, 2021 at 2:52 PM Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 04/12/2021 01:06, Chris Angelico wrote:
> > On Sat, Dec 4, 2021 at 11:59 AM Rob Cliffe via Python-ideas
> > wrote:
> >>
> >>
> >> On 03/12/2021 22:38, Chris Angel
On Sat, Dec 4, 2021 at 11:59 AM Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 03/12/2021 22:38, Chris Angelico wrote:
> > On Sat, Dec 4, 2021 at 8:18 AM Rob Cliffe via Python-ideas
> > wrote:
> >>
> >>
> >> On 03/12/2021 19:32, Ada
On Sat, Dec 4, 2021 at 6:33 AM Adam Johnson wrote:
> > 5) Do you know how to compile CPython from source, and would you be
> > willing to try this out? Please? :)
>
> I have.
>
> The first unwelcome surprise was:
>
> >>> def func(a=>[]):
> ... return a
> ...
>
> >>> import
On Sat, Dec 4, 2021 at 8:18 AM Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 03/12/2021 19:32, Adam Johnson wrote:
> >
> > The first unwelcome surprise was:
> >
> > >>> def func(a=>[]):
> > ... return a
> > ...
> >
> > >>> import inspect
> > >>>
On Sat, Dec 4, 2021 at 4:48 AM Eric V. Smith wrote:
>
> On 12/2/2021 6:36 PM, Chris Angelico wrote:
> > On Fri, Dec 3, 2021 at 7:54 AM Eric V. Smith wrote:
> >>
> >> Say I have a function with an early-bound default. I can inspect it and
> >> I can ch
On Sat, Dec 4, 2021 at 3:47 AM Andrew Jaffe wrote:
> b) I think another motivation that hasn't been highlighted is teaching
> -- perhaps surprisingly, I think adding this will make some aspects of
> teaching *easier*. Mutable defaults are known to be confusing to Python
> neophytes; I have
On Fri, Dec 3, 2021 at 3:47 PM Abe Dillon wrote:
> This seems like an exceedingly minor complaint. The obvious answer is: you
> invoke the default behaviour by not passing the argument. And yes, I know
> that's less explicit, but that's kinda the whole point of defaults to begin
> with. It's
On Fri, Dec 3, 2021 at 2:30 PM Brendan Barnwell wrote:
>
> On 2021-12-02 15:40, Chris Angelico wrote:
> > Actually, no. I want to put the default arguments into the signature,
> > and the body in the body. The distinction currently has a technical
> > restriction tha
On Fri, Dec 3, 2021 at 2:24 PM Steven D'Aprano wrote:
>
> On Fri, Dec 03, 2021 at 01:08:50PM +1100, Chris Angelico wrote:
>
> > How, with external calling, are you going to know which name
> > references to look up, and where to get their values from?
>
> Isn'
On Fri, Dec 3, 2021 at 2:27 PM Steven D'Aprano wrote:
>
> On Fri, Dec 03, 2021 at 10:36:55AM +1100, Chris Angelico wrote:
>
> > Same again. If you consider the equivalent to be a line of code in the
> > function body, then the signature has become MASSIVELY more useful.
On Fri, Dec 3, 2021 at 12:48 PM Steven D'Aprano wrote:
>
> On Fri, Dec 03, 2021 at 02:10:12AM +1100, Chris Angelico wrote:
>
> > > > Unfortunately not, since the default expression could refer to other
> > > > parameters, or closure variables,
On Fri, Dec 3, 2021 at 9:26 AM Brendan Barnwell wrote:
>
> On 2021-12-02 00:31, Chris Angelico wrote:
> > Here's how a ternary if looks:
> >
> >>>> >>>def f(n):
> > ... return 0 if n == 0 else 42/n
> > ...
> >>>
On Fri, Dec 3, 2021 at 8:07 AM David Mertz, Ph.D. wrote:
>
> On Thu, Dec 2, 2021 at 2:40 PM Chris Angelico wrote:
>>
>> How is a late-bound default different from half of a conditional expression?
>
>
>>
>> def f(lst=>[], n=>len(lst)):
>>
>
On Fri, Dec 3, 2021 at 7:54 AM Eric V. Smith wrote:
>
> On 12/2/2021 2:21 PM, Brendan Barnwell wrote:
> > On 2021-12-02 01:35, Steven D'Aprano wrote:
> > >4) If "no" to question 1, is there some other spelling or other
> small
> > >change that WOULD mean you would use it? (Some
On Fri, Dec 3, 2021 at 6:50 AM Oscar Benjamin
wrote:
>
> On Thu, 2 Dec 2021 at 17:28, Chris Angelico wrote:
> >
> > On Fri, Dec 3, 2021 at 4:22 AM Nicholas Cole
> > wrote:
> > > There is nothing that this proposal makes possible that is not already
>
On Fri, Dec 3, 2021 at 6:24 AM Brendan Barnwell wrote:
> What I'm saying is that I want that "thing" to exist. At the time the
> function is defined, I want there to be a Python object which represents
> the behavior to be activated at call time if the argument is not passed.
> In the
On Fri, Dec 3, 2021 at 4:22 AM Nicholas Cole wrote:
> There is nothing that this proposal makes possible that is not already
> possible with more explicit code.
It's worth noting that "explicit" does not mean "verbose". For
instance, this is completely explicit about what it does:
x += 1
It
401 - 500 of 2585 matches
Mail list logo
