On Tue, May 25, 2021 at 12:14 PM Steven D'Aprano
wrote:
> On Tue, May 25, 2021 at 10:55:07AM +0200, Stéfane Fermigier wrote:
>
> > I had a similar idea ~8 years ago while working on a RAD (rapid
> application
> > development) framework [*] that had to manage business objects using a
> > variety o
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 tha
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
On Wed, May 26, 2021 at 5:26 PM Shreyan Avigyan
wrote:
>
> 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 f
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 constan
On Wed, May 26, 2021 at 07:25:09AM -, 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 absol
On Wed, May 26, 2021 at 07:14:41AM -, 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 supp
On Wed, May 26, 2021 at 07:39:54AM -, Shreyan Avigyan wrote:
> 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 a
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 nam
On Wed, May 26, 2021 at 08:58:51AM +0200, Stéfane Fermigier wrote:
> For the use cases I have in mind, some kind of context information would
> need to be passed too, like:
>
> class Customer:
>
> @permissions({"read": USER, "write": MANAGER})
> first_name: str
>
> the function primary_
On Tue, May 25, 2021 at 10:10:12PM +1000, Chris Angelico wrote:
> On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano wrote:
> > Here's a counter-proposal: we have a special symbol which is transformed
> > at compile-time to the left hand assignment target as a string. Let's
> > say we make that speci
On Wed, May 26, 2021 at 08:10:17PM +1000, Steven D'Aprano wrote:
> - Decorators are a hammer, and some people think that every problem
> is a nail.
Sorry, on re-reading that statement, it comes across as less gracious
than I intended.
So let me explicitly thank Jeremiah for raising this issue
On Wed, May 26, 2021 at 8:44 PM Steven D'Aprano wrote:
>
> On Tue, May 25, 2021 at 10:10:12PM +1000, Chris Angelico wrote:
> > On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano wrote:
> > > Here's a counter-proposal: we have a special symbol which is transformed
> > > at compile-time to the left ha
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
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
Think of it as a const *ptr. Don't think of it as const *ptr const.
___
On Wed, May 26, 2021 at 12:13 PM Steven D'Aprano
wrote:
> On Wed, May 26, 2021 at 08:58:51AM +0200, Stéfane Fermigier wrote:
>
> > For the use cases I have in mind, some kind of context information would
> > need to be passed too, like:
> >
> > class Customer:
> >
> > @permissions({"read": US
On Wed, May 26, 2021 at 9:20 PM Richard Damon wrote:
>
> 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 const
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
On Wed, May 26, 2021 at 11:26:17AM -, 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 = [] # Err
On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote:
> > I think that's a minor win in that you don't have to repeat the
> > variable name.
>
>
> Repetition is not the main issue, in my own experience. The main issue is
> the risk of making a typo in the variable's name when passi
Reply to Steven -
Sorry for creating confusions.
1. Leave debugging. As I said that's not a good argument for the existence of
constants.
2. "Constants doesn't mean we can't reassign the name to a different value."
was differently intended. I was trying to say that we should *treat* it like
> 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-ideas mailing list -- python-ideas@pytho
On 5/26/21 7:40 AM, Steven D'Aprano wrote:
> On Wed, May 26, 2021 at 11:26:17AM -, 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
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 v
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.
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.p
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 canno
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
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.
___
Python-ideas mailing list -- [email protected]
To unsubscribe sen
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. Prefe
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 s
On Wed, May 26, 2021 at 1:38 PM Shreyan Avigyan
wrote:
> Reply to Stestagg:
>
> That's annotation to make sure no one uses a name.
No.
> This is a proposal to implement constant name binding in Python.
Here are some excerpts from pep 591, specifically, how are they different
from what you a
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
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
On Wed, May 26, 2021 at 12:31:07PM -, 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
On Wed, 26 May 2021 at 13:13, 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 cann
On 2021-05-26 at 12:53:32 -,
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'
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 na
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
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. I've seen
code where constants can be really necessary. Python lets us use these things
because it's a programming language. But li
On Wed, May 26, 2021 at 12:53:32PM -, 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
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 t
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
On Wed, 26 May 2021 at 14:33, Shreyan Avigyan wrote:
>
> 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 SomeErro
On 2021-05-26 13:53, 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 lot
Ricky Teachey writes:
> Continuing on with Steven's counter proposal and the motivating example of
> symbolic math, for multiple symbols it would be this:
>
> # x, y, z = symbols( 'x,y,z' )
> x, y, z = symbols(@@)
>
> However, even though it works for the symbols example, this meaning loo
Steven D'Aprano writes:
> On Tue, May 25, 2021 at 04:24:39PM +0900, Stephen J. Turnbull wrote:
> It's not really purely cooperative. API consumers always want more than
> the API designers are willing or able to give.
True enough as stated, but "purely cooperative" doesn't mean "if I
optimize
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 yo
Well. How can I go beyond why constant was invented in the first place? As far
as I can understand by my limited knowledge that *sometimes* constants can be
useful, sometimes they are terrible. The main reason constant was invented was
to provide an additional support to programmers so that they
On Wed, May 26, 2021 at 7:54 AM Steven D'Aprano wrote:
> On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote:
>
> > Last point that I like in the decorator syntax: it's
> >
> > I can compose N different decorators and keep the intent obvious:
> >
> > @acl(READ, WRITE)
> > @constrain
I made a mistake. This sentence:
My idea is to optionally allow any callable object to write a
> __decoration_call__ method that gets called in lieu of the __call__ method
> when the callable object is employed using decorator syntax. When this
> happens, the decorated named is supplied- not count
Now this is a really interesting proposal. Something wasn't right in the other
discussion, I didn't think making variable decorators inconsistent with the
current class and function decorators by providing the variable name was
particularly good. I've always felt like that something like
__deco
While I am not at this point dropping the idea of @decorator(expression)
targetname
a thought occurred to me yesterday after discussing targetname as a string
in
assignments (and I appreciate the continued discussion in a new thread but
this is a new counter proposal so keeping it here).
There is a
I'm still digesting this proposal (though I think I like it quite a bit),
but there's one thing in particular that just really doesn't gel with me.
Is there any particular reason why you've proposed assignment decorators as
being on the same line as the assignment statement rather than on the
prec
On Wed, May 26, 2021 at 2:22 PM Matt del Valle wrote:
> I'm still digesting this proposal (though I think I like it quite a bit),
> but there's one thing in particular that just really doesn't gel with me.
>
> Is there any particular reason why you've proposed assignment decorators
> as being on
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
On 5/26/2021 7:07 AM, Chris Angelico wrote:
Either way, it would be a string. The difference is that string
literals can be placed adjacent to each other:
"{1}" f' - {1+2=} - ' '{2}'
'{1} - 1+2=3 - {2}'
Which goes to show, btw, that an f-string is still a literal, even
though it's not a const
> Although nothing in Python prevents defining __eq__() how you want and
> having it return other values can still be problematic to do so
> because of the way that __eq__() is tied to __hash__() and used in
> dicts and sets.
I think, this can work if you guarantee there are no hash collisions. T
58 matches
Mail list logo
