Yes I'm aware of that. That's for typing. I'm talking about implementing it in Python itself not Python typing.

Ethan:

Optional typing != core Python.

Exactly

We've already had all of this since long before typing.py existed. ALLCAPS means "this value should only be set once and not changed." _underscore means "this is not part of public API, and it may change in next version. __double_under means "this is SERIOUSLY not something you should muck with, it's likely to break stuff if you do." Python should never become a B&D language like Java. If a user violates the contracts provided by code they utilize, that's on them, not on the language. On Tue, May 25, 2021, 11:28 AM Stestagg wrote:

On Tue, May 25, 2021 at 4:02 PM Ethan Furman wrote:

...

On 5/25/21 5:23 AM, Chris Angelico wrote:

...

On Tue, May 25, 2021 at 9:55 PM Shreyan Avigyan wrote:

...

...

The proposed syntax is as follows,

constant x = 10 constant y = ["List"] constant z: str = "Hi"

https://docs.pytcorehon.org/3/library/typing.html#typing.Final https://docs.python.org/3/library/typing.html#typing.Final

Already exists :)

Optional typing != core Python.

I mean, it's part of the standard library, so we could argue on personal definitions of 'core Python', but it would be more useful to work out exactly what aspects of typing.Final are lacking for you.

Why would this constant annotation need to be more strongly enforced than type checks? What actual benefit would this provide?

Steve

--

...

~Ethan~ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/NZUWNB... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/2G2NFU... Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, May 25, 2021 at 9:36 PM Steven D'Aprano wrote:

...

ALLCAPS means "this value should only be set once and not changed."

`math.pi` says hello.

(U ⇒ O) ⊬ (¬U ⇒ ¬O) The existence of math.pi and the fact that probably nobody ever has

introduced a bug into their code by carelessly assigning another value to it suggests strongly that the benefit of language enforced constants is not high.

Well, rarely. I've once or twice carelessly tested or taught some iterative algorithm for generating pi and made the error of overwriting the name. In this particular example, and also math.e and math.tau, the lowercase follows external conventions. From time to time other such mathy constants too. But the UPPERCASE constants are pretty darn common, pre-dating Python.

...

_underscore means "this is not part of public API, and it may change in next version.

Namedtuple and the sys module also say hello.

Yeah. There are a few exceptions. I'll note... perhaps *confess*... that even though I was literally sitting at the desk next to Raymond when he was thinking about the design of namedtuple, and even discussed it with him slightly, I had assumed for more years than I wish to mention that ._asdict and ._fields were not strictly promised because of their names.

...

__double_under means "this is SERIOUSLY not something you should muck with, it's likely to break stuff if you do."

That's a convention I've never heard of before. What's the difference between "private" and "SERIOUSLY private, I REALLY mean it"?

In classes, it's name mangling. I've found that most people, or most code I've seen, treat module or function level `__double` names as implicitly similar. That's certainly what I do myself. If I don't want someone to rely on a name in future versions of some module, I'll use the single underscore. If I want to warn them that relying on it might cause bad things even right now, in this version, I'll use the double leading-underscore. Obviously it's not enforced at a language level. But it's a pretty good clue for other users.

The problem with naming conventions is that not everyone knows the conventions. Not every Python programmer spends hours every day on Python forums, reading Stackoverflow, etc. What you call "a B&D language like Java", other people might call "safety rails and warning lights".

It seems like a documentation question then. PEP 8 describes it as: - _single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose names start with an underscore. - __double_leading_underscore: when naming a class attribute, invokes name mangling - __double_leading_and_trailing_underscore__: "magic" objects or attributes that live in user-controlled namespaces. E.g. __init__, __import__ or __file__. Never invent such names; only use them as documented. It's not 100% explicit about double underscore meaning "I REALLY mean it" ... but it's kinda implied in the contrast with single underscore. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.

On Tue, May 25, 2021 at 04:27:41PM +0100, Stestagg wrote:

On Tue, May 25, 2021 at 4:02 PM Ethan Furman wrote:

...

Optional typing != core Python.

I mean, it's part of the standard library, so we could argue on personal definitions of 'core Python', but it would be more useful to work out exactly what aspects of typing.Final are lacking for you.

The actual enforcement perhaps? Without mypy, which is not part of the standard library or core language, annotating something with typing has no more benefit than a naming convention -- and likely less, since naming conventions are visible every time you refer to the name, not just at the point of creation.

Why would this constant annotation need to be more strongly enforced than type checks? What actual benefit would this provide?

I guess that comes down to your position on how strongly you care about backwards compatibility for people who ignore your (not-so?) clear documentation. If you take the Microsoft position of trying very hard not to break the code of people even if they have used undocumented internals or clearly documented private areas, you might want the interpreter to do more to discourage those practices. If you take the Apple position of not giving a damn whose code you break, then you might not. -- Steve

On 5/25/21 8:33 AM, Damian Shaw wrote:

On Tue, May 25, 2021 at 11:02 AM Ethan Furman wrote:

...

On 5/25/21 5:23 AM, Chris Angelico wrote:

...

On Tue, May 25, 2021 at 9:55 PM Shreyan Avigyan wrote:

...

...

...

The proposed syntax is as follows,

constant x = 10 constant y = ["List"] constant z: str = "Hi"

https://docs.python.org/3/library/typing.html#typing.Final

Already exists :)

Optional typing != core Python.

It's still a Python feature even if it's not a language feature, it's well defined by PEP and any type checker wanting to implement type hinting to spec must include it.

Further type hinting allows developers who want to use a Constant / Final feature get the benefit already from type hinting, whereas developers who want to stick to the pythonic philosophy of "we're all consenting adults here" can still mess with the code but know it's not supported at all. As far as I can see it's the best of both worlds.

Could you please list in your proposal the real world benefits vs. the existing type hinting feature?

To be clear, this is not my proposal, and I completely agree with David Mertz. I am -1 on the proposal. Nevertheless, the proposal is not satisfied by a stdlib module that is completely ignored by the Python runtime -- that was the only point I was trying to make. -- ~Ethan~

On Tue, May 25, 2021 at 4:41 PM Shreyan Avigyan wrote:

First it would seem useless or not necessary but soon this becomes clear. 1) It would help programmers debug their code easily and help them find out that the bug's not in the constant,

A reasonable type checker will detect cases where typing.Final annotated bindings are reassigned. For example, with mypy: https://mypy.readthedocs.io/en/stable/final_attrs.html If mypy is not catching cases of rebinding, then that would likely be treated as a bug by the maintainers. If you want help with debugging code, then a type checker will help with that.

that's for sure. 2) This would allow another branch of OOP programming to enter Python. Read-only member variables.

see above, this is already provided by mypy There are Private members in Java and C++. But I believe they are not their

to hide things. They are there to debug.

There are private methods in python too, just not enforced by the runtime, instead enforced by the myriad developer/debug tooling out there in the form of linters/checkers.

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PU4DFQ... Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, May 26, 2021 at 2:00 AM Shreyan Avigyan wrote:

I'm aware that Python is a "Consenting Adults" language but I think Python should provide this functionality at least. This idea doesn't actually make it like Java. Because why should we mess around with that member anyway. Sometimes we want to provide members that users must use but mustn't change. Well if the user does, then "crash"! Suppose we have filename member and we must access that but if we change it by any chance then what will happen is Python will not close the file instead it will create a new file leaving it in an undefined state - "Half written half not".

At best, Python could check this at run time, after it's too late. Type annotations and a tool like mypy can check it at, effectively, compilation time. All you have to do is run mypy on your code, and you'll know if that private member got assigned to. That's its point! What advantage would be gained by adding this functionality to the language interpreter, as opposed to being in the typing module and verified by an external tool? Do you really need your validation to be done later and in an unreliable way? There are four points at which a bug could be detected: 1) Editing 2) Deployment 3) Compilation (in Python's case, that happens on first import of the module) 4) Execution (an exception when you actually attempt the mutation) #1 is achieved by ALL_CAPS_NAMING_CONVENTION, because if anyone attempts to assign to it, it's obvious that something's wrong. That's the absolute earliest that you could possibly notice the bug, and *we already have that feature* built into our own brains. #2 would be where MyPy would catch the bug. Include a type checker pass in your pre-deployment checklist, possibly enforced by your pull request system, or verified automatically as part of CI. I'm not sure how you could catch this kind of thing at phase #3, but it might be possible. #4 is where you'd actually catch it, if your proposal were to be implemented. The mutation would have to occur, and only then would you get the exception. Possibly bombing your server in production. We already have options 1 and 2 available to us. You can use something that a type checker can verify, you can use something that every human can verify, and you can even do both if you're paranoid. Do you really need more than that? Remember: The thing that you declare Final will, some day, need to be changed. Probably as part of your own test suite (you do have one of those, right?). With MyPy, you could tell it not to validate that line, or that file. With a naming convention, you can explain the need for the change with a comment. How are you going to override the language feature? ChrisA

On Tue, May 25, 2021 at 5:24 PM Shreyan Avigyan wrote:

Reply to Chris:

Wait. Deployment? Before deploying we *run the code* at least once and then we get the errors. And I'm not sure but type checking is ok but sometimes enforcing is a better option. Why? Mypy or typecheckers have to be run manually

Check out pycharm with the mypy plugin. It will flag up typing.Final violations before you even finish typing the line containing the error. You can see the plugin in action in this short gif: https://imgshare.io/image/mypy.p8Gy4d

and they are also not part of the stdlib. Enforcing can help us catch it during editing because we don't deploy before running it at least once. So we're writing our own code and we don't run it before deploying? Mypy will catch at step 2 but enforcing can help as catch at step 1. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/IMD7WH... Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, May 25, 2021 at 06:09:29PM -0000, Shreyan Avigyan wrote:

I actually suggest a different kind of Constant in Python not the classical const we see in Java or C/C++.

Constants doesn't mean we can't reassign the name to a different value.

So... constants aren't constant? They're variables?

Constants behave like literals. They are sort of literals actually.

In what way are they like literals? How do literals behave?

We reference a value by a name. Variable is just a reference to a value and can change to provide reference to another value.

Right. A variable is a name that references a value.

Constants on the other hand are name for a value.

Right. Constants are a name that references a value.

So constant is a name we can alternatively use for a value.

Indeed. The only difference between a constant and a variable is that constants cannot be rebound to a new value, but variables can. But you've said that you want constants to be capable of being rebound to a new value. So your constants are identical to variables.

So 10 is same as constant while 10 is same as the value dereferenced by variable.

I don't understand what you are trying to say here. -- Steve

On Wed, May 26, 2021 at 07:14:41AM -0000, Shreyan Avigyan wrote:

Reply to Steven D'Aprano:

...

But you've said that you want constants to be capable of being rebound to a new value. So your constants are identical to variables.

No, not at all. Actually to be clear, constants are supposed to behave like literals but in implementation they are nothing more than names that are bind to a value.

I don't know how you think literals behave and you haven't told us! "Nothing more" than a name bound to a value is a variable. Why do you call it a constant if it is nothing more than a variable? -- Steve

On Wed, May 26, 2021 at 02:09:58AM +1000, Chris Angelico wrote:

Remember: The thing that you declare Final will, some day, need to be changed. Probably as part of your own test suite (you do have one of those, right?). With MyPy, you could tell it not to validate that line, or that file. With a naming convention, you can explain the need for the change with a comment. How are you going to override the language feature?

That depends on how it is implemented. Here are some thoughts. Given: constant spam = "spam and eggs" we might be able to change it like this: # Rebinding a constant raises a warning. Just ignore the warning. try: spam = "spam spam spam spam" except Warning: pass # Write directly to the namespace. globals()['spam'] = "spam spam spam spam" # Command line switch or environment variable. python3.11 --no-constants testsuite.py # Context manager. with ConstantEnforcement(False): spam = "spam spam spam spam" # Special backdoor. sys.setconstant('spam', "spam spam spam spam") Enforcing constantness doesn't necessarily imply there is no way to disable or work around it. Especially in a consenting adults language like Python, I would expect that there will be. (Most likely just write directly to the namespace.) -- Steve

Reply to Chris: There are two things I want to say about constants :- 1) Global-Local Constants - The ALL_CAPS convention variables should become constant. 2) Class member constants - Constants should be used only for avoiding from being overridden. It should not be used as "We have a class. Use constants.". Sometimes if someone changes a critical value especially in Python a dynamically typed language it can have bad effects. Suppose we have a Windows and we go to registry editor and delete keys and set different values and then Windows won't boot up the next time. That's why class member constants is necessary.

Chris wrote:

There are many arguments in favour of constants, but this one strikes me as particularly weak.

That's not exactly how I meant it. I was telling that while constant should be there it should not be used as "Use constants everywhere". I actually believe the main reason for constants should "Debugging". Our program can become unstable if something really important changes. And yeah sometimes stopping people from doing dangerous things is a good idea and sometimes not.

On Wed, May 26, 2021 at 07:25:09AM -0000, Shreyan Avigyan wrote:

2) Class member constants - Constants should be used only for avoiding from being overridden.

But you said that constants can be overriden and the name rebound. Is your proposal only to add a keyword "constant" that does absolutely nothing? If that is not your proposal, please explain what you want the keyword to do. So far you have just confused me, and I don't think I'm the only one. You have said that constants can be rebound to new values, but then you say they are used to stop them from being overridden. You said that constants act just like literals, but you won't tell us how literals act. Let me see if I can get some clarity: If I define a constant: constant pi = 3.14 what happens when I try to rebind it later? # later pi = 3.1415

Sometimes if someone changes a critical value especially in Python a dynamically typed language it can have bad effects. Suppose we have a Windows and we go to registry editor and delete keys and set different values and then Windows won't boot up the next time. That's why class member constants is necessary.

The Windows registry isn't a class. The Windows registry doesn't prevent you from changing values or deleting keys. If the keys and values in the registry were constant, then you couldn't control the behaviour of Windows, or install new applications, drivers, printers, hardware, etc. So I don't think the registry is a good example. -- Steve

On 5/26/21 5:55 AM, Shreyan Avigyan wrote:

Reply to Steven -

Literals mean 10 or 20. Can you assign something to literal? No. But you can assign something to a variable to point to another value. That's why I said constants should behave like literals. Point is constants are names bind to a value. We can change the value but not the name to point to a different value. Simply think "const type *pointer" not "type *pointer const".

And by debugging I meant it would immediately be detectable if someone tries to change the constant or not. (Not a good argument in constant's favor though)

I think the biggest problem is that basically, by definition, to actually enforce this requires a attribute lookup on EVERY rebinding or mutating operation. One stated goal was that constant mylist = [1, 2, 3] was to generate an error if you do mylist.append(4) but that also means we need to catch yourlist = mylist yourlist.append(4) and since that binding could happen on a cross module function call, every mutating operation needs a run-time check to see if this object has been bound to a constant. We also need to test everytime we bind/rebind a name, as the creation of that constant binding might be hidden behind mechanisms that we can't determine at compile time. Things like can another module inject a constant into our module? If so, we need to check every name binding to see if that name has been made a constant. This can add up to a noticable run time cost. Using the alternative of type hints says that the checker can warn us of many of the violations, and you have the OPTION of turning on run time checking if you think you have a problem (or you can just choose to always turn it on and pay the cost). -- Richard Damon

On Wed, May 26, 2021 at 11:26:17AM -0000, Shreyan Avigyan wrote:

Reply to Richard Damon:

The values can be changed. It can be mutated (if mutable). This idea suggests we can't reassign anything to the name. Suppose,

constant x = ["List"] x.append("something") # OK

x = [] # Error

At last, a straight answer to the question of what this does. Thank you. Your answer here crossed with my previous post. In the future, can you please try to use standard Python terminology instead of ambiguous language? "The values can be changed" is ambiguous. That can mean mutating an object: x.append(None) # mutation changes the value of x and it can mean rebinding: x = None # rebinding changes the value of x So now tell us, what sort of error do you get? Is it a compile-time error or a run-time error?

Think of it as a const *ptr. Don't think of it as const *ptr const.

What's a const *ptr and a const *ptr const? -- Steve

On Wed, 26 May 2021 at 12:55, Shreyan Avigyan wrote:

...

What's a const *ptr and a const *ptr const?

In C, a const pointer means a pointer that can only point to one value while const pointer const means a pointer that can only point to one constant value.

Python has names that bind to values. They are *not* equivalent to pointers that point to variables. So I suspect that the communication problem here is that you aren't thinking of what you're trying to propose in Python terms, hence everyone else (who is!) is misunderstanding you. You need to make sure that you properly understand Python's name binding mechanisms before proposing to change them... (Maybe you do, in which case can you please express your ideas in terms of those mechanisms, not in terms of C). Paul

On Wed, May 26, 2021 at 1:10 PM Shreyan Avigyan wrote:

Reply to Paul Moore:

In Python terms, a constant is a name that binds itself to a value in memory and that name cannot bind itself to a different value now (unlike variables). The value can be mutated (if mutable) but the name cannot bind to a different value once it has bind itself to a value.

Given Python already has a method for annotating a variable (name binding) as 'constant', by using typing.Final, I don't see any need for an alternative syntax for this. Wouldn't it be simpler to just propose making the compiler/runtime enforce typing.Final annotations at compile and/or run-time? PEP 591 has all of the definitions and explanation pre-written for you, so that would avoid all the terminology wrangling too ;)

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/CVMLMQ... Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, May 26, 2021 at 10:37 PM Shreyan Avigyan wrote:

Reply to Stestagg:

That's annotation to make sure no one uses a name. This is a proposal to implement constant name binding in Python. There are many applications of constants.

Yes, and you've given us zero of them. Can you show us how constants would be beneficial as part of the language, where ALL_CAPS_NAMES and typing.Final would not be beneficial? ChrisA

On Wed, May 26, 2021 at 10:53 PM Shreyan Avigyan wrote:

I've already given one. Since Python is dynamically typed changing a critical variable can cause huge instability. Want a demonstration? Here we go,

import sys sys.stdout = None

Now what? Now how can we print anything? Isn't this a bug? There are lots of code out there where we need to protect things from being overwritten. Though I'm never telling to use constants in Python stdlib or else I could have never done this demonstration. :)

A bug? Python did exactly what it should (with the possible exception, pun intended, that there could be an issue with None not being writable). That module attribute exists specifically to be overwritten. Are you saying that this should be a constant? This isn't "instability". This is the interpreter doing exactly what you told it to. Plus - this wouldn't even apply to the proposal as given, which doesn't affect module assignment, only assignment to globals. If this is the best justification you can give, I don't think this proposal is very strong. ChrisA

On Wed, May 26, 2021 at 11:20 PM Shreyan Avigyan wrote:

Reply to Chris:

Yes I know that. sys.stdout exists there for that reason only. But if we can't print then it means we changed it somewhere. I just gave an example.

Yes, an example where you're trying to show... something. Which I still don't understand, because you're advocating constants, and then citing an example of something that is specifically there for the purpose of being changed/replaced.

I've seen code where constants can be really necessary. Python lets us use these things because it's a programming language. But libraries are not programming languages. They are there to enhance the programming. Suppose we're testing out a library. Now maybe there's something really critical we shouldn't change. We must access but mustn't change. And we mistakenly changed it. Now we're not gonna deploy our application. So we don't run a type checker. Now we run and the program crashes and yet we can't find where is the bug. Why should tools be needed to solve such an obvious problem? Why can't Python itself help us like it does when we add int and str?

So........ if you think you have a problem, your program crashes, and you're having trouble finding the bug... then...... maybe that would be a good time to use a type checker? I don't know. Your examples are so extremely vague, and you're assuming that (a) the library author can and does declare that something shouldn't ever be changed, (b) the program author can and does attempt to change it, (c) the library author was correct and the program author was wrong, and (d) the program author couldn't figure this out by the fact that the name was in ALL_CAPS. That is a lot of big assumptions, especially the third one. Plus, you're assuming that this constness will be detected if the mutation happens in some other module, which is NOT part of several iterations of the proposal. Need a more specific example. Yaknow, an actual example, not just "this might happen in some universe". Figure out what you're actually proposing. Figure out what real problems it is supposed to be able to solve. The problems you're solving should govern the feature you're proposing. ChrisA

On 2021-05-26 at 12:53:32 -0000, Shreyan Avigyan wrote:

I've already given one. Since Python is dynamically typed changing a critical variable can cause huge instability. Want a demonstration? Here we go,

import sys sys.stdout = None

Now what? Now how can we print anything? Isn't this a bug? There are lots of code out there where we need to protect things from being overwritten. Though I'm never telling to use constants in Python stdlib or else I could have never done this demonstration. :)

In C: fclose(stdout); Now what? Now how can we print anything? (I'm sure other languages allow programs to close stdout, but C has come up in this thread before.) There are a handful of real use cases for closing (or otherwise changing) stdout; e.g., background/daemon processes, programs that operate exclusively in a graphical environment.

I have certainly overridden sys.stdout, it's USEFUL, Shreyan.  (One use case was to make programs pause after each screenful of output. Probably I've also used it to suppress output.) But I didn't know about sys.__stdout__, thanks Steven. And yes, I'm at least as confused as to what the proposal is as anybody else. Rob Cliffe On 26/05/2021 14:20, Steven D'Aprano wrote:

...

I've already given one. Since Python is dynamically typed changing a critical variable can cause huge instability. Want a demonstration? Here we go,

import sys sys.stdout = None

Now what? Now how can we print anything? Isn't this a bug? Assigning to None is probably a TypeError, because None doesn't implement the file object interface. But assigning to a file is

On Wed, May 26, 2021 at 12:53:32PM -0000, Shreyan Avigyan wrote: perfectly correct.

stdout, stdin and stderr are designed to be assigned to.

That's why the sys module defines `sys.__stdout__` etc, so you can easily restore them to the originals.

You should also note that there are many circumstances where sys.stdout etc are all set to None. See the documentation.

https://docs.python.org/3/library/sys.html#sys.__stdin__

Shreyan Avigyan writes:

I've already given one. Since Python is dynamically typed changing a critical variable can cause huge instability. Want a demonstration? Here we go,

import sys sys.stdout = None

Now what? Now how can we print anything?

With print(). Even in your code, it still works, for an appropriate definition of "works". See next comment.

Isn't this a bug?

Maybe, but if it is, it's a bug because you didn't sys.stdout.close() before rebinding it.[1] sys.stdout = None is useful; it has the effect of sys.stdout = open("/dev/null", "w") ie, shutting up a chatty program. (This surprised me; I thought print would raise because None has no 'write' attribute. It's an 'is None' test, not a bool test; it does complain on sys.stdout = 0. It really doesn't like 0, it complains again -- about 'flush' -- on interpreter exit. :-)

There are lots of code out there where we need to protect things from being overwritten.

Perhaps you could give a more persuasive example. The whole idea is against the usual "consenting adults" approach of Python. Or as that famous Python programmer Barack Obama put it, "let's try not to do stupid shit." :-) Footnotes: [1] I suspect there's a race condition in some environments. At least up to version 9, MacOS poll(2) and X.org were buggy together. The event loop would poll(), and if you had an open file descriptor that hadn't been closed before fork but was somehow unused in the child, it would infloop on an OS error from poll(). So if you fork before sys.stdout gets GC'd and therefore .close()'d, you could end up with such a zombie fd.

On 5/26/21 7:40 AM, Steven D'Aprano wrote:

On Wed, May 26, 2021 at 11:26:17AM -0000, Shreyan Avigyan wrote:

...

Reply to Richard Damon:

The values can be changed. It can be mutated (if mutable). This idea suggests we can't reassign anything to the name. Suppose,

constant x = ["List"] x.append("something") # OK

x = [] # Error

So we only have to check at runtime if name has been marked constant to handle cases like: if flag:     constant foo = ["List"] else:     foo = ["Other"] or import mymodule constant mymodule.foo = ["List"] or are you going to restrict how constants are created?

At last, a straight answer to the question of what this does. Thank you. Your answer here crossed with my previous post.

In the future, can you please try to use standard Python terminology instead of ambiguous language?

"The values can be changed" is ambiguous. That can mean mutating an object:

x.append(None) # mutation changes the value of x

and it can mean rebinding:

x = None # rebinding changes the value of x

So now tell us, what sort of error do you get? Is it a compile-time error or a run-time error?

...

Think of it as a const *ptr. Don't think of it as const *ptr const. What's a const *ptr and a const *ptr const?

He is assuming that people are familiar with C. -- Richard Damon

Shreyan, you have probably spent hundreds, maybe thousands of words to avoid giving straightforward, direct, explicit answers to the questions, preferring to force us to guess what you mean from vague analogies. Please stop. Please give an explicit description of the functional requirements of this proposed feature. Give code samples showing the exact behaviour. Stop expecting us to guess what you mean when your statements contradict themselves. what happens when I try to rebind a constant? constant pi = 3.14 # later pi = 3.1415 For the record, this is not a rhetorical question. I do not know the answer, I have asked at least twice before what happens when we rebind a constant, *and you won't tell me*. On Wed, May 26, 2021 at 09:55:41AM -0000, Shreyan Avigyan wrote:

Literals mean 10 or 20. Can you assign something to literal? No.

Constants aren't literals, they are names. `10` is a literal, but `pi` is a constant. Can you assign to a name? Yes, otherwise we can't give the constant a value in the first place. Can you rebind that name? You have said yes. You wrote: "Constants doesn't mean we can't reassign the name to a different value." https://mail.python.org/archives/list/python-ideas@python.org/message/NTDZ4E... Actually, I think most people think that being a constant *does* mean that you can't reassign the name to a different value. Otherwise its not a constant, its just a variable. But in the same post I linked to above you explicitly ruled out classic constants like found in C and Java (and Pascal, and other languages). So now I have *no idea* what your constants are, since apparently they behave exactly like variables: they are names that refer to values, and you can rebind them to new values.

But you can assign something to a variable to point to another value. That's why I said constants should behave like literals. Point is constants are names bind to a value. We can change the value but not the name to point to a different value.

What do you mean by "change the value"? Are you talking about mutable objects? Earlier you said that we can change the name to point to a different value, now you say that we can't.

Simply think "const type *pointer" not "type *pointer const".

That means nothing to me. This is a proposal for a feature in Python, please describe it in terms of existing Python behaviour, not whatever language that is.

And by debugging I meant it would immediately be detectable if someone tries to change the constant or not. (Not a good argument in constant's favor though)

How would it be detectable? Please stop expecting us to guess what will happen. **Tell us what will happen.** It shouldn't be this hard to get information out of somebody proposing a new language feature :-( -- Steve

On Wed, 26 May 2021 at 12:59, Shreyan Avigyan wrote:

4. constant pi = 3.14 # later pi = 3.1415 # Error

Steven's already asked what error, and is it compile time or runtime. I'll add foo.py: constant x = 12 bar.py import foo foo.x = 19 You can only detect this at runtime. baz.py import foo name = 'x' setattr(foo, name, 22) You can only detect this at runtime. Also, if some_condition: constant a = 1 else: a = 2 a = 3 Is this allowed? Is a constant? What about for i in range(10): constant a = [] Is this allowed, or is it 10 rebindings of a? for i in range(10): constant a = [i] What about this? What is a "literal" anyway? You've used lists in examples (when discussing mutability) but list displays aren't actually literals. Lots of questions. I'm sure it's possible to answer them. But as the proposer, *you* need to give the answers (or at least give a complete and precise enough specification that people can deduce the answers). At the moment, everyone is just guessing. Paul

On Wed, May 26, 2021 at 10:31 PM Shreyan Avigyan wrote:

Reply to Paul Moore:

if some_condition: constant a = 1 else: a = 2 a = 3

Yes this is allowed. This is runtime.

for i in range(10): constant a = []

Not sure. Though it's preferable to be runtime. Preferable is "not allowed".

And lists are also literals. Any Python Object that is not assigned to a variable is a literal. Python claims that itself. A preview -

[10] = [2] SyntaxError: Can't assign to literal here.

The literal that you can't assign to here is "10". You're perfectly allowed to assign to a list display: [x, y, z] = range(3)

Constants should have a similar error -

constant x = 10 x = [2] SomeErrorType: Can't assign to constant here.

Is it a syntax error? Be VERY specific here. It makes a huge difference. Also, what about this: constant x = 10 def f(): x = 20 SyntaxError? Runtime error? Shadowing? This is important and cannot be brushed aside. ChrisA

On Wed, May 26, 2021 at 11:15 PM Steven D'Aprano wrote:

On Wed, May 26, 2021 at 10:37:34PM +1000, Chris Angelico wrote:

...

Also, what about this:

constant x = 10 def f(): x = 20

SyntaxError? Runtime error? Shadowing?

The x inside the function is just a local variable. The x outside the function and the x inside it are in different namespaces and shouldn't clobber each other any more than variables in different namespaces do.

I'd kinda expect that too, but given the uncertainties in the rest of this thread, I wasn't certain. I'm fairly lost as to what the proposal even is, though. It seems to morph every time it gets poked. ChrisA

Reply to Paul Moore:

But you just said it was runtime, so it definitely *isn't* similar to the syntax error "Can't assign to literal here". You're making inconsistent statements again :-(

That's exactly why I wrote SomeErrorType instead of SyntaxError. They are never similar. I just said the behavior would seem similar.

I don't think you've thought this proposal through at all, to be honest. You seem to be making up answers as the questions arise, which is *not* what people are asking for here. We are asking that you *explain* your proposal, assuming that you already know the answers and are simply struggling to communicate the details.

I'm trying my best. But sometimes there are few questions coming up that confuses and I'm not sure of the answer and I'm ending up making inconsistent statements.

On Wed, May 26, 2021 at 12:31:07PM -0000, Shreyan Avigyan wrote:

Reply to Paul Moore:

if some_condition: constant a = 1 else: a = 2 a = 3

Yes this is allowed. This is runtime.

Do you have any suggestions for how this should be implemented, how the interpreter will know at runtime whether or not the name `a` is a constant?

for i in range(10): constant a = []

Not sure. Though it's preferable to be runtime. Preferable is "not allowed".

That is equivalent to: constant a = [] constant a = [] constant a = [] # seven more times If you can't rebind constants, then that better be disallowed. Otherwise you have rebound the constant `a` nine times: initialised it to one list on the first loop, and then the next nine loops you bind the same name to nine different lists.

And lists are also literals.

Lists are not literals. The documentation calls them *displays*. You won't find lists under "literals": https://docs.python.org/3/reference/expressions.html#literals but you will find them here: https://docs.python.org/3/reference/expressions.html#list-displays I admit that I too often wrongly refer to expressions like `[1, 2]` as a list literal, but that language is not technically correct for Python.

Any Python Object that is not assigned to a variable is a literal.

That's incorrect. When I write the expression: print(a*x + b) the object returned by `a*x + b` is not assigned to anything, but it's not a literal.

Python claims that itself. A preview -

[10] = [2] SyntaxError: Can't assign to literal here.

You are misinterpreting the error. If you look at the pointer in the syntax error, it points at the 10, not the list: >>> [10] = [2] File "<stdin>", line 1 [10] = [2] ^ SyntaxError: cannot assign to literal That statement is doing sequence unpacking: it unpacks the list [2], and the target list [10], and tries to assign 10 = 2 which is forbidden because 10 is a literal, *not* because `[10]` is a literal. (It isn't.) You can see a better example here: >>> [a, b, c, 10, d, e] = range(6) File "<stdin>", line 1 [a, b, c, 10, d, e] = range(6) ^ SyntaxError: cannot assign to literal -- Steve

if you want it for debugging, then static type checkers can do that for you. 2) This would allow another branch of OOP programming to enter Python.

Read-only member variables. There are Private members in Java and C++.

Then use Java or C++ -- the benefits of Python are not primarily the syntax, but it's dynamic nature. Though this does bring up an interesting (to the ignorant of most things typing me) question: Do the static type checkers support the concept of private attributes? That might be a nice feature. -CHB ----- Chris Barker Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

Now it seems Python doesn’t need constant. There are many ways we can achieve constants. Though constants may increase performance. Yet again it can also be the opposite. ________________________________ From: Paul Sokolovsky Sent: Saturday, May 29, 2021 12:44:09 AM To: Shreyan Avigyan Cc: python-ideas@python.org Subject: [Python-ideas] Re: Introduce constants in Python (constant name binding) Hello, On Tue, 25 May 2021 11:53:20 -0000 "Shreyan Avigyan" wrote:

I posted my previous idea regarding this on the mailing list. This idea is a little different. This idea suggests introducing constant name bindings. This is similar to const pointer in C/C++. Once a name has been assigned to a data we can change the data (if mutable) but we cannot change the name to point to a different data. The only way the data the constant points can get deallocated is if it goes out of scope, the program exits or the constant is manually `del` by the user. The proposed syntax is as follows,

constant x = 10 constant y = ["List"] constant z: str = "Hi"

The idea of introducing constants on the core language level in Python is well-known topic and was brought up on multiple occasions both on the python-ideas and python-dev mailing lists. A random example: https://www.mail-archive.com/python-dev@python.org/msg110424.html "constants in Python: Starting simple and gradually adding more features, was: Re: Pattern Matching controversy" The matter is actually implementing it in different Python implementations. And some implementations had support for *some kind* of constants for many years (e.g. MicroPython with it's pre-annotation syntax of "FOO = const(1)"), while CPython still has it only on the level of external first-generation annotation module, "typing". As another example, I can give "strict mode" (https://www.mail-archive.com/python-ideas@python.org/msg25403.html) feature of my Python dialect, Pycopy (https://github.com/pfalcon/pycopy), which implements some (but again, not all) aspects of const'ness. E.g.: === print("In import-time") a: const = 1 a: const = 2 def __main__(): print("In run-time") global a a = 3 === Gives: ==== In import-time Warning: strict mode: overriding (monkey-patching) const name 'a' In run-time Traceback (most recent call last): File "strict.py", line 9, in __main__ RuntimeError: strict mode: cannot override const name ==== -- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PHU3YE... Code of Conduct: http://python.org/psf/codeofconduct/