On Sat, Jun 16, 2012 at 10:52 AM, Benjamin Peterson benja...@python.org wrote:
2012/6/15 Larry Hastings la...@hastings.org:
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
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
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 function, how
On Fri, Jun 15, 2012 at 3:23 PM, Larry Hastings la...@hastings.org 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
On Thu, 14 Jun 2012 21:43:34 -0700
Larry Hastings la...@hastings.org wrote:
On 06/14/2012 08:20 PM, Benjamin Peterson wrote:
2012/6/14 Larry Hastingsla...@hastings.org:
Also, it's more granular than that. For example, Python now understands
symbolic links on Windows--but only haphazardly
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
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
On 2012-06-14, at 11:21 PM, Nick Coghlan wrote:
On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov
yselivanov...@gmail.com 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
On Fri, Jun 15, 2012 at 8:51 PM, Larry Hastings la...@hastings.org 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
On Fri, Jun 15, 2012 at 9:25 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-14, at 11:21 PM, Nick Coghlan wrote:
On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov
yselivanov...@gmail.com wrote:
On 2012-06-14, at 7:16 PM, Nick Coghlan wrote:
POSITIONAL_ONLY
POSITIONAL_OR_KEYWORD
On 15 June 2012 12:32, Nick Coghlan ncogh...@gmail.com 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.
2012/6/15 Larry Hastings la...@hastings.org:
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
On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Peterson benja...@python.org wrote:
2012/6/15 Larry Hastings la...@hastings.org:
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
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
On Fri, 15 Jun 2012 11:17:09 -0700, Larry Hastings la...@hastings.org 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.
On Fri, Jun 15, 2012 at 9:52 AM, Benjamin Petersonbenja...@python.org wrote:
2012/6/15 Larry Hastingsla...@hastings.org:
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
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
2012/6/15 Larry Hastings la...@hastings.org:
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
On 06/15/2012 12:06 PM, Benjamin Peterson wrote:
2012/6/15 Larry Hastingsla...@hastings.org:
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
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
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
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 yselivanov...@gmail.com wrote:
* bind(\*args, \*\*kwargs) - BoundArguments
Creates a mapping from positional and keyword arguments to
parameters. Raises a
On Sat, 16 Jun 2012 07:48:19 +1000
Steven D'Aprano st...@pearwood.info 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
2012/6/15 Larry Hastings la...@hastings.org:
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
On Jun 14, 2012 2:31 PM, Alexandre Zani alexandre.z...@gmail.com 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?
On 2012-06-14, at 12:17 AM, Nick Coghlan wrote:
On Thu, Jun 14, 2012 at 1:06 PM, Yury Selivanov yseliva...@gmail.com 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,
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
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 are
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 yseliva...@gmail.com wrote:
On 2012-06-14, at
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 default
On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov yselivanov...@gmail.com 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
Thanks. :)
On Thu, Jun 14, 2012 at 4:50 AM, Yury Selivanov yseliva...@gmail.com 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,
-
On 2012-06-14, at 10:50 AM, Alexandre Zani wrote:
On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov yselivanov...@gmail.com
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
On Thu, 14 Jun 2012 07:50:42 -0700, Alexandre Zani alexandre.z...@gmail.com
wrote:
On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov yselivanov...@gmail.com
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?
On 14 June 2012 15:50, Alexandre Zani alexandre.z...@gmail.com 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
On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov yselivanov...@gmail.comwrote:
[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'.
Brett Cannon wrote:
On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov yselivanov...@gmail.com
mailto:yselivanov...@gmail.com wrote:
[SNIP]
Let's consider replacement of 'Parameter.is_*' set of attributes with
a single 'Parameter.kind' attribute, which will have the following
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:
[SNIP]
Let's consider replacement of 'Parameter.is_*' set of attributes with
a single 'Parameter.kind' attribute, which will have the following
possible
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 yselivanov...@gmail.com wrote:
[SNIP]
Let's consider replacement of 'Parameter.is_*' set of attributes with
a single 'Parameter.kind' attribute, which will have the
2012/6/14 Yury Selivanov yselivanov...@gmail.com:
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:
[SNIP]
Let's consider replacement of 'Parameter.is_*' set of attributes with
a single 'Parameter.kind'
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov yselivanov...@gmail.com:
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:
[SNIP]
Let's consider replacement of 'Parameter.is_*'
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
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 annotations.
On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov yselivanov...@gmail.comwrote:
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov yselivanov...@gmail.com:
On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov
+1
On Thu, Jun 14, 2012 at 9:16 AM, Yury Selivanov yselivanov...@gmail.com wrote:
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:
[SNIP]
Let's consider replacement of 'Parameter.is_*' set of attributes with
a
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
On 6/14/2012 1:10 PM, Brett Cannon wrote:
On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov
yselivanov...@gmail.com mailto:yselivanov...@gmail.com wrote:
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov yselivanov...@gmail.com
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 describe the
On Thu, Jun 14, 2012 at 9:06 AM, R. David Murray rdmur...@bitdance.com 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
On Thu, Jun 14, 2012 at 10:10 AM, Brett Cannon br...@python.org wrote:
On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
2012/6/14 Yury Selivanov yselivanov...@gmail.com:
On 2012-06-14, at 11:24 AM, Brett
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
On Thu, 14 Jun 2012 09:32:59 -0700
Benjamin Peterson benja...@python.org 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
Antoine Pitrou wrote:
On Thu, 14 Jun 2012 09:32:59 -0700
Benjamin Peterson benja...@python.org 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):
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us 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
2012/6/14 Ethan Furman et...@stoneleaf.us:
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
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we have with strings now:
-- 'aA'.islower()
False
-- 'aA'.isupper()
False
-- 'a'.islower()
True
--
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we have with strings now:
-- 'aA'.islower()
False
--
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()
False
On Thu, 14 Jun 2012 21:57:34 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we have with strings now:
-- 'aA'.islower()
False
-- 'aA'.isupper()
False
-- 'a'.islower()
On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote:
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman et...@stoneleaf.us wrote:
This is no different from what we
On Wed, 13 Jun 2012 22:52:43 -0400
Yury Selivanov yselivanov...@gmail.com 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
On Thu, Jun 14, 2012 at 1:45 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote:
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 14 Jun 2012 12:46:38
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
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
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:
On Thu, Jun 14, 2012 at 2:00 PM, Benjamin Peterson benja...@python.org wrote:
2012/6/14 Alexandre Zani alexandre.z...@gmail.com:
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
On 2012-06-14, at 4:53 PM, Antoine Pitrou wrote:
On Wed, 13 Jun 2012 22:52:43 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
* bind(\*args, \*\*kwargs) - BoundArguments
Creates a mapping from positional and keyword arguments to
parameters. Raises a ``BindError`` (subclass of
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
2012/6/14 Nick Coghlan ncogh...@gmail.com:
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
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
On Jun 15, 2012 8:37 AM, Benjamin Peterson benja...@python.org wrote:
2012/6/14 Nick Coghlan ncogh...@gmail.com:
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
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
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
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
2012/6/14 Larry Hastings la...@hastings.org:
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
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
2012/6/14 Larry Hastings la...@hastings.org:
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
On Fri, Jun 15, 2012 at 11:37 AM, Yury Selivanov
yselivanov...@gmail.com 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
On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Peterson benja...@python.org wrote:
2012/6/14 Larry Hastings la...@hastings.org:
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
On 06/14/2012 08:20 PM, Benjamin Peterson wrote:
2012/6/14 Larry Hastingsla...@hastings.org:
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
On 06/14/2012 08:41 PM, Nick Coghlan wrote:
On Fri, Jun 15, 2012 at 1:20 PM, Benjamin Petersonbenja...@python.org wrote:
2012/6/14 Larry Hastingsla...@hastings.org:
Also, it's more granular than that. For example, Python now understands
symbolic links on Windows--but only haphazardly at
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
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 before
On Thu, Jun 14, 2012 at 1:06 PM, Yury Selivanov yseliva...@gmail.com 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
On Wed, Jun 13, 2012 at 8:06 PM, Yury Selivanov yseliva...@gmail.com 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
84 matches
Mail list logo
