Any way to modify locals dictionary?












12















locals is a built in function that returns a dictionary of local values. The documentation says:




Warning



The contents of this dictionary should
not be modified; changes may not
affect the values of local variables
used by the interpreter.




Unfortunately, exec has the same problem in Python 3.0. Is there any way round this?



Use Case



Consider:



@depends("a", "b", "c", "d", "e", "f")
def test():
put_into_locals(test.dependencies)


depends stores the strings provided in its arguments in a list test.dependences. These strings are keys in a dictionary d. I would like to be able to able to write put_into_locals so that we could pull the values out of d and put them into the locals. Is this possible?










share|improve this question

























  • Link to the relevant documentation: docs.python.org/2/library/functions.html#locals

    – Ceasar Bautista
    Dec 5 '14 at 19:53











  • why does test. dependencies = ["a", "b", "c", "d", "e", "f"] work and then decorate the assignment I wrote above to your test() function?

    – Charlie Parker
    Jun 22 '17 at 22:34











  • did you manage to update/modify locals or no?

    – Charlie Parker
    Oct 16 '17 at 22:20











  • is there a way to make it work for python 3 or more?

    – Charlie Parker
    Oct 16 '17 at 22:23
















12















locals is a built in function that returns a dictionary of local values. The documentation says:




Warning



The contents of this dictionary should
not be modified; changes may not
affect the values of local variables
used by the interpreter.




Unfortunately, exec has the same problem in Python 3.0. Is there any way round this?



Use Case



Consider:



@depends("a", "b", "c", "d", "e", "f")
def test():
put_into_locals(test.dependencies)


depends stores the strings provided in its arguments in a list test.dependences. These strings are keys in a dictionary d. I would like to be able to able to write put_into_locals so that we could pull the values out of d and put them into the locals. Is this possible?










share|improve this question

























  • Link to the relevant documentation: docs.python.org/2/library/functions.html#locals

    – Ceasar Bautista
    Dec 5 '14 at 19:53











  • why does test. dependencies = ["a", "b", "c", "d", "e", "f"] work and then decorate the assignment I wrote above to your test() function?

    – Charlie Parker
    Jun 22 '17 at 22:34











  • did you manage to update/modify locals or no?

    – Charlie Parker
    Oct 16 '17 at 22:20











  • is there a way to make it work for python 3 or more?

    – Charlie Parker
    Oct 16 '17 at 22:23














12












12








12


0






locals is a built in function that returns a dictionary of local values. The documentation says:




Warning



The contents of this dictionary should
not be modified; changes may not
affect the values of local variables
used by the interpreter.




Unfortunately, exec has the same problem in Python 3.0. Is there any way round this?



Use Case



Consider:



@depends("a", "b", "c", "d", "e", "f")
def test():
put_into_locals(test.dependencies)


depends stores the strings provided in its arguments in a list test.dependences. These strings are keys in a dictionary d. I would like to be able to able to write put_into_locals so that we could pull the values out of d and put them into the locals. Is this possible?










share|improve this question
















locals is a built in function that returns a dictionary of local values. The documentation says:




Warning



The contents of this dictionary should
not be modified; changes may not
affect the values of local variables
used by the interpreter.




Unfortunately, exec has the same problem in Python 3.0. Is there any way round this?



Use Case



Consider:



@depends("a", "b", "c", "d", "e", "f")
def test():
put_into_locals(test.dependencies)


depends stores the strings provided in its arguments in a list test.dependences. These strings are keys in a dictionary d. I would like to be able to able to write put_into_locals so that we could pull the values out of d and put them into the locals. Is this possible?







python local-variables






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 2 at 1:08









martineau

68.5k1090183




68.5k1090183










asked Sep 20 '09 at 4:03









CasebashCasebash

49k72209318




49k72209318













  • Link to the relevant documentation: docs.python.org/2/library/functions.html#locals

    – Ceasar Bautista
    Dec 5 '14 at 19:53











  • why does test. dependencies = ["a", "b", "c", "d", "e", "f"] work and then decorate the assignment I wrote above to your test() function?

    – Charlie Parker
    Jun 22 '17 at 22:34











  • did you manage to update/modify locals or no?

    – Charlie Parker
    Oct 16 '17 at 22:20











  • is there a way to make it work for python 3 or more?

    – Charlie Parker
    Oct 16 '17 at 22:23



















  • Link to the relevant documentation: docs.python.org/2/library/functions.html#locals

    – Ceasar Bautista
    Dec 5 '14 at 19:53











  • why does test. dependencies = ["a", "b", "c", "d", "e", "f"] work and then decorate the assignment I wrote above to your test() function?

    – Charlie Parker
    Jun 22 '17 at 22:34











  • did you manage to update/modify locals or no?

    – Charlie Parker
    Oct 16 '17 at 22:20











  • is there a way to make it work for python 3 or more?

    – Charlie Parker
    Oct 16 '17 at 22:23

















Link to the relevant documentation: docs.python.org/2/library/functions.html#locals

– Ceasar Bautista
Dec 5 '14 at 19:53





Link to the relevant documentation: docs.python.org/2/library/functions.html#locals

– Ceasar Bautista
Dec 5 '14 at 19:53













why does test. dependencies = ["a", "b", "c", "d", "e", "f"] work and then decorate the assignment I wrote above to your test() function?

– Charlie Parker
Jun 22 '17 at 22:34





why does test. dependencies = ["a", "b", "c", "d", "e", "f"] work and then decorate the assignment I wrote above to your test() function?

– Charlie Parker
Jun 22 '17 at 22:34













did you manage to update/modify locals or no?

– Charlie Parker
Oct 16 '17 at 22:20





did you manage to update/modify locals or no?

– Charlie Parker
Oct 16 '17 at 22:20













is there a way to make it work for python 3 or more?

– Charlie Parker
Oct 16 '17 at 22:23





is there a way to make it work for python 3 or more?

– Charlie Parker
Oct 16 '17 at 22:23












5 Answers
5






active

oldest

votes


















11














I just tested exec and it works in Python 2.6.2



>>> def test():
... exec "a = 5"
... print a
...
>>> test()
5


If you are using Python 3.x, it does not work anymore because locals are optimized as an array at runtime, instead of using a dictionary.



When Python detects the "exec statement", it will force Python to switch local storage from array to dictionary. However since "exec" is a function in Python 3.x, the compiler cannot make this distinction since the user could have done something like "exec = 123".



http://bugs.python.org/issue4831




To modify the locals of a function on
the fly is not possible without
several consequences: normally,
function locals are not stored in a
dictionary, but an array, whose
indices are determined at compile time
from the known locales. This collides
at least with new locals added by
exec. The old exec statement
circumvented this, because the
compiler knew that if an exec without
globals/locals args occurred in a
function, that namespace would be
"unoptimized", i.e. not using the
locals array. Since exec() is now a
normal function, the compiler does not
know what "exec" may be bound to, and
therefore can not treat is specially.







share|improve this answer
























  • I think it is pretty conclusive that it is just not possible

    – Casebash
    Sep 20 '09 at 5:35






  • 1





    @Casebash, it probably is possible, it just requires byte code hacks or Python 2.x

    – Unknown
    Sep 20 '09 at 5:49











  • Okay, I'll leave this question unresolved for now

    – Casebash
    Sep 20 '09 at 6:37











  • @Casebash: you might not want to hold your breath. Python byte codes are not very well documented.

    – Unknown
    Sep 20 '09 at 18:07











  • I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort

    – Casebash
    Sep 21 '09 at 0:55



















6














The local variables are modified by assignment statements.



If you have dictionary keys which are strings, please don't also make them local variables -- just use them as dictionary keys.



If you absolutely must have local variables do this.



def aFunction( a, b, c, d, e, f ):
# use a, b, c, d, e and f as local variables

aFunction( **someDictWithKeys_a_b_c_d_e_f )


That will populate some local variables from your dictionary without doing anything magical.






share|improve this answer



















  • 5





    This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by aFunction()), which makes the current definition of aFunction() break. A useful generalization is: aFunction(a, b, c, d, e, f, **kwargs).

    – Eric O Lebigot
    Jul 18 '10 at 10:40






  • 4





    @S. Lott: Let me rephrase my point: what breaks is having the signature def aFunction(a, b, c, d, e, f) when someDictWithKeys_a_b_c_d_e_f contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, def aFunction(a, b, c, d, e, f, **kwargs) is a convenient way of addressing this situation.

    – Eric O Lebigot
    Jul 18 '10 at 18:01






  • 3





    @S. Lott: just run the code of your answer (which I upvoted) with aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6}) and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.

    – Eric O Lebigot
    Jul 20 '10 at 8:24








  • 2





    @S. Lott: The whole purpose of this is to get more convenient access to dict or object members. The idea is that some formula like (a**2+b)*exp(c*d/e) is easier to read than (n.a**2+n.b)*exp(n.c*n.d/n.e) for some n (perhaps just wrapping the dict containing the relevant variables). As for "bad design", suppose you have some parameters that determine the shape of a collection of functions. For example, these could be material parameters describing the equation of state and other properties for a gas.

    – Jed
    May 30 '11 at 17:39






  • 3





    Each function uses a subset of the parameters and you don't want to write a bunch of boilerplate to extract only the part that is really needed. You don't want to modify the callers when the function needs more parameters and you don't want to modify the inner functions when a different part of the model requires a new parameter to be introduced.

    – Jed
    May 30 '11 at 17:39



















3














This isn't possible. I think this is to allow for performance optimizations later on. Python bytecode references locals by index, not by name; if locals() was required to be writable, it could prevent interpreters from implementing some optimizations, or make them more difficult.



I'm fairly certain you're not going to find any core API that guarantees you can edit locals like this, because if that API could do it, locals() wouldn't have this restriction either.



Don't forget that all locals must exist at compile-time; if you reference a name that isn't bound to a local at compile-time, the compiler assumes it's a global. You can't "create" locals after compilation.



See this question for one possible solution, but it's a serious hack and you really don't want to do that.



Note that there's a basic problem with your example code:



@depends("a", "b", "c", "d", "e", "f")
def test():
put_into_locals(test.dependencies)


"test.dependencies" isn't referring to "f.dependencies" where f is the current function; it's referencing the actual global value "test". That means if you use more than one decorator:



@memoize
@depends("a", "b", "c", "d", "e", "f")
def test():
put_into_locals(test.dependencies)


it'll no longer work, since "test" is memoize's wrapped function, not depends's. Python really needs a way to refer to "the currently-executing function" (and class).






share|improve this answer

































    1














    I would store it in a variable:



    refs    = locals()
    def set_pets():
    global refs
    animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
    for i in range(len(animals)):
    refs['pet_0%s' % i] = animals[i]

    set_pets()
    refs['pet_05']='bird'
    print(pet_00, pet_02, pet_04, pet_01, pet_03, pet_05 )
    >> dog fish monkey cat fox bird


    And if you want to test your dict before putting it in locals():



    def set_pets():
    global refs
    sandbox = {}
    animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
    for i in range(len(animals)):
    sandbox['pet_0%s' % i] = animals[i]
    # Test sandboxed dict here
    refs.update( sandbox )


    Python 3.6.1 on MacOS Sierra






    share|improve this answer































      0














      I'm not sure if it is subject to the same restrictions, but you can get a direct reference to the current frame (and from there, the local variables dictionary) through the inspect module:



      >>> import inspect
      >>> inspect.currentframe().f_locals['foo'] = 'bar'
      >>> dir()
      ['__builtins__', '__doc__', '__name__', '__package__', 'foo', 'inspect']
      >>> foo
      'bar'





      share|improve this answer



















      • 7





        This is exactly the same as locals(); inspect.currentframe().f_locals is locals() is true.

        – Glenn Maynard
        Sep 20 '09 at 4:21






      • 1





        This is not totally wrong, but it only works when the frame is the topmost one i.e. the global scope. It wont work within local scopes.

        – bendtherules
        Jun 12 '15 at 1:50











      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1450275%2fany-way-to-modify-locals-dictionary%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      5 Answers
      5






      active

      oldest

      votes








      5 Answers
      5






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      11














      I just tested exec and it works in Python 2.6.2



      >>> def test():
      ... exec "a = 5"
      ... print a
      ...
      >>> test()
      5


      If you are using Python 3.x, it does not work anymore because locals are optimized as an array at runtime, instead of using a dictionary.



      When Python detects the "exec statement", it will force Python to switch local storage from array to dictionary. However since "exec" is a function in Python 3.x, the compiler cannot make this distinction since the user could have done something like "exec = 123".



      http://bugs.python.org/issue4831




      To modify the locals of a function on
      the fly is not possible without
      several consequences: normally,
      function locals are not stored in a
      dictionary, but an array, whose
      indices are determined at compile time
      from the known locales. This collides
      at least with new locals added by
      exec. The old exec statement
      circumvented this, because the
      compiler knew that if an exec without
      globals/locals args occurred in a
      function, that namespace would be
      "unoptimized", i.e. not using the
      locals array. Since exec() is now a
      normal function, the compiler does not
      know what "exec" may be bound to, and
      therefore can not treat is specially.







      share|improve this answer
























      • I think it is pretty conclusive that it is just not possible

        – Casebash
        Sep 20 '09 at 5:35






      • 1





        @Casebash, it probably is possible, it just requires byte code hacks or Python 2.x

        – Unknown
        Sep 20 '09 at 5:49











      • Okay, I'll leave this question unresolved for now

        – Casebash
        Sep 20 '09 at 6:37











      • @Casebash: you might not want to hold your breath. Python byte codes are not very well documented.

        – Unknown
        Sep 20 '09 at 18:07











      • I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort

        – Casebash
        Sep 21 '09 at 0:55
















      11














      I just tested exec and it works in Python 2.6.2



      >>> def test():
      ... exec "a = 5"
      ... print a
      ...
      >>> test()
      5


      If you are using Python 3.x, it does not work anymore because locals are optimized as an array at runtime, instead of using a dictionary.



      When Python detects the "exec statement", it will force Python to switch local storage from array to dictionary. However since "exec" is a function in Python 3.x, the compiler cannot make this distinction since the user could have done something like "exec = 123".



      http://bugs.python.org/issue4831




      To modify the locals of a function on
      the fly is not possible without
      several consequences: normally,
      function locals are not stored in a
      dictionary, but an array, whose
      indices are determined at compile time
      from the known locales. This collides
      at least with new locals added by
      exec. The old exec statement
      circumvented this, because the
      compiler knew that if an exec without
      globals/locals args occurred in a
      function, that namespace would be
      "unoptimized", i.e. not using the
      locals array. Since exec() is now a
      normal function, the compiler does not
      know what "exec" may be bound to, and
      therefore can not treat is specially.







      share|improve this answer
























      • I think it is pretty conclusive that it is just not possible

        – Casebash
        Sep 20 '09 at 5:35






      • 1





        @Casebash, it probably is possible, it just requires byte code hacks or Python 2.x

        – Unknown
        Sep 20 '09 at 5:49











      • Okay, I'll leave this question unresolved for now

        – Casebash
        Sep 20 '09 at 6:37











      • @Casebash: you might not want to hold your breath. Python byte codes are not very well documented.

        – Unknown
        Sep 20 '09 at 18:07











      • I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort

        – Casebash
        Sep 21 '09 at 0:55














      11












      11








      11







      I just tested exec and it works in Python 2.6.2



      >>> def test():
      ... exec "a = 5"
      ... print a
      ...
      >>> test()
      5


      If you are using Python 3.x, it does not work anymore because locals are optimized as an array at runtime, instead of using a dictionary.



      When Python detects the "exec statement", it will force Python to switch local storage from array to dictionary. However since "exec" is a function in Python 3.x, the compiler cannot make this distinction since the user could have done something like "exec = 123".



      http://bugs.python.org/issue4831




      To modify the locals of a function on
      the fly is not possible without
      several consequences: normally,
      function locals are not stored in a
      dictionary, but an array, whose
      indices are determined at compile time
      from the known locales. This collides
      at least with new locals added by
      exec. The old exec statement
      circumvented this, because the
      compiler knew that if an exec without
      globals/locals args occurred in a
      function, that namespace would be
      "unoptimized", i.e. not using the
      locals array. Since exec() is now a
      normal function, the compiler does not
      know what "exec" may be bound to, and
      therefore can not treat is specially.







      share|improve this answer













      I just tested exec and it works in Python 2.6.2



      >>> def test():
      ... exec "a = 5"
      ... print a
      ...
      >>> test()
      5


      If you are using Python 3.x, it does not work anymore because locals are optimized as an array at runtime, instead of using a dictionary.



      When Python detects the "exec statement", it will force Python to switch local storage from array to dictionary. However since "exec" is a function in Python 3.x, the compiler cannot make this distinction since the user could have done something like "exec = 123".



      http://bugs.python.org/issue4831




      To modify the locals of a function on
      the fly is not possible without
      several consequences: normally,
      function locals are not stored in a
      dictionary, but an array, whose
      indices are determined at compile time
      from the known locales. This collides
      at least with new locals added by
      exec. The old exec statement
      circumvented this, because the
      compiler knew that if an exec without
      globals/locals args occurred in a
      function, that namespace would be
      "unoptimized", i.e. not using the
      locals array. Since exec() is now a
      normal function, the compiler does not
      know what "exec" may be bound to, and
      therefore can not treat is specially.








      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Sep 20 '09 at 5:09









      UnknownUnknown

      34.7k22120169




      34.7k22120169













      • I think it is pretty conclusive that it is just not possible

        – Casebash
        Sep 20 '09 at 5:35






      • 1





        @Casebash, it probably is possible, it just requires byte code hacks or Python 2.x

        – Unknown
        Sep 20 '09 at 5:49











      • Okay, I'll leave this question unresolved for now

        – Casebash
        Sep 20 '09 at 6:37











      • @Casebash: you might not want to hold your breath. Python byte codes are not very well documented.

        – Unknown
        Sep 20 '09 at 18:07











      • I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort

        – Casebash
        Sep 21 '09 at 0:55



















      • I think it is pretty conclusive that it is just not possible

        – Casebash
        Sep 20 '09 at 5:35






      • 1





        @Casebash, it probably is possible, it just requires byte code hacks or Python 2.x

        – Unknown
        Sep 20 '09 at 5:49











      • Okay, I'll leave this question unresolved for now

        – Casebash
        Sep 20 '09 at 6:37











      • @Casebash: you might not want to hold your breath. Python byte codes are not very well documented.

        – Unknown
        Sep 20 '09 at 18:07











      • I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort

        – Casebash
        Sep 21 '09 at 0:55

















      I think it is pretty conclusive that it is just not possible

      – Casebash
      Sep 20 '09 at 5:35





      I think it is pretty conclusive that it is just not possible

      – Casebash
      Sep 20 '09 at 5:35




      1




      1





      @Casebash, it probably is possible, it just requires byte code hacks or Python 2.x

      – Unknown
      Sep 20 '09 at 5:49





      @Casebash, it probably is possible, it just requires byte code hacks or Python 2.x

      – Unknown
      Sep 20 '09 at 5:49













      Okay, I'll leave this question unresolved for now

      – Casebash
      Sep 20 '09 at 6:37





      Okay, I'll leave this question unresolved for now

      – Casebash
      Sep 20 '09 at 6:37













      @Casebash: you might not want to hold your breath. Python byte codes are not very well documented.

      – Unknown
      Sep 20 '09 at 18:07





      @Casebash: you might not want to hold your breath. Python byte codes are not very well documented.

      – Unknown
      Sep 20 '09 at 18:07













      I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort

      – Casebash
      Sep 21 '09 at 0:55





      I'll probably look at it myself some day. ATM, I really am not going to get enough utility out of it to justify the effort

      – Casebash
      Sep 21 '09 at 0:55













      6














      The local variables are modified by assignment statements.



      If you have dictionary keys which are strings, please don't also make them local variables -- just use them as dictionary keys.



      If you absolutely must have local variables do this.



      def aFunction( a, b, c, d, e, f ):
      # use a, b, c, d, e and f as local variables

      aFunction( **someDictWithKeys_a_b_c_d_e_f )


      That will populate some local variables from your dictionary without doing anything magical.






      share|improve this answer



















      • 5





        This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by aFunction()), which makes the current definition of aFunction() break. A useful generalization is: aFunction(a, b, c, d, e, f, **kwargs).

        – Eric O Lebigot
        Jul 18 '10 at 10:40






      • 4





        @S. Lott: Let me rephrase my point: what breaks is having the signature def aFunction(a, b, c, d, e, f) when someDictWithKeys_a_b_c_d_e_f contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, def aFunction(a, b, c, d, e, f, **kwargs) is a convenient way of addressing this situation.

        – Eric O Lebigot
        Jul 18 '10 at 18:01






      • 3





        @S. Lott: just run the code of your answer (which I upvoted) with aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6}) and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.

        – Eric O Lebigot
        Jul 20 '10 at 8:24








      • 2





        @S. Lott: The whole purpose of this is to get more convenient access to dict or object members. The idea is that some formula like (a**2+b)*exp(c*d/e) is easier to read than (n.a**2+n.b)*exp(n.c*n.d/n.e) for some n (perhaps just wrapping the dict containing the relevant variables). As for "bad design", suppose you have some parameters that determine the shape of a collection of functions. For example, these could be material parameters describing the equation of state and other properties for a gas.

        – Jed
        May 30 '11 at 17:39






      • 3





        Each function uses a subset of the parameters and you don't want to write a bunch of boilerplate to extract only the part that is really needed. You don't want to modify the callers when the function needs more parameters and you don't want to modify the inner functions when a different part of the model requires a new parameter to be introduced.

        – Jed
        May 30 '11 at 17:39
















      6














      The local variables are modified by assignment statements.



      If you have dictionary keys which are strings, please don't also make them local variables -- just use them as dictionary keys.



      If you absolutely must have local variables do this.



      def aFunction( a, b, c, d, e, f ):
      # use a, b, c, d, e and f as local variables

      aFunction( **someDictWithKeys_a_b_c_d_e_f )


      That will populate some local variables from your dictionary without doing anything magical.






      share|improve this answer



















      • 5





        This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by aFunction()), which makes the current definition of aFunction() break. A useful generalization is: aFunction(a, b, c, d, e, f, **kwargs).

        – Eric O Lebigot
        Jul 18 '10 at 10:40






      • 4





        @S. Lott: Let me rephrase my point: what breaks is having the signature def aFunction(a, b, c, d, e, f) when someDictWithKeys_a_b_c_d_e_f contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, def aFunction(a, b, c, d, e, f, **kwargs) is a convenient way of addressing this situation.

        – Eric O Lebigot
        Jul 18 '10 at 18:01






      • 3





        @S. Lott: just run the code of your answer (which I upvoted) with aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6}) and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.

        – Eric O Lebigot
        Jul 20 '10 at 8:24








      • 2





        @S. Lott: The whole purpose of this is to get more convenient access to dict or object members. The idea is that some formula like (a**2+b)*exp(c*d/e) is easier to read than (n.a**2+n.b)*exp(n.c*n.d/n.e) for some n (perhaps just wrapping the dict containing the relevant variables). As for "bad design", suppose you have some parameters that determine the shape of a collection of functions. For example, these could be material parameters describing the equation of state and other properties for a gas.

        – Jed
        May 30 '11 at 17:39






      • 3





        Each function uses a subset of the parameters and you don't want to write a bunch of boilerplate to extract only the part that is really needed. You don't want to modify the callers when the function needs more parameters and you don't want to modify the inner functions when a different part of the model requires a new parameter to be introduced.

        – Jed
        May 30 '11 at 17:39














      6












      6








      6







      The local variables are modified by assignment statements.



      If you have dictionary keys which are strings, please don't also make them local variables -- just use them as dictionary keys.



      If you absolutely must have local variables do this.



      def aFunction( a, b, c, d, e, f ):
      # use a, b, c, d, e and f as local variables

      aFunction( **someDictWithKeys_a_b_c_d_e_f )


      That will populate some local variables from your dictionary without doing anything magical.






      share|improve this answer













      The local variables are modified by assignment statements.



      If you have dictionary keys which are strings, please don't also make them local variables -- just use them as dictionary keys.



      If you absolutely must have local variables do this.



      def aFunction( a, b, c, d, e, f ):
      # use a, b, c, d, e and f as local variables

      aFunction( **someDictWithKeys_a_b_c_d_e_f )


      That will populate some local variables from your dictionary without doing anything magical.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Sep 20 '09 at 11:50









      S.LottS.Lott

      319k67441717




      319k67441717








      • 5





        This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by aFunction()), which makes the current definition of aFunction() break. A useful generalization is: aFunction(a, b, c, d, e, f, **kwargs).

        – Eric O Lebigot
        Jul 18 '10 at 10:40






      • 4





        @S. Lott: Let me rephrase my point: what breaks is having the signature def aFunction(a, b, c, d, e, f) when someDictWithKeys_a_b_c_d_e_f contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, def aFunction(a, b, c, d, e, f, **kwargs) is a convenient way of addressing this situation.

        – Eric O Lebigot
        Jul 18 '10 at 18:01






      • 3





        @S. Lott: just run the code of your answer (which I upvoted) with aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6}) and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.

        – Eric O Lebigot
        Jul 20 '10 at 8:24








      • 2





        @S. Lott: The whole purpose of this is to get more convenient access to dict or object members. The idea is that some formula like (a**2+b)*exp(c*d/e) is easier to read than (n.a**2+n.b)*exp(n.c*n.d/n.e) for some n (perhaps just wrapping the dict containing the relevant variables). As for "bad design", suppose you have some parameters that determine the shape of a collection of functions. For example, these could be material parameters describing the equation of state and other properties for a gas.

        – Jed
        May 30 '11 at 17:39






      • 3





        Each function uses a subset of the parameters and you don't want to write a bunch of boilerplate to extract only the part that is really needed. You don't want to modify the callers when the function needs more parameters and you don't want to modify the inner functions when a different part of the model requires a new parameter to be introduced.

        – Jed
        May 30 '11 at 17:39














      • 5





        This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by aFunction()), which makes the current definition of aFunction() break. A useful generalization is: aFunction(a, b, c, d, e, f, **kwargs).

        – Eric O Lebigot
        Jul 18 '10 at 10:40






      • 4





        @S. Lott: Let me rephrase my point: what breaks is having the signature def aFunction(a, b, c, d, e, f) when someDictWithKeys_a_b_c_d_e_f contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, def aFunction(a, b, c, d, e, f, **kwargs) is a convenient way of addressing this situation.

        – Eric O Lebigot
        Jul 18 '10 at 18:01






      • 3





        @S. Lott: just run the code of your answer (which I upvoted) with aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6}) and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.

        – Eric O Lebigot
        Jul 20 '10 at 8:24








      • 2





        @S. Lott: The whole purpose of this is to get more convenient access to dict or object members. The idea is that some formula like (a**2+b)*exp(c*d/e) is easier to read than (n.a**2+n.b)*exp(n.c*n.d/n.e) for some n (perhaps just wrapping the dict containing the relevant variables). As for "bad design", suppose you have some parameters that determine the shape of a collection of functions. For example, these could be material parameters describing the equation of state and other properties for a gas.

        – Jed
        May 30 '11 at 17:39






      • 3





        Each function uses a subset of the parameters and you don't want to write a bunch of boilerplate to extract only the part that is really needed. You don't want to modify the callers when the function needs more parameters and you don't want to modify the inner functions when a different part of the model requires a new parameter to be introduced.

        – Jed
        May 30 '11 at 17:39








      5




      5





      This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by aFunction()), which makes the current definition of aFunction() break. A useful generalization is: aFunction(a, b, c, d, e, f, **kwargs).

      – Eric O Lebigot
      Jul 18 '10 at 10:40





      This is an interesting idea. However, there are many applications in which the dictionary actually contains many other variables (that are not needed by aFunction()), which makes the current definition of aFunction() break. A useful generalization is: aFunction(a, b, c, d, e, f, **kwargs).

      – Eric O Lebigot
      Jul 18 '10 at 10:40




      4




      4





      @S. Lott: Let me rephrase my point: what breaks is having the signature def aFunction(a, b, c, d, e, f) when someDictWithKeys_a_b_c_d_e_f contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, def aFunction(a, b, c, d, e, f, **kwargs) is a convenient way of addressing this situation.

      – Eric O Lebigot
      Jul 18 '10 at 18:01





      @S. Lott: Let me rephrase my point: what breaks is having the signature def aFunction(a, b, c, d, e, f) when someDictWithKeys_a_b_c_d_e_f contains more keys than these few variables, which is a typical situation when performing complex scientific calculations (the whole calculation uses more variables than most of the functions it calls). As I pointed out, def aFunction(a, b, c, d, e, f, **kwargs) is a convenient way of addressing this situation.

      – Eric O Lebigot
      Jul 18 '10 at 18:01




      3




      3





      @S. Lott: just run the code of your answer (which I upvoted) with aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6}) and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.

      – Eric O Lebigot
      Jul 20 '10 at 8:24







      @S. Lott: just run the code of your answer (which I upvoted) with aFunction(**{'a': 0, 'b': 1, 'c': 2, 'd': 3, 'e': 4, 'f': 5, 'g': 6}) and this will precisely show why my remark can be useful to StackOverflow readers. In real-life scientific calculations, dictionaries typically hold more variables than what is sent individually to each function called.

      – Eric O Lebigot
      Jul 20 '10 at 8:24






      2




      2





      @S. Lott: The whole purpose of this is to get more convenient access to dict or object members. The idea is that some formula like (a**2+b)*exp(c*d/e) is easier to read than (n.a**2+n.b)*exp(n.c*n.d/n.e) for some n (perhaps just wrapping the dict containing the relevant variables). As for "bad design", suppose you have some parameters that determine the shape of a collection of functions. For example, these could be material parameters describing the equation of state and other properties for a gas.

      – Jed
      May 30 '11 at 17:39





      @S. Lott: The whole purpose of this is to get more convenient access to dict or object members. The idea is that some formula like (a**2+b)*exp(c*d/e) is easier to read than (n.a**2+n.b)*exp(n.c*n.d/n.e) for some n (perhaps just wrapping the dict containing the relevant variables). As for "bad design", suppose you have some parameters that determine the shape of a collection of functions. For example, these could be material parameters describing the equation of state and other properties for a gas.

      – Jed
      May 30 '11 at 17:39




      3




      3





      Each function uses a subset of the parameters and you don't want to write a bunch of boilerplate to extract only the part that is really needed. You don't want to modify the callers when the function needs more parameters and you don't want to modify the inner functions when a different part of the model requires a new parameter to be introduced.

      – Jed
      May 30 '11 at 17:39





      Each function uses a subset of the parameters and you don't want to write a bunch of boilerplate to extract only the part that is really needed. You don't want to modify the callers when the function needs more parameters and you don't want to modify the inner functions when a different part of the model requires a new parameter to be introduced.

      – Jed
      May 30 '11 at 17:39











      3














      This isn't possible. I think this is to allow for performance optimizations later on. Python bytecode references locals by index, not by name; if locals() was required to be writable, it could prevent interpreters from implementing some optimizations, or make them more difficult.



      I'm fairly certain you're not going to find any core API that guarantees you can edit locals like this, because if that API could do it, locals() wouldn't have this restriction either.



      Don't forget that all locals must exist at compile-time; if you reference a name that isn't bound to a local at compile-time, the compiler assumes it's a global. You can't "create" locals after compilation.



      See this question for one possible solution, but it's a serious hack and you really don't want to do that.



      Note that there's a basic problem with your example code:



      @depends("a", "b", "c", "d", "e", "f")
      def test():
      put_into_locals(test.dependencies)


      "test.dependencies" isn't referring to "f.dependencies" where f is the current function; it's referencing the actual global value "test". That means if you use more than one decorator:



      @memoize
      @depends("a", "b", "c", "d", "e", "f")
      def test():
      put_into_locals(test.dependencies)


      it'll no longer work, since "test" is memoize's wrapped function, not depends's. Python really needs a way to refer to "the currently-executing function" (and class).






      share|improve this answer






























        3














        This isn't possible. I think this is to allow for performance optimizations later on. Python bytecode references locals by index, not by name; if locals() was required to be writable, it could prevent interpreters from implementing some optimizations, or make them more difficult.



        I'm fairly certain you're not going to find any core API that guarantees you can edit locals like this, because if that API could do it, locals() wouldn't have this restriction either.



        Don't forget that all locals must exist at compile-time; if you reference a name that isn't bound to a local at compile-time, the compiler assumes it's a global. You can't "create" locals after compilation.



        See this question for one possible solution, but it's a serious hack and you really don't want to do that.



        Note that there's a basic problem with your example code:



        @depends("a", "b", "c", "d", "e", "f")
        def test():
        put_into_locals(test.dependencies)


        "test.dependencies" isn't referring to "f.dependencies" where f is the current function; it's referencing the actual global value "test". That means if you use more than one decorator:



        @memoize
        @depends("a", "b", "c", "d", "e", "f")
        def test():
        put_into_locals(test.dependencies)


        it'll no longer work, since "test" is memoize's wrapped function, not depends's. Python really needs a way to refer to "the currently-executing function" (and class).






        share|improve this answer




























          3












          3








          3







          This isn't possible. I think this is to allow for performance optimizations later on. Python bytecode references locals by index, not by name; if locals() was required to be writable, it could prevent interpreters from implementing some optimizations, or make them more difficult.



          I'm fairly certain you're not going to find any core API that guarantees you can edit locals like this, because if that API could do it, locals() wouldn't have this restriction either.



          Don't forget that all locals must exist at compile-time; if you reference a name that isn't bound to a local at compile-time, the compiler assumes it's a global. You can't "create" locals after compilation.



          See this question for one possible solution, but it's a serious hack and you really don't want to do that.



          Note that there's a basic problem with your example code:



          @depends("a", "b", "c", "d", "e", "f")
          def test():
          put_into_locals(test.dependencies)


          "test.dependencies" isn't referring to "f.dependencies" where f is the current function; it's referencing the actual global value "test". That means if you use more than one decorator:



          @memoize
          @depends("a", "b", "c", "d", "e", "f")
          def test():
          put_into_locals(test.dependencies)


          it'll no longer work, since "test" is memoize's wrapped function, not depends's. Python really needs a way to refer to "the currently-executing function" (and class).






          share|improve this answer















          This isn't possible. I think this is to allow for performance optimizations later on. Python bytecode references locals by index, not by name; if locals() was required to be writable, it could prevent interpreters from implementing some optimizations, or make them more difficult.



          I'm fairly certain you're not going to find any core API that guarantees you can edit locals like this, because if that API could do it, locals() wouldn't have this restriction either.



          Don't forget that all locals must exist at compile-time; if you reference a name that isn't bound to a local at compile-time, the compiler assumes it's a global. You can't "create" locals after compilation.



          See this question for one possible solution, but it's a serious hack and you really don't want to do that.



          Note that there's a basic problem with your example code:



          @depends("a", "b", "c", "d", "e", "f")
          def test():
          put_into_locals(test.dependencies)


          "test.dependencies" isn't referring to "f.dependencies" where f is the current function; it's referencing the actual global value "test". That means if you use more than one decorator:



          @memoize
          @depends("a", "b", "c", "d", "e", "f")
          def test():
          put_into_locals(test.dependencies)


          it'll no longer work, since "test" is memoize's wrapped function, not depends's. Python really needs a way to refer to "the currently-executing function" (and class).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited May 23 '17 at 12:22









          Community

          11




          11










          answered Sep 20 '09 at 4:37









          Glenn MaynardGlenn Maynard

          43.4k693122




          43.4k693122























              1














              I would store it in a variable:



              refs    = locals()
              def set_pets():
              global refs
              animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
              for i in range(len(animals)):
              refs['pet_0%s' % i] = animals[i]

              set_pets()
              refs['pet_05']='bird'
              print(pet_00, pet_02, pet_04, pet_01, pet_03, pet_05 )
              >> dog fish monkey cat fox bird


              And if you want to test your dict before putting it in locals():



              def set_pets():
              global refs
              sandbox = {}
              animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
              for i in range(len(animals)):
              sandbox['pet_0%s' % i] = animals[i]
              # Test sandboxed dict here
              refs.update( sandbox )


              Python 3.6.1 on MacOS Sierra






              share|improve this answer




























                1














                I would store it in a variable:



                refs    = locals()
                def set_pets():
                global refs
                animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
                for i in range(len(animals)):
                refs['pet_0%s' % i] = animals[i]

                set_pets()
                refs['pet_05']='bird'
                print(pet_00, pet_02, pet_04, pet_01, pet_03, pet_05 )
                >> dog fish monkey cat fox bird


                And if you want to test your dict before putting it in locals():



                def set_pets():
                global refs
                sandbox = {}
                animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
                for i in range(len(animals)):
                sandbox['pet_0%s' % i] = animals[i]
                # Test sandboxed dict here
                refs.update( sandbox )


                Python 3.6.1 on MacOS Sierra






                share|improve this answer


























                  1












                  1








                  1







                  I would store it in a variable:



                  refs    = locals()
                  def set_pets():
                  global refs
                  animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
                  for i in range(len(animals)):
                  refs['pet_0%s' % i] = animals[i]

                  set_pets()
                  refs['pet_05']='bird'
                  print(pet_00, pet_02, pet_04, pet_01, pet_03, pet_05 )
                  >> dog fish monkey cat fox bird


                  And if you want to test your dict before putting it in locals():



                  def set_pets():
                  global refs
                  sandbox = {}
                  animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
                  for i in range(len(animals)):
                  sandbox['pet_0%s' % i] = animals[i]
                  # Test sandboxed dict here
                  refs.update( sandbox )


                  Python 3.6.1 on MacOS Sierra






                  share|improve this answer













                  I would store it in a variable:



                  refs    = locals()
                  def set_pets():
                  global refs
                  animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
                  for i in range(len(animals)):
                  refs['pet_0%s' % i] = animals[i]

                  set_pets()
                  refs['pet_05']='bird'
                  print(pet_00, pet_02, pet_04, pet_01, pet_03, pet_05 )
                  >> dog fish monkey cat fox bird


                  And if you want to test your dict before putting it in locals():



                  def set_pets():
                  global refs
                  sandbox = {}
                  animals = ('dog', 'cat', 'fish', 'fox', 'monkey')
                  for i in range(len(animals)):
                  sandbox['pet_0%s' % i] = animals[i]
                  # Test sandboxed dict here
                  refs.update( sandbox )


                  Python 3.6.1 on MacOS Sierra







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jul 18 '17 at 20:52









                  David PennellDavid Pennell

                  111




                  111























                      0














                      I'm not sure if it is subject to the same restrictions, but you can get a direct reference to the current frame (and from there, the local variables dictionary) through the inspect module:



                      >>> import inspect
                      >>> inspect.currentframe().f_locals['foo'] = 'bar'
                      >>> dir()
                      ['__builtins__', '__doc__', '__name__', '__package__', 'foo', 'inspect']
                      >>> foo
                      'bar'





                      share|improve this answer



















                      • 7





                        This is exactly the same as locals(); inspect.currentframe().f_locals is locals() is true.

                        – Glenn Maynard
                        Sep 20 '09 at 4:21






                      • 1





                        This is not totally wrong, but it only works when the frame is the topmost one i.e. the global scope. It wont work within local scopes.

                        – bendtherules
                        Jun 12 '15 at 1:50
















                      0














                      I'm not sure if it is subject to the same restrictions, but you can get a direct reference to the current frame (and from there, the local variables dictionary) through the inspect module:



                      >>> import inspect
                      >>> inspect.currentframe().f_locals['foo'] = 'bar'
                      >>> dir()
                      ['__builtins__', '__doc__', '__name__', '__package__', 'foo', 'inspect']
                      >>> foo
                      'bar'





                      share|improve this answer



















                      • 7





                        This is exactly the same as locals(); inspect.currentframe().f_locals is locals() is true.

                        – Glenn Maynard
                        Sep 20 '09 at 4:21






                      • 1





                        This is not totally wrong, but it only works when the frame is the topmost one i.e. the global scope. It wont work within local scopes.

                        – bendtherules
                        Jun 12 '15 at 1:50














                      0












                      0








                      0







                      I'm not sure if it is subject to the same restrictions, but you can get a direct reference to the current frame (and from there, the local variables dictionary) through the inspect module:



                      >>> import inspect
                      >>> inspect.currentframe().f_locals['foo'] = 'bar'
                      >>> dir()
                      ['__builtins__', '__doc__', '__name__', '__package__', 'foo', 'inspect']
                      >>> foo
                      'bar'





                      share|improve this answer













                      I'm not sure if it is subject to the same restrictions, but you can get a direct reference to the current frame (and from there, the local variables dictionary) through the inspect module:



                      >>> import inspect
                      >>> inspect.currentframe().f_locals['foo'] = 'bar'
                      >>> dir()
                      ['__builtins__', '__doc__', '__name__', '__package__', 'foo', 'inspect']
                      >>> foo
                      'bar'






                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Sep 20 '09 at 4:13









                      dcrostadcrosta

                      19.2k65877




                      19.2k65877








                      • 7





                        This is exactly the same as locals(); inspect.currentframe().f_locals is locals() is true.

                        – Glenn Maynard
                        Sep 20 '09 at 4:21






                      • 1





                        This is not totally wrong, but it only works when the frame is the topmost one i.e. the global scope. It wont work within local scopes.

                        – bendtherules
                        Jun 12 '15 at 1:50














                      • 7





                        This is exactly the same as locals(); inspect.currentframe().f_locals is locals() is true.

                        – Glenn Maynard
                        Sep 20 '09 at 4:21






                      • 1





                        This is not totally wrong, but it only works when the frame is the topmost one i.e. the global scope. It wont work within local scopes.

                        – bendtherules
                        Jun 12 '15 at 1:50








                      7




                      7





                      This is exactly the same as locals(); inspect.currentframe().f_locals is locals() is true.

                      – Glenn Maynard
                      Sep 20 '09 at 4:21





                      This is exactly the same as locals(); inspect.currentframe().f_locals is locals() is true.

                      – Glenn Maynard
                      Sep 20 '09 at 4:21




                      1




                      1





                      This is not totally wrong, but it only works when the frame is the topmost one i.e. the global scope. It wont work within local scopes.

                      – bendtherules
                      Jun 12 '15 at 1:50





                      This is not totally wrong, but it only works when the frame is the topmost one i.e. the global scope. It wont work within local scopes.

                      – bendtherules
                      Jun 12 '15 at 1:50


















                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1450275%2fany-way-to-modify-locals-dictionary%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Monofisismo

                      Angular Downloading a file using contenturl with Basic Authentication

                      Olmecas