It there an equivalent to PHP's extract in Python? [duplicate] - php

Question

This question already has answers here:
Python equivalent of PHP's compact() and extract()
(6 answers)
Closed 7 years ago.
Looking for the python equivalent of this.
http://php.net/extract

Answer 1

Maybe you would be better off explaining what you are trying to do. Any solution to the direct question would be rather unpythonic as there is almost certainly a better way to do what you want.
EDIT (per your comments):
And indeed, there is a better way.
What you are trying to do is known as unpacking argument lists, and can be done like this:
self.__api_call__('POST', '/api/foobar/', **mydict)
A working example:
>>> def a_plus_b(a,b):
... return a+b
...
>>> mydict = {'a':3,'b':4}
>>> a_plus_b(**mydict)
7
And it also works with kwargs, as you might expect:
>>> def a_plus_b(**kwargs):
... return kwargs['a'] + kwargs['b']
...
>>> a_plus_b(**mydict)
7

Answer 2

no. why do you need it?
do the following (see comment)
def __api_call__(self, method, resource, **kwargs):
print(kwargs)
def do_call(my_dict):
self.__api_call__('POST', '/api/foobar/', **your_dict) # double asterisk!

Answer 3

One generally uses locals() to achieve this result, but the exact functionality is up to you.
>>> print apple
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'apple' is not defined
>>> print banana
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'banana' is not defined
>>> variables = {"apple" : "a rigid, juicy fruit", "banana" : "a soft, fleshy fruit"}
>>> for variable,value in variables.iteritems():
... locals()[variable] = value
...
>>> print apple
a rigid, juicy fruit
>>> print banana
a soft, fleshy fruit
EDIT
Thanks to everyone who has diligently commented on the badness of this approach. I wholeheartedly agree that THIS IS A BAD APPROACH, and it deserves to be mentioned in the actual response for anyone who stumbles across this page. (Never underestimate that; I saw this technique in a code snippet somewhere. I can see why in that particular case it was harmless, but I know I can't go around encouraging bad methodology just because there are situations in which it won't break.)

Answer 4

IMO it is at least a nice theoretical question: how such construction can be implemented and how does it look like once it is applied?
For instance, as a function it can be implemented as
import inspect
def extract_attribute(obj, names):
if type(names) == str:
names = [names]
# Get previous frame from the inspect stack.
frame = inspect.stack()[1][0]
try:
frame_locals = frame.f_locals
attributes = inspect.getmembers(
obj, lambda attr: not inspect.ismethod(attr))
for name, attribute in attributes:
if name.startswith('__') or name.endswith('__'):
continue
if name in names:
frame_locals[name] = attribute
finally:
del frame
del frame_locals
and used as
class A(object):
foo = 'bar'
a = A()
extract_attribute(a, 'foo')
assert locals()['foo'] == 'bar'
assert foo == 'bar
Note: await pylint will complain on the last line. One can find *extract_attribute* function working with object in somewhat similar way to import functionality for modules. Applying it as additional layer of scope coupling (mixed with present import) will increase complexity of the code almost without exceptions.
PS
Obvious enough manipulating built-in is a sign of doing something python was not designed to do. But self-flattering mantras like not-practical and "non-pythonic" are not really proper arguments to me. In general it is always much more "practical" to make an experiment and to see if:
1. Construction will enrich the expressiveness of the language (e.g. making it more readable and natural-like), give new functionality, etc.
2. Construction is too ugly and dangerous to be used, too flexible and unsafe, performance trade-offs are unacceptable, etc.
Illustration and test by explicit example is a preferred alternative. Looking at code everyone is free to make his own opinion without sharing the "professional guts" or copy-pasting religious dogmas. Please don't.