Mailman 3 PYTHON3PATH - Python-Dev

newer
3.1.2 / 2.6.5 maintenance releases?

PYTHON3PATH

R. David Murray

13 Jan 2010 13 Jan '10

5:24 p.m.

Please review issue 2375 [1], which is an enhancement request to add a PYTHON3PATH environment variable. Because we have elected to have both a python and a python3 command, I think this is an issue worth thinking about carefully to make sure we are serving the Python user community and easing the transition to python3. It could be that "use virtualenv" is the best answer, but I feel we should think about it carefully to make sure that is really true. [1] http://bugs.python.org/issue2375 -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls

Show replies by date

Guido van Rossum

13 Jan 13 Jan

5:31 p.m.

Somehow the bug site doesn't load for me right now, but I'm -1 on this. There are maybe a dozen PYTHON... variables -- we really shouldn't try to add PYTHON3 variants for all of them. Specifically for PYTHONPATH, I feel that its use is always a short-time or localized hack, not something you set in your .profile nd forget about it (forgetting about it inparticular often leads to unnecessary debugging pain later). The better approaches are based on site-packages, wrapper scripts, virtualenv, etc. --Guido On Wed, Jan 13, 2010 at 9:24 AM, R. David Murray wrote:

...

Please review issue 2375 [1], which is an enhancement request to add a PYTHON3PATH environment variable. Because we have elected to have both a python and a python3 command, I think this is an issue worth thinking about carefully to make sure we are serving the Python user community and easing the transition to python3. It could be that "use virtualenv" is the best answer, but I feel we should think about it carefully to make sure that is really true.

[1] http://bugs.python.org/issue2375

-- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

Ralf Schmitt

5:55 p.m.

Guido van Rossum writes:

...

Somehow the bug site doesn't load for me right now, but I'm -1 on this. There are maybe a dozen PYTHON... variables -- we really shouldn't try to add PYTHON3 variants for all of them.

Specifically for PYTHONPATH, I feel that its use is always a short-time or localized hack, not something you set in your .profile nd forget about it (forgetting about it inparticular often leads to unnecessary debugging pain later). The better approaches are based on site-packages, wrapper scripts, virtualenv, etc.

then at least remove them completely from python3, so one can use them for his python 2 installation. Otherwise it will stump on some innocent python 3 program (and cause unnecessary debugging pain).

Ralf Schmitt

5:40 p.m.

"R. David Murray" writes:

...

Please review issue 2375 [1], which is an enhancement request to add a PYTHON3PATH environment variable. Because we have elected to have both a python and a python3 command, I think this is an issue worth thinking about carefully to make sure we are serving the Python user community and easing the transition to python3. It could be that "use virtualenv" is the best answer, but I feel we should think about it carefully to make sure that is really true.

[1] http://bugs.python.org/issue2375

The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier. - Ralf

Steven Bethard

5:57 p.m.

On Wed, Jan 13, 2010 at 9:40 AM, Ralf Schmitt wrote:

...

"R. David Murray" writes:

...
Please review issue 2375 [1], which is an enhancement request to add a PYTHON3PATH environment variable. Because we have elected to have both a python and a python3 command, I think this is an issue worth thinking about carefully to make sure we are serving the Python user community and easing the transition to python3. It could be that "use virtualenv" is the best answer, but I feel we should think about it carefully to make sure that is really true.

[1] http://bugs.python.org/issue2375

The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier.

How complicated is your PYTHONSTARTUP file? My suspicion is that you could easily write it to work for both Python 2.X and 3.X. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

Ralf Schmitt

6:03 p.m.

Steven Bethard writes:

...

How complicated is your PYTHONSTARTUP file? My suspicion is that you could easily write it to work for both Python 2.X and 3.X.

sure. that's exactly what I did. My point is that sharing those environment variables will cause pain for some people.

ssteinerX＠gmail.com

5:57 p.m.

On Jan 13, 2010, at 12:40 PM, Ralf Schmitt wrote:

...

"R. David Murray" writes:

...
Please review issue 2375 [1], which is an enhancement request to add a PYTHON3PATH environment variable. Because we have elected to have both a python and a python3 command, I think this is an issue worth thinking about carefully to make sure we are serving the Python user community and easing the transition to python3. It could be that "use virtualenv" is the best answer, but I feel we should think about it carefully to make sure that is really true.

[1] http://bugs.python.org/issue2375

The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier.

Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely. Python 2 will continue to run as it has, and better solutions will emerge for Python 3 development. Beats the heck out of making a whole duplicate set for PYTHON3BLAHBLAH, yuck! S

Guido van Rossum

6:07 p.m.

On Wed, Jan 13, 2010 at 9:57 AM, ssteinerX@gmail.com > Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely. -1. They have their use, but more in controlled situations. If you have "global" env vars that you only want to use with Python 2.x, write a wrapper for Python 3 that invokes it with -E. -- --Guido van Rossum (python.org/~guido)

Nick Coghlan

9:43 p.m.

Guido van Rossum wrote:

...

On Wed, Jan 13, 2010 at 9:57 AM, ssteinerX@gmail.com > Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely.

-1. They have their use, but more in controlled situations. If you have "global" env vars that you only want to use with Python 2.x, write a wrapper for Python 3 that invokes it with -E.

Perhaps a case can be made for Python 3 to assume -E by default, with a -e option to enable reading of the environment variables? That way naive users could run Python3 without tripping over existing Python2 environment variables, while other tools could readily set up a different environment before launching Python3. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Guido van Rossum

10:45 p.m.

On Wed, Jan 13, 2010 at 1:43 PM, Nick Coghlan wrote:

...

Guido van Rossum wrote:

...
On Wed, Jan 13, 2010 at 9:57 AM, ssteinerX@gmail.com > Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely.

-1. They have their use, but more in controlled situations. If you have "global" env vars that you only want to use with Python 2.x, write a wrapper for Python 3 that invokes it with -E.

Perhaps a case can be made for Python 3 to assume -E by default, with a -e option to enable reading of the environment variables?

That way naive users could run Python3 without tripping over existing Python2 environment variables, while other tools could readily set up a different environment before launching Python3.

Naive users using environment variables? That's a recipe for disaster in any version! :-) -- --Guido van Rossum (python.org/~guido)

Jared Grubb

10:56 p.m.

On 13 Jan 2010, at 13:43, Nick Coghlan wrote:

...

Guido van Rossum wrote:

...
On Wed, Jan 13, 2010 at 9:57 AM, ssteinerX@gmail.com > Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely.

-1. They have their use, but more in controlled situations. If you have "global" env vars that you only want to use with Python 2.x, write a wrapper for Python 3 that invokes it with -E.

Perhaps a case can be made for Python 3 to assume -E by default, with a -e option to enable reading of the environment variables?

That way naive users could run Python3 without tripping over existing Python2 environment variables, while other tools could readily set up a different environment before launching Python3.

I raised a question about these PYTHON3* variables once before in a discussion about shebang lines: http://www.mailinglistarchive.com/python-dev@python.org/msg29500.html I'm not advocating them, but just wanted to make sure to bring up the shebang use case. Jared

M.-A. Lemburg

14 Jan 14 Jan

7:19 p.m.

Nick Coghlan wrote:

...

Guido van Rossum wrote:

...
On Wed, Jan 13, 2010 at 9:57 AM, ssteinerX@gmail.com > Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely.

-1. They have their use, but more in controlled situations. If you have "global" env vars that you only want to use with Python 2.x, write a wrapper for Python 3 that invokes it with -E.

Perhaps a case can be made for Python 3 to assume -E by default, with a -e option to enable reading of the environment variables?

That way naive users could run Python3 without tripping over existing Python2 environment variables, while other tools could readily set up a different environment before launching Python3.

Naive users won't have PYTHONPATH or any other Python environment variables setup. Really, if you know that you are going to run Python 3 instead of Python 2 or vice-versa it's easy enough to run . py3env.sh or . py2env.sh in order to setup your shell environment, much like you typically do when using virtual Python installations or work on different projects that require different setups. If you just want to separate Python 2 and 3 files, use the user site-packages dir which includes the Python version. More experienced users could also write their own environment switching sitecustomize.py or usercustomize.py. And then there's the hackery option for experts that love dirty tricks: add a .pth file which includes an "import mysetup" line to fix-up you path and other settings. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 14 2010)

...

...
...
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

Nick Coghlan

9:02 p.m.

M.-A. Lemburg wrote:

...

Nick Coghlan wrote:

...
Guido van Rossum wrote:

...
On Wed, Jan 13, 2010 at 9:57 AM, ssteinerX@gmail.com > Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely.

-1. They have their use, but more in controlled situations. If you have "global" env vars that you only want to use with Python 2.x, write a wrapper for Python 3 that invokes it with -E. Perhaps a case can be made for Python 3 to assume -E by default, with a -e option to enable reading of the environment variables?

That way naive users could run Python3 without tripping over existing Python2 environment variables, while other tools could readily set up a different environment before launching Python3.

Naive users won't have PYTHONPATH or any other Python environment variables setup.

I was actually thinking of the situation where the OS had a preinstalled Python 2 with a default PYTHONPATH setting and the user was playing with Python 3. However, I agree that that is a fairly unlikely scenario (since preinstalled Pythons tend not to rely on the environment variables and a user sophisticated enough to be playing with a new Python interpreter should be able to cope with a few environment variable conflicts anyway). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Michael Foord

9:09 p.m.

On 14/01/2010 21:02, Nick Coghlan wrote:

...

However, I agree that that is a fairly unlikely scenario (since preinstalled Pythons tend not to rely on the e Well, on the other hand I think that during the next few years it will be increasingly common for developers (and possibly users) to have Python 2 and Python 3 installed side-by-side.

Many libraries and applications may never make the jump to Python 3 and Python users may be using 'legacy' Python 2 code for many years to come. It will also become increasingly common for developers to be using Python 3 *primarily* and for Python 3 only libraries and applications to emerge. Whilst there are workarounds we *are* in a situation that Python 2 and Python 3 share environment variables for the location of libraries and executing code on startup, whilst at the same time they are largely incompatible and need separate library paths and startup code. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

Ralf Schmitt

9:25 p.m.

"M.-A. Lemburg" writes:

...

Naive users won't have PYTHONPATH or any other Python environment variables setup.

Really, if you know that you are going to run Python 3 instead of Python 2 or vice-versa it's easy enough to run

You don't even know that you're going to run python. I have 40 python scripts in my /usr/bin directory.

...

. py3env.sh or . py2env.sh

in order to setup your shell environment, much like you typically do when using virtual Python installations or work on different projects that require different setups.

No, thanks. I'd rather setup my shell environment in ~/.zshrc, once.

...

If you just want to separate Python 2 and 3 files, use the user site-packages dir which includes the Python version.

Both the bzr and mercurial wiki recommend setting PYTHONPATH in order to install those programs in a user's home directory. There are still people running python <2.6.

M.-A. Lemburg

9:51 p.m.

Ralf Schmitt wrote:

...

"M.-A. Lemburg" writes:

...
Naive users won't have PYTHONPATH or any other Python environment variables setup.

Really, if you know that you are going to run Python 3 instead of Python 2 or vice-versa it's easy enough to run

You don't even know that you're going to run python. I have 40 python scripts in my /usr/bin directory.

...
. py3env.sh or . py2env.sh

in order to setup your shell environment, much like you typically do when using virtual Python installations or work on different projects that require different setups.

No, thanks. I'd rather setup my shell environment in ~/.zshrc, once.

...
If you just want to separate Python 2 and 3 files, use the user site-packages dir which includes the Python version.

Both the bzr and mercurial wiki recommend setting PYTHONPATH in order to install those programs in a user's home directory. There are still people running python <2.6.

Note that you only need to have a different PYTHONPATH setups for Python 2.x/3.x if you plan to run code that: * is not installed in site-packages (most OS shipped code will be found in the resp. system site-packages/ dir) * is not installed in a user site-packages directory (user installed code will typically go there (*)) * uses modules/packages that come in two different versions (one for Python 2.x and one for 3.x) and use the same name for both versions * needs to work in both Python 2.x and 3.x (*) The method for installing code in user site-packages dir is running: python setup.py install --user instead of the standard python setup.py install which install to the system-wide site-packages. BTW: I guess the bzr and mercurial wikis will need to be updated accordingly - at least for users of Python >=2.6. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 14 2010)

...

...
...
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

Oleg Broytman

13 Jan 13 Jan

6:18 p.m.

On Wed, Jan 13, 2010 at 12:57:42PM -0500, ssteinerX@gmail.com wrote:

...

Or, how about just removing the antiquated use of environment variables

"antiquated"? You are kidding, aren't you?! Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Lennart Regebro

7:50 p.m.

On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt wrote:

...

The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier.

What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64

Oleg Broytman

8:08 p.m.

On Wed, Jan 13, 2010 at 08:50:59PM +0100, Lennart Regebro wrote:

...

What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-)

See http://phd.pp.ru/Software/dotfiles/init.py.html for an example. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Lennart Regebro

8:27 p.m.

On Wed, Jan 13, 2010 at 21:08, Oleg Broytman wrote:

...

On Wed, Jan 13, 2010 at 08:50:59PM +0100, Lennart Regebro wrote:

...
What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-)

See http://phd.pp.ru/Software/dotfiles/init.py.html for an example.

Cheese and fries! :-) Anyway, I don't see how this could pose any problems, because any user advanced enough to do these things will be advanced enough to understand what the problem is and fix it so it works under Python 3 too. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

Georg Brandl

16 Jan 16 Jan

8:05 p.m.

Am 13.01.2010 21:27, schrieb Lennart Regebro:

...

On Wed, Jan 13, 2010 at 21:08, Oleg Broytman wrote:

...
On Wed, Jan 13, 2010 at 08:50:59PM +0100, Lennart Regebro wrote:

...
What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-)

See http://phd.pp.ru/Software/dotfiles/init.py.html for an example.

Cheese and fries! :-)

Anyway, I don't see how this could pose any problems, because any user advanced enough to do these things will be advanced enough to understand what the problem is and fix it so it works under Python 3 too.

I'd propose adding a bit of text to the environment variables documentation, and especially about the needs of PYTHONSTARTUP files. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Ralf Schmitt

13 Jan 13 Jan

8:52 p.m.

Lennart Regebro writes:

...

On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt wrote:

...
The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier.

What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-)

hehe. tab completion: # -*- mode: python -*- # Last changed: 2009-12-23 22:25:15 by ralf import sys import os def initreadline(): try: import readline except ImportError: sys.stdout.write("Module readline not available.\n") return import rlcompleter readline.parse_and_bind("tab: complete") # Use tab for completions readline.parse_and_bind('tab: complete') # This forces readline to automatically print the above list when tab # completion is set to 'complete'. readline.parse_and_bind('set show-all-if-ambiguous on') # Bindings for incremental searches in the history. These searches # use the string typed so far on the command line and search # anything in the previous input history containing them. readline.parse_and_bind('"\C-r": reverse-search-history') readline.parse_and_bind('"\C-s": forward-search-history') history = os.path.expanduser("~/.pyhistory") if os.path.exists(history): readline.read_history_file(history) import atexit atexit.register(lambda: readline.write_history_file(history)) initreadline() del initreadline

Jeroen Ruigrok van der Werven

16 Jan 16 Jan

8:50 p.m.

-On [20100113 22:13], Ralf Schmitt (ralf@brainbot.com) wrote:

...

hehe. tab completion:

With bpython and ipython available, why would you even want to stick to the 'plain old' interactive interpreter? (Sorry to derail the discussion, but maybe there's more people that have not heard of either or both.) -- Jeroen Ruigrok van der Werven / asmodai イェルーンラウフロックヴァンデルウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B For ever, brother, hail and farewell...

Antoine Pitrou

8:57 p.m.

Jeroen Ruigrok van der Werven writes:

...

-On [20100113 22:13], Ralf Schmitt (ralf <at> brainbot.com) wrote:

...
hehe. tab completion:

With bpython and ipython available, why would you even want to stick to the 'plain old' interactive interpreter?

Why wouldn't we? There are probably many more people using the standard Python prompt than ipython.

Ben Finney

10:41 p.m.

Jeroen Ruigrok van der Werven writes:

...

-On [20100113 22:13], Ralf Schmitt (ralf@brainbot.com) wrote:

...
hehe. tab completion:

With bpython and ipython available, why would you even want to stick to the 'plain old' interactive interpreter?

Because those optional extras are not always available, whereas the standard interactive interpreter is always available with CPython distributions. -- \ “I fly Air Bizarre. You buy a combination one-way round-trip | `\ ticket. Leave any Monday, and they bring you back the previous | _o__) Friday. That way you still have the weekend.” —Steven Wright | Ben Finney

Nick Coghlan

17 Jan 17 Jan

12:22 a.m.

Ben Finney wrote:

...

Jeroen Ruigrok van der Werven writes:

...
-On [20100113 22:13], Ralf Schmitt (ralf@brainbot.com) wrote:

...
hehe. tab completion: With bpython and ipython available, why would you even want to stick to the 'plain old' interactive interpreter?

Because those optional extras are not always available, whereas the standard interactive interpreter is always available with CPython distributions.

I've never even contemplated the idea of installing 3rd party apps for the 4 current development builds (2.x trunk, 2.x maintenance, 3.x trunk, 3.x maintenance) on my home development machine. And of course work suffers from the problem of not being allowed to install arbitrary apps I downloaded from the internet without getting the licensing vetted for commercial acceptability. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

"Martin v. Löwis"

13 Jan 13 Jan

9:05 p.m.

Lennart Regebro wrote:

...

On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt wrote:

...
The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier.

What do you need to do in the PYTHONSTARTUP file?

I personally set up readline: set tab completion, and load the history of commands from the previous session. Of course, I don't know what Ralf uses it for. Regards, Martin

skip＠pobox.com

10:24 p.m.

Lennart> What do you need to do in the PYTHONSTARTUP file? Just reading off stuff from my own personal startup file... I use it for stuff I want available during interactive sessions: 1. Enable true division. 2. Conditionally define "help" from back in the days when there was no help builtin function. 3. Auto-save session (readline) history so I can easily recall commands across sessions. 4. Add other fake builtins ("like") or override behavior of some (like "dir") making them handier for interactive use. 5. autoload modules/symbols (pokes around in common modules from sys.excepthook function). Oh, and I've had no particular trouble keeping it working in Python 1, 2 or 3. Skip

5211

Age (days ago)

5215

Last active (days ago)

List overview

Download

27 comments

17 participants

participants (17)

"Martin v. Löwis"
Antoine Pitrou
Ben Finney
Georg Brandl
Guido van Rossum
Jared Grubb
Jeroen Ruigrok van der Werven
Lennart Regebro
M.-A. Lemburg
Michael Foord
Nick Coghlan
Oleg Broytman
R. David Murray
Ralf Schmitt
skip＠pobox.com
ssteinerX＠gmail.com
Steven Bethard

PYTHON3PATH

ssteinerX＠gmail.com

Oleg Broytman

Oleg Broytman

tags

participants (17)