On 09/01/2008, Steve Holden [EMAIL PROTECTED] wrote:
The idea that users would /program their own computers/ was totally
alien to the Windows mindset.
Actually, the alien idea is that more than one person would use the
same (Windows) computer. Not surprising as these were *personal*
computers.
Reed O'Brien wrote:
On Jan 9, 2008, at 1:48 AM, Jeroen Ruigrok van der Werven wrote:
-On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote:
Python's _winreg module and pywin32 expose several functions to
get the paths from the registry but I don't think it has a simple
function
Jeroen Ruigrok van der Werven wrote:
-On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote:
Python's _winreg module and pywin32 expose several functions to get the
paths from the registry but I don't think it has a simple function like
get_mydocuments().
Careful with the name
Nick Coghlan wrote:
Jeroen Ruigrok van der Werven wrote:
-On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote:
Python's _winreg module and pywin32 expose several functions to get the
paths from the registry but I don't think it has a simple function like
On 09/01/2008, Michael Foord [EMAIL PROTECTED] wrote:
Note today's Coding Horror blog entry: Don't Pollute User Space
http://www.codinghorror.com/blog/archives/001032.html
Keep your dirty, filthy paws out of my personal user space!
:-) Absolutely
[...]
If applications need to store shared
On Jan 9, 2008, at 1:48 AM, Jeroen Ruigrok van der Werven wrote:
-On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote:
Python's _winreg module and pywin32 expose several functions to
get the
paths from the registry but I don't think it has a simple function
like
Paul Moore wrote:
On 09/01/2008, Michael Foord [EMAIL PROTECTED] wrote:
Note today's Coding Horror blog entry: Don't Pollute User Space
http://www.codinghorror.com/blog/archives/001032.html
Keep your dirty, filthy paws out of my personal user space!
:-) Absolutely
[...]
On 09/01/2008, Michael Foord [EMAIL PROTECTED] wrote:
Only because Windows XP uses a stupidly long path with spaces in it.
It's not actually *hard* to navigate manually to these directories.
The directories are also hidden. That does make it hard to navigate
there. I know you can un-hide hidden
Jeroen Ruigrok van der Werven wrote:
Careful with the name though. Microsoft Windows Vista did away with 'My
Documents Settings'. It is now C:\Users.
So you get:
C:\Users\name\AppData\Local\(former Local Settings\Application Data)
C:\Users\name\AppData\Roaming\ (former Application
Paul Moore wrote:
The directories are also hidden. That does make it hard to navigate
there. I know you can un-hide hidden files, but I view the hidden
attribute as useful - just badly misused in this case, unless you
assume that these directories are intended to be left alone by the
user.
On 09/01/2008, Christian Heimes [EMAIL PROTECTED] wrote:
It's not an issue for experienced users. For the rest we can put a link
in the start menu under Python 2.5 which opens a new explorer with the
user package directory.
Um, I'm an experienced user and it's an issue for me...
The problem
Paul Moore wrote:
If you are suggesting that a file intended to be viewed/edited by a
user manually should go in AppData, then please be explicit. We can
then argue the concrete issues, rather than just theoretical
principles.
I'm frustrated as well. Neither AppData nor MyDocuments fulfill
On 09/01/2008, Christian Heimes [EMAIL PROTECTED] wrote:
Paul Moore wrote:
If you are suggesting that a file intended to be viewed/edited by a
user manually should go in AppData, then please be explicit. We can
then argue the concrete issues, rather than just theoretical
principles.
I'm
Paul Moore wrote:
[...]
No matter how you cut it, Windows isn't designed for per-user
installable programs. Maybe a per-user site-packages just isn't
appropriate on Windows.
This reminds me of the early days of Microsoft Terminal Service (read:
X Window done wrong fifteen years later), when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 7, 2008, at 5:49 PM, Tristan Seligmann wrote:
In that case how about:
~/.local/lib/pythonX.Y/site-packages
or:
~/local/lib/pythonX.Y/site-packages
I believe both of these locations are already in use by various
systems
/ people,
On 08/01/2008, Christian Heimes [EMAIL PROTECTED] wrote:
Paul Moore wrote:
What would be used on Windows? It's likely to be of marginal use on
Windows, but an appropriate equivalent should be defined. Possibly
just replace ~ with %USERPROFILE%. I'd argue against anything under
%APPDATA%
Paul Moore wrote:
Not My Documents, please! That's for documents, not configuration.
%USERPROFILE% is actually where most other applications put stuff. The
alternative would be %HOMEDRIVE%%HOMEPATH% which is what
os.path.expanduser uses.
On mys system only one application has put
Paul Moore wrote:
Not My Documents, please! That's for documents, not configuration.
%USERPROFILE% is actually where most other applications put stuff. The
alternative would be %HOMEDRIVE%%HOMEPATH% which is what
os.path.expanduser uses.
-On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote:
Python's _winreg module and pywin32 expose several functions to get the
paths from the registry but I don't think it has a simple function like
get_mydocuments().
Careful with the name though. Microsoft Windows Vista did away with
On Sun, Jan 06, 2008 at 04:23:59PM -0800, Guido van Rossum wrote:
I don't want py or python to be
part of the stdlib package namespace. *If* (part of) the stdlib has to
live under a single distinguished name, pick something like std or
core. When I'm using Python I already know I'm using
On 2008-01-07 14:57, Fred Drake wrote:
On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote:
Next, we add a per-user site-packages directory to the standard
sys.path, and then we could get rid of most of the setuptools
import and sys.path hackery, making it a lot cleaner.
PYTHONPATH already
On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote:
Next, we add a per-user site-packages directory to the standard
sys.path, and then we could get rid of most of the setuptools
import and sys.path hackery, making it a lot cleaner.
PYTHONPATH already provides this functionality. I see no need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
We could easily resolve that issue, if we add a per-user site-packages
dir to sys.path in site.py (this is already done for Macs).
+1. I've advocated that for years.
- -Barry
-BEGIN PGP
On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
We could easily resolve that issue, if we add a per-user site-packages
dir to sys.path in site.py (this is already done for Macs).
+1. I've advocated that for years.
I'm not sure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote:
On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
We could easily resolve that issue, if we add a per-user site-
packages
dir to
On 2008-01-07 17:24, Barry Warsaw wrote:
On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote:
On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
We could easily resolve that issue, if we add a per-user site-packages
dir to sys.path
At 01:48 PM 1/7/2008 +0100, M.-A. Lemburg wrote:
I also don't like the import mechanism hackery that's being
used in setuptools to get namespace packages working.
I believe you're mistaken: there is no import mechanism hackery in
pkg_resources. (__path__ is a documented *hook*, not a hack, and
At 03:01 PM 1/7/2008 +0100, M.-A. Lemburg wrote:
On 2008-01-07 14:57, Fred Drake wrote:
On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote:
Next, we add a per-user site-packages directory to the standard
sys.path, and then we could get rid of most of the setuptools
import and sys.path
At 11:24 AM 1/7/2008 -0500, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote:
On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
We could easily resolve that
On Jan 7, 2008 12:19 PM, Brett Cannon [EMAIL PROTECTED] wrote:
On Jan 6, 2008 8:28 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 6, 2008 7:23 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote:
Regarding using common words, either the
On Jan 7, 2008 12:40 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 7, 2008 12:19 PM, Brett Cannon [EMAIL PROTECTED] wrote:
On Jan 6, 2008 8:28 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 6, 2008 7:23 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:23 PM 1/6/2008 -0800,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 7, 2008, at 11:37 AM, Phillip J. Eby wrote:
Python automatically adds ~/.python/site-packages to sys.path; this
is
added /before/ the system site-packages file. An open question is
whether it needs to go at the front of the list. It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 7, 2008, at 11:30 AM, M.-A. Lemburg wrote:
Open question: should we add yet another environment variable to
control
this? It's pretty typical for apps to expose such a thing so that
the
base directory (e.g. ~/.python) can be moved.
On Jan 7, 2008, at 3:56 PM, Brett Cannon wrote:
OK. So an html package could have htmllib for its __init__ (or
html.lib), and then have html.entities and html.parser for
htmlentitydefs and HTMLParser, respectively.
Actually, I'd be inclined not to have both HTMLParser and htmllib
(regardless
And then extend this to any other
package that we consider creating? Otherwise leave it out? How would
that follow for sqlite since that is not going to get any shorter
thanks to a package? Should it still go into the package for
organizational purposes?
If you're asking me, the
On 07/01/2008, Raymond Hettinger [EMAIL PROTECTED] wrote:
It is my hope that there will be a great deal of restraint in the effort to
group modules into
packages in Py3.0.
+1
The best existing indicator we have is the organization of the docs for the
standard library.
I, for one, have a
At 05:24 PM 1/7/2008 -0500, Raymond Hettinger wrote:
The best existing indicator we have is the organization of the docs
for the standard library. I, for one, have a hell of a difficult
time finding modules via the organized table of contents in the
Library Reference. Instead, I always go the
* Barry Warsaw [EMAIL PROTECTED] [2008-01-07 16:01:42 -0500]:
On Jan 7, 2008, at 11:37 AM, Phillip J. Eby wrote:
Python automatically adds ~/.python/site-packages to sys.path; this
is
added /before/ the system site-packages file. An open question is
whether it needs to go at the
On 07/01/2008, Tristan Seligmann [EMAIL PROTECTED] wrote:
D'oh, yes of course. So make that:
~/.python/lib/pythonX.Y/site-packages
In that case how about:
~/.local/lib/pythonX.Y/site-packages
or:
~/local/lib/pythonX.Y/site-packages
What would be used on Windows? It's likely to be
The best existing indicator we have is the organization of the docs for
the standard library. I, for one, have a hell of a difficult time finding
modules via the organized table of contents in the Library Reference.
Instead, I always go the the Global Module Index where the somewhat flat
namespace
On Jan 7, 2008 12:56 PM, Brett Cannon [EMAIL PROTECTED] wrote:
OK. So an html package could have htmllib for its __init__ (or
html.lib), and then have html.entities and html.parser for
htmlentitydefs and HTMLParser, respectively.
I'd be very reluctant to have more asymmetric packages like os
Paul Moore wrote:
What would be used on Windows? It's likely to be of marginal use on
Windows, but an appropriate equivalent should be defined. Possibly
just replace ~ with %USERPROFILE%. I'd argue against anything under
%APPDATA% as that directory is hidden.
No, we shouldn't mess with the
On Jan 7, 2008 3:47 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Jan 7, 2008 12:56 PM, Brett Cannon [EMAIL PROTECTED] wrote:
OK. So an html package could have htmllib for its __init__ (or
html.lib), and then have html.entities and html.parser for
htmlentitydefs and HTMLParser,
On Jan 7, 2008 2:24 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
And then extend this to any other
package that we consider creating? Otherwise leave it out? How would
that follow for sqlite since that is not going to get any shorter
thanks to a package? Should it still go into the
Hello!
We are discussing name space packages on the stdlib reorg list. For
Python 3.0 we plan to organize the packages by purpose, e.g. put all
database related packages like sqlite and shelve in a 'databases' name
space.
Of course we want to have the name spaces extensible by 3rd party
On Jan 6, 2008 8:33 AM, Christian Heimes [EMAIL PROTECTED] wrote:
* PJE: Does pkg_resource have an easy way to overwrite a package in a
name space package? E.g. an user wants to overwrite Python's
databases.sqlite with a newer version of sqlite. Can he simply do it by
inserting a package into
Steven Bethard wrote:
Do we really want to encourage this? Wouldn't that just introduce
more pyxml-like nightmares? I've been bitten way too many times by
pyxml overwriting the regular xml package and causing version
incompatibilities. I'd hate for this kind of thing to become common
On Jan 6, 2008 11:34 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
Do we really want to encourage this? Wouldn't that just introduce
more pyxml-like nightmares? I've been bitten way too many times by
pyxml overwriting the regular xml package and causing version
At 07:34 PM 1/6/2008 +0100, Christian Heimes wrote:
Steven Bethard wrote:
Do we really want to encourage this? Wouldn't that just introduce
more pyxml-like nightmares? I've been bitten way too many times by
pyxml overwriting the regular xml package and causing version
incompatibilities.
At 04:33 PM 1/6/2008 +0100, Christian Heimes wrote:
Hello!
We are discussing name space packages on the stdlib reorg list. For
Python 3.0 we plan to organize the packages by purpose, e.g. put all
database related packages like sqlite and shelve in a 'databases' name
space.
Of course we want to
On 06/01/2008, Steven Bethard [EMAIL PROTECTED] wrote:
What concerned me was your comment:
E.g. an user wants to overwrite Python's
databases.sqlite with a newer version of sqlite
Maybe the situation is different here, but having someone installing a
different version of sqlite
At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote:
Maybe the situation is different here, but having someone installing a
different version of sqlite behind my back makes me nervous.
Er, someone who? Behind whose back? I'm quite confused by what it
is that's making you nervous.
Do you worry
On Jan 6, 2008 1:07 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote:
Maybe the situation is different here, but having someone installing a
different version of sqlite behind my back makes me nervous.
Er, someone who? Behind whose back? I'm quite
On Jan 6, 2008 2:01 PM, Steven Bethard [EMAIL PROTECTED] wrote:
On Jan 6, 2008 1:07 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote:
Maybe the situation is different here, but having someone installing a
different version of sqlite behind my back
On 06/01/2008, Brett Cannon [EMAIL PROTECTED] wrote:
My question becomes whether we want to allow something like this even
if we explicitly state people should not use this mechanism to
override pre-existing modules. Do we want people tossing stuff into
the 'databases' package, or should the
On Sun, Jan 06, 2008 at 11:12:43PM +, Paul Moore wrote:
If we want a guaranteed-stdlib package form, we should probably have
a top-level package, std or whatever.
py.
That notion has, I believe,
been shot down before (no time to look up references now).
Mr Van Rossum has spoken
At 03:01 PM 1/6/2008 -0700, Steven Bethard wrote:
Note that this all happens behind my back because I didn't know that
pyxml would be replacing pyexpat in such a way that would cause this
crash. In fact, I didn't even know that pyxml was installing pyexpat.
Ah -- so this is 100% orthogonal to
On Jan 6, 2008 3:28 PM, Oleg Broytmann [EMAIL PROTECTED] wrote:
Now I think - if we don't want a separate Python's top-level namespace
may be we should think about a separate top-level non-Python's (3rd
parties') namespace? With it we could have database.sqlite (Python's
sqlite) and
At 02:10 PM 1/6/2008 -0800, Brett Cannon wrote:
My question becomes whether we want to allow something like this even
if we explicitly state people should not use this mechanism to
override pre-existing modules. Do we want people tossing stuff into
the 'databases' package, or should the packages
On Jan 6, 2008 3:35 PM, Jeffrey Yasskin [EMAIL PROTECTED] wrote:
On Jan 6, 2008 3:28 PM, Oleg Broytmann [EMAIL PROTECTED] wrote:
Now I think - if we don't want a separate Python's top-level namespace
may be we should think about a separate top-level non-Python's (3rd
parties') namespace?
Phillip J. Eby wrote:
This is actually an excellent point, given that the actual intended
use of namespace packages is to allow an *organization* to control a
namespace: e.g. zope.* and zc.* packages, osaf.* packages,
etc. Using names that have meaning (like email or databases)
sort of
On Jan 6, 2008 4:10 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
This is actually an excellent point, given that the actual intended
use of namespace packages is to allow an *organization* to control a
namespace: e.g. zope.* and zc.* packages, osaf.* packages,
etc.
On Jan 6, 2008, at 6:28 PM, Oleg Broytmann wrote:
On Sun, Jan 06, 2008 at 11:12:43PM +, Paul Moore wrote:
If we want a guaranteed-stdlib package form, we should probably
have
a top-level package, std or whatever.
py.
That notion has, I believe,
been shot down before (no time to
At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote:
Regarding using common words, either the stdlib grabs these, or
*nobody* gets to use them (for fear of conflicting with some other 3rd
party package grabbing the same).
This isn't quite true; a standalone Python application that isn't
On Jan 6, 2008 7:23 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote:
Regarding using common words, either the stdlib grabs these, or
*nobody* gets to use them (for fear of conflicting with some other 3rd
party package grabbing the same).
This
65 matches
Mail list logo
