Re: having both dynamic and static variables
On Mar 5, 9:44 pm, John Nagle wrote: > All functions in Python can be replaced dynamically. While they're > running. From another thread. Really. Indeed, and I find this feature VERY useful when coding. Two places I've used it are: 1) in GUI coding (say, when I have a panel of buttons, and each one has its own associated function in my code -- but that function's name is not part of the object definition itself) and 2) when profiling code, and I'm trying out various versions of a function. For example, I'll write: for func in (func1, func2, func3): # do something with func() -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
"BartC" wrote:
> Another example:
>
> pi=3.141592654
>
> print ("pi is:",pi)
>
> pi=42
>
> print ("pi is now:",pi)
>
> which is clearly undesirable.
Maybe not if you're the state of Indiana :)
--
http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
"Steven D'Aprano" wrote in message
news:4d743f70$0$29984$c3e8da3$54964...@news.astraweb.com...
On Sun, 06 Mar 2011 12:59:55 -0800, Westley Martínez wrote:
I'm confused. Can someone tell me if we're talking about constant as in
'fixed in memory' or as in 'you can't reassign' or both?
Python already has fixed in memory constants. They are immutable objects
like strings, ints, floats, etc. Once you create a string "spam", you
cannot modify it. This has been true about Python forever.
What Python doesn't have is constant *names*. Once you bind an object to
a name, like this:
s = "spam"
you can't modify the *object*, but you can rebind the name:
s = "Nobody expects the Spanish Inquisition!"
and now your code that expects s to be "spam" will fail. So the only new
feature under discussion is a way to bind-once names, which many people
call constants.
Another example:
pi=3.141592654
print ("pi is:",pi)
pi=42
print ("pi is now:",pi)
which is clearly undesirable.
Many languages just don't 'get' constants; C is one (the closest it comes is
'#define' and 'enum', while what it calls 'const' is really 'read-only
variable'), and perhaps Python is another.
But then, the dividing line between constants and 'variables' can get
confused when the values involved are complex (strings and such), so might
be understandable up to a point.
--
bartc
--
http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
Steven D'Aprano writes: >> L[0].append(5) # mutate L, in some reasonable sense of "mutate" > > You haven't mutated the tuple called "L". You've mutated its internal > components, which are lists. If you wanted them to also be immutable, you > should have used tuples :) Obviously you are correct in one reasonable sense of "mutate". In another sense, if L is immutable and you evaluate a purely computational function on it two different times, you should get the same result both times; for example, if you pickle L twice you should get two identical pickles. That's what I think of "immutable" as meaning, and obviously isn't the case with this L. > The real point I was trying to make is that there are two definitions of > "constant" that we care about: immutability and resistance to name re- > binding. (Unbindability?) Python already gives us all the tools we need > for immutability (modulo the usual disclaimers about "we're all adult > here", "private attributes are private by convention", etc.). What Python > doesn't have is any way of prohibiting name rebinding short of creating a > new reserved word like None. I think I'd also want to be able to make instance attributes un-rebindable. E.g. class Foo(object): @const def wibble(self, a): ... it shouldn't be possible to redefine x.wibble if x is a Foo. That should allow for compile-time binding in a lot of practical code. -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Mon, 07 Mar 2011 13:20:39 -0800, Paul Rubin wrote: > Steven D'Aprano writes: >> but I call that a feature, not a bug. If you want an immutable >> constant, use a tuple, not a list. > > Nope: > > L = ([1,2],[3,4]) # tuple > L[0].append(5) # mutate L, in some reasonable sense of "mutate" You haven't mutated the tuple called "L". You've mutated its internal components, which are lists. If you wanted them to also be immutable, you should have used tuples :) It all depends on what sense of mutate you consider "reasonable", but once you include any mutable object in a compound object, the whole object becomes mutable in *some sense*. If you care about that sense -- and you may not -- then you have to ensure that each component that you care about immutability is immutable. The real point I was trying to make is that there are two definitions of "constant" that we care about: immutability and resistance to name re- binding. (Unbindability?) Python already gives us all the tools we need for immutability (modulo the usual disclaimers about "we're all adult here", "private attributes are private by convention", etc.). What Python doesn't have is any way of prohibiting name rebinding short of creating a new reserved word like None. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
Now you're just muddying the terminology! ~/santa On Mon, Mar 7, 2011 at 1:20 PM, Paul Rubin wrote: > Steven D'Aprano writes: > > but I call that a feature, not a bug. If you want an immutable constant, > > use a tuple, not a list. > > Nope: > >L = ([1,2],[3,4]) # tuple >L[0].append(5) # mutate L, in some reasonable sense of "mutate" > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
Steven D'Aprano writes: > but I call that a feature, not a bug. If you want an immutable constant, > use a tuple, not a list. Nope: L = ([1,2],[3,4]) # tuple L[0].append(5) # mutate L, in some reasonable sense of "mutate" -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Sun, 06 Mar 2011 12:59:55 -0800, Westley Martínez wrote: > I'm confused. Can someone tell me if we're talking about constant as in > 'fixed in memory' or as in 'you can't reassign' or both? Python already has fixed in memory constants. They are immutable objects like strings, ints, floats, etc. Once you create a string "spam", you cannot modify it. This has been true about Python forever. What Python doesn't have is constant *names*. Once you bind an object to a name, like this: s = "spam" you can't modify the *object*, but you can rebind the name: s = "Nobody expects the Spanish Inquisition!" and now your code that expects s to be "spam" will fail. So the only new feature under discussion is a way to bind-once names, which many people call constants. Perhaps the name is not the best, since I'm sure some people will be surprised that you can do this: # hypothetical example const L = [1, 2, 3] L.append(4) # works del L[:] # works L = [] # fails but I call that a feature, not a bug. If you want an immutable constant, use a tuple, not a list. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
John Nagle wrote: "let" allows the usual optimizations - constant folding, hoisting out of loops, compile time arithmetic, unboxing, etc. Only if the compiler knows the value of the constant, which it won't if it's defined in a different module. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Sun, 2011-03-06 at 07:58 +, Steven D'Aprano wrote: > On Sat, 05 Mar 2011 20:33:49 -0800, Westley Martínez wrote: > > > On Sat, 2011-03-05 at 18:37 -0800, John Nagle wrote: > >> It's worth having some syntax for constants. I'd suggest > >> using "let": > > +1 on syntax for constants. -0 for "let". I'd prefer something more > explicit, like "const". > > > I'm against constants, for the purpose of "programmers should be smart > > enough to not set a variable to another value that should be static", > > Most programmers are smart enough not to rebind names which should be > constant. The problem is, how do you know which names should be constant? > > A naming convention like ALL_CAPITALS helps, but not everybody sticks to > the convention. Also, if constants are enforced by the compiler, that > opens the door for many optimizations that currently Python can't do even > in principle. > > > > > but if Python were to have constants I think it would be better to use > > something more descriptive than 'let'. Also, because the defined > > constant is static, I think it would be better to use 'is' instead of > > '='. Example: > > No, we're talking about assignment, not a comparison operator. The `is` > operator is equivalent to `==`, equals, not assignment. > > > -- > Steven I'm confused. Can someone tell me if we're talking about constant as in 'fixed in memory' or as in 'you can't reassign' or both? -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Sat, 05 Mar 2011 20:33:49 -0800, Westley Martínez wrote: > On Sat, 2011-03-05 at 18:37 -0800, John Nagle wrote: >> It's worth having some syntax for constants. I'd suggest >> using "let": +1 on syntax for constants. -0 for "let". I'd prefer something more explicit, like "const". > I'm against constants, for the purpose of "programmers should be smart > enough to not set a variable to another value that should be static", Most programmers are smart enough not to rebind names which should be constant. The problem is, how do you know which names should be constant? A naming convention like ALL_CAPITALS helps, but not everybody sticks to the convention. Also, if constants are enforced by the compiler, that opens the door for many optimizations that currently Python can't do even in principle. > but if Python were to have constants I think it would be better to use > something more descriptive than 'let'. Also, because the defined > constant is static, I think it would be better to use 'is' instead of > '='. Example: No, we're talking about assignment, not a comparison operator. The `is` operator is equivalent to `==`, equals, not assignment. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Thu, 03 Mar 2011 06:19:41 -0800, Westley Martínez wrote: > On Wed, 2011-03-02 at 19:45 -0800, Yingjie Lan wrote: >> Hi everyone, >> >> Variables in Python are resolved dynamically at runtime, which comes at >> a performance cost. However, a lot of times we don't need that feature. >> Variables can be determined at compile time, which should boost up >> speed. [...] > I once used this obscure language called "C"; it did kind of what you're > talking about. I'm told that there might be a couple of programming languages other than Python and C. Personally, I find that hard to believe. Why would the world need _three_ programming languages? *wink* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Thu, 03 Mar 2011 08:52:16 -0800, Rafe Kettler wrote: >> Finally, Python 3 introduced type annotations, which are currently a >> feature looking for a reason. > > By type annotations, do you mean function annotations (see PEP 3107, > http://www.python.org/dev/peps/pep-3107/)? Or is this some other feature > that I'm unaware of? Sorry, yes, I meant function annotations. Of course you can use function annotations for more than just types. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Mar 5, 7:46 pm, Corey Richardson wrote: > On 03/05/2011 10:23 PM, MRAB wrote: > > > Having a fixed binding could be useful elsewhere, for example, with > > function definitions: > > [..] > > fixed PI = 3.1415926535897932384626433832795028841971693993751 > > > fixed def squared(x): > > return x * x > > This question spawns from my ignorance: When would a functions > definition change? What is the difference between a dynamic function and > a fixed function? There's a bit of ambiguity here. We have to differentiate between "fixed binding" (which is what John Nagle and MRAB were talking about) and "immutable object" (which, apparently, is how you took it). I don't like speaking of "constants" in Python because it's not always clear which is meant, and IMO it's not a constant unless it's both. An immutable object like a number or tuple can't be modified, but the name refering to it can be rebound to a different object. a = (1,2,3) a.append(4) # illegal, can't modify a tuple a = (1,2,3,4) # but this is legal, can set a to a new tuple If a hypothetical fixed binding were added to Python, you wouldn't be able to rebind a after it was set: fixed a = (1,2,3) a = (1,2,3,4) # now illegal If you could define functions with fixed bindings like this, then a compiler that's a lot smarter than CPython's would be able to inline functions for potentially big speed increases. It can't do that now because the name of the function can always be rebound to something else. BTW, a function object is definitely mutable. def squared(x): return x*x squared.foo = 'bar' Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
Shouldn't this go to python-ideas? Anyway, I'm partial to "static". ~/santa On Sat, Mar 5, 2011 at 8:33 PM, Westley Martínez wrote: > On Sat, 2011-03-05 at 18:37 -0800, John Nagle wrote: > > On 3/2/2011 9:27 PM, Steven D'Aprano wrote: > > > On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: > > > > > >> Hi everyone, > > >> > > >> Variables in Python are resolved dynamically at runtime, which comes > at > > >> a performance cost. However, a lot of times we don't need that > feature. > > >> Variables can be determined at compile time, which should boost up > > >> speed. > > > [...] > > > > > > This is a very promising approach taken by a number of projects. > > > > It's worth having some syntax for constants. I'd suggest > > using "let": > > > > let PI = 3.1415926535897932384626433832795028841971693993751 > > > > I'd propose the following semantics: > > > > 1. "let" creates an object whose binding is unchangeable. This > > is effectively a constant, provided that the value is immutable. > > A compiler may treat such variables as constants for optimization > > purposes. > > > > 2. Assignment to a a variable created with "let" produces an error > > at compile time or run time. > > > > 3. Names bound with "let" have the same scope as any other name > > created in the same context. Function-local "let" variables > > are permitted. > > > > 4. It is an error to use "let" on a name explicitly made "global", > > because that would allow access to the variable before it was > > initialized. > > > > This is close to the semantics of "const" in C/C++, except that > > there's no notion of a const parameter. > > > > "let" allows the usual optimizations - constant folding, hoisting > > out of loops, compile time arithmetic, unboxing, etc. Ordinarily, > > Python compilers have to assume that any variable can be changed > > at any time from another thread, requiring worst-case code for > > everything. > > > > John Nagle > I'm against constants, for the purpose of "programmers should be smart > enough to not set a variable to another value that should be static", > but if Python were to have constants I think it would be better to use > something more descriptive than 'let'. Also, because the defined > constant is static, I think it would be better to use 'is' instead of > '='. Example: > > constant x is 5 > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On 3/5/2011 7:46 PM, Corey Richardson wrote: On 03/05/2011 10:23 PM, MRAB wrote: Having a fixed binding could be useful elsewhere, for example, with function definitions: [..] fixed PI = 3.1415926535897932384626433832795028841971693993751 fixed def squared(x): return x * x This question spawns from my ignorance: When would a functions definition change? What is the difference between a dynamic function and a fixed function? All functions in Python can be replaced dynamically. While they're running. From another thread. Really. Implementing this is either inefficient, with a lookup for every use (CPython) or really, really complicated, involving just-in-time compilers, invalidation, recompilation, and a backup interpreter for when things get ugly (PyPy). John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Sat, 2011-03-05 at 18:37 -0800, John Nagle wrote: > On 3/2/2011 9:27 PM, Steven D'Aprano wrote: > > On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: > > > >> Hi everyone, > >> > >> Variables in Python are resolved dynamically at runtime, which comes at > >> a performance cost. However, a lot of times we don't need that feature. > >> Variables can be determined at compile time, which should boost up > >> speed. > > [...] > > > > This is a very promising approach taken by a number of projects. > > It's worth having some syntax for constants. I'd suggest > using "let": > > let PI = 3.1415926535897932384626433832795028841971693993751 > > I'd propose the following semantics: > > 1. "let" creates an object whose binding is unchangeable. This > is effectively a constant, provided that the value is immutable. > A compiler may treat such variables as constants for optimization > purposes. > > 2. Assignment to a a variable created with "let" produces an error > at compile time or run time. > > 3. Names bound with "let" have the same scope as any other name > created in the same context. Function-local "let" variables > are permitted. > > 4. It is an error to use "let" on a name explicitly made "global", > because that would allow access to the variable before it was > initialized. > > This is close to the semantics of "const" in C/C++, except that > there's no notion of a const parameter. > > "let" allows the usual optimizations - constant folding, hoisting > out of loops, compile time arithmetic, unboxing, etc. Ordinarily, > Python compilers have to assume that any variable can be changed > at any time from another thread, requiring worst-case code for > everything. > > John Nagle I'm against constants, for the purpose of "programmers should be smart enough to not set a variable to another value that should be static", but if Python were to have constants I think it would be better to use something more descriptive than 'let'. Also, because the defined constant is static, I think it would be better to use 'is' instead of '='. Example: constant x is 5 -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
A function object can get bound to a name, too: def foo(x): return x + 1 foo = lambda x: x - 1 assert foo(1) == 0 ~/santa On Sat, Mar 5, 2011 at 7:46 PM, Corey Richardson wrote: > On 03/05/2011 10:23 PM, MRAB wrote: > > Having a fixed binding could be useful elsewhere, for example, with > > function definitions: > > [..] > > fixed PI = 3.1415926535897932384626433832795028841971693993751 > > > > fixed def squared(x): > > return x * x > > This question spawns from my ignorance: When would a functions > definition change? What is the difference between a dynamic function and > a fixed function? > > -- > Corey Richardson > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On 03/05/2011 10:23 PM, MRAB wrote: > Having a fixed binding could be useful elsewhere, for example, with > function definitions: > [..] > fixed PI = 3.1415926535897932384626433832795028841971693993751 > > fixed def squared(x): > return x * x This question spawns from my ignorance: When would a functions definition change? What is the difference between a dynamic function and a fixed function? -- Corey Richardson -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On 06/03/2011 02:37, John Nagle wrote: On 3/2/2011 9:27 PM, Steven D'Aprano wrote: On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: Hi everyone, Variables in Python are resolved dynamically at runtime, which comes at a performance cost. However, a lot of times we don't need that feature. Variables can be determined at compile time, which should boost up speed. [...] This is a very promising approach taken by a number of projects. It's worth having some syntax for constants. I'd suggest using "let": let PI = 3.1415926535897932384626433832795028841971693993751 I'd propose the following semantics: 1. "let" creates an object whose binding is unchangeable. This is effectively a constant, provided that the value is immutable. A compiler may treat such variables as constants for optimization purposes. 2. Assignment to a a variable created with "let" produces an error at compile time or run time. 3. Names bound with "let" have the same scope as any other name created in the same context. Function-local "let" variables are permitted. 4. It is an error to use "let" on a name explicitly made "global", because that would allow access to the variable before it was initialized. This is close to the semantics of "const" in C/C++, except that there's no notion of a const parameter. "let" allows the usual optimizations - constant folding, hoisting out of loops, compile time arithmetic, unboxing, etc. Ordinarily, Python compilers have to assume that any variable can be changed at any time from another thread, requiring worst-case code for everything. Having a fixed binding could be useful elsewhere, for example, with function definitions: const PI = 3.1415926535897932384626433832795028841971693993751 const def squared(x): return x * x or: fixed PI = 3.1415926535897932384626433832795028841971693993751 fixed def squared(x): return x * x -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
> It's worth having some syntax for constants. I'd suggest >using "let": >let PI = 3.1415926535897932384626433832795028841971693993751 in to many languages, let is just a setter. why not just const pye = 3.14... -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On 3/2/2011 9:27 PM, Steven D'Aprano wrote: On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: Hi everyone, Variables in Python are resolved dynamically at runtime, which comes at a performance cost. However, a lot of times we don't need that feature. Variables can be determined at compile time, which should boost up speed. [...] This is a very promising approach taken by a number of projects. It's worth having some syntax for constants. I'd suggest using "let": let PI = 3.1415926535897932384626433832795028841971693993751 I'd propose the following semantics: 1. "let" creates an object whose binding is unchangeable. This is effectively a constant, provided that the value is immutable. A compiler may treat such variables as constants for optimization purposes. 2. Assignment to a a variable created with "let" produces an error at compile time or run time. 3. Names bound with "let" have the same scope as any other name created in the same context. Function-local "let" variables are permitted. 4. It is an error to use "let" on a name explicitly made "global", because that would allow access to the variable before it was initialized. This is close to the semantics of "const" in C/C++, except that there's no notion of a const parameter. "let" allows the usual optimizations - constant folding, hoisting out of loops, compile time arithmetic, unboxing, etc. Ordinarily, Python compilers have to assume that any variable can be changed at any time from another thread, requiring worst-case code for everything. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
BartC wrote: I got the impression the OP was talking about simply pinning down certain variables, so that a runtime name lookup (if that's in fact what Python does) was not necessary. A problem with this is that lexical name lookups are a relatively small proportion of the looking up that goes on in a typical Python program. Much more often you're looking up attributes of objects, which is much harder to turn into an indexed access, because the compiler has next to no knowledge of what type the object will be at run time. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
> > Declaring the *type* of such variables is a different matter I think (and > probably is not considered 'pythonic'; certainly it's a crude, if effective, > way of getting extra performance). I concur. Especially given performance is not a primary goal of Python to begin with, and--if such a bottleneck can be located--an extension module can be written to minimize it, anyway. ~/santa On Fri, Mar 4, 2011 at 1:13 PM, BartC wrote: > > "Steven D'Aprano" wrote in message > news:4d6f26a5$0$30003$c3e8da3$54964...@news.astraweb.com... > > On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: >> >> Hi everyone, >>> >>> Variables in Python are resolved dynamically at runtime, which comes at >>> a performance cost. However, a lot of times we don't need that feature. >>> Variables can be determined at compile time, which should boost up >>> speed. >>> >> [...] >> >> This is a very promising approach taken by a number of projects. >> >> Cython and Pyrex are compilers that take Python-like code with static >> type declarations and use it to produce compiled C code. >> > > I got the impression the OP was talking about simply pinning down certain > variables, so that a runtime name lookup (if that's in fact what Python > does) was not necessary. > > Declaring the *type* of such variables is a different matter I think (and > probably is not considered 'pythonic'; certainly it's a crude, if effective, > way of getting extra performance). > > -- > Bartc > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
"Steven D'Aprano" wrote in message news:4d6f26a5$0$30003$c3e8da3$54964...@news.astraweb.com... On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: Hi everyone, Variables in Python are resolved dynamically at runtime, which comes at a performance cost. However, a lot of times we don't need that feature. Variables can be determined at compile time, which should boost up speed. [...] This is a very promising approach taken by a number of projects. Cython and Pyrex are compilers that take Python-like code with static type declarations and use it to produce compiled C code. I got the impression the OP was talking about simply pinning down certain variables, so that a runtime name lookup (if that's in fact what Python does) was not necessary. Declaring the *type* of such variables is a different matter I think (and probably is not considered 'pythonic'; certainly it's a crude, if effective, way of getting extra performance). -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
> Finally, Python 3 introduced type annotations, which are currently a > feature looking for a reason. By type annotations, do you mean function annotations (see PEP 3107, http://www.python.org/dev/peps/pep-3107/)? Or is this some other feature that I'm unaware of? Rafe -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Wed, 2011-03-02 at 19:45 -0800, Yingjie Lan wrote: > Hi everyone, > > Variables in Python are resolved dynamically at runtime, which comes at a > performance cost. However, a lot of times we don't need that feature. > Variables > can be determined at compile time, which should boost up speed. Therefore, I > wonder if it is a good idea to have static variables as well. So at compile > time, a variable is determined to be either static or dynamic (the reference > of > a static varialbe is determined at compile time -- the namespace > implementation > will consist of two parts, a tuple for static variables and a dict for > dynamic > ones). The resolution can be done at the second pass of compilation. By > default, > variables are considered static. A variables is determined dynamic when: 1. > it > is declared dynamic; 2. it is not defined locally and the nearest namespace > has > it declared dynamic. A static variable can't be deleted, so a deleted > variable > must be a dynamic one: we can either enforce that the variable must be > explicitly declared or allow a del statement to implicitly declare a dynamic > variable. > > Any thoughts? > > Yingjie > > > > I once used this obscure language called "C"; it did kind of what you're talking about. -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
- Original Message From: Steven D'Aprano To: python-list@python.org Sent: Thu, March 3, 2011 1:27:01 PM Subject: Re: having both dynamic and static variables On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: > Hi everyone, > > Variables in Python are resolved dynamically at runtime, which comes at > a performance cost. However, a lot of times we don't need that feature. > Variables can be determined at compile time, which should boost up > speed. :This is a very promising approach taken by a number of projects. Thanks, that's good to know -- so people are doing this already! :Finally, Python 3 introduced type annotations, which are currently a :feature looking for a reason. I have a use for that feature -- I have a project that help build the scaffold for people to extend CPython. See http://expy.sf.net/ It is only good for Python 2 at this moment. Yingjie -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
On Wed, 02 Mar 2011 19:45:16 -0800, Yingjie Lan wrote: > Hi everyone, > > Variables in Python are resolved dynamically at runtime, which comes at > a performance cost. However, a lot of times we don't need that feature. > Variables can be determined at compile time, which should boost up > speed. [...] This is a very promising approach taken by a number of projects. Cython and Pyrex are compilers that take Python-like code with static type declarations and use it to produce compiled C code. PyPy is an implementation of Python with a JIT compiler that aims to eventually rival C for speed; it's currently about twice the speed of CPython for many tasks. It was based on the earlier project, Psyco. Neither Psyco nor PyPy require type declarations, the optimized path is taken at runtime according to the type of the data. In principle, the use of runtime data can enable the compiler to generate code which is significantly faster than would be generated at compile time. Finally, Python 3 introduced type annotations, which are currently a feature looking for a reason. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
having both dynamic and static variables
Hi everyone, Variables in Python are resolved dynamically at runtime, which comes at a performance cost. However, a lot of times we don't need that feature. Variables can be determined at compile time, which should boost up speed. Therefore, I wonder if it is a good idea to have static variables as well. So at compile time, a variable is determined to be either static or dynamic (the reference of a static varialbe is determined at compile time -- the namespace implementation will consist of two parts, a tuple for static variables and a dict for dynamic ones). The resolution can be done at the second pass of compilation. By default, variables are considered static. A variables is determined dynamic when: 1. it is declared dynamic; 2. it is not defined locally and the nearest namespace has it declared dynamic. A static variable can't be deleted, so a deleted variable must be a dynamic one: we can either enforce that the variable must be explicitly declared or allow a del statement to implicitly declare a dynamic variable. Any thoughts? Yingjie -- http://mail.python.org/mailman/listinfo/python-list
