Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #49801 > unrolled thread

Default scope of variables

Back to article view | Back to comp.lang.python

Contents

  Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-04 03:27 +0000
    Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-04 14:07 +1000
      Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-04 05:32 +0000
        Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-04 15:47 +1000
          Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-04 16:38 +0000
            Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-05 02:58 +1000
            Re: Default scope of variables Wayne Werner <wayne@waynewerner.com> - 2013-07-07 08:13 -0500
            Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-07 23:43 +1000
              Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-07 16:03 +0000
                Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-08 10:46 +1000
              Re: Default scope of variables alex23 <wuwei23@gmail.com> - 2013-07-09 14:52 +1000
                Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-09 15:07 +1000
                  Re: Default scope of variables alex23 <wuwei23@gmail.com> - 2013-07-09 16:08 +1000
                    Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-09 16:13 +1000
                    Re: Default scope of variables "Frank Millman" <frank@chagford.com> - 2013-07-09 09:35 +0200
                    Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-09 17:45 +1000
                    Re: Default scope of variables Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-09 01:56 -0600
                    Re: Default scope of variables "Frank Millman" <frank@chagford.com> - 2013-07-09 10:22 +0200
                    Re: Default scope of variables "Frank Millman" <frank@chagford.com> - 2013-07-09 10:38 +0200
                    Re: Default scope of variables Ethan Furman <ethan@stoneleaf.us> - 2013-07-09 09:07 -0700
                    Re: Default scope of variables Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-09 10:44 -0600
                    Re: Default scope of variables Ethan Furman <ethan@stoneleaf.us> - 2013-07-09 10:23 -0700
                    Re: Default scope of variables Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-09 12:41 -0600
                    Re: Default scope of variables Ethan Furman <ethan@stoneleaf.us> - 2013-07-09 12:19 -0700
                    Re: Default scope of variables "Frank Millman" <frank@chagford.com> - 2013-07-10 07:54 +0200
                    Re: Default scope of variables Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-10 09:42 -0600
                    Re: Default scope of variables Ethan Furman <ethan@stoneleaf.us> - 2013-07-10 08:29 -0700
                    Re: Default scope of variables "Frank Millman" <frank@chagford.com> - 2013-07-11 07:52 +0200
            Re: Default scope of variables Ethan Furman <ethan@stoneleaf.us> - 2013-07-07 09:52 -0700
            Re: Default scope of variables Ethan Furman <ethan@stoneleaf.us> - 2013-07-07 11:59 -0700
            Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-08 10:48 +1000
              Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-08 02:23 +0000
                Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-08 13:11 +1000
                  Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-08 05:00 +0000
                    Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-08 15:14 +1000
        Re: Default scope of variables Peter Otten <__peter__@web.de> - 2013-07-04 08:48 +0200
        Re: Default scope of variables Ian Kelly <ian.g.kelly@gmail.com> - 2013-07-04 01:12 -0600
        Re: Default scope of variables Dave Angel <davea@davea.name> - 2013-07-04 03:06 -0400
          Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-04 15:52 +0000
          Re: Default scope of variables Rotwang <sg552@hotmail.co.uk> - 2013-07-04 17:54 +0100
            Re: Default scope of variables Peter Otten <__peter__@web.de> - 2013-07-04 20:36 +0200
            Re: Default scope of variables Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-05 01:04 +0100
            Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-05 01:24 +0000
              Re: Default scope of variables Dave Angel <davea@davea.name> - 2013-07-04 22:03 -0400
              Re: Default scope of variables Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-05 03:29 +0100
              Re: Default scope of variables Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-05 03:27 +0100
              Re: Default scope of variables Rotwang <sg552@hotmail.co.uk> - 2013-07-05 07:28 +0100
          Re: Default scope of variables Neil Cerutti <neilc@norwich.edu> - 2013-07-05 13:24 +0000
            Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-05 23:43 +1000
              Re: Default scope of variables Neil Cerutti <neilc@norwich.edu> - 2013-07-05 15:36 +0000
            Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-07 16:08 +0000
              Re: Default scope of variables Neil Cerutti <neilc@norwich.edu> - 2013-07-08 11:54 +0000
                Re: Default scope of variables Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-08 14:14 +0100
        Re: Default scope of variables Lele Gaifax <lele@metapensiero.it> - 2013-07-04 14:43 +0200
        Re: Default scope of variables Wayne Werner <wayne@waynewerner.com> - 2013-07-04 10:45 -0500
    Re: Default scope of variables Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-04 05:30 +0100
      Re: Default scope of variables Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-07-04 05:45 +0000
    Re: Default scope of variables Chris Angelico <rosuav@gmail.com> - 2013-07-04 14:36 +1000
    Re: Default scope of variables Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-04 06:09 +0100
    Re: Default scope of variables Joshua Landau <joshua.landau.ws@gmail.com> - 2013-07-08 17:58 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#49895

Rotwang wrote:

> Sorry to be OT, but this is sending my pedantry glands haywire:

We are mostly pedants, too -- so this is well-deserved...
 
> On 04/07/2013 08:06, Dave Angel wrote:
>> On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
>>>
>>        <SNIP>
>>>
>>> Well, if I ever have more than 63,000,000 variables[1] in a function,
>>> I'll keep that in mind.
>>>
>>      <SNIP>
>>>
>>> [1] Based on empirical evidence that Python supports names with length
>>> [at
>>> least up to one million characters long, and assuming that each
>>> character can be an ASCII letter, digit or underscore.
>>>
>>
>> Well, the number wouldn't be 63,000,000.  Rather it'd be 63**1000000
>>
>> I probably have it wrong, but I think that looks like:
>>
>> 859,122,[etc.]
>>
>>
>> variables.  (The number has 180 digits)
> 
> That's 63**100. Note that 10**1000000 has 1000001 digits, and is
> somewhat smaller than 63**1000000.
> 
> Anyway, none of the calculations that has been given takes into account
> the fact that names can be /less/ than one million characters long. 

I think we have a winner ;)

> The
> actual number of non-empty strings of length at most 1000000 characters,
> that consist only of ascii letters, digits or underscores, and that
> don't start with a digit, is
> 
> sum(53*63**i for i in range(1000000)) == 53*(63**1000000 - 1)//62

> It's perhaps worth mentioning that some non-ascii characters are allowed
> in identifiers in Python 3, though I don't know which ones.

[toc] | [prev] | [next] | [standalone]

#49910

On 4 July 2013 17:54, Rotwang <sg552@hotmail.co.uk> wrote:
> 53*(63**1000000 - 1)//62

Or about 10**10**6.255 (so about 1.80M digits long).


For the unicode side (Python 3, in other words) and reusing your math
(ya better hope it's right!), you are talking:

97812*((97812+2020)**1000000 - 1)/(97812+2020-1)

Or about 10**10**6.699

Which has about 5.00M digits.


Good luck running out.

[toc] | [prev] | [next] | [standalone]

#49915

On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
[...]
> Anyway, none of the calculations that has been given takes into account
> the fact that names can be /less/ than one million characters long. 


Not in *my* code they don't!!!

*wink*


> The
> actual number of non-empty strings of length at most 1000000 characters,
> that consist only of ascii letters, digits or underscores, and that
> don't start with a digit, is
> 
> sum(53*63**i for i in range(1000000)) == 53*(63**1000000 - 1)//62


I take my hat of to you sir, or possibly madam. That is truly an inspired 
piece of pedantry.


> It's perhaps worth mentioning that some non-ascii characters are allowed
> in identifiers in Python 3, though I don't know which ones.

PEP 3131 describes the rules:

http://www.python.org/dev/peps/pep-3131/

For example:

py> import unicodedata as ud
py> for c in 'é極¿μЖᚃ‰⇄∞':
...     print(c, ud.name(c), c.isidentifier(), ud.category(c))
...
é LATIN SMALL LETTER E WITH ACUTE True Ll
æ LATIN SMALL LETTER AE True Ll
¥ YEN SIGN False Sc
µ MICRO SIGN True Ll
¿ INVERTED QUESTION MARK False Po
μ GREEK SMALL LETTER MU True Ll
Ж CYRILLIC CAPITAL LETTER ZHE True Lu
ᚃ OGHAM LETTER FEARN True Lo
‰ PER MILLE SIGN False Po
⇄ RIGHTWARDS ARROW OVER LEFTWARDS ARROW False So
∞ INFINITY False Sm



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#49921

On 07/04/2013 09:24 PM, Steven D'Aprano wrote:
> On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
> [...]
>> Anyway, none of the calculations that has been given takes into account
>> the fact that names can be /less/ than one million characters long.
>
>
> Not in *my* code they don't!!!
>
> *wink*
>
>
>> The
>> actual number of non-empty strings of length at most 1000000 characters,
>> that consist only of ascii letters, digits or underscores, and that
>> don't start with a digit, is
>>
>> sum(53*63**i for i in range(1000000)) == 53*(63**1000000 - 1)//62
>
>
> I take my hat of to you sir, or possibly madam. That is truly an inspired
> piece of pedantry.
>
>
>> It's perhaps worth mentioning that some non-ascii characters are allowed
>> in identifiers in Python 3, though I don't know which ones.
>
> PEP 3131 describes the rules:
>
> http://www.python.org/dev/peps/pep-3131/
>
> For example:
>
> py> import unicodedata as ud
> py> for c in 'é極¿μЖᚃ‰⇄∞':
> ...     print(c, ud.name(c), c.isidentifier(), ud.category(c))
> ...
> é LATIN SMALL LETTER E WITH ACUTE True Ll
> æ LATIN SMALL LETTER AE True Ll
> ¥ YEN SIGN False Sc
> µ MICRO SIGN True Ll
> ¿ INVERTED QUESTION MARK False Po
> μ GREEK SMALL LETTER MU True Ll
> Ж CYRILLIC CAPITAL LETTER ZHE True Lu
> ᚃ OGHAM LETTER FEARN True Lo
> ‰ PER MILLE SIGN False Po
> ⇄ RIGHTWARDS ARROW OVER LEFTWARDS ARROW False So
> ∞ INFINITY False Sm
>
>
>

The isidentifier() method will let you weed out the characters that 
cannot start an identifier.  But there are other groups of characters 
that can appear after the starting "letter".  So a more reasonable 
sample might be something like:

 > py> import unicodedata as ud
 > py> for c in 'é極¿μЖᚃ‰⇄∞':
 > ...     xc = "X" + c
 > ...     print(c, ud.name(c), xc.isidentifier(), ud.category(c))
 > ...

In particular,
     http://docs.python.org/3.3/reference/lexical_analysis.html#identifiers

has a  definition for id_continue that includes several interesting 
categories.  I expected the non-ASCII digits, but there's other stuff 
there, like "nonspacing marks" that are surprising.

I'm pretty much speculating here, so please correct me if I'm way off.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#49922

On 5 July 2013 03:03, Dave Angel <davea@davea.name> wrote:
> In particular,
>     http://docs.python.org/3.3/reference/lexical_analysis.html#identifiers
>
> has a  definition for id_continue that includes several interesting
> categories.  I expected the non-ASCII digits, but there's other stuff there,
> like "nonspacing marks" that are surprising.

"nonspacing marks" are just accents, so it makes sense *á* mon avis.

[toc] | [prev] | [next] | [standalone]

#49923

On 5 July 2013 03:03, Dave Angel <davea@davea.name> wrote:
> On 07/04/2013 09:24 PM, Steven D'Aprano wrote:
>> On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
>>> It's perhaps worth mentioning that some non-ascii characters are allowed
>>> in identifiers in Python 3, though I don't know which ones.
>>
>> PEP 3131 describes the rules:
>>
>> http://www.python.org/dev/peps/pep-3131/
>
> The isidentifier() method will let you weed out the characters that cannot
> start an identifier.  But there are other groups of characters that can
> appear after the starting "letter".  So a more reasonable sample might be
> something like:
...
> In particular,
>     http://docs.python.org/3.3/reference/lexical_analysis.html#identifiers
>
> has a  definition for id_continue that includes several interesting
> categories.  I expected the non-ASCII digits, but there's other stuff there,
> like "nonspacing marks" that are surprising.
>
> I'm pretty much speculating here, so please correct me if I'm way off.

For my calculation above, I used this code I quickly mocked up:

> import unicodedata as unidata
> from sys import maxunicode
> from collections import defaultdict
> from itertools import chain
>
> def get():
>     xid_starts = set()
>     xid_continues = set()
>
>     id_start_categories = "Lu, Ll, Lt, Lm, Lo, Nl".split(", ")
>     id_continue_categories = "Mn, Mc, Nd, Pc".split(", ")
>
>     characters = (chr(n) for n in range(maxunicode + 1))
>
>     print("Making normalized characters")
>
>     normalized = (unidata.normalize("NFKC", character) for character in characters)
>     normalized = set(chain.from_iterable(normalized))
>
>     print("Assigning to categories")
>
>     for character in normalized:
>         category = unidata.category(character)
>
>         if category in id_start_categories:
>             xid_starts.add(character)
>         elif category in id_continue_categories:
>             xid_continues.add(character)
>
>     return xid_starts, xid_continues

Please note that "xid_continues" actually represents "xid_continue - xid_start".

[toc] | [prev] | [next] | [standalone]

#49926

On 05/07/2013 02:24, Steven D'Aprano wrote:
> On Thu, 04 Jul 2013 17:54:20 +0100, Rotwang wrote:
> [...]
>> Anyway, none of the calculations that has been given takes into account
>> the fact that names can be /less/ than one million characters long.
>
>
> Not in *my* code they don't!!!
>
> *wink*
>
>
>> The
>> actual number of non-empty strings of length at most 1000000 characters,
>> that consist only of ascii letters, digits or underscores, and that
>> don't start with a digit, is
>>
>> sum(53*63**i for i in range(1000000)) == 53*(63**1000000 - 1)//62
>
>
> I take my hat of to you sir, or possibly madam. That is truly an inspired
> piece of pedantry.

FWIW, I'm male.


>> It's perhaps worth mentioning that some non-ascii characters are allowed
>> in identifiers in Python 3, though I don't know which ones.
>
> PEP 3131 describes the rules:
>
> http://www.python.org/dev/peps/pep-3131/

Thanks.

[toc] | [prev] | [next] | [standalone]

#49982

On 2013-07-04, Dave Angel <davea@davea.name> wrote:
> On 07/04/2013 01:32 AM, Steven D'Aprano wrote:
>        <SNIP>
>> Well, if I ever have more than 63,000,000 variables[1] in a
>> function, I'll keep that in mind.
>>
>      <SNIP>
>>
>> [1] Based on empirical evidence that Python supports names
>> with length at least up to one million characters long, and
>> assuming that each character can be an ASCII letter, digit or
>> underscore.
>
> Well, the number wouldn't be 63,000,000.  Rather it'd be
> 63**1000000

You should really count only the ones somebody might actually
want to use. That's a much, much smaller number, though still
plenty big.

Inner scopes (I don't remember the official name) is a great
feature of C++. It's not the right feature for Python, though,
since Python doesn't have deterministic destruction. It wouldn't
buy much except for namespace tidyness.

for x in range(4):
   print(x)
print(x) # Vader NOoooooOOOOOO!!!

Python provides deterministic destruction with a different
feature.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#49984

On Fri, Jul 5, 2013 at 11:24 PM, Neil Cerutti <neilc@norwich.edu> wrote:
> Python provides deterministic destruction with a different
> feature.

You mean 'with'? That's not actually destruction, it just does one of
the same jobs that deterministic destruction is used for (RAII). It
doesn't, for instance, have any influence on memory usage, nor does it
ensure the destruction of the object's referents. But yes, it does
achieve (one of) the most important role(s) of destruction.

ChrisA

[toc] | [prev] | [next] | [standalone]

#49995

On 2013-07-05, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Jul 5, 2013 at 11:24 PM, Neil Cerutti
> <neilc@norwich.edu> wrote:
>> Python provides deterministic destruction with a different
>> feature.
>
> You mean 'with'? That's not actually destruction, it just does
> one of the same jobs that deterministic destruction is used for
> (RAII). It doesn't, for instance, have any influence on memory
> usage, nor does it ensure the destruction of the object's
> referents. But yes, it does achieve (one of) the most important
> role(s) of destruction.

Yes, thanks. I meant the ability to grab and release a
resource deterministically.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#50104

On Fri, 05 Jul 2013 13:24:43 +0000, Neil Cerutti wrote:

> for x in range(4):
>    print(x)
> print(x) # Vader NOoooooOOOOOO!!!

That loops do *not* introduce a new scope is a feature, not a bug. It is 
*really* useful to be able to use the value of x after the loop has 
finished. That's a much more common need than being able to have an x 
inside the loop and an x outside the loop.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#50146

On 2013-07-07, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Fri, 05 Jul 2013 13:24:43 +0000, Neil Cerutti wrote:
>
>> for x in range(4):
>>    print(x)
>> print(x) # Vader NOoooooOOOOOO!!!
>
> That loops do *not* introduce a new scope is a feature, not a bug. It is 
> *really* useful to be able to use the value of x after the loop has 
> finished.

I don't buy necessarily buy that it's "*really*" useful but I do
like introducing new names in (not really the scope of)
if/elif/else and for statement blocks.

z = record["Zip"]
if int(z) > 99999:
    zip_code = z[:-4].rjust(5, "0")
    zip4 = z[-4:]
else:
  zip_code = z.rjust(5, "0")
  zip4 = ""


As opposed to:

zip_code = None
zip4 = None
z = record["Zip"]
if int(z) > 99999:
    zip_code = z[:-4].rjust(5, "0")
    zip4 = z[-4:]
else:
    zip_code = z.rjust(5, "0")
    zip4 = ""

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#50155

On 8 July 2013 12:54, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-07-07, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>> On Fri, 05 Jul 2013 13:24:43 +0000, Neil Cerutti wrote:
>>
>>> for x in range(4):
>>>    print(x)
>>> print(x) # Vader NOoooooOOOOOO!!!
>>
>> That loops do *not* introduce a new scope is a feature, not a bug. It is
>> *really* useful to be able to use the value of x after the loop has
>> finished.
>
> I don't buy necessarily buy that it's "*really*" useful

Just take "really" to mean "like, I'm totz not lying".

> but I do
> like introducing new names in (not really the scope of)
> if/elif/else and for statement blocks.
>
> z = record["Zip"]
> if int(z) > 99999:
>     zip_code = z[:-4].rjust(5, "0")
>     zip4 = z[-4:]
> else:
>   zip_code = z.rjust(5, "0")
>   zip4 = ""

I'd probably break down and cry if "if"s introduced a new scope in
Pythons before the "nonlocal" keyword (assuming current Python
semantics where "=" defaults to only the inner-most scope).

[toc] | [prev] | [next] | [standalone]

#49850

Dave Angel <davea@davea.name> writes:

> Well, the number wouldn't be 63,000,000.  Rather it'd be 63**1000000

Uhm, if we are talking about Py2, then you should not count all the
combinations starting with a digit, while under Py3 the number explodes,
as this is valid code:

>>> à = 1
>>> à
1

:-)

back to easily-enumerable issues,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [next] | [standalone]

#49877

On Thu, 4 Jul 2013, Steven D'Aprano wrote:
>
> [1] Based on empirical evidence that Python supports names with length at
> least up to one million characters long, and assuming that each character
> can be an ASCII letter, digit or underscore.
>

The specification *does* state unlimited length:

http://docs.python.org/release/2.5.2/ref/identifiers.html

Though practicality beats purity.

-W

[toc] | [prev] | [next] | [standalone]

#49807

On 4 July 2013 05:07, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> With respect to the Huffman coding of declarations, Javascript gets it
>> backwards. Locals ought to be more common, but they require more typing.
>> Locals are safer, better, more desirable than globals, and so it should
>> be easier to use locals than globals, not the other way around. Having to
>> declare "give me the safe kind of variable", while getting the harmful[1]
>> kind of variable for free, strikes me as arse-backwards. Lazy, naive or
>> careless coders get globals[2] by default or accident. That's bad.
>
> I agree that Javascript has it wrong, but not quite for the reason you
> say. The advantage of declaring locals is a flexibility: you can have
> multiple unique variables with the same name in the same function.
> Python lets you do that across but not within functions.
>
> But Javascript/ECMAScript/whatever doesn't give you that. A var
> declaration makes it function-local, no matter where the declaration
> is.

Coffeescript, which compiles to Javascript, "fixes" the problem Steven
brought up by automatically declaring variables so that you don't have
to. But what do you think this does?:

a = 1
func = ->
    a = 2
    b = 2

The "a" in "func" is global, the "b" is local. And Coffeescript
*doesn't let* you shadow even if you explicitly want to. There just
isn't syntax for it.

That said, I'm not too convinced. Personally, the proper way to do
what you are talking about is creating a new closure. Like:

for i in range(100):
    with new_scope():
        for i in range(100):
            func(i)
    func(i) # Using i from original loop

But it's not like Python'll ever support that.

[toc] | [prev] | [next] | [standalone]

#49816

On Thu, 04 Jul 2013 05:30:03 +0100, Joshua Landau wrote:

> That said, I'm not too convinced. Personally, the proper way to do what
> you are talking about is creating a new closure. Like:
> 
> for i in range(100):
>     with new_scope():
>         for i in range(100):
>             func(i)
>     func(i) # Using i from original loop
> 
> But it's not like Python'll ever support that.

Probably not, but Python does support this:


for i in range(100):
    for j in range(100):
        func(j)
    func(i) # Using i from original loop


which solves the problem of inner i overwriting outer i nicely.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#49809

On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
<joshua.landau.ws@gmail.com> wrote:
> That said, I'm not too convinced. Personally, the proper way to do
> what you are talking about is creating a new closure. Like:
>
> for i in range(100):
>     with new_scope():
>         for i in range(100):
>             func(i)
>     func(i) # Using i from original loop
>
> But it's not like Python'll ever support that.
>

def foo():
  for i in range(3):
    print("outer",i)
    def inner():
      for i in range(4):
        print("inner",i)
    inner()
    print("outer",i)

That works, but you then have to declare all your nonlocals, and it
hardly reads well.

ChrisA

[toc] | [prev] | [next] | [standalone]

#49811

On 4 July 2013 05:36, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
> <joshua.landau.ws@gmail.com> wrote:
>> That said, I'm not too convinced. Personally, the proper way to do
>> what you are talking about is creating a new closure. Like:
>>
>> for i in range(100):
>>     with new_scope():
>>         for i in range(100):
>>             func(i)
>>     func(i) # Using i from original loop
>>
>> But it's not like Python'll ever support that.
>>
>
> def foo():
>   for i in range(3):
>     print("outer",i)
>     def inner():
>       for i in range(4):
>         print("inner",i)
>     inner()
>     print("outer",i)
>
> That works, but you then have to declare all your nonlocals, and it
> hardly reads well.

Unfortunately that's what people, I included, end up doing. Stuff like:

def paranoia(...):
    def safe_recursive(...):
        safe_recursive(...)
    return safe_recursive
safe_recursive = paranoia()

is blimmin ugly. Then you're only really left with

class safe_recursive:
    def __call__(self, ...):
        self(...)

which only solves it for recursive functions.

I guess this means I actually agree with your sentiment, just not the specifics.

[toc] | [prev] | [next] | [standalone]

#50161

On 4 July 2013 05:36, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Jul 4, 2013 at 2:30 PM, Joshua Landau
> <joshua.landau.ws@gmail.com> wrote:
>> That said, I'm not too convinced. Personally, the proper way to do
>> what you are talking about is creating a new closure. Like:
>>
>> for i in range(100):
>>     with new_scope():
>>         for i in range(100):
>>             func(i)
>>     func(i) # Using i from original loop
>>
>> But it's not like Python'll ever support that.
>>
>
> def foo():
>   for i in range(3):
>     print("outer",i)
>     def inner():
>       for i in range(4):
>         print("inner",i)
>     inner()
>     print("outer",i)
>
> That works, but you then have to declare all your nonlocals, and it
> hardly reads well.

Stealing concepts shamelessly from
http://www.slideshare.net/r1chardj0n3s/dont-do-this-24000445, you can
do this:

import inspect
from contextlib import contextmanager

@contextmanager
def scope(namespace=None):
    old_names = inspect.currentframe().f_back.f_back.f_locals.copy()

    yield

    names = inspect.currentframe().f_back.f_back.f_locals

    if namespace is not None:
        new_names = {k:v for k, v in names.items() if k not in
old_names and v is not namespace}
        namespace.update(**new_names)

    names.clear()
    names.update(old_names)

So you *can* do:

>>> for i in range(3):
...     with scope():
...         for i in range(3):
...             print("Inner:", i)
...     print("Outer", i)
Inner: 0
Inner: 1
Inner: 2
Outer 0
Inner: 0
Inner: 1
Inner: 2
Outer 1
Inner: 0
Inner: 1
Inner: 2
Outer 2

:)

If you pass scope() a dictionary, all the new variables will get added to it.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web