This idea comes up periodically, but it's something that appeals more to those who don't use lisp than those who do. I thought the same thing before I started really using lisp, but once you start feeling comfortable with sexps a superficial pythonic skin sounds annoying. The suggestion of trading lisp's macro features (how would you define macros with "mexps", and how would mexps interact with macros?) for syntactic whitespace that people either love or hate doesn't sound like a long term improvement.
"Mexps" might attract a few new people to lisp, but the existing lisp community would reject them. It would be more effective in the long term to show people the value of lisp's existing syntax.
"it makes the language far more flexible than any other language and provides a foundation for fully hygienic macros: you can modify the program entirely while it’s running and guarantee that there will be no crazy conflict behaviour. "
That's not true though, Common Lisp's macros can have nasty variable capture issues, can't they? This isn't using the word "hygienic" in the sense of Scheme's, so what does this mean exactly?
Common Lisp macros allow the programmer to capture variables if they desire and/or are ignorant of the semantics of the language. Sometimes this is nice, like in the anaphora package. Defining hygienic macros is not hard though.
>>> "1"*1000 is "1"*1000
False
>>> 2**31 is 2**31
False
The fact is that the only thing guaranteed by "is" is that if you have "a = b", then "a is b". Whether or not "new" objects are going to be identical to old ones is left undefined, and may change depending on type or value.
Sure. `==` should be used for such comparisons, not `is`, as the latter is semantically different. They have the same effect for "apricot" because Python interns strings up to length 20:
>>> "1"*20 is "1"*20
True
>>> "1"*21 is "1"*21
False
"==" is an equality check that calls various methods[1] to answer the question. "is" is true if and only if the two references are actually the exact same reference, or, under the hood, basically that the two pointers are equal.
>>> [1,2,3] == [1,2,3]
True
>>> [1,2,3] is [1,2,3]
False
The equality check in the case of lists is recursive and checks the equality of its elements piecewise. But they are two different lists, so they don't check "is" the same.
As an optimization, because everything in Python is an object (despite occasional claims to the contrary by the Ruby community), certain objects are created at interpreter start time and cached forever, such as (IIRC) the numbers 0 through 100 or so, so if you happen to use "is" it will sometimes "work":
>>> (1 + 3) is (2 + 2)
True
but it's not good or reliable:
>>> (1000 + 3000) is (2000 + 2000)
False
Basically, unless you are doing something with "object identity" and you know what you are doing (and if you don't know what I mean by caring about "object identity" you probably don't pass this check), OR are checking that something is specifically "None" and not merely false (as None is another of those cached values and there is only ever one None in the system), don't use "is".
Well, "is" in Python is a specific notion of object identity, and Python happens to sometimes decide it's not worth creating new objects. Not really confusing, it's just completely different from '==' (except by coincidence basically).
"Mexps" might attract a few new people to lisp, but the existing lisp community would reject them. It would be more effective in the long term to show people the value of lisp's existing syntax.