First of all: Thanks to everyone for explaining everything about the id function.
You are all so smart...

[Greg Ewing]
Dots have been used for attribute access in so many languages
for so long that it has become the normal and expected syntax
to use. ?. is much more recent. Maybe in another 30 years, if
it has stood the test of time, it could be argued for on the
basis of familiarity, but not now.
 
My point exactly.

[Steve D'Aprano]
You're thinking of Scratch and other languages aimed at school kids.

Nope. I'm thinking of Python. 

[Steve D'Aprano]
frankly I'm getting sick to the back teeth of 
people saying "Mustn't do that useful thing because it will make Python 
harder for beginners to learn".

Fine. So it takes them an extra day to learn one more operator. Big 
deal. 

It's not just about learning it. It's about the mental load of reading code. little things add up. 

If "sick through your back teeth" of people being cautious, that sounds like a personal problem. I'm worried about the pace people are adding functionality to Python. You start learning about concurrent.futures, then asyncio gets added with "yield from", then async def and await and all that gets added and it all seems to be a mess. Now there are how many ways to format strings?

Should we just shovel features from other popular languages into Python because they might be a little useful? I wouldn't wan't your back teeth to rot from my prudishness...

Python is very little like natural language. Your earlier idea that 
attribute access spam.eggs is like natural language (in English) because 
its only a few characters different from "spam's eggs" really doesn't 
hold up. Apart from the word order, there's no similarity.

I feel like you're being willfully dense about this. There is a difference between:

if any(thing.is_metalic for thing in pockets): raise Alarm("metal detected!")

and

if any(thing$!<>~.s_metal for thing in pockets): raise Alarm("metal detected!")

The syntax of this proposal is almost objectively disgusting. It's truly horrid. I don't know how many ways to say it.

[Steve D'Aprano]
I don't know that Python has any binary operators which are split 
into an infix part and a postfix part.

That's not at all what I proposed.

[Steve D'Aprano]
So you're against:
    spam?.eggs?.cheese?.aardvark
but you prefer:
    spam.eggs?.cheese?.aardvark?
instead.

NO! I'm proposing:

spam.eggs.cheese.aardvark?

A single POSTFIX operator that has a high priority in the order of operations.


On Sun, Jul 29, 2018 at 1:03 AM, Chris Angelico <rosuav@gmail.com> wrote:
On Sun, Jul 29, 2018 at 3:54 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Being an implementation detail, CPython is free to change it at any
> time, without warning or notice, even in a bug-fix release. If CPython
> ever gets a memory manager that can move objects around, as they can
> move in Jython and IronPython, CPython will also have to change id().
>

To clarify: If that were to happen, CPython would change *the
description of the id() function*, not the IDs returned. The IDs
returned must be constant for the lifetime of the object, as that's
what Python-the-language demands and guarantees.

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/