[Python-ideas] Re: `__lcontains__` for letting the other class determine container membership when `__contains__` fails

[Guido van Rossum]

Note that __lcontains__ (if it exists) would be called first, at least for
different types. So maybe it would be easier than you think. But I still
think it’s not needed.

On Tue, Nov 12, 2019 at 9:04 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:

> On Nov 12, 2019, at 17:00, Samuel Muldoon  wrote:
>
> *Currently, the `in` operator (also known as `__contains__`) always uses
> the rightmost argument's implementation.*
>
> *For example,*
>
>
>> *   status = obj in "xylophone" *
>>
>
> *Is similar to:*
>
> *status = "xylophone".__contains__( obj )*
>
>
> *The current implementation of  `__contains__` is similar to the way that
> `+` used to only look to the leftmost argument for implementation. *
>
> *total = 4 + obj*
>>
>> *total = int.__add__(4, obj)*
>>
>
> When was this? I’m pretty sure __radd__ was there in 1.x.
>
> *However, these days, `__radd__` gives us the following:*
>
> * try:*
>> * total = type(4).__add__(4, obj)*
>> * except NotImplementedError:*
>> * total = type(obj).__radd__(obj, 4) *
>>
>
> *We propose something similar for `__contains__`: That a new dunder/magic
> method `__lcontains__` be created and that the `in` operator be implemented
> similarly to the following:*
>
> *# IMPLEMENTATION OF*
>>
>> *# status = obj in "xylophone"`*
>> *try:*
>> *status =  "xylophone".__contains__(obj)*
>> *except NotImplementedError:*
>>
>> *status = False *
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *if not status:try:status =
>> obj.__lcontains__(“xylophone”)except AttributeError:# type(obj)
>> does not have an `__lcontains__` methodwith io.StringIO() as
>> string_stream:print("unsupported operand
>> type(s) for `in`:",repr(type(4).__name__),
>> "and",repr(type(obj).__name__),
>> file=string_stream)msg = string_stream.getvalue()
>>   raise TypeError(msg) from None*
>>
>
> You’ve specified rules that are different from the one you gave for
> __radd__, and also different from the actual rules for __radd__. Is that
> intentional? If so, why?
>
> To summarize the rules: If type(rhs) is a proper subclass of type(lhs),
> check rhs.__radd__ first and fall back to lhs.__add__. Otherwise, if
> they’re the same type, only check lhs.__add__. Otherwise, check lhs.__add__
> first and fall back to rhs.__radd__. In each case, the check uses special
> method lookup, not normal getattr. Also, fallback happens if lookup raises
> an AttributeError or the call returns NotImplemented; it does not happen if
> either one raises NotImplementedError. And finally, if the fallback fails
> in the same way, you get a TypeError.
>
> *As an example application, one might develope a tree in which each node
> represents a string (the strings being unique within the tree). A property
> of the tree might be that node `n` is a descendant of node `m` if and only
> if `n` is a sub-string of `m`. For example the string "yell" is a
> descendant of "yellow." We might want the root node of the tree to be a
> special object, `root` such that every string is in `root` and that `root`
> is in no string.*
>
>
> I don’t understand why you’d want this. If your tree is defined as
> substrings of a string, why isn’t your root the maximal string, instead of
> an empty string? Also, why does `node in “yellow”` work in the first place,
> when “yellow” is a str, not a Node?  Also, any string is a substring of
> itself; do you actually want every Node to be a descendant of itself? (And,
> if so, is the root a descendant of itself or not?) And finally, doesn’t
> this mean the root of any tree contains every descendant of every possible
> tree, not just its own descendants?
>
> Most of all, why can’t you implement your rule in Python today, without
> any new methods?
>
> class Node:
> def __contains__(self, other):
> if self.isroot: return True
> if other.isroot: return False
> return other.label in self.label
>
> The only reason you need __radd__ is to handle interaction with different
> types, especially ones you don’t control. When you’re just building a
> single type, you can put all the logic in __add__. And the same thing ought
> to be true for __lcontains__.
>
> Not understanding the point of this example makes it hard to evaluate how
> well the proposal solves it, but I don’t think it actually does.
>
> * That is, the code `root in "yellow"` should return `False`. If `
> __lcontains__ ` were implemented, then we could implement the node as
> follows:*
>
>>
>>
>> *class RootNode(Node): *
>>
>> *def __contains__(container, element):*
>>
>>
>> *return True *
>>
>> *def __lcontains__(element, container):*
>>
>> *return False*
>>
>
> Presumably the rhs’s __contains__ method exists and does not raise
> NotImplementedError, right? Then by your rules, RootNode._

[Python-ideas] Re: `__lcontains__` for letting the other class determine container membership when `__contains__` fails

[Andrew Barnert via Python-ideas]

On Nov 12, 2019, at 17:00, Samuel Muldoon  wrote:
> 
> Currently, the `in` operator (also known as `__contains__`) always uses the 
> rightmost argument's implementation.
> 
> For example,
> 
>>status = obj in "xylophone" 
> 
> Is similar to:
> 
> status = "xylophone".__contains__( obj )
> 
> The current implementation of  `__contains__` is similar to the way that `+` 
> used to only look to the leftmost argument for implementation. 
> 
>> total = 4 + obj
>> total = int.__add__(4, obj)

When was this? I’m pretty sure __radd__ was there in 1.x.

> However, these days, `__radd__` gives us the following:
> 
>>  try:
>>  total = type(4).__add__(4, obj)
>>  except NotImplementedError:
>>  total = type(obj).__radd__(obj, 4) 
> 
> We propose something similar for `__contains__`: That a new dunder/magic 
> method `__lcontains__` be created and that the `in` operator be implemented 
> similarly to the following:
> 
>> # IMPLEMENTATION OF
>> # status = obj in "xylophone"`
>> try:
>> status =  "xylophone".__contains__(obj)
>> except NotImplementedError:
>> status = False 
>> if not status:
>> try:
>> status = obj.__lcontains__(“xylophone”)
>> except AttributeError:
>> # type(obj) does not have an `__lcontains__` method
>> with io.StringIO() as string_stream:
>> print(
>> "unsupported operand type(s) for `in`:",
>> repr(type(4).__name__),
>> "and",
>> repr(type(obj).__name__),
>> file=string_stream
>> )
>> msg = string_stream.getvalue()
>> raise TypeError(msg) from None

You’ve specified rules that are different from the one you gave for __radd__, 
and also different from the actual rules for __radd__. Is that intentional? If 
so, why?

To summarize the rules: If type(rhs) is a proper subclass of type(lhs), check 
rhs.__radd__ first and fall back to lhs.__add__. Otherwise, if they’re the same 
type, only check lhs.__add__. Otherwise, check lhs.__add__ first and fall back 
to rhs.__radd__. In each case, the check uses special method lookup, not normal 
getattr. Also, fallback happens if lookup raises an AttributeError or the call 
returns NotImplemented; it does not happen if either one raises 
NotImplementedError. And finally, if the fallback fails in the same way, you 
get a TypeError.

> As an example application, one might develope a tree in which each node 
> represents a string (the strings being unique within the tree). A property of 
> the tree might be that node `n` is a descendant of node `m` if and only if 
> `n` is a sub-string of `m`. For example the string "yell" is a descendant of 
> "yellow." We might want the root node of the tree to be a special object, 
> `root` such that every string is in `root` and that `root` is in no string.

I don’t understand why you’d want this. If your tree is defined as substrings 
of a string, why isn’t your root the maximal string, instead of an empty 
string? Also, why does `node in “yellow”` work in the first place, when 
“yellow” is a str, not a Node?  Also, any string is a substring of itself; do 
you actually want every Node to be a descendant of itself? (And, if so, is the 
root a descendant of itself or not?) And finally, doesn’t this mean the root of 
any tree contains every descendant of every possible tree, not just its own 
descendants?

Most of all, why can’t you implement your rule in Python today, without any new 
methods?

class Node:
def __contains__(self, other):
if self.isroot: return True
if other.isroot: return False
return other.label in self.label

The only reason you need __radd__ is to handle interaction with different 
types, especially ones you don’t control. When you’re just building a single 
type, you can put all the logic in __add__. And the same thing ought to be true 
for __lcontains__.

Not understanding the point of this example makes it hard to evaluate how well 
the proposal solves it, but I don’t think it actually does.

> That is, the code `root in "yellow"` should return `False`. If ` 
> __lcontains__ ` were implemented, then we could implement the node as follows:
>> 
>> class RootNode(Node): 
>> def __contains__(container, element):
>> 
>> return True 
>> 
>> def __lcontains__(element, container):
>> 
>> return False

Presumably the rhs’s __contains__ method exists and does not raise 
NotImplementedError, right? Then by your rules, RootNode.__lcontains__ would 
never get called. 

This is the reason for those complicated rules about proper subclasses, 
identical classes, and unrelated classes being handled differently by __radd__. 
But even with those rules, your rhs isn’t even a Node, it’s a str. And 
str.__contains__ definitely exists and doesn’t raise NotImplementedError, and, 
as it’s an unrelated class, it will get c

[Python-ideas] Re: `__lcontains__` for letting the other class determine container membership when `__contains__` fails

[Guido van Rossum]

Hm... with only a little bit of cooperation of the container class (e.g.
xylophone), you could implement this yourself:

class xylophone:
def __contains__(self, item):
if hasattr(item, '__lcontains__'):
return item.__lcontains__(self)
return False

On Tue, Nov 12, 2019 at 5:04 PM Samuel Muldoon 
wrote:

> *Currently, the `in` operator (also known as `__contains__`) always uses
> the rightmost argument's implementation.*
>
> *For example,*
>
>
>> *   status = obj in "xylophone" *
>>
>
> *Is similar to:*
>
> *status = "xylophone".__contains__( obj )*
>
>
> *The current implementation of  `__contains__` is similar to the way that
> `+` used to only look to the leftmost argument for implementation. *
>
> *total = 4 + obj*
>>
>> *total = int.__add__(4, obj)*
>>
>
> *However, these days, `__radd__` gives us the following:*
>
> * try:*
>> * total = type(4).__add__(4, obj)*
>> * except NotImplementedError:*
>>
>> * total = type(obj).__radd__(obj, 4) *
>>
>
> *We propose something similar for `__contains__`: That a new dunder/magic
> method `__lcontains__` be created and that the `in` operator be implemented
> similarly to the following:*
>
> *# IMPLEMENTATION OF*
>>
>> *# status = obj in "xylophone"`*
>> *try:*
>> *status =  "xylophone".__contains__(obj)*
>> *except NotImplementedError:*
>>
>> *status = False *
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *if not status:try:status =
>> obj.__lcontains__(“xylophone”)except AttributeError:# type(obj)
>> does not have an `__lcontains__` methodwith io.StringIO() as
>> string_stream:print("unsupported operand
>> type(s) for `in`:",repr(type(4).__name__),
>> "and",repr(type(obj).__name__),
>> file=string_stream)msg = string_stream.getvalue()
>>   raise TypeError(msg) from None*
>>
>
>
>
> *The proposed enhancement would be backwards compatible except in the
> event that a user already wrote a class having an `__lcontains__` method.*
>
> * With our running example of the string “xylophone”, writers of
> user-defined classes would be able to decide whether their objects are
> elements of  “xylophone” or not. Programmer would do this by writing an
> `__lcontains__` method.*
>
> *As an example application, one might develope a tree in which each node
> represents a string (the strings being unique within the tree). A property
> of the tree might be that node `n` is a descendant of node `m` if and only
> if `n` is a sub-string of `m`. For example the string "yell" is a
> descendant of "yellow." We might want the root node of the tree to be a
> special object, `root` such that every string is in `root` and that `root`
> is in no string. That is, the code `root in "yellow"` should return
> `False`. If ` __lcontains__ ` were implemented, then we could implement the
> node as follows:*
>
>>
>>
>> *class RootNode(Node): *
>>
>> *def __contains__(container, element):*
>>
>>
>> *return True *
>>
>> *def __lcontains__(element, container):*
>>
>> *return False*
>>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/X2VCWCBJZABPWJH5LNMYPODZKNM7UZML/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/27AFGAUBCVK4B43XXFKLT2EA4WRBN52E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] `__lcontains__` for letting the other class determine container membership when `__contains__` fails

[Samuel Muldoon]

 *Currently, the `in` operator (also known as `__contains__`) always uses
the rightmost argument's implementation.*

*For example,*


> *   status = obj in "xylophone" *
>

*Is similar to:*

*status = "xylophone".__contains__( obj )*


*The current implementation of  `__contains__` is similar to the way that
`+` used to only look to the leftmost argument for implementation. *

*total = 4 + obj*
>
> *total = int.__add__(4, obj)*
>

*However, these days, `__radd__` gives us the following:*

* try:*
> * total = type(4).__add__(4, obj)*
> * except NotImplementedError:*
>
> * total = type(obj).__radd__(obj, 4) *
>

*We propose something similar for `__contains__`: That a new dunder/magic
method `__lcontains__` be created and that the `in` operator be implemented
similarly to the following:*

*# IMPLEMENTATION OF*
>
> *# status = obj in "xylophone"`*
> *try:*
> *status =  "xylophone".__contains__(obj)*
> *except NotImplementedError:*
>
> *status = False *
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *if not status:try:status =
> obj.__lcontains__(“xylophone”)except AttributeError:# type(obj)
> does not have an `__lcontains__` methodwith io.StringIO() as
> string_stream:print("unsupported operand
> type(s) for `in`:",repr(type(4).__name__),
> "and",repr(type(obj).__name__),
> file=string_stream)msg = string_stream.getvalue()
>   raise TypeError(msg) from None*
>



*The proposed enhancement would be backwards compatible except in the event
that a user already wrote a class having an `__lcontains__` method.*

* With our running example of the string “xylophone”, writers of
user-defined classes would be able to decide whether their objects are
elements of  “xylophone” or not. Programmer would do this by writing an
`__lcontains__` method.*

*As an example application, one might develope a tree in which each node
represents a string (the strings being unique within the tree). A property
of the tree might be that node `n` is a descendant of node `m` if and only
if `n` is a sub-string of `m`. For example the string "yell" is a
descendant of "yellow." We might want the root node of the tree to be a
special object, `root` such that every string is in `root` and that `root`
is in no string. That is, the code `root in "yellow"` should return
`False`. If ` __lcontains__ ` were implemented, then we could implement the
node as follows:*

>
>
> *class RootNode(Node): *
>
> *def __contains__(container, element):*
>
>
> *return True *
>
> *def __lcontains__(element, container):*
>
> *return False*
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X2VCWCBJZABPWJH5LNMYPODZKNM7UZML/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

[David Mertz]

Yeah. Maybe I should replace regex ' *:=' rather than just ':='. That's
easy enough with the plugin

On Tue, Nov 12, 2019, 12:12 PM Mike Miller 
wrote:

>
> On 2019-11-11 16:13, David Mertz wrote:
> > I implemented this discussed arrow operator in vim with conceal plugin.
> This is
> > an example given in PEP 572.  It looks perfectly fine.  It also does not
> require
> > ANY change to Python-the-language.  It just means that I can type ':'
> followed
> > by '=' to get that, rather than type 'Alt+Shift', '2', '1', '9', '0'.
> So fewer
> > keystrokes. No chording.  Easier to type.  And what gets saved to disk
> is good
> > old plain ASCII.
>
> I like your solution and think it looks great, though perhaps you forgot
> the
> space behind it?  I'm not a huge fan of how modern Python is putting
> colons
> everywhere so this helps a tiny bit.
>
> > I don't hate how it looks, but I really, really don't get how it's
> supposed to
> > "transform my thinking about coding" to have a slightly different glyph
> on
> > screen.
>
> Probably would need several, as CB mentioned below.  Still, debatable.
>
> > I mean, as shown in this example and a previous one I posted a
> > screenshot of, I think it's cute and geeky to use a few math symbols in
> the same
> > way in my editor.  I've been doing that for a few years, and it never
> got beyond
> > "slightly cute."
>
> Guessing there were a few rare curmudgeons who didn't think we needed
> lowercase
> letters before ascii and still a few who don't want syntax highlighting
> either.
> I realize we're hitting the land of diminishing returns on text, but once
> features are gained I know I don't want to go back.
>
> For example, I use many useful Unicode symbols in my text strings and
> console
> output.  Billions of folks are using non-latin alphabets right now because
> Python3 makes it easy.  All modern systems can handle them, why not?  And
> input
> is not an significant issue, though it depends on the block.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4WNTP45AD43HJTZUTBBZF5KFOKVPPGLW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7PPNKOZW6MQNBZGFJFV7EDDJP3WSM3WO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

[Eric V. Smith]

*/PEP 328 doesn’t seem to mention any of the names detailed below./*


I strongly advise reading PEPs as documentation once their work has 
landed. At that point they are mostly historical documents and will 
not be kept up to date going forward. IOW do not read any 
import-related PEPs for help; everything will be in the stdlib docs 
for importlib or in the language reference for imports.


Just to be clear, I think Brett meant he strongly advises *against 
*reading the PEPs as documentation once they've landed.


Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OYQXUSRQJNQPXIIQMZ4BJN53OA2WIMAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

[Brett Cannon]

On Fri, Nov 8, 2019 at 11:07 AM Ricky Teachey  wrote:

>
>
>> __import__ already has a 'level' argument.
>>
>
> doh! maybe "context" is better, then.
>
>
>> Not without frame inspection to know what import statements are in the
>> context manager's block.
>>
>>
> I don't doubt you know what you're talking about, so this is a learning
> question: why couldn't you do it by simply adding an
> "inside_context_manager" flag, and producing an appropriate globals and
> locals based on the flag value?
>

Not thread-safe (we have a custom import lock to avoid this sort of
problem) and the instant you start mucking with globals() and locals() you
have (a) become a bit magical, and (b) made things extremely slow for PyPy.

My opinion on this idea is while I appreciate the motivation behind it,
this is proposing a lot of churn and change in Python to fix a single issue
that only some people hit and most people learn to avoid the first time to
realize what they have done. If it was a problem people ran into constantly
throughout their life using Python then maybe I would personally be more
receptive, but since it's a one-time mistake for vast majority of people I
think I don't feel comfortable making every book on Python be outdated
overnight over this.

-Brett


>
> this is really lame, but maybe like this:
>
> class __import__:
>
> def __enter__(self):
> self.inside_context_manager = True
> return None
>
> def __exit__(self, *args):
> self.inside_context_manager = False
>
> def __call__(self, name, globals=None, locals=None, fromlist=(),
> level=0, context=None):
> am_i_outside_context_manager =  not self.inside_context_manager
> if am_i_outside_context_manager:
> do_normal_import(name, globals, locals, fromlist, level)
> else:
> # inside context manager
> if context is None:
> raise ValueError("invalid import context")
> cglobals = contextualized_globals(globals, context)
> clocals = contextualized_locals(locals, context)
> do_special_import(name, cglobals, clocals, fromlist, level)
>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UM3WJZDPGS6C2PWVUOKJX6WLHLSZXPQI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Suggest having a mechanism to distinguish import sources

[Brett Cannon]

On Sat, Nov 9, 2019 at 10:57 AM Steve Barnes  wrote:

>
>
>
>
> *From:* Brett Cannon 
> *Sent:* 08 November 2019 18:10
> *To:* Ricky Teachey 
> *Cc:* Dan Sommers <2qdxy4rzwzuui...@potatochowder.com>; python-ideas <
> python-ideas@python.org>
> *Subject:* [Python-ideas] Re: Suggest having a mechanism to distinguish
> import sources
>
>
>
>
>
>
>
> On Fri, Nov 8, 2019 at 10:01 AM Ricky Teachey  wrote:
>
> throwing this idea out there, no idea if it is practical but it might be
> pretty nice/easily understood syntax.
>
>
>
> could a context manager be created such that anything imported under it is
> guaranteed to be imported from the standard library, and produce an error
> otherwise? perhaps by adding a level keyword argument to the __import__
> built in.
>
>
>
> __import__ already has a 'level' argument.
>
> *[Steve Barnes] *
>
> *To be honest this is the first that I have heard of __import__(level) but
> looking at the docs and help for 3.8 doesn’t read like what you describe
> below – maybe it is an un/under-documented feature – it certainly wasn’t
> easy to find in the documentation (*
> https://docs.python.org/3/library/functions.html#__import__*)!*
>

It has to do with handling relative imports. It doesn't have anything to do
with the idea being proposed beyond being a parameter name that already
exists.


>
>
> *level* specifies whether to use absolute or relative imports. 0 (the
> default) means only perform absolute imports. Positive values for *level* 
> indicate
> the number of parent directories to search relative to the directory of the
> module calling __import__()
>  (see *PEP
> 328*  for the details).
>
> *PEP 328 doesn’t seem to mention any of the names detailed below.*
>

I strongly advise reading PEPs as documentation once their work has landed.
At that point they are mostly historical documents and will not be kept up
to date going forward. IOW do not read any import-related PEPs for help;
everything will be in the stdlib docs for importlib or in the language
reference for imports.

-Brett


>
>
>
>
> something like:
>
>
>
> with __import__(level="std"):
>
> # imports guaranteed to fail of not in the standard library
>
> from pathlib import Path
>
> from sys import argv
>
>
>
> with __import__(level="package"):
>
> # imports guaranteed to fail of not in the current package
>
> import mod1
>
> import mod2
>
>
>
> with __import__(level="local"):
>
> # imports guaranteed to fail of not in the local directory
>
> import mod1
>
> import mod2
>
>
>
> with __import__(level="site"):
>
> # imports guaranteed to fail if not in site-packages, or some other
> definition that makes sense
>
> import numpy as np
>
>
>
> Not without frame inspection to know what import statements are in the
> context manager's block.
>
>
>
> This can all be done with code which calls importlib.import_module() and
> checks __spec__.origin to see where the module came from. Basically if
> you're willing to give up the syntax support of 'import' statements (which
> are just calls to __import__ with some assignments afterwards to bind
> things to names) you can have this protection today without adding syntax
> (which is always a massive ask).
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NO2CKBUAXYCLPVJLFJJ3HN2JUTH4UREF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

[Mike Miller]

On 2019-11-11 16:13, David Mertz wrote:
I implemented this discussed arrow operator in vim with conceal plugin.  This is 
an example given in PEP 572.  It looks perfectly fine.  It also does not require 
ANY change to Python-the-language.  It just means that I can type ':' followed 
by '=' to get that, rather than type 'Alt+Shift', '2', '1', '9', '0'.  So fewer 
keystrokes. No chording.  Easier to type.  And what gets saved to disk is good 
old plain ASCII.


I like your solution and think it looks great, though perhaps you forgot the 
space behind it?  I'm not a huge fan of how modern Python is putting colons 
everywhere so this helps a tiny bit.


I don't hate how it looks, but I really, really don't get how it's supposed to 
"transform my thinking about coding" to have a slightly different glyph on 
screen.  


Probably would need several, as CB mentioned below.  Still, debatable.

I mean, as shown in this example and a previous one I posted a 
screenshot of, I think it's cute and geeky to use a few math symbols in the same 
way in my editor.  I've been doing that for a few years, and it never got beyond 
"slightly cute."


Guessing there were a few rare curmudgeons who didn't think we needed lowercase 
letters before ascii and still a few who don't want syntax highlighting either. 
I realize we're hitting the land of diminishing returns on text, but once 
features are gained I know I don't want to go back.


For example, I use many useful Unicode symbols in my text strings and console 
output.  Billions of folks are using non-latin alphabets right now because 
Python3 makes it easy.  All modern systems can handle them, why not?  And input 
is not an significant issue, though it depends on the block.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4WNTP45AD43HJTZUTBBZF5KFOKVPPGLW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

[Marko Ristin-Kaufmann]

Hi,

>  I mean, as shown in this example and a previous one I posted a screenshot
> of, I think it's cute and geeky to use a few math symbols in the same way
> in my editor.  I've been doing that for a few years, and it never got
> beyond "slightly cute."
>

I  would second this. I find it actually less readable if the font does not
provide nice arrows. It reminds me of ScaLa and the "=>" symbol. The right
implication arrow was barely readable in most common Ubuntu fonts.

Cheers,
Marko

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RUC6NH26QBEVGAK575A4SABU7A7KNIRF/
Code of Conduct: http://python.org/psf/codeofconduct/