Re: [Python-ideas] Suggestion: Clear screen command for the REPL
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
On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Apranowrote: > (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
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__?
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
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.
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.
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
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/