> Trying to import my made module to python with helper function:
>
> import os.path.join
> ("D","pyth_nonsens","workspace_python","PyhonTutorial","reader")
There are esoteric methods by which one can import a python
module from a filepath, but doing so is not considered good
practice, and the import statement was not designed with
filepaths in mind. Is there a good reason why you want
import from a filepath, as opposed to using the "module
identifier"? Did another language teach you to do this?
The standard method to share objects between modules is to
use the import statement. It seems you understand the first
step, but you do not understand how "import" works, nor the
limitations of it. Generally speaking, if you intend to
borrow the objects from "scriptA.py" and use them in
"scriptB.py", then "import scriptA" or "from scriptA import
blah" is all you need, *HOWEVER*, in order for these imports
to produce desirable results, "scriptA" must be somewhere
that Python knows to look. And Python does not adopt the
same youthful exuberance observed in christian children on
the morning of easter sunday...
You cannot just randomly place scripts on your HD and expect
that an import request will find them, no, "import" will
only look in a few predefined locations for the requested
module (and you can investigate these locations for yourself
by printing sys.path). So, if you'd like to store your
importable modules _outside_ of the scope of the default
search path, then you'll need to add the containing
directory to python's search path manually. Here's a little
info on the search path:
https://docs.python.org/3/tutorial/modules.html#the-module-search-path
Personaly, i prefer to us a *.pth file to define my custom
search path additions, as I can add or remove this
customization by adding or removing a single file. Plus, the
*.pth file offers an easy method by which to persist these
paths through time and across subsequent and diverse
installations. It's a practical solution because i no longer
concern myself with remembering multiple paths (some of
which are quite complex!), no, i only need to copy+paste a
single file. I suppose there are some cons to this approach,
as python is probably reading this file at every invocation
of the interpreter. But do i care that python has to sweat a
little more to save me some labour -- *NOPE*!.
What good is to be found in slaveownership, if the
slaveowner cannot offload the onerous on someone, or
something else? From my point of view, the amount of work
that Python does is irrelevant to me, so long as the time
required to do the work is tolerable to myself and/or my
clients. "Premature optimization is the root of all evil (or
at least most of it)..." they say. So what's more important:
that a program produces a result that is correct, or that a
program produces a questionable result in the quickest time?
The sane design philosophy is that a program should produce
a correct result in the shortest time possible. But the
"shortest time possible" does not mean that we sacrifice
practical necessity on the alters of speed. If we devote our
time to squeezing every drop of speed juice from the lemon,
that is time that could have been spent expanding the
feature set, or in some other practical pursuit. The blazing
fast technology of the modern era has removed optimization
as our primary goal, and has shifted our priorities to
concentrate on the more practical needs of software
development, namely: intuitive interfaces and feature
richness. We can always come back later and squeeze a few
more drops from that lemon.
> >>> import os.path.join
> >>> ("D","pyth_nonsens","workspace_python","PyhonTutorial","reader")
> File "<stdin>", line 1
> import os.path.join
> ("D","pyth_nonsens","workspace_python","PyhonTutorial","reader")
> ^
I've never understood this proclivity of newbies to cobble
multiple irrelevant actions into one test suite, as though
they were preparing a fruit cake for the oven, and then,
after tossing the whole discombobulated mess at a python
interpreter hoping that it will stick, the resulting
exception (yeah, big surprise!) causes them to assume there
is no easy answer. In this case, the contemptible action is
not ignorance, no, it is a poor methodology (ignorance can
be forgiven, whereas, a poor methodology cannot). If the
OP's intent is to test whether or not the import statement
will accept filepaths, and the OP cannot be bothered to read
the docs, then it would be behoove the OP to utilize the
smallest, non-distracting example that will test this
conjecture.
There is nothing inherently wrong about assumption, sure,
there are more acceptable scientific methods by which we may
gain insights into the unknown, but if we are going to just
simply _guess_, at least we should do it _wisely_. In this
case, a short, hard-coded filepath to a test file that is
_known_ to exist, would be the wisest way to guess. Of
course, even if the OP adopted a wise methodology, the
conjecture is a flop nonetheless, but at least, if we choose
a wise methodology, we won't be temporarily blinded by our
own superfluity in the process of conducting an experiment,
and many times, the simplicity of a properly designed test
suite will block the blinding rays of light that prevented
us from seeing the solution in the first place.
But in the end, sometimes you just have to forsake your ego,
and go RTFM.
> Can I use functions while defining paths?
Your question is as absurd as: "Can i wear tennis shoes
while boating?". We cannot provide good help if you do not
ask good questions.
--
https://mail.python.org/mailman/listinfo/python-list
