On Mar 10, 2017 02:42, "Terry Reedy" wrote:
On 3/2/2017 3:03 AM, 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 (
On 3/2/2017 3:03 AM, 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).
In other words, Python signa
On 03.03.2017 16:24, Yury Selivanov wrote:
TBH I think that optional parameters isn't a problem requiring new
syntax. We probably do need syntax for positional-only arguments
(since we already have them in a way), but optional parameters
can be solved easily without a new syntax.
Syntax like:
On 03/03/2017 06:29 AM, Victor Stinner wrote:
An alternative for generated signature of multiple optional arguments
is "bytearray([source[, encoding[, errors]]])", but I'm not a big fan
of nested [...],
But that's not the same thing.
bytearry([source,] [encoding,] [errors])
says that each
TBH I think that optional parameters isn't a problem requiring new
syntax. We probably do need syntax for positional-only arguments
(since we already have them in a way), but optional parameters
can be solved easily without a new syntax.
Syntax like:
1. def a(?foo),
2. def a(foo=pass),
3. def a
Since yet another sentinel singleton sounds like a dead end, I suggest
to use [arg=value] syntax and require a default value in the
prototype, as currently required for *optional keyword* arguments.
"[...]" syntax for optional parameter is commonly used in Python
documentation (but the exact synta
On 03.03.2017 14:06, Victor Stinner wrote:
2017-03-03 6:13 GMT+01:00 Mike Miller :
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 perspect
2017-03-03 6:13 GMT+01:00 Mike Miller :
> 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.
The question here is how to have a
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
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
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 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
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 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 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
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 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
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
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 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
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
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 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
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
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 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
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 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 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 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 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 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
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 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
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
>
>
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 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
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 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
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.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 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 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
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
44 matches
Mail list logo
