Re: [Python-ideas] for/except/else

On 3/1/17, Wolfgang Maier wrote: > - as explained by Nick, the existence of "except break" would strengthen > the analogy with try/except/else and help people understand what the > existing else clause after a loop is good for. I was thinking bout this

Re: [Python-ideas] Optional parameters without default value

On Thu, Mar 2, 2017 at 9:13 PM, Mike Miller wrote: > > It is a built-in singleton so rarely known that you will almost never > encounter code with it, so you'll have it all to yourself. Even on a python > mailing list, in a thread about sentinels/singletons, it will

Re: [Python-ideas] Optional parameters without default value

Agreed, I've rarely found a need for a "second None" or sentinel either, but once every few years I do. So, this use case doesn't seem to be common enough to devote special syntax or a keyword to from my perspective. But, I'll let you know my secret. I don't make my own sentinel, but rather

Re: [Python-ideas] Delayed Execution via Keyword

Another problem I thought of was how this might complicate stack tracebacks. If you execute the following code: [1] a = ["hello", 1] [2] b = "1" + 1 [3] a = "".join(a) [4] print(a) The interpreter would build a graph until it hit line 4 and was forced to evaluate `a`. It would track `a` back to

Re: [Python-ideas] Delayed Execution via Keyword

> > without special casing iteration how do you know that `x1 = next(xs)` > depends on the value of `x0`? `x1 = next(xs)` doesn't depend on the value of `x0`, it depends on the state of xs. In order to evaluate `next(xs)` you have to jump into the function call and evaluate the relevant

Re: [Python-ideas] Delayed Execution via Keyword

without special casing iteration how do you know that `x1 = next(xs)` depends on the value of `x0`? If you assume every operation depends on every other operation then you have implemented an eager evaluation model. On Thu, Mar 2, 2017 at 8:26 PM, Abe Dillon wrote: > I

Re: [Python-ideas] Delayed Execution via Keyword

I don't think you have to make a special case for iteration. When the interpreter hits: >>> print(x1) print falls under I/O, so it forces evaluation of x1, so we back-track to where x1 is evaluated: >>> x1 = next(xs) And in the next call, we find that we must evaluate the state of the iterator,

Re: [Python-ideas] Positional-only parameters

I am thinking at writing a PEP, yes. I need time to think about it, find all corner cases. Maybe also include something for "optional parameter without default value". Don't expect it soon, I have some pending work to finish before :-) Victor Le 2 mars 2017 7:16 PM, "Brett Cannon"

Re: [Python-ideas] Optional parameters without default value

In my code, I commonly use a NOT_SET singleton used as default value. I like this name for the test: if arg is NOT_SET: ... ;-) I use that when I want to behave differently when None is passed. And yes, I have such code. Victor Le 2 mars 2017 9:36 AM, "M.-A. Lemburg" a écrit

Re: [Python-ideas] Delayed Execution via Keyword

Other things that scrutinize an expression are iteration or branching (with the current evaluation model). If `xs` is a thunk, then `for x in xs` must scrutinize `xs`. At first this doesn't seem required; however, in general `next` imposes a data dependency on the next call to `next`. For example:

Re: [Python-ideas] lazy use for optional import

On Fri, Mar 3, 2017 at 10:10 AM, Abe Dillon wrote: > I really think the whole "lazy" idea is misguided. If it's possible for the > interpreter to determine automatically when it needs to force evaluation of > a lazy expression or statement, then why not make *all* expressions

Re: [Python-ideas] Optional parameters without default value

On Mar 02, 2017, at 06:37 PM, Brett Cannon wrote: >So to me, there's actually two things being discussed. Do we need another >sentinel to handle the "None is valid" case, and do we want syntax to more >clearly delineate optional arguments? No, and no (IMHO). -Barry pgpULmSfZJDcd.pgp

Re: [Python-ideas] Optional parameters without default value

I honestly don't understand the reasoning behind using anything more complex than a built-in sentinel value. Just plop "NotGiven" or whatever in the built-ins and say "it's like None, but for the specific case of optional parameters with no default value". Why prohibit people from passing it to

Re: [Python-ideas] lazy use for optional import

I really think the whole "lazy" idea is misguided. If it's possible for the interpreter to determine automatically when it needs to force evaluation of a lazy expression or statement, then why not make *all* expressions and statements lazy by default? I think it's pretty clear when to force

Re: [Python-ideas] Optional parameters without default value

On 2017-03-02 08:03, Serhiy Storchaka wrote: Function implemented in Python can have optional parameters with default value. It also can accept arbitrary number of positional and keyword arguments if use var-positional or var-keyword parameters (*args and **kwargs). But there is no way to

Re: [Python-ideas] for/except/else

On 1 March 2017 at 06:37, Wolfgang Maier wrote: > Now here's the proposal: allow an except (or except break) clause to follow > for/while loops that will be executed if the loop was terminated by a break > statement. After rethinking over some code I've

Re: [Python-ideas] Positional-only parameters

It seems all the core devs who have commented on this are in the positive (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't explicitly vote). So to me that suggests there's enough support to warrant writing a PEP. Are you up for writing it, Victor, or is someone else going to write

Re: [Python-ideas] Optional parameters without default value

On Thu, 2 Mar 2017 at 08:58 Ethan Furman wrote: > On 03/02/2017 08:13 AM, Joao S. O. Bueno wrote: > > > Is it just me that find that having the un-assigned parameter raise > > NameError (or other exception) much more cumbersome than > > havign a sentinel-value? > > No. While

Re: [Python-ideas] add __contains__ into the "type" object

-1. It is already possible to specify what inst in cls means by using a metaclass. For example: class Color(enum.Enum): RED = 1 GREEN = 2 BLUE = 3 some_var = Color.GREEN some_var in Color # True some_var in enum.Enum # False Containment != isinstance() --

Re: [Python-ideas] Optional parameters without default value

Is it just me that find that having the un-assigned parameter raise NameError (or other exception) much more cumbersome than havign a sentinel-value? I definitely don't find it clever - for one, a common default parameter - sentinel or not, can be replaced in a single line of code by an

Re: [Python-ideas] Positional-only parameters

2017-03-02 14:23 GMT+01:00 Steven D'Aprano : >> Replace "replace(self, old, new, count=-1, /)" with "replace(self, >> old, new[, count=-1])" (or maybe even not document the default >> value?). > > That isn't right. It would have to be: > > replace([self, old, new, count=-1]) >

Re: [Python-ideas] Positional-only parameters

2017-03-01 21:52 GMT+01:00 Terry Reedy : > + 1 also. When people write a Python equivalent of a built-in function for > documentation or teaching purposes, they should be able to exactly mimic the > API. Yeah, Serhiy said basically the same thing: it's doable, but complex

Re: [Python-ideas] Optional parameters without default value

On 02.03.2017 14:08, Serhiy Storchaka wrote: > On 02.03.17 12:04, M.-A. Lemburg wrote: >> This is not new syntax, nor is it a keyword. It's only a >> new singleton and it is well usable outside of function >> declarations as well, e.g. for class attributes which are >> not yet initialized (and

Re: [Python-ideas] add __contains__ into the "type" object

By itself, I don't see using the ``in`` syntax to check for ``instanceof`` as a big benefit, given the overhead of learning that new concept. However, given in the light of a bigger concept, I think it may make more sense. If we accept that it may be desirable to work with types as set-like

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 14:24, Steven D'Aprano wrote: > I like this! If the caller doesn't provide a value, the parameter > remains unbound and any attempt to look it up will give a NameError or > UnboundLocalError. Hmm. But those exceptions currently indicate with almost 100%

Re: [Python-ideas] Optional parameters without default value

So let's turn the question around: Since Coverity is user-extensible (and supports Python), can you write a Coverity rule which detects wrong use of some given NoDefault sentinel with a useful level of reliability? Actually I feel this should be feasible. (And if so, mission accomplished?)

Re: [Python-ideas] Optional parameters without default value

On Thu, Mar 02, 2017 at 10:03:29AM +0200, Serhiy Storchaka wrote: > I propose to add a new syntax for optional parameters. If the argument > corresponding to the optional parameter without default value is not > specified, the parameter takes no value. As well as the "*" prefix means >

Re: [Python-ideas] Optional parameters without default value

On Fri, Mar 3, 2017 at 1:15 AM, Stephan Houben wrote: > I do not think such a magic linter can be written. > It seems an obvious instance of the Halting Problem to me. Yeah it can :) Static analysis is pretty impressive these days. Check out tools like Coverity, which can

Re: [Python-ideas] Optional parameters without default value

On Thu, Mar 02, 2017 at 01:08:42PM +0100, M.-A. Lemburg wrote: > Sorry for the confusion. NoDefault would be usable just like > any other singleton. But that is exactly the trouble! We already have a singleton to indicate "no default" -- that is spelled None. Occasionally, we need to allow

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 13:11, Serhiy Storchaka wrote: > On 02.03.17 14:20, Paul Moore wrote: >> >> So I guess I'm +0.5 on the proposed "positional only parameters" >> syntax, and -1 on any form of new language-defined sentinel value. > > > My proposition is not about

Re: [Python-ideas] add __contains__ into the "type" object

On Fri, Mar 3, 2017 at 12:44 AM, Steven D'Aprano wrote: > Compare to the OP's suggestion: > > 23 in int > > This doesn't even make sense unless you have been exposed to a very > small subset of theoretical computer science which treats classes as > sets and instances as

Re: [Python-ideas] add __contains__ into the "type" object

On Thu, Mar 02, 2017 at 04:23:08AM +0100, Jürgen A. Erhard wrote: > > The OP seems to be proposing that we reflect this identity between > > types and sets in Python by spelling "isinstance(obj, T)" as "obj in > > T" and "issubclass(S, T)" as "S <= T". This proposal has some solid > > theory

Re: [Python-ideas] Positional-only parameters

On Tue, Feb 28, 2017 at 10:17:31PM +0100, Victor Stinner wrote: > My question is: would it make sense to implement this feature [positional only parameters] > in Python directly? +0 on positional-only parameters. > If yes, what should be the syntax? Use "/" marker? I think that / makes a

Re: [Python-ideas] Optional parameters without default value

On 02.03.17 14:20, Paul Moore wrote: So I guess I'm +0.5 on the proposed "positional only parameters" syntax, and -1 on any form of new language-defined sentinel value. My proposition is not about "positional-only parameters". ___ Python-ideas

Re: [Python-ideas] get() method for list and tuples

On Wed, Mar 01, 2017 at 02:56:44AM +0100, Michel Desmoulin wrote: > > first_item = (alist[0:1] or ["ham"])[0] > > Come on, I've been doing Python for more than a decade and never saw > anybody doing that. Even reading it in a code would make me scratch my > head for a moment with a "what is it

Re: [Python-ideas] add __contains__ into the "type" object

> On 2017 Mar 2 , at 2:53 a, Stephan Houben wrote: > > A crucial difference between a set and a type is that you cannot > explicitly iterate over the elements of a type, so while we could implement > > x in int > > to do something useful, we cannot make > > for x in

Re: [Python-ideas] Optional parameters without default value

On Thu, Mar 2, 2017 at 11:22 PM, Stephan Houben wrote: > Would this also apply if we provide or capture the keyword arguments using > ** ? > > I.e. > f(**{"x": NoDict}) > > (lambda **kw: kw)(x=NoDict) > > In that case I see a problem with this idiom: > > newdict =

Re: [Python-ideas] Optional parameters without default value

On 02.03.2017 13:22, Stephan Houben wrote: > OK, I get it, I think. > > I presume it is really the object identity which matters, not the syntax, > so: > > y = NoDefault > f(x=y) > > would be equally an error. Yes. > Would this also apply if we provide or capture the keyword arguments using >

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 13:20, Paul Moore wrote: > On 2 March 2017 at 11:31, Stephan Houben wrote: > > NoDefault would be special syntax so that this would be disallowed: > > > > f(NoDefault) > > [...] > > So I guess I'm +0.5 on the proposed "positional

Re: [Python-ideas] Optional parameters without default value

OK, I get it, I think. I presume it is really the object identity which matters, not the syntax, so: y = NoDefault f(x=y) would be equally an error. Would this also apply if we provide or capture the keyword arguments using ** ? I.e. f(**{"x": NoDict}) (lambda **kw: kw)(x=NoDict) In that

Re: [Python-ideas] Optional parameters without default value

On 02.03.2017 12:31, Stephan Houben wrote: > I am not sure if I fully understand the proposal then. > > NoDefault would be special syntax so that this would be disallowed: > > f(NoDefault) > > but this would be allowed: > def f(x=NoDefault): >... > > and also this: > > x is NoDefault > >

Re: [Python-ideas] Optional parameters without default value

I am not sure if I fully understand the proposal then. NoDefault would be special syntax so that this would be disallowed: f(NoDefault) but this would be allowed: def f(x=NoDefault): ... and also this: x is NoDefault So this would seem to require an exhaustive list of syntactic contexts

Re: [Python-ideas] Positional-only parameters

Here's a proof-of-concept for the decorator. It does not address the issue of passing aliases to positional arguments to **kwargs - I guess this requires changes in the CPython's core. (Sorry about the coloring, that's how it's pasted) from inspect import signature, Parameter from functools

Re: [Python-ideas] Optional parameters without default value

In cases like this I would recommend creating the sentinel yourself: NoDefault = object() def get(store, key, default=NoDefault): if default is NoDefault: # do something You can arrange to not export NoDefault so that the client code cannot even access the sentinel value. This is

Re: [Python-ideas] Optional parameters without default value

On 02.03.2017 10:06, Serhiy Storchaka wrote: > On 02.03.17 10:36, M.-A. Lemburg wrote: >> Why a new syntax ? Can't we just have a pre-defined sentinel >> singleton NoDefault and use that throughout the code (and also >> special case it in argument parsing/handling)? >> >> def get(store, key,

Re: [Python-ideas] Positional-only parameters

On 03/01/2017 11:41 PM, Stephan Houben wrote: I have a slight variant of the decorator proposal. Rather than specify a count, let the decorator implement the typeshed dunder convention: @positional_only def replace(self, __old, __new, count=-1): (I imagine this decorator would also

Re: [Python-ideas] Optional parameters without default value

On 2 March 2017 at 09:36, M.-A. Lemburg wrote: > On 02.03.2017 09:03, Serhiy Storchaka wrote: > > Function implemented in Python can have optional parameters with default > [...] > Why a new syntax ? Can't we just have a pre-defined sentinel > singleton NoDefault and use that

Re: [Python-ideas] Optional parameters without default value

On 02.03.2017 09:03, Serhiy Storchaka wrote: > Function implemented in Python can have optional parameters with default > value. It also can accept arbitrary number of positional and keyword > arguments if use var-positional or var-keyword parameters (*args and > **kwargs). But there is no way to

Re: [Python-ideas] add __contains__ into the "type" object

This suggestion is really problematic IMHO. "isinstance" is a nominal check. I can't ask "isinstance(x, Callable[int, int])" because that would imply solving the halting problem. so "isinstance(x, Y)" does not mean "is it true that x is an element of the type Y" but rather "is it true that x was

Re: [Python-ideas] PEP 8 coding style included in grammar ?

On 02.03.2017 01:04, Barry Warsaw wrote: > On Mar 01, 2017, at 03:04 PM, Mathieu BEAL wrote: > >> I was wondering why the PEP coding style ( >> https://www.python.org/dev/peps/pep-0008/) is not natively included in python >> grammar ? > > Well, the simple answer is that the grammar predates PEP

[Python-ideas] Optional parameters without default value

Function implemented in Python can have optional parameters with default value. It also can accept arbitrary number of positional and keyword arguments if use var-positional or var-keyword parameters (*args and **kwargs). But there is no way to declare an optional parameter that don't have