Re: [Python-Dev] PEP 362 Third Revision

On Sat, Jun 16, 2012 at 10:52 AM, Benjamin Peterson wrote: > 2012/6/15 Larry Hastings : >> Note that I'm genuinely interested in your answer--"is_implemented" appears >> to have a groundswell of anti-support and I rather suspect will be axed. >> Meantime I still need to solve this problem. > > How

Re: [Python-Dev] PEP 362 Third Revision

2012/6/15 Larry Hastings : > Note that I'm genuinely interested in your answer--"is_implemented" appears > to have a groundswell of anti-support and I rather suspect will be axed. > Meantime I still need to solve this problem. How about a list of functions that support it. Then you could do things

Re: [Python-Dev] PEP 362 Third Revision

On Sat, 16 Jun 2012 07:48:19 +1000 Steven D'Aprano wrote: > > The introduction of BindError will allow functions to raise a more specific, > and less misleading, exception when they are called with the wrong number of > arguments, or invalid keywords, etc. If that's what you want, a separate P

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: On 2012-06-14, at 4:53 PM, Antoine Pitrou wrote: On Wed, 13 Jun 2012 22:52:43 -0400 Yury Selivanov wrote: * bind(\*args, \*\*kwargs) -> BoundArguments Creates a mapping from positional and keyword arguments to parameters. Raises a ``BindError`` (subclass of ``Type

Re: [Python-Dev] PEP 362 Third Revision

On 06/15/2012 12:34 PM, Yury Selivanov wrote: On 2012-06-15, at 3:31 PM, Larry Hastings wrote: (Perhaps the right thing would be to take this discussion to issue 14626.) Let's keep it in this thread while it's related to Signature. I can assure you, however Benjamin might spell it, it won't u

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-15, at 3:31 PM, Larry Hastings wrote: > (Perhaps the right thing would be to take this discussion to issue 14626.) Let's keep it in this thread while it's related to Signature. - Yury ___ Python-Dev mailing list Python-Dev@python.org http://

Re: [Python-Dev] PEP 362 Third Revision

On 06/15/2012 12:06 PM, Benjamin Peterson wrote: 2012/6/15 Larry Hastings: On 06/15/2012 11:46 AM, R. David Murray wrote: Adding a os.have_openat seems more reasonable than adding is_implemented to every __signature__ object. And more useful, as well; it provides a much more specific piece of

Re: [Python-Dev] PEP 362 Third Revision

2012/6/15 Larry Hastings : > On 06/15/2012 11:46 AM, R. David Murray wrote: > > Adding a os.have_openat seems more reasonable than adding is_implemented > to every __signature__ object. And more useful, as well; it provides > a much more specific piece of information. > > > We already have "os.hav

Re: [Python-Dev] PEP 362 Third Revision

On 06/15/2012 11:46 AM, R. David Murray wrote: Adding a os.have_openat seems more reasonable than adding is_implemented to every __signature__ object. And more useful, as well; it provides a much more specific piece of information. We already have "os.have_openat"; it's spelled sysconfig.get_

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson wrote: 2012/6/15 Larry Hastings: If I understand you correctly, you seem to be trying to apply "is_implemented" to the problem of predicting which specific inputs to a parameter would be valid. I don't think that problem is tractable--it's w

Re: [Python-Dev] PEP 362 Third Revision

On Fri, 15 Jun 2012 11:17:09 -0700, Larry Hastings wrote: > On 06/15/2012 04:32 AM, Nick Coghlan wrote: > > Since I don't believe your proposed flag will answer any question that > > actually matters in practice, I consider it useless noise that should > > be dropped from the proposal. > > I can

Re: [Python-Dev] PEP 362 Third Revision

On 06/15/2012 04:32 AM, Nick Coghlan wrote: Since I don't believe your proposed flag will answer any question that actually matters in practice, I consider it useless noise that should be dropped from the proposal. I can cite a situation where it matters in practice: the implementation of os.

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson wrote: > 2012/6/15 Larry Hastings : >> If I understand you correctly, you seem to be trying to apply >> "is_implemented" to the problem of predicting which specific inputs to a >> parameter would be valid.  I don't think that problem is tractable-

Re: [Python-Dev] PEP 362 Third Revision

2012/6/15 Larry Hastings : > If I understand you correctly, you seem to be trying to apply > "is_implemented" to the problem of predicting which specific inputs to a > parameter would be valid.  I don't think that problem is tractable--it's way > too context-specific. Exactly! It's too context sen

Re: [Python-Dev] PEP 362 Third Revision

On 15 June 2012 12:32, Nick Coghlan wrote: > Now, what a function *could* do is set __signature__ to a Signature > subclass that provided an additional "validate()" method, or provided > arbitrary additional information about supported features. That's a > perfectly reasonable option. It might be

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 9:25 PM, Yury Selivanov wrote: > On 2012-06-14, at 11:21 PM, Nick Coghlan wrote: >> On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov >> wrote: >>> On 2012-06-14, at 7:16 PM, Nick Coghlan wrote: >>> POSITIONAL_ONLY POSITIONAL_OR_KEYWORD VAR_POSITIONAL KE

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 8:51 PM, Larry Hastings wrote: > If I understand you correctly, you seem to be trying to apply > "is_implemented" to the problem of predicting which specific inputs to a > parameter would be valid.  I don't think that problem is tractable--it's way > too context-specific.

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 11:21 PM, Nick Coghlan wrote: > On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov > wrote: >> On 2012-06-14, at 7:16 PM, Nick Coghlan wrote: >> >>> POSITIONAL_ONLY >>> POSITIONAL_OR_KEYWORD >>> VAR_POSITIONAL >>> KEYWORD_ONLY >>> VAR_KEYWORD >> >> I like those. A bit too length

Re: [Python-Dev] PEP 362 Third Revision

On 06/15/2012 12:18 AM, Nick Coghlan wrote: Perhaps you meant "ill-concieved"? No, I mean ill-defined. The criteria for when a particular platform should flip that bit for an arbitrary parameter is highly unclear, as whether or not a particular parameter is "implemented" or not depends on the o

Re: [Python-Dev] PEP 362 Third Revision

R. David Murray wrote: We know that a string cannot be both all-upper and all-lower at the same time; We know that because it's common wisdom for everyone (although who knows what oddities the unicode consortium may come up with in the future). Indeed, there is at least one letter that is use

Re: [Python-Dev] PEP 362 Third Revision

On Thu, 14 Jun 2012 21:43:34 -0700 Larry Hastings wrote: > On 06/14/2012 08:20 PM, Benjamin Peterson wrote: > > 2012/6/14 Larry Hastings: > >> Also, it's more granular than that. For example, Python now understands > >> symbolic links on Windows--but only haphazardly at best. The > >> "follow_s

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 3:23 PM, Larry Hastings wrote: > I disagree with the description "ill-defined".  I would be very surprised > indeed if either you or Benjamin genuinely didn't understand exactly what > "is_implemented" represents.  If you're suggesting that the documentation is > inadequate

Re: [Python-Dev] PEP 362 Third Revision

On 06/14/2012 11:37 PM, Victor Stinner wrote: os.chown.__signature__.parameters['fd'].is_implemented = sysconfig.get_config_var('HAVE_FCHOWN') (Do you mean "fd" or "dirfd"?) I meant "fd". "dir_fd" is contingent on fchownat(). But it was only an example anyway. I don't like such functio

Re: [Python-Dev] PEP 362 Third Revision

>> I don't understand what the purpose of is_implemented is, or how it is >> supposed to be computed. > > It's computed based on locally available functionality.  Its purpose is to > allow LBYL when using functionality that may not be available on all > platforms.  See issue 14626 for a specific us

Re: [Python-Dev] PEP 362 Third Revision

On 06/14/2012 08:41 PM, Nick Coghlan wrote: On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson wrote: 2012/6/14 Larry Hastings: Also, it's more granular than that. For example, Python now understands symbolic links on Windows--but only haphazardly at best. The "follow_symlinks" argument wor

Re: [Python-Dev] PEP 362 Third Revision

On 06/14/2012 08:20 PM, Benjamin Peterson wrote: 2012/6/14 Larry Hastings: Also, it's more granular than that. For example, Python now understands symbolic links on Windows--but only haphazardly at best. The "follow_symlinks" argument works on Windows for os.stat() but not for os.chmod(). The

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson wrote: > 2012/6/14 Larry Hastings : >> Also, it's more granular than that.  For example, Python now understands >> symbolic links on Windows--but only haphazardly at best.  The >> "follow_symlinks" argument works on Windows for os.stat() but not f

Re: [Python-Dev] PEP 362 Third Revision

On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov wrote: > On 2012-06-14, at 7:16 PM, Nick Coghlan wrote: > >> POSITIONAL_ONLY >> POSITIONAL_OR_KEYWORD >> VAR_POSITIONAL >> KEYWORD_ONLY >> VAR_KEYWORD > > I like those.  A bit too lengthy and verbose, but the names > are consistent. In this case, I

Re: [Python-Dev] PEP 362 Third Revision

2012/6/14 Larry Hastings : > Also, it's more granular than that.  For example, Python now understands > symbolic links on Windows--but only haphazardly at best.  The > "follow_symlinks" argument works on Windows for os.stat() but not for > os.chmod(). Then indeed it's more granular than a paramete

Re: [Python-Dev] PEP 362 Third Revision

On 06/14/2012 07:49 PM, Benjamin Peterson wrote: In that case wouldn't be nicer to have os level attribute ala os.path.supports_unicode_filenames? os.supports_atfunctions is gobs nicer than os.chown.__signature__.parameters['fd'].is_implemented Not "implementing" all parameters (whatever exac

Re: [Python-Dev] PEP 362 Third Revision

2012/6/14 Larry Hastings : > > On 06/14/2012 01:53 PM, Antoine Pitrou wrote: > > * is_implemented : bool > True if the parameter is implemented for use. Some platforms > implement functions but can't support specific parameters > (e.g. "mode" for ``os.mkdir``). Passing in an unimpleme

Re: [Python-Dev] PEP 362 Third Revision

On 06/14/2012 01:53 PM, Antoine Pitrou wrote: * is_implemented : bool True if the parameter is implemented for use. Some platforms implement functions but can't support specific parameters (e.g. "mode" for ``os.mkdir``). Passing in an unimplemented parameter may result in t

Re: [Python-Dev] PEP 362 Third Revision

On 06/14/2012 05:06 AM, Victor Stinner wrote: * is_implemented : bool True if the parameter is implemented for use. Some platforms implement functions but can't support specific parameters (e.g. "mode" for ``os.mkdir``). Passing in an unimplemented parameter may result in the pa

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 7:16 PM, Nick Coghlan wrote: > POSITIONAL_ONLY > POSITIONAL_OR_KEYWORD > VAR_POSITIONAL > KEYWORD_ONLY > VAR_KEYWORD I like those. A bit too lengthy and verbose, but the names are consistent. - Yury ___ Python-Dev mailing list Python

Re: [Python-Dev] PEP 362 Third Revision

On Jun 15, 2012 8:37 AM, "Benjamin Peterson" wrote: > > 2012/6/14 Nick Coghlan : > > I like the idea of a kind attribute, I don't like the current names for the > > possible values. > > > > At the very least, "positional only" needs to be supported to handle > > nameless parameters in C functions

Re: [Python-Dev] PEP 362 Third Revision

Nick Coghlan wrote: I like the idea of a kind attribute, I don't like the current names for the possible values. At the very least, "positional only" needs to be supported to handle nameless parameters in C functions (or those that unpack *args internally) The level of abbreviation used also

Re: [Python-Dev] PEP 362 Third Revision

2012/6/14 Nick Coghlan : > I like the idea of a kind attribute, I don't like the current names for the > possible values. > > At the very least, "positional only" needs to be supported to handle > nameless parameters in C functions (or those that unpack *args internally) > > The level of abbreviati

Re: [Python-Dev] PEP 362 Third Revision

I like the idea of a kind attribute, I don't like the current names for the possible values. At the very least, "positional only" needs to be supported to handle nameless parameters in C functions (or those that unpack *args internally) The level of abbreviation used also seems unnecessary and in

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 4:53 PM, Antoine Pitrou wrote: > On Wed, 13 Jun 2012 22:52:43 -0400 > Yury Selivanov wrote: > >> * bind(\*args, \*\*kwargs) -> BoundArguments >>Creates a mapping from positional and keyword arguments to >>parameters. Raises a ``BindError`` (subclass of ``TypeError``) >>

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 2:00 PM, Benjamin Peterson wrote: > 2012/6/14 Alexandre Zani : >> How about keyword instead of kwonly? I find kwonly clear when >> side-by-side with varkw, but ambiguous standalone. >> >> I like the idea of using args and kwargs just because those are the >> defacto standar

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: I'll amend the PEP this evening to replace 'is_args', 'is_kwargs', and 'is_keyword_only' with a 'kind' attribute, with possible values: 'positional', 'vararg', 'varkw', 'kwonly'. Parameter class will have four constants, respectively: class Parameter: KIND_PO

Re: [Python-Dev] PEP 362 Third Revision

2012/6/14 Alexandre Zani : > How about keyword instead of kwonly? I find kwonly clear when > side-by-side with varkw, but ambiguous standalone. > > I like the idea of using args and kwargs just because those are the > defacto standard way we refer to that type of argument. That conflates the name

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 1:45 PM, Yury Selivanov wrote: > On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote: > >> 2012/6/14 Alexandre Zani : >>> On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou >>> wrote: On Thu, 14 Jun 2012 12:46:38 -0700 Ethan Furman wrote: > > This is no di

Re: [Python-Dev] PEP 362 Third Revision

On Wed, 13 Jun 2012 22:52:43 -0400 Yury Selivanov wrote: > * is_implemented : bool > True if the parameter is implemented for use. Some platforms > implement functions but can't support specific parameters > (e.g. "mode" for ``os.mkdir``). Passing in an unimplemented > parameter

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote: > 2012/6/14 Alexandre Zani : >> On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou wrote: >>> On Thu, 14 Jun 2012 12:46:38 -0700 >>> Ethan Furman wrote: This is no different from what we have with strings now: --> 'aA'.islow

Re: [Python-Dev] PEP 362 Third Revision

On Thu, 14 Jun 2012 21:57:34 +0200, Antoine Pitrou wrote: > On Thu, 14 Jun 2012 12:46:38 -0700 > Ethan Furman wrote: > > > > This is no different from what we have with strings now: > > > > --> 'aA'.islower() > > False > > --> 'aA'.isupper() > > False > > --> 'a'.islower() > > True > > --> 'A'.

Re: [Python-Dev] PEP 362 Third Revision

On 6/14/2012 3:46 PM, Ethan Furman wrote: Antoine Pitrou wrote: Also, the "is_*" attributes are misleading: it looks like they are orthogonal but only one of them can be true at any time. This is no different from what we have with strings now: --> 'aA'.islower() False --> 'aA'.isupper() Fa

Re: [Python-Dev] PEP 362 Third Revision

2012/6/14 Alexandre Zani : > On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou wrote: >> On Thu, 14 Jun 2012 12:46:38 -0700 >> Ethan Furman wrote: >>> >>> This is no different from what we have with strings now: >>> >>> --> 'aA'.islower() >>> False >>> --> 'aA'.isupper() >>> False >>> --> 'a'.islo

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou wrote: > On Thu, 14 Jun 2012 12:46:38 -0700 > Ethan Furman wrote: >> >> This is no different from what we have with strings now: >> >> --> 'aA'.islower() >> False >> --> 'aA'.isupper() >> False >> --> 'a'.islower() >> True >> --> 'A'.isupper() >> T

Re: [Python-Dev] PEP 362 Third Revision

2012/6/14 Ethan Furman : > This is no different from what we have with strings now: > > --> 'aA'.islower() > False > --> 'aA'.isupper() > False > --> 'a'.islower() > True > --> 'A'.isupper() > True > > We know that a string cannot be both all-upper and all-lower at the same > time; likewise we know

Re: [Python-Dev] PEP 362 Third Revision

On Thu, 14 Jun 2012 12:46:38 -0700 Ethan Furman wrote: > > This is no different from what we have with strings now: > > --> 'aA'.islower() > False > --> 'aA'.isupper() > False > --> 'a'.islower() > True > --> 'A'.isupper() > True > > We know that a string cannot be both all-upper and all-lower

Re: [Python-Dev] PEP 362 Third Revision

Antoine Pitrou wrote: On Thu, 14 Jun 2012 09:32:59 -0700 Benjamin Peterson wrote: How about adding 'kind' and keeping 'is_*' attributes, but making them read-only dynamic properties, i.e.: class Parameter: ... @property def is_vararg(self): return self.kind == 'v

Re: [Python-Dev] PEP 362 Third Revision

On Thu, 14 Jun 2012 09:32:59 -0700 Benjamin Peterson wrote: > > > > How about adding 'kind' and keeping 'is_*' attributes, > > but making them read-only dynamic properties, i.e.: > > > >   class Parameter: > >       ... > > > >       @property > >       def is_vararg(self): > >           return se

Re: [Python-Dev] PEP 362 Third Revision

Alexandre Zani wrote: I don't think it really breaks TOOWTDI because you're talking about two use-cases. In one case, you're checking if something is a particular kind of parameter. In the other case, you're doing some sort of dict-based dispatch. I also think is_args etc is cleaner to use when d

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 10:10 AM, Brett Cannon wrote: > > > On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov > wrote: >> >> On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote: >> >> > 2012/6/14 Yury Selivanov : >> >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote: >> >>> On Thu, Jun 14, 2012 at

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 9:06 AM, R. David Murray wrote: > I don't have strong feelings about this, but to me the fact that there > are values of the individual parameters that if they occur on the same > object at the same time would be invalid is a code smell.  If the thing > can be one and only

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 1:51 PM, Terry Reedy wrote: > On 6/14/2012 6:00 AM, Nick Coghlan wrote: > >> > Just a thought: Do we want to include the docstring? A function's >> > docstring is often intimately tied to its signature. (Or at least, a >> > lot of us try to write docstrings that effectively desc

Re: [Python-Dev] PEP 362 Third Revision

On 6/14/2012 1:10 PM, Brett Cannon wrote: On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov mailto:yselivanov...@gmail.com>> wrote: On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote: > 2012/6/14 Yury Selivanov mailto:yselivanov...@gmail.com>>: >> On 2012-06-14, at 11:24 AM, Bre

Re: [Python-Dev] PEP 362 Third Revision

On 6/14/2012 6:00 AM, Nick Coghlan wrote: > Just a thought: Do we want to include the docstring? A function's > docstring is often intimately tied to its signature. (Or at least, a > lot of us try to write docstrings that effectively describe the > function's signature) No, combining the si

Re: [Python-Dev] PEP 362 Third Revision

+1 On Thu, Jun 14, 2012 at 9:16 AM, Yury Selivanov wrote: > On 2012-06-14, at 11:24 AM, Brett Cannon wrote: >> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov >> wrote: >> >> [SNIP] >> >> Let's consider replacement of 'Parameter.is_*' set of attributes with >> a single 'Parameter.kind' attribut

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov wrote: > On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote: > > > 2012/6/14 Yury Selivanov : > >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote: > >>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov < > yselivanov...@gmail.com> wrote: > >>> > >>>

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 12:03 PM, Ethan Furman wrote: > Yury Selivanov wrote: >> Hello, >> The new revision of PEP 362 has been posted: >> http://www.python.org/dev/peps/pep-0362/ >> It's possible to test Signatures for equality. Two signatures >> are equal when they have equal parameters and return an

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ It's possible to test Signatures for equality. Two signatures are equal when they have equal parameters and return annotations. Possibly a dumb question, but do the parameter n

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote: > 2012/6/14 Yury Selivanov : >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote: >>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov >>> wrote: >>> >>> [SNIP] >>> >>> Let's consider replacement of 'Parameter.is_*' set of attributes with >>> a

Re: [Python-Dev] PEP 362 Third Revision

2012/6/14 Yury Selivanov : > On 2012-06-14, at 11:24 AM, Brett Cannon wrote: >> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov >> wrote: >> >> [SNIP] >> >> Let's consider replacement of 'Parameter.is_*' set of attributes with >> a single 'Parameter.kind' attribute, which will have the following

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: On 2012-06-14, at 11:24 AM, Brett Cannon wrote: On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov wrote: [SNIP] Let's consider replacement of 'Parameter.is_*' set of attributes with a single 'Parameter.kind' attribute, which will have the following possible values: 'pos

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 11:24 AM, Brett Cannon wrote: > On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov > wrote: > > [SNIP] > > Let's consider replacement of 'Parameter.is_*' set of attributes with > a single 'Parameter.kind' attribute, which will have the following > possible values: 'positional',

Re: [Python-Dev] PEP 362 Third Revision

Brett Cannon wrote: On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov > wrote: [SNIP] Let's consider replacement of 'Parameter.is_*' set of attributes with a single 'Parameter.kind' attribute, which will have the following possible values: 'posi

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov wrote: [SNIP] > > > Let's consider replacement of 'Parameter.is_*' set of attributes with > a single 'Parameter.kind' attribute, which will have the following > possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'. > > (I think 'posit

Re: [Python-Dev] PEP 362 Third Revision

On 14 June 2012 15:50, Alexandre Zani wrote: > Comparing with strings is error prone. If I do param.is_varargs > (adding an s at the end of the attribute name) I will see an attribute > error and know what is going on. If I do the same mistake with the > kind attribute param.kind == "varargs", the

Re: [Python-Dev] PEP 362 Third Revision

On Thu, 14 Jun 2012 07:50:42 -0700, Alexandre Zani wrote: > On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov > wrote: > > On 2012-06-14, at 8:06 AM, Victor Stinner wrote: > >> Hum, why not using a attribute with a string value instead of 3 > >> attribute? For example: > >> * argtype: "index", "v

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 10:50 AM, Alexandre Zani wrote: > On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov > wrote: >> I guess if nobody really wants to keep 'is_args', we can alter the >> PEP. >> >> Let's consider replacement of 'Parameter.is_*' set of attributes with >> a single 'Parameter.kind' attr

Re: [Python-Dev] PEP 362 Third Revision

Thanks. :) On Thu, Jun 14, 2012 at 4:50 AM, Yury Selivanov wrote: > On 2012-06-14, at 12:29 AM, Alexandre Zani wrote: >> Why do we look at __wrapped__ only if the object is a FunctionType? >> Why not support __wrapped__ on all callables? > > Good idea ;)  I'll add this. > > Thanks, > - > Yury ___

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov wrote: > On 2012-06-14, at 8:06 AM, Victor Stinner wrote: >> Sorry if I'm asking dummy questions, I didn't follow the discussion. >> >>> * format(...) -> str >>>    Formats the Signature object to a string.  Optional arguments allow >>>    for custom

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 8:06 AM, Victor Stinner wrote: > Sorry if I'm asking dummy questions, I didn't follow the discussion. > >> * format(...) -> str >>Formats the Signature object to a string. Optional arguments allow >>for custom render functions for parameter names, >>annotations and d

Re: [Python-Dev] PEP 362 Third Revision

Looks great! One very minor quibble is that I prefer 'ns' to 'dct' for the namespace parameter in a metaclass, but that doesn't really matter for the PEP. -- Sent from my phone, thus the relative brevity :) On Jun 14, 2012 9:45 PM, "Yury Selivanov" wrote: > On 2012-06-14, at 12:17 AM, Nick Cogh

Re: [Python-Dev] PEP 362 Third Revision

Sorry if I'm asking dummy questions, I didn't follow the discussion. > * format(...) -> str >    Formats the Signature object to a string.  Optional arguments allow >    for custom render functions for parameter names, >    annotations and default values, along with custom separators. Hum, what a

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 12:29 AM, Alexandre Zani wrote: > Why do we look at __wrapped__ only if the object is a FunctionType? > Why not support __wrapped__ on all callables? Good idea ;) I'll add this. Thanks, - Yury ___ Python-Dev mailing list Python-Dev@py

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-14, at 12:17 AM, Nick Coghlan wrote: > On Thu, Jun 14, 2012 at 1:06 PM, Yury Selivanov wrote: >> On 2012-06-13, at 10:52 PM, Yury Selivanov wrote: >>> 2. signature() function support all kinds of callables: >>> classes, metaclasses, methods, class- & staticmethods, >>> 'functools.parti

Re: [Python-Dev] PEP 362 Third Revision

On Jun 14, 2012 2:31 PM, "Alexandre Zani" wrote: > Why do we look at __wrapped__ only if the object is a FunctionType? > Why not support __wrapped__ on all callables? Fair question - duck typing here makes more sense to me, too. > > Why special-case functools.partial? Couldn't functools.partial

Re: [Python-Dev] PEP 362 Third Revision

On Wed, Jun 13, 2012 at 8:06 PM, Yury Selivanov wrote: > On 2012-06-13, at 10:52 PM, Yury Selivanov wrote: >> 2. signature() function support all kinds of callables: >> classes, metaclasses, methods, class- & staticmethods, >> 'functools.partials', and callable objects.  If a callable >> object ha

Re: [Python-Dev] PEP 362 Third Revision

On Thu, Jun 14, 2012 at 1:06 PM, Yury Selivanov wrote: > On 2012-06-13, at 10:52 PM, Yury Selivanov wrote: >> 2. signature() function support all kinds of callables: >> classes, metaclasses, methods, class- & staticmethods, >> 'functools.partials', and callable objects.  If a callable >> object ha

Re: [Python-Dev] PEP 362 Third Revision

On 2012-06-13, at 10:52 PM, Yury Selivanov wrote: > 2. signature() function support all kinds of callables: > classes, metaclasses, methods, class- & staticmethods, > 'functools.partials', and callable objects. If a callable > object has a '__signature__' attribute it does a deepcopy > of it befor

[Python-Dev] PEP 362 Third Revision

Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ Summary: 1. Signature object now represents the call signature of a function. That said, it doesn't have 'name' and 'qualname' attributes anymore, and can be tested for equality against other signature