Re: [Python-ideas] Suggestion: Clear screen command for the REPL

[Greg Ewing]

Terry Reedy wrote:
In the default 
mode with user code executed in a separate no-window process, there is 
currently no way for the child process to know the current size of 
Shell's tk text window in the parent process.


On unix it should be possible to let the child know if it's
connected through a pty rather than a pipe. I don't know
whether Windows has any equivalent notion, though.

--
Greg
___
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] Make partial a built-in

[Greg Ewing]

אלעזר wrote:
@partial(partial, partial(partial, partial)) 
def add(a, b, c): return a + b + c


For large numbers of arguments, it's much clearer if you
write it this way:

>>> from functools import partial as badger, partial as mushroom
>>> @badger(badger, badger(badger, badger(badger, mushroom)))
... def add(a,b,c,d):
...  return a+b+c+d
...
>>> add(1)(2)(3)(4)
10

--
Greg
___
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] Overloading operators for testing

[Mark Lawrence via Python-ideas]

On 21/09/2016 00:14, Neil Girdhar wrote:

As Ryan points out, pytest does this right.  The way I understand it,
pytest is actively maintained and nose isn't.  You should switch to
pytest as soon as possible.

Best,

Neil


Nose is no longer maintained but long live nose2 
https://pypi.python.org/pypi/nose2/0.6.5 https://github.com/nose-devs/nose2


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] Make partial a built-in

[Steven D'Aprano]

Folks,


There are pros and cons of partial over lambda over classes, and which 
you prefer may be at least in part a matter of subjective taste. But 
Guido has spoken that he is virulently against making partial a builtin. 
It really isn't hard to put "from functools import partial" at the top 
of your modules. Can we let this thread die a natural death now please?


-- 
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] Make partial a built-in

[אלעזר]

This class should be put somewhere. If you need it from inside a method,
you have to choose where to put it. If it is inside the method, it forces
the reader to scan it thoroughly to verify there's no "real" closure there,
and it also makes your methods significantly longer. If it is outside the
whole class, it might be very far away from your logic, doing a very simple
thing that is not needed anywhere else.

Elazar

On Wed, Sep 21, 2016 at 5:32 AM Dan Sommers  wrote:

> On Tue, 20 Sep 2016 15:29:36 +, אלעזר wrote:
>
> > The alternative to partial is writing a closure in the form of a
> > function, that needs to be carefully inspected to verify that it is
> > indeed just a partial application and not something more complex. It
> > has more opportunity for introducing an error. And it's longer and
> > adds distance between related parts of the code.
>
> While I'm not usually one to promote object oriented programming,
> another Python alternative is a class with a __call__ method; e.g.:
>
> class Adder:
> def __init__(self, addend_one):
> self.addend_one = addend_one
> def __call__(self, addend_two):
> return self.addend_one + addend_two
>
> add_5 = Adder(5)
> print(add_5(4))
>
> I like the way the whole thing is bundled up into a class.  Yes, it's
> more verbose than a lambda expression or a partial function application,
> but I find it very readable and its intent is usually pretty obvious.
>
> Instances are closures in disguise (and they're all just different ways
> of hiding state of one kind or another).
>
> ___
> 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] Make partial a built-in

[Dan Sommers]

On Tue, 20 Sep 2016 15:29:36 +, אלעזר wrote:

> The alternative to partial is writing a closure in the form of a
> function, that needs to be carefully inspected to verify that it is
> indeed just a partial application and not something more complex. It
> has more opportunity for introducing an error. And it's longer and
> adds distance between related parts of the code.

While I'm not usually one to promote object oriented programming,
another Python alternative is a class with a __call__ method; e.g.:

class Adder:
def __init__(self, addend_one):
self.addend_one = addend_one
def __call__(self, addend_two):
return self.addend_one + addend_two

add_5 = Adder(5)
print(add_5(4))

I like the way the whole thing is bundled up into a class.  Yes, it's
more verbose than a lambda expression or a partial function application,
but I find it very readable and its intent is usually pretty obvious.

Instances are closures in disguise (and they're all just different ways
of hiding state of one kind or another).

___
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] Overloading operators for testing

[Steven D'Aprano]

On Sun, Sep 18, 2016 at 02:52:31AM +0200, Arek Bulski wrote:
> I am using declarative testing a lot and I found out why unit tests are so
> clunky.

I don't think unit tests are clunky.


> The reason why assertEquals(a,b) is used is because if we put
> `assert a==b` then nose can catch the AssertionError but wont find out what
> was returned or expected. 

That's not the only reason.

assert* methods can take an arbitrary number of arguments. == cannot.

It is easy to extend the collection of assert* methods, to use 
inheritance to modify them, and so on. Not so easy if you have only a 
single, global function or operator.

assert* methods can run even when assertions are disabled.


> This could be easily overcome if we allow
> oveloading == operator from outside. Right now == would have to be changed
> for every lefhand object that is compared in the tests, builtin types
> including. We could use a way to change it from above, so to speak.

Having global state that controls the behaviour of == is not a good 
idea. Look at your proposed code:

> Consider this:
> 
> def __glob_eq__(a,b):
>   if not a == b:
>   raise FoundInequalityError(a,b)
>   return True
> 
> assert obj1 == obj2   #<-- using eq above

That can't work as you have written it, because it will recurse forever. 
obj1 == obj2 will call the global eq, which calls == which calls the 
global eq, which calls == which calls the global eq. 

So let's re-write it:

def __glob_eq__(a,b):
saved_state = get_global_eq()
delete_global_eq()
try:
if not a == b:  # calls the real ==
raise FoundInequalityError(a,b)
return True
finally:
set_global_eq(saved_state)


Okay, that's pretty yucky, and its not thread-safe, but at least its 
only in one place, right? Except it isn't. Every single call to == (and 
!= ) will have to be re-written to do the same thing.

And of course, that just replaces assertEquals. What about all the other 
assert* methods?

But there's another, more fundamental problem with using assert in this 
way. You cannot run your unit tests with assertions turned off.

That is why I think the nose style of using "assert a == b" for unit 
testing is seriously broken. That is an abuse of the assert statement. 
It's good enough for a handful of quick and dirty tests, but is not good 
enough for a full-sized unit test suite.


-- 
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] Suggestion: Clear screen command for the REPL

[Terry Reedy]

On 9/20/2016 9:31 AM, Steven D'Aprano wrote:

On Mon, Sep 19, 2016 at 06:18:38AM -0400, Terry Reedy wrote:

On 9/19/2016 4:31 AM, Paul Moore wrote:


shutil.get_terminal_size() is available on all platforms.


On windows, it works with Command Prompt and PowerShell but fails in
IDLE, as it must.


Why "must" it fail?


Good question.  When I wrote that, I had in mind the qualification 'in 
IDLE's default mode, as IDLE is currently structured'.  In the default 
mode with user code executed in a separate no-window process, there is 
currently no way for the child process to know the current size of 
Shell's tk text window in the parent process.  But this is not the real 
story.  See below.



What is it about the IDLE terminal that prevents it from emulating an
actual terminal, like all(?) the other terminal emulation programs
people use?


IDLE's Shell is based on a tk Text and by design is not a terminal 
emulation.  (Which terminal would it emulate?).  Note that with 
proportional fonts, a text editor does not really have character 
columns, though it can be sized according to some 'average' character 
width.  Also, IDLE is a development environment, not a run environment, 
and this impacts a few decisions.



I just opened my Konqueror file & web browser, gave the command "Show
Terminal Emulator", and ran Python:

py> import shutil
py> shutil.get_terminal_size()
os.terminal_size(columns=85, lines=10)

That's spot on perfectly correct. I then resized the window and tried it
again:

py> shutil.get_terminal_size()
os.terminal_size(columns=108, lines=13)


This is what I did and equivalently got with Command Prompt.


I then quit Python, and ran idle3.3 from the Konqueror terminal.
Unfortunately, get_terminal_size() returned the size of the *Konqueror*
terminal, instead of the IDLE terminal. I think that's a bug. I don't
know if its a bug in IDLE or get_terminal_size() or both.


If I run IDLE from Command Prompt, without or with the currently 
deprecated -n option, to run user code in the original IDLE process 
instead of a separate subprocess, I get the same -- the current size of 
the parent Command Prompt.


The reason is that shutil.get_terminal_size first looks for 
int(os.environ['COLUMNS']) (or 'LINES') and if that fails, calls
os.get_terminal_size(sys.__stdout__.fileno()).  In both cases, the 
latter refer to the parent console.


The 'obvious' possible solution is for Shell to set the environment 
variables when created or modified.  On creation would be easy. 
Unfortunately, there is not, AFAIK, an application-accessible Resize 
event.  A feature of tk is that geometry managers handle resizing 
automatically once the user sets the parameters of which widgets can be 
resized, and if so, min sizes and relative weights.  But maybe there is 
a workaround.


I am also not sure if modified environ is propagated to subprocesses. 
On Posix, subprocess.Popen uses os.execvp, so the parent environment is 
inherited by the new process.  I don't know if this means that 
subsequent changes are inherited.  On Windows, Popen used the system 
CreateProcess and I don't know what this does.


A workaround would be to monkeypatch the function.  In the rarely used 
-n mode, this would be easy.  In normal mode, this would require the 
execution server to send an rpc message to the Shell client asking for 
its dimensions so the server can format the string to send to the 
client.  I do not know if the current rpc mechanism is set up for 
requests from server to client.


If not fixed soon, I should add the limitation to the IDLE doc.

--
Terry Jan Reedy

___
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] Overloading operators for testing

[Neil Girdhar]

As Ryan points out, pytest does this right.  The way I understand it, 
pytest is actively maintained and nose isn't.  You should switch to pytest 
as soon as possible.

Best,

Neil

On Saturday, September 17, 2016 at 8:55:43 PM UTC-4, Arek Bulski wrote:
>
> I am using declarative testing a lot and I found out why unit tests are so 
> clunky. The reason why assertEquals(a,b) is used is because if we put 
> `assert a==b` then nose can catch the AssertionError but wont find out what 
> was returned or expected. This could be easily overcome if we allow 
> oveloading == operator from outside. Right now == would have to be changed 
> for every lefhand object that is compared in the tests, builtin types 
> including. We could use a way to change it from above, so to speak. 
> Consider this:
>
> def __glob_eq__(a,b):
>   if not a == b:
>   raise FoundInequalityError(a,b)
>   return True
>
> assert obj1 == obj2   #<-- using eq above
>
> Nose could easily catch FoundInequalityError and print whatever 
> assertEquals would. This goes very handy when you consider declarative unit 
> testing that I use in my project. I have a  unitest.TestCase derivative and 
> the actual testcase has a method that yields individual comparisons, like 
> this:
>
> class TestBinary(declarativeunittest.TestCase):
> def alltestsinteractive(self):
>
> yield [func(1) == 2]
> shuffle(alist)
> yield [sorted(alist) == [1,2,3]]
>
> Notice that this allows to put imperative statements in between 
> declarative cases. So shuffled() is no longer necessary in this code. :)
>
> pozdrawiam,
> Arkadiusz Bulski
>
>___
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] Make partial a built-in

[אלעזר]

On Wed, Sep 21, 2016 at 12:04 AM Terry Reedy  wrote:

> On 9/20/2016 11:51 AM, Guido van Rossum wrote:
>
> ... (The greater flexibility of lambda, pointed out by David Mertz, is
> another.)
>
>
I just wanted to point out that the greater flexibility of lambda is a very
good reason *not* to choose it: more flexibility implies being harder to
reason about. I recommend reading this article about "Principle of Least
Power"
http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html

Elazar
___
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] Make partial a built-in

[Terry Reedy]

On 9/20/2016 11:51 AM, Guido van Rossum wrote:


We seem to have fundamentally different ideas of what sort of code is
most readable. The alternative to partial is usually a lambda,


Partial and lambda are different in that partial captures variable 
values immediately, whereas lambda does not, unless the default argument 
trick, with its attendant disadvantages, is used.  I consider this one 
reason to chose one or the other.  (The greater flexibility of lambda, 
pointed out by David Mertz, is another.)


# Demonstration
from functools import partial

def f(a): print(a)

# lambda

fl = []
for i in range(3):
fl.append(lambda: f(i))
fl[0]()
# 2 - bug

flc = [lambda: f(i) for i in range(3)]
flc[0]()
# 2 - bug

flcd = [lambda i=i: f(i) for i in range(3)]
flcd[0]()
# 0 - correct

# partial

fp = []
for i in range(3):
fp.append(partial(f, i))
fp[0]()
# 0 - correct

fpc = [partial(f, i) for i in range(3)]
fpc[0]()
# 0 - correct


and the
signature of the lambda helps me understand how it is being called.


The 'i=i' signature is typically left out by beginners creating multiple 
functions in a loop, leading to one of *the* most frequent of FAQs.

https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result

When added 'i=i', better written '_i=i', is misleading, as '_i' is not 
really a parameter and 'i' is not a replaceable default value, but is 
supposed to be a fixed value, as with partial.


I believe in a previous thread about creating functions in a loop, it 
was generally agreed that using partial is better.  (This alternative 
has not made it to the FAQ yet, but I thing it should.)


I otherwise generally agree with what you wrote.

--
Terry Jan Reedy


___
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] from __pip__ import

[Chris Angelico]

On Wed, Sep 21, 2016 at 4:58 AM, אלעזר  wrote:
> I think that combining user convenience and security considerations, there
> should be some way to invoke a GUI version of pip with flashing screen
> asking for permissions to install the library. In situations where
> interaction with the user is not trivial (i.e. when you don't have GUI
> accessible) we can assume that the user is knowledgeable enough to install
> the dependencies by herself. The import statement will be self explanatory
> in this case.

There have been talks of linking pip with Idle, which might do what
you want. I don't know how that has progressed, but it'd be something
to look into.

ChrisA
___
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] Make partial a built-in

[אלעזר]

On Tue, Sep 20, 2016 at 9:18 PM Stephan Houben  wrote:

> I must admit I am a bit partial to partial, you can do fun things like
> this:
>
> >>> from functools import partial
> >>> @partial(partial, partial)
> ... def add(x, y):
> ... return x+y
> ...
> >>> add(3)(4)
> 7
>
> I suppose that isn't exactly going to convince Guide to put it in
> builtins, though.
>
> I quietly LOLed, but note that for three arguments you'll need

@partial(partial, partial(partial, partial))
def add(a, b, c): return a + b + c

>>> add(1)(2)(3)
6

So @curry is the transitive closure or something :)

Elazar
___
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] Make partial a built-in

[Stephan Houben]

I must admit I am a bit partial to partial, you can do fun things like this:

>>> from functools import partial
>>> @partial(partial, partial)
... def add(x, y):
... return x+y
...
>>> add(3)(4)
7

I suppose that isn't exactly going to convince Guide to put it in builtins,
though.

Stephan



2016-09-20 19:48 GMT+02:00 David Mertz :

> I find myself "partializing" in ways partial() doesn't support more often
> than not. E.g.
>
> lambda first, third: myfunc(first, 42, third)
>
> I think it's good to have partial() in functools, but it's two orders of
> magnitude less common than things that should be in builtins.
>
> On Sep 20, 2016 9:42 AM, "Ryan Gonzalez"  wrote:
> > lambda *args, **kw: myfunc(partial_arg, *args, **kw)
> >
> > which isn't more readable than just:
> >
> > partial(myfunc, partial_func)
>
> ___
> 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] Make partial a built-in

[David Mertz]

I find myself "partializing" in ways partial() doesn't support more often
than not. E.g.

lambda first, third: myfunc(first, 42, third)

I think it's good to have partial() in functools, but it's two orders of
magnitude less common than things that should be in builtins.

On Sep 20, 2016 9:42 AM, "Ryan Gonzalez"  wrote:
> lambda *args, **kw: myfunc(partial_arg, *args, **kw)
>
> which isn't more readable than just:
>
> partial(myfunc, partial_func)
___
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] Make partial a built-in

[Jonathan Slenders]

Le 20 sept. 2016 18:42, "Ryan Gonzalez"  a écrit :
> Doing something like:
>
> lambda x, y: myfunc(partial_arg, x, y)
>
> is more error-prone to changes in myfunc's signature.

No, if the signature of the function changes, then the signature of the
partial would also change. The risk is the same.

Jonathan
___
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] Make partial a built-in

[Alexander Belopolsky]

On Tue, Sep 20, 2016 at 11:51 AM, Guido van Rossum 
wrote:

> Also, I once timed it and could not show that partial was faster. This
> surprised me but it was what I measured (in one particular case).


I did similar timings on several occasions in the past and was also
surprised by the results.  Lambdas are often faster than equivalent
partials.  It looks like at least recent versions of Python have ways to
optimize calls to pure Python functions that are not available to functions
implemented in C or called from C.
___
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] Make partial a built-in

[Guido van Rossum]

On Tue, Sep 20, 2016 at 8:29 AM, אלעזר  wrote:

> Guido, can you please elaborate?
>
> "What's going on" is usually that the same arguments are going to be
> passed over and over again, and the programmer wanted to avoid this
> repetition. The other option is adjusting the function to a predefined
> interface.
>

I did a little searching on a large Python code base I have access to, and
that's not what I found. The partial calls don't seem to produce code
that's in any way clearer than the equivalent use of lambda would. My
conclusion is that most people who are, um, partial to partial do so out of
a habit (or perhaps a belief that it's more performant), not to make their
code clearer. (FWIW I found an order of magnitude more uses of lambda than
of partial in the same code base.)

> The alternative to partial is writing a closure in the form of a function,
> that needs to be carefully inspected to verify that it is indeed just a
> partial application and not something more complex. It has more opportunity
> for introducing an error. And it's longer and adds distance between related
> parts of the code.
>

We seem to have fundamentally different ideas of what sort of code is most
readable. The alternative to partial is usually a lambda, and the signature
of the lambda helps me understand how it is being called. I don't see how
the lambda is longer or creates more distance. There are some exceptions,
when the function has a complex signature that should mostly be preserved
(and a few other, rare exceptions). But most of the uses of partial that I
found had exactly one call site and the call site was not calling a complex
signature.

A big problem I have reading code that uses partial is that *unless I
already know the function being partialed*, the partial() call itself gives
me no clue about the signature of that function. So then I have to look for
the call site of the partial (what do you call that?) and then in my head I
have to combine that with the partial parameters and figure out what is
really happening. A lambda would have given me a simple stepping stone. In
effect it's a little bit of "typing" right there, showing me the signature
that's being called, which is useful for reading the code quickly.

Also, I once timed it and could not show that partial was faster. This
surprised me but it wa what I measured (in one particular case).


> Elazar
>
> בתאריך יום ג׳, 20 בספט' 2016, 18:20, מאת Guido van Rossum ‏<
> gvanros...@gmail.com>:
>
>> I am radically opposed to this proposal. Every time I see a partial
>> application I wonder endlessly about what's going on.
>>
>> --Guido (mobile)
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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] Suggestion: Clear screen command for the REPL

[Steven D'Aprano]

On Mon, Sep 19, 2016 at 06:18:38AM -0400, Terry Reedy wrote:
> On 9/19/2016 4:31 AM, Paul Moore wrote:
> 
> >shutil.get_terminal_size() is available on all platforms.
> 
> On windows, it works with Command Prompt and PowerShell but fails in 
> IDLE, as it must.

Why "must" it fail?

What is it about the IDLE terminal that prevents it from emulating an 
actual terminal, like all(?) the other terminal emulation programs 
people use?

I just opened my Konqueror file & web browser, gave the command "Show 
Terminal Emulator", and ran Python:

py> import shutil
py> shutil.get_terminal_size()
os.terminal_size(columns=85, lines=10)

That's spot on perfectly correct. I then resized the window and tried it 
again:

py> shutil.get_terminal_size()
os.terminal_size(columns=108, lines=13)


I then quit Python, and ran idle3.3 from the Konqueror terminal. 
Unfortunately, get_terminal_size() returned the size of the *Konqueror* 
terminal, instead of the IDLE terminal. I think that's a bug. I don't 
know if its a bug in IDLE or get_terminal_size() or both.


-- 
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] Make partial a built-in

[אלעזר]

Guido, can you please elaborate?

"What's going on" is usually that the same arguments are going to be passed
over and over again, and the programmer wanted to avoid this repetition.
The other option is adjusting the function to a predefined interface.

The alternative to partial is writing a closure in the form of a function,
that needs to be carefully inspected to verify that it is indeed just a
partial application and not something more complex. It has more opportunity
for introducing an error. And it's longer and adds distance between related
parts of the code.

Elazar

בתאריך יום ג׳, 20 בספט' 2016, 18:20, מאת Guido van Rossum ‏<
gvanros...@gmail.com>:

> I am radically opposed to this proposal. Every time I see a partial
> application I wonder endlessly about what's going on.
>
> --Guido (mobile)
> ___
> 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] Make partial a built-in

[Guido van Rossum]

I am radically opposed to this proposal. Every time I see a partial
application I wonder endlessly about what's going on.

--Guido (mobile)
___
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] from __pip__ import

[Paul Moore]

On 20 September 2016 at 13:58, Random832  wrote:
> On Tue, Sep 20, 2016, at 07:12, אלעזר wrote:
>> Moreover, being able to do it programmatically is a security risk,
>> since it requires elevated privileges that I don't know how to drop,
>> and most people will not think about doing, but a library
>> implementation will.
>
> Maybe we should be thinking about why pip requires elevated privileges.

I'm not sure to what extent this was a rhetorical question, but
basically because, by default pip installs into the Python
installation directory, and if the user is running a system Python,
that directory is only modifiable by an admin.

You can use --user to make pip install into the user's site-packages.
But that's not the default, and the proposal didn't discuss supplying
any non-default options to pip. Pip could be changed to make the
default --user, but that's not happened yet (and there are some
compatibility issues holding it up). And even ignoring that, what
about *other* pip options that might be needed (for example,
specifying a proxy, or a non-default certificate store)? There's no
capability to specify them in the proposal.

Paul.
___
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] singledispatch for instance methods

[Bar Harel]

At last! Haven't used single dispatch exactly because of that. Thank you
savior!
+1

On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell 
wrote:

> Hi All,
>
> We have a modified version of singledispatch at work which works for
> methods as well as functions.  We have open-sourced it as methoddispatch
> (pypi: https://pypi.python.org/pypi/methoddispatch).
>
> IMHO I thought it would make a nice addition to python stdlib.
>
> What does everyone else think?
>
>
> ___
> 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] from __pip__ import

[Random832]

On Tue, Sep 20, 2016, at 07:12, אלעזר wrote:
> Moreover, being able to do it programmatically is a security risk,
> since it requires elevated privileges that I don't know how to drop,
> and most people will not think about doing, but a library
> implementation will.

Maybe we should be thinking about why pip requires elevated privileges.
___
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] from __pip__ import

[Paul Moore]

On 20 September 2016 at 12:12, אלעזר  wrote:
> Moreover, being able to do it programmatically is a security risk, since it
> requires elevated privileges that I don't know how to drop, and most people
> will not think about doing, but a library implementation will.
>
> So if someone uses subprocess.run(), and the system asks the user for
> elevated privileges, a bug in later code can easily cause serious harm
> instead of failing. Yes, untrusted code should be sandboxed - but it isn't,
> more often than not.

It's not possible to gain elevated privileges without asking the user
(certainly not on Windows, and I don't believe so on Unix). So what
you're talking about is getting people used to the idea that running a
script they grabbed off the internet would ask them to run it
elevated, and they should agree. That sounds to me like a very
dangerous lesson to be teaching.

(rwt gets round this by installing dependencies to a temporary
location for the duration of the script. I *really* recommend that you
look into it if you haven't already).

Paul
___
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] from __pip__ import

[Xavier Combelle]

Le 20/09/2016 à 12:35, Paul Moore a écrit :
>
> While on the whole subject of this, I should also point out that there
> are a lot of potential issues with installing new packages while a
> Python program is running. They are all low-probability, and easy to
> avoid if you're not doing weird things, but for a generally-promoted
> mechanism, we need to explain the corner cases[2], and an approach
> with a list of caveats longer than the main documentation is
> problematic.
>
> 1. If the install fails, you need to catch that and report it to the
> user, in a more friendly manner than pip's output. For example if the
> user has no C compiler and you need a C extension to be built.
> 2. You quite possibly want to suppress pip's output if it's *not* a
> failure, as it'll clutter up the program's real output.
> 3. If the code has already imported foo.bar, then you install a new
> version of foo (there are discussions as to whether pip install foo
> should automatically imply --upgrade, so even if it won't do that by
> default now, it might in the future), and maybe that new version
> doesn't have a bar submodule. So now you have a weird mix of old and
> new code in your process.
> 4. The install mechanism sometimes (I can't recall the details) caches
> the fact that it couldn't import a module. If it does that and then
> later you pip install that module, imports will still fail because the
> information is cached.
>
>
you forget the use of a linux where it will fail with high probability
because
by default, pip need to have super user right
___
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] from __pip__ import

[אלעזר]

Moreover, being able to do it programmatically is a security risk, since it
requires elevated privileges that I don't know how to drop, and most people
will not think about doing, but a library implementation will.

So if someone uses subprocess.run(), and the system asks the user for
elevated privileges, a bug in later code can easily cause serious harm
instead of failing. Yes, untrusted code should be sandboxed - but it isn't,
more often than not.

Elazar

‪On Tue, Sep 20, 2016 at 2:02 PM ‫אלעזר‬‎  wrote:‬

> I think I generally understand concerns, and partially agree. I'm
> certainly not dismissing them. I only try to understand what are the
> precise problems and why the current situation - with dangerous functions
> at reach, easily buried deep in the code instead of marked on the top of
> the script - is so much better.
>
> Elazar
>
> On Tue, Sep 20, 2016 at 1:56 PM Paul Moore  wrote:
>
>> On 20 September 2016 at 11:46, אלעזר  wrote:
>> > So it should be something like
>> >
>> > from unsafe.__pip__ import benchmark
>> >
>> > Where unsafe is the hypothetical namespace in which exec(), eval() and
>> > subprocess.run() would have reside given your concerns.
>>
>> In my opinion, it should be
>>
>> # Please install benchmark using pip to run this script
>>
>> Or you should run the script using a dedicated runner like rwt. Or you
>> can depend on a custom import hook that makes "from __pip__
>> install..." work as you want. I'm just saying that I don't want core
>> Python to implicitly install packages for me. But that's simply a
>> personal opinion. I'm not trying to persuade you you're wrong, just
>> trying to explain my position. We can agree to differ. It certainly
>> doesn't seem to me that there's any need for you to modify your
>> proposal to suit me, it's unlikely I'll like any variation you're
>> going to be happy with, which is fine (you're under no obligation to
>> convince me).
>>
>> Paul
>>
>
___
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] from __pip__ import

[אלעזר]

I think I generally understand concerns, and partially agree. I'm certainly
not dismissing them. I only try to understand what are the precise problems
and why the current situation - with dangerous functions at reach, easily
buried deep in the code instead of marked on the top of the script - is so
much better.

Elazar

On Tue, Sep 20, 2016 at 1:56 PM Paul Moore  wrote:

> On 20 September 2016 at 11:46, אלעזר  wrote:
> > So it should be something like
> >
> > from unsafe.__pip__ import benchmark
> >
> > Where unsafe is the hypothetical namespace in which exec(), eval() and
> > subprocess.run() would have reside given your concerns.
>
> In my opinion, it should be
>
> # Please install benchmark using pip to run this script
>
> Or you should run the script using a dedicated runner like rwt. Or you
> can depend on a custom import hook that makes "from __pip__
> install..." work as you want. I'm just saying that I don't want core
> Python to implicitly install packages for me. But that's simply a
> personal opinion. I'm not trying to persuade you you're wrong, just
> trying to explain my position. We can agree to differ. It certainly
> doesn't seem to me that there's any need for you to modify your
> proposal to suit me, it's unlikely I'll like any variation you're
> going to be happy with, which is fine (you're under no obligation to
> convince me).
>
> Paul
>
___
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] from __pip__ import

[Paul Moore]

On 20 September 2016 at 11:46, אלעזר  wrote:
> So it should be something like
>
> from unsafe.__pip__ import benchmark
>
> Where unsafe is the hypothetical namespace in which exec(), eval() and
> subprocess.run() would have reside given your concerns.

In my opinion, it should be

# Please install benchmark using pip to run this script

Or you should run the script using a dedicated runner like rwt. Or you
can depend on a custom import hook that makes "from __pip__
install..." work as you want. I'm just saying that I don't want core
Python to implicitly install packages for me. But that's simply a
personal opinion. I'm not trying to persuade you you're wrong, just
trying to explain my position. We can agree to differ. It certainly
doesn't seem to me that there's any need for you to modify your
proposal to suit me, it's unlikely I'll like any variation you're
going to be happy with, which is fine (you're under no obligation to
convince me).

Paul
___
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] from __pip__ import

[אלעזר]

On Tue, Sep 20, 2016 at 1:42 PM Paul Moore  wrote:

> On 20 September 2016 at 00:28, אלעזר  wrote:
> > On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull
> >  wrote:
> >>
> >> אלעזר writes:
> >>
> >>  > Another use case, though I admit not the top priority of anyone here,
> >> is
> >>  > that of assignment checkers. In most courses I took at the
> university,
> >> the
> >>  > person who checks the assignments says something like "you are
> allowed
> >> to
> >>  > use only this this and this libraries", in order not to mess with
> >> unknown
> >>  > dependencies from tens of students (I am talking about advanced
> >> courses,
> >>  > where the method I use to solve the problem is unimportant or only
> >> requires
> >>  > explanation). With this statement they can simply state "you can
> import
> >>  > pip".
> >>
> >> In other words, you're advocating a feature that allows script writers
> >> to download, install, and execute arbitrary, unsandboxed code on any
> >> machine where the script is run.  That sounds ... *scary*, when put
> >> that way.  Remember, you're advocating this on behalf of people who by
> >> assumption are infants years below the age of consent.
> >>
> > Let me understand. Your argument is "installing pip modules is unsafe,
> and
> > therefore we should make it less usable, where the appropriate amount of
> > (un)usability is running cmd and then `pip install unsafe`" ?
>
> The argument is that if someone posts a script that says it does
> something innocuous, for example "benchmark showing that X is faster
> than Y", people will scan it, see that it looks OK, and run it. They
> have a reasonable expectation that it's not a security risk.
>
> If it requires a benchmarking module from PyPI, they may not
> immediately notice that "from __pypi__ import benchmark" opens up a
> security risk. On the other hand, being explicitly told to run a
> command whose sole purpose is to download and install an external tool
> clearly indicates to them that they need to be aware of what's
> happening. Likely they will simply do so and it's no big deal. But in
> certain environments they may have to pause and possibly even check
> with their security team as to whether that tool has been approved.
>
> It's not about "making it less usable", it's about ensuring that the
> implications are clear - explicit is better than implicit, in effect.
> Which is a particularly important principle when security risks such
> as "downloading arbitrary code from the internet" is involved.
>
>
So it should be something like

from unsafe.__pip__ import benchmark

Where unsafe is the hypothetical namespace in which exec(), eval() and
subprocess.run() would have reside given your concerns.

 Elazar
___
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] from __pip__ import

[Paul Moore]

On 20 September 2016 at 00:28, אלעזר  wrote:
> On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull
>  wrote:
>>
>> אלעזר writes:
>>
>>  > Another use case, though I admit not the top priority of anyone here,
>> is
>>  > that of assignment checkers. In most courses I took at the university,
>> the
>>  > person who checks the assignments says something like "you are allowed
>> to
>>  > use only this this and this libraries", in order not to mess with
>> unknown
>>  > dependencies from tens of students (I am talking about advanced
>> courses,
>>  > where the method I use to solve the problem is unimportant or only
>> requires
>>  > explanation). With this statement they can simply state "you can import
>>  > pip".
>>
>> In other words, you're advocating a feature that allows script writers
>> to download, install, and execute arbitrary, unsandboxed code on any
>> machine where the script is run.  That sounds ... *scary*, when put
>> that way.  Remember, you're advocating this on behalf of people who by
>> assumption are infants years below the age of consent.
>>
> Let me understand. Your argument is "installing pip modules is unsafe, and
> therefore we should make it less usable, where the appropriate amount of
> (un)usability is running cmd and then `pip install unsafe`" ?

The argument is that if someone posts a script that says it does
something innocuous, for example "benchmark showing that X is faster
than Y", people will scan it, see that it looks OK, and run it. They
have a reasonable expectation that it's not a security risk.

If it requires a benchmarking module from PyPI, they may not
immediately notice that "from __pypi__ import benchmark" opens up a
security risk. On the other hand, being explicitly told to run a
command whose sole purpose is to download and install an external tool
clearly indicates to them that they need to be aware of what's
happening. Likely they will simply do so and it's no big deal. But in
certain environments they may have to pause and possibly even check
with their security team as to whether that tool has been approved.

It's not about "making it less usable", it's about ensuring that the
implications are clear - explicit is better than implicit, in effect.
Which is a particularly important principle when security risks such
as "downloading arbitrary code from the internet" is involved.

Paul
___
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] from __pip__ import

[אלעזר]

I believe that at least some of these problems can be addressed given that
pip *knows* that this import is an in-script import. So the list of corner
cases will be shorter.

Elazar

On Tue, Sep 20, 2016 at 1:35 PM Paul Moore  wrote:

> On 19 September 2016 at 23:46, אלעזר  wrote:
> >> import pip
> >> pip.install('attrs')
> >> import attr
> >
> > Please forgive me for my ignorance, but it doesn't work as written -
> what's
> > the actual method?
>
> As David Mertz said, pip.main(['install', 'attrs']) works right now,
> but it is NOT a supported use of pip[1]. To be 100% explicit, the only
> supported way of doing this is
>
> import sys
> from subprocess import run
> run([sys.executable, '-m', 'pip', 'install', 'attrs'])
>
> I suggested a hypothetical "pip.install" method as there is currently
> some discussion on the pip tracker about providing a supported install
> method. But it doesn't exist yet. Sorry for being confusing.
>
> While on the whole subject of this, I should also point out that there
> are a lot of potential issues with installing new packages while a
> Python program is running. They are all low-probability, and easy to
> avoid if you're not doing weird things, but for a generally-promoted
> mechanism, we need to explain the corner cases[2], and an approach
> with a list of caveats longer than the main documentation is
> problematic.
>
> 1. If the install fails, you need to catch that and report it to the
> user, in a more friendly manner than pip's output. For example if the
> user has no C compiler and you need a C extension to be built.
> 2. You quite possibly want to suppress pip's output if it's *not* a
> failure, as it'll clutter up the program's real output.
> 3. If the code has already imported foo.bar, then you install a new
> version of foo (there are discussions as to whether pip install foo
> should automatically imply --upgrade, so even if it won't do that by
> default now, it might in the future), and maybe that new version
> doesn't have a bar submodule. So now you have a weird mix of old and
> new code in your process.
> 4. The install mechanism sometimes (I can't recall the details) caches
> the fact that it couldn't import a module. If it does that and then
> later you pip install that module, imports will still fail because the
> information is cached.
>
> I'm still not at all clear why any of this is so much better than a
> comment at the top of the script
>
> # To run this script, you need to "pip install attrs" first
>
> Paul.
>
> [1] We've had people report issues where pip breaks their logging
> config, for example, because pip uses logging but doesn't expect to be
> run from user code that also does so.
> [2] That "run([sys.executable, ...])" invocation doesn't work in an
> embedded program, for example, where sys.executable isn't "python".
>
___
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] Make partial a built-in

[Steven D'Aprano]

On Tue, Sep 20, 2016 at 09:56:48AM +, אלעזר wrote:
> foo.__call__.partial() solves most of the problem I think.

There are two problems with that, one obvious and one subtle.

The obvious one is that __call__ is a dunder method, which means that 
accessing it directly from outside of the object's class is a code 
smell. It's not necessarily *wrong*, but its a bit... smelly. A bit 
suspicious. Something we should think *very* carefully about before 
encouraging.

The subtle one is that foo.__call__ may not actually be the method that 
is used when you call foo().

py> class X(object):
... def __call__(self):
... return "from X"
...
py> x = X()
py> x.__call__ = lambda: "surprise!"
py> x()
'from X'
py> x.__call__()
'surprise!'



-- 
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] from __pip__ import

[Paul Moore]

On 19 September 2016 at 23:46, אלעזר  wrote:
>> import pip
>> pip.install('attrs')
>> import attr
>
> Please forgive me for my ignorance, but it doesn't work as written - what's
> the actual method?

As David Mertz said, pip.main(['install', 'attrs']) works right now,
but it is NOT a supported use of pip[1]. To be 100% explicit, the only
supported way of doing this is

import sys
from subprocess import run
run([sys.executable, '-m', 'pip', 'install', 'attrs'])

I suggested a hypothetical "pip.install" method as there is currently
some discussion on the pip tracker about providing a supported install
method. But it doesn't exist yet. Sorry for being confusing.

While on the whole subject of this, I should also point out that there
are a lot of potential issues with installing new packages while a
Python program is running. They are all low-probability, and easy to
avoid if you're not doing weird things, but for a generally-promoted
mechanism, we need to explain the corner cases[2], and an approach
with a list of caveats longer than the main documentation is
problematic.

1. If the install fails, you need to catch that and report it to the
user, in a more friendly manner than pip's output. For example if the
user has no C compiler and you need a C extension to be built.
2. You quite possibly want to suppress pip's output if it's *not* a
failure, as it'll clutter up the program's real output.
3. If the code has already imported foo.bar, then you install a new
version of foo (there are discussions as to whether pip install foo
should automatically imply --upgrade, so even if it won't do that by
default now, it might in the future), and maybe that new version
doesn't have a bar submodule. So now you have a weird mix of old and
new code in your process.
4. The install mechanism sometimes (I can't recall the details) caches
the fact that it couldn't import a module. If it does that and then
later you pip install that module, imports will still fail because the
information is cached.

I'm still not at all clear why any of this is so much better than a
comment at the top of the script

# To run this script, you need to "pip install attrs" first

Paul.

[1] We've had people report issues where pip breaks their logging
config, for example, because pip uses logging but doesn't expect to be
run from user code that also does so.
[2] That "run([sys.executable, ...])" invocation doesn't work in an
embedded program, for example, where sys.executable isn't "python".
___
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] Suggestion: Clear screen command for the REPL

[Michel Desmoulin]

+1 for this. I regularly miss this feature.

Le 17/09/2016 à 13:12, João Matos a écrit :
> Hello,
> 
> In other interpreted programming languages the clear screen command
> (whatever it is) also does not clear the session.
> It just clears the screen clutter.
> 
> As I said, this would be very useful for newbies, which don't know
> anything about usercustomize or sitecustomize.
> 
> 
> Best regards,
> 
> JM
> 
> 
> On 17-09-2016 12:07, Chris Angelico wrote:
>> On Sat, Sep 17, 2016 at 8:51 PM, João Matos  wrote:
>>> I would like to suggest adding a clear command (not function) to Python.
>>> It's simple purpose would be to clear the REPL screen, leaving the >>>
>>> prompt at the top left of the screen.
>>>
>>> This is something very basic but also very useful for newbies learning
>>> Python from the REPL.
>>> After some trial and errors it is best to start with a clean screen.
>>> Clearing the screen helps clear your mind.
>>>
>> I'm not sure that it _is_ helpful, given that you're starting with a
>> clean screen but not restarting the session (so you'll still have all
>> the state from your previous work). If you want a completely fresh
>> start, just exit Python, clear the screen with a shell command, and
>> re-enter.
>>
>> The easiest way to play around with this would be to create a pure
>> Python clear() function in your usercustomize or sitecustomize, and
>> then try it in your own workflow - see whether it annoys you that it
>> doesn't change the interpreter state. Maybe it will, maybe it won't.
>>
>> ChrisA
>> ___
>> 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] Suggestion: Clear screen command for the REPL

[Chris Angelico]

On Tue, Sep 20, 2016 at 6:20 PM, Paul Moore  wrote:
> There
> have been occasional deviations from this (for example, the "as" in
> "import foo as bar" was, for a time, only a keyword in that specific
> context) but I don't believe any of them survived long-term.

async and await are similarly context-sensitive for a couple of
versions, to make the breakage simpler. But again, it's not intended
to be long-term.

ChrisA
___
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] Make partial a built-in

[אלעזר]

Yeah I did say it was a strawman :)

On Tue, Sep 20, 2016 at 11:17 AM Chris Angelico  wrote:

> On Tue, Sep 20, 2016 at 6:09 PM, אלעזר  wrote:
> > I meant something like making it a "__bind__" (just a strawman
> suggestion)
> > and do the same lookup as foo() does, and using a (wrong)
> > functional-programming-inspired syntax
> >
> > foo 5 ()
> >
> > Such a syntax will have the side benefit of allowing calling print in a
> > similar way to Python2, which people seem to love.
> >
> > print "hello" ()
> >
>
> Python has a rule that syntax shouldn't look like grit on Tim's
> screen. In this case, it looks like the *absence of* grit, which is
> even worse :) You're giving meaning to the abuttal of two tokens, the
> first of which must be callable but the second can be anything. And it
> creates the scary situation of giving valid-but-useless meaning to
> something all too common in Py2 code:
>
> print "hello"
>
> This would now create a function that, if called, would print "hello",
> but then abandons it without a second thought. So it'd work in 2.7,
> fail with an opaque error in 3.3, fail with a more informative error
> in 3.5, and silently do nothing in 3.7. No thank you! :)
>
> ChrisA
> ___
> 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] Make partial a built-in

[אלעזר]

On Tue, Sep 20, 2016 at 10:54 AM Chris Angelico  wrote:

> On Tue, Sep 20, 2016 at 5:01 PM, אלעזר  wrote:
> > But the foo() finds the function to call, so foo.bind() could be made to
> > find it too.
>
> class Demo:
> def __init__(self):
> self.bind = 42
> def __call__(self):
> print("I got called!")
>
> foo = Demo()
>
> You can most certainly call foo(), but foo.bind() will bite you.
>
> With a stand-alone function bind(foo), it can use protocols like __call__.
>
> I meant something like making it a "__bind__" (just a strawman suggestion)
and do the same lookup as foo() does, and using a (wrong)
functional-programming-inspired syntax

foo 5 ()

Such a syntax will have the side benefit of allowing calling print in a
similar way to Python2, which people seem to love.

print "hello" ()

This strawman proposal has many downsides I guess. My point being, this can
be made to work, but it's probably not worth it.

Elazar
___
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] Suggestion: Clear screen command for the REPL

[אלעזר]

On Tue, Sep 20, 2016 at 4:56 AM Steven D'Aprano  wrote:

> On Mon, Sep 19, 2016 at 01:35:53PM -0700, João Matos wrote:
> > Hello,
> >
> > I don't see why creating a clear command would interfere with
> dict.clear()
> > which is a function/method.
>
> For the same reason that you can't have a method called foo.while or
> foo.if or foo.raise. If clear is a "command" (a statement) it would need
> to be a keyword, like while, if and raise.
>
>
> This is since in Python there are no contextual keywords (like "override"
and "final" in C++). I remember encountering error in a Django project
where accessing u.pass was a syntax error, but there *was* a field "pass"
in u and they had to resort to getattr(u, "pass").
What is the reasoning behind that decision?

Elazar
___
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] Suggestion: Clear screen command for the REPL

[João Matos]

Hello,

You are correct.
Thanks for the explanation.

Best regards,

JM


terça-feira, 20 de Setembro de 2016 às 02:56:57 UTC+1, Steven D'Aprano 
escreveu:

> On Mon, Sep 19, 2016 at 01:35:53PM -0700, João Matos wrote: 
> > Hello, 
> > 
> > I don't see why creating a clear command would interfere with 
> dict.clear() 
> > which is a function/method. 
>
> For the same reason that you can't have a method called foo.while or 
> foo.if or foo.raise. If clear is a "command" (a statement) it would need 
> to be a keyword, like while, if and raise. 
>
>
> -- 
> Steve 
> ___ 
> 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] Make partial a built-in

[Stephan Houben]

Hi all,

I would like to add that I don't believe that discoverability is
always better in the `builtins' module.

I personally had the experience of going over itertools, where
I found 'zip_longest', but I couldn't find a 'zip_shortest'.

Only after some googling I found out it was called `zip' and it lived in
`builtins'.

Stephan

2016-09-20 7:23 GMT+02:00 Stefan Behnel :

> אלעזר schrieb am 19.09.2016 um 17:59:
> > If at all, it should be function.bind(). It was discussed and dropped; I
> > don't remember why, but one problem is that it looks like an in-place
> > modification.
>
> IMHO, the main drawback of that solution is that it only works for
> functions and not for any other callable in Python. It would introduce an
> inconsistency without solving the problem in general.
>
> Stefan
>
>
> ___
> 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] Make partial a built-in

[אלעזר]

But the foo() finds the function to call, so foo.bind() could be made to
find it too.

בתאריך יום ג׳, 20 בספט' 2016, 08:24, מאת Stefan Behnel ‏:

> אלעזר schrieb am 19.09.2016 um 17:59:
> > If at all, it should be function.bind(). It was discussed and dropped; I
> > don't remember why, but one problem is that it looks like an in-place
> > modification.
>
> IMHO, the main drawback of that solution is that it only works for
> functions and not for any other callable in Python. It would introduce an
> inconsistency without solving the problem in general.
>
> Stefan
>
>
> ___
> 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/