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
>>>
At 10:47 AM 1/10/2008 +, Paul Moore wrote:
>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) com
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*
computer
-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
>
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"),
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
> > princip
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:
> 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 probl
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
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\\AppData\Local\(former Local Settings\Application Data)
> C:\Users\\AppData\Roaming\ (former Application Da
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 hid
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!
>>
>
> :-) Absolu
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
>> ge
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 sto
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
>>> ge
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
-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 wit
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.
http://msdn2.microsoft.com/en-us/library/bb762494(VS
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 configura
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
> > %
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
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,
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 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 lik
>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
>nam
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
* 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 t
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
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,
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
(regardle
-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
-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.
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
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,
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 stdlib grabs these, or
> > >*nobody* gets to use them (for fe
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 r
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.p
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, a
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
-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
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
-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 SIGN
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
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 a
On 2008-01-06 16:33, 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.
Regardless of whet
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
On 07/01/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> There seems to be a misunderstanding. This is *not* going to happen
> for standard library package names. I'm fine with inventing mechanisms
> to allow 3rd party packages to beo cobbled together from multiple
> contributions (it would see
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).
>
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
extensi
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 be
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,
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")
> s
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')
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 packag
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 us
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 t
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 sp
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
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 be
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
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 a
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 sql
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 wa
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
> > incompatibi
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 versi
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
> p
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
67 matches
Mail list logo
