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
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
> 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
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 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
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 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 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
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 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
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 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
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 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
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, 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 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 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
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 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
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 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 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 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 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
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 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__
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 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 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
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 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
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 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
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
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
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
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 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(
39 matches
Mail list logo
