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

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

Re: [Python-ideas] Make partial a built-in

אלעזר 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,

Re: [Python-ideas] Overloading operators for testing

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

Re: [Python-ideas] Make partial a built-in

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

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

Re: [Python-ideas] Make partial a built-in

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

Re: [Python-ideas] Overloading operators for testing

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

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

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.

Re: [Python-ideas] Overloading operators for testing

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

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

Re: [Python-ideas] Make partial a built-in

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,

Re: [Python-ideas] from __pip__ import

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

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

Re: [Python-ideas] Make partial a built-in

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

Re: [Python-ideas] Make partial a built-in

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,

Re: [Python-ideas] Make partial a built-in

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

Re: [Python-ideas] Make partial a built-in

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

Re: [Python-ideas] Make partial a built-in

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

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

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

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

Re: [Python-ideas] Make partial a built-in

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

Re: [Python-ideas] from __pip__ import

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

Re: [Python-ideas] singledispatch for instance methods

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

Re: [Python-ideas] from __pip__ import

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

Re: [Python-ideas] from __pip__ import

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

Re: [Python-ideas] from __pip__ import

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

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

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

Re: [Python-ideas] from __pip__ import

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

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,

Re: [Python-ideas] from __pip__ import

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

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, אלעזר

Re: [Python-ideas] Make partial a built-in

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

Re: [Python-ideas] from __pip__ import

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

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

+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

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

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

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()

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

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

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

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

Re: [Python-ideas] Make partial a built-in

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'

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