[Python-Dev] any tips on malloc debugging?

[Bill Janssen]

I've been expanding the SSL test suite, and found something like this
cropping up, not always, but maybe 30% of the time.  So I run it under
gdb, but the "szone_error" breakpoint never gets hit.  Any other
malloc debugging tips I should know about?

(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x900f2e56 
(gdb) (gdb) run ./Lib/test/regrtest.py -R :4: -u all test_ssl
Starting program: /local/python/trunk/src/python.exe ./Lib/test/regrtest.py -R 
:4: -u all test_ssl
test_ssl
[...]
python.exe(22696,0xa000d000) malloc: *** error for object 0x650800: double free
python.exe(22696,0xa000d000) malloc: *** set a breakpoint in szone_error to 
debug
test test_ssl failed -- Traceback (most recent call last):
  File "/local/python/trunk/src/Lib/test/test_ssl.py", line 304, in testSSL3
CERTFILE2, CERTFILE3)
  File "/local/python/trunk/src/Lib/test/test_ssl.py", line 203, in 
serverParamsTest
raise test_support.TestFailed("Unexpected SSL error:  " + str(x))
TestFailed: Unexpected SSL error:  (8, '_ssl.c:394: EOF occurred in violation 
of protocol')

1 test failed:
test_ssl
[23436 refs]

Program exited with code 01.
(gdb) 

Bill
___
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-archive.com

Re: [Python-Dev] any tips on malloc debugging?

[Guido van Rossum]

I think there's a way to enable heavier malloc debugging than the
normal --with-pydebug. You'll have to enable it manually by editing
Python.h I believe. Though it may already be on if you define
Py_DEBUG. (Is WITH_PYMALLOC always on?) Ther may also be a libmalloc
that enables heavier debugging; the malloc man page would have info.

On 9/7/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I've been expanding the SSL test suite, and found something like this
> cropping up, not always, but maybe 30% of the time.  So I run it under
> gdb, but the "szone_error" breakpoint never gets hit.  Any other
> malloc debugging tips I should know about?
>
> (gdb) info break
> Num Type   Disp Enb AddressWhat
> 1   breakpoint keep y   0x900f2e56 
> (gdb) (gdb) run ./Lib/test/regrtest.py -R :4: -u all test_ssl
> Starting program: /local/python/trunk/src/python.exe ./Lib/test/regrtest.py 
> -R :4: -u all test_ssl
> test_ssl
> [...]
> python.exe(22696,0xa000d000) malloc: *** error for object 0x650800: double 
> free
> python.exe(22696,0xa000d000) malloc: *** set a breakpoint in szone_error to 
> debug
> test test_ssl failed -- Traceback (most recent call last):
>   File "/local/python/trunk/src/Lib/test/test_ssl.py", line 304, in testSSL3
> CERTFILE2, CERTFILE3)
>   File "/local/python/trunk/src/Lib/test/test_ssl.py", line 203, in 
> serverParamsTest
> raise test_support.TestFailed("Unexpected SSL error:  " + str(x))
> TestFailed: Unexpected SSL error:  (8, '_ssl.c:394: EOF occurred in violation 
> of protocol')
>
> 1 test failed:
> test_ssl
> [23436 refs]
>
> Program exited with code 01.
> (gdb)
>
> Bill
> ___
> 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/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com

Re: [Python-Dev] any tips on malloc debugging?

[Martin v. Löwis]

> I've been expanding the SSL test suite, and found something like this
> cropping up, not always, but maybe 30% of the time.  So I run it under
> gdb, but the "szone_error" breakpoint never gets hit.  Any other
> malloc debugging tips I should know about?

Is this a --with-pydebug build? If not, it should be.

If that still does not give insights, I usually try valgrind
(although usually with little success).

Regards,
Martin
___
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-archive.com

[Python-Dev] PEP 362: Signature objects

[Jim Jewett]

Brett Cannon wrote:

> A Signature object has the following structure attributes:

> * name : str
> Name of the function.  This is not fully qualified because
> function objects for methods do not know the class they are
> contained within.  This makes functions and methods
> indistinguishable from one another when passed to decorators,
> preventing proper creation of a fully qualified name.

(1)  Would this change with the new static __class__ attribute used
for the new super?

(2)  What about functions without a name?  Do you want to say str or
NoneType, or is that assumed?

(3)  Is the Signature object live or frozen?  (name is writable ...
will the Signature object reflect the new name, or the name in use at
the time it was created?)

> * var_annotations: dict(str, object)
> Dict that contains the annotations for the variable parameters.
> The keys are of the variable parameter with values of the

Is there a special key for the "->" returns annotation, or is that
available as a separate property?

> The structure of the Parameter object is:

> * name : (str | tuple(str))
> The name of the parameter as a string if it is not a tuple.  If
> the argument is a tuple then a tuple of strings is used.

What is used for unnamed arguments (typically provided by C)?  I like
None, but I see the arguments for both "" and missing attribute.

> * position : int
> The position of the parameter within the signature of the
> function (zero-indexed).  For keyword-only parameters the position
> value is arbitrary while not conflicting with positional
> parameters.

Is this just a property/alias for signature.parameters.index(self) ?

What should a "parameter" object not associated with a specific
signature return?  -1, None, or missing attribute?

Is there a way to get the associated Signature, or is it "compiled
out" when the Signature and its child Parameters are first
constructed?  (I think the position property is the only attribute
that would use it, unless you want some of the other attributes --
like annotations -- to be live.)

...

I would also like to see a

 * value : object

attribute; this would be missing on most functions, but might be
filled in on a Signature representing a closure, or an execution
frame.


> When to construct the Signature object?
> ---

> The Signature object can either be created in an eager or lazy
> fashion.  In the eager situation, the object can be created during
> creation of the function object.

Since most code doesn't need it, I would expect it to be optimized out
at least as often as docstrings are.

>  In the lazy situation, one would
> pass a function object to a function and that would generate the
> Signature object and store it to ``__signature__`` if
> needed, and then return the value of ``__signature__``.

Why store it?  Do you expect many use cases to need the signature more
than once (but not to save it themselves)?

If there is a __signature__ attribute on a object, you have to specify
whether it can be replaced, which parts of it are writable, how that
will affect the function's own behavior, etc.  I also suspect it might
become a source of heisenbugs, like the "reference leaks" that were
really DUMMY items in a dict.

If the Signature is just a snapshot no longer attached to the original
function, then people won't expect changes to the Signature to affect
the callable.

> Should ``Signature.bind`` return Parameter objects as keys?

(see above) If a Signature is a snapshot (rather than a live part of
the function), then it might make more sense to just add a value
attribute to Parameter objects.

> Provide a mapping of parameter name to Parameter object?
> 

> While providing access to the parameters in order is handy, it might
> also be beneficial to provide a way to retrieve Parameter objects from
> a Signature object based on the parameter's name.  Which style of
> access (sequential/iteration or mapping) will influence how the
> parameters are stored internally and whether __getitem__ accepts
> strings or integers.

I think it should accept both.

What storage mechanism to use is an internal detail that should be
left to the implementation.  I wouldn't expect Signature inspection to
be inside a tight loop anyhow, unless it were part of a Generic
Function dispatch engine ... and those authors (just PJE?) can
optimize on what they actually need.

> Remove ``has_*`` attributes?
> 

> If an EAFP approach to the API is taken,

Please leave them; it is difficult to catch Exceptions in a list comprehension.

> Have ``var_args`` and ``_var_kw_args`` default to ``None``?

Makes sense to me, particularly since it should probably be consistent
with function name, and that should probably be None.


-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://m

Re: [Python-Dev] any tips on malloc debugging?

[Bill Janssen]

> Is this a --with-pydebug build? If not, it should be.

Yes.

> If that still does not give insights, I usually try valgrind
> (although usually with little success).

Actually, Google is your friend here.  The message in malloc is
misleading; set a breakpoint in malloc_printf instead.

Bill
___
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-archive.com

[Python-Dev] OpenSSL thread safety when reading files?

[Bill Janssen]

I'm seeing a number of malloc (actully, free) errors, now that I'm
pounding on the OpenSSL server/client setup with lots of server
threads and client threads.  They all look like either

(gdb) bt
#0  0x9010b807 in malloc_printf ()
#1  0x900058ad in szone_free ()
#2  0x90005588 in free ()
#3  0x9194e508 in CRYPTO_free ()
#4  0x91993e77 in ERR_clear_error ()
#5  0x919b1884 in PEM_X509_INFO_read_bio ()
#6  0x9197a692 in X509_load_cert_crl_file ()
#7  0x9197a80e in by_file_ctrl ()
#8  0x919d6e2e in X509_STORE_load_locations ()
[...]

or (much more frequently)

(gdb) bt
#0  0x9010b807 in malloc_printf ()
#1  0x900058ad in szone_free ()
#2  0x90005588 in free ()
#3  0x9194e508 in CRYPTO_free ()
#4  0x91993e77 in ERR_clear_error ()
#5  0x949fcf11 in SSL_CTX_use_certificate_chain_file ()
[...]

Always in ERR_clear_error(), always from some frame that's reading a
certificate file for some purpose.

If I disable Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS around the
places where the C code reads the certificate files, all these free
errors go away.

ERR_clear_error() is supposed to be thread-safe; it operates on a
per-thread error state structure (which I make sure is initialized in
my C code).  But it sure looks like the client and server threads are
both working with the same error state.

Bill
___
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-archive.com

Re: [Python-Dev] OpenSSL thread safety when reading files?

[Bill Janssen]

> I'm seeing a number of malloc (actully, free) errors, now that I'm
> pounding on the OpenSSL server/client setup with lots of server
> threads and client threads.  They all look like either

The issue seems to be that we assume OpenSSL is thread-safe (that is,
we call Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS), but the _ssl.c
code never did what was necessary to support that assumption.  See
http://www.openssl.org/docs/crypto/threads.html#DESCRIPTION.

My analysis is that we need to add lock and unlock functions to the
OpenSSL initialization code we currently use, which looks like this:

/* Init OpenSSL */
SSL_load_error_strings();
SSLeay_add_ssl_algorithms();

Or, just not allow threads, which seems wrong.

Bill
___
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-archive.com

Re: [Python-Dev] [PEPs] Email addresses in PEPs?

[Trent Mick]

David Goodger wrote:
> On 8/20/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> I believe email addresses are automatically obfuscated as part of the
>> HTML generation process, but one of the PEP editors can correct me if
>> I am wrong.
> 
> Yes, email addresses are obfuscated in PEPs.
> 
> For example, in PEPs 0 & 12, my address is encoded as
> "goodger at python.org" (the "@" is changed to " at " and
> further obfuscated from there).  More tricks could be played, but that
> would only decrease the usefulness of addresses for legitimate
> purposes.

If some would find it useful, here is a snippet of code that obfuscates 
email addresses for HTML as done by Markdown (a text-to-html markup 
translator). It randomly encodes each charater as a hex or decimal HTML 
entity (roughly 10% raw, 45% hex, 45% dec).

The email still appears normally in the browser, but is pretty obtuse 
when slicing and dicing the raw HTML.

Would others find this useful in pep2html.py?


---
from random import random

def _encode_email_address(self, addr):
 #  Input: an email address, e.g. "[EMAIL PROTECTED]"
 #
 #  Output: the email address as a mailto link, with each character
 #  of the address encoded as either a decimal or hex entity, in
 #  the hopes of foiling most address harvesting spam bots. E.g.:
 #
 #foo@exa
 #   mple.com
 #
 #  Based on a filter by Matthew Wickline, posted to the BBEdit-Talk
 #  mailing list: 
 chars = [_xml_encode_email_char_at_random(ch)
  for ch in "mailto:"; + addr]
 # Strip the mailto: from the visible part.
 addr = '%s' \
% (''.join(chars), ''.join(chars[7:]))
 return addr

def _xml_encode_email_char_at_random(ch):
 r = random()
 # Roughly 10% raw, 45% hex, 45% dec.
 # '@' *must* be encoded. I [John Gruber] insist.
 if r > 0.9 and ch != "@":
 return ch
 elif r < 0.45:
 # The [1:] is to drop leading '0': 0x63 -> x63
 return '&#%s;' % hex(ord(ch))[1:]
 else:
 return '&#%s;' % ord(ch)
---


-- 
Trent Mick
trentm at activestate.com
___
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-archive.com

Re: [Python-Dev] OpenSSL thread safety when reading files?

[Bill Janssen]

> My analysis is that we need to add lock and unlock functions to the
> OpenSSL initialization code we currently use

Yep, this seems to fix the problem.  I'm now able to re-enable
Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS, and still get a clean
run:

(gdb) run
Starting program: /local/python/trunk/src/python.exe ./Lib/test/regrtest.py -R 
:4: -u all test_ssl
test_ssl
/local/python/trunk/src/Lib/test/test_ssl.py:247: DeprecationWarning: 
socket.ssl() is deprecated.  Use ssl.sslsocket() instead.
  ssl_sock = socket.ssl(s)
beginning 9 repetitions
123456789
.
1 test OK.
[30009 refs]

Program exited normally.
(gdb)

Bill
___
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-archive.com

[Python-Dev] working with Python threads from C extension module?

[Bill Janssen]

Reading through the C API documentation, I find:

``This is done so that dynamically loaded extensions compiled with
thread support enabled can be loaded by an interpreter that was
compiled with disabled thread support.''

I've currently got the set-up-SSL-threading code in _ssl.c surrounded
by a "#ifdef HAVE_THREAD" bracket.  It sounds like that might not be
sufficient.  It sounds like I need a runtime test for thread
availability, instead, like this:

#ifdef HAVE_THREAD
if (PyEval_ThreadsInitialized())
_setup_ssl_threads();
#endif

Seem right?

So what happens when someone loads the _ssl module, initializes the
threads, and tries to use SSL?  It's going to start failing again.  I
think I need my own version of Py_BEGIN_ALLOW_THREADS and
Py_END_ALLOW_THREADS, don't I?  Which also checks to see if the SSL
threading support has been initialized, in addition to the Python
threading support.  Something like

#define SSL_ALLOW_THREADS {if (_ssl_locks != NULL) { Py_BEGIN_ALLOW_THREADS }}
#define SSL_DISALLOW_THREADS {if (_ssl_locks != NULL) { Py_BEGIN_ALLOW_THREADS 
}}

Any comments?

Bill
___
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-archive.com

Re: [Python-Dev] working with Python threads from C extension module?

[Bill Janssen]

> #define SSL_ALLOW_THREADS {if (_ssl_locks != NULL) { Py_BEGIN_ALLOW_THREADS }}
> #define SSL_DISALLOW_THREADS {if (_ssl_locks != NULL) { 
> Py_BEGIN_ALLOW_THREADS }}

I'd forgotten how convoluted Py_BEGIN_ALLOW_THREADS and
Py_END_ALLOW_THREADS were.  Anyone have any other suggestions about
how to do this?

Raise an error if loaded in a non-threaded environment, then used in a
threaded environment?  Dynamic initialization of threading?

Bill
___
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-archive.com

Re: [Python-Dev] working with Python threads from C extension module?

[Bill Janssen]

> So what happens when someone loads the _ssl module, initializes the
> threads, and tries to use SSL?  It's going to start failing again.  I

Which turns out to be exactly what test_ssl.py does.  I'm tempted
to have the _ssl module call PyEval_InitThreads().  Would that be kosher?

Bill
___
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-archive.com

Re: [Python-Dev] working with Python threads from C extension module?

[Guido van Rossum]

Well, one shouldn't be bothering with threads unless the user intends
to create threads. So I think it's not kosher. Once threads are
initialized, everything runs a tad slower because the GIL
manipulations actually cost time (even if there are no other threads).

On 9/7/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > So what happens when someone loads the _ssl module, initializes the
> > threads, and tries to use SSL?  It's going to start failing again.  I
>
> Which turns out to be exactly what test_ssl.py does.  I'm tempted
> to have the _ssl module call PyEval_InitThreads().  Would that be kosher?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com

Re: [Python-Dev] working with Python threads from C extension module?

[Bill Janssen]

> Well, one shouldn't be bothering with threads unless the user intends
> to create threads. So I think it's not kosher. Once threads are
> initialized, everything runs a tad slower because the GIL
> manipulations actually cost time (even if there are no other threads).

I think that doing it in _ssl.c might be OK; it would only happen when
the user loaded that extension module.  In any case, I'm going to do
it that way till we figure out a better solution.  The alternatives
right now are (1) let OpenSSL step all over itself (and potentially
other things), or (2) remove the Py_BEGIN_ALLOW_THREADS on SSL context
reads and writes.

> On 9/7/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > So what happens when someone loads the _ssl module, initializes the
> > > threads, and tries to use SSL?  It's going to start failing again.  I
> >
> > Which turns out to be exactly what test_ssl.py does.  I'm tempted
> > to have the _ssl module call PyEval_InitThreads().  Would that be kosher?

The problem is the sequencing of the loading of the extension module,
compared to when the user gets around to initializing threading.  If
we want to keep it kosher, we need a way to hook into
PyEval_InitThreads() so that it will call the thread initialization
routines of other dynamically loaded libraries that have already been
loaded.  Or a way to have Py_BEGIN_ALLOW_THREADS take into account that
there may be more than one thread-dependent thing to check on.

Bill
___
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-archive.com

Re: [Python-Dev] [PEPs] Email addresses in PEPs?

[skip]

Trent> If some would find it useful, here is a snippet of code that
Trent> obfuscates email addresses for HTML as done by Markdown (a
Trent> text-to-html markup translator). It randomly encodes each
Trent> charater as a hex or decimal HTML entity (roughly 10% raw, 45%
Trent> hex, 45% dec).

Aren't most spammers' scrapers going to be intelligent enough by now
(several years since they first arrived on the scene) to "see through" these
sorts of common obfuscations?

Skip
___
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-archive.com

Re: [Python-Dev] PEP 362: Signature objects

[Brett Cannon]

On 9/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > A Signature object has the following structure attributes:
>
> > * name : str
> > Name of the function.  This is not fully qualified because
> > function objects for methods do not know the class they are
> > contained within.  This makes functions and methods
> > indistinguishable from one another when passed to decorators,
> > preventing proper creation of a fully qualified name.
>
> (1)  Would this change with the new static __class__ attribute used
> for the new super?
>

I don't know enough about the super implementation to know.  If you
can figure out the class from the function object alone then sure,
this can change.

> (2)  What about functions without a name?  Do you want to say str or
> NoneType, or is that assumed?
>

What functions don't have a name?  Even lambdas have the name ''.

> (3)  Is the Signature object live or frozen?  (name is writable ...
> will the Signature object reflect the new name, or the name in use at
> the time it was created?)
>

They are currently one-time creation objects.  One could change it to
use properties and do the look up dynamically by caching the function
object.  But I currently have it implemented as all created in
__init__ and then just left alone.

> > * var_annotations: dict(str, object)
> > Dict that contains the annotations for the variable parameters.
> > The keys are of the variable parameter with values of the
>
> Is there a special key for the "->" returns annotation, or is that
> available as a separate property?
>

Oops, that didn't get into the PEP for some reason.  The Signature
object has ``has_annotation``/``annotation`` attributes for the
'return' annotation.


> > The structure of the Parameter object is:
>
> > * name : (str | tuple(str))
> > The name of the parameter as a string if it is not a tuple.  If
> > the argument is a tuple then a tuple of strings is used.
>
> What is used for unnamed arguments (typically provide by C)?  I like
> None, but I see the arguments for both "" and missing attribute.
>

It's open for debate.  I didn't even think about functions not having
__name__ set.  Basically whatever people want to go with for var_args
and var_kw_args.

> > * position : int
> > The position of the parameter within the signature of the
> > function (zero-indexed).  For keyword-only parameters the position
> > value is arbitrary while not conflicting with positional
> > parameters.
>
> Is this just a property/alias for signature.parameters.index(self) ?
>

Assuming that 'self' refers to some parameter, yes.

> What should a "parameter" object not associated with a specific
> signature return?  -1, None, or missing attribute?
>

This is not an option as it must be specified by the Parameter
constructor.  A Parameter object should not exist without belonging to
a Signature object.  That's why neither Signature nor Parameter have
their constructors specified; the signature() function is the only way
you should cause the construction of either object.

> Is there a way to get the associated Signature, or is it "compiled
> out" when the Signature and its child Parameters are first
> constructed?  (I think the position property is the only attribute
> that would use it, unless you want some of the other attributes --
> like annotations -- to be live.)

There is currently no way to work backwards from a Parameter object to
its parent Signature.  It could be added if people wanted.

>
> ...
>
> I would also like to see a
>
>  * value : object
>
> attribute; this would be missing on most functions, but might be
> filled in on a Signature representing a closure, or an execution
> frame.

What for?  How does either have bearing on the call signature of a function?

>
>
> > When to construct the Signature object?
> > ---
>
> > The Signature object can either be created in an eager or lazy
> > fashion.  In the eager situation, the object can be created during
> > creation of the function object.
>
> Since most code doesn't need it, I would expect it to be optimized out
> at least as often as docstrings are.
>
> >  In the lazy situation, one would
> > pass a function object to a function and that would generate the
> > Signature object and store it to ``__signature__`` if
> > needed, and then return the value of ``__signature__``.
>
> Why store it?  Do you expect many use cases to need the signature more
> than once (but not to save it themselves)?

Because you can use these with decorators to allow introspection redirection::

 def dec(fxn):
   def inner(*args, **kwargs):
   return fxn(*args, **kwargs)
   sig = signature(fxn)
   inner.__signature__ = sig
   return inner

>
> If there is a __signature__ attribute on a object, you have to specify
> whether it can be replaced,

It can.

> which parts of it are writable,

Any of it.

> how that
> will affect the function's own behavior, etc.

It won't.

>  I a

Re: [Python-Dev] PEP 362: Signature objects

[Guido van Rossum]

On 9/7/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 9/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > A Signature object has the following structure attributes:
> >
> > > * name : str
> > > Name of the function.  This is not fully qualified because
> > > function objects for methods do not know the class they are
> > > contained within.  This makes functions and methods
> > > indistinguishable from one another when passed to decorators,
> > > preventing proper creation of a fully qualified name.
> >
> > (1)  Would this change with the new static __class__ attribute used
> > for the new super?
>
> I don't know enough about the super implementation to know.  If you
> can figure out the class from the function object alone then sure,
> this can change.

I don't think it'll work -- the __class__ variable is only available
*within* the function, not when one is introspecting the function
object. Also, it is only available for functions that reference
'super' (or __class__ directly). As __class__ is passed into the
function call as a "cell" variable (like references to variables from
outer scopes), its mere presense slows down the call somewhat, hence
it is only present when used. (BTW, it is not an attribute.)

BTW there's a good reason why functions don't have easier access to
the class in which they are defined: functions can easily be moved or
shared between classes. The __class__ variable only records the class
inside which the function is defined lexically, if any.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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-archive.com