Re: [Python-ideas] [Python-Dev] Language proposal: variable assignment in functional context

[Steven D'Aprano]

Welcome Robert. My response below.

Follow-ups to Python-Ideas, thanks. You'll need to subscribe to see any 
further discussion.


On Fri, Jun 16, 2017 at 11:32:19AM +, Robert Vanden Eynde wrote:

> In a nutshell, I would like to be able to write:
> y = (b+2 for b = a + 1)

I think this is somewhat similar to a suggestion of Nick Coghlan's. One 
possible syntax as a statement might be:

y = b + 2 given:
b = a + 1


https://www.python.org/dev/peps/pep-3150/

In mathematics, I might write:

y = b + 2 where b = a + 1

although of course I wouldn't do so for anything so simple. Here's a 
better example, the quadratic formula:

  -b ± √Δ
x =  ─
 2a

where Δ = b² - 4ac

although even there I'd usually write Δ in place.


> Python already have the "functional if", lambdas, list comprehension, 
> but not simple assignment functional style.

I think you mean "if *expression*" rather than "functional if". The term 
"functional" in programming usually refers to a particular paradigm:

https://en.wikipedia.org/wiki/Functional_programming


-- 
Steve
___
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] [Python-Dev] Language proposal: variable assignment in functional context

[Erik]

[cross-posted to python-ideas]

Hi Robert,

On 16/06/17 12:32, Robert Vanden Eynde wrote:
Hello, I would like to propose an idea for the language but I don't know 
where I can talk about it.


Can you please explain what the problem is that you are trying to solve?


In a nutshell, I would like to be able to write:
y = (b+2 for b = a + 1)


The above is (almost) equivalent to:

y = (a+1)+2

I realize the parentheses are not required, but I've included them 
because if your example mixed operators with different precedence then 
they might be necessary.


Other than binding 'b' (you haven't defined what you expect the scope of 
that to be, but I'll assume it's the outer scope for now), what is it 
about the form you're proposing that's different?



Or in list comprehension:
Y = [b+2 for a in L for b = a+1]

Which can already be done like this:
Y = [b+2 for a in L for b in [a+1]]


Y = [(a+1)+2 for a in L]

Which is less obvious, has a small overhead (iterating over a list) and 
get messy with multiple assignment:

Y =  [b+c+2 for a in L for b,c in [(a+1,a+2)]]

New syntax would allow to write:
Y =  [b+c+2 for a in L for b,c = (a+1,a+2)]


Y = [(a+1)+(a+2)+2 for a in L]

My first example (b+2 for b = a+1) can already be done using ugly syntax 
using lambda


y = (lambda b: b+2)(b=a+1)
y = (lambda b: b+2)(a+1)
y = (lambda b=a+1: b+2)()

Choice of syntax: for is good because it uses current keyword, and the 
analogy for x = 5 vs for x in [5] is natural.


But the "for" loses the meaning of iteration.
The use of "with" would maybe sound more logical.

Python already have the "functional if", lambdas, list comprehension, 
but not simple assignment functional style.


Can you present an example that can't be re-written simply by reducing 
the expression as I have done above?


Regards, E.
___
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] Define __fspath__() for NamedTemporaryFile and TemporaryDirectory

[Ethan Furman]

On 06/16/2017 01:37 PM, Alexandre Brault wrote:


So a  if used directly, and a  if used as a
context manager.  I don't have a copy of 3.6 nor the future 3.7 handy,
so maybe it changed there?


The code in master has the context manager return `self.name`. This
behaviour has (based on looking at the 3.2 tag where TemporaryDirectory
was added) always been used.


It is an often overlooked fact that a context manager is free to return anything, not just itself.  So 
TemporaryDirectory can create the folder, return the name of the folder, and remove the folder on exit.  So no need for 
the "extract the name from the object" dance.  Interestingly enough, that is what the docs say [1].


Pretty cool.

--
~Ethan~

[1] https://docs.python.org/3/library/tempfile.html#tempfile.TemporaryDirectory
___
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] Define __fspath__() for NamedTemporaryFile and TemporaryDirectory

[Thomas Jollans]

On 08/06/17 15:42, Antoine Pietri wrote:
> Hello everyone!
>
> A very common pattern when dealing with temporary files is code like this:
>
> with tempfile.TemporaryDirectory() as tmpdir:
> tmp_path = tmpdir.name
>
> os.chmod(tmp_path)
> os.foobar(tmp_path)
> open(tmp_path).read(barquux)

Is it?

py> import tempfile
py> with tempfile.TemporaryDirectory() as tmpdir:
... print(tmpdir, type(tmpdir))
...
/tmp/tmp2kiqzmi9 
py>


>
> PEP 519 (https://www.python.org/dev/peps/pep-0519/) introduced the
> concept of "path-like objects", objects that define a __fspath__()
> method. Most of the standard library has been adapted so that the
> functions accept path-like objects.
>
> My proposal is to define __fspath__() for TemporaryDirectory and
> NamedTemporaryFile so that we can pass those directly to the library
> functions instead of having to use the .name attribute explicitely.
>
> Thoughts? :-)
>

-- 
Thomas Jollans

m ☎ +31 6 42630259
e ✉ t...@tjol.eu

___
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] Restore the __members__ behavior to python3 for C extension writers

[Nick Coghlan]

On 16 June 2017 at 07:44, Barry Scott  wrote:
> But I need the result of __dir__ for my object not its base. Then I need to
> add in the list of member attributes that are missing because python
> itself has no knowledge of them they are accessed via getattr().

The C code:

   dir_result = PyObject_CallMethod(base_type, "__dir__", "O", self);

is roughly equivalent to the Python code:

dir_result = BaseType.__dir__(self)

That is, it's calling the base type's __dir__ method, but it's still
using the subclass *instance*.

It's the same pattern people use to call a base type's __getattr__ or
__getattribute__ for the subclass implementation of those methods,
just without multiple inheritance support (since calling super() from
C is painful).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/