On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix
Glyph Lefkowitz wrote:
I'd say that since ~/Library/Python is already used, there's no
particular reason to add a new ~/Library/Preferences/Python location.
I think the reason for separating out Preferences is so
that you can install a new version of a library or application
without losing
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you
On Sun, 01 Aug 2010 17:22:55 +0200
Éric Araujo mer...@netwok.org wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
Putting .pydistutils.cfg
On 02 Aug, 2010,at 11:48 AM, Michael Foord fuzzy...@voidspace.org.uk wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo
On 02/08/2010 11:48, Ronald Oussoren wrote:
On 02 Aug, 2010,at 11:48 AM, Michael Foord fuzzy...@voidspace.org.uk
wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug,
On 02/08/2010 11:48, Ronald Oussoren wrote:
On 02 Aug, 2010,at 11:48 AM, Michael Foord fuzzy...@voidspace.org.uk
wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug,
On 02 Aug, 2010,at 01:00 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:
The only apple one that is actually used is the .CFUserTextEncoding
file, I have an .Xcode in my home as well but that is empty and last
updated in 2007. AFAIK current versions of Xcode store preferences in
On 02/08/2010 14:34, Ronald Oussoren wrote:
On 02 Aug, 2010,at 01:00 PM, Michael Foord fuzzy...@voidspace.org.uk
wrote:
The only apple one that is actually used is the .CFUserTextEncoding
file, I have an .Xcode in my home as well but that is empty and last
updated in 2007. AFAIK current
On 02/08/2010 14:34, Ronald Oussoren wrote:
On 02 Aug, 2010,at 01:00 PM, Michael Foord fuzzy...@voidspace.org.uk
wrote:
The only apple one that is actually used is the .CFUserTextEncoding
file, I have an .Xcode in my home as well but that is empty and last
updated in 2007. AFAIK current
(Ronald, the text version of your message was very difficult to sort
through and read, because all of the quoting information was lost.
Just thought you'd want to know.)
What I hear Glyph saying is that we should support looking in *both*
locations for configuration info on OSX, and I don't see a
On 02/08/2010 15:24, R. David Murray wrote:
(Ronald, the text version of your message was very difficult to sort
through and read, because all of the quoting information was lost.
Just thought you'd want to know.)
What I hear Glyph saying is that we should support looking in *both*
locations
On 2 Aug, 2010, at 16:24, R. David Murray wrote:
(Ronald, the text version of your message was very difficult to sort
through and read, because all of the quoting information was lost.
Just thought you'd want to know.)
I'll stop using the mobile-me webmail client for lists, it seems to mess
Michael Foord fuzzy...@voidspace.org.uk writes:
I would be interested in hearing from other Mac users as to where they
would look for configuration files for command line tools - in ~ or in
~/Library/Preferences?
My primary personal machine has been OSX for years now, and as someone
who lives
In article 4c56d814.4030...@voidspace.org.uk,
Michael Foord fuzzy...@voidspace.org.uk wrote:
Ronald was wrong when he said that the only configuration file in ~ used
by the Mac itself is .CFUserTextEncoding. Terminal (the Mac OS X command
line) has a user editable config file which it stores
On 31 Jul, 2010, at 13:57, Michael Foord wrote:
On 31/07/2010 12:46, Michael Foord wrote:
[snip...]
If PEP 376 goes ahead then we could keep the user plugin
I meant keep the user config file.
Speaking of which... Your documentation says it's named ~/unittest.cfg, could
you make this a
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory
On Sun, 01 Aug 2010 17:22:55 +0200, mer...@netwok.org wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
Putting .pydistutils.cfg .pypirc
On 01/08/2010 18:38, R. David Murray wrote:
On Sun, 01 Aug 2010 17:22:55 +0200,mer...@netwok.org wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
2010/7/31 David Cournapeau courn...@gmail.com:
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how
to get the
On 31/07/2010 01:51, David Cournapeau wrote:
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how
to get the
On 31/07/2010 12:46, Michael Foord wrote:
[snip...]
If PEP 376 goes ahead then we could keep the user plugin
I meant keep the user config file.
Michael
and use the PEP 376 metadata, in concert with a user config file, to
discover all plugins *available*. A plugins subcommand could then
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
...
Installation of plugins would still be done through the standard
distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would
be fine with this.)
Note that the PEP 376 implementation is mainly
On 31/07/2010 17:22, Tarek Ziadé wrote:
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
...
Installation of plugins would still be done through the standard
distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would
be fine with this.)
Note that the PEP 376 implementation is mainly done in pkgutil. A
custom version lives in distutils2 but
when ready, will be pushed independently in pkgutil
Ok. It would be helpful for unittest2 (the backport) if it was *still*
available in distutils2 even after the merge into pkgutil (for
On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
...
The Plugin Class
A sometimes-more-convenient way of creating plugins is to subclass the
``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will
auto-instantiate the plugin
On 30/07/2010 11:09, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
...
The Plugin Class
A sometimes-more-convenient way of creating plugins is to subclass the
``unittest2.events.Plugin`` class. By default subclassing
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how
to get the prototype) on my blog:
http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186
Michael
On 29 July 2010 23:55,
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:
I'm going to read your blog entry on the topic to evaluate it properly
though:
https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
and-the-extensions-package/
Very interesting. For Mailman 3, I have YAPS (yet another
On 30/07/2010 15:04, Barry Warsaw wrote:
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:
I'm going to read your blog entry on the topic to evaluate it properly
though:
https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
and-the-extensions-package/
Very
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw ba...@python.org wrote:
..
* Registration - How do third party plugins declare themselves to exist, and
be enabled? Part of this seems to me to include interface declarations
too. Is installation of the plugin enough to register it? How do end
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw ba...@python.org wrote:
You guys should definitely write up a plugin PEP!
I am all for it, I am pretty sure we can come up with a generic tool
that can be useful for many packages in the stdlib
Starting this...
--
Tarek Ziadé | http://ziade.org
This is my first post to python-dev, so for those who might not know
me, I'm the author of Pro Django and more recently, Pro Python.
I haven't looked at the plugin landscape in a while, but I was very
disappointed the last time I looked at how complex typical systems
were in this regard. There
On Fri, Jul 30, 2010 at 4:34 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
...
Again I think the *needs* of unittest and distutils are different, so I
wonder if a single system can usefully suit both our needs (let alone
universally support other systems). Definitely an area worth
On 30/07/2010 15:37, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsawba...@python.org wrote:
..
* Registration - How do third party plugins declare themselves to exist, and
be enabled? Part of this seems to me to include interface declarations
too. Is installation of
On 30/07/2010 15:41, Marty Alchin wrote:
This is my first post to python-dev, so for those who might not know
me, I'm the author of Pro Django and more recently, Pro Python.
I haven't looked at the plugin landscape in a while, but I was very
disappointed the last time I looked at how complex
Le 30/07/2010 17:04, Michael Foord a écrit :
There is no type checking or interface requirements in my plugin
proposal for unittest. It is essentially an event based system.
Event-based sounds good. unittest2 does have an interface IMO:
configuration loading, plugin registration/activation,
On 30/07/2010 16:28, Éric Araujo wrote:
Le 30/07/2010 17:04, Michael Foord a écrit :
There is no type checking or interface requirements in my plugin
proposal for unittest. It is essentially an event based system.
Event-based sounds good. unittest2 does have an interface IMO:
It has an API, but the plugins are not interface based (so interface
requirements don't need to be part of the plugin system).
Oh, I see. With duck-typing and ABCs, I don’t make a difference between
protocols and interfaces in my head :) Also, the I in API does mean
interface, but not imply
On Jul 30, 2010, at 6:23 AM, Michael Foord wrote:
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how to
get the prototype) on my blog:
On Fri, Jul 30, 2010 at 5:54 PM, Éric Araujo mer...@netwok.org wrote:
It has an API, but the plugins are not interface based (so interface
requirements don't need to be part of the plugin system).
Oh, I see. With duck-typing and ABCs, I don’t make a difference between
protocols and interfaces
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
Automatic discoverability, a-la setuptools entry points, is not
without its problems though. Tarek outlines some of these in a more
recent blog post:
FWIW, it's not discovery that's the problem, but configuring *which*
plugins you wish to
On 30/07/2010 21:56, P.J. Eby wrote:
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
Automatic discoverability, a-la setuptools entry points, is not
without its problems though. Tarek outlines some of these in a more
recent blog post:
FWIW, it's not discovery that's the problem, but
At 04:37 PM 7/30/2010 +0200, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw ba...@python.org wrote:
..
* Registration - How do third party plugins declare themselves to
exist, and
be enabled? Part of this seems to me to include interface declarations
too. Is
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how
to get the prototype) on my blog:
On Sat, Jul 31, 2010 at 12:34 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Explicit registration over implicit registration by subclassing is an
interesting discussion, but I like the simplicity provided by just
subclassing.
Note that ABCs are deliberately designed to let *users* choose
Hello all,
My apologies in advance if email mangles whitespace in the code
examples. I can reformulate as a PEP if that is deemed useful and this
document can be found online at:
http://hg.python.org/unittest2/file/tip/description.txt
(Please excuse errors and omissions - but do feel
Damn, the email was truncated. Probably my fault. The part missed off is:
Not Yet Implemented
===
Except where noted, everything in this document is already working in
the prototype. There are a few open issues and things still to be
implemented.
Certain event attributes
50 matches
Mail list logo
