FAQ
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

Search Discussions

  • Steven D'Aprano at Mar 3, 2011 at 5:27 am

    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
  • Yingjie Lan at Mar 3, 2011 at 6:30 am
    ----- Original Message ----

    From: Steven D'Aprano <steve+comp.lang.python at pearwood.info>
    To: python-list at 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
  • Rafe Kettler at Mar 3, 2011 at 4:52 pm

    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
  • Steven D'Aprano at Mar 6, 2011 at 7:29 am

    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
  • BartC at Mar 4, 2011 at 9:13 pm
    "Steven D'Aprano" <steve+comp.lang.python at pearwood.info> wrote in message
    news:4d6f26a5$0$30003$c3e8da3$5496439d at 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
  • Santoso Wijaya at Mar 4, 2011 at 9:39 pm

    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" <steve+comp.lang.python at pearwood.info> wrote in message
    news:4d6f26a5$0$30003$c3e8da3$5496439d at 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110304/067c1f90/attachment.html>
  • Gregory Ewing at Mar 6, 2011 at 12:51 am

    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
  • John Nagle at Mar 6, 2011 at 2:37 am

    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
  • Littlefield, Tyler at Mar 6, 2011 at 3:06 am

    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...
  • MRAB at Mar 6, 2011 at 3:23 am

    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
  • Corey Richardson at Mar 6, 2011 at 3:46 am

    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
  • Santoso Wijaya at Mar 6, 2011 at 4:03 am
    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110305/e310f662/attachment.html>
  • John Nagle at Mar 6, 2011 at 4:44 am

    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
  • John Ladasky at Mar 23, 2011 at 5:37 am

    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()
  • Carl Banks at Mar 6, 2011 at 5:59 am

    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
  • Westley Martínez at Mar 6, 2011 at 4:33 am

    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
  • Santoso Wijaya at Mar 6, 2011 at 4:47 am
    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110305/748ba9db/attachment.html>
  • Steven D'Aprano at Mar 6, 2011 at 7:58 am

    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
  • Westley Martínez at Mar 6, 2011 at 8:59 pm

    On Sun, 2011-03-06 at 07:58 +0000, 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?
  • Steven D'Aprano at Mar 7, 2011 at 2:14 am

    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
  • Paul Rubin at Mar 7, 2011 at 9:20 pm

    Steven D'Aprano <steve+comp.lang.python at pearwood.info> 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"
  • Santoso Wijaya at Mar 7, 2011 at 10:30 pm
    Now you're just muddying the terminology!

    ~/santa

    On Mon, Mar 7, 2011 at 1:20 PM, Paul Rubin wrote:

    Steven D'Aprano <steve+comp.lang.python at pearwood.info> 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110307/92cab2ff/attachment-0001.html>
  • Steven D'Aprano at Mar 8, 2011 at 1:25 am

    On Mon, 07 Mar 2011 13:20:39 -0800, Paul Rubin wrote:

    Steven D'Aprano <steve+comp.lang.python at pearwood.info> 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
  • Paul Rubin at Mar 8, 2011 at 2:22 am

    Steven D'Aprano <steve+comp.lang.python at pearwood.info> 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.
  • BartC at Mar 9, 2011 at 6:23 pm
    "Steven D'Aprano" <steve+comp.lang.python at pearwood.info> wrote in message
    news:4d743f70$0$29984$c3e8da3$5496439d at 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)

    piB

    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
  • Alex23 at Mar 10, 2011 at 1:26 am

    "BartC" wrote:
    Another example:

    pi=3.141592654

    print ("pi is:",pi)

    piB

    print ("pi is now:",pi)

    which is clearly undesirable.
    Maybe not if you're the state of Indiana :)
  • Gregory Ewing at Mar 6, 2011 at 11:28 pm

    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
  • Westley Martínez at Mar 3, 2011 at 2:19 pm

    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.
  • Steven D'Aprano at Mar 6, 2011 at 7:33 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedMar 3, '11 at 3:45a
activeMar 23, '11 at 5:37a
posts30
users15
websitepython.org

People

Translate

site design / logo © 2022 Grokbase