Re: [Python-ideas] Is this PEP-able? "with" statement inside genexps / list comprehensions
On Monday, July 30, 2018 at 3:55:25 PM UTC-4, Kyle Lahnakoski wrote: > > Rudy, > > I think your proposal may be very specific to iterable context managers; > I don't think his proposal is specific to iterable context managers. You can have a with clause that is used in a following for clause. in which case, make a method that makes that assumption: > > > def iter_with(obj): > > with obj as context: > > yield from context > > and use it > > > g = ( > > f.read() > > for fn in filenames > > for f in iter_with(open(fn)) > > ) > > On 2018-07-30 15:15, Rudy Matela wrote: > > Hello, > > > > Do you think it would be nice to allow with statements inside genexps or > > list comprehensions? The functions __enter__ and __exit__ would be > > automatically called as iterables are traversed. I am thinking of > > drafting a PEP about this. Examples: > > > > > > This > > > > g = (f.read() for fn in filenames with open(fn) as f) > > > > would be equivalent to the following use of a generator function: > > > > def __gen(): > > for fn in filenames: > > with open(fn) as f: > > yield f.read() > > g = __gen() > > > > > > This > > > > list = [f.read() for fn in filenames with open(fn) as f] > > > > would be equivalent to the following: > > > > list = [] > > for fn in filenames: > > with open(fn) as f: > > list.append(f.read()) > > > > -- > > Rudy > > ___ > > Python-ideas mailing list > > python...@python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ > Python-ideas mailing list > python...@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > >___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Syntactic sugar to declare partial functions
Therefore one can do a decorator that gives .partial:
def partialize(f):
from functools import partial
f.partial = lambda *a, **b: partial(f, *a, **b)
return f
@partialize
def f(x,y):
return x-y
g = f.partial(5)
g(3)
That's the same idea as funcoperators.partially but doesn't return a new
function (which has the advantage of keeping help(f))
Le sam. 11 août 2018 à 14:53, Robert Vanden Eynde a
écrit :
>
>
> Le sam. 11 août 2018 à 10:34, Vincent Maillol
> a écrit :
>
>> Hello,
>>
>> Currently the user defined functions are mutables, there can be existed
>> python codes like this:
>>
>> >>> def foo():
>> ... pass
>> ...
>> >>> if not hasattr(foo, 'partial'):
>> ... foo.partial = {}
>> ...
>>
>> Adding a new method to function object can break existing projects, but
>> it is without impact with buit-in functions because they are immutables.
>>
>>
> Or use a decorator like in the lib ?
>
> from funcoperators import partially
>
> @partially
> def f(x, y):
> return x-y
>
> g = f.part(4)
> g(5)
>
> The mutability solution however cannot have a "self" argument :
>
> def f(x,y):
> return x-y
>
> f.stuff = lambda self: self(5, 2)
> f.stuff() # missing self
>
> One would have to give "f".
>
> f.partial = lambda *a, **b: functools.partial(f, *a, **b)
>
> g = f.partial(4)
> g(5)
>
>
>> 2018-08-09 18:59 GMT+02:00 Michel Desmoulin :
>>
>>> I'd rather have functools.partial() to be added as a new method on
>>> function objects.
>>>
>>> >
>>> > fromfunctools importpartial
>>> >
>>> >
>>> > def add(x:int,y:int)->int:
>>> > returnx +y
>>> >
>>> >
>>> > add_2 = partial(add,2)
>>> >
>>>
>>> Would become:
>>>
>>> add_2 = add.partial(2)
>>>
>>> Nothing to change on the parser, no obscure syntax for future readers,
>>> and we can get the opportunity of rewriting partial() in C as right now
>>> it is amazingly way, way slower than a lambda.
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Syntactic sugar to declare partial functions
Le sam. 11 août 2018 à 10:34, Vincent Maillol a
écrit :
> Hello,
>
> Currently the user defined functions are mutables, there can be existed
> python codes like this:
>
> >>> def foo():
> ... pass
> ...
> >>> if not hasattr(foo, 'partial'):
> ... foo.partial = {}
> ...
>
> Adding a new method to function object can break existing projects, but it
> is without impact with buit-in functions because they are immutables.
>
>
Or use a decorator like in the lib ?
from funcoperators import partially
@partially
def f(x, y):
return x-y
g = f.part(4)
g(5)
The mutability solution however cannot have a "self" argument :
def f(x,y):
return x-y
f.stuff = lambda self: self(5, 2)
f.stuff() # missing self
One would have to give "f".
f.partial = lambda *a, **b: functools.partial(f, *a, **b)
g = f.partial(4)
g(5)
> 2018-08-09 18:59 GMT+02:00 Michel Desmoulin :
>
>> I'd rather have functools.partial() to be added as a new method on
>> function objects.
>>
>> >
>> > fromfunctools importpartial
>> >
>> >
>> > def add(x:int,y:int)->int:
>> > returnx +y
>> >
>> >
>> > add_2 = partial(add,2)
>> >
>>
>> Would become:
>>
>> add_2 = add.partial(2)
>>
>> Nothing to change on the parser, no obscure syntax for future readers,
>> and we can get the opportunity of rewriting partial() in C as right now
>> it is amazingly way, way slower than a lambda.
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Consider adding an iterable option to dataclass
My only motivation for this idea is so that I can forget about namedtuple. Thinking about it again today, I withdraw my suggestion until I one day see a need for it. On Fri, Aug 10, 2018 at 10:14 PM Eric V. Smith wrote: > On 8/10/2018 7:01 PM, Neil Girdhar wrote: > > It would be nice if dataclasses > > ( > https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass) > > had an option to make them a sequence. This would make > > > > dataclass(frozen=True, order=True, sequence=True) > > > > an optionally-typed version of namedtuple. It would almost totally > > supplant it except that namedtuples have a smaller memory footprint. > > Note that type.NamedTuple already gives you typed namedtuples. > Admittedly the feature set is different from dataclasses, though. > > > sequence would simply inherit from collections.abc.Sequence and > > implement the two methods __len__ and __getitme__. > > Unless I'm misunderstanding you, this falls in to the same problem as > setting __slots__: you need to return a new class, in this case since > you can't add inheritance after the fact. I don't think > __isinstancecheck__ helps you here, but maybe I'm missing something (I'm > not a big user of inheritance or ABCs). > > Not that returning a new class is impossible, it's just that I didn't > want to do it in the first go-round with dataclasses. > That's a fair point. I'm sure you know that your decorator could always return a new class that inherits from both Sequence and the original class. As a user of dataclass, I never assumed that it wouldn't do this. > For slots, I have a sample @add_slots() at > https://github.com/ericvsmith/dataclasses/blob/master/dataclass_tools.py. > Maybe we could do something similar with @add_sequence() and test it > out? It would have to be a little more sophisticated than @add_slots(), > since it would need to iterate over __dataclass_fields__, etc. > > I'm on vacation next week, maybe I'll play around with this. > Cool, have a great vacation. > > Eric > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "python-ideas" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/python-ideas/8C9iVJsba5A/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > python-ideas+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Syntactic sugar to declare partial functions
Hello,
Currently the user defined functions are mutables, there can be existed
python codes like this:
>>> def foo():
... pass
...
>>> if not hasattr(foo, 'partial'):
... foo.partial = {}
...
Adding a new method to function object can break existing projects, but it
is without impact with buit-in functions because they are immutables.
2018-08-09 18:59 GMT+02:00 Michel Desmoulin :
> I'd rather have functools.partial() to be added as a new method on
> function objects.
>
> >
> > fromfunctools importpartial
> >
> >
> > def add(x:int,y:int)->int:
> > returnx +y
> >
> >
> > add_2 = partial(add,2)
> >
>
> Would become:
>
> add_2 = add.partial(2)
>
> Nothing to change on the parser, no obscure syntax for future readers,
> and we can get the opportunity of rewriting partial() in C as right now
> it is amazingly way, way slower than a lambda.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
