[Python-ideas] Fwd: Conditional context manager

2016-10-02 Thread Nick Coghlan 
Forwarding to the list, since I took the broken Google Group cc out of
the reply list, but didn't added the proper one.


-- Forwarded message --
From: Nick Coghlan 
Date: 2 October 2016 at 17:45
Subject: Re: [Python-ideas] Conditional context manager
To: Neil Girdhar 


On 2 October 2016 at 04:07, Neil Girdhar  wrote:
> I'm just throwing this idea out there to get feedback.
>
> Sometimes, I want to conditionally enter a context manager.  This simplest
> (afaik) way of doing that is:
>
> with ExitStack() as stack:
> if condition:
> cm = stack.enter_context(cm_function())
> suite()
>
> I suggest a more compact notation:
>
> with cm_function() as cm if condition:
> suite()

As Chris notes, this is typically going to be better handled by
creating an *un*conditional CM that encapsulates the optionality so
you don't need to worry about it at the point of use.

If you wanted a generic version of that, then the stack creation and
cm creation can be combined into a single context manager:

@contextmanager
def optional_cm(condition, cm_factory, *args, **kwds):
stack = ExitStack()
cm = None
with stack:
if condition:
cm = stack.enter_context(cm_factory(*args, **kwds))
yield stack, cm

However, even simpler than both this and Chris's maybe_cm() example is
the plain ExitStack-as-the-null-context-manager function approach
already covered in the contextlib docs:
https://docs.python.org/3/library/contextlib.html#simplifying-support-for-single-optional-context-managers

Applying that approach to this particular pattern looks like:

def optional_cm(condition, cm_factory, *args, **kwds):
if condition:
return cm_factory(*args, **kwds)
return ExitStack()

Resulting in:

with optional_cm(condition, cm_function):
suite()

which is fine for a construct that is uncommon in general, but may be
popular in a particular code base.

Cheers,
Nick.

--
Nick Coghlan   |   [email protected]   |   Brisbane, Australia


-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] async objects

2016-10-02 Thread Rene Nejsum 
Having followed Yury Selivanov yselivanov.ml at gmail.com  
proposal to add async/await to Python  (PEP 492 Coroutines with async and await 
syntax and (PEP 525  Asynchronous Generators) and and especially the discussion 
about PEP 530: Asynchronous Comprehensions  I would like to add some concerns 
about the direction Python is taking on this.

As Sven R. Kunze srkunze at mail.de  mentions the is a risk of 
having to double a lot of methods/functions to have an Async implementation. 
Just look at the mess in .NET  when Microsoft introduced async/await in their 
library, a huge number of functions had to be implemented with a Async version 
of each member. Definitely not the DRY principle.

While I think parallelism and concurrency are very important features in a 
language, I feel the direction Python is taking right now is getting to 
complicated, being difficult to understand and implement correct.

I thought it might be worth to look at using async at a higher level. Instead 
of making methods, generators and lists async, why not make the object itself 
async? Meaning that the method call (message to object) is async

Example:

class SomeClass(object):
   def some_method(self):
   return 42

o = async SomeClass()  # Indicating that the user want’s an async version of 
the object
r = o.some_method()# Will implicit be a async/await “wrapped” method no 
matter impl.
# Here other code could execute, until the result (r) is referenced
print r

I think above code is easier to implement, use and understand, while it handles 
some of the use cases handled by defining a lot of methods as async/await.

I have made a small implementation called PYWORKS 
(https://github.com/pylots/pyworks ), 
somewhat based on the idea above. PYWORKS has been used in several real world 
implementation and seams to be fairly easy for developers to understand and use.

br
/Rene

PS. This is my first post to python-ideas, please be gentle :-)___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/