On Thu, Jun 7, 2012 at 9:41 PM, Nick Coghlan wrote:
> On Fri, Jun 8, 2012 at 2:20 PM, Alexandre Zani
> wrote:
>> A comment on the way methods are handled. I have seen decorators that
>> do something like this:
>>
>> import functools
>>
>> def dec(f):
>> functools.wraps(f)
>> def decorated(
On Fri, Jun 8, 2012 at 2:20 PM, Alexandre Zani wrote:
> A comment on the way methods are handled. I have seen decorators that
> do something like this:
>
> import functools
>
> def dec(f):
> functools.wraps(f)
> def decorated(*args, *kwargs):
> cursor = databaseCursor()
> retur
On Fri, Jun 8, 2012 at 2:04 PM, Yury Selivanov wrote:
>>> If you dig up some of the older PEP 362 discussions, you'll find that
>>> allowing developers to reduce this problem over time is the main
>>> reason the Signature.bind() method was added to the PEP. While I
>>> wouldn't recommend it for th
A comment on the way methods are handled. I have seen decorators that
do something like this:
import functools
def dec(f):
functools.wraps(f)
def decorated(*args, *kwargs):
cursor = databaseCursor()
return f(cursor, *args, **kwargs)
As a result, if the decorated function
Nick,
I'm replying to your email (re 'functools.partial') in python-ideas here,
in the PEP 362 thread, as my response raises some questions regarding its
design.
> On 2012-06-07, at 11:40 PM, Nick Coghlan wrote:
>> On Fri, Jun 8, 2012 at 12:57 PM, Yury Selivanov
>> wrote:
>>> Hello,
>>>
>>> W
On Fri, Jun 8, 2012 at 12:18 PM, Larry Hastings wrote:
> On 06/07/2012 07:08 PM, Steven D'Aprano wrote:
>
> Perhaps func.__signature__ should be a computed the first time it is
> accessed?
>
>
> The PEP already declares that signatures are lazily generated. signature()
> checks to see if __signat
On 2012-06-07, at 8:40 PM, R. David Murray wrote:
> IMO the __repr__ should make it clear that it is a signature object
> somehow.
+1.
-
Yury
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
On 06/07/2012 07:08 PM, Steven D'Aprano wrote:
Perhaps func.__signature__ should be a computed the first time it is
accessed?
The PEP already declares that signatures are lazily generated.
signature() checks to see if __signature__ is set, and if it is returns
it. (Or, rather, a deepcopy of
Nick Coghlan wrote:
On Fri, Jun 8, 2012 at 4:34 AM, Larry Hastings wrote:
In other words: this is possible but extremely unlikely, and will only be
done knowingly and with deliberate intent by a skilled practitioner.
I think it's reasonable to declare that, if you're monkeying around with
dund
On Fri, Jun 8, 2012 at 4:34 AM, Larry Hastings wrote:
> In other words: this is possible but extremely unlikely, and will only be
> done knowingly and with deliberate intent by a skilled practitioner.
>
> I think it's reasonable to declare that, if you're monkeying around with
> dunder attributes
On Fri, Jun 8, 2012 at 1:45 AM, Daniel Urban wrote:
> On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan
> wrote:
>> -* If the metaclass hint refers to an instance of ``type``, then it is
>> +* If the metaclass hint refers to a subclass of ``type``, then it is
>> considered as a candidate metaclass
On Thu, 07 Jun 2012 17:39:54 -0400, Terry Reedy wrote:
> On 6/7/2012 4:54 PM, Yury Selivanov wrote:
>
> > I think we'll add a 'format' method to the Signature, that will work
> > like 'inspect.formatargspec'. 'Signature.__str__' will use it with
> > default parameters/formatters.
>
> Great. If
On 6/7/2012 4:54 PM, Yury Selivanov wrote:
I think we'll add a 'format' method to the Signature, that will work
like 'inspect.formatargspec'. 'Signature.__str__' will use it with
default parameters/formatters.
Great. If I don't like the default, I could customize.
I'm not sure how __repr__
The inaccuracies in the analogy are why this is in the tutorial, not the
language reference. All 3 else clauses are really their own thing. For if
statements, the full construct is "if/elif/else", for loops it is
"for/break/else" and "while/break/else" and for try statements it is
"try/except/else"
On 2012-06-07, at 5:39 PM, Terry Reedy wrote:
> On 6/7/2012 4:54 PM, Yury Selivanov wrote:
>
>> I think we'll add a 'format' method to the Signature, that will work
>> like 'inspect.formatargspec'. 'Signature.__str__' will use it with
>> default parameters/formatters.
>
> Great. If I don't like
On 2012-06-07, at 3:54 PM, Terry Reedy wrote:
> On 6/7/2012 10:41 AM, Yury Selivanov wrote:
>> Hello,
>>
>> The new revision of PEP 362 has been posted:
>> http://www.python.org/dev/peps/pep-0362/
>>
>> Thanks to Brett, Larry, Nick, and everybody else on python-dev
>> for your corrections/suggest
On Thu, Jun 7, 2012 at 9:47 PM, Terry Reedy wrote:
> On 6/7/2012 11:45 AM, Daniel Urban wrote:
>>
>> On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan
>> wrote:
>>>
>>> -* If the metaclass hint refers to an instance of ``type``, then it is
>>> +* If the metaclass hint refers to a subclass of ``type``,
On 6/7/2012 10:41 AM, Yury Selivanov wrote:
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Thanks to Brett, Larry, Nick, and everybody else on python-dev
for your corrections/suggestions.
Summary of changes:
1. We don't cache signatures in __signa
On 6/7/2012 8:42 AM, nick.coghlan wrote:
http://hg.python.org/cpython/rev/6e4ec47fba6a
changeset: 77369:6e4ec47fba6a
branch: 3.2
parent: 77363:aa9cfeea07ad
user:Nick Coghlan
date:Thu Jun 07 22:41:34 2012 +1000
summary:
Nudge readers towards a more accurate mental
On 06/07/2012 10:08 AM, Eric Snow wrote:
I'm missing something here. Can you give me an example of modifying an
existing function object such that its Signature would change? Decorators
implementing a closure with a different signature don't count--they return a
new function object.
I doubt t
Eric,
On 2012-06-07, at 12:54 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 11:10 AM, 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)
On Thu, Jun 7, 2012 at 8:12 AM, Larry Hastings wrote:
> On 06/06/2012 06: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 fun
On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov wrote:
> On 2012-06-06, at 1:02 PM, Eric Snow wrote:
>> I'm with Steven on this one. What's the benefit to storing the name
>> or qualname on the signature object? That ties the signature object
>> to a specific function. If you access the signatu
On Thu, Jun 7, 2012 at 2:08 PM, nick.coghlan wrote:
> -* If the metaclass hint refers to an instance of ``type``, then it is
> +* If the metaclass hint refers to a subclass of ``type``, then it is
> considered as a candidate metaclass along with the metaclasses of all of
> the parents of the c
On 2012-06-07, at 10:45 AM, R. David Murray wrote:
> On Thu, 07 Jun 2012 07:00:29 -0700, Larry Hastings wrote:
>> On 06/06/2012 11:56 PM, Nick Coghlan wrote:
>>> I'd say return a copy in the first case to be safe against accidental
>>> modification. If someone actually wants in-place modification,
On Thu, 07 Jun 2012 07:00:29 -0700, Larry Hastings wrote:
> On 06/06/2012 11:56 PM, Nick Coghlan wrote:
> > I'd say return a copy in the first case to be safe against accidental
> > modification. If someone actually wants in-place modification, they
> > can access __signature__ directly.
>
> I re
Hello,
The new revision of PEP 362 has been posted:
http://www.python.org/dev/peps/pep-0362/
Thanks to Brett, Larry, Nick, and everybody else on python-dev
for your corrections/suggestions.
Summary of changes:
1. We don't cache signatures in __signature__ attribute implicitly
2. signature() f
On 06/06/2012 06: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. Certainly that's
On 06/06/2012 11:56 PM, Nick Coghlan wrote:
I'd say return a copy in the first case to be safe against accidental
modification. If someone actually wants in-place modification, they
can access __signature__ directly.
I really don't understand this anxiety about mutable Signature objects.
Can
On Thu, Jun 7, 2012 at 11:28 PM, Michael Foord
wrote:
>> We'll probably extend it to copy __signature__ too; then
>> 'signature(decor(f))'
>> will be the same as 'signature(f)'.
>
> I don't think functools.wraps can copy the signature by default - it's not
> uncommon to have decorators that modi
Nick,
On 2012-06-07, at 2:56 AM, Nick Coghlan wrote:
> 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,
On 2012-06-07, at 9:28 AM, Michael Foord wrote:
> On 6 Jun 2012, at 18:28, Yury Selivanov wrote:
>> On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
>> Never copy attributes by hand, always use 'functools.wraps'. It copies
>> '__name__', '__qualname__', and bunch of other attributes to the decorat
On 6 Jun 2012, at 18:28, Yury Selivanov wrote:
> 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_
On Thu, 07 Jun 2012 11:08:09 +0100, Sam Partington
wrote:
> > On Jun 2, 2012 6:21 AM, "r.david.murray" wrote:
> >> + Â For example, ``'ab c\n\nde fg\rkl\r\n'.splitlines()`` returns
> >> + Â ``['ab c', '', 'de fg', 'kl']``, while the same call with
> >> ``splinelines(True)``
> >> + Â returns `
On Thu, Jun 7, 2012 at 10:04 PM, Steven D'Aprano wrote:
> Nick Coghlan wrote:
>> I've presented use cases for doing this already. Please stop calling me
>> stupid.
>
> I'm sorry Nick, I missed your email and my choice of words was poor. Please
> accept my apologies.
Thanks and no worries. I can d
Nick Coghlan wrote:
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 mi
> On Jun 2, 2012 6:21 AM, "r.david.murray" wrote:
>> + For example, ``'ab c\n\nde fg\rkl\r\n'.splitlines()`` returns
>> + ``['ab c', '', 'de fg', 'kl']``, while the same call with
>> ``splinelines(True)``
>> + returns ``['ab c\n', '\n, 'de fg\r', 'kl\r\n']``
Wouldn't that be better written
On Thu, Jun 7, 2012 at 12:32 PM, jdmorgan wrote:
> Hello,
>
> I am hoping that this list is a good place to ask this question.
Close, but not quite the right place. This is a list for the design
and development *of* Python itself, rather than a list for using
Python.
For this kind of question, y
Hello,
I am hoping that this list is a good place to ask this question.I am
still fairly new to python, but find it to be a great scripting
language.Here is my issue:
I am attempting to utilize a function to receive any sequence of letter
characters and return to me the next value in alphabe
39 matches
Mail list logo
