Lets say I import a module. In order for me to make the best use of it, I would like to know what properties, methods, etc. that I can use. Is there a way to find that out?
As an example: Determining running programs in Python
In this line:
os.system('WMIC /OUTPUT:C:\ProcessList.txt PROCESS get Caption,Commandline,Processid')
Let's say I wanted to also print out the memory consumed by the processes. How do I find out if that's possible? And what would be the correct 'label' for it? (just as the author uses 'Commandline', 'ProcessId')
Similarly, in this:
import win32com.client
def find_process(name):
objWMIService = win32com.client.Dispatch("WbemScripting.SWbemLocator")
objSWbemServices = objWMIService.ConnectServer(".", "root\cimv2")
colItems = objSWbemServices.ExecQuery(
"Select * from Win32_Process where Caption = '{0}'".format(name))
return len(colItems)
print find_process("SciTE.exe")
How would I make the function also print out the memory consumed, the executable path, etc.?
As for Python modules, you can do
>>> import module
>>> help(module)
and you'll get a list of supported methods (more exactly, you get the docstring, which might not contain every single method). If you want that, you can use
>>> dir(module)
although now you'd just get a long list of all properties, methods, classes etc. in that module.
In your first example, you're calling an external program, though. Of course Python has no idea which features wmic.exe has. How should it?
dir(module) returns the names of the attributes of the module
module.__dict__ is the mapping between the keys and the attributes objects themselves
module.__dict__.keys() and dir(module) are lists having the same elements, though they are not equals because the elements aren't in same order in them
it seems that help(module) iswhat you really need
Python has a build in function called dir(). I'm not sure if this is what you are referring to, but fire up a interactive python console and type:
import datetime
dir(datetime)
This should give you a list of methods, properties and submodules
#ldmvcd
Ok, excuse me, I think you are a beginner and you don't see to what fundamental notions I am refering.
Objects are Python’s abstraction for
data. All data in a Python program is
represented by objects or by relations
between objects.
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
I don't understand why it is called "abstraction": for me an object is something real in the machine, a series of bits organized according certain rules to represent conceptual data or functionning.
Names refer to objects. Names are
introduced by name binding operations.
Each occurrence of a name in the
program text refers to the binding of
that name established in the innermost
function block containing the use.
http://docs.python.org/reference/executionmodel.html#naming-and-binding
.
A namespace is a mapping from names to
objects. Most namespaces are currently
implemented as Python dictionaries,
but that’s normally not noticeable in
any way (except for performance), and
it may change in the future. Examples
of namespaces are: the set of built-in
names (containing functions such as
abs(), and built-in exception names);
the global names in a module; and the
local names in a function invocation.
In a sense the set of attributes of an
object also form a namespace.
http://docs.python.org/tutorial/classes.html#a-word-about-names-and-objects
.
By the way, I use the word attribute
for any name following a dot — for
example, in the expression z.real,
real is an attribute of the object z.
Strictly speaking, references to names
in modules are attribute references:
in the expression modname.funcname,
modname is a module object and
funcname is an attribute of it. In
this case there happens to be a
straightforward mapping between the
module’s attributes and the global
names defined in the module: they
share the same namespace!
http://docs.python.org/tutorial/classes.html#a-word-about-names-and-objects
.
Namespaces are created at different
moments and have different lifetimes.
http://docs.python.org/tutorial/classes.html#a-word-about-names-and-objects
.
The namespace for a module is
automatically created the first time a
module is imported. The main module
for a script is always called
main. http://docs.python.org/reference/executionmodel.html#naming-and-binding
.
Well, a Python programm is a big machine that plays with objects, references to these objects , names of these objects, and namespaces in which are binded the names and the objects , namespaces being implemented as dictionaries.
So, you're right: when I refer to keys , I refer to names being the keys in the diverse namespaces. Names are arbitrary or not , according if the objects they have been created to name are user's objects or built-in objects.
I give advise you to read thoroughly the parts
3.1. Objects , values and types
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
and
4.1. Naming and binding
http://docs.python.org/reference/executionmodel.html#naming-and-binding
Related
I have a challenge where I'm given a function where I can pass only a single argument which must be a builtin (no modules of any kind), for example chr or IndexError and use its attributes and call its functions to get access to other builtin types.
For example, if I choose the getattr function, I can access the builtins like this:
def main(a):
builtins = a(a, '__self__')
main(getattr)
Most other functions aren't of much help for my challenge. I know that the attributes are deep and a lot of information can be extracted.
This is a good reference: https://book.hacktricks.xyz/misc/basic-python/bypass-python-sandboxes
What can I get access to using an Ellipsis object, in Python written as ... ?
Subclasses can be accessed using ....__class__.__base__.__subclasses__() which returns a list and eventually get access back using a for loop to find which of those classes's __name__ attribute is catch-warnings, and that class's _module attribute has all the builtins (Code). I cannot use that because the index at which it will appear is always different
The python version I target is 3.9.
Is it possible to avoid importing a file with from file import function?
Someone told me i would need to put an underscore as prefix, like: _function, but isn't working.
I'm using Python 2.6 because of a legacy code.
There are ways you can prevent the import, but they're generally hacks and you want to avoid them. The normal method is to just use the underscore:
def _function():
pass
Then, when you import,
from my_module import *
You'll notice that _function is not imported because it begins with an underscore. However, you can always do this:
# In Python culture, this is considered rude
from my_module import _function
But you're not supposed to do that. Just don't do that, and you'll be fine. Python's attitude is that we're all adults. There are a lot of other things you're not supposed to do which are far worse, like
import my_module
# Remove the definition for _function!
del my_module._function
There is no privacy in Python. There are only conventions governing what external code should consider publicly accessible and usable.
Importing a module for the first time, triggers the creation of a module object and the execution of all top-level code in the module. The module object contains the global namespace with the result of that code having run.
Because Python is dynamic you can always introspect the module namespace; you can see all names defined, all objects those names reference, and you can access and alter everything. It doesn't matter here if those names start with underscores or not.
So the only reason you use a leading _ underscore for a name, is to document that the name is internal to the implementation of the module, and that external code should not rely on that name existing in a future version. The from module import * syntax will ignore such names for that reason alone. But you can't prevent a determined programmer from accessing such a name anyway. They simply do so at their own risk, it is not your responsibility to keep them from that access.
If you have functions or other objects that are only needed to initialise the module, you are of course free to delete those names at the end.
I'm trying to mimic methods.grep from Ruby which simply returns a list of available methods for any object (class or instance) called upon, filtered by regexp pattern passed to grep.
Very handy for investigating objects in an interactive prompt.
def methods_grep(self, pattern):
""" returns list of object's method by a regexp pattern """
from re import search
return [meth_name for meth_name in dir(self) \
if search(pattern, meth_name)]
Because of Python's limitation not quite clear to me it unfortunately can't be simply inserted in the object class ancestor:
object.mgrep = classmethod(methods_grep)
# TypeError: can't set attributes of built-in/extension type 'object'
Is there some workaround how to inject all classes or do I have to stick with a global function like dir ?
There is a module called forbiddenfruit that enables you to patch built-in objects. It also allows you to reverse the changes. You can find it here https://pypi.python.org/pypi/forbiddenfruit/0.1.1
from forbiddenfruit import curse
curse(object, "methods_grep", classmethod(methods_grep))
Of course, using this in production code is likely a bad idea.
There is no workaround AFAIK. I find it quite annoying that you can't alter built-in classes. Personal opinion though.
One way would be to create a base object and force all your objects to inherit from it.
But I don't see the problem to be honest. You can simply use methods_grep(object, pattern), right? You don't have to insert it anywhere.
I'm assuming the namespace is the allotted place in memory in which the name is to be stored. Or are they the same thing?
A namespace is a theoretical space in which the link between names and objects are situated: that is what is called a mapping between the names and the objects.
Names are the identifiers written in a script.
Objects are structures of bits lying in the memory.
The data structure that implements this theoretical namespace is a dictionnary. "Implements" means that it is the object that holds this data in the bits of the memory.
But the objects that this dictionary references are not grouped all together in a delimited portion of the memory, they are lying everywhere in the memory, it's the role of the dictionary to know how to find any of them with just a name at start when a name is encountered by the interpreter.
That's why I wrote it is a theoretical space, though it has a concrete existence in the memory. It is theoretical because the fact that several objects disseminated at different places in the memory can be considered to belong to one namespace is the result of the under-the-hood functionning of the Python interpreter, that is to say its data model and its execution model
In fact, things are more complex, under the hood there is a symbol table in the game. But I'm not enough competent concerning the C implementation of Python to say more. And by the way, people rarely allude to the symbol table.
However, I hope that the above explanation will shed some light in your mind concerning the subject of namespace.
Names are what can be traditionally thought of as "variables".
a = 1
b = 2
Both a and b are "names". If you try to reference a name that hasn't been set yet, you'll get a NameError:
>>> print c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'c' is not defined
Namespaces are the places where names live. Typically this is a module. Each module (file) has it's own namespace -- Or it's own set of names which map to a corresponding value (a->1, b -> 2 in my example above). You can "merge" module namespaces in different ways using python's import functionality.
import foo # bring foo into the current namespace
from foo import * # bring all of the names in foo's namespace into the current namespace
Classes can also be considered a namespace although you can't import the names directly into your module namespace without some work.
class Namespace(object):
pass
namespace = Namespace()
namespace.a = 1
namespace.b = 2
As pointed out in some of the discussion in the comments, I ought to mention that namespaces in python are usually implemented by a dictionary since those are well suited to mapping names to values/objects. On a class, (or class instance), you can access the dictionary via ClassName.__dict__ or instance.__dict__ and you can do the same with a module: module.__dict__ if module is imported.
At a generic/language agnostic level, I think of a namespace as a way to bind a group of related names (and their associated values) together and to prevent those names from getting mixed up with similar names in a different namespace. e.g. I can have foo.something and bar.something. Both names are something, but they live in different namespaces (foo and bar respectively) so we can tell them apart.
'I'm assuming the namespace is the allotted place in memory in which the name is to be stored.'
yep.
I just posted below query to comp.lang.python, but i feel this kind of question has some kind of right-of-way here on Stack Overflow, too, so be it repeated. the essence: why does ‘builtins’ have two distinct interpretations in Python 3?
I would be very gladly accept any commentaries about what this
sentence, gleaned from http://celabs.com/python-3.1/reference/executionmodel.html,
is meant to mean, or why gods have decided this is the way to go. i
anticipate this guy named Kay Schluehr will have a say on that, or
maybe even the BDFL will care to pronounce __builtins__ the
correct way to his fallovers, followers, and fellownerds::
The built-in namespace associated with the execution of
a code block is actually found by looking up the name
__builtins__ in its global namespace; this should be a
dictionary or a module (in the latter case the module’s
dictionary is used). By default, when in the __main__
module, __builtins__ is the built-in module builtins;
when in any other module, __builtins__ is an alias for
the dictionary of the builtins module itself.
__builtins__ can be set to a user-created dictionary to
create a weak form of restricted execution.
it used to be the case that there were at least two distinct terms,
‘builtin’ (in the singular) and ‘builtins’ (in the plural), some of
which existed both in module and in dict form (?just guessing?). now
there is only builtins, so fortunately the ambivalence between
singular and plural has gone—good riddance.
but why does __builtins__ change its meaning depending on whether
this is the scope of the ‘script’ (i.e. the module whose name was
present, when calling python foobar.py) or whether this is the
scope of a secondary module (imported or executed, directly or
indirectly, by foobar.py)? i cannot understand the reasoning
behind this and find it highly confusing.
rationale: why do i care?—i want to be able to ‘export names to the
global namespace that were not marked private (by an underscore
prefix) in a python module that i execute via exec( compile( get
( locator ), locator, 'exec' ), R ) where R is supposed to going
to hold the private names of said module’. it is a little arcane but
the basic exercise is to by-pass python’s import system and get similr
results... it is all about injecting names into the all-global and the
module-global namespaces.
getattr(__builtins__, '__dict__', __builtins__) should give you the dict that you want to update to "export names to the global namespace", whether __builtins__ is a dict (then it doesn't have a __dict__ attribute so getattr returns the third argument, which is the dict __builtins__ itself) or a module (then it does have that attribute and getattr returns it). This is the workaround. As to why Python's documented to work in a way requiring such a tangled workaround, I'd classify it as an unfortunate case of an implementation issue surfacing to user-visible (and indeed documented) level (sigh). Pity we didn't think of fixing it in the move to Python 3, but it's too late to make backwards-incompatible changes now:-(.