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

[Stephen J. Turnbull]

Chris Angelico writes:
 > On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano  
 > wrote:
 > > (The fallback if all else fails is easy: get the height of the terminal,
 > > in lines, and print that many blank lines.)
 > 
 > Assuming you can get the height in lines. Have you tried that in the
 > default Windows shell? I don't think tcgetattr works on Windows.

Since a command is out of the question (look what happened to print!),
it's a matter of defining a callable with a repr that explains how to
call it (like help and friends).  So if someone really wants this to
happen, I would say the thing to do is to define that callable, put it
on PyPI, add support for all the platforms, fix all the bugs, and when
there are a couple million downloads, suggest preloading it in
interpreter then.  Don't forget how to document how to add it to
site.py.

But I would think that nowadays we'd push in the opposite direction
(as with print).  That is, with the great improvements in IDLE
(batteries included!), IPython, and now we have Jupyter, you could now
argue that the built-in REPL should lose at least one of the two exit
functions (since EOF is a sufficient reason to exit).  (help() still
makes sense as the public interface to __doc__.)

In other words, the built-in REPL should just provide some
line-editing features and otherwise simply read lines, incrementally
compile and execute them, and print results.  Leave UI conveniences to
other applications that (gasp!) specialize in providing consistent,
powerful UI that isn't going to feel like bat guano on Tim's keyboard.
IMHO YMMV, of course.

___
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 Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano  wrote:
> (The fallback if all else fails is easy: get the height of the terminal,
> in lines, and print that many blank lines.)

Assuming you can get the height in lines. Have you tried that in the
default Windows shell? I don't think tcgetattr works on Windows.

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

[Steven D'Aprano]

On Sat, Sep 17, 2016 at 11:51:16AM +0100, João Matos wrote:
> Hello,
> 
> I would like to suggest adding a clear command (not function) to Python.

While technically "clear" could be a command, I think it should not be.

First off, making clear a reserved keyword, and a statement, like print 
in Python 2, raise or import, would be a major backwards compatibility 
break. It would mean dict.clear() has to be renamed, and it would break 
lots of existing code.

So making clear a keyword is not going to happen.

If could be a pseudo-built-in, like help(), quit() and exit(), added to 
built-ins by the site module. In that case, it is *technically* possible 
to have it operate without the parentheses:

class ClearType:
def __repr__(self):
# code to clear the screen here
...

clear = ClearType()

so that when you enter clear at the interactive interpreter, __repr__ is 
called and it clears the screen. But I would argue against it. Instead, 
it is better to use the same convention that executable code that has 
side-effects should be implemented as a function call.

So I suggest following the design of exit() and quit():

py> exit
Use exit() or Ctrl-D (i.e. EOF) to exit


class ClearType:
def __repr__(self):
return "Use clear() or Ctrl-L (i.e. FF) to clear the screen"
def __call__(self):
# clear screen code goes here

clear = ClearType()  # or possibly cls ?



That is, *if* we add this function at all.

Personally, I agree with you. There are many different ways of clearing 
the screen, but they depend on the specific terminal used, whether 
readline is active or not, the operating system, etc. I think that 
interactive use is important enough that we should have a standard way 
of clearing the screen. I personally often find myself just holding down 
the Enter key until I have a blank screen.

In this ticket:

http://bugs.python.org/issue27771

Raymond Hettinger mentions that it is an often-requested feature by 
learners, and I believe that IDLE has an active task for this feature:

http://bugs.python.org/issue6143

but I don't see any tasks for a clear screen command for the default 
REPL.

I'm in favour of adding a clear() *function* to the site.py module, 
similar to exit/quit/help, but not making it "magical" or a keyword that 
doesn't require brackets. But I don't know how to implement it for the 
large variety of terminals and operating systems supported by Python.

(The fallback if all else fails is easy: get the height of the terminal, 
in lines, and print that many blank lines.)


-- 
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] divmod(): fallback to __floordiv__ and __mod__?

[Steven D'Aprano]

On Sat, Sep 17, 2016 at 09:01:53AM +, Spencer Brown wrote:

> Currently, calling divmod() on a class with __floordiv__ and __mod__ 
> defined, but not __divmod__ raises a TypeError. Is there any reason 
> why it doesn't fallback to (self // x, self % x)? 

Because things get really complex, fast. Does the added complexity pay 
its own way?

I may have some of the details wrong, but I understand the 
implementation of divmod() is something like this:

# pseudo-code for divmod
def divmod(a, b):
A, B = type(a), type(b)
if issubclass(B, A):
# Give priority to the reverse dunder version
if hasattr(B, '__rdivmod__'):
result = B.__rdivmod__(b, a)
if result is not NotImplemented:
return result
if hasattr(A, '__divmod__'):
result = A.__divmod__(a, b)
if result is not NotImplemented:
return result
raise TypeError
if hasattr(A, '__divmod__'):
result = A.__divmod__(a, b)
if result is not NotImplemented:
return result
if hasattr(B, '__rdivmod__'):
result = B.__rdivmod__(b, a)
if result is not NotImplemented:
return result
raise TypeError


only it will be in C, so probably three or five times as much code :-)

Now consider adding a fallback to __floordiv__ and __mod__ as suggested. 
That adds a lot more complexity:

- what if the object has __floordiv__, but not __mod__? Do you try 
  the reversed method, __rmod__, instead?

- likewise for NotImplemented?

- what if they're None?


So let's look at the complexity of the fallback:


# reverse dunder version, for when b is a subclass of a
rdiv = getattr(B, '__rfloordiv__, None)
rmod = getattr(B, '__rmod__, None)
if rdiv is not None and rmod is not None:
x, y = rdiv(b, a), rmod(b, a)
if x is NotImplemented:
div = getattr(A, '__floordiv__', None)
if div is not None:
x = div(a, b)
if x is NotImplemented:
raise TypeError
if y is NotImplemented:
mod = getattr(A, '__mod__', None)
if mod is not None:
y = mod(a, b)
if y is NotImplemented:
raise TypeError
assert NotImplemented not in (x, y)
else:
# try the __floordiv__ and __mod__ versions, without falling 
# back to reversed versions
...
return (x, y)


And then more or less the same for the "standard" case where a has 
priority over b (i.e. isn't a subclass). So, my estimate is that this 
will roughly triple the complexity of the divmod() function. Perhaps 
worse.

Oh, and I forgot the case where __divmod__ exists but is None, but I'm 
not going back to add it in because I'm not even sure where that ought 
to be tested.

Now I daresay we can refactor my naive pseudo-code above, but however 
you look at it, there's going to be a big jump in complexity for not a 
lot of benefit. In the case of __ne__ falling back on not __eq__, there 
is at least an utterly clear and obvious user-expectation that the two 
methods are linked, and there are no reversed __req__ and __rne__ 
methods to care about. That's not the case here.

Going the other way (fall back to __divmod__ if __floordiv__ or __mod__ 
is not defined) will probably be not quite as complex, but it will still 
add a fair amount of complexity.

So, *emotionally* I actually do quite like the idea of having divmod 
fall back to // and %, *and* the other way, but *intellectually* when I 
think about the complexity and the tests that will be needed to cover 
all the cases, I have to say "Uh uh, no way!"

It may be that the actual C implementation is simpler than I think, in 
which case maybe this is a reasonable idea, but on the face of it, I 
think that it will be really hard to get right, add a lot of code, and 
provide very little benefit.



-- 
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] (Windows-only - calling Steve Dower) Consider addinga symlink to pip in the same location as the py launcher

[João Matos]

Hello,

Ok, thanks for the feedback.

Best regards,

JM



domingo, 18 de Setembro de 2016 às 13:52:44 UTC+1, Steve Dower escreveu:

> I'd like to add a launcher in the same style as py.exe, but that would 
> upset people who manually configure their PATH appropriately.
>
> Personally, I find "py.exe -m pip" quite okay, but appreciate the idea. 
> I'm thinking about this issue (also for other scripts).
>
> Top-posted from my Windows Phone
> --
> From: João Matos 
> Sent: ‎9/‎17/‎2016 3:57
> To: python...@python.org 
> Subject: [Python-ideas] (Windows-only - calling Steve Dower) Consider 
> addinga symlink to pip in the same location as the py launcher
>
> Hello,
>
> If Py3.5 is installed in user mode instead of admin (all users) and we 
> follow your advice that we shouldn't add it to the PATH env var, we can 
> execute Python using the py launcher, but we can't use pip.
> Please consider adding a pip symlink in the same location as the py 
> launcher.
>
> Best regards,
>
> JM
>
> ___
> 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] (Windows-only - calling Steve Dower) Is Python forWindows using PGO? If not consider this a suggestion.

[João Matos]

Hello,

Ok, thanks for the feedback.

Best regards,

JM


domingo, 18 de Setembro de 2016 às 13:53:44 UTC+1, Steve Dower escreveu:
>
> It was disable previously because of compiler bugs. 3.6.0b1 64-bit has PGO 
> enabled, but we'll disable it again if there are any issues.
>
> Top-posted from my Windows Phone
> --
> From: João Matos 
> Sent: ‎9/‎17/‎2016 4:02
> To: python...@python.org 
> Subject: [Python-ideas] (Windows-only - calling Steve Dower) Is Python 
> forWindows using PGO? If not consider this a suggestion.
>
> Hello,
>
> Is Python for Windows using PGO (Profile Guided Optimizations)? If not 
> consider this a suggestion.
>
> Best regards,
>
> JM
>
> ___
> 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] (Windows-only - calling Steve Dower) Is Python forWindows using PGO? If not consider this a suggestion.

[Steve Dower]

It was disable previously because of compiler bugs. 3.6.0b1 64-bit has PGO 
enabled, but we'll disable it again if there are any issues.

Top-posted from my Windows Phone

-Original Message-
From: "João Matos" 
Sent: ‎9/‎17/‎2016 4:02
To: "python-ideas@python.org" 
Subject: [Python-ideas] (Windows-only - calling Steve Dower) Is Python 
forWindows using PGO? If not consider this a suggestion.

Hello,

Is Python for Windows using PGO (Profile Guided Optimizations)? If not 
consider this a suggestion.

Best regards,

JM

___
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] (Windows-only - calling Steve Dower) Consider addinga symlink to pip in the same location as the py launcher

[Steve Dower]

I'd like to add a launcher in the same style as py.exe, but that would upset 
people who manually configure their PATH appropriately.

Personally, I find "py.exe -m pip" quite okay, but appreciate the idea. I'm 
thinking about this issue (also for other scripts).

Top-posted from my Windows Phone

-Original Message-
From: "João Matos" 
Sent: ‎9/‎17/‎2016 3:57
To: "python-ideas@python.org" 
Subject: [Python-ideas] (Windows-only - calling Steve Dower) Consider addinga 
symlink to pip in the same location as the py launcher

Hello,

If Py3.5 is installed in user mode instead of admin (all users) and we 
follow your advice that we shouldn't add it to the PATH env var, we can 
execute Python using the py launcher, but we can't use pip.
Please consider adding a pip symlink in the same location as the py 
launcher.

Best regards,

JM

___
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/