Phillip J. Eby wrote:
> Sorry about that - as I said, __notified__ is very much an implicit
> thing in peak.util.imports.
>
> And I believe I've also mentioned a lot of times how hard it is to get
> this stuff right... :)
*hehe* Indeed, you did! I should have been warned. :)
> Congrats! Now a
At 04:40 AM 1/16/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > I guess it's not right then. ;-) Though I shouldn't make fun, since it
> > turns out that my code sketch was not a correct translation of
> > peak.util.imports. (See below.)
>
>*gr* I spent more than hour to find
Phillip J. Eby wrote:
> I guess it's not right then. ;-) Though I shouldn't make fun, since it
> turns out that my code sketch was not a correct translation of
> peak.util.imports. (See below.)
*gr* I spent more than hour to find my error ...
> That is, module.__notified__ has to be set *b
Bill Janssen wrote:
> Sure, but it's clearly where this should be on an OS X system, by
> default. And I'm sure there's a different "best place" on Windows
> (for instance, all of our accounts are network roaming accounts, and
> you don't want to put anything in ~). And there are probably various
> Bill Janssen wrote:
> > Good point, but I prefer ~/Library/Python to either of these.
>
> ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems.
> I *could* add yet another environment variable PYTHONUSERHOME to set the
> base path but I prefer not.
>
> Christian
Sure, but it
At 02:28 AM 1/16/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
> >> My code queues up new hooks while a sequence of hooks is processed. It
> >> makes sure that hooks for a parent aren't called in the middle of a
> >> child's hook
Bill Janssen wrote:
> Good point, but I prefer ~/Library/Python to either of these.
~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems.
I *could* add yet another environment variable PYTHONUSERHOME to set the
base path but I prefer not.
Christian
_
Phillip J. Eby wrote:
> At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
>> My code queues up new hooks while a sequence of hooks is processed. It
>> makes sure that hooks for a parent aren't called in the middle of a
>> child's hook chain.
>
> Notice that that's not necessary with the notific
Oleg Broytmann writes:
> On Wed, Jan 16, 2008 at 06:31:42AM +0900, Stephen J. Turnbull wrote:
> > I think both for UI reasons (given above) and for API reasons (given
> > by others) there should be a separate ~/SOMETHING/{bin,etc,lib,share}
> > hierarchy for user-specific packaged contents. I like
Oleg>Why not use GNU stow?
Thanks for the reference. I'd never heard of it before. I suspect our IT
folks may not have as well.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
At 02:19 PM 1/15/2008 -0800, Guido van Rossum wrote:
>While I have you, I've come across a need that I don't know how to do
>with GFs. Suppose I have a GF that implements some recursive function
>over container types, e.g. serialization or flattening. Now suppose
>I'd like to create *another* GF th
Oleg Broytmann writes:
> On Wed, Jan 16, 2008 at 06:31:42AM +0900, Stephen J. Turnbull wrote:
> > I think both for UI reasons (given above) and for API reasons (given
> > by others) there should be a separate ~/SOMETHING/{bin,etc,lib,share}
> > hierarchy for user-specific packaged contents. I
> Second, a "metaclass" to add a number of methods (or other attributes)
> to an existing class, using a convenient class notation:
I think this is similar to my "partial" classes:
http://pypi.python.org/pypi/partial
Regards,
Martin
___
Python-Dev mail
On Jan 15, 2008 2:08 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:51 PM 1/15/2008 -0800, Guido van Rossum wrote:
> >On Jan 15, 2008 1:27 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > > Second, a "metaclass" to add a number of methods (or other attributes)
> > > > to an existing cl
At 01:51 PM 1/15/2008 -0800, Guido van Rossum wrote:
>On Jan 15, 2008 1:27 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Second, a "metaclass" to add a number of methods (or other attributes)
> > > to an existing class, using a convenient class notation:
> >
> > I think this is similar to
At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
>My code queues up new hooks while a sequence of hooks is processed. It
>makes sure that hooks for a parent aren't called in the middle of a
>child's hook chain.
Notice that that's not necessary with the notification algorithm I
gave, since the
On Jan 15, 2008 1:27 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Second, a "metaclass" to add a number of methods (or other attributes)
> > to an existing class, using a convenient class notation:
>
> I think this is similar to my "partial" classes:
>
> http://pypi.python.org/pypi/partial
On Wed, Jan 16, 2008 at 06:31:42AM +0900, Stephen J. Turnbull wrote:
> I think both for UI reasons (given above) and for API reasons (given
> by others) there should be a separate ~/SOMETHING/{bin,etc,lib,share}
> hierarchy for user-specific packaged contents. I like ~/.local a
> little better tha
Oleg Broytmann writes:
>~/.python
To me, this strongly suggests user configuration files, not a place
where an app can store user-specific packages.
True, there are apps that store their stuff in such places, like most
GNOME apps. But they have no user-servicable parts (including config
fi
> Right now Python faces a lot of problems in the webhosting world because it's
> tedious to set up and maintain for the webhosting user since they often have
> to compile and install their own Python in their home directory.
I don't understand why they *have* to do that. I can believe they do
tha
Phillip J. Eby wrote:
> when_imported('a.b')(func_ab1)
> when_imported('a.b')(func_ab2)
>
> @when_imported('a')
> def func_a1(module_a):
> when_imported('a.b')(func_ab3)
> notify_module('a.b') # <- this is here to foil trivial
> implementations
>
> when_imported('a')(func_a2)
> notify_m
On Tue, Jan 15, 2008 at 02:34:02PM -0600, [EMAIL PROTECTED] wrote:
> Oleg>~/.python
> Oleg>~/.python/bin
> Oleg>~/.python/lib
> Oleg>~/.python/lib/python2.5
>
> The drawback of this approach is that it implies that Perl, Tcl, IPython,
> etc. belong in their own .wha
Guido van Rossum writes:
> I think it's useful to share these recipes,
But only to people who have demonstrated that they already know when,
why and how to monkeypatch on their own. Lisp's `defadvice' plays a
starring role in a number of my nightmares. Most recently, 15 minutes
ago.
Come to t
Oleg>~/.python
Oleg>~/.python/bin
Oleg>~/.python/lib
Oleg>~/.python/lib/python2.5
The drawback of this approach is that it implies that Perl, Tcl, IPython,
etc. belong in their own .whatever directory. The IT folks here at work do
things that way (though not in ho
Daniel> I use ~/local, with a layout analogous to /usr, ...
Ditto. Makes things nice and clear. I install stuff without becoming root
or polluting central directories.
Daniel> To those folks who favor creating ~/bin, ~/lib, ~/share, ad
Daniel> nauseum, I point out that non-hidden,
On Tue, Jan 15, 2008 at 12:11:37PM -0800, Daniel Arbuckle wrote:
> I use ~/local, with a layout analogous to /usr, all the time. It's not
> a standard, but in my experience it is by far the best solution to
> installing things in the home directory. It doesn't matter much
> whether you call it loca
On Tue, 15 Jan 2008 06:57:02 -0500, Kevin Jacobs wrote:
> On Jan 15, 2008 6:24 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jan 14, 2008 at 11:41:47PM +, Jon Ribbens wrote:
> > > It makes sense, but personally I have never heard before of ~/.local.
> > > Whereas ~/bin is somethin
On Jan 15, 2008 8:22 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> pypy has something that requires the base class to use a specific metaclass:
> https://codespeak.net/viewvc/pypy/dist/pypy/tool/pairtype.py?view=markup
That's no good for my particular use case.
--
--Guido van Rossum (home page
Guido van Rossum python.org> writes:
>
> I ran into the need of monkeypatching a large number of classes (for
> what I think are very good reasons and invented two new recipes.
> These don't depend on Py3k, and the second one actually works all the
> way back to Python 2.2. Neither of these allo
Guido van Rossum:
> I ran into the need of monkeypatching a large number of classes (for
> what I think are very good reasons :-) and invented two new recipes.
> These don't depend on Py3k, and the second one actually works all the
> way back to Python 2.2. Neither of these allows monkeypatching
>
At 10:10 PM 1/11/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > *sigh*. We seem to be getting further and further off course,
> > here. The more different you make the semantics of the system, the
> > harder it will be to verify that it's doing the right thing without
> > having r
[EMAIL PROTECTED] wrote:
> On 03:37 pm, [EMAIL PROTECTED] wrote:
>> I think it's useful to share these recipes, if only to to establish
>> whether they have been discovered before, or to decide whether they
>> are worthy of a place in the standard library. I didn't find any
>> relevant hits on the
On 03:37 pm, [EMAIL PROTECTED] wrote:
>I think it's useful to share these recipes, if only to to establish
>whether they have been discovered before, or to decide whether they
>are worthy of a place in the standard library. I didn't find any
>relevant hits on the ASPN Python cookbook.
>from impor
I ran into the need of monkeypatching a large number of classes (for
what I think are very good reasons :-) and invented two new recipes.
These don't depend on Py3k, and the second one actually works all the
way back to Python 2.2. Neither of these allows monkeypatching
built-in types like list. If
On Tue, Jan 15, 2008 at 01:21:46PM +0100, Christian Heimes wrote:
> It took me a while to find a reference to .local. It's part of the
> FreeDesktop.Org standards:
> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
The site only mentions $HOME/.local/share, there is no $HOME/
Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> Never heard of it either, would be completely baffled if caught unawares by
> it in the wild. Has anyone consulted with the LSB or a cross-platform
> filesystem layout guide to see what the recommended best-practice is?
It took me a while to find a refere
On Jan 15, 2008 6:24 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 14, 2008 at 11:41:47PM +, Jon Ribbens wrote:
> > It makes sense, but personally I have never heard before of ~/.local.
> > Whereas ~/bin is something I am quite familiar with.
>
> Me too. python-dev is the only
On Mon, Jan 14, 2008 at 11:41:47PM +, Jon Ribbens wrote:
> It makes sense, but personally I have never heard before of ~/.local.
> Whereas ~/bin is something I am quite familiar with.
Me too. python-dev is the only place I have heard of ~/.local. I have
been using Linux (different distribut
Jeroen Ruigrok van der Werven wrote:
> One thing I miss in this PEP and discussion is the point of view from a
> webhosting company and webhosting user.
>
> If the webhoster upgrades his hosting software and Python get updated by a
> revision (say 2.5 to 2.6) this would in the current case mean th
39 matches
Mail list logo
