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 <ros...@gmail.com> wrote:
> On Sun, Jul 29, 2018 at 3:54 PM, Steven D'Aprano <st...@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/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
