Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets

2013-07-07 Thread Charles-François Natali 
2013/7/7 Cameron Simpson :
> On 06Jul2013 11:23, Charles-François Natali  wrote:
> | > I've read your "Rejected Alternatives" more closely and Ulrich
> | > Drepper's article, though I think the article also supports adding
> | > a blocking (default True) parameter to open() and os.open(). If you
> | > try to change that default on a platform where it doesn't work, an
> | > exception should be raised.
> |
> | Contrarily to close-on-exec, non-blocking only applies to a limited
> | type of files (e.g. it doesn't work for regular files, which represent
> | 90% of open() use cases).
>
> sockets, pipes, serial devices, ...

How do you use open() on a socket (which are already covered by
socket(blocking=...)? Also, I said *regular files* - for which
O_NONBLOCK doesn't make sense - represent 90% of io.open() use cases,
and stand by this claim. Nothing prevents you from setting the FD
non-blocking manually.

> And you can set it on anything. Just because some things don't block
> anyway isn't really a counter argument.

Well, it complicates the signature and implementation.
If we go the same way, why stop there and not expose O_DSYNC, O_SYNC,
O_DIRECT...

When using a high-level API like io.open(), I think we should only
expose portable flags, which are supported both on all operating
systems (like the 'x' O_EXCL flag added in 3.3) and file types.

If you want precise control over the open() sementics, os.open() is
the way to go (that's also the rationale behind io.open() opener
argument, see http://bugs.python.org/issue12105)

cf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 445

2013-07-07 Thread Antonio Cavallo 
Yes that is indeed a great news. 

Having to debug some binary only extension modules that will make my (rather 
selfish) life so much easier ;)

Thanks


On 7 Jul 2013, at 00:04, Victor Stinner  wrote:

> 2013/7/6 Antonio Cavallo :
>> Could that remove the need for the --with-pydebug flag?
> 
> With the PEP 445, you still have to recompile Python with
> --with-debug, but you don't have to recompile Python extensions
> anymore. Debug checks on memory allocators are now implemented as
> hooks, instead of using C macros.
> 
> I see this as an improvment ;-)
> 
> Victor

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rough idea for adding introspection information for builtins

2013-07-07 Thread Larry Hastings 



On 07/07/2013 07:19 AM, Ronald Oussoren wrote:
Not entirely on topic, but close enough: pydoc currently doesn't use 
the __signature__ information at all. Adding such support would be 
easy enough, see #17053 for an implementation ;-) 


True, it doesn't use inspect.signature, it uses inspect.getfullargspec.  
Since I don't propose modifying inspect.getfullargspec to add the 
optional parameter group information, 17053 or something like it would 
have to happen.



On 07/07/2013 07:25 AM, R. David Murray wrote:

Sorry to make your life more complicated, but unless I'm misunderstanding
something, issue 18220 (http://bugs.python.org/issue18220) throws another
monkey-wrench in to this.  If I'm understanding this discussion correctly,
that example:

 islice(stop)
 islice(start, stop [, step])

requires the multiple-signature approach.

Note also that the python3 documentation has moved away from the []
notation wherever possible.


It depends on what problem you're addressing.  In terms of the Argument 
Clinic DSL, and in terms of the static introspection information stored 
for builtins, someone (Nick?) suggested a refinement to the semantics: 
in the face of ambiguity, prefer the leftmost group(s) first.  That 
means that range() and islice() could be specified as follows:


   range([start,] stop, [step])


In terms of the documentation, it might be better to preserve the 
multiple-lines approach, as perhaps that's more obvious to the reader.  
On the other hand: in Python 3, help(itertools.islice) uses solely the 
optional group syntax, on one line.



On 07/07/2013 07:25 AM, Ronald Oussoren wrote:

Signature objects use a name in angled brackets to indicate that a parameter is positional only, for 
example "input()". That might be an alternative to adding a "/" in the 
argument list in pydoc's output.


I wasn't aware that Signature objects currently had any support 
whatsoever for positional-only parameters.  Yes, in theory they do, but 
in practice they have never seen one, because positional-only parameters 
only occur in builtins and Signature objects have no metadata for 
builtins.  (The very problem Argument Clinic eventually hopes to solve!)


Can you cite an example of this, so I may examine it?


//arry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rough idea for adding introspection information for builtins

2013-07-07 Thread Ronald Oussoren 

On 7 Jul, 2013, at 13:35, Larry Hastings  wrote:
> 
> On 07/07/2013 07:25 AM, Ronald Oussoren wrote:
>> Signature objects use a name in angled brackets to indicate that a parameter 
>> is positional only, for example "input()". That might be an 
>> alternative to adding a "/" in the argument list in pydoc's output.
>> 
> 
> I wasn't aware that Signature objects currently had any support whatsoever 
> for positional-only parameters.  Yes, in theory they do, but in practice they 
> have never seen one, because positional-only parameters only occur in 
> builtins and Signature objects have no metadata for builtins.  (The very 
> problem Argument Clinic eventually hopes to solve!)
> 
> Can you cite an example of this, so I may examine it?

I have a branch of PyObjC that uses this: 
. That 
branch isn't quite stable yet, but does add a __signature__ slot to 
objc.selector and objc.function (basicly methods of Cocoa classes and 
automaticly wrapped global functions), both of which only have positional-only 
arguments. With the patch for pydoc/inspect I mentioned earlier I can then 
generate somewhat useful documentation for Cocoa classes using pydoc.

A word of warning though: the PyObjC source code isn't the most approachable, 
the code that generates the Signature object is actually in python 
(callable_signature in pyobjc-core/Lib/objc/_callable_docstr.py)

Ronald

> 
> 
> /arry

___
Python-Dev mailing list
[email protected]
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 446: Add new parameters to configure the inherance of files and for non-blocking sockets

2013-07-07 Thread Victor Stinner 
2013/7/7 Charles-François Natali :
> 2013/7/7 Cameron Simpson :
>> On 06Jul2013 11:23, Charles-François Natali  wrote:
>> | > I've read your "Rejected Alternatives" more closely and Ulrich
>> | > Drepper's article, though I think the article also supports adding
>> | > a blocking (default True) parameter to open() and os.open(). If you
>> | > try to change that default on a platform where it doesn't work, an
>> | > exception should be raised.
>> |
>> | Contrarily to close-on-exec, non-blocking only applies to a limited
>> | type of files (e.g. it doesn't work for regular files, which represent
>> | 90% of open() use cases).
>>
>> sockets, pipes, serial devices, ...
>
> How do you use open() on a socket (which are already covered by
> socket(blocking=...)? Also, I said *regular files* - for which
> O_NONBLOCK doesn't make sense - represent 90% of io.open() use cases,
> and stand by this claim. Nothing prevents you from setting the FD
> non-blocking manually.

Ok, I think that the best consensus here is to add a new
os.set_blocking() function. The function would not be available on
Windows, but should be available on all UNIX platforms. The advantage
of os.set_blocking() over fcntl is that it may be implemented using
ioctl (FIONBIO) to use 1 syscall instead of 2. It is also easier to
remember calling "os.set_blocking(fd, True)" instead of
"fcntl.fcntl(fd, fcntl.F_SETFL, fcntl.fcntl(fcntl.F_GETFL, fd) |
os.O_NONBLOCK)".

See the diff:
http://hg.python.org/peps/rev/ce61588d244c

@Charles-François and Cameron: Do you prefer to new version of the PEP?
http://www.python.org/dev/peps/pep-0446/
(will be updated in a few minutes)

I'm not sure that many people are concerned by the number of syscalls,
but there is at least Peter Portante who opened a thread
"Modules/socketmodule.c: avoiding second fcntl() call worth the
effort?" on this mailing list, last January:
http://mail.python.org/pipermail/python-dev/2013-January/123661.html
"OpenStack Swift using the Eventlet module, which sets the accepted socket
non-blocking, resulting in twice the number of fcntl() calls. Not a killer
on performance, but it seems simple enough to save a system call here."

(This specific issue will be solved by the new blocking parameter
added to socket constructor ;-))

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 445

2013-07-07 Thread Victor Stinner 
2013/7/6 Antoine Pitrou :
> I'm accepting PEP 445 (A C API to customize memory allocators) by
> Victor.  There is probably some grammar to correct here and there
> (neither Victor nor I are native English speakers), but I don't want
> this to hold back acceptance.  The PEP is an obvious improvement in
> flexibility for everyone embedding Python in some external application,
> or even recompiling their own Python runtime for specific uses.
>
> The implementation is tracked in http://bugs.python.org/issue3329

Thanks Antoine for you review :-)

I pushed the implementation of the PEP, splitted in different
changesets: new functions and then changes to use these new functions.

You can now play with the new hooks to hack your own memory debug tool
for Python 3.4! You can easily implement your own tool in Python! (if
you hook PYMEM_DOMAIN_MEM and PYMEM_DOMAIN_OBJ, but not
PYMEM_DOMAIN_RAW) I will share with you my experiment of these new
APIs.

I'm preparing a new version of pytracemalloc to adapt it to the API of
the PEP 445.
https://pypi.python.org/pypi/pytracemalloc

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hooking into super() attribute resolution

2013-07-07 Thread Steve Dower 
Could the same result be achieved by hooking the MRO that super uses and 
returning a list of proxy objects? And then wouldn't you only really need a 
__getattribute__ that doesn't recurse (__getlocalattribute__)? The end result 
may be conceptually simpler, but you've thought through the edge cases better 
than I have.

(Apologies for the HTML top-post)

Sent from my Windows Phone

From: Ronald Oussoren
Sent: ‎7/‎6/‎2013 0:47
To: Ronald Oussoren
Cc: [email protected] Dev
Subject: Re: [Python-Dev] Hooking into super() attribute resolution

I've updated the implementation in issue 18181 
 while adding some tests, and have updated 
the proposal as well.

The proposal has some open issues at the moment, most important of which is the 
actual signature for the new special method; in particular I haven't been able 
to decide if this should be an instance-, class- or static method. It is a 
static method in the proposal and prototype, but I'm not convinced that that is 
the right solution.

Ronald




PEP: TODO
Title: Hooking into super attribute resolution
Version: $Revision$
Last-Modified: $Date$
Author: Ronald Oussoren 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Jun-2013
Post-History: 2-Jul-2013, ?


Abstract


In current python releases the attribute resolution of the `super class`_
peeks in the ``__dict__`` attribute of classes on the MRO to look
for attributes. This PEP introduces a hook that classes can use
to override that behavior for specific classes.


Rationale
=

Peeking in the class ``__dict__`` works for regular classes, but can
cause problems when a class dynamicly looks up attributes in a
``__getattribute__`` method.

The new hook makes it possible to introduce the same customization for
attribute lookup through the `super class`_.


The superclass attribute lookup hook


In C code
-

A new slot ``tp_getattro_super`` is added to the ``PyTypeObject`` struct. The
``tp_getattro`` slot for super will call this slot when it is not ``NULL``,
and will raise an exception when it is not set (which shouldn't happen because
the method is implemented for :class:`object`).

The slot has the following prototype::

PyObject* (*getattrosuperfunc)(PyTypeObject* cls, PyObject* name,
PyObject* object, PyObject* owner);

The function should perform attribute lookup on *object* for *name*, but only
looking in type *tp* (which will be one of the types on the MRO for *self*)
and without looking in the instance *__dict__*.

The function returns ``NULL`` when the attribute cannot be found, and raises and
exception. Exception other than ``AttributeError`` will cause failure of super's
attribute resolution.

The implementation of the slot for the :class:`object` type is
``PyObject_GenericGetAttrSuper``, which peeks in the ``tp_dict`` for *cls*.

Note that *owner* and *object* will be the same object when using a
class-mode super.


In Python code
--

A Python class can contain a definition for a static method
``__getattribute_super__`` with the following prototype::

   def __getattribute_super__(cls, name, object, owner): pass

The method should perform attribute lookup for *name* on instance *self* while
only looking at *cls* (it should not look in super classes or the instance
*__dict__*

XXX: I haven't got a clue at the moment if the method should be an
instance-, class- or staticmethod. The prototype uses a staticmethod.

XXX: My prototype automagicly makes this a static method, just like __new__ is
made into a static method. That's more convenient, but also (too?) magical.

XXX: Should this raise AttributeError or return a magic value to signal that
an attribute cannot be found (such as NotImplemented, used in the comparison
operators)? I'm currently using an exception, a magical return value would
be slightly more efficient because the exception machinery is not invoked.


Alternative proposals
-

Reuse ``tp_getattro``
.

It would be nice to avoid adding a new slot, thus keeping the API simpler and
easier to understand.  A comment on `Issue 18181`_ asked about reusing the
``tp_getattro`` slot, that is super could call the ``tp_getattro`` slot of all
methods along the MRO.

AFAIK that won't work because ``tp_getattro`` will look in the instance
``__dict__`` before it tries to resolve attributes using classes in the MRO.
This would mean that using ``tp_getattro`` instead of peeking the class
dictionaries changes the semantics of the `super class`_.


Open Issues
===

* The names of the new slot and magic method are far from settled.

* I'm not too happy with the prototype for the new hook.

* Should ``__getattribute_super__`` be a class method instead?

  -> Yes? The method looks up a named attribu

Re: [Python-Dev] Rough idea for adding introspection information for builtins

2013-07-07 Thread Larry Hastings 

On 07/07/2013 01:42 PM, Ronald Oussoren wrote:

On 7 Jul, 2013, at 13:35, Larry Hastings  wrote:

On 07/07/2013 07:25 AM, Ronald Oussoren wrote:

Signature objects use a name in angled brackets to indicate that a parameter is positional only, for 
example "input()". That might be an alternative to adding a "/" in the 
argument list in pydoc's output.


I wasn't aware that Signature objects currently had any support whatsoever for 
positional-only parameters.  Yes, in theory they do, but in practice they have 
never seen one, because positional-only parameters only occur in builtins and 
Signature objects have no metadata for builtins.  (The very problem Argument 
Clinic eventually hopes to solve!)

Can you cite an example of this, so I may examine it?

I have a branch of PyObjC that uses this: 
. That 
branch isn't quite stable yet, but does add a __signature__ slot to objc.selector and 
objc.function (basicly methods of Cocoa classes and automaticly wrapped global 
functions), both of which only have positional-only arguments. With the patch for 
pydoc/inspect I mentioned earlier I can then generate somewhat useful documentation 
for Cocoa classes using pydoc.

A word of warning though: the PyObjC source code isn't the most approachable, 
the code that generates the Signature object is actually in python 
(callable_signature in pyobjc-core/Lib/objc/_callable_docstr.py)


Ah.  In other words, you have proposed it yourself in an external 
project.  I thought you were saying this was something Python itself 
already did.


In that case, I think I will stick with Guido's suggested syntax. 
Consider window.border in the curses module: eight positional-only 
parameters, each in its own optional parameter group.  Adding sixteen 
angle-brackets to that already unreadable morass will make it even 
worse.  But with "/" we add only a single extra character, in an 
easy-to-find place (the end).



//arry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rough idea for adding introspection information for builtins

2013-07-07 Thread Ronald Oussoren 

On 7 Jul, 2013, at 19:20, Larry Hastings  wrote:

> On 07/07/2013 01:42 PM, Ronald Oussoren wrote:
>> On 7 Jul, 2013, at 13:35, Larry Hastings 
>>  wrote:
>> 
>>> On 07/07/2013 07:25 AM, Ronald Oussoren wrote:
>>> 
 Signature objects use a name in angled brackets to indicate that a 
 parameter is positional only, for example "input()". That might be 
 an alternative to adding a "/" in the argument list in pydoc's output.
 
 
>>> I wasn't aware that Signature objects currently had any support whatsoever 
>>> for positional-only parameters.  Yes, in theory they do, but in practice 
>>> they have never seen one, because positional-only parameters only occur in 
>>> builtins and Signature objects have no metadata for builtins.  (The very 
>>> problem Argument Clinic eventually hopes to solve!)
>>> 
>>> Can you cite an example of this, so I may examine it?
>>> 
>> I have a branch of PyObjC that uses this: 
>> 
>> . That branch isn't quite stable yet, but does add a __signature__ slot to 
>> objc.selector and objc.function (basicly methods of Cocoa classes and 
>> automaticly wrapped global functions), both of which only have 
>> positional-only arguments. With the patch for pydoc/inspect I mentioned 
>> earlier I can then generate somewhat useful documentation for Cocoa classes 
>> using pydoc.
>> 
>> A word of warning though: the PyObjC source code isn't the most 
>> approachable, the code that generates the Signature object is actually in 
>> python (callable_signature in pyobjc-core/Lib/objc/_callable_docstr.py)
>> 
> 
> Ah.  In other words, you have proposed it yourself in an external project.  I 
> thought you were saying this was something Python itself already did.

I wasn't clear enough in what I wrote.  The stdlib contains support for 
positional-only arguments in Signature objects (see Lib/inspect.py, line 1472, 
which says "_POSITIONAL_ONLY= _ParameterKind(0, 
name='POSITIONAL_ONLY')".  The __str__ of Parameter amongst other says:

if kind == _POSITIONAL_ONLY:
if formatted is None:
formatted = ''
formatted = '<{}>'.format(formatted)

That is, it adds angled brackets around the names of positional-only 
parameters.  I pointed to PyObjC as an example of code that actually creates 
Signature objects with positional-only arguments, as far as I know the stdlib 
never does this because the stdlib can only create signatures for plain python 
functions and those cannot have such arguments.

> In that case, I think I will stick with Guido's suggested syntax.  Consider 
> window.border in the curses module: eight positional-only parameters, each in 
> its own optional parameter group.  Adding sixteen angle-brackets to that 
> already unreadable morass will make it even worse.  But with "/" we add only 
> a single extra character, in an easy-to-find place (the end).

Using Guido's suggestion is fine by me, I agree that there is a clear risk of 
angle-bracket overload for functions with a lot of arguments. I do think that 
the __str__ for Signatures should be changed to match the convention. 

And to be clear: I'm looking forward to having Argument Clinic and 
__signature__ objects on built-in functions, "funcname(...)" in the output 
pydoc is somewhat annoying, especially for extensions where the author hasn't 
bothered to provide a docstring. That's one reason I wrote the __signature__ 
support in PyObjC in the first place (and the patch for pydoc to actually use 
the signature information)

Ronald

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hooking into super() attribute resolution

2013-07-07 Thread Ronald Oussoren 

On 7 Jul, 2013, at 17:17, Steve Dower  wrote:

> Could the same result be achieved by hooking the MRO that super uses and 
> returning a list of proxy objects?

What is the advantage over adding a hook to the class itself? That seems to be 
the right place to add such a hook, super already looks in the classes along 
the MRO and my proposal would add a formal interface for that instead of having 
super peek into the class __dict__. I have thought of using a custom mapping 
object for the tp_dict slot to intercept this, but that won't work because 
super assumes that tp_dict is an actual PyDictObject (and likely other parts of 
the interpreter do so as well).


> And then wouldn't you only really need a __getattribute__ that doesn't 
> recurse (__getlocalattribute__)? The end result may be conceptually simpler, 
> but you've thought through the edge cases better than I have. 

__getattribute_super__ already is a kind of __getlocalattribute__, the primairy 
difference being __getattribute_super__ is a staticmethod instead of an 
instance method. To be honest I'm not sure if a staticmethod is the right 
solution, I'm having a hard time to determine if this should be a class, 
instance or static method. 

Currently super(StartClass, x) basicly does (assuming x is an instance method):


def __getattribute__(self, name):
mro = type(x).mro()
idx = mro.index(StartClass)
while idx < len(mro):
   dct = mro[idx].__dict__
   try:
  result = dct[name]
  # deal with descriptors here
  return result

   except KeyError:
   continue
return object.__getattribute__(self, name)

With my proposal 'dct' would no longer be needed and 'result = dct[name]' would 
be 'mro[idx].__getattribute_super__(mro[idx], name, x, StartClass)' (I may have 
the last argument for the call to __getattribute_super__ wrong, but that's the 
idea). Given that the first argument of __get...super__ is the same as the 
object the method get getattr-ed from I guess the method should be a 
classmethod instead of an staticmethod. Changing that would be easy enough.

I'm still interested in feedback on the basic idea, I'd love to here that my 
proposal isn't necessary because there is already a way to get the behavior I'm 
looking for although that's nog going to happen ;-).

Ronald


> 
> (Apologies for the HTML top-post)

I don't mind.

PS. Does anyone know if the pep editors are away (conferences, holidays, ...)? 
I could just check in my proposal in the peps repository, but as this is my 
first PEP I'd prefer to follow the documented procedure and have someone that 
knows what he's doing look at the metadata before checking in.

> 
> Sent from my Windows Phone
> From: Ronald Oussoren
> Sent: ‎7/‎6/‎2013 0:47
> To: Ronald Oussoren
> Cc: [email protected] Dev
> Subject: Re: [Python-Dev] Hooking into super() attribute resolution
> 
> I've updated the implementation in issue 18181 
>  while adding some tests, and have updated 
> the proposal as well. 
> 
> The proposal has some open issues at the moment, most important of which is 
> the actual signature for the new special method; in particular I haven't been 
> able to decide if this should be an instance-, class- or static method. It is 
> a static method in the proposal and prototype, but I'm not convinced that 
> that is the right solution.
> 
> Ronald
> 
> 
> 
> 
> PEP: TODO
> Title: Hooking into super attribute resolution
> Version: $Revision$
> Last-Modified: $Date$
> Author: Ronald Oussoren 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 12-Jun-2013
> Post-History: 2-Jul-2013, ?
> 
> 
> Abstract
> 
> 
> In current python releases the attribute resolution of the `super class`_
> peeks in the ``__dict__`` attribute of classes on the MRO to look
> for attributes. This PEP introduces a hook that classes can use
> to override that behavior for specific classes.
> 
> 
> Rationale
> =
> 
> Peeking in the class ``__dict__`` works for regular classes, but can
> cause problems when a class dynamicly looks up attributes in a
> ``__getattribute__`` method.
> 
> The new hook makes it possible to introduce the same customization for
> attribute lookup through the `super class`_.
> 
> 
> The superclass attribute lookup hook
> 
> 
> In C code
> -
> 
> A new slot ``tp_getattro_super`` is added to the ``PyTypeObject`` struct. The
> ``tp_getattro`` slot for super will call this slot when it is not ``NULL``,
> and will raise an exception when it is not set (which shouldn't happen because
> the method is implemented for :class:`object`).
> 
> The slot has the following prototype::
> 
> PyObject* (*getattrosuperfunc)(PyTypeObject* cls, PyObject* name,
> PyObject* object, PyObject* owner);
> 
> The function should perform attribute lookup on *object* for *name*, but only
> looking in type *tp* (which will be one of the ty

Re: [Python-Dev] Rough idea for adding introspection information for builtins

2013-07-07 Thread Terry Reedy 

On 7/7/2013 7:35 AM, Larry Hastings wrote:



On 07/07/2013 07:19 AM, Ronald Oussoren wrote:

Not entirely on topic, but close enough: pydoc currently doesn't use
the __signature__ information at all. Adding such support would be
easy enough, see #17053 for an implementation ;-)


True, it doesn't use inspect.signature, it uses inspect.getfullargspec.


This is currently true of Idle calltips. But with 3.2 out of the way, I 
plan to switch sometime and not worry about 2.7.



Since I don't propose modifying inspect.getfullargspec to add the
optional parameter group information, 17053 or something like it would
have to happen.


On 07/07/2013 07:25 AM, R. David Murray wrote:

Sorry to make your life more complicated, but unless I'm misunderstanding
something, issue 18220 (http://bugs.python.org/issue18220) throws another
monkey-wrench in to this.  If I'm understanding this discussion correctly,
that example:

 islice(stop)
 islice(start, stop [, step])

requires the multiple-signature approach.

Note also that the python3 documentation has moved away from the []
notation wherever possible.


It depends on what problem you're addressing.  In terms of the Argument
Clinic DSL, and in terms of the static introspection information stored
for builtins, someone (Nick?) suggested a refinement to the semantics:
in the face of ambiguity, prefer the leftmost group(s) first.  That
means that range() and islice() could be specified as follows:

range([start,] stop, [step])


This is how it was until last September. See #15831, which also changed 
max, min, and slice entries to use two lines. The multiple lines for 
bytes and str signatures in the docstrings were another issue.



In terms of the documentation, it might be better to preserve the
multiple-lines approach, as perhaps that's more obvious to the reader.


It seems that signatures that do not match what one can do with a def 
statement are confusing. The header line for the Python version of the 
above is

def range(start_or_stop, stop=None, step=1):
My suggestion to use this, which is the actual signature, was rejected 
in favor of using two lines. This is fine with me, as it documents the 
calling signatures rather than the hybrid definition signature used to 
implement the call signatures.



On the other hand: in Python 3, help(itertools.islice) uses solely the
optional group syntax, on one line.


Because it has not yet been changed ;-).


On 07/07/2013 07:25 AM, Ronald Oussoren wrote:

Signature objects use a name in angled brackets to indicate that a parameter is positional only, for 
example "input()". That might be an alternative to adding a "/" in the 
argument list in pydoc's output.


I wasn't aware that Signature objects currently had any support
whatsoever for positional-only parameters.  Yes, in theory they do, but
in practice they have never seen one, because positional-only parameters
only occur in builtins and Signature objects have no metadata for
builtins.  (The very problem Argument Clinic eventually hopes to solve!)


I look forward to the day when accurate (auto-generated) call data is 
also available for C-coded functions.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com