Re: [Python-ideas] Overloading operators for testing

[Greg Ewing]

Arek Bulski wrote:

def __glob_eq__(a,b):
  if not a == b:
  raise FoundInequalityError(a,b)
  return True

assert obj1 == obj2   #<-- using eq above


How would you ensure that this overriding only applied in
the places you want it? You don't want to change the meaning
of == in the code under test!

Related to that, how would you prevent the use of ==
in the definition of __glob_eq__ above from triggering infinite
recursion?

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

[Python-ideas] Overloading operators for testing

[Arek Bulski]

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

[Ethan Furman]

On 09/17/2016 03:14 PM, Chris Angelico wrote:

On Sun, Sep 18, 2016 at 8:06 AM, Ethan Furman wrote:



Just like Python will use the defined __ne__ if
it's present, or fall back to negating the result of __eq__ if __ne__ is
not present, I see __divmod__ working the same way:

- is __mod__ present? use it
- is __floordiv__ present? use it
- otherwise, use __divmod__ and return the needed piece

I'm pretty sure __div__ should not fall back to __divmod__.


How does __mod__ fall back to __floordiv__? I'm lost.


Oops, sorry.  Got my directions reversed when thinking about how __div__ should 
fit in.

Bird's eye view: if the exact method needed is present, use it; otherwise if a 
fallback method is available, use that.

Currently this is done for __ne__ --> not __eq__, and I seem to remember 
another case or two that was talked about but I don't remember what they were and 
I'm not sure if they got implemented to follow the fallback pattern.

--
~Ethan~
___
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__?

[Chris Angelico]

On Sun, Sep 18, 2016 at 8:06 AM, Ethan Furman  wrote:
> Just like Python will use the defined __ne__ if
> it's present, or fall back to negating the result of __eq__ if __ne__ is
> not present, I see __divmod__ working the same way:
>
> - is __mod__ present? use it
> - is __floordiv__ present? use it
> - otherwise, use __divmod__ and return the needed piece
>
> I'm pretty sure __div__ should not fall back to __divmod__.

How does __mod__ fall back to __floordiv__? I'm lost.

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

[Terry Reedy]

On 9/17/2016 6:51 AM, João Matos wrote:

Hello,

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.

Historically it is a common command in interpreted languages.


Python is not an 'interpreted' language in the sense that you are using 
the word.  It is a compiled language that includes its compile function 
as part of the runtime.  This enables an interactive mode.


Python does not have commands, only statements, expressions, and 
functions, etcetera.  This is why the 'exit()' and 'quit()' 'commands' 
are functions and require the parentheses.  In interactive mode, a 
statement consisting of a single indentifier (or expression) causes 
display of a representation of the resulting object.


You could request that the site module also add a clear() function. But 
the next problem is that clearing the screen is not a Python function 
and the Python runtime does not normally know how to do so.  The 
implementation of 'clear screen' is specific to the particular console 
or window or terminal emulation.  The control sequence for a window that 
emulates VT100 does not work on Windows Command Prompt (excepting 
possibly a non-default CP on Win 10) or necessarily IDLE or IPython or 
PyCharm or ... .  The only assumption that Python makes about the screen 
it is running on is that '\n' is interpreted as a newline.



IDLE has a 'Restart Shell' menu command with key binding.  It does not 
physically clear the screen but it draws a double line, which serves 
most of the 'clear the mind' purpose.  If there is an editor window 
open, one can close and reopen the Shell window to start really fresh.


At least on Windows, Select All (^A) + Del (or Backspace) is the common 
idiom for clearing an editor box in a GUI.  Is this used on other OSes? 
This works in an IDLE editor also.  It is disabled in the Shell because 
IDLE's original designers thought to protect beginners from doing such. 
A clear screen menu option has been requested, but it has never become a 
top priority.  In any case, this, like other current clear screen 
commands, would work because the command would go to the window manager 
and not to python.


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

[Chris Angelico]

On Sun, Sep 18, 2016 at 3:57 AM, David Mertz  wrote:
> For example, '%' is fairly widely (ab)used for meanings other than modulo.
> E.g. string formatting.  Probably not that many classes that respond to '%'
> to do something non-modulo simultaneously implement `.__divmod__()` ... but
> maybe some use case is not obvious to me.  If those exist, your change would
> break that (well, depending whether methods of ancestors are used or not).

So there'll be classes that define __mod__ but not __divmod__ - that's
fine. Are there any that go the other way around?

It might technically be a breaking change, but it's unlikely to cause
very much breakage. So it'd be inappropriate for 3.6.1, but okay for
3.7.

+1 on the fallback exactly as Ethan described. The One Obvious Way to
implement arithmetic division would be to define __divmod__. Defining
__truediv__ or __mod__ would be for times when you can implement it
more efficiently by not calculating the other half, and of course the
times when they're not implementing division (cf pathlib.Path and str,
for / and % respectively).

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

[David Mertz]

It seems like this could be something similar to `functools.total_ordering`
and decorate a class.  In principle that transformation could go in either
direction, but only if the decorator is used.

On Sat, Sep 17, 2016 at 3:56 AM, Mark Dickinson  wrote:

> On Sat, Sep 17, 2016 at 10:01 AM, 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)?
>
> It's an interesting idea. I wonder whether the falling back shouldn't
> be in the other direction, though: that is, if a class defines
> `__divmod__` but not `__floordiv__` or `__mod__`, perhaps the `//` and
> `%` operations should use `__divmod__`? That way, if you're writing a
> class that intends to support all three operations, you only have to
> write one method. And it might make sense from an efficiency
> perspective, too; it's common for a `divmod` computation to be cheaper
> than doing separate computations of the quotient and remainder.
>
> For the builtin int type, for example, in nontrivial cases Python
> computes both the quotient and remainder when asked to do a % or //
> operation, and then discards whichever part isn't needed. So in that
> case it would be wasteful to build up the divmod result from two
> separate % and // calls.
>
> --
> Mark
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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] typing.modifiers

[אלעזר]

Thank you all!

אלעזר
(AKA Elazar)

On Sat, Sep 17, 2016 at 4:53 AM Steven D'Aprano  wrote:

> On Sat, Sep 17, 2016 at 03:39:08AM +1000, Chris Angelico wrote:
> > On Fri, Sep 16, 2016 at 11:22 PM, אלעזר  wrote:
> > > P.S. how do I change the name in my quotes? I believe אלעזר is not
> very easy
> > > to address...
> > >
> >
> > TBH I wouldn't worry about it. If people can't cite names using Hebrew
> > script, that's their problem, not yours. :)
>
> [in-joke, that Chris will get]
> But how do we know that אלעזר is his real name? It looks made up to me.
> [/in-joke]
>
> Still, thank you Elazar for also providing a Latin-1 compatible name
> which is readable and pronounceable by English speakers.
>
>
> --
> 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/
___
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

[eryk sun]

On Sat, Sep 17, 2016 at 1:15 PM, Wes Turner  wrote:
>   !cls #windows

cmd's built-in cls command doesn't clear just the screen, like a VT100
\x1b[1J. It clears the console's entire scrollback buffer. Unix
`clear` may also work like that. With GNOME Terminal in Linux, `clear`
leaves a single screen in the scrollback buffer.
___
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,

I searched and found several possible solutions to clear the screen in 
the CPython REPL, but all are, in my opinion, complex for a newbie.
The existence of a clear command would be a simple and obvious, 
therefore accessible to newbies.


Best regards,

JM



On 17-09-2016 14:34, eryk sun wrote:

On Sat, Sep 17, 2016 at 11:11 AM, João Matos  wrote:

On 17-09-2016 12:07, Oleg Broytman wrote:

 Pressing [Ctrl]+[L] works for me.

Doesn't work on Windows.

Windows 10 added VT100 support to the console, so you can create a
little cls() function to clear the screen:

 cls = lambda: print('\x1b[1J', end='', flush=True)

VT100 support isn't enabled by default. However, cmd.exe always
enables this mode. So run doskey.exe via os.system to enable VT100
mode while setting a convenient "cls" alias:

 import os
 os.system(r'doskey /exename=python.exe cls=cls()')

This alias substitutes "cls()" for "cls" at the beginning of a line.
This saves you from having to type "()" all the time. The alias isn't
active for other programs; e.g. if you execute
subprocess.call('powershell'), then "cls" will be the PowerShell alias
for Clear-Host.

You can also use ctypes instead of os.system and doskey.exe:

 import ctypes
 kernel32 = ctypes.WinDLL('kernel32')
 hStdOut = kernel32.GetStdHandle(-11)

 # enable VT100 mode
 mode = (ctypes.c_uint * 1)()
 kernel32.GetConsoleMode(hStdOut, mode)
 kernel32.SetConsoleMode(hStdOut, mode[0] | 4)

 # define a cls() function and set a console alias
 cls = lambda: print('\x1b[1J', end='', flush=True)
 kernel32.AddConsoleAliasW('cls', 'cls()', 'python.exe')

For older versions of Windows you can use ANSICON or ConEmu, which use
DLL injection to extend the console API. Python's colorama and
pyreadline modules should also work for this.
___
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

[João Matos]

Hello,

I know about those IPython commands and I searched and found several 
possible solutions to clear the screen in the CPython REPL, but all are, 
in my opinion, complex for a newbie.
The existence of a clear command would be simple and obvious, therefore 
accessible to newbies.



Best regards,

JM



On 17-09-2016 14:15, Wes Turner wrote:

With IPython, there are a number of ways to reset the terminal display:

  clear  # %clear
  !cls #windows
  !reset

- 
http://stackoverflow.com/questions/6892191/clearing-the-screen-in-ipython

  - Ctrl-L is a readline binding
  - 
http://pythonhosted.org/pyreadline/usage.html#pyreadline-with-python-interpreter

  - https://anaconda.org/anaconda/pyreadline
  - https://pypi.python.org/pypi/pyreadline
  - IPython >= 5 no longer uses pyreadline (instead, python prompt 
toolkit)
- 
https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/prompt_toolkit/shortcuts.py 
#def clear



 - 
http://unix.stackexchange.com/questions/124762/how-does-clear-command-work
- 
http://urwid.org/reference/display_modules.html#urwid.raw_display.Screen.clear

- https://rosettacode.org/wiki/Terminal_control/Clear_the_screen#Python

On Saturday, September 17, 2016, João Matos > wrote:


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/