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
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 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
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
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
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
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 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 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
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 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
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 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,
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 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
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
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
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
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
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
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 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
> 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
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
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
>>> 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
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
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 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 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 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 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
+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 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
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
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
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
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
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
>
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
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 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,
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 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 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 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 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 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
48 matches
Mail list logo
