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,
>> 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 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
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
software.
69 matches
Mail list logo
