On 5/15/2023 3:26 AM, Barry wrote:
On 15 May 2023, at 05:39, Thomas Passin wrote:
On 5/14/2023 11:08 PM, Chris Angelico wrote:
On Mon, 15 May 2023 at 12:07, Thomas Passin wrote:
Well, no, why would you assume that? I started to use Linux - in VMs -
because I had to make sure that my cros
On Mon, 15 May 2023 at 14:38, Thomas Passin wrote:
>
> On 5/14/2023 11:08 PM, Chris Angelico wrote:
> > On Mon, 15 May 2023 at 12:07, Thomas Passin wrote:
> >> Well, no, why would you assume that? I started to use Linux - in VMs -
> >> because I had to make sure that my cross-platform java/jytho
> On 15 May 2023, at 05:39, Thomas Passin wrote:
>
> On 5/14/2023 11:08 PM, Chris Angelico wrote:
>>> On Mon, 15 May 2023 at 12:07, Thomas Passin wrote:
>>> Well, no, why would you assume that? I started to use Linux - in VMs -
>>> because I had to make sure that my cross-platform java/jytho
On 5/14/2023 11:08 PM, Chris Angelico wrote:
On Mon, 15 May 2023 at 12:07, Thomas Passin wrote:
Well, no, why would you assume that? I started to use Linux - in VMs -
because I had to make sure that my cross-platform java/jython Tomcat
program would work right on Linux. Why, for example, woul
On Mon, 15 May 2023 at 12:07, Thomas Passin wrote:
> Well, no, why would you assume that? I started to use Linux - in VMs -
> because I had to make sure that my cross-platform java/jython Tomcat
> program would work right on Linux. Why, for example, would I think to
> install Idle from the packa
On 5/14/2023 7:28 PM, Chris Angelico wrote:
On Mon, 15 May 2023 at 09:22, Thomas Passin wrote:
You made a little slam against Windows, but you will find it harder to
get things working on Linux. Ubuntu, like many other Linux distros,
does not come with pip and Tk (needed for Idle) installed, a
On Mon, 15 May 2023 at 09:22, Thomas Passin wrote:
> You made a little slam against Windows, but you will find it harder to
> get things working on Linux. Ubuntu, like many other Linux distros,
> does not come with pip and Tk (needed for Idle) installed, and it's not
> so obvious how to install t
On 5/14/2023 3:00 PM, Grizzy Adams via Python-list wrote:
Sunday, May 14, 2023 at 11:11, Mats Wichmann wrote:
Re: PythonPath / sys.path (at least in part)
[snip]
I have since moved up (a little) so only ~4 years old, I then updated pip from
9.x to 19.1
reason its an old version is it'
not help,
The default value of the above registry key is only used if Python
can't calculate the default sys.path based on searching for "os.py",
the landmark module in the standard library. This can happen sometimes
when Python is embedded or run from a symlink.
The default value
On 5/14/23 13:00, Grizzy Adams via Python-list wrote:
Sunday, May 14, 2023 at 11:11, Mats Wichmann wrote:
Re: PythonPath / sys.path (at least in part)
On 5/14/23 10:43, Barry wrote:
I take it you have business reasons to use an obsolete version python.
Where did you get your version of
Sunday, May 14, 2023 at 11:11, Mats Wichmann wrote:
Re: PythonPath / sys.path (at least in part)
>On 5/14/23 10:43, Barry wrote:
>> I take it you have business reasons to use an obsolete version python.
>> Where did you get your version of python from?
>In fact, a *nine* y
nything to do with the sys.path, though.
--
https://mail.python.org/mailman/listinfo/python-list
> On 14 May 2023, at 16:32, Grizzy Adams via Python-list
> wrote:
>
> Hi All
>
> My first post (repeated)
>
> I am having a problem with PythonPath / sys.path
>
> I have a dir where I keep all my current work, but I can't seem to add it to
> Py
Hi All
My first post (repeated)
I am having a problem with PythonPath / sys.path
I have a dir where I keep all my current work, but I can't seem to add it to
PythonPath / sys.path
When I try to import one of my modules I see
>>>import My_Working_File
Traceback (most recent call
Ralf M. ha scritto:
Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list:
How are you invoking your script? Presumably you have some code
in your embedding application that takes a script path and runs
it. Instead of putting the code to update sys.path into every
script, the embedding
On 4/22/23 16:04, Ralf M. wrote:
Am 21.04.2023 um 18:07 schrieb Thomas Passin:
On 4/20/2023 5:47 PM, Ralf M. wrote:
Hello,
when I run a script with a "normally" installed python, the directory
the script resides in is automatically added as first element to
sys.path, so th
On 23/04/23 10:04 am, Ralf M. wrote:
I thought about that, but for that to work all local modules across all
script locations must have unique names, otherwise import might get hold
of a module from the wrong directory.
You could put all the local modules belonging to a particular
script into
On 4/22/2023 5:45 PM, Ralf M. wrote:
Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list:
How are you invoking your script? Presumably you have some code
in your embedding application that takes a script path and runs
it. Instead of putting the code to update sys.path into every
script
Am 21.04.2023 um 18:07 schrieb Thomas Passin:
On 4/20/2023 5:47 PM, Ralf M. wrote:
Hello,
when I run a script with a "normally" installed python, the directory
the script resides in is automatically added as first element to
sys.path, so that "import my_local_module" find
Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list:
How are you invoking your script? Presumably you have some code
in your embedding application that takes a script path and runs
it. Instead of putting the code to update sys.path into every
script, the embedding application could do it
Am 21.04.2023 um 17:31 schrieb Mats Wichmann:
On 4/20/23 15:47, Ralf M. wrote:
Hello,
when I run a script with a "normally" installed python, the directory
the script resides in is automatically added as first element to
sys.path, so that "import my_local_module" finds m
How are you invoking your script? Presumably you have some code
in your embedding application that takes a script path and runs
it. Instead of putting the code to update sys.path into every
script, the embedding application could do it before running
the script.
--
Greg
--
https
On 4/20/2023 5:47 PM, Ralf M. wrote:
Hello,
when I run a script with a "normally" installed python, the directory
the script resides in is automatically added as first element to
sys.path, so that "import my_local_module" finds my_local_module.py in
the directory of t
On 4/20/23 15:47, Ralf M. wrote:
Hello,
when I run a script with a "normally" installed python, the directory
the script resides in is automatically added as first element to
sys.path, so that "import my_local_module" finds my_local_module.py in
the directory of the scrip
Hello,
when I run a script with a "normally" installed python, the directory
the script resides in is automatically added as first element to
sys.path, so that "import my_local_module" finds my_local_module.py in
the directory of the script.
However, when I run
Robin Becker wrote at 2020-3-12 10:25 +:
> ...
>I want many different versions of python all in one place to use for testing.
I contribute to the `zopefoundation` projects. They, too, have a need
to test with many different Python versions -- and use "tox" for it.
Maybe, "tox" can also help so
On 12/03/2020 09:19, Dieter Maurer wrote:
Let me try again:
When you start "python", its "site" module extends "sys.path"
to include an appropriate "site-packages".
For this, it uses a heuristic based on the path with which you
have called the i
s just a link to the base python.
>
>It seems as though the above doesn't apply to the python itself which seems
>kind of dumb. A quick check reveals that the
>documentation later which says
Let me try again:
When you start "python", its "site" module extends &q
On 11/03/2020 17:24, Dieter Maurer wrote:
Robin Becker wrote at 2020-3-11 15:26 +:
I'm trying to understand why python 3.8.2 venv behaves differently when it is
executed va a link
Make the env
rptlab@everest:~/code/hg-repos
$ python38 -mvenv __py__/382v
...
so the linked versio
>
>make a link
>> $ ln -s ../__py__/382v/bin/python bin/python382v
>
>the venv sys.path
>> rptlab@everest:~/code/hg-repos > $ __py__/382v/bin/python -c"import
>> sys;print('\n'.join(sys.path))"
>>
>> /home/rptlab/LOCAL/382/lib/pyth
On 2020-03-11, Robin Becker wrote:
> I'm trying to understand why python 3.8.2 venv behaves differently
> when it is executed va a link
Because site.py contains a function called venv() which looks up the
path of the executed python binary, and searches for the virtual
environment relative to tha
I'm trying to understand why python 3.8.2 venv behaves differently when it is
executed va a link
Make the env
rptlab@everest:~/code/hg-repos
$ python38 -mvenv __py__/382v
rptlab@everest:~/code/hg-repos
make a link
$ ln -s ../__py__/382v/bin/python bin/python382v
the venv sys.path
r
Note that in the `sys.path`variable the path is given as absolute path (I only
wrote it relative to `~` in the in my post, but in the script the absolute path
is used everywhere). See line 2:
```
['/home/pyuser/.homeassistant',
'/home/pyuser/.homeassistant/deps/lib
ad than where the modules are imported. (However
>> as far as I can tell the importing thread waits for the install to finish.)
>>
>> Now the interesting thing is that when I start HA in verbose mode, I can see
>> that Python is trying not all of the paths that are in `sys.
g thread waits for the install to finish.)
>
> Now the interesting thing is that when I start HA in verbose mode, I can see
> that Python is trying not all of the paths that are in `sys.path` (in the
> following snippet I cut out some stuff for brevity. Link to the full log at
> the
Am Sonntag, 29. Juli 2018 01:32:07 UTC+2 schrieb MRAB:
That was also my first suspicion, but I checked that the path exists by
printing the directory contents out, right before the ìmport ` statement.
The "please check your config" message are a result of another package
(aiohttp_cors) that is a
start HA in verbose mode, I can see
that Python is trying not all of the paths that are in `sys.path` (in the
following snippet I cut out some stuff for brevity. Link to the full log at the
end). As one can see the `~/.homeassistant/deps/lib/python3.7/site-packages`
location is not tried and he
is trying not all of the paths that are in `sys.path` (in the
following snippet I cut out some stuff for brevity. Link to the full log at the
end). As one can see the `~/.homeassistant/deps/lib/python3.7/site-packages`
location is not tried and hence the import fails:
```
# trying
/home/p
Thomas Jollans wrote:
You can find out where a module is loaded from by checking its __file__
attribute. Run python (in interactive mode) and execute
import pyreadline
pyreadline.__file__
Thanks for that tip.
Does that mean that only this .egg is where python imports all pyreadline
files f
On 28/10/17 19:24, ElChino wrote:
> From the Python2.7 snippet in [1], Python2.7 reports that my
> sys.path[] contains:
> f:\ProgramFiler\Python27\lib\site-packages\pyreadline-2.0-py2.7-win32.egg
>
> (a .zip-file)
>
> But I have also a 'f:\ProgramFiler\Python27\li
From the Python2.7 snippet in [1], Python2.7 reports that my
sys.path[] contains:
f:\ProgramFiler\Python27\lib\site-packages\pyreadline-2.0-py2.7-win32.egg
(a .zip-file)
But I have also a 'f:\ProgramFiler\Python27\lib\site-packages\pyreadline'
directory. With the complete package A
;s failing to find the lib package. Since you removed
>> the "lib" directory from sys.path, does its parent directory exist in
>> sys.path?
>
>
> The path is not in the modules path or in sys.path. Hence the append. I
> thought I could add the local "lib"
On 09/08/2017 05:41 PM, Ian Kelly wrote:
I'm confused about where the character_tools import is made. If that's
within a module in the lib package, it should be fine.
It looks like it's failing to find the lib package. Since you removed
the "lib" directory from
ERROR collecting tests/test_base_tools.py
> __
> tests/test_base_tools.py:6: in
>> import lib.base_tools
> E ImportError: No module named lib.base_tools
It looks like it's failing to find the lib package. Since you removed
th
A kind soul pointed out that my code uses a sys.path.append("lib") to
get files to be imported:
sys.path.append("lib")
from character_tools import *
He noted that having an __init__.py in lib and using:
from .character_tools import *
Should be sufficient for "please do
On Wed, Feb 8, 2017 at 8:22 AM, Pavol Lisy wrote:
>>> How about graphic and video designers? Just how well does hg cope with
>>> gigabytes of video data?
>>
>> I've no idea, but I know that git can handle large amounts of data.
>> (There are a couple of extensions that make it easier.)
>
> But the
On 2/6/17, Chris Angelico wrote:
> On Mon, Feb 6, 2017 at 1:19 PM, Steve D'Aprano
> wrote:
[...]
>> How about graphic and video designers? Just how well does hg cope with
>> gigabytes of video data?
>
> I've no idea, but I know that git can handle large amounts of data.
> (There are a couple of
On Mon, 06 Feb 2017 09:07:34 +1100, Steve D'Aprano wrote:
> On Sun, 5 Feb 2017 07:01 pm, Wildman wrote:
>
>> Sure, you
>> could trick someone into running a program that could
>> mess with $HOME but that is all. For anyone, like me,
>> that makes regular backups, that is not a big problem.
>> To
On Mon, Feb 6, 2017 at 1:19 PM, Steve D'Aprano
wrote:
> On Mon, 6 Feb 2017 09:26 am, Chris Angelico wrote:
>
>> On Mon, Feb 6, 2017 at 9:07 AM, Steve D'Aprano
>> wrote:
>>> As far as "regular backups", well, you're just not thinking deviously
>>> enough. If I were to write a ransomware applicatio
On Mon, 6 Feb 2017 09:26 am, Chris Angelico wrote:
> On Mon, Feb 6, 2017 at 9:07 AM, Steve D'Aprano
> wrote:
>> As far as "regular backups", well, you're just not thinking deviously
>> enough. If I were to write a ransomware application, running as the
>> regular user, I would have the applicatio
On Mon, Feb 6, 2017 at 9:07 AM, Steve D'Aprano
wrote:
> As far as "regular backups", well, you're just not thinking deviously
> enough. If I were to write a ransomware application, running as the regular
> user, I would have the application encrypt files and emails just a few at a
> time, over a p
On Sun, 5 Feb 2017 07:01 pm, Wildman wrote:
> Sure, you
> could trick someone into running a program that could
> mess with $HOME but that is all. For anyone, like me,
> that makes regular backups, that is not a big problem.
> To do any real damage to the system or install a key
> logger or some
On Sat, 04 Feb 2017 19:12:55 +, Grant Edwards wrote:
> On 2017-02-04, Wildman via Python-list wrote:
>>>
>>> The next time you are in the /tmp directory looking for something, can
>>> you guess what happens when you mistype "ls" as "sl"?
>>>
DOS and Windows has searched the current dir
On Sat, Feb 4, 2017 at 3:19 PM, Wildman via Python-list
wrote:
>
> Personally I don't understand the danger in having the dot in the path. The
> './' only
> means the current directory. DOS and Windows has searched the current
> directory
> since their beginning. Is that also dangerous?
On W
On 02/04/2017 12:20 PM, Lew Pitcher wrote:
> It doesn't take root access to write a file to /tmp
> In fact, /tmp is specifically set up to allow /any/ user to create /any/ file
> or directory in it.
>
> Witness:
>
>
> guest@bitsie:~$ chmod a+x /tmp/dothis
>
> Hey! I've even made the file exe
On 02/04/2017 08:19 AM, Wildman via Python-list wrote:
> No, I do not know. You might try your question in
> a linux specific group. Personally I don't understand
> the danger in having the dot in the path. The './'
> only means the current directory. DOS and Windows
> has searched the current
On 04Feb2017 12:56, Wildman wrote:
On Sat, 04 Feb 2017 18:25:03 +, Grant Edwards wrote:
The next time you are in the /tmp directory looking for something, can
you guess what happens when you mistype "ls" as "sl"?
[...]
Your scenario assumes the malicious user has root access
to be able to
On 04Feb2017 09:19, Wildman wrote:
[...] Personally I don't understand
the danger in having the dot in the path. The './'
only means the current directory. DOS and Windows
has searched the current directory since their
beginning. Is that also dangerous?
Citing DOS and Windows as prior art
On 04Feb2017 08:10, Neal Becker wrote:
Neal Becker wrote:
I want to make sure any modules I build in the current directory overide
any
others. To do this, I'd like sys.path to always have './' at the
beginning.
What's the best way to ensure this is always true wh
Dan Sommers :
> On Sat, 04 Feb 2017 21:19:06 +0200, Marko Rauhamaa wrote:
>> Now, that's why the distros are careful to place $HOME/bin as the
>> final entry of PATH; the system commands take precedence over the
>> user's personal ones. However, the user is free to define the PATH
>> any way they
On Sat, 04 Feb 2017 21:19:06 +0200, Marko Rauhamaa wrote:
> Now, that's why the distros are careful to place $HOME/bin as the
> final entry of PATH; the system commands take precedence over the
> user's personal ones. However, the user is free to define the PATH any
> way they like.
I deliberatel
On Saturday February 4 2017 13:56, in comp.lang.python, "Wildman"
wrote:
> On Sat, 04 Feb 2017 18:25:03 +, Grant Edwards wrote:
>
>> On 2017-02-04, Wildman via Python-list wrote:
>>
>>> No, I do not know. You might try your question in a linux specific
>>> group. Personally I don't unde
Grant Edwards :
> It allows a malicous user to put an evil executable someplace public
> like /tmp and have it executed accidentally. For example, let's say
> this executable file was named "sl" and placed in /tmp.
>
> --sl--
> #!/bin/bash
>
On Sat, 04 Feb 2017 12:56:58 -0600, Wildman wrote:
> On Sat, 04 Feb 2017 18:25:03 +, Grant Edwards wrote:
>> It allows a malicous user to put an evil executable someplace public
>> like /tmp and have it executed accidentally. For example, let's say
>> this executable file was named "sl" and
On 2017-02-04, Wildman via Python-list wrote:
>>
>> The next time you are in the /tmp directory looking for something, can
>> you guess what happens when you mistype "ls" as "sl"?
>>
>>> DOS and Windows has searched the current directory since their
>>> beginning. Is that also dangerous?
>>
>>
On Sat, 04 Feb 2017 18:25:03 +, Grant Edwards wrote:
> On 2017-02-04, Wildman via Python-list wrote:
>
>> No, I do not know. You might try your question in a linux specific
>> group. Personally I don't understand the danger in having the dot
>> in the path. The './' only means the current
On 2017-02-04, Wildman via Python-list wrote:
> No, I do not know. You might try your question in a linux specific
> group. Personally I don't understand the danger in having the dot
> in the path. The './' only means the current directory.
It allows a malicous user to put an evil executable
On Sat, 04 Feb 2017 09:19:38 -0600, Wildman wrote:
> On Sat, 04 Feb 2017 11:27:01 +0200, Jussi Piitulainen wrote:
>
>> Wildman writes:
>>
>> [snip]
>>
>>> If anyone is interested the correct way is to add this to /etc/profile
>>> (at the bottom):
>>>
>>> PATH=$PATH:./
>>> export PATH
>>
>> Out
Wildman writes:
> On Sat, 04 Feb 2017 11:27:01 +0200, Jussi Piitulainen wrote:
>
>> Wildman writes:
>>
>> [snip]
>>
>>> If anyone is interested the correct way is to add this to
>>> /etc/profile (at the bottom):
>>>
>>> PATH=$PATH:./
>>> export PATH
>>
>> Out of interest, can you think of a cor
On Sat, 04 Feb 2017 11:27:01 +0200, Jussi Piitulainen wrote:
> Wildman writes:
>
> [snip]
>
>> If anyone is interested the correct way is to add this to
>> /etc/profile (at the bottom):
>>
>> PATH=$PATH:./
>> export PATH
>
> Out of interest, can you think of a corresponding way that a mere user
Neal Becker wrote:
> I want to make sure any modules I build in the current directory overide
> any
> others. To do this, I'd like sys.path to always have './' at the
> beginning.
>
> What's the best way to ensure this is always true whenever I run python
Wildman writes:
[snip]
> If anyone is interested the correct way is to add this to
> /etc/profile (at the bottom):
>
> PATH=$PATH:./
> export PATH
Out of interest, can you think of a corresponding way that a mere user
can remove the dot from their $PATH after some presumably well-meaning
system
ir trojan horse commands after typing errors, such as the ever
popular "gerp" search programme.
Even with Python I'd feel it is better to not have "." in the
sys.path; I'd be happier with a full path to a preferred source of
modules. (Yes, I know Python likes to search
Steve D'Aprano writes:
> On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote:
> > See https://www.python.org/dev/peps/pep-0328/>, in particular
> > https://www.python.org/dev/peps/pep-0328/#guido-s-decision>.
>
> I think you are conflating the package directory and . the current
> working directory.
I
On 04Feb2017 13:59, Steve D'Aprano wrote:
On Sat, 4 Feb 2017 01:13 pm, Cameron Simpson wrote:
1. In your .bashrc file, or equivalent, set the environment
variable PYTHONPATH:
export PYTHONPATH='./;$PYTHONPATH'
You want double quotes (allowing parameter substitution) instead of single
quote
On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote:
> So, for the past ten years and more, Python supports import of modules
> from the current directory with an explicit *relative* path::
>
> # Absolute imports, searching ‘sys.path’.
> import datetime
> from collections
On Sat, 4 Feb 2017 01:13 pm, Cameron Simpson wrote:
>>1. In your .bashrc file, or equivalent, set the environment
>> variable PYTHONPATH:
>>export PYTHONPATH='./;$PYTHONPATH'
>
> You want double quotes (allowing parameter substitution) instead of single
> quotes here. Or, of course, no quotes a
s. To do this, I'd like sys.path to always have './'
at the beginning.
The ‘sys.path’ list is used only for *absolute* imports. Modules in the
current directory should not be imported with an absolute path[0]. So, the
current directory should not be in ‘sys.path’.
[...]
[0]: Why no
On 04Feb2017 12:16, Steve D'Aprano wrote:
On Sat, 4 Feb 2017 03:06 am, Neal Becker wrote:
I want to make sure any modules I build in the current directory overide
any
others. To do this, I'd like sys.path to always have './' at the
beginning.
What's the best way to e
On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote:
> Neal Becker writes:
>
>> I want to make sure any modules I build in the current directory
>> overide any others. To do this, I'd like sys.path to always have './'
>> at the beginning.
>
> The ‘sys.p
such as the ever popular "gerp" search programme.
Even with Python I'd feel it is better to not have "." in the sys.path; I'd be
happier with a full path to a preferred source of modules. (Yes, I know Python
likes to search the current directory for modules, n
On Sat, 4 Feb 2017 03:06 am, Neal Becker wrote:
> I want to make sure any modules I build in the current directory overide
> any
> others. To do this, I'd like sys.path to always have './' at the
> beginning.
>
> What's the best way to ensure this is alw
On 04Feb2017 10:13, Ben Finney wrote:
Neal Becker writes:
I want to make sure any modules I build in the current directory
overide any others. To do this, I'd like sys.path to always have './'
at the beginning.
The ‘sys.path’ list is used only for *absolute* imports. Modules
If you use
>>>> /etc/rc.local, the execute bit must be set.
>>>
>>> I don't think this is what Neal Becker was asking about. He's talking
>>> about the Python module search path (sys.path) not the operating system
>>> PATH variable. Corre
Neal Becker writes:
> I want to make sure any modules I build in the current directory
> overide any others. To do this, I'd like sys.path to always have './'
> at the beginning.
The ‘sys.path’ list is used only for *absolute* imports. Modules in the
current director
sking about. He's talking
about the Python module search path (sys.path) not the operating system
PATH variable. Correct me if I'm wrong.
After re-reading the post I see you are correct.
I will endeavor to read a little closer and a
little slower in the future.
Also, what you describ
out. He's talking
> about the Python module search path (sys.path) not the operating system
> PATH variable. Correct me if I'm wrong.
After re-reading the post I see you are correct.
I will endeavor to read a little closer and a
little slower in the future.
--
GNU/Linux user #5
On 02/03/2017 12:07 PM, Wildman via Python-list wrote:
> Sorry, I forgot something important. If you use
> /etc/rc.local, the execute bit must be set.
I don't think this is what Neal Becker was asking about. He's talking
about the Python module search path (sys.path) not the
On Fri, 03 Feb 2017 12:58:15 -0600, Wildman wrote:
> On Fri, 03 Feb 2017 11:06:00 -0500, Neal Becker wrote:
>
>> I want to make sure any modules I build in the current directory overide any
>> others. To do this, I'd like sys.path to always have './' at the
On Fri, 03 Feb 2017 11:06:00 -0500, Neal Becker wrote:
> I want to make sure any modules I build in the current directory overide any
> others. To do this, I'd like sys.path to always have './' at the beginning.
>
> What's the best way to ensure this is always
I want to make sure any modules I build in the current directory overide any
others. To do this, I'd like sys.path to always have './' at the beginning.
What's the best way to ensure this is always true whenever I run python3?
--
https://mail.python.org/mailman/listinfo/python-list
Pierre Rouleau writes:
> On a OS/X 101.10.5 (Yosemite) system, the system Python just got updated to
> 2.7.10 but it sys.path is partially invalid. How can I fix that?
> ... details removed ...
You have found out that the execution of "site.py" inserts
the invalid entri
Hi,
On a OS/X 101.10.5 (Yosemite) system, the system Python just got updated to
2.7.10 but it sys.path is partially invalid. How can I fix that? I don't want
to add something in PYTHONPATH. I know I can create a softlink at the invalid
location to where the real files are located.I
-c "import sys; [sys.stdout.write('%%s\n' %% p) for (i,p) in
enumerate(sys.path)]" | sort --ignore-case
which produces:
f:\Documents and Settings\Gisle
Vanem\Programdata\Python\Python27\site-packages
f:\windows\system32\python27.zip<< !! doesn't exist, but okay.
, which just
>> contains the site-packages path. Removing that file solves the issue
>> for me.
>
>
> That was the case here too! Deleted my setuptools.pth and the "problem"
> was gone. It would be nice to know how these .pth files are involved in
> extending t
.
That was the case here too! Deleted my setuptools.pth and the "problem"
was gone. It would be nice to know how these .pth files are involved in
extending the 'sys.path[]'. Who does that and how? Any good reference on
that?
--
--gv
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Jan 9, 2015 at 6:14 AM, Gisle Vanem wrote:
> Why are these listed twice with different casing? One
> would assume that Python on Win32 would be case-insensitive.
> Some .pth-file to blame here?
I checked my own Python 2.7 installation and discovered that I have
the same problem, although
%% p) for (i,p) in
enumerate(sys.path)]" | sort --ignore-case
which produces:
f:\Documents and Settings\Gisle
Vanem\Programdata\Python\Python27\site-packages
f:\windows\system32\python27.zip<< !! doesn't exist, but okay.
G:\Programfiler\Python27
g:\Programfiler\Py
Idiot that I am...I was not calling the script with the full path !
Thanks for your help
--
https://mail.python.org/mailman/listinfo/python-list
>
> import sys
> import os
> from os.path import *
>
> scriptpath=os.path.dirname(sys.argv[0])
> otherscriptspath=printerpath.replace("scripts","otherscripts")
> sys.path.append(otherscriptspath)
>
> from AuditUpdate import *
Well, adding a path
1 - 100 of 336 matches
Mail list logo
