> What you're calling 'true globals,' other languages (e.g. PHP) call
> superglobals. Python does have these, sort of: you can emulate a
> superglobal by sticking things into __builtins__, which isn't
> particularly clean, but gets the job done.
Thanks for reply. It appears from your comments abo
[EMAIL PROTECTED] wrote:
> I would like to suggest replacing the 'global' keyword
> with a new keyword 'modular'.
What you're calling 'true globals,' other languages (e.g. PHP) call
superglobals. Python does have these, sort of: you can emulate a
superglobal by sticking things into __builtins__, w
I would like to suggest replacing the 'global' keyword
with a new keyword 'modular'.
Why? In my limited understanding, 'global' means "in all namespaces"
or "visible everywhere".
Because globals are accessed like this:
mymodule.myvariable
they are just as "global" as this:
mymodule.mycla
On 7/6/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > So, my proposal is to give up on static, accept PEP 3103 with the
> > following options:
> > - Syntax alternative 2+B (unindented cases, 'case in ...' for multiple
> > cases).
> > - Semantics option 3 (def-time fr
On 7/6/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
I would like to propose a syntax that would explicitly be read as"Create an object of Foo converted from object Bar". Being explicit,as such, could bring about some interesting optimizations in thefuture or immediately, and reduce redundant sign
Calvin Spealman wrote:
> # Get the first index of a value in a list
> idx = 'b' from ['a', 'b', 'c']
> assert idx == 'b'
'assert idx == 1'?
--
Ivan Krstic <[EMAIL PROTECTED]> | GPG: 0x147C722D
___
Python-3000 mailing list
Python-3000@python
as you may remember, i suggest some time ago to distinguish
between the *function* type that returns the type of an object,
and *metaclass* type that creates new types. the main issue
was type() behaving both as a function and as a factory, which
is an overloaded behavior.
if i recall correctly, t
I would like to propose a syntax that would explicitly be read as
"Create an object of Foo converted from object Bar". Being explicit,
as such, could bring about some interesting optimizations in the
future or immediately, and reduce redundant signatures (such as the
type(foo) syntax). I understand
Greg Ewing writes:
> Maybe a compromise could be reached by having the
> style guide recommend a two-space indent for the
> cases, and a further two-space indent for the
> case bodies. Then the overall indentation of the
> bodies would still be only four spaces.
+1: I tried it and it looks good on
