On Mon, Oct 25, 2021 at 05:23:38AM +1100, Chris Angelico wrote:
> On Mon, Oct 25, 2021 at 4:29 AM Erik Demaine wrote:
> >
> > On Sun, 24 Oct 2021, Erik Demaine wrote:
> >
> > > I think the semantics are easy to specify: the argument defaults get
> > > evaluated for unspecified order, in left to ri
On Mon, Oct 25, 2021 at 6:13 PM Steven D'Aprano wrote:
>
> On Mon, Oct 25, 2021 at 05:23:38AM +1100, Chris Angelico wrote:
> > On Mon, Oct 25, 2021 at 4:29 AM Erik Demaine wrote:
> > >
> > > On Sun, 24 Oct 2021, Erik Demaine wrote:
> > >
> > > > I think the semantics are easy to specify: the argu
I DO expect this thread to be bombarded with negative replies.
Currently, there are `in`/`not in` operators which work like this in Python:
> def contains(contains_value, iterable, not_in):
> for element in iterable:
> if element == contains_value:
> return True ^ not_in
>
> On 24 Oct 2021, at 01:13, Chris Angelico wrote:
>
> Specification
> =
>
> Function default arguments can be defined using the new ``=>`` notation::
>
>def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
>def connect(timeout=>default_timeout):
>def add_item(item, t
On Mon, Oct 25, 2021 at 7:40 PM Jeremiah Vivian
wrote:
>
> I DO expect this thread to be bombarded with negative replies.
>
> Currently, there are `in`/`not in` operators which work like this in Python:
> > def contains(contains_value, iterable, not_in):
> > for element in iterable:
> >
On Mon, Oct 25, 2021 at 7:51 PM Barry Scott wrote:
>
> Clarification please:
>
> What is the bytecode that will be generated?
Equivalent to:
if argument not provided:
argument =
except that we don't have a way of saying "not provided".
> Does the bytecode only run the default code if the
Something like this:
> \>\>\> class Movement:
> ... def __eq__(self, x):
> ... return type(x) is Movement
> ...
> \>\>\> dummy = Movement()
> \>\>\> # suppose `bar` is a list of every recorded action in a game
> \>\>\> if dummy in bar:
> ... if dummy is in bar: # check if the dummy
On Mon, Oct 25, 2021 at 8:09 PM Jeremiah Vivian
wrote:
>
> Something like this:
> > \>\>\> class Movement:
> > ... def __eq__(self, x):
> > ... return type(x) is Movement
> > ...
Uhh, why are you defining equality in this bizarre way? Every Movement
is equal to every other?
ChrisA
__
For quick checking if a `Movement` object is inside of an iterable.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Mess
On Mon, Oct 25, 2021 at 08:39:19AM -, Jeremiah Vivian wrote:
> If I wanted to check if an *exact* object is in an iterable
A nice way to check for exact identity in an iterable is this:
any(value is element for element in iterable)
That stops on the first match, and is pretty efficient.
I don’t like the => syntax for delayed default argument. It looks like a lambda
and it’s confusing. The @ symbol is more readable. Like this @var=len(a) or
even var@=len(a). The function decorator changes the behavior of the function.
Similarly this @ default argument will change the argument va
It should make sense that if an operation is grammatically correct in a
programming language, there's something wrong there. There could be alternative
syntax,
> 'is `object` in `iterable`'
or
> 'is `object` not in `iterable`'
but I feel like there's some disadvantage to this alternative syntax.
*It should be obvious
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archi
On Mon, Oct 25, 2021 at 8:35 PM Steven D'Aprano wrote:
>
> Otherwise, it would silently do the wrong thing. And then the coder who
> accidentally inserts an unneeded `is` into the test will have to deal
> with weird implementation-dependent silent failures due to caching of
> small ints and string
> It's worth noting that "in" is defined by the container. Object
> identity and equality aren't actually part of the definition. A lot of
> containers will behave as the OP describes, but strings, notably, do
> not - if you iterate over "caterpillar", you will never see "cat", yet
> it is most def
On Mon, Oct 25, 2021 at 9:33 PM Jeremiah Vivian
wrote:
>
> > It's worth noting that "in" is defined by the container. Object
> > identity and equality aren't actually part of the definition. A lot of
> > containers will behave as the OP describes, but strings, notably, do
> > not - if you iterate
On 24.10.2021 02:13, Chris Angelico wrote:
> How to Teach This
> =
>
> Early-bound default arguments should always be taught first, as they are the
> simpler and more efficient way to evaluate arguments. Building on them, late
> bound arguments are broadly equivalent to code at the
On Mon, Oct 25, 2021 at 10:39 PM Marc-Andre Lemburg wrote:
> I would prefer to not go down this path.
>
> "Explicit is better than implicit" and this is too much "implicit"
> for my taste :-)
>
> For simple use cases, this may save a few lines of code, but as soon
> as you end up having to think w
On 25.10.2021 13:53, Chris Angelico wrote:
> On Mon, Oct 25, 2021 at 10:39 PM Marc-Andre Lemburg wrote:
>> I would prefer to not go down this path.
>>
>> "Explicit is better than implicit" and this is too much "implicit"
>> for my taste :-)
>>
>> For simple use cases, this may save a few lines of
On Mon, Oct 25, 2021 at 11:20 PM Marc-Andre Lemburg wrote:
>
> On 25.10.2021 13:53, Chris Angelico wrote:
> > On Mon, Oct 25, 2021 at 10:39 PM Marc-Andre Lemburg wrote:
> >> I would prefer to not go down this path.
> >>
> >> "Explicit is better than implicit" and this is too much "implicit"
> >>
While I love this idea, and I think this PEP is bound for glory, I don't
love any of the proposed spellings for denoting late-binding arguments. It
seems to me that a specialized symbol combination indicating that a
particular argument has special behavior does not serve readability,
regardless of
On Mon, Oct 25, 2021 at 11:41 PM Jon Kiparsky wrote:
> I would prefer to build on the fact that arguments already come in two
> flavors with somewhat different behaviors, and that the ordering of these is
> determined. Going by this analogy, it would make sense to have late-binding
> arguments
On 25.10.2021 14:26, Chris Angelico wrote:
> On Mon, Oct 25, 2021 at 11:20 PM Marc-Andre Lemburg wrote:
>>
>> On 25.10.2021 13:53, Chris Angelico wrote:
>>> On Mon, Oct 25, 2021 at 10:39 PM Marc-Andre Lemburg wrote:
I would prefer to not go down this path.
"Explicit is better than
On Mon, Oct 25, 2021 at 11:53 PM Marc-Andre Lemburg wrote:
>
> On 25.10.2021 14:26, Chris Angelico wrote:
> > On Mon, Oct 25, 2021 at 11:20 PM Marc-Andre Lemburg wrote:
> >>
> >> On 25.10.2021 13:53, Chris Angelico wrote:
> >>> On Mon, Oct 25, 2021 at 10:39 PM Marc-Andre Lemburg
> >>> wrote:
>
> On 25 Oct 2021, at 08:08, Steven D'Aprano wrote:
>
> I would say that it makes most sense to assign early-bound defaults
> first, then late-bound defaults, specifically so that late-bound
> defaults can refer to early-bound ones:
>
>def func(x=0, @y=x+1)
>
> So step 3 above should bec
On 10/25/2021 8:26 AM, Chris Angelico wrote:
If it's done with syntax, it can have special behaviour. If it looks
like a function call (or class constructor), it doesn't look like it
has special behaviour.
This has been mentioned before, but I'll say it again: It doesn't need
to be syntax in
Thanks. Not as catchy as I would have hoped, though. ;-)
One person except me in favor of this idea.
Any other feedback? How to proceed?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
On 10/25/2021 11:21 AM, Tom Pohl wrote:
Thanks. Not as catchy as I would have hoped, though. ;-)
When you respond to a message, could you keep a little of the context
that you're replying to? I'm not sure what this refers to.
One person except me in favor of this idea.
Any other feedback? How t
Now if do something like `[] in set()` python raise an exception, but if an
object isn't hashable then we know for sure that it isn't in the set. Propose
return False for these cases. What do you think?
___
Python-ideas mailing list -- python-ideas@pyth
Tom Pohl wrote:
> A question for the Python experts: What is the correct technical term for a
> functionality like "http.server", i.e., a module with an actual "main"
> function?
There's some details about it here
https://docs.python.org/3/library/__main__.html#idiomatic-usage
_
25.10.21 18:49, Kazantcev Andrey пише:
> Now if do something like `[] in set()` python raise an exception, but if an
> object isn't hashable then we know for sure that it isn't in the set. Propose
> return False for these cases. What do you think?
What was changed since this topic was discussed
On Mon, 25 Oct 2021, Chris Angelico wrote:
On Mon, Oct 25, 2021 at 6:13 PM Steven D'Aprano wrote:
The rules for applying parameter defaults are well-defined. I would have
to look it up to be sure...
And that right there is all the evidence I need. If you, an
experienced Python programmer, c
On Tue, Oct 26, 2021 at 3:32 AM Erik Demaine wrote:
> As Jonathan Fine mentioned, if you defined the order to be a linearization of
> the partial order on arguments, (a) this would be complicated and (b) it would
> be ambiguous. I think, if you're going to forbid `def f(a := b, b:= a)` at
> the c
On Mon, Oct 25, 2021 at 10:28 AM Chris Angelico wrote:
> [...] The two options on the table are:
>
> 1) Allow references to any value that has been provided in any way
> 2) Allow references only to parameters to the left
>
> Option 2 is a simple SyntaxError on compilation (you won't even get as
>
On 10/23/21 8:04 PM, Bruce Leban wrote:
> I was talking about (2) but I should have been explicit. And yes, you
highlight a potential source of confusion.
>
> def f(x=>x + 1): ...
>
> means that x is 1 more than the value of x from the enclosing global scope
(at function call time) while
Uh, n
> Option 2 is a simple SyntaxError on compilation (you won't even get as
>> far as the def statement). Option 1 allows everything all up to the
>> point where you call it, but then might raise UnboundLocalError if you
>> refer to something that wasn't passed.
>>
>
> Note that if you were to choose
On 10/24/21 11:22 PM, Steven D'Aprano wrote:
> On Sun, Oct 24, 2021 at 05:40:55PM +0100, Jonathan Fine wrote:
>> def puzzle(*, a=>b+1, b=>a+1):
>> return a, b
> We can consider that to be syntactic sugar for:
>
> def puzzle(*, a=None, b=None):
> if a is None:
>
On Tue, Oct 26, 2021 at 4:36 AM Guido van Rossum wrote:
>
> On Mon, Oct 25, 2021 at 10:28 AM Chris Angelico wrote:
>>
>> [...] The two options on the table are:
>>
>> 1) Allow references to any value that has been provided in any way
>> 2) Allow references only to parameters to the left
>>
>> Opt
There are other options. Maybe you can't combine early and late binding
defaults in the same signature. Or maybe all early binding defaults must
precede all late binding defaults.
FWIW have you started an implementation yet? "If the implementation is easy
to explain, ..."
On Mon, Oct 25, 2021 at
On Tue, Oct 26, 2021 at 4:54 AM Guido van Rossum wrote:
>
> There are other options. Maybe you can't combine early and late binding
> defaults in the same signature. Or maybe all early binding defaults must
> precede all late binding defaults.
>
All early must precede all late would make a dece
On Mon, Oct 25, 2021, 8:20 AM Marc-Andre Lemburg
> If I instead write:
>
> def process_files(processor, files=deferred(os.listdir(DEFAULT_DIR))):
>
> it is pretty clear that something is happening at a different time than
> function definition time :-)
>
> Even better: the deferred() object can be
On 10/25/21 6:54 AM, Eric V. Smith wrote:
> On 10/25/2021 8:26 AM, Chris Angelico wrote:
>> If it's done with syntax, it can have special behaviour. If it looks
>> like a function call (or class constructor), it doesn't look like it
>> has special behaviour.
>
> This has been mentioned before, bu
Hi Chris,
I feel like we're pretty close to agreement. :-) The only difference is that
I still lean toward allowing one of the two left-to-right options, and not
trying to raise SyntaxErrors. I feel like detecting this kind of bad code
belongs more with a linter than the programming language
On 10/25/21 11:50 AM, Erik Demaine wrote:
> Here's another example where it matters whether the default expressions are
computed within their own scope:
>
> ```
> def f(x := (y := 5)):
> print(x) # 5
> print(y) # 5???
> f()
> ```
That should definitely be a SyntaxError.
--
~Ethan~
On Tue, Oct 26, 2021 at 5:50 AM Erik Demaine wrote:
> But you're definitely right that it's easier to give permissions later than
> take them away, and there are two natural left-to-right orders...
>
> Speaking of implementation as Guido just raised, maybe going with what makes
> the most sense in
On 2021-10-25 11:27, Ethan Furman wrote:
- `deferred` soft keyword
"defer" please.
This construct did not happen in the past, and it's shorter of course.
-Mike
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an emai
On 2021-10-23 17:13, Chris Angelico wrote:
def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
Sounds like deferred execution could be useful, but I wanted to complain about
the example above. I realize it is "just an example" but if I saw this in code,
the first thing I'd do is a
On Mon, Oct 25, 2021 at 3:42 PM Mike Miller
wrote:
>
> On 2021-10-25 11:27, Ethan Furman wrote:
> > - `deferred` soft keyword
>
>
> "defer" please.
>
> This construct did not happen in the past, and it's shorter of course.
>
> -Mike
>
For soft keyword options, defer is better than deferred.
But
I've been thinking for a while that it would be good to be able to use context
managers in an expression context, and I haven't been able to come up with any
arguments against it (although it may not be to everyone's taste) and I can't
see any sign that it's come up before (although the words of
Due to https://www.python.org/dev/peps/pep-0554/ multi-interpreters
implementation going really slow, I had the audicity to try an alternative route
towards the same objective of implementing multicore support of python:
instead of sharing the memory by running multiple threads, I employed
an inter
What should happen if the context manager attempts to suppress a raised
exception? In cases where you applied the context manager to an entire line,
e.g.
data = fail() with contextlib.suppress(Exception)
Then it would make sense to treat it like
with contextlib.suppress(Exception):
data =
On Tue, Oct 26, 2021 at 6:46 AM Mike Miller wrote:
>
>
> On 2021-10-23 17:13, Chris Angelico wrote:
> > def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
>
>
> Sounds like deferred execution could be useful, but I wanted to complain about
> the example above. I realize it is "just an ex
On Mon, Oct 25, 2021 at 07:17:18PM +0300, Serhiy Storchaka wrote:
> 25.10.21 18:49, Kazantcev Andrey пише:
> > Now if do something like `[] in set()` python raise an exception,
> > but if an object isn't hashable then we know for sure that it isn't
> > in the set. Propose return False for these
On Sun, Oct 24, 2021 at 07:40:26PM -0400, Jon Kiparsky wrote:
> I would prefer to build on the fact that arguments already come in two
> flavors with somewhat different behaviors,
Three.
- Positional only.
- Positional-or-keyword.
- Keyword only.
plus two somewhat special `*args` and `**kwargs`
On Mon, Oct 25, 2021 at 12:45:03PM -0700, Mike Miller wrote:
>
> On 2021-10-23 17:13, Chris Angelico wrote:
> > def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
>
>
> Sounds like deferred execution could be useful, but I wanted to complain
> about the example above. I realize it is "
On 2021-10-25 3:31 p.m., Mike Miller wrote:
> "defer" please.
>
> This construct did not happen in the past, and it's shorter of course.
>
> -Mike
>
I also like `defer`:
> def range(a, min=0, max = defer len(a)):
> return a[min:max]
`default` is also nice:
> def range(a, min=
On Tue, Oct 26, 2021 at 10:20 AM Kyle Lahnakoski wrote:
> I was concerned with this proposal at first because an inner function
> definition may be ambiguous:
>
> > def do_work():
> > a = ['this', 'is', 'a', 'list']
> > def range(a, min=0, max = defer len(a)):
> > return a[min:
My 2¢ (perhaps it should be 3¢ as I've already contributed 2¢). Chris A
did ask/
"do Python core devs agree with less-skilled Python programmers on the
intuitions?"/
so putting myself firmly in the second camp (though I have been using
Python for over a decade) here are my thoughts in case they
On Tue, Oct 26, 2021 at 11:44 AM Rob Cliffe via Python-ideas
wrote:
> I prefer 1). Easier to understand and debug in examples with side-effects
> such as
> def f(a := enter_codes(), b = assign_targets(), c := unlock_missiles(), d
> = FIRE()):
> (not that this is something to be particularly
On 2021-10-26 at 12:12:47 +1100,
Chris Angelico wrote:
> On Tue, Oct 26, 2021 at 11:44 AM Rob Cliffe via Python-ideas
> wrote:
> > I prefer 1). Easier to understand and debug in examples with side-effects
> > such as
> > def f(a := enter_codes(), b = assign_targets(), c := unlock_missiles(
On Tue, Oct 26, 2021 at 12:40 PM <[email protected]> wrote:
>
> On 2021-10-26 at 12:12:47 +1100,
> Chris Angelico wrote:
>
> > On Tue, Oct 26, 2021 at 11:44 AM Rob Cliffe via Python-ideas
> > wrote:
> > > I prefer 1). Easier to understand and debug in examples with
> > > side-e
On Sat, 16 Oct 2021, Erik Demaine wrote:
Assuming the support remains relatively unanimous for [*...], {*...}, and
{**...} (thanks for all the quick replies!), I'll put together a PEP.
As promised, I put together a pre-PEP (together with my friend and coteacher
Adam Hartz, not currently subsc
On Tue, Oct 26, 2021 at 01:32:58AM +0100, Rob Cliffe via Python-ideas wrote:
> Syntax bikeshedding: I still favour
> var := expr
That clashes with the walrus operator. Remember that the walrus operator
can appear inside the expression:
var:=spam+eggs:=(something+other) or eggs
Modifyin
On Tue, Oct 26, 2021 at 12:56:06PM +1100, Steven D'Aprano wrote:
> Have some faith that coders aren't idiots. There are genuinely confusing
> features that are *inherently* complicated and complex, like threading,
> asynchronous code, metaclasses, the descriptor class, and we cope.
Sorry, that
I like this. I think explicitly discussing order of inclusion would be
worthwhile. I know it's implied by the approximate equivalents, but
actually stating it would improve the PEP, IMO.
For example:
nums = [(1, 2, 3), (1.0, 2.0, 3.0)]
nset = {*n for n in nums}
Does 'nset' wind up containing int
On 2021-10-26 at 12:51:43 +1100,
Chris Angelico wrote:
> On Tue, Oct 26, 2021 at 12:40 PM <[email protected]> wrote:
> >
> > On 2021-10-26 at 12:12:47 +1100,
> > Chris Angelico wrote:
> > > The difference between early evaluation and late evaluation is that
> > > one retains th
On Tue, Oct 26, 2021 at 1:20 PM <[email protected]> wrote:
>
> On 2021-10-26 at 12:51:43 +1100,
> Chris Angelico wrote:
>
> > On Tue, Oct 26, 2021 at 12:40 PM <[email protected]> wrote:
> > >
> > > On 2021-10-26 at 12:12:47 +1100,
> > > Chris Angelico wrote:
>
>
On Tue, Oct 26, 2021 at 1:10 PM David Mertz, Ph.D.
wrote:
>
> I like this. I think explicitly discussing order of inclusion would be
> worthwhile. I know it's implied by the approximate equivalents, but actually
> stating it would improve the PEP, IMO.
>
> For example:
>
> nums = [(1, 2, 3), (1.
I do get what it does, but the phrase in the PEP feels like there is wiggle
room: "The new notation listed above is effectively short-hand for the
following existing notation."
"Effectively" doesn't quite feel the same as "guaranteed exactly
equivalent."
On Mon, Oct 25, 2021, 10:22 PM Chris Ange
On Tue, Oct 26, 2021 at 04:48:17AM +1100, Chris Angelico wrote:
> The problem is the bizarre inconsistencies that can come up, which are
> difficult to explain unless you know exactly how everything is
> implemented internally. What exactly is the difference between these,
> and why should some be
On Mon, Oct 25, 2021 at 02:59:02PM +0100, Barry Scott wrote:
> def func(@y=x+1, @x=0):
>
> Is it unreasonable to get a UnboundLocal or SyntaxError for this case?
I think that UnboundLocalError is fine, if the caller doesn't supply x.
So all of these cases will succeed:
func(21, 20)
On 2021-10-24 11:23, Chris Angelico wrote:
Ah, but is it ALL argument defaults, or only those that are
late-evaluated? Either way, it's going to be inconsistent with itself
and harder to explain. That's what led me to change my mind.
I don't understand what this means. The ones that are early
Thanks for the nudge.
If anyone is interested (or could approve to make the pipeline run), here's the
PR: https://github.com/python/cpython/pull/29217
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-
On Tue, Oct 26, 2021 at 3:00 PM Steven D'Aprano wrote:
>
> On Tue, Oct 26, 2021 at 04:48:17AM +1100, Chris Angelico wrote:
>
> > The problem is the bizarre inconsistencies that can come up, which are
> > difficult to explain unless you know exactly how everything is
> > implemented internally. Wha
On 26/10/2021 02:12, Chris Angelico wrote:
On Tue, Oct 26, 2021 at 11:44 AM Rob Cliffe via Python-ideas
wrote:
I prefer 1). Easier to understand and debug in examples with side-effects such
as
def f(a := enter_codes(), b = assign_targets(), c := unlock_missiles(), d
= FIRE()):
(not th
75 matches
Mail list logo
