So I'm reading this old module from I think around 2002 and it has this line "import string". Did Python require you to import a string module explicitly before to be able to use string type variables or something? I don't see it used like this in the code:
string.something
The string module contains a set of useful constants, such as ascii_letters and digits, and the module is often still imported for that reason.
If you see a import string but never see string.something, someone just forgot to remove an unused import.
While there did use to be some things in string that are now standard methods of str objects, you still had to either
prefix them with string. after importing the library, or
use from string import <whatever> syntax.
Typically, the only times you'll see something properly imported but never "explicitly used" are from __future__ import with_statement or the like - the forwards/backwards compatability triggers used by Python for new language features.
Like Ambar said, it seems to be a redundant import, and RoeeeK is also right in saying that most of the string module's functions are meanwhile string methods, i.e. you can do "foobar".method() instead of string.function("foobar"). However, sometimes it is still useful to explicitely import the module; for instance, in the case of callbacks:
map(string.strip, [' foo ', ' bar ']).
Note that the above can also be achieved by [chunk.strip() for chunk in [' foo ', ' bar ']], so importing string is actually not required in this case.
well, in older versions the string module was indeed much more useful, but in the recent versions most of the string module functions are available also as string methods..
this page will give you a better look:
http://effbot.org/librarybook/string.htm
Related
I am reverse engineering for the purpose of fixing a script in Python. There is nothing about
from asyncio.windows_events import NULL
on the internet, and the documentation of asyncio is a little ambiguous. What does this line do? If I remove this line, will this affect the functionality of the code in any meaningful way?
from asyncio.windows_events import NULL
means exactly to import the name NULL from the module asyncio.windows_events.
That name is a re-export of _winapi.NULL.
_winapi is an extension module that is only compiled on Windows, and _winapi.NULL is exactly the integer 0.
In other words, you could probably replace that line with
NULL = 0
Anything that looks like
from some.package import something
means that the name something (it could be a class, a function, a variable, or etc) is being imported from some.package, and you will need to refer to this package's documentation (or in the worst case its source code) to figure out what exactly the declaration does. Though often, the code which does the import will make its purpose clear enough, even if you don't know exactly how the name is eventually defined.
Removing the import will break your code unless something was unused in the first place. Now Python won't know what something refers to.
If you type this:
import somemodule
help(somemodule)
it will print out paged package description. I would need to get the same description as a string but without importing this package to the current namespace. Is this possible? It surely is, because anything is possible in Python, but what is the most elegant/pythonic way of doing so?
Side note: by elegant way I mean without opening a separate process and capturing its stdout... ;)
In other words, is there a way to peek into a unimported but installed package and get its description? Maybe something with importlib.abc.InspectLoader? But I have no idea how to make it work the way I need.
UPDATE: I need not just not polluting the namespace but also do this without leaving any traces of itself or dependent modules in memory and in sys.modules etc. Like it was never really imported.
UPDATE: Before anyone asks me why I need it - I want to list all installed python packages with their description. But after this I do not want to have them imported in sys.modules nor occupying excessive space in memory because there can be a lots of them.
The reason that you will need to import the module to get a help string is that in many cases, the help strings are actually generated in code. It would be pointlessly difficult to parse the text of such a package to get the string since you would then have to write a small Python interpreter to reconstruct the actual string.
That being said, there are ways of completely deleting a temporarily imported modules based on this answer, which summarizes a thread that appeared on the Python mailing list around 2003: http://web.archive.org/web/20080926094551/http://mail.python.org/pipermail/python-list/2003-December/241654.html. The methods described here will generally only work if the module is not referenced elsewhere. Otherwise the module will be unloaded in the sense that import will reload it from scratch instead of using the existing sys.modules entry, but the module will still live in memory.
Here is a function that does approximately what you want and even prints a warning if the module does not appear to have been unloaded. Unlike the solutions proposed in the linked answer, this function really handles all the side-effects of loading a module, including the fact that importing one package may import other external packages into sys.modules:
import sys, warnings
def get_help(module_name):
modules_copy = sys.modules.copy()
module = __import__(module_name)
h = help(module)
for modname in list(sys.modules):
if modname not in modules_copy:
del sys[modname]
if sys.getrefcount(module) > 1:
warnings.warn('Module {} is likely not to be completely wiped'.format(module_name))
del module
return h
The reason that I make a list of the keys in the final loop is that it is inadvisable to modify a dictionary (or any other iterable) as you iterate through it. At least in Python 3, dict.keys() returns an iterable that is backed by the dictionary itself, not a frozen copy. I am not sure if h = ... and return h are even necessary, but in the worst case, h is just None.
Well, if you are only worried about keeping the global namespace tidy, you could always import in a function:
>>> def get_help():
... import math
... help(math)
...
>>> math
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'math' is not defined
I would suggest a different approach, if i understand you correctly, you wish to read a portion of a package, without importing it (even within a function with local scope). I would suggest a method to do so would be via accessing the (python_path)/Lib/site-packages/(package_name)/ and reading the contents of the respective files as an alternative to importing the module so Python can.
While reading through the objects listed under dir(__builtins__) in python2.7 I noticed that the keyword print is there.
Now under python3.5 I can see that print and exec are now objects.
What is the reasoning for this? Why even list it under __builtins__ to begin with? Specifically this keyword in particular, what difference would it have made if it were never grouped in there at all. It seems import might have a case for being listed there as well?
print is in __builtins__ because there really is a print built-in function. If you do from __future__ import print_function, the print keyword is disabled and print refers to the built-in.
exec and import are not in __builtins__. You most likely mixed them up with the built-in functions eval and __import__.
As an aside: don't use __builtins__. It's an implementation detail, and its value is different in different contexts. If you want the module containing all built-in names, use import __builtin__, or import builtins in Python 3.
This is sort of a best practice question. If I have a large number of custom classes, but don't want them in my main program is it acceptable to stick `from someFile import *' at the top? I know that I won't be doing anything to edit/redefine the classes, functions and variables from that file.
from someFile import *
a = someFunction()
#Other stuff
someFile would just contain various custom classes and function that I know work and I don't need to scroll past every time I'm working in the program. As long as I'm careful is there any reason to not do this?
If you are using a lot of classes, it is usually safer to avoid the use of this syntax. Especially if you use third-party classes, because some of them may have the same methods. (eg. sin, cos, etc) and you can get strange behaviors.
In my opinion, it is acceptable to use this syntax when you provide an example of the use of your code. In this way you only source your method like that to show the functionalities in a more clear way.
Personally I try to avoid this syntax. I prefer to explicitly call the "right" class. If you don't like to write long class/modules names, try just to load them as aliases like
import LongModuleName as LM
http://www.python.org/dev/peps/pep-0008/#imports
According to pep-8:
There is one defensible use case for a wildcard import, which is to republish an internal interface as part of a public API (for example, overwriting a pure Python implementation of an interface with the definitions from an optional accelerator module and exactly which definitions will be overwritten isn't known in advance).
In my opinion, probably the most useful case of the from someFile import * syntax is when you are using the python interpreter interactively. Image you want to do some quick math:
$ python
>>> from math import *
>>> sin(4.0)
This is especially useful when using pylab and ipython to turn your ipython session into a MATLAB clone with just the line from pylab import *.
One problem with from module import * is that it makes it difficult to see where different functions came from, compare:
import random
random.shuffle(...)
from random import shuffle
shuffle(...)
from random import *
shuffle(...)
Another is risk of name collision; if two modules have classes or functions with the same name, import * will shadow one with the other. With from x import y you can see right at the top that you might need from z import y as y2.
Using from someFile import * is fine as long as you're aware you're importing everything into the namespace of that module. This could lead to clashes if you happen to be reusing names.
Consider only importing the classes and functions that you really use in that module as it's more explicit for others who may be reading the source code. It also makes it easier to figure out where a function is defined: if I see a function and can't locate an explicit import line in the same file then I'm forced to grep / search more broadly to see where the function is defined.
I have a plypython function which does some json magic. For this it obviously imports the json library.
Is the import called on every call to the function? Are there any performance implication I have to be aware of?
The import is executed on every function call. This is the same behavior you would get if you wrote a normal Python module with the import statement inside a function body as oppposed to at the module level.
Yes, this will affect performance.
You can work around this by caching your imports like this:
CREATE FUNCTION test() RETURNS text
LANGUAGE plpythonu
AS $$
if 'json' in SD:
json = SD['json']
else:
import json
SD['json'] = json
return json.dumps(...)
$$;
This is admittedly not very pretty, and better ways to do this are being discussed, but they won't happen before PostgreSQL 9.4.
The declaration in the body of a PL/Python function will eventually become an ordinary Python function and will thus behave as such. When a Python function imports a module for the first time the module is cached in the sys.modules dictionary (https://docs.python.org/3/reference/import.html#the-module-cache). Subsequent imports of the same module will simply bind the import name to the module object found in the dictionary. In a sense, what I'm saying may cast some doubt on the usefulness of the tip given in the accepted answer, since it makes it somewhat redundant, as Python already does a similar caching for you.
To sum things up, I'd say that if you import in the standard way of simply using the import or from [...] import constructs, then you need not worry about repeated imports, in functions or otherwise, Python has got you covered.
On the other hand, Python allows you to bypass its native import semantics and to implement your own (with the __import__() function and importlib module). If this is what you're doing, maybe you should review what's available in the toolbox (https://docs.python.org/3/reference/import.html).