Re: [Python-Dev] multiprocessing BaseManager's "serializer" argument

2014-03-27 Thread Yuriy Taraday
On Thu, Mar 27, 2014 at 8:42 PM, Brett Cannon wrote: > Creating the bug is the best bet as then the reason can be discussed > there. If there are no objections then you can create a patch to make sure > it's tested and documented. Created http://bugs.python.org/issue21078 -- Kind regards, Yu

[Python-Dev] multiprocessing BaseManager's "serializer" argument

2014-03-27 Thread Yuriy Taraday
Hello. Is there any reason BaseManager's "serializer" argument has never been documented? We're going to use BaseManager for simple secure local RPC and for the "secure" part we can't use pickle. Can we hope that argument won't go away? Should I create a bug and provide some patch for the docs to

Re: [Python-Dev] PEP 455: TransformDict

2013-10-08 Thread Yuriy Taraday
On Tue, Oct 8, 2013 at 10:17 PM, MRAB wrote: > If you don't need the original key, then you might as well just use a > transform function with a dict. As I understood, storing original keys is not the purpose of TransformDict, allowing hashing on something other then provided key itself is. Thi

Re: [Python-Dev] PEP 455: TransformDict

2013-10-08 Thread Yuriy Taraday
On Fri, Sep 13, 2013 at 10:40 PM, Antoine Pitrou wrote: > > Hello, > > Following the python-dev discussion, I've written a PEP to recap the > proposal and the various arguments. It's inlined below, and it will > probably appear soon at http://www.python.org/dev/peps/pep-0455/, too. > > Regards > >

Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

2013-01-09 Thread Yuriy Taraday
On Wed, Jan 9, 2013 at 1:39 PM, Antoine Pitrou wrote: > > Hi Yuriy, > > For the record, it isn't necessary to cross-post. python-ideas is > the place for discussing this, and most interested people will be > subscribed to both python-ideas and python-dev, and therefore they get > duplicate messag

Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

2013-01-09 Thread Yuriy Taraday
On Wed, Jan 9, 2013 at 10:02 AM, Guido van Rossum wrote: > Changing event loops in the middle of event processing is not a common > (or even useful) pattern. You start the event loop and then leave it > alone. > Yes. It was not-so-great morning idea. > Yes, 'write' part is good, I should menti

Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

2013-01-09 Thread Yuriy Taraday
On Wed, Jan 9, 2013 at 8:50 AM, Guido van Rossum wrote: > On Tue, Jan 8, 2013 at 8:31 PM, Guido van Rossum wrote: > > On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday > wrote: > >> - pause() and resume() work with reading only, so they should be > suffixed > >>

Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

2013-01-08 Thread Yuriy Taraday
On Wed, Jan 9, 2013 at 9:14 AM, Guido van Rossum wrote: > On Tue, Jan 8, 2013 at 9:02 PM, Yuriy Taraday wrote: > > Should transports be bound to event loop on creation? I wonder, what > would > > happen if someone changes current event loop between these calls. > &g

Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

2013-01-08 Thread Yuriy Taraday
On Wed, Jan 9, 2013 at 8:31 AM, Guido van Rossum wrote: > On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday wrote: > > I've read the PEP and some things raise questions in my consciousness. > Here > > they are. > > Thanks! > > > 1. Series of sock_ methods can b

Re: [Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

2013-01-08 Thread Yuriy Taraday
On Wed, Jan 9, 2013 at 6:31 AM, Nick Coghlan wrote: > On Wed, Jan 9, 2013 at 11:14 AM, Yuriy Taraday > wrote: > > 4. Why separate exception() from result() for Future class? It does the > same > > as result() but with different interface (return instead of raise). > Does

[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

2013-01-08 Thread Yuriy Taraday
Hello. I've read the PEP and some things raise questions in my consciousness. Here they are. 1. Series of sock_ methods can be organized into a wrapper around sock object. This wrappers can then be saved and used later in async-aware code. This way code like: sock = socket(...) # later,