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 defa
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 8
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 c
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 d
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 throughout the code
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 treat
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, default=NoDefault):
if store.exists(key):
return stor
On 1 March 2017 at 19:38, Serhiy Storchaka wrote:
> On 01.03.17 11:31, Paul Moore wrote:
>>
>> On 1 March 2017 at 01:31, qhlonline wrote:
>>>
>>> My code example is not proper, Yes, may be this is better:
>>> list.sort().revers(
>>
>>
>> We can already do this - reversed(sorted(lst))
>
>
> Or j
On 02.03.2017 09:45, Ivan Levkivskyi wrote:
> 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
>>
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, defaul
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 str
On 02.03.2017 06:46, Nick Coghlan wrote:
On 1 March 2017 at 19:37, Wolfgang Maier
mailto:[email protected]>>
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
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 impor
On 02.03.2017 11:22, Stephan Houben wrote:
> 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 cl
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
in
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
>
>
On 2 March 2017 at 11:31, Stephan Houben wrote:
> NoDefault would be special syntax so that this would be disallowed:
>
> f(NoDefault)
I think the key point of confusion here is whether the language needs
to enforce this or it's just convention.
MAL is saying that f(NoDefault) is disallowed - bu
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 cas
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 only parameters"
> syntax, and -1 on any form o
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
>
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 = dict(**olddict)
>
> This would no
> 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 int:
>print(x)
>
__c
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 do
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 which can accept None as value).
If it is not a keyword, it
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 maili
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 nic
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 behin
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 elements of those sets.
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 "positional-only parameters".
Bah
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 None
Hi Chris,
I do not think such a magic linter can be written.
It seems an obvious instance of the Halting Problem to me.
If it is possible, then the problem is moot anyway since we can just write it
and teach it to treat some arbitrary sentinel
NoDefault = object()
as the magic value and there
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 analyse your source code
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
> "arbitra
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?)
Steph
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%
certainty, a programming
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 obje
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 whic
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
without builtin support f
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])
>
> if all of the argum
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
expressio
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 clever, the hassle of figuring out if you have a parameter clearly outweighs the bene
-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()
--
~Et
On Thu, 2 Mar 2017 at 03:07 Wolfgang Maier <
[email protected]> wrote:
[SNIP]
> As always though, reality can be expected to be quite a bit more
> complicated than theory so I decided to check the stdlib for real uses
> of break. This is quite a tedious task since break is us
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 clever, the hassle o
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
i
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 written in the past, yes, I agree
this chan
Isn't https://www.python.org/dev/peps/pep-0457/ the PEP you are looking for?
On 02.03.2017 19:16, Brett Cannon wrote:
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 sugge
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 declare
On Mar 02, 2017, at 10:03 AM, Serhiy Storchaka wrote:
>Currently you need to use the sentinel idiom for implementing this:
>
>_sentinel = object()
>def get(store, key, default=_sentinel):
> if store.exists(key):
> return store.retrieve(key)
> if default is _sentinel:
> rais
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
evaluat
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 fun
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
Descriptio
I'm going to repeat here what I posted in the thread on lazy imports.
If it's possible for the interpreter to determine when it needs to force
evaluation of a lazy expression or statement, then why not use them
everywhere? If that's the case, then why not make everything lazy by
default? Why not ma
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 and
> statements lazy
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:
I dislike the try/except NameError test to chevk if the parameter is set.
Catching NameError is slow.
What is the root issue? Function signature in help(func)? If yes, the
solution can be a special value understood by inspect.signature().
Should it be possible to pass explicitly the special 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 :
On 02.03.2017
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" a écrit :
>
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,
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 don't think you have to ma
>
> 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 expression
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 t
On 2 March 2017 at 21:06, Wolfgang Maier <
[email protected]> wrote:
> On 02.03.2017 06:46, Nick Coghlan wrote:
>
>> The proposal in this thread then has the significant downside of only
>> covering the "nested side effect" case:
>>
>> for item in iterable:
>> if
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 u
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 not be
> mentioned. Some may
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 analogy:
1. try/else (without except) is S
66 matches
Mail list logo
