On Thu, Jun 7, 2012 at 11:16 AM, Yury Selivanov wrote:
> On 2012-06-06, at 9:00 PM, Nick Coghlan wrote:
> So, the idea for the 'signature(obj)' function is to first check if
> 'obj' has '__signature__' attribute set, if yes - return it, if no -
> create a new one (but don't cache).
I'd say return
On Wed, Jun 6, 2012 at 10:10 PM, Yury Selivanov wrote:
> On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
>> On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov
>> wrote:
>>> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
> I'll try to answer you with the following code:
>
> >>> def foo(*
On 2012-06-06, at 9:00 PM, Nick Coghlan wrote:
> On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow
> wrote:
>> Furthermore, using __signature__ as a cache may even cause problems.
>> If the Signature object is cached then any changes to the function
>> will not be reflected in the Signature object. Cer
On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow wrote:
> Furthermore, using __signature__ as a cache may even cause problems.
> If the Signature object is cached then any changes to the function
> will not be reflected in the Signature object. Certainly that's an
> unlikely case, but it is a real case
On Wed, Jun 6, 2012 at 11:28 AM, Yury Selivanov wrote:
> Never copy attributes by hand, always use 'functools.wraps'. It copies
> '__name__', '__qualname__', and bunch of other attributes to the decorator
> object.
>
> We'll probably extend it to copy __signature__ too; then 'signature(decor(f))'
On Thu, Jun 7, 2012 at 8:38 AM, Steven D'Aprano wrote:
> Brett Cannon wrote:
>> This is also Python, the language that assumes everyone is an consenting
>> adult.
>
>
> Exactly, which is why I'm not asking for __signature__ to be immutable. Who
> knows, despite Larry's skepticism (and mine!), perh
On Wed, Jun 6, 2012 at 12:35 AM, Terry Reedy wrote:
> On 6/5/2012 4:24 PM, Tarek Sheasha wrote:
>>
>> Hello,
>> I have been working for a long time on cross-compiling python for
>> android I have used projects like:
>> http://code.google.com/p/android-python27/
>>
>> I am stuck in a certain area,
Yury Selivanov wrote:
We can implement the __eq__ operator though.
+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-a
On 6/6/2012 6:38 PM, Steven D'Aprano wrote:
redundant. Even so, getfullargspec is not doing any harm. We're not
*adding* complexity, it's already there, and breaking currently working
code by deprecating and then removing it is not a step we should take
lightly. API churn is itself a cost.
The
On Wed, Jun 6, 2012 at 6:07 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 5:40 AM, nick.coghlan
> wrote:
> > +
> > +Alternatives
> > +
> > +
>
> Would it be worth also (briefly) rehashing why the class instance
> couldn't be created before the class body is executed*? It might seem
>
Brett Cannon wrote:
On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano wrote:
Larry Hastings wrote:
[...]
"Changes to the Signature object, or to any of its data members,
do not affect the function itself."
which leaves the possibility that __signature__ may no longer match the
actual argumen
Larry Hastings wrote:
inspect.getfullargspec is currently unable to introspect builtin
functions and methods. Should builtins gain a __signature__ so they
can be introspected?
If function signatures are useful, then they're useful, and the
implementation language for the function is irreleva
Yury Selivanov wrote:
I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures,
however, I don't think it's possible. I.e. we can't make it that the
'signature(foo) is signature(bar)'. We can implement the __eq__ operator
though.
+1 to __eq__.
I don't think we should care ab
On Wed, Jun 6, 2012 at 5:40 AM, nick.coghlan wrote:
> +
> +Alternatives
> +
> +
Would it be worth also (briefly) rehashing why the class instance
couldn't be created before the class body is executed*? It might seem
like a viable alternative if you haven't looked at how classes get
c
On 6/6/2012 7:24 AM, Edward K. Ream wrote:
Hello all,
I'm wondering whether this is the appropriate place to discuss
(global) static type analysis, a topic Guido mentioned around the 28
min mark in his PyCon 2012 keynote,
http://pyvideo.org/video/956/keynote-guido-van-rossum
I think either pyt
+1 on the PEP. FWIW, it may be useful to note that not only has the
pattern of having a class-level init been proposed before, it's actually
used: Zope has had __class_init__ and used it as a metaclass alternative
since well before Thomas Heller's proposal.
And in my case, about 80% of my non-dyn
On Jun 7, 2012 12:20 AM, "Yury Selivanov" wrote:
>
> I agree, that we shouldn't make 'functools' be dependent on 'inspect'
module.
> Moreover, this is not even currently possible, as it creates an
import-loop
> that is hard to untie. But how about the following:
>
> 1. Separate 'Signature' objec
On Jun 7, 2012 3:11 AM, "Steven D'Aprano" wrote:
>
> Larry Hastings wrote:
>
>>> [...]
>>> "Changes to the Signature object, or to any of its data members,
>>> do not affect the function itself."
>>>
>>> which leaves the possibility that __signature__ may no longer match the
actual argument spec,
On 2012-06-06, at 3:33 PM, Daniel Urban wrote:
> On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov
> wrote:
>> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
I'll try to answer you with the following code:
>>> def foo(*args):
...print(args)
>>> bound_args =
On Wed, Jun 6, 2012 at 8:35 PM, Yury Selivanov wrote:
> On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
>>> I'll try to answer you with the following code:
>>>
>>> >>> def foo(*args):
>>> ... print(args)
>>>
>>> >>> bound_args = signature(foo).bind(1, 2, 3)
>>> >>> bound_args.arguments
>
On 6/6/2012 7:40 AM, nick.coghlan wrote:
PEP 422 rewrite to present an idea that a) isn't crazy and
> b) it turns out Thomas Heller proposed back in 2001
+There is currently no corresponding mechanism in Python 3 that allows the
+code executed in the class body to directly influence how t
On 2012-06-06, at 2:22 PM, Daniel Urban wrote:
>> I'll try to answer you with the following code:
>>
>> >>> def foo(*args):
>> ...print(args)
>>
>> >>> bound_args = signature(foo).bind(1, 2, 3)
>> >>> bound_args.arguments
>> OrderedDict([('args', (1, 2, 3))])
>>
>> You can't invoke
>>> BoundArguments Object
>>> =
>>>
>>> Result of a ``Signature.bind`` call. Holds the mapping of arguments
>>> to the function's parameters.
>>
>> The Signature.bind function has changed since the previous version of
>> the PEP. If I understand correctly, the 'arguments' attri
Daniel,
On 2012-06-06, at 1:39 PM, Daniel Urban wrote:
>> BoundArguments Object
>> =
>>
>> Result of a ``Signature.bind`` call. Holds the mapping of arguments
>> to the function's parameters.
>
> The Signature.bind function has changed since the previous version of
> the PE
Sorry I missed answering these on my first pass.
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What to do about parameters which are partly implemented? E.g.
mode='spam' is implemented but mode='ham' is not.
Parameter objects aren't sophisticated enough to represent such a
situation. If y
> BoundArguments Object
> =
>
> Result of a ``Signature.bind`` call. Holds the mapping of arguments
> to the function's parameters.
The Signature.bind function has changed since the previous version of
the PEP. If I understand correctly, the 'arguments' attribute is the
same a
On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
> A question regarding the name. I have often seen the following pattern
> in decorators:
>
> def decor(f):
>def some_func(a,b):
>do_stuff using f
>some_func.__name__ = f.__name__
>return some_func
>
> What are the name and full
On 06/06/2012 09:16 AM, Steven D'Aprano wrote:
Nevertheless, the world is full of doorknobs, and people will have to
deal with their code.
I'm having a hard time seeing it. Can you propose a credible situation
where
* some programmer would have a reason (even a bad reason) to modify
th
On Wed, Jun 6, 2012 at 12:16 PM, Steven D'Aprano wrote:
> Larry Hastings wrote:
>
> [...]
>>> "Changes to the Signature object, or to any of its data members,
>>> do not affect the function itself."
>>>
>>> which leaves the possibility that __signature__ may no longer match the
>>> actual argumen
Eric,
On 2012-06-06, at 1:02 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov
> wrote:
>> On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
>>> Functions already record their name (twice!), and it is simple enough to
>>> query func.__name__. What reason is there for recor
A question regarding the name. I have often seen the following pattern
in decorators:
def decor(f):
def some_func(a,b):
do_stuff using f
some_func.__name__ = f.__name__
return some_func
What are the name and fully qualified names in the signature for the
returned function? som
Larry Hastings wrote:
[...]
"Changes to the Signature object, or to any of its data members,
do not affect the function itself."
which leaves the possibility that __signature__ may no longer match
the actual argument spec, for some reason. If you remove
getfullargspec, people will have to rei
On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov wrote:
> On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
>> Functions already record their name (twice!), and it is simple enough to
>> query func.__name__. What reason is there for recording it a third time, in
>> the Signature object?
>
> Sign
On 06/06/2012 09:05 AM, Larry Hastings wrote:
Is there a use-case for is_implemented?
Yes, see issue 14626.
I should add, there are already some places in the standard library
where is_implemented would be relevant. The "mode" argument to os.mkdir
comes immediately to mind; on Windows it
Steven,
On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
> Brett Cannon wrote:
>> Python has always supported powerful introspection capabilities,
>> including introspecting functions and methods. (For the rest of
>> this PEP, "function" refers to both functions and methods). By
>> examining a
On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
What's the fully qualified name of the function, and why is it needed?
Please see PEP 3155.
"args" is just a common name for the parameter, not for the kind of
parameter. *args (or *data, *whatever) is a varargs parameter, and so
the attribut
Steven D'Aprano wrote:
Brett Cannon wrote:
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon , Jiwon Seo ,
Yury Selivanov , Larry Hastings <
la...@hastings.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2
On Wed, Jun 6, 2012 at 5:31 AM, Nick Coghlan wrote:
> On Wed, Jun 6, 2012 at 5:09 PM, Nick Coghlan wrote:
> > On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby wrote:
> >> To be clear, what I specifically proposed (as I mentioned in an earlier
> >> thread) was simply to patch __build_class__ in order to r
Brett Cannon wrote:
PEP: 362
Title: Function Signature Object
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon , Jiwon Seo ,
Yury Selivanov , Larry Hastings <
la...@hastings.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 21-Aug-2006
Python-Versio
On Jun 06, 2012, at 05:55 PM, Ben Finney wrote:
>The PEP document currently says it targets “3.x”. I'll leave it in that
>state until we're more confident that the current work will be on track
>for a particular Python release.
>
>Do I need to do anything in particular to be explicit that PEP 3143
On 2012-06-06, at 2:48 AM, Nick Coghlan wrote:
> However, looking at the code, I think the split that makes sense is
> for a lower level functools.signature to *only* support real function
> objects (i.e. not even method objects).
>
> At the inspect layer, inspect.signature could then support retr
On 2012-06-06, at 9:28 AM, Isaac Morland wrote:
> On Wed, 6 Jun 2012, Nick Coghlan wrote:
>
>> 2. Signature.bind introduces the ability to split the "bind arguments
>> to parameters" operation from the "call object" operation
>
> Has anybody considered calling bind __call__? That is, the result
On Wed, 6 Jun 2012, Nick Coghlan wrote:
2. Signature.bind introduces the ability to split the "bind arguments
to parameters" operation from the "call object" operation
Has anybody considered calling bind __call__? That is, the result of
calling the signature of a procedure instead of the pro
Hello all,
I'm wondering whether this is the appropriate place to discuss
(global) static type analysis, a topic Guido mentioned around the 28
min mark in his PyCon 2012 keynote,
http://pyvideo.org/video/956/keynote-guido-van-rossum
This is a topic that has interested me for a long time, and it h
Just to add my 2 cents to this discussion as someone who's worked
with mxDateTime for almost 15 years.
I think we all agree that users of an application want to input
date/time data using their local time (which may very well not be
the timezone of the system running the application). On output
th
On Wed, Jun 6, 2012 at 5:09 PM, Nick Coghlan wrote:
> On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby wrote:
>> To be clear, what I specifically proposed (as I mentioned in an earlier
>> thread) was simply to patch __build_class__ in order to restore the missing
>> __metaclass__ hook. (Which, incidentall
Ben Finney writes:
> Georg Brandl writes:
>
> > list of possible features for 3.3 as specified by PEP 398:
> >
> > Candidate PEPs:
> […]
>
> > * PEP 3143: Standard daemon process library
>
> Our porting work will not be done in time for Python 3.3. I will update
> this to target Python 3.4.
The
On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby wrote:
> To be clear, what I specifically proposed (as I mentioned in an earlier
> thread) was simply to patch __build_class__ in order to restore the missing
> __metaclass__ hook. (Which, incidentally, would make ALL code using
> __metaclass__ cross-version
48 matches
Mail list logo
