Prev: Updating values in a dictionary
Next: Qt and progressBar - how to update
From: Gregory Ewing on 17 May 2010 03:56
John Nagle wrote:
> Also, more compile-time arithmetic becomes possible.

But only if their values can be computed at compile time. This
leads to a huge can of worms if you want to be able to import
named constants from other modules. A large part of what
currently happens only at run time would have to become
possible at compile time as well. Either that or so many
restrictions would have to be placed on the way that the
values of named constants are specified that they would not
be very useful in practice.

> I think there's some religious objection to constants in Python,

Not religious, but pragmatic. What appears to be a simple and
obvious idea on the surface turns out not to be nearly so simple
or obvious in a language as dynamic as Python.

--
Greg
From: Steven D'Aprano on 17 May 2010 05:13
On Mon, 17 May 2010 19:56:15 +1200, Gregory Ewing wrote:

> John Nagle wrote:
>> Also, more compile-time arithmetic becomes possible.
>
> But only if their values can be computed at compile time.

John said "more", not "everything imaginable can be calculated at compile
time" :)

Python already does constant folding at compile time:


>>> code = compile('"abc"*2*3', '', 'single')
>>> dis.dis(code)
1 0 LOAD_CONST 5 ('abcabcabcabcabcabc')
3 PRINT_EXPR
4 LOAD_CONST 3 (None)
7 RETURN_VALUE



> This leads to
> a huge can of worms if you want to be able to import named constants
> from other modules.


Why? Once the module is loaded, the named constant is bound to an object.
Provided that it can't be rebound or mutated, where's the can of worms?


> A large part of what currently happens only at run
> time would have to become possible at compile time as well. Either that
> or so many restrictions would have to be placed on the way that the
> values of named constants are specified that they would not be very
> useful in practice.

I disagree. Enforcing immutability would be tricky, but enforcing once-
only name binding is relatively simple. There's even a recipe for it in
the Python Cookbook.




--
Steven
From: Rhodri James on 17 May 2010 18:54
On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano
<steven(a)remove.this.cybersource.com.au> wrote:

> On Sun, 16 May 2010 18:57:15 -0700, John Nagle wrote:
>
>> James Mills wrote:
>>> The only place global variables are considered somewhat "acceptable"
>>> are as constants in a module shared as a static value.
>>
>> Python really ought to have named constants.
>
> +1
>
> Unfortunately, it will most likely require new syntax, and semantics.
> While the concept of a constant is pretty straightforward for immutable
> types like ints and strings, what about mutable types?
>
> And then there's the moratorium, so even if we had agreement on semantics
> and syntax, and a patch, it couldn't be deployed for a few years.

Careful, you're reconflating two concepts that John separated: mutability
of an object and binding of a name. I'm on the side of 'named constant'
meaning 'this name (in this scope) is bound to this object and cannot be
rebound.' That would cover most of the cases people care about, and the
gotchas are essentially the same as with default arguments.

But yes, it would require new syntax.

--
Rhodri James *-* Wildebeeste Herder to the Masses
From: Giampaolo Rodolà on 17 May 2010 19:33
2010/5/16 Chris Rebert <clp2(a)rebertia.com>:
> On Sun, May 16, 2010 at 10:50 AM, AON LAZIO <aonlazio(a)gmail.com> wrote:
>> Hi,
>> How can I set up global variables for the entire python applications?
>> Like I can call and set this variables in any .py files.
>> Think of it as a global variable in a single .py file but this is for the
>> entire application.
>
> Thankfully, there is no such thing (can you say spaghetti code?). The
> closest approximation, as I said in my previous reply, is to use the
> namespace of a designated module for this purpose, and import that
> module wherever you need to access/modify these "superglobal"
> variables.
>
> Example:
> #g.py:
> #this module exists to hold superglobal vars
> global1 = "foo"
> global2 = "bar"
>
>
> #elsewhere.py:
> #this is some other module in the same program
> import mypackage.g as g
>
> print "global #1 = ", g.global1
> print "global #2 =", g.global2
> g.global1 = "baz" # modify a superglobal
> g.global3 = "qux" # create a new superglobal
>
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
> --
> http://mail.python.org/mailman/listinfo/python-list

I agree global variables are evil, but a config.py module within a
serie of global constants which are supposed to be shared amongst all
other modules is a little less evil, and also a different beast IMO.
Even if you use a class to store such data, a "global" reference to
its instance accessible from everywhere must still exist, so the
problem basically still stands.
I would be interested to know a good practice to solve such a problem.


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
From: Steven D'Aprano on 17 May 2010 20:22
On Mon, 17 May 2010 23:54:38 +0100, Rhodri James wrote:

> On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano
> <steven(a)remove.this.cybersource.com.au> wrote:
>
>> On Sun, 16 May 2010 18:57:15 -0700, John Nagle wrote:
>>
>>> James Mills wrote:
>>>> The only place global variables are considered somewhat "acceptable"
>>>> are as constants in a module shared as a static value.
>>>
>>> Python really ought to have named constants.
>>
>> +1
>>
>> Unfortunately, it will most likely require new syntax, and semantics.
>> While the concept of a constant is pretty straightforward for immutable
>> types like ints and strings, what about mutable types?
>>
>> And then there's the moratorium, so even if we had agreement on
>> semantics and syntax, and a patch, it couldn't be deployed for a few
>> years.
>
> Careful, you're reconflating two concepts that John separated:
> mutability of an object and binding of a name.

In my own head the two issues of mutability and rebinding were completely
separate, but I see now that didn't come through as clearly as I hoped in
my post. My apologies for any confusion.


> I'm on the side of
> 'named constant' meaning 'this name (in this scope) is bound to this
> object and cannot be rebound.' That would cover most of the cases
> people care about, and the gotchas are essentially the same as with
> default arguments.

I think it is an abuse of the term constant to allow you to talk about a
mutable object being "constant", since it can vary. Generally, you don't
care about identity, only equality. Making up a syntax on the spot:

constant pi = [3.1415]
assert pi = 3.1415
pi[0] = 3
assert pi = 3.1415

makes a mockery of the concept of a constant.

Having said that, recognising mutable objects is a hard problem, so
simply for reasons of practicality we might have to just live with the
limitation that "constants" can be mutated if the object supports it.



> But yes, it would require new syntax.


Ideally, but there may be alternatives. I've already mentioned the
Cookbook recipe, or perhaps something like:

import constants
constants.register('pi')
pi = 3.1415


--
Steven
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Updating values in a dictionary
Next: Qt and progressBar - how to update