Apologies in advance for conflating functions and methods, I don't have time at the moment to sort out the terminology but I'm aware of the distinction (generally).
I'm trying to control what functions are run by my script via command-line arguments. After a lot of reading here and elsewhere, I'm moving in the direction of the following example.
# After connecting to a database with MySQLdb and defining a cursor...
cursor.execute(some_query_stored_earlier)
for row in cursor:
for method_name in processing_methods: # ('method1','method2', ...)
globals()[method_name](row)
(Clarification: processing_methods is a tuple of user-defined strings via command-line argument(s) with nargs='*'.)
However, I'm running into problems with print (no surprise there). I would like print to be:
among the methods that MIGHT be specified from the command line;
the default method when NO methods are specified from the command line;
not performed if ONLY OTHER methods are specified from the command line.
Let me acknowledge that I can make things easier on myself by eliminating the first and third criteria and simply doing:
for row in cursor:
print row
for method_name in processing_methods:
globals[method_name](row)
But I really don't want to ALWAYS print every row in what will sometimes be a several-million-rows result. I did a future import, hoping that would solve my problem - no such luck. So I did a little exploring:
>>> from __future__ import print_function
>>> print
<built-in function print>
>>> globals()
{'__builtins__': <module '__builtin__' (built-in)>, '__name__': '__main__', '__doc__': None, 'print_function': _Feature((2, 6, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 65536), '__package__': None}
>>> a = "Hello, world!"
>>> print(a)
Hello, world!
>>> globals()['print'](a)
Traceback (most recent call last):
File "<pyshell#33>", line 1, in <module>
globals()['print'](a)
KeyError: 'print' # Okay, no problem, obviously it's...
>>> globals()['print_function'](a)
Traceback (most recent call last):
File "<pyshell#34>", line 1, in <module>
globals()['print_function'](a)
AttributeError: _Feature instance has no __call__ method # ...huh.
So then I did a little more reading, and this Q&A prompted some more exploring:
>>> dir()
['__builtins__', '__doc__', '__name__', '__package__']
>>> __builtins__
<module '__builtin__' (built-in)>
>>> 'print' in dir(__builtins__)
True # now we're getting somewhere!
>>> __builtins__.print something
SyntaxError: invalid syntax # fair enough.
>>> __builtins__.print('something')
SyntaxError: invalid syntax # wait, what?
>>> dir(__builtins__.print)
SyntaxError: invalid syntax # -_-
Something is going on here that I just don't understand, and this other Q&A hasn't made it any clearer. I think the easy solution to my particular issue is going to be a mildly awkward wrapper like:
def printrows(row):
print row # assuming no future import, of course
But it's driving me crazy: Why can't I access print via the globals dictionary? Am I doing it wrong, or is it just something you can't do with built-in functions?
Did you forget to repeat from __future__ import print_function when you opened a new shell for your second try (where you got all those syntax errors)? It works for me: https://ideone.com/JOBAAk
If you do an otherwise seemingly useless assignment, it works the way I think you expected. I'm not an expert in the internals at work here, so I can't explain WHY this works, but it does.
>>> from __future__ import print_function
>>> row="Hello world"
>>> print = print
>>> globals()['print'](row)
Hello world
Related
What is the best alternative to more-ing or less-ing multi-line output while running python in the interpreter mode?
Suppose, there exists an object variable foo which had many properties. A dir(foo) would dump onto the screen. We cannot inspect or page this output since you are presented with the interpreter prompt immediately.
Currently the only way to inspect such data is to store into a variable and view slices or it. For e.g.
>>> keys = dir(foo)
>>> len(keys)
120
>>> keys[10:20] #viewing the sub slice of keys
...
Hoping that there is an alternative to this. I know that help() does present with a more-like interface, but only for documentation of the object under consideration.
help's more-like interface is provided by the pydoc module, in particular its undocumented method pager. If you convert your data to a string (perhaps by using the pprint module for additional readability), you can send it to pager to get the interactive visualization you're looking for.
>>> import pydoc
>>> import pprint
>>> def more_vars(obj):
... pydoc.pager(pprint.pformat(vars(obj)))
...
>>> import math
>>> more_vars(math)
{'__doc__': 'This module provides access to the mathematical functions\n'
'defined by the C standard.',
'__loader__': <class '_frozen_importlib.BuiltinImporter'>,
'__name__': 'math',
'__package__': '',
[not pictured: about 30 more lines of methods/attributes]
'frexp': <built-in function frexp>,
'fsum': <built-in function fsum>,
'gamma': <built-in function gamma>,
-- More --
I just started looking into the Python and need help on this.
In the shell I did
>>> print = 1
Now when I tried to print anything like
>>> print ("hello")
I am getting "TypeError: 'int' object is not callable, obviously because print in now a int
I am able to figure out that if I restart the shell, print starts working fine again.
What I want to know that how can I reset the print to its original state i.e. print to console without restarting the shell?
You created a global that masks the built-in name. Use del to remove the new global; Python will then find the built-in again:
del print
Python looks for print through the current scope (in functions that includes locals and any parent scopes), then globals, then the built-in namespace, and it is in the latter that the print() function lives.
You have "masked" the builtin print function by creating a variable with the same name. You could do one of three things:
Quit python and restart it. This is guaranteed to work. :-)
Delete the variable you created, as suggested by #MartijnPieters.
Change the new variable to refer to the builtins.print function.
For the last option, you'll need to import builtins.
>>> print = 1
>>> print("Hello")
>>> Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable
>>> import builtins
>>> dir(builtins)
>>> ['ArithmeticError', 'AssertionError', 'AttributeError',
...
'print',
...
'tuple', 'type', 'vars', 'zip']
>>> print=builtins.print
>>> print("Hello")
>>> Hello
Let's have a.py be:
def foo():
global spam
spam = 42
return 'this'
At a console, if I simply import a, things make sense to me:
>>> import a
>>> a.foo()
'this'
>>> a.spam
42
However, if I do the less popular thing and...
>>> from a import *
>>> foo()
'this'
>>> spam
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'spam' is not defined
>>> a.spam
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
I've read opinions about why people don't like "from module import * " from a namespace perspective, but I can't find anything on this behavior, and frankly I figured out that this was the issue I was having by accident.
When you ask for a.spam there happens a namespace search in the module a and spam is found. But when you ask for just spam:
>>> from a import * # imported foo, spam doesn't exist yet
>>> foo()
spam is created in the namespace a (you cannot access it with such import though), but not in the current module. And it seems like nobody promised us to add newly added globals of a to all the namespaces module a has been imported into via *. That will require storing import links inside the interpreter and probably will degrade performance if one heavily imported module does such tricks all the time.
And imagine you have defined spam in your main module prior to calling foo(). That would be downright name collision.
Just as illustration, you can do from a import * to get fresh updates for the module a:
from a import *
print(foo())
from a import *
print(spam)
Let's go thorough it step by step:
At the point of importing, a only has the symbol foo which refers to a function.
Only if the function is executed, a gets the additional symbol spam.
In the first case, you do import a and get a "handle" to the module, which allows you to monitor whatever happens later. If you'd do a.spam before calling a.foo(), you'd get an error.
In the second case, from a import * gives you whatever currently is in the module - and that's just spam(). After calling that, you could do from a import * to get spam as well.
I generally agree with Vovanrock2002.
As was recently explained to me, the '.' is a scope resolution operator. import a and from a import * give you different syntaxes. from a import * imports each global variable from a separately, and binds them as variables in the local scope. A more practical example might be the difference between import datetime and from datetime import date. With the former, I have to create a date object using datetime.date(2015, 11, 12), with the latter I get to just use date(2015, 11, 12).
You can read more on the import statement
I would have to differ with you, however, in that I don't believe that spam is the meaning of life, the universe, and everything.
I have a function which receives a method. I would like to recognise whether this method is written in Python or in Cython. Is there some reliable way to do this?
Just a thought but, assuming that "pure Python" means "not built-in" where the term “built-in” means “written in C” (according to Python's documentation):
We could then distinguish those two kinds by doing:
>>> import types
>>> types.BuiltinFunctionType
<type 'builtin_function_or_method'>
This is not C-compiled function :
>>> def foo(x):
... pass
>>> isinstance(foo, types.BuiltinFunctionType)
False
This is C-compiled function :
>>> from numpy import array
>>> isinstance(array, types.BuiltinFunctionType)
True
So any third-party module with C extensions will also report its functions as type builtin_function_or_method.
Related link:
http://docs.python.org/2/library/types.html
EDIT :
Another idea (a dirty one, but as Sage is not cooperative...):
>>> def foo(x):
... pass
>>> foo.some_attr = 0
is accepted, while:
>>> array.some_attr = 0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'builtin_function_or_method' object has no attribute 'some_attr'
Hoping this can be helpful... You tell me.
Given that I have the code object for a module, how do I get the corresponding module object?
It looks like moduleNames = {}; exec code in moduleNames does something very close to what I want. It returns the globals declared in the module into a dictionary. But if I want the actual module object, how do I get it?
EDIT:
It looks like you can roll your own module object. The module type isn't conveniently documented, but you can do something like this:
import sys
module = sys.__class__
del sys
foo = module('foo', 'Doc string')
foo.__file__ = 'foo.pyc'
exec code in foo.__dict__
As a comment already indicates, in today's Python the preferred way to instantiate types that don't have built-in names is to call the type obtained via the types module from the standard library:
>>> import types
>>> m = types.ModuleType('m', 'The m module')
note that this does not automatically insert the new module in sys.modules:
>>> import sys
>>> sys.modules['m']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: 'm'
That's a task you must perform by hand:
>>> sys.modules['m'] = m
>>> sys.modules['m']
<module 'm' (built-in)>
This can be important, since a module's code object normally executes after the module's added to sys.modules -- for example, it's perfectly correct for such code to refer to sys.modules[__name__], and that would fail (KeyError) if you forgot this step. After this step, and setting m.__file__ as you already have in your edit,
>>> code = compile("a=23", "m.py", "exec")
>>> exec code in m.__dict__
>>> m.a
23
(or the Python 3 equivalent where exec is a function, if Python 3 is what you're using, of course;-) is correct (of course, you'll normally have obtained the code object by subtler means than compiling a string, but that's not material to your question;-).
In older versions of Python you would have used the new module instead of the types module to make a new module object at the start, but new is deprecated since Python 2.6 and removed in Python 3.