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

2013-07-04 Thread Victor Stinner 
HTML version:
http://www.python.org/dev/peps/pep-0446/


PEP: 446
Title: Add new parameters to configure the inherance of files and for
non-blocking sockets
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 3-July-2013
Python-Version: 3.4


Abstract


This PEP proposes new portable parameters and functions to configure the
inherance of file descriptors and the non-blocking flag of sockets.


Rationale
=

Inherance of file descriptors
-

The inherance of file descriptors in child processes can be configured
on each file descriptor using a *close-on-exec* flag. By default, the
close-on-exec flag is not set.

On Windows, file descriptors are not inherited if the
``bInheritHandles`` parameter of the ``CreateProcess()`` function is
``FALSE``, even if the close-on-exec flag is not set.

On UNIX, file descriptors with the close-and-exec flag set are closed at
the execution of a new program (ex: when calling ``execv()``). The flag
has no effect on ``fork()``, all file descriptors are inherited by the
child process.

Issues of the inherance of file descriptors
---

Inherance of file descriptors causes issues. For example, closing a file
descriptor in the parent process does not release the resource (file,
socket, ...), because the file descriptor is still open in the child
process.

Leaking file descriptors is also a major security vulnerability. An
untrusted child process can read sensitive data like passwords and take
control of the parent process though leaked file descriptors. It is for
example a known vulnerability to escape from a chroot.


Non-blocking sockets


To handle multiple network clients in a single thread, a multiplexing
function like ``select()`` can be used. For best performances, sockets
must be configured as non-blocking. Operations like ``send()`` and
``recv()`` return an ``EAGAIN`` or ``EWOULDBLOCK`` error if the
operation would block.

By default, newly created sockets are blocking. Setting the non-blocking
mode requires additional system calls.


Setting flags at the creation of the file descriptor


Windows and recent versions of other operating systems like Linux
support setting the close-on-exec flag directly at the creation of file
descriptors, and close-on-exec and blocking flags at the creation of
sockets.

Setting these flags at the creation is atomic and avoids additional
system calls.


Proposal


New cloexec And blocking Parameters
---

Add a new optional *cloexec* on functions creating file descriptors:

* ``io.FileIO``
* ``io.open()``
* ``open()``
* ``os.dup()``
* ``os.dup2()``
* ``os.fdopen()``
* ``os.open()``
* ``os.openpty()``
* ``os.pipe()``
* ``select.devpoll()``
* ``select.epoll()``
* ``select.kqueue()``

Add new optional *cloexec* and *blocking* parameters to functions
creating sockets:

* ``asyncore.dispatcher.create_socket()``
* ``socket.socket()``
* ``socket.socket.accept()``
* ``socket.socket.dup()``
* ``socket.socket.fromfd``
* ``socket.socketpair()``

The default value of *cloexec* is ``False`` and the default value of
*blocking* is ``True``.

The atomicity is not guaranteed. If the platform does not support
setting close-on-exec and blocking flags at the creation of the file
descriptor or socket, the flags are set using additional system calls.

New Functions
-

Add new functions the get and set the close-on-exec flag of a file
descriptor:

* ``os.get_cloexec(fd:int) -> bool``
* ``os.set_cloexec(fd:int, cloexec: bool)``


Other Changes
-

The ``subprocess.Popen`` class must clear the close-on-exec flag of file
descriptors of the ``pass_fds`` parameter.

The close-on-exec flag must also be set on private file descriptors and
sockets in the Python standard library. For example, on UNIX,
os.urandom() opens ``/dev/urandom`` to read some random bytes and the
file descriptor is closed at function exit. The file descriptor is not
expected to be inherited by child processes.


Rejected Alternatives
=

PEP 433
---

The PEP 433 entitled "Easier suppression of file descriptor inheritance"
is a previous attempt proposing various other alternatives, but no
consensus could be reached.

This PEP has a well defined behaviour (the default value of the new
*cloexec* parameter is not configurable), is more conservative (no
backward compatibility issue), and is much simpler.


Add blocking parameter for file descriptors and Windows overlapped I/O
--

Windows supports non-blocking operations on files using an extension of
the Windows API called "Overlapped I/O". Using this extension requires
to modify the Python standard library and applications to pass a
``OVERLAPPED`` structure and an event lo

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

2013-07-04 Thread Victor Stinner 
2013/7/4 Victor Stinner :
> Add a new optional *cloexec* on functions creating file descriptors:
>
> * ``io.FileIO``
> * ``io.open()``
> * ``open()``

The PEP 433 proposes adding an "e" mode to open in alternatives. I
didn't keep this idea because the fopen() function of the GNU libc
library has no mode for the O_NONBLOCK flag. IMO it is not interesting
to mention it in the PEP 466.

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

2013-07-04 Thread Victor Stinner 
> PEP: 446
> Title: Add new parameters to configure the inherance of files and for
> non-blocking sockets
> (...)
> Rejected Alternatives
> =
>
> PEP 433
> ---
>
> The PEP 433 entitled "Easier suppression of file descriptor inheritance"
> is a previous attempt proposing various other alternatives, but no
> consensus could be reached.
>
> This PEP has a well defined behaviour (the default value of the new
> *cloexec* parameter is not configurable), is more conservative (no
> backward compatibility issue), and is much simpler.

Even if the PEP 433 was not explicitly rejected, no consensus could be
reached. I didn't want to loose all my work on this PEP and so I'm
proposing something new which should make everbody agrees :-)

The PEP 446 is written to supersed the PEP 433. Even if they are very
close, many drawbacks of the PEP 433 (especially the configurable
default value of the new cloexec parameter) goes away with the PEP
466, which explains why the PEP 466 is much shorter. I preferred to
create a new PEP to keep the historic in the PEP 433. I also chose to
not detail the implementation in the PEP 466, because the PEP 433
already contains a lot of information.

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

[Python-Dev] lament for the demise of unbound methods

2013-07-04 Thread Chris Withers 

Hi All,

In Python 2, I can figure out whether I have a method or a function, 
and, more importantly, for an unbound method, I can figure out what 
class the method belongs to:


>>> class MyClass(object):
...   def method(self): pass
...
>>> MyClass.method

>>> MyClass.method.im_class


There doesn't appear to be any way in Python 3 to do this, which is a 
little surprising and frustrating...


What am I missing here?

Chris

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

On 4 Jul, 2013, at 13:19, Victor Stinner  wrote:

> 2013/7/4 Victor Stinner :
>> Add a new optional *cloexec* on functions creating file descriptors:
>> 
>> * ``io.FileIO``
>> * ``io.open()``
>> * ``open()``
> 
> The PEP 433 proposes adding an "e" mode to open in alternatives. I
> didn't keep this idea because the fopen() function of the GNU libc
> library has no mode for the O_NONBLOCK flag. IMO it is not interesting
> to mention it in the PEP 466.

I don't understand your reasoning, that is what has GNU libc to do with adding 
"e" mode to io.open?

BTW. I have no particular fondness for an "e" flag, adding a clo_exec flag 
would be fine and I'm just curious.

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

2013-07-04 Thread Ronald Oussoren 

On 4 Jul, 2013, at 13:21, Chris Withers  wrote:

> Hi All,
> 
> In Python 2, I can figure out whether I have a method or a function, and, 
> more importantly, for an unbound method, I can figure out what class the 
> method belongs to:
> 
> >>> class MyClass(object):
> ...   def method(self): pass
> ...
> >>> MyClass.method
> 
> >>> MyClass.method.im_class
> 
> 
> There doesn't appear to be any way in Python 3 to do this, which is a little 
> surprising and frustrating...
> 
> What am I missing here?

You can find the fully qualified name of the method with the qualname attribute:

>>> class A:
...def method(self): pass
... 
>>> A.method.__qualname__
'A.method'

Ronald
> 
> Chris
> 
> -- 
> Simplistix - Content Management, Batch Processing & Python Consulting
>- http://www.simplistix.co.uk
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com

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

2013-07-04 Thread Christian Heimes 
Am 04.07.2013 13:21, schrieb Chris Withers:
> There doesn't appear to be any way in Python 3 to do this, which is a
> little surprising and frustrating...
> 
> What am I missing here?

I removed unbound methods almost six years ago:

http://hg.python.org/cpython/rev/48af6375207e

Christian
___
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-04 Thread Victor Stinner 
2013/7/4 Ronald Oussoren :
>> The PEP 433 proposes adding an "e" mode to open in alternatives. I
>> didn't keep this idea because the fopen() function of the GNU libc
>> library has no mode for the O_NONBLOCK flag. IMO it is not interesting
>> to mention it in the PEP 466.
>
> I don't understand your reasoning, that is what has GNU libc to do with 
> adding "e" mode to io.open?

The GNU libc supports fopen(filename, "re") to set O_CLOEXEC flag on
the file. I pick the idea into the PEP 433, in alternatives:
open(filename, "re") sets O_CLOEXEC flag on the file.

For the PEP 466, I only proposed the original API of the PEP 433:
open(filename, "r", cloexec=True).

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

2013-07-04 Thread Chris Withers 

On 04/07/2013 12:59, Christian Heimes wrote:

Am 04.07.2013 13:21, schrieb Chris Withers:

There doesn't appear to be any way in Python 3 to do this, which is a
little surprising and frustrating...

What am I missing here?


I removed unbound methods almost six years ago:

http://hg.python.org/cpython/rev/48af6375207e


Not disputing when it happened, more the why...

...the recommended change doesn't work, for obvious reasons:

>>> MyClass.method.__self__.__class__
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'function' object has no attribute '__self__'

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.


cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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] lament for the demise of unbound methods

2013-07-04 Thread Chris Withers 

On 04/07/2013 12:55, Ronald Oussoren wrote:


You can find the fully qualified name of the method with the qualname attribute:


class A:

...def method(self): pass
...

A.method.__qualname__

'A.method'


That doesn't seem helpful as a sensible way to get back to the class object:

>> globals()[MyClass.method.__qualname__.split('.')[0]]


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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] lament for the demise of unbound methods

2013-07-04 Thread Brett Cannon 
On Thu, Jul 4, 2013 at 8:13 AM, Chris Withers wrote:

> On 04/07/2013 12:59, Christian Heimes wrote:
>
>> Am 04.07.2013 13:21, schrieb Chris Withers:
>>
>>> There doesn't appear to be any way in Python 3 to do this, which is a
>>> little surprising and frustrating...
>>>
>>> What am I missing here?
>>>
>>
>> I removed unbound methods almost six years ago:
>>
>> http://hg.python.org/cpython/**rev/48af6375207e
>>
>
> Not disputing when it happened, more the why...
>
> ...the recommended change doesn't work, for obvious reasons:
>
> >>> MyClass.method.__self__.__**class__
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'function' object has no attribute '__self__'
>
> 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.
___
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] lament for the demise of unbound methods

2013-07-04 Thread Victor Stinner 
2013/7/4 Chris Withers :
> That doesn't seem helpful as a sensible way to get back to the class object:
>
>>> globals()[MyClass.method.__qualname__.split('.')[0]]
> 

globals() can only be used if MyClass is in the same module.
Otherwise, you a more complex function:
---
import types

def get_function_class(func):
obj = func
for name in func.__qualname__.split('.')[:-1]:
if name == "":
raise ValueError("you lose")
if isinstance(obj, types.FunctionType):
obj = func.__globals__[name]
else:
# get a method of a class, or a class defined in a child
obj = getattr(obj, name)
return obj
---

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

2013-07-04 Thread Guido van Rossum 
Chris, what do you want to do with the knowledge you are seeking?

--Guido van Rossum (sent from Android phone)
On Jul 4, 2013 4:28 AM, "Chris Withers"  wrote:

> Hi All,
>
> In Python 2, I can figure out whether I have a method or a function, and,
> more importantly, for an unbound method, I can figure out what class the
> method belongs to:
>
> >>> class MyClass(object):
> ...   def method(self): pass
> ...
> >>> MyClass.method
> 
> >>> MyClass.method.im_class
> 
>
> There doesn't appear to be any way in Python 3 to do this, which is a
> little surprising and frustrating...
>
> What am I missing here?
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> - http://www.simplistix.co.uk
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org
>
___
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] lament for the demise of unbound methods

2013-07-04 Thread Chris Withers 

Hi Guido,

I've bumped into this a couple of times.

First time was when I wanted to know whether what I had was a 
classmethod, staticmethod or normal method here:


https://github.com/Simplistix/testfixtures/blob/master/testfixtures/replace.py#L59

This resulted in having to trawl through __dict__ here:

https://github.com/Simplistix/testfixtures/blob/master/testfixtures/resolve.py#L17

...rather than just using getattr.

I bumped into it again, yesterday, trying to add support for classes to 
this lightweight dependency injection framework I'm developing:


https://github.com/Simplistix/mush/blob/master/tests/test_runner.py#L189

Here's my local copy of that test:

https://gist.github.com/cjw296/db64279c69cdc0c5e112

The workaround I was playing with this morning is a wrapper so that I 
know I have a class method, although what I really want to write at this 
line is:


https://gist.github.com/cjw296/db64279c69cdc0c5e112#file-gistfile1-txt-L40

runner = Runner(T0, C1.meth, C2.meth1, C2.meth2)

...but if I do that, how can the runner know that what it gets for its 
second argument is a class method of C1?
(which is this case means that it should do C1().meth() rather than 
C1.meth())


cheers,

Chris

On 04/07/2013 17:25, Guido van Rossum wrote:

Chris, what do you want to do with the knowledge you are seeking?

--Guido van Rossum (sent from Android phone)

On Jul 4, 2013 4:28 AM, "Chris Withers" mailto:[email protected]>> wrote:

Hi All,

In Python 2, I can figure out whether I have a method or a function,
and, more importantly, for an unbound method, I can figure out what
class the method belongs to:

 >>> class MyClass(object):
...   def method(self): pass
...
 >>> MyClass.method

 >>> MyClass.method.im_class


There doesn't appear to be any way in Python 3 to do this, which is
a little surprising and frustrating...

What am I missing here?

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
 - http://www.simplistix.co.uk
_
Python-Dev mailing list
[email protected] 
http://mail.python.org/__mailman/listinfo/python-dev

Unsubscribe:
http://mail.python.org/__mailman/options/python-dev/__guido%40python.org



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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] lament for the demise of unbound methods

2013-07-04 Thread Guido van Rossum 
Thanks for the code pointers. So it's all about monkeypatching. :-) I have
only a little sympathy, as there still seems to be a way to do this, it's
just less convenient. Too bad.

--Guido

On Thu, Jul 4, 2013 at 9:42 AM, Chris Withers wrote:

> Hi Guido,
>
> I've bumped into this a couple of times.
>
> First time was when I wanted to know whether what I had was a classmethod,
> staticmethod or normal method here:
>
> https://github.com/Simplistix/**testfixtures/blob/master/**
> testfixtures/replace.py#L59
>
> This resulted in having to trawl through __dict__ here:
>
> https://github.com/Simplistix/**testfixtures/blob/master/**
> testfixtures/resolve.py#L17
>
> ...rather than just using getattr.
>
> I bumped into it again, yesterday, trying to add support for classes to
> this lightweight dependency injection framework I'm developing:
>
> https://github.com/Simplistix/**mush/blob/master/tests/test_**
> runner.py#L189
>
> Here's my local copy of that test:
>
> https://gist.github.com/**cjw296/db64279c69cdc0c5e112
>
> The workaround I was playing with this morning is a wrapper so that I know
> I have a class method, although what I really want to write at this line is:
>
> https://gist.github.com/**cjw296/db64279c69cdc0c5e112#**
> file-gistfile1-txt-L40
>
> runner = Runner(T0, C1.meth, C2.meth1, C2.meth2)
>
> ...but if I do that, how can the runner know that what it gets for its
> second argument is a class method of C1?
> (which is this case means that it should do C1().meth() rather than
> C1.meth())
>
> cheers,
>
> Chris
>
>
> On 04/07/2013 17:25, Guido van Rossum wrote:
>
>> Chris, what do you want to do with the knowledge you are seeking?
>>
>> --Guido van Rossum (sent from Android phone)
>>
>> On Jul 4, 2013 4:28 AM, "Chris Withers" > > wrote:
>>
>> Hi All,
>>
>> In Python 2, I can figure out whether I have a method or a function,
>> and, more importantly, for an unbound method, I can figure out what
>> class the method belongs to:
>>
>>  >>> class MyClass(object):
>> ...   def method(self): pass
>> ...
>>  >>> MyClass.method
>> 
>>  >>> MyClass.method.im_class
>> 
>>
>> There doesn't appear to be any way in Python 3 to do this, which is
>> a little surprising and frustrating...
>>
>> What am I missing here?
>>
>> Chris
>>
>> --
>> Simplistix - Content Management, Batch Processing & Python Consulting
>>  - http://www.simplistix.co.uk
>> __**___
>> Python-Dev mailing list
>> [email protected] 
>> 
>> http://mail.python.org/__**mailman/listinfo/python-dev
>> 
>> 
>> >
>> Unsubscribe:
>> http://mail.python.org/__**mailman/options/python-dev/__**
>> guido%40python.org
>> > guido%40python.org
>> >
>>
>>
>> __**__**
>> __
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> __**__**
>> __
>>
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> - http://www.simplistix.co.uk
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] lament for the demise of unbound methods

2013-07-04 Thread Chris Withers 

On 04/07/2013 18:00, Guido van Rossum wrote:

Thanks for the code pointers. So it's all about monkeypatching. :-)


Well, that's the testfixtures use case, but for mush it's about figuring 
out whether you need to instantiate a class before calling a callable.


MyClass.a_method is a bit like a functools.partial in the mush case, if 
I can pass that object around and know what to do with it (which I can 
in Python 2) then I only have to pass that around.


In Python3, I either have to pass around the class, the method and a 
flag to indicate that a class and method are being passed, or wrap my 
own unboundmethod equivalent, meaning mush users would have to write 
method(MyClass, 'a_method') under Python 3 when they can just write 
MyClass.a_method under Python 2.



I
have only a little sympathy, as there still seems to be a way to do
this, it's just less convenient. Too bad.


I don't know that Victor's suggestion will actually work in all the 
cases that MyClass.a_method.im_class does :-S


Chris


On Thu, Jul 4, 2013 at 9:42 AM, Chris Withers https://github.com/Simplistix/__testfixtures/blob/master/__testfixtures/replace.py#L59



This resulted in having to trawl through __dict__ here:


https://github.com/Simplistix/__testfixtures/blob/master/__testfixtures/resolve.py#L17



...rather than just using getattr.

I bumped into it again, yesterday, trying to add support for classes
to this lightweight dependency injection framework I'm developing:

https://github.com/Simplistix/__mush/blob/master/tests/test___runner.py#L189


Here's my local copy of that test:

https://gist.github.com/__cjw296/db64279c69cdc0c5e112


The workaround I was playing with this morning is a wrapper so that
I know I have a class method, although what I really want to write
at this line is:


https://gist.github.com/__cjw296/db64279c69cdc0c5e112#__file-gistfile1-txt-L40


runner = Runner(T0, C1.meth, C2.meth1, C2.meth2)

...but if I do that, how can the runner know that what it gets for
its second argument is a class method of C1?
(which is this case means that it should do C1().meth() rather than
C1.meth())

cheers,

Chris


On 04/07/2013 17:25, Guido van Rossum wrote:

Chris, what do you want to do with the knowledge you are seeking?

--Guido van Rossum (sent from Android phone)

On Jul 4, 2013 4:28 AM, "Chris Withers" mailto:[email protected]>
__>> wrote:

 Hi All,

 In Python 2, I can figure out whether I have a method or a
function,
 and, more importantly, for an unbound method, I can figure
out what
 class the method belongs to:

 >>> class MyClass(object):
 ...   def method(self): pass
 ...
 >>> MyClass.method

 >>> MyClass.method.im_class


 There doesn't appear to be any way in Python 3 to do this,
which is
 a little surprising and frustrating...

 What am I missing here?

 Chris

 --
 Simplistix - Content Management, Batch Processing & Python
Consulting
  - http://www.simplistix.co.uk
 ___
 Python-Dev mailing list
[email protected] 
>
http://mail.python.org/mailman/listinfo/python-dev

>
 Unsubscribe:

http://mail.python.org/mailman/options/python-dev/guido%40python.org



>



__
This email has been scanned by the Symantec Email Security.cloud
service.
For more information please visit http://www.symanteccloud.com

__


--
Simplistix - Content Management, Batch Processing & Python Consulting

Re: [Python-Dev] lament for the demise of unbound methods

2013-07-04 Thread Eric Snow 
On Thu, Jul 4, 2013 at 5:21 AM, Chris Withers wrote:

> Hi All,
>
> In Python 2, I can figure out whether I have a method or a function, and,
> more importantly, for an unbound method, I can figure out what class the
> method belongs to:
>
> >>> class MyClass(object):
> ...   def method(self): pass
> ...
> >>> MyClass.method
> 
> >>> MyClass.method.im_class
> 
>
> There doesn't appear to be any way in Python 3 to do this, which is a
> little surprising and frustrating...
>
> What am I missing here?


You could always monkeypatch builtins.__build_class__ to add an attribute
to every "unbound method" pointing to the class.

-eric
___
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

[Python-Dev] Oddity in MISC/News on default

2013-07-04 Thread Antoine Pitrou 

Hello,

In 3.4's Misc/NEWS, there's a huge section entitled "What's New in
Python 3.3.1 release candidate 1". It seems it shouldn't be there,
should it?

Regards

Antoine.


___
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] Oddity in MISC/News on default

2013-07-04 Thread Guido van Rossum 
Why not? Presumably those news items were all merged into the default
branch, and Misc/NEWS also has all the news for all 3.3.0 releases. Why
pick on 3.3.1 rc1?

On Thu, Jul 4, 2013 at 12:09 PM, Antoine Pitrou  wrote:

>
> Hello,
>
> In 3.4's Misc/NEWS, there's a huge section entitled "What's New in
> Python 3.3.1 release candidate 1". It seems it shouldn't be there,
> should it?
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Oddity in MISC/News on default

2013-07-04 Thread Antoine Pitrou 
Le jeudi 04 juillet 2013 à 12:17 -0700, Guido van Rossum a écrit :
> Why not? Presumably those news items were all merged into the default
> branch, and Misc/NEWS also has all the news for all 3.3.0 releases.
> Why pick on 3.3.1 rc1?

3.3.1rc1 is the only post-3.3.0 release that's mentioned there (e.g.
3.3.2 isn't), which is what makes me thing a mistake was made along the
way (probably when merging).

Regards

Antoine.


___
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] Oddity in MISC/News on default

2013-07-04 Thread Guido van Rossum 
Maybe the mistake is that the others aren't mentioned? Or perhaps
everything before 3.4a1 should be dropped? I forget what kind of policy we
have for this -- is it all changes in this branch or only changes unique to
this branch?

On Thu, Jul 4, 2013 at 12:19 PM, Antoine Pitrou  wrote:

> Le jeudi 04 juillet 2013 à 12:17 -0700, Guido van Rossum a écrit :
> > Why not? Presumably those news items were all merged into the default
> > branch, and Misc/NEWS also has all the news for all 3.3.0 releases.
> > Why pick on 3.3.1 rc1?
>
> 3.3.1rc1 is the only post-3.3.0 release that's mentioned there (e.g.
> 3.3.2 isn't), which is what makes me thing a mistake was made along the
> way (probably when merging).
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Oddity in MISC/News on default

2013-07-04 Thread Benjamin Peterson 
Does annotate show it might have been added accidently in a merge?

2013/7/4 Antoine Pitrou :
>
> Hello,
>
> In 3.4's Misc/NEWS, there's a huge section entitled "What's New in
> Python 3.3.1 release candidate 1". It seems it shouldn't be there,
> should it?
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/benjamin%40python.org



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

2013-07-04 Thread Benjamin Peterson 
2013/7/4 Eric Snow :
>
> On Thu, Jul 4, 2013 at 5:21 AM, Chris Withers 
> wrote:
>>
>> Hi All,
>>
>> In Python 2, I can figure out whether I have a method or a function, and,
>> more importantly, for an unbound method, I can figure out what class the
>> method belongs to:
>>
>> >>> class MyClass(object):
>> ...   def method(self): pass
>> ...
>> >>> MyClass.method
>> 
>> >>> MyClass.method.im_class
>> 
>>
>> There doesn't appear to be any way in Python 3 to do this, which is a
>> little surprising and frustrating...
>>
>> What am I missing here?
>
>
> You could always monkeypatch builtins.__build_class__ to add an attribute to
> every "unbound method" pointing to the class.

I would not reccomend that. __build_class__ is very internal and it's
contract may change between versions.



--
Regards,
Benjamin
___
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-04 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/04/2013 07:03 AM, Victor Stinner wrote:
> Title: Add new parameters to configure the inherance of files and for 
> non-blocking sockets

Not commenting on either the form or the substance (pun intended), but
the word you want is "inheritance" -- "inherence" is a valid term[1], but
would a good deal stranger notion to apply to a file descriptor. ;)


[1] https://en.wikipedia.org/wiki/Inherence


Platonic'ly,


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHV0VoACgkQ+gerLs4ltQ4YCQCgp6mFPxEVVoXAXib/jrChjRxu
QkAAoLJQIfBCQezj61LCAgmVaE1kwNmM
=yiPj
-END PGP SIGNATURE-

___
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] Oddity in MISC/News on default

2013-07-04 Thread Antoine Pitrou 
On Thu, 4 Jul 2013 12:47:30 -0700
Benjamin Peterson  wrote:

> Does annotate show it might have been added accidently in a merge?

Annotate shows the original changesets on the 3.3 branch, which doesn't
help ;-)

Regards

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

2013-07-04 Thread Chris Withers 

On 04/07/2013 20:50, Benjamin Peterson wrote:

2013/7/4 Eric Snow :


You could always monkeypatch builtins.__build_class__ to add an attribute to
every "unbound method" pointing to the class.


I would not reccomend that. __build_class__ is very internal and it's
contract may change between versions.


Right, not to mention the fact that there's no way a library can ensure 
it monkeypatches that before the users of the library have created any 
classes.


cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
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-04 Thread Victor Stinner 
2013/7/4 Tres Seaver :
> Not commenting on either the form or the substance (pun intended), but
> the word you want is "inheritance" -- "inherence" is a valid term[1], but
> would a good deal stranger notion to apply to a file descriptor. ;)

Oh... I don't know why I wrote "inherance", it was "inheritance" in the PEP 433.

Thanks, I fixed the typo in the PEP 466.

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

2013-07-04 Thread Cameron Simpson 
First up I broadly like this.

You might want to make clear that the "blocking" parameter refers
only to the file creation calls (eg socket.socket) and not to the
file descriptor itself, and is not to be confused with the UNIX
O_NONBLOCK file descriptor flag (and whatever equivalent flag may
apply on Windows).

This is deducable from your PEP, but I was at first confused, and
initially expected get_blocking/set_blocking functions in New
Functions.

On 04Jul2013 13:03, Victor Stinner  wrote:
| Other Changes
| -
| The ``subprocess.Popen`` class must clear the close-on-exec flag of file
| descriptors of the ``pass_fds`` parameter.

I would expect Popen and friends to need to both clear the flag to
get the descriptors across the fork() call, and _possibly_ to set
the flag again after the fork. Naively, I would expect the the flag
to be as it was before the Popen call, after the call.

This is not addressed.

Cheers,
-- 
Cameron Simpson 

Time is nature's way of keeping everything from happening at once.
___
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-04 Thread Cameron Simpson 
On 05Jul2013 10:41, I wrote:
| On 04Jul2013 13:03, Victor Stinner  wrote:
| | Other Changes
| | -
| | The ``subprocess.Popen`` class must clear the close-on-exec flag of file
| | descriptors of the ``pass_fds`` parameter.
| 
| I would expect Popen and friends to need to both clear the flag to
| get the descriptors across the fork() call, and _possibly_ to set
| the flag again after the fork. Naively, I would expect the the flag
| to be as it was before the Popen call, after the call.

This is harder than I'd thought through.

Descriptors go across a fork() anyway, and after an exec() there is nobody to
change their state.

In order for the parent to restore the prior close-on-exec state
(if deemed the right thing to do) it would need to know when the
exec was done in the child.

You'd need something like an extra descriptor attached to a pipe
marked close-on-exec so that the parent could see EOF on the read
end after the exec, since the exec would close the write end.
tractable, but baroque.

So I'd have the PEP take a position on the post-exec() state of the
passed file descriptors, and if state is not going to be restored
it should outright say that passing an fd clears the close-on-exec
flag. Which is it does, but I think the doco should be pretty overt
about:

  - this side effect of clearing close-on-exec on these fds

  - that the file descriptor and its close-on-exec state is common
between the parent and the child

  - that setting of close-on-exec on the fds in the parent could
in principle comprimise the exec in the child if done too soon

If you decide state should get restored, the implementation gets a
bit fiddlier to detect the exec() in the child. I can't speak for
what might be required on non-UNIX.

Cheers,
-- 
Cameron Simpson 

Agree, for Law is costly. -- Very good advice to litigious Persons, founded
upon Reason and Experience; for many Times the Charges of a Suit exceed the
Value of the Thing in Dispute. - Bailey's dictionary, 1736
___
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-04 Thread Victor Stinner 
2013/7/5 Cameron Simpson :
> You might want to make clear that the "blocking" parameter refers
> only to the file creation calls (eg socket.socket) and not to the
> file descriptor itself, and is not to be confused with the UNIX
> O_NONBLOCK file descriptor flag (and whatever equivalent flag may
> apply on Windows).

The two following codes are the same:

s = socket.socket(..., blocking=False)

and

s = socket.socket(...)
s.setblocking(False)

Both set O_NONBLOCK flag (UNIX) or clear HANDLE_FLAG_INHERIT (Windows)
on the socket (which is a file descriptor).

socket.socket(..., blocking=False) cannot fail with EAGAIN or
EWOULDBLOCK (at least on Linux according to the manual page).

> This is deducable from your PEP, but I was at first confused, and
> initially expected get_blocking/set_blocking functions in New
> Functions.

socket objects already have get_blocking() and set_blocking() methods.
If we supported the blocking flag on any file descriptor, it would
make sense to add such function to the os module. But I explained in
the "Add blocking parameter for file descriptors and Windows
overlapped I/O" section why I only want to set/clear the blocking file
on sockets.

> I would expect Popen and friends to need to both clear the flag to
> get the descriptors across the fork() call, and _possibly_ to set
> the flag again after the fork. Naively, I would expect the the flag
> to be as it was before the Popen call, after the call.

As explained in the "Inheritance of file descriptors" section, the
close-on-exec flag has no effect on fork:

"The flag has no effect on fork(), all file descriptors are inherited
by the child process."

The close-on-exec flag is cleared after the fork and before the
exec(). Pseudo-code for Popen:

pid = os.fork()
if pid:
  return pid
# child process
for fd in pass_fds: os.set_cloexec(fd, False)
os.execv(...)

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