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

[Ronald Oussoren]

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 attribute name of an object in
 a specific class. Is also likely needed to deal with @classmethod
 and super(Class, Class)

* Should ``__getattribute_super__`` be defined on object?

  -> Yes: makes it easier to delegate to the default implementation

* This doesn't necessarily work for class method super class
   (e.g. super(object, object))...


References
==

* `Issue 18181`_ contains a prototype implementation


Copyright
=

This document has been placed in the public domain.

.. _`Issue 18181`: http://bugs.python.org/issue18181

.. _`super class`: 
http://docs.python.org/3/library/functions.html?highlight=super#super

_

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

[Charles-François Natali]

> 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).

Also, one of the main reasons for exposing close-on-exec in
open()/socket() etc is to make it possible to create file descriptors
with the close-on-exec flag atomically, to prevent unwanted FD
inheritance especially in multi-threaded code. And that's not
necessary for the non-blocking parameter.

Those are two reasons why IMO "blocking" doesn't have to receive the
same treatment as close-on-exec (there's also the Windows issue but
I'm not familiar with it).

cf
___
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] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

[R. David Murray]

On Sat, 06 Jul 2013 10:25:19 +0200, ronald.oussoren 
 wrote:
> http://hg.python.org/cpython/rev/a2c2ffa1a41c
> changeset:   84453:a2c2ffa1a41c
> branch:  3.3
> parent:  84449:df79735b21c1
> user:Ronald Oussoren 
> date:Sat Jul 06 10:23:59 2013 +0200
> summary:
>   Issue #17860: explicitly mention that std* streams are opened in binary 
> mode by default.
> 
> The documentation does mention that the streams are opened in text mode
> when univeral_newlines is true, but not that that they are opened in
> binary mode when that argument is false and that seems to confuse at
> least some users.
> 
> files:
>   Doc/library/subprocess.rst |  6 --
>   1 files changed, 4 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst
> --- a/Doc/library/subprocess.rst
> +++ b/Doc/library/subprocess.rst
> @@ -293,7 +293,8 @@
> If *universal_newlines* is ``True``, the file objects *stdin*, *stdout* 
> and
> *stderr* will be opened as text streams in :term:`universal newlines` mode
> using the encoding returned by :func:`locale.getpreferredencoding(False)
> -   `.  For *stdin*, line ending characters
> +   `, otherwise these streams will be opened
> +   as binary streams.  For *stdin*, line ending characters
> ``'\n'`` in the input will be converted to the default line separator
> :data:`os.linesep`.  For *stdout* and *stderr*, all line endings in the
> output will be converted to ``'\n'``.  For more information see the

IMO, either the default should be mentioned first, or the default
should be mentioned in a parenthetical.  Otherwise it sounds like
newline translation is being done in both modes.  Logically that makes
no sense, so the above construction will likely lead to, at a minimum,
an interruption in the flow for the reader, and at worse even more
confusion than not mentioning it at all.

--David
___
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 446: Add new parameters to configure the inherance of files and for non-blocking sockets

[Victor Stinner]

2013/7/6 Charles-François Natali :
>> 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).

What do you mean by "does not work"? On Linux, O_NONBLOCK flag can be
set on regular files, sockets, pipes, etc.

Example with a regular file on Linux 3.9:

smithers$ python3
Python 3.3.0 (default, Sep 29 2012, 22:07:38)
>>> from fcntl import *
>>> import os
>>> f=open("/etc/issue", "rb")
>>> fd=f.fileno()
>>> flags=fcntl(fd, F_GETFL)
>>> fcntl(fd, F_SETFL, flags|os.O_NONBLOCK)
0
>>> fcntl(fd, F_GETFL) & os.O_NONBLOCK
2048
>>> f.read(10)
b'Fedora rel'

For example, asyncore.file_dispatcher() uses fcntl to set the
O_NONBLOCK flag. (The asyncore module is probably the only module of
the stdlib which would benefit of a new os.set_blocking() function.)

> Also, one of the main reasons for exposing close-on-exec in
> open()/socket() etc is to make it possible to create file descriptors
> with the close-on-exec flag atomically, to prevent unwanted FD
> inheritance especially in multi-threaded code. And that's not
> necessary for the non-blocking parameter.

In the review of PEP 433 on this mailing list, Martin von Loewis said
that the PEP does guarantee the atomicity. The implementation of the
PEP falls back on ioctl or fcntl to set the flag on old Linux versions
(or if the OS does not support setting O_CLOEXEC flag when creating a
file descriptor). The GIL is released during system calls, so another
thread can call execv().

That's why I mentionned explicitly in the PEP 446 that it does not
offer any atomicity guarantee.

But open(filename, blocking=False) on Linux has at least one advantage
over f=open(filename); os.set_blocking(f.fileno()): it only uses one
syscall (versus 2 or 3 syscalls).

Victor
___
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] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

[Ronald Oussoren]

On 6 Jul, 2013, at 13:59, R. David Murray  wrote:

> On Sat, 06 Jul 2013 10:25:19 +0200, ronald.oussoren 
>  wrote:
>> http://hg.python.org/cpython/rev/a2c2ffa1a41c
>> changeset:   84453:a2c2ffa1a41c
>> branch:  3.3
>> parent:  84449:df79735b21c1
>> user:Ronald Oussoren 
>> date:Sat Jul 06 10:23:59 2013 +0200
>> summary:
>>  Issue #17860: explicitly mention that std* streams are opened in binary 
>> mode by default.
>> 
>> The documentation does mention that the streams are opened in text mode
>> when univeral_newlines is true, but not that that they are opened in
>> binary mode when that argument is false and that seems to confuse at
>> least some users.
>> 
>> files:
>>  Doc/library/subprocess.rst |  6 --
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>> 
>> 
>> diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst
>> --- a/Doc/library/subprocess.rst
>> +++ b/Doc/library/subprocess.rst
>> @@ -293,7 +293,8 @@
>>If *universal_newlines* is ``True``, the file objects *stdin*, *stdout* 
>> and
>>*stderr* will be opened as text streams in :term:`universal newlines` mode
>>using the encoding returned by :func:`locale.getpreferredencoding(False)
>> -   `.  For *stdin*, line ending characters
>> +   `, otherwise these streams will be opened
>> +   as binary streams.  For *stdin*, line ending characters
>>``'\n'`` in the input will be converted to the default line separator
>>:data:`os.linesep`.  For *stdout* and *stderr*, all line endings in the
>>output will be converted to ``'\n'``.  For more information see the
> 
> IMO, either the default should be mentioned first, or the default
> should be mentioned in a parenthetical.  Otherwise it sounds like
> newline translation is being done in both modes.  Logically that makes
> no sense, so the above construction will likely lead to, at a minimum,
> an interruption in the flow for the reader, and at worse even more
> confusion than not mentioning it at all.

You've got a point there. Converting the next text (", otherwise ...") to a 
parententical
seems to be the cleanest fix, creating a separate sentence for the ``False`` 
case introduces
duplication unless I restructure the text.

Ronald

> 
> --David
> ___
> 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/ronaldoussoren%40mac.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] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets

[Ronald Oussoren]

On 6 Jul, 2013, at 14:04, Victor Stinner  wrote:

> 2013/7/6 Charles-François Natali :
>>> 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).
> 
> What do you mean by "does not work"? On Linux, O_NONBLOCK flag can be
> set on regular files, sockets, pipes, etc.

I guess he means that O_NONBLOCK doesn't actually do anything for regular
files, regular files are always ready for I/O as far as select et. al. are
concerned and I/O will block when data has to be read from disk (or in 
the case of a network filesystem, from another machine).

Ronald

___
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 446: Add new parameters to configure the inherance of files and for non-blocking sockets

[Victor Stinner]

2013/7/6 Cameron Simpson :
> Yes. Please forget I mentioned fork(); it is only relevant if you
> were offering some facility to undo the addition of cloexec to a
> Popen passed file descriptor. Which you are not.

Oh... gotcha. I now understood your concern.

There is a little "trick" here: at fork, file descriptors are
duplicated in the child process and almost all properties (open state,
flags, offset, etc.) are shared. There is one little exception: file
attributes are not shared, and there is only one file attribute:
O_CLOEXEC. Setting O_CLOEXEC in a child process does not affect the
flag in the parent process ;-) I will add a unit test to check this.

I modified the PEP to explain that, and I also mentioned the name of
the close-on-exec and blocking flags:
http://hg.python.org/peps/rev/425f831fddf7

Victor
___
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] lament for the demise of unbound methods

[Michael Foord]

On 5 Jul 2013, at 12:07, "Martin v. Löwis"  wrote:

> Am 05.07.13 11:23, schrieb Michael Foord:
>> I've also lamented the death of bound methods in Python 3 for mock
>> "autospeccing". Autospec introspects objects and provides mock
>> objects with the same attributes - and with the same method
>> signatures.
> 
> I wonder why you need to figure out the signatures in advance.
> Can you just wait until the function is actually used, and then
> process the parameters as you get them?
> 

How does that solve the problem? Given a call and a reference to the original 
"function object" I need to know whether or not to trim the first argument from 
the original signature or not (remove self if the corresponding function object 
is actually a method).

Michael

> Regards,
> Martin


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
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] lament for the demise of unbound methods

[Michael Foord]

On 5 Jul 2013, at 12:26, Łukasz Langa  wrote:

> On 5 lip 2013, at 12:07, Martin v. Löwis  wrote:
> 
>> I wonder why you need to figure out the signatures in advance.
>> Can you just wait until the function is actually used, and then
>> process the parameters as you get them?
>> 
> 
> My guess is that Michael's design lets mock objects be introspected as well, 
> i.e. they don't appear as magical as they really are to the user code.
> 

This is also true. Doing it up front has some conveniences - for example 
dir(...) works correctly.

Michael

> -- 
> Best regards,
> Łukasz Langa
> 
> WWW: http://lukasz.langa.pl/
> Twitter: @llanga
> IRC: ambv on #python-dev
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
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] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

[Ronald Oussoren]

On 6 Jul, 2013, at 14:09, Ronald Oussoren  wrote:

> 
> On 6 Jul, 2013, at 13:59, R. David Murray  wrote:
>> 
>> IMO, either the default should be mentioned first, or the default
>> should be mentioned in a parenthetical.  Otherwise it sounds like
>> newline translation is being done in both modes.  Logically that makes
>> no sense, so the above construction will likely lead to, at a minimum,
>> an interruption in the flow for the reader, and at worse even more
>> confusion than not mentioning it at all.
> 
> You've got a point there. Converting the next text (", otherwise ...") to a 
> parententical
> seems to be the cleanest fix, creating a separate sentence for the ``False`` 
> case introduces
> duplication unless I restructure the text.

I didn't like the parenthentical after all. Would this work for you?:

 
-   If *universal_newlines* is ``True``, the file objects *stdin*, *stdout* and
-   *stderr* will be opened as text streams in :term:`universal newlines` mode
+   If *universal_newlines* is ``False`` the file objects *stdin*, *stdout* and
+   *stderr* will be opened as binary streams, and no line ending conversion is 
done.
+
+   If *universal_newlines* is ``True``, these file objects
+   will be opened as text streams in :term:`universal newlines` mode
using the encoding returned by :func:`locale.getpreferredencoding(False)
-   `, otherwise these streams will be opened
-   as binary streams.  For *stdin*, line ending characters
+   `.  For *stdin*, line ending characters
``'\n'`` in the input will be converted to the default line separator
:data:`os.linesep`.  For *stdout* and *stderr*, all line endings in the
output will be converted to ``'\n'``.  For more information see the

That is, a new paragraph is added before the existing one to explain the 
behavior of
"not universal_newlines".

Ronald


> 
> Ronald
> 
>> 
>> --David
>> ___
>> 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/ronaldoussoren%40mac.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/ronaldoussoren%40mac.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] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

[Gregory P. Smith]

Please update the docstring in subprocess.py with the wording improvements
that you settle on while you're at it.


On Sat, Jul 6, 2013 at 6:03 AM, Ronald Oussoren wrote:

>
> On 6 Jul, 2013, at 14:09, Ronald Oussoren  wrote:
>
> >
> > On 6 Jul, 2013, at 13:59, R. David Murray  wrote:
> >>
> >> IMO, either the default should be mentioned first, or the default
> >> should be mentioned in a parenthetical.  Otherwise it sounds like
> >> newline translation is being done in both modes.  Logically that makes
> >> no sense, so the above construction will likely lead to, at a minimum,
> >> an interruption in the flow for the reader, and at worse even more
> >> confusion than not mentioning it at all.
> >
> > You've got a point there. Converting the next text (", otherwise ...")
> to a parententical
> > seems to be the cleanest fix, creating a separate sentence for the
> ``False`` case introduces
> > duplication unless I restructure the text.
>
> I didn't like the parenthentical after all. Would this work for you?:
>
>
> -   If *universal_newlines* is ``True``, the file objects *stdin*,
> *stdout* and
> -   *stderr* will be opened as text streams in :term:`universal newlines`
> mode
> +   If *universal_newlines* is ``False`` the file objects *stdin*,
> *stdout* and
> +   *stderr* will be opened as binary streams, and no line ending
> conversion is done.
> +
> +   If *universal_newlines* is ``True``, these file objects
> +   will be opened as text streams in :term:`universal newlines` mode
> using the encoding returned by
> :func:`locale.getpreferredencoding(False)
> -   `, otherwise these streams will be opened
> -   as binary streams.  For *stdin*, line ending characters
> +   `.  For *stdin*, line ending characters
> ``'\n'`` in the input will be converted to the default line separator
> :data:`os.linesep`.  For *stdout* and *stderr*, all line endings in the
> output will be converted to ``'\n'``.  For more information see the
>
> That is, a new paragraph is added before the existing one to explain the
> behavior of
> "not universal_newlines".
>
> Ronald
>
>
> >
> > Ronald
> >
> >>
> >> --David
> >> ___
> >> 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/ronaldoussoren%40mac.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/ronaldoussoren%40mac.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/greg%40krypto.org
>
___
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] Rough idea for adding introspection information for builtins

[Larry Hastings]

Revisiting a four-month-old discussion:

On 03/19/2013 11:00 AM, Larry Hastings wrote:
As for handling optional argument groups, my gut feeling is that we're 
better off not leaking it out of Argument Clinic--don't expose it in 
this string we're talking about, and don't add support for it in the 
inspect.Parameter object.  I'm not going to debate range(), the syntax 
of which predates one of our release managers.  But I suggest option 
groups are simply a misfeature of the curses module.  There are some 
other possible uses in builtins (I forgot to dig those out this 
evening) but so far we're talking adding complexity to an array of 
technologies (this representation, the parser, the Parameter object) 
to support a handful of uses of something we shouldn't have done in 
the first place, for consumers who I think won't care and won't 
appreciate the added conceptual complexity.


I'm sad to say I've just about changed my mind on this.

This is what help(os.stat) looks like in my dev branch for Argument Clinic:

>>> help(os.stat)
   Help on built-in function stat in module posix:

   stat(...)
os.stat(path, *, dir_fd=None, follow_symlinks=True)
   ...


Argument Clinic added the line starting with "os.stat(path, ". pydoc 
generated the "stat(...)" line.  It doesn't have any info because of the 
lack of introspection information.


Once builtins have introspection information, pydoc can do a better job, 
and Argument Clinic can stop generating its redundant prototype line.  
But if pydoc doesn't have argument group information, it won't be able 
to tell where one group ends and the next begins, and it won't be able 
to render the prototype for the help text correctly.  I fear misleading 
text is even worse than no text at all.


I also suggest that fancy editors (PyCharm etc) want as much information 
as we can give them.  If we give them argument group information, they 
can flag malformed calls (e.g. "there's no way to legally call this 
function with exactly three arguments").


I therefore have two credible consumers of this information.  That's 
enough for me: I propose we amend the Parameter object to add option 
group information for positional-only parameters.



//arry/
___
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] Accepting PEP 445

[Antoine Pitrou]

Hello,

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 to Victor for his patience :-)

Regards

Antoine.


___
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] Accepting PEP 445

[Antonio Cavallo]

Could that remove the need for the --with-pydebug flag?




On 6 Jul 2013, at 21:54, Antoine Pitrou  wrote:

> 
> Hello,
> 
> 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 to Victor for his patience :-)
> 
> Regards
> 
> Antoine.
> 
> 
> ___
> 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/a.cavallo%40cavallinux.eu

___
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] Accepting PEP 445

[Antoine Pitrou]

On Sat, 6 Jul 2013 22:07:40 +0100
Antonio Cavallo  wrote:
> Could that remove the need for the --with-pydebug flag?

No, --with-pydebug enables much more than just memory debug checks.

Regards

Antoine.


> 
> 
> 
> 
> On 6 Jul 2013, at 21:54, Antoine Pitrou  wrote:
> 
> > 
> > Hello,
> > 
> > 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 to Victor for his patience :-)
> > 
> > Regards
> > 
> > Antoine.
> > 
> > 
> > ___
> > 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/a.cavallo%40cavallinux.eu
> 

___
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] lament for the demise of unbound methods

[Nick Coghlan]

On 6 Jul 2013 22:52, "Michael Foord"  wrote:
>
>
> On 5 Jul 2013, at 12:26, Łukasz Langa  wrote:
>
> > On 5 lip 2013, at 12:07, Martin v. Löwis  wrote:
> >
> >> I wonder why you need to figure out the signatures in advance.
> >> Can you just wait until the function is actually used, and then
> >> process the parameters as you get them?
> >>
> >
> > My guess is that Michael's design lets mock objects be introspected as
well, i.e. they don't appear as magical as they really are to the user code.
> >
>
> This is also true. Doing it up front has some conveniences - for example
dir(...) works correctly.

Doesn't this really mean that in Py3, introspection APIs need a class *and*
an instance of that class for robust analysis of expected descriptor
results? (which was technically always true, the removal of unbound methods
just makes it significantly more important to handle descriptors with no
special behaviour on the class side of things).

And yes, I'm aware that idea poses a significant challenge for correct
handling of ABCs :P

Cheers,
Nick.

>
> Michael
>
> > --
> > Best regards,
> > Łukasz Langa
> >
> > WWW: http://lukasz.langa.pl/
> > Twitter: @llanga
> > IRC: ambv on #python-dev
> >
>
>
> --
> http://www.voidspace.org.uk/
>
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing
> http://www.sqlite.org/different.html
>
>
>
>
>
> ___
> 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/ncoghlan%40gmail.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] Rough idea for adding introspection information for builtins

[Nick Coghlan]

On 7 Jul 2013 05:22, "Larry Hastings"  wrote:
>
>
> Revisiting a four-month-old discussion:
>
>
> On 03/19/2013 11:00 AM, Larry Hastings wrote:
>>
>> As for handling optional argument groups, my gut feeling is that we're
better off not leaking it out of Argument Clinic--don't expose it in this
string we're talking about, and don't add support for it in the
inspect.Parameter object.  I'm not going to debate range(), the syntax of
which predates one of our release managers.  But I suggest option groups
are simply a misfeature of the curses module.  There are some other
possible uses in builtins (I forgot to dig those out this evening) but so
far we're talking adding complexity to an array of technologies (this
representation, the parser, the Parameter object) to support a handful of
uses of something we shouldn't have done in the first place, for consumers
who I think won't care and won't appreciate the added conceptual complexity.
>
>
> I'm sad to say I've just about changed my mind on this.
>
> This is what help(os.stat) looks like in my dev branch for Argument
Clinic:
>>
>> >>> help(os.stat)
>> Help on built-in function stat in module posix:
>>
>> stat(...)
>> os.stat(path, *, dir_fd=None, follow_symlinks=True)
>> ...
>
>
> Argument Clinic added the line starting with "os.stat(path, ".  pydoc
generated the "stat(...)" line.  It doesn't have any info because of the
lack of introspection information.
>
> Once builtins have introspection information, pydoc can do a better job,
and Argument Clinic can stop generating its redundant prototype line.  But
if pydoc doesn't have argument group information, it won't be able to tell
where one group ends and the next begins, and it won't be able to render
the prototype for the help text correctly.  I fear misleading text is even
worse than no text at all.
>
> I also suggest that fancy editors (PyCharm etc) want as much information
as we can give them.  If we give them argument group information, they can
flag malformed calls (e.g. "there's no way to legally call this function
with exactly three arguments").
>
> I therefore have two credible consumers of this information.  That's
enough for me: I propose we amend the Parameter object to add option group
information for positional-only parameters.

Rather than perpetuating unwanted complexity, can't we just add a single
"incomplete signature" flag to handle the legacy cases, and leave those to
the docstrings?

As in, if the flag is set, pydoc displays the "..." because it knows the
signature data isn't quite right.

Alternatively (and even more simply), is it really so bad if argument
clinic doesn't support introspection of such functions at all, and avoids
setting __signature__ for such cases?

As a third option, we could add an "alternative signatures" attribute to
capture multiple orthogonal signatures that should be presented on separate
lines.

All of those possibilities sound more appealing to me than adding direct
support for parameter groups at the Python level (with my preference being
to postpone the question to 3.5 by not allowing introspection of affected
functions in this initial iteration).

Cheers,
Nick.

>
>
> /arry
>
> ___
> 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/ncoghlan%40gmail.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] Accepting PEP 445

[Nick Coghlan]

On 7 Jul 2013 07:01, "Antoine Pitrou"  wrote:
>
>
> Hello,
>
> 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 to Victor for his patience :-)

Yay! And thanks to you for suggesting this API would benefit from being run
through the PEP process - I think the end result is a significant
improvement over what we originally planned to commit.

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> 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/ncoghlan%40gmail.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] Accepting PEP 445

[Victor Stinner]

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
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] Rough idea for adding introspection information for builtins

[Larry Hastings]

On 07/07/2013 12:32 AM, Nick Coghlan wrote:


Rather than perpetuating unwanted complexity, can't we just add a 
single "incomplete signature" flag to handle the legacy cases, and 
leave those to the docstrings?


As in, if the flag is set, pydoc displays the "..." because it knows 
the signature data isn't quite right.


Alternatively (and even more simply), is it really so bad if argument 
clinic doesn't support introspection of such functions at all, and 
avoids setting __signature__ for such cases?


As a third option, we could add an "alternative signatures" attribute 
to capture multiple orthogonal signatures that should be presented on 
separate lines.


All of those possibilities sound more appealing to me than adding 
direct support for parameter groups at the Python level (with my 
preference being to postpone the question to 3.5 by not allowing 
introspection of affected functions in this initial iteration).




First, I think the PyCharm case is compelling enough on its own.  I 
realized after I sent it that there's a related class of tools that are 
interested: PyFlakes, PyLint, and the like.  I'm sure the static 
correctness analyzers would like to be able to automatically determine 
"this is an illegal number of parameters for this function" for 
builtins--particularly for third-party builtins!  The fact that we 
wouldn't need to special-case pydoc suggests it's the superior 
approach.  ("Special cases aren't special enough to break the rules.")


Second, the added complexity would be a single new member on the 
Parameter object.  Let me propose such a parameter here, in the style of 
the Parameter class documentation:


   group

   If not None, represents which "optional parameter group" this
   parameter belongs to.  Optional parameter groups are contiguous
   sequences of parameters that must either all be specified or all
   be unspecified.  For example, if a function takes four
   parameters but the last two are in an optional parameter group,
   you could specify either two or four arguments to that
   function--it would be illegal to specify three arguments. 
   Parameter groups can only contain positional-only parameters;

   therefore group will only be a non-None value when kind is
   POSITIONAL_ONLY.


I suggest that is a manageable level of complexity.  And that the 
tooling projects would very much like to have this information.


Third, your proposals are respectively: 1) a hack which fixes the 
docstring but doesn't fix the introspection information (so we'd be 
providing incorrect introspection information to tools), 2) a small 
cop-out (which I think would also probably require a hack to pydoc), and 
3) way more complicated than doing it the right way (so I don't see how 
it's an improvement).  Of your three suggestions I dislike 2) least.


This facet of call signatures has existed in Python since the addition 
of range().  I concede that it's legacy, but it's not going away.  
Ever.  I now think we're better off embracing this complexity than 
trying to sweep it under the rug.



//arry/
___
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 446: Add new parameters to configure the inherance of files and for non-blocking sockets

[Cameron Simpson]

On 06Jul2013 14:43, Victor Stinner  wrote:
| 2013/7/6 Cameron Simpson :
| > Yes. Please forget I mentioned fork(); it is only relevant if you
| > were offering some facility to undo the addition of cloexec to a
| > Popen passed file descriptor. Which you are not.
| 
| Oh... gotcha. I now understood your concern.
| 
| There is a little "trick" here: at fork, file descriptors are
| duplicated in the child process and almost all properties (open state,
| flags, offset, etc.) are shared. There is one little exception: file
| attributes are not shared, and there is only one file attribute:
| O_CLOEXEC. Setting O_CLOEXEC in a child process does not affect the
| flag in the parent process ;-) I will add a unit test to check this.

That's news to me. Interesting.

I can't find UNIX doco to support this, though I haven't finished
looking. None of the POSIX, Linux or MacOSX fork() manual pages
seem to describe this.

Can you point me at doco for this? I thought file descriptors were
a direct index into a per-process table of file handle structures,
and did not think the latter got part copies, part shared over a
fork.

Also, is O_CLOEXEC really the only file attribute? So O_NONBLOCK
is a flag and not an attribute (guessing the terminology distinguishes
these)? Now you mention it, ISTR noticing that there were distinct
ioctls to adjust flags and something else.

| I modified the PEP to explain that, and I also mentioned the name of
| the close-on-exec and blocking flags:
| http://hg.python.org/peps/rev/425f831fddf7

Thanks.

Your change says:

  On Windows, the close-on-exec flag is ``HANDLE_FLAG_INHERIT``.

I feel it would be clearer to say:

  On Windows, the close-on-exec flag is the inverse of ``HANDLE_FLAG_INHERIT``.

or

  On Windows, the close-on-exec flag implemented using ``HANDLE_FLAG_INHERIT``.

(This latter is fine because the rest of the paragraph explains the
meaning of HANDLE_FLAG_INHERIT.)

The bare "is" in your current wording suggests to me that the
truthiness (ick!) of close-on-exec is the same as for HANDLE_FLAG_INHERIT,
which it isn't.
-- 
Cameron Simpson 

I've always been a big Greenaway fan - I've seen and enjoyed "The Falls" for
crying out loud.- Peter Alexander Merel 
___
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 446: Add new parameters to configure the inherance of files and for non-blocking sockets

[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, ...

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

Cheers,
-- 
Cameron Simpson 

Hofstadter's Law: It always takes longer than you expect, even when you take
into account Hofstadter's Law.
- Douglas Hosfstadter, Godel, Escher, Bach: an Eternal Golden Braid
___
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] Rough idea for adding introspection information for builtins

[Nick Coghlan]

On 7 Jul 2013 10:25, "Larry Hastings"  wrote:
>
> On 07/07/2013 12:32 AM, Nick Coghlan wrote:
>>
>> Rather than perpetuating unwanted complexity, can't we just add a single
"incomplete signature" flag to handle the legacy cases, and leave those to
the docstrings?
>>
>> As in, if the flag is set, pydoc displays the "..." because it knows the
signature data isn't quite right.
>>
>> Alternatively (and even more simply), is it really so bad if argument
clinic doesn't support introspection of such functions at all, and avoids
setting __signature__ for such cases?
>>
>> As a third option, we could add an "alternative signatures" attribute to
capture multiple orthogonal signatures that should be presented on separate
lines.
>>
>> All of those possibilities sound more appealing to me than adding direct
support for parameter groups at the Python level (with my preference being
to postpone the question to 3.5 by not allowing introspection of affected
functions in this initial iteration).
>
>
> First, I think the PyCharm case is compelling enough on its own.  I
realized after I sent it that there's a related class of tools that are
interested: PyFlakes, PyLint, and the like.  I'm sure the static
correctness analyzers would like to be able to automatically determine
"this is an illegal number of parameters for this function" for
builtins--particularly for third-party builtins!  The fact that we wouldn't
need to special-case pydoc suggests it's the superior approach.  ("Special
cases aren't special enough to break the rules.")
>
> Second, the added complexity would be a single new member on the
Parameter object.  Let me propose such a parameter here, in the style of
the Parameter class documentation:
>>
>> group
>>>
>>> If not None, represents which "optional parameter group" this parameter
belongs to.  Optional parameter groups are contiguous sequences of
parameters that must either all be specified or all be unspecified.  For
example, if a function takes four parameters but the last two are in an
optional parameter group, you could specify either two or four arguments to
that function--it would be illegal to specify three arguments.  Parameter
groups can only contain positional-only parameters; therefore group will
only be a non-None value when kind is POSITIONAL_ONLY.
>
>
> I suggest that is a manageable level of complexity.  And that the tooling
projects would very much like to have this information.
>
> Third, your proposals are respectively: 1) a hack which fixes the
docstring but doesn't fix the introspection information (so we'd be
providing incorrect introspection information to tools), 2) a small cop-out
(which I think would also probably require a hack to pydoc), and 3) way
more complicated than doing it the right way (so I don't see how it's an
improvement).  Of your three suggestions I dislike 2) least.
>
> This facet of call signatures has existed in Python since the addition of
range().  I concede that it's legacy, but it's not going away.  Ever.  I
now think we're better off embracing this complexity than trying to sweep
it under the rug.

The "group" attribute sounds reasonable to me, with the proviso that we use
"multiple signature lines" as the way to represent them in pydoc (rather
than inventing a notation for showing them in a single signature line).

It occurs to me that "type" is itself an example of this kind of dual
signature.

Cheers,
Nick.

>
>
> /arry
>
> ___
> 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/ncoghlan%40gmail.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] Rough idea for adding introspection information for builtins

[Larry Hastings]

On 07/07/2013 03:04 AM, Nick Coghlan wrote:


On 7 Jul 2013 10:25, "Larry Hastings" > wrote:

>>
>> group
>>>
>>> If not None, represents which "optional parameter group" this 
parameter belongs to.  Optional parameter groups are contiguous 
sequences of parameters that must either all be specified or all be 
unspecified.  For example, if a function takes four parameters but the 
last two are in an optional parameter group, you could specify either 
two or four arguments to that function--it would be illegal to specify 
three arguments.  Parameter groups can only contain positional-only 
parameters; therefore group will only be a non-None value when kind is 
POSITIONAL_ONLY.


The "group" attribute sounds reasonable to me, with the proviso that 
we use "multiple signature lines" as the way to represent them in 
pydoc (rather than inventing a notation for showing them in a single 
signature line).


It occurs to me that "type" is itself an example of this kind of dual 
signature.




We don't have to invent a notation--because we already have one. It's 
square brackets enclosing the optional parameter groups.  This is the 
syntax Guido dictated for Argument Clinic to use in its input DSL back 
at PyCon US 2013.  And the Python standard library documentation has 
been using this convention since the 90s. (Admittedly as a documentation 
convention, not in code.  But what we're talking about is documentation 
so I claim it's totally relevant.)


If we combine that with the admittedly-new "/" indicating "all previous 
parameters are positional-only", which we're also already using in the 
Argument Clinic input DSL syntax (at your suggestion!), we have a 
complete, crisp syntax.  I suppose "/" isn't really necessary, the 
Python documentation has survived without it for a long time.  But I 
think it'd would be a nice clarification; it would convey that you can't 
splat in **kwargs into functions specifying it, for example.


I expect this to be the format of the signature-for-builtins static data 
too, as well as the Argument Clinic input syntax.  Sure seems like a 
nice idea to use the same syntax everywhere.  Particularly allowing as 
how it's so nice and readable.



An admission: the Python standard library documentation actually uses 
*both* square-brackets-for-optional-groups and multiple lines. Sometimes 
even for the same function!  An example:


   http://docs.python.org/3/library/curses.html#curses.window.addch

Of the two, I believe the square brackets syntax is far more common.


//arry/
___
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] lament for the demise of unbound methods

[Raymond Hettinger]

On Jul 4, 2013, at 2:34 AM, Brett Cannon  wrote:

> The loss of the ability to figure out the class from an unbound method seems 
> quite an annoying step back from an introspection point of view.
> 
> It's only annoying if you take the perspective that methods are somehow 
> special compared to functions. With the removal of bound class methods that 
> makes methods == functions that are an attribute on a class. And when you 
> take that perspective it makes having anything special about methods seem 
> wrong. It also makes adding a function to a class post-class creation make 
> more sense since there is no difference technically.

Well said, Brett.  
This is a nice summary.


Raymond___
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] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

[R. David Murray]

On Sat, 06 Jul 2013 08:14:26 -0700, "Gregory P. Smith"  wrote:
> Please update the docstring in subprocess.py with the wording improvements
> that you settle on while you're at it.
> 
> On Sat, Jul 6, 2013 at 6:03 AM, Ronald Oussoren wrote:
> > I didn't like the parenthentical after all. Would this work for you?:
> >
> > -   If *universal_newlines* is ``True``, the file objects *stdin*,
> > *stdout* and
> > -   *stderr* will be opened as text streams in :term:`universal newlines`
> > mode
> > +   If *universal_newlines* is ``False`` the file objects *stdin*,
> > *stdout* and
> > +   *stderr* will be opened as binary streams, and no line ending
> > conversion is done.
> > +
> > +   If *universal_newlines* is ``True``, these file objects
> > +   will be opened as text streams in :term:`universal newlines` mode
> > using the encoding returned by
> > :func:`locale.getpreferredencoding(False)
> > -   `, otherwise these streams will be opened
> > -   as binary streams.  For *stdin*, line ending characters
> > +   `.  For *stdin*, line ending characters
> > ``'\n'`` in the input will be converted to the default line separator
> > :data:`os.linesep`.  For *stdout* and *stderr*, all line endings in the
> > output will be converted to ``'\n'``.  For more information see the
> >
> > That is, a new paragraph is added before the existing one to explain the
> > behavior of "not universal_newlines".

Looks good to me.

--David
___
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] Rough idea for adding introspection information for builtins

[Ronald Oussoren]

On 6 Jul, 2013, at 19:33, Larry Hastings  wrote:
> 
> Once builtins have introspection information, pydoc can do a better job, and 
> Argument Clinic can stop generating its redundant prototype line.

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 ;-)

Ronald
___
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] Rough idea for adding introspection information for builtins

[R. David Murray]

On Sun, 07 Jul 2013 04:48:18 +0200, Larry Hastings  wrote:
> On 07/07/2013 03:04 AM, Nick Coghlan wrote:
> >
> > On 7 Jul 2013 10:25, "Larry Hastings"  > > wrote:
> > >>
> > >> group
> > >>>
> > >>> If not None, represents which "optional parameter group" this 
> > parameter belongs to.  Optional parameter groups are contiguous 
> > sequences of parameters that must either all be specified or all be 
> > unspecified.  For example, if a function takes four parameters but the 
> > last two are in an optional parameter group, you could specify either 
> > two or four arguments to that function--it would be illegal to specify 
> > three arguments.  Parameter groups can only contain positional-only 
> > parameters; therefore group will only be a non-None value when kind is 
> > POSITIONAL_ONLY.
> >
> > The "group" attribute sounds reasonable to me, with the proviso that 
> > we use "multiple signature lines" as the way to represent them in 
> > pydoc (rather than inventing a notation for showing them in a single 
> > signature line).
> >
> > It occurs to me that "type" is itself an example of this kind of dual 
> > signature.
> >
> 
> We don't have to invent a notation--because we already have one. It's 
> square brackets enclosing the optional parameter groups.  This is the 
> syntax Guido dictated for Argument Clinic to use in its input DSL back 
> at PyCon US 2013.  And the Python standard library documentation has 
> been using this convention since the 90s. (Admittedly as a documentation 
> convention, not in code.  But what we're talking about is documentation 
> so I claim it's totally relevant.)
> 
> If we combine that with the admittedly-new "/" indicating "all previous 
> parameters are positional-only", which we're also already using in the 
> Argument Clinic input DSL syntax (at your suggestion!), we have a 
> complete, crisp syntax.  I suppose "/" isn't really necessary, the 
> Python documentation has survived without it for a long time.  But I 
> think it'd would be a nice clarification; it would convey that you can't 
> splat in **kwargs into functions specifying it, for example.
> 
> I expect this to be the format of the signature-for-builtins static data 
> too, as well as the Argument Clinic input syntax.  Sure seems like a 
> nice idea to use the same syntax everywhere.  Particularly allowing as 
> how it's so nice and readable.
> 
> 
> An admission: the Python standard library documentation actually uses 
> *both* square-brackets-for-optional-groups and multiple lines. Sometimes 
> even for the same function!  An example:
> 
> http://docs.python.org/3/library/curses.html#curses.window.addch
> 
> Of the two, I believe the square brackets syntax is far more common.

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.

--David
___
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] Rough idea for adding introspection information for builtins

[Ronald Oussoren]

On 7 Jul, 2013, at 4:48, Larry Hastings  wrote:

> 
> If we combine that with the admittedly-new "/" indicating "all previous 
> parameters are positional-only",

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.

Ronald
___
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] lament for the demise of unbound methods

[Chris Withers]

On 05/07/2013 11:26, "Martin v. Löwis" wrote:

...

A.__getattribute__(A,'s')



A.__getattribute__(A,'c')



A.__getattribute__(A,'r')




Okay, but with this line:

found = found.__getattribute__(found, n)

I get a tonne of failures like this:

  File "testfixtures.tests.test_replacer.TestReplacer.test_with_statement[3]>", 
line 2, in 

r.replace('testfixtures.tests.sample1.z',test_z)
  File 
"/Users/chris/LocalGIT/testfixtures/testfixtures/replace.py", line 50, 
in replace

container, method, attribute, t_obj = resolve(target)
  File 
"/Users/chris/LocalGIT/testfixtures/testfixtures/resolve.py", line 17, 
in resolve

found = found.__getattribute__(found, n)
TypeError: expected 1 arguments, got 2

If I change it to :

found = found.__getattribute__(n)

I get fewer failures, but still plenty, now of the form:

  File "testfixtures.tests.test_replacer.TestReplacer.test_multiple_replace[7]>", line 
1, in 

r.replace('testfixtures.tests.sample1.X.y',test_y)
  File 
"/Users/chris/LocalGIT/testfixtures/testfixtures/replace.py", line 50, 
in replace

container, method, attribute, t_obj = resolve(target)
  File 
"/Users/chris/LocalGIT/testfixtures/testfixtures/resolve.py", line 17, 
in resolve

found = found.__getattribute__(n)
TypeError: expected 1 arguments, got 0

...so I'm back to:

found = found.__dict__[n]

...and having to catch both KeyError and AttributeError.

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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