date:20100802

Ron Adam writes:

 > Something that may be more useful, is a "no activity" search field
 > with choices of day, week, month, year, etc... and make the output
 > sortable on time without activity.

That's exactly what a sort on date of activity gives you, though, and
it can be from longest down.

Also, I think that most of the "date" fields actually allow ranges
(iirc something like "today - 1 year, today" works, I've never
actually used them), but I don't think this can be easily negated in
the stock Roundup.  What could be done though is something like
"created Jan 1 1970, today - 2 years AND open" to find bugs that have
been hanging fire for more than two years.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

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 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 (or %APPDATA% on win32 and
what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
is not the right directory for configuration files, as pointed in
http://bugs.python.org/issue7175

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.

~/Library/Python would be a good location on OSX, even if the 100% formally
correct location would be ~/Preferences/Python (at least of framework builds,
unix-style builds may want to follow the unix convention).

"100% formally" speaking, MacOS behaves like UNIX in many
ways.

Storing files in unix location will be confusing to many Mac users, Apple has
an explicitly documented convention for where to store files and dot-files in
the user's home directory aren't part of that convention.

An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is
that these locations are both logical for mac users and can be navigated to from the Finder
without resorting to typing the folder name in "Go -> Go to Folder".

Really? As a Mac user I have never edited (or even looked at) files in
~/Library. I would never think of going there for finding config files
to edit. However in my home directory I have:

.Xauthority
.Xcode
. CFUserTextEncoding - (an Apple encoding configuration for Core
Foundation)

.bash_profile
.cups
.dropbox
.dvdcss
.filezilla
.fontconfig
.hgrc
.idlerc
.ipython
.mono
.netbeans
.parallels_settings
.pypirc
.wingide3

My preference would be to follow this established and well used convention.

Michael

It's fine to have a mac-pathname-convention-following place for such data, but
please _also_ respect the UNIX-y version on the Mac. The only possible outcome
of python on the Mac respect only Mac pathnames is to have automation scripts
that work fine on BSD and Linux, but then break when you try to run them on a
Mac.

The stdlib should have APIs for locating common directories, although I must
admit that I haven't checked if it actually does have them. That way you can
write automation scripts that work anyware, not just on systems that look a lot
like Linux.

I've written a lot of scripts that had to follow platform conventions on a lot
of unix platforms, and those tended to require small changes for every new unix
flavor we encountered. Non-linux platforms also have filesystem hierarchy
standards, even though they are often not as detailed as the Linux ones and
most unix platforms don't have a user-base that is as vocal as the linux
packagers when software doesn't follow the conventions.

There is really no benefit to intentionally avoiding honoring the UNIX
conventions. (For another example, note that although Python resides in
/System/Library, on the mac, the thing that's in your $PATH when you're using a
terminal is the symlink in /usr/bin/python.)

Also, no, "~/Preferences" isn't the right place for it either; there's no such thing.
You probably meant "~/Library/Preferences". I'd say that since ~/Library/Python is
already used, there's no particular reason to add a new ~/Library/Preferences/Python location.
After all, if you really care a lot about platform conventions, you should put it in
~/Library/Preferences/org.python.distutils.plist, but I don't see what benefit that extra
complexity would have for anyone.

Your right, I meant ~/Library/Preferences, and I'd prefer ~/Library/Python for
the reason you meant. The actual format of the configuration files is not
prescribed in any way, and I'd by -1 on storing the preferences in a plist on
OSX because that is making live for programmers actively harder.

Ronald

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By acceptin

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On Sun, 01 Aug 2010 17:22:55 +0200
É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 and possibly
> other in the user home directory (or %APPDATA% on win32 and
> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
> is not the right directory for configuration files, as pointed in
> http://bugs.python.org/issue7175
> 
> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
> $XDG_CONFIG_HOME/python directory and put config files there.

+1

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1

On Mon, 02 Aug 2010 08:10:58 +0200
Georg Brandl  wrote:
> Thanks, Benjamin!  I'd also like to thank Martin and Ronald for the prompt
> binaries, and the folks of #python-dev for support.  RMing was a pleasant
> experience so far.

Are you already trying to lure other people into replacing you?


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

2010-08-02 Thread Ronald Oussoren

On 02 Aug, 2010,at 11:48 AM, Michael Foord  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 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 and possibly
other in the user home directory (or %APPDATA% on win32 and
what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
is not the right directory for configuration files, as pointed in
http://bugs.python.org/issue7175

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.

  
  ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).
  

"100% formally" speaking, MacOS behaves like UNIX in many ways.  

  
  Storing files in unix location will be confusing to many Mac users, Apple has an explicitly documented convention for where to store files and dot-files in the user's home directory aren't part of that convention.

An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is that these locations are both logical for mac users and can be navigated to from the Finder without resorting to typing the folder name in "Go -> Go to Folder".

  


Really? As a Mac user I have never edited (or even looked at) files in
~/Library. I would never think of going there for finding config files
to edit. However in my home directory I have:

    .Xauthority
    .Xcode
    .

CFUserTextEncoding  - (an Apple encoding configuration for Core
Foundation)
    .bash_profile
    .cups
    .dropbox
    .dvdcss
    .filezilla
    .fontconfig
    .hgrc
    .idlerc
    .ipython
    .mono
    .netbeans
    .parallels_settings
    .pypirc
    .wingide3

Actually that is just a small selection of the .config
files/directories in my home directory. It is certainly *a* standard
location for config files on the Mac, including some Apple software
(XCode) and Python applications. 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 ~/Library/Preferences.  Most of the other ones are ports of unix tools and store junk in the standard unix location for storing configuration.   Try edit one without resorting to the command-line, with a default configuration of the Finder you cannot even see these files (and that includes the File open dialog of tools like Text Edit)The reason you don't normally look in ~/Library/Preferences is that GUI tools on OSX have configuration screens for editing preferences and you don't have to edit them manually.  

My preference would  be to follow this established and well used
convention. My preference is still to use ~/Library/Python (or a subdirectory thereof) and filenames that don't start with a dot.Ronald___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 11:48, Ronald Oussoren wrote:

On 02 Aug, 2010,at 11:48 AM, Michael Foord
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 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)?

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.

"100% formally" speaking, MacOS behaves like UNIX in many
ways.

Really? As a Mac user I have never edited (or even looked at) files
in ~/Library. I would never think of going there for finding config
files to edit. However in my home directory I have:

.Xauthority
.Xcode
. CFUserTextEncoding - (an Apple encoding configuration for Core
Foundation)

.bash_profile
.cups
.dropbox
.dvdcss
.filezilla
.fontconfig
.hgrc
.idlerc
.ipython
.mono
.netbeans
.parallels_settings
.pypirc
.wingide3

Actually that is just a small selection of the .config
files/directories in my home directory. It is certainly *a* standard
location for config files on the Mac, including some Apple software
(XCode) and Python applications.
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
~/Library/Preferences. Most of the other ones are ports of unix tools
and store junk in the standard unix location for storing
configuration. Try edit one without resorting to the command-line,
with a default configuration of the Finder you cannot even see these
files (and that includes the File open dialog of tools like Text Edit)

The reason you don't normally look in ~/Library/Preferences is that
GUI tools on OSX have configuration screens for editing preferences
and you don't have to edit them manually.

Right, so what you are saying is that for user editable text config
files ~/Library/Preferences is *not* a convention - and in fact the unix
convention of dot files in the home directory is commonly used on the
Mac. :-)

Michael

My preference would be to follow this established and well used
convention.
My preference is still to use ~/Library/Python (or a subdirectory
thereof) and filenames that don't start with a dot.

Ronald

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 11:48, Ronald Oussoren wrote:

On 02 Aug, 2010,at 11:48 AM, Michael Foord
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 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)?

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.

"100% formally" speaking, MacOS behaves like UNIX in many
ways.

Really? As a Mac user I have never edited (or even looked at) files
in ~/Library. I would never think of going there for finding config
files to edit. However in my home directory I have:

.Xauthority
.Xcode
. CFUserTextEncoding - (an Apple encoding configuration for Core
Foundation)

.bash_profile
.cups
.dropbox
.dvdcss
.filezilla
.fontconfig
.hgrc
.idlerc
.ipython
.mono
.netbeans
.parallels_settings
.pypirc
.wingide3

The configuration files we are discussing are for command line tools -
so I don't think that having to resort to the command line is a
disadvantage at all. If users don't / can't use the command line then
they *won't* want to edit these files anyway.

If they are used to the command line then ~/.python32/distutils.cfg is
going to be a very natural place for them.

If we provide GUI tools that use these config files then we will also
provide GUI tools that use these config files then we will also provide
GUI tools to configure them - so I can't see a downside to having them
in the unix location and no upside to putting them elsewhere.

Michael

, with a default configuration of the Finder you cannot even see these
files (and that includes the File open dialog of tools like Text Edit)

The reason you don't normally look in ~/Library/Preferences is that
GUI tools on OSX have configuration screens for editing preferences
and you don't have to edit them manually.

My preference would be to follow this established and well used
convention.
My preference is still to use ~/Library/Python (or a subdirectory
thereof) and filenames that don't start with a dot.

Ronald

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread Tarek Ziadé

On Sun, Aug 1, 2010 at 10:37 PM, Tarek Ziadé  wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> = adding a PLUGINS file =
>
> A new file called 'PLUGINS' is added to the dist-info directory at
> install time, and contains a list of plugins for the installed
> distribution.

After some more thoughts, ISTM that it would be better to have the
plugin definitions in a new metadata field in PEP 345,
rather than in the PLUGINS file. The reason is that it will allow
tools and users to browse PyPI to look for plugins.

The PLUGINS file can be kept only for the state value, which is not read-only.

Regards,
Tarek

-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread Tarek Ziadé

On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby  wrote:
..
>
> So without specific examples of why this is a problem, it's hard to see why
> a special Python-specific set of configuration files is needed to resolve
> it, vs. say, encouraging application authors to use the available
> alternatives for doing plugin directories, config files, etc.

I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.

I propose that we drop the PLUGINS file idea and we add a new metadata
field called Provides-Plugin
in PEP 345, which will contain the info I've described minus the state
field. This will allow us to expose
plugins at PyPI.

IOW, have entry points like setuptools provides, but in a metadata
field instead of a entry_points.txt file.

Tarek

-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

> The PLUGINS file can be kept only for the state value, which is not read-only.

It will be for OS packages.

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pdb mini-sprint report and questions

2010-08-02 Thread Nick Coghlan

On Mon, Aug 2, 2010 at 10:10 AM, Ilya Sandler  wrote:
> Hello,
>
> I'm the submitter of the original patch and would like to help with it if I 
> can.
>
>> One issue that's not yet closed is #7245, which adds a (very nice IMO)
>> feature: when you press Ctrl-C while the program being debugged runs,
>> you will not get a traceback but execution is suspended, and you can
>> debug from the current point of execution -- just like in gdb.
>>
>> However, there were apparently issues with some of the buildbots when
>> the patch was applied for a short time.  I also don't know how and if
>> it works on Windows, so I'd need some helpful people testing it.
>
> For whatever it's worth, it worked for me with python trunk (2.x) on
> Vista, when I tried it manually.  But I don't know how to implement
> the unit test there (subprocess module doesn't support sending SIGINT
> programmatically on windows either). So the test_pdb2 test does not
> check signal behavior on Windows platforms.

I haven't looked at the relevant patch to check if this is applicable
to the test case, but actually sending a Ctrl-C character to stdin
(via a pipe) can work (although I think there can be some weirdness if
the parent process has no console).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby  wrote:
> ..
>>
>> So without specific examples of why this is a problem, it's hard to see why
>> a special Python-specific set of configuration files is needed to resolve
>> it, vs. say, encouraging application authors to use the available
>> alternatives for doing plugin directories, config files, etc.
> 
> I don't have a specific example in mind, and I must admit that if an
> application does the right thing
> (provide the right configuration file), this activate feature is not
> useful at all. So it seems to be a bad idea.
> 
> I propose that we drop the PLUGINS file idea and we add a new metadata
> field called Provides-Plugin
> in PEP 345, which will contain the info I've described minus the state
> field. This will allow us to expose
> plugins at PyPI.
> 
> IOW, have entry points like setuptools provides, but in a metadata
> field instead of a entry_points.txt file.

Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?

Packages can already work as application plugins by simply defining
a plugins namespace package and then placing the plugin packages
into that namespace.

See Zope for an example of how well this simply mechanism works out in
practice: it simply scans the "Products" namespace for sub-packages and
then loads each sub-package it finds to have it register itself with Zope.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread exarkun


On 12:21 pm, [email protected] wrote:

Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby  
wrote:

..


So without specific examples of why this is a problem, it's hard to 
see why
a special Python-specific set of configuration files is needed to 
resolve

it, vs. say, encouraging application authors to use the available
alternatives for doing plugin directories, config files, etc.


I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.

I propose that we drop the PLUGINS file idea and we add a new metadata
field called Provides-Plugin
in PEP 345, which will contain the info I've described minus the state
field. This will allow us to expose
plugins at PyPI.

IOW, have entry points like setuptools provides, but in a metadata
field instead of a entry_points.txt file.


Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?

Packages can already work as application plugins by simply defining
a plugins namespace package and then placing the plugin packages
into that namespace.

See Zope for an example of how well this simply mechanism works out in
practice: it simply scans the "Products" namespace for sub-packages and
then loads each sub-package it finds to have it register itself with 
Zope.


This is also roughly how Twisted's plugin system works.  One drawback, 
though, is that it means potentially executing a large amount of Python 
in order to load plugins.  This can build up to a significant 
performance issue as more and more plugins are installed.


Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


On 02/08/2010 13:31, [email protected] wrote:

On 12:21 pm, [email protected] wrote:

Tarek Ziad� wrote:

On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby  wrote:
..


So without specific examples of why this is a problem, it's hard to 
see why
a special Python-specific set of configuration files is needed to 
resolve

it, vs. say, encouraging application authors to use the available
alternatives for doing plugin directories, config files, etc.


I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.

I propose that we drop the PLUGINS file idea and we add a new metadata
field called Provides-Plugin
in PEP 345, which will contain the info I've described minus the state
field. This will allow us to expose
plugins at PyPI.

IOW, have entry points like setuptools provides, but in a metadata
field instead of a entry_points.txt file.


Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?

Packages can already work as application plugins by simply defining
a plugins namespace package and then placing the plugin packages
into that namespace.

See Zope for an example of how well this simply mechanism works out in
practice: it simply scans the "Products" namespace for sub-packages and
then loads each sub-package it finds to have it register itself with 
Zope.


This is also roughly how Twisted's plugin system works.  One drawback, 
though, is that it means potentially executing a large amount of 
Python in order to load plugins.  This can build up to a significant 
performance issue as more and more plugins are installed.




unittest will solve this problem by having plugins explicitly enabled in 
its own configuration system, and possibly managed through a separate 
tool like a plugins subcommand. The full package list will *only* need 
to be scanned when managing plugins, not during normal execution.


Having this distutils2 supported "plugin declaration and discovery" will 
be extremely useful for the unittest plugin system. Given that plugins 
may need configuring after installation, and tools that handle both 
activation and configuration can be provided, it doesn't seem a heavy cost.


The downside to this is that installing and activating plugins are two 
separate steps. Given that each project can have a different set of 
plugins enabled I don't see a way round it.


Michael


Jean-Paul


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

[email protected] wrote:
> On 12:21 pm, [email protected] wrote:
>> Tarek Ziad� wrote:
>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby  wrote:
>>> ..

 So without specific examples of why this is a problem, it's hard to
 see why
 a special Python-specific set of configuration files is needed to
 resolve
 it, vs. say, encouraging application authors to use the available
 alternatives for doing plugin directories, config files, etc.
>>>
>>> I don't have a specific example in mind, and I must admit that if an
>>> application does the right thing
>>> (provide the right configuration file), this activate feature is not
>>> useful at all. So it seems to be a bad idea.
>>>
>>> I propose that we drop the PLUGINS file idea and we add a new metadata
>>> field called Provides-Plugin
>>> in PEP 345, which will contain the info I've described minus the state
>>> field. This will allow us to expose
>>> plugins at PyPI.
>>>
>>> IOW, have entry points like setuptools provides, but in a metadata
>>> field instead of a entry_points.txt file.
>>
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defining
>> a plugins namespace package and then placing the plugin packages
>> into that namespace.
>>
>> See Zope for an example of how well this simply mechanism works out in
>> practice: it simply scans the "Products" namespace for sub-packages and
>> then loads each sub-package it finds to have it register itself with
>> Zope.
> 
> This is also roughly how Twisted's plugin system works.  One drawback,
> though, is that it means potentially executing a large amount of Python
> in order to load plugins.  This can build up to a significant
> performance issue as more and more plugins are installed.

I'd say that it's up to the application to deal with this problem.

An application which requires lots and lots of plugins could
define a registration protocol that does not require loading
all plugins at scanning time.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

2010-08-02 Thread Ronald Oussoren

On 02 Aug, 2010,at 01:00 PM, Michael Foord  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 
> ~/Library/Preferences. Most of the other ones are ports of unix tools 
> and store junk in the standard unix location for storing 
> configuration. Try edit one without resorting to the command-line

The configuration files we are discussing are for command line tools - 
so I don't think that having to resort to the command line is a 
disadvantage at all. If users don't / can't use the command line then 
they *won't* want to edit these files anyway. Not being comfortable at the command-line is not the same as not wanting to edit the global configuration of unittest or distutils.Anyway, does that mean that the configuration should move if I create a patch for IDLE that allows you the manage the unittest configuration through a GUI?

If they are used to the command line then ~/.python32/distutils.cfg is 
going to be a very natural place for them. That location isn't natural for me. If we invent a new location for python-related configuration file we might as well do it properly and follow platform conventions.The MacOSX conventions are described here .Macosx-is-not-a-crappy-linux-ly yours,  Ronald
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 14:34, Ronald Oussoren wrote:

On 02 Aug, 2010,at 01:00 PM, Michael Foord  
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
> ~/Library/Preferences. Most of the other ones are ports of unix tools
> and store junk in the standard unix location for storing
> configuration. Try edit one without resorting to the command-line

The configuration files we are discussing are for command line tools -
so I don't think that having to resort to the command line is a
disadvantage at all. If users don't / can't use the command line then
they *won't* want to edit these files anyway.
Not being comfortable at the command-line is not the same as not 
wanting to edit the global configuration of unittest or distutils.

Anyway, does that mean that the configuration should move if I create 
a patch for IDLE that allows you the manage the unittest configuration 
through a GUI?

Nope, as I doubt for *most* users it will be the primary way of editing 
the file.

If they are used to the command line then ~/.python32/distutils.cfg is
going to be a very natural place for them.
That location isn't natural for me. If we invent a new location for 
python-related configuration file we might as well do it properly and 
follow platform conventions.

But you yourself said that it *isn't* normal to have files we expect the 
user to edit in the location you suggested - and a glance on my system 
is that use ~/.app files is a *very* common convention on the Mac.

Michael
The MacOSX conventions are described here 
.

Macosx-is-not-a-crappy-linux-ly yours,

  Ronald

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your 
employer, to release me from all obligations and waivers arising from any and all 
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, 
confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS 
AGREEMENTS") that I have entered into with your employer, its partners, licensors, 
agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. 
You further represent that you have the authority to release me from any BOGUS AGREEMENTS 
on behalf of your employer.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread exarkun


On 01:27 pm, [email protected] wrote:

[email protected] wrote:

On 12:21 pm, [email protected] wrote:


See Zope for an example of how well this simply mechanism works out 
in
practice: it simply scans the "Products" namespace for sub-packages 
and

then loads each sub-package it finds to have it register itself with
Zope.


This is also roughly how Twisted's plugin system works.  One drawback,
though, is that it means potentially executing a large amount of 
Python

in order to load plugins.  This can build up to a significant
performance issue as more and more plugins are installed.


I'd say that it's up to the application to deal with this problem.

An application which requires lots and lots of plugins could
define a registration protocol that does not require loading
all plugins at scanning time.


It's not fixable at the application level, at least in Twisted's plugin 
system.  It sounds like Zope's system has the same problem, but all I 
know of that system is what you wrote above.  The cost increases with 
the number of plugins installed on the system, not the number of plugins 
the application wants to load.


Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On 02/08/2010 14:34, Ronald Oussoren wrote:

On 02 Aug, 2010,at 01:00 PM, Michael Foord  
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
> ~/Library/Preferences. Most of the other ones are ports of unix tools
> and store junk in the standard unix location for storing
> configuration. Try edit one without resorting to the command-line

The configuration files we are discussing are for command line tools -
so I don't think that having to resort to the command line is a
disadvantage at all. If users don't / can't use the command line then
they *won't* want to edit these files anyway.
Not being comfortable at the command-line is not the same as not 
wanting to edit the global configuration of unittest or distutils.

But both of those are primarily command line tools. A basic ability to 
use the command line is a prerequisite of wanting to configure them.

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?

Michael

Anyway, does that mean that the configuration should move if I create 
a patch for IDLE that allows you the manage the unittest configuration 
through a GUI?

If they are used to the command line then ~/.python32/distutils.cfg is
going to be a very natural place for them.
That location isn't natural for me. If we invent a new location for 
python-related configuration file we might as well do it properly and 
follow platform conventions.

The MacOSX conventions are described here 
.

Macosx-is-not-a-crappy-linux-ly yours,

  Ronald

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your 
employer, to release me from all obligations and waivers arising from any and all 
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, 
confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS 
AGREEMENTS") that I have entered into with your employer, its partners, licensors, 
agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. 
You further represent that you have the authority to release me from any BOGUS AGREEMENTS 
on behalf of your employer.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

2010-08-02 Thread R. David Murray

(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 downside to
that.  Most unix applications look in multiple places for configuration
info.

Michael seems to be arguing for not using the standard OSX locations
because the Finder can't edit them anyway.  Is that true?

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Ron Adam

On 08/02/2010 03:57 AM, Stephen J. Turnbull wrote:

Ron Adam writes:

  >  Something that may be more useful, is a "no activity" search field
  >  with choices of day, week, month, year, etc... and make the output
  >  sortable on time without activity.

That's exactly what a sort on date of activity gives you, though, and
it can be from longest down.

Yes, but when I do it, I either get a single specific day, or 2700 issues.

Also, I think that most of the "date" fields actually allow ranges
(iirc something like "today - 1 year, today" works, I've never
actually used them), but I don't think this can be easily negated in
the stock Roundup.  What could be done though is something like
"created Jan 1 1970, today - 2 years AND open" to find bugs that have
been hanging fire for more than two years.

Have you tried it?  I tried various different spelling and could only enter 
one specific day, "today" works, but "1 month" or "2 years" doesn't.

What does work is entering a partial date, ie...  2010-07 for all issues 
with activity this july. Or 2010 for all issues with activity this year.

Ron

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 2.6.6 rc 1 planned for today

Hi folks,

Don't forget that I am planning to cut Python 2.6.6 rc 1 later today (probably
starting at around 2200 UTC).  We have a number of release blockers currently
reported:

http://bugs.python.org/iss...@columns=title,id,activity,versions,assignee&@sort=activity&@group=priority&@filter=priority,status&@pagesize=50&@startwith=0&priority=1&status=1&@dispname=Showstoppers

Feel free to ping me on irc (freenode @ #python-dev) or follow up here if you
have any input on these.

I'll send the usually notes out to the committers list when I'm ready to
freeze the tree.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1

On Aug 02, 2010, at 12:09 PM, Antoine Pitrou wrote:

>On Mon, 02 Aug 2010 08:10:58 +0200
>Georg Brandl  wrote:
>> Thanks, Benjamin!  I'd also like to thank Martin and Ronald for the
>> prompt binaries, and the folks of #python-dev for support.  RMing
>> was a pleasant experience so far.
>
>Are you already trying to lure other people into replacing you?

Whitewashing the fence is *soo* much fun! :)

Congratulations Georg.  Benjamin and I have now been authorized to show you
the secret PSU handsha


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)


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 for configuration info on OSX, and I don't see a downside to
that.  Most unix applications look in multiple places for configuration
info.
   


That adds extra complexity to the implementation of the configuration 
system. If it uses the first one it finds which order does it look in, 
if we have tools that create the file which location does it create it 
in and so on.



Michael seems to be arguing for not using the standard OSX locations
because the Finder can't edit them anyway.  Is that true?
   
I am saying that Ronald's suggestion is *not* a natural location for 
user editable configuration files - as far as I can tell I have no user 
editable files there and plenty in ~/.something. Ronald himself said 
that the location he is specifying is the standard location for 
configuration / preference files created and used by *gui* tools, and 
files in that location are not usually intended to be user editable.


I don't believe a Mac user basically competent at the command line is 
*likely* to go looking in the gui preferences location for these config 
files and I think they would easily find them in ~. This is backed up 
the number of existing programs that use this convention on Mac OS X. It 
*is* a widely used convention on Mac OS X to use ~/.appname for 
configuration files. Applications like mercurial use this location on 
the Mac for example.


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 in ~.


The issue with the finder is that by default . files and directories 
aren't shown and so they wouldn't be editable from the finder. As basic 
willingness to use the command line is a prerequisite for *wanting* to 
edit these files I don't see this as an issue. A user unfamiliar with 
the command line is not likely to guess the correct location for these 
files if we put them elsewhere, so they are going to have to refer to 
some documentation anyway.


Michael



--
R. David Murray  www.bitdance.com
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python-checkins Reply-To now set for python-dev

Over in #python-dev, Georg reminded us of a change to the python-checkins
mailing list that was discussed a few weeks ago:

http://mail.python.org/pipermail/python-dev/2010-July/101853.html

Despite the mild preference of redirecting python-checkins to
python-committers, I noticed that the list was already set up to redirect to
python-dev (but the Reply-To munging was disabled).  I've now re-enabled
redirects of python-checkins to python-dev.  I think it's better to default to
more openness and it's not really that much traffic anyway.

If it gets obnoxious we can narrow things, but let's see how it goes.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

Le 02/08/2010 14:31, [email protected] a écrit :
> On 12:21 pm, [email protected] wrote:
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defining
>> a plugins namespace package and then placing the plugin packages
>> into that namespace. [...]
>
> This is also roughly how Twisted's plugin system works.  One drawback, 
> though, is that it means potentially executing a large amount of Python 
> in order to load plugins.  This can build up to a significant 
> performance issue as more and more plugins are installed.

If namespace packages make it into Python, they would indeed solve a
part of the problem in a nice, generic way. Regarding the performance
issue, I wonder if functions in pkgutil or importlib could allow one to
iterate over the plugins (i.e. submodules and subpackages of the
namespace package) without actually loading then. We would get only
their names though, not their description or any other information
useful to decide to activate them or not. Maybe importing is the way to
go, with a doc recommendation that people make their plugins subpackages
with an __init__ module containing only a docstring.

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread Glyph Lefkowitz


On Aug 2, 2010, at 9:53 AM, [email protected] wrote:

> On 01:27 pm, [email protected] wrote:
>> [email protected] wrote:
>>> On 12:21 pm, [email protected] wrote:
 
 See Zope for an example of how well this simply mechanism works out in
 practice: it simply scans the "Products" namespace for sub-packages and
 then loads each sub-package it finds to have it register itself with
 Zope.
>>> 
>>> This is also roughly how Twisted's plugin system works.  One drawback,
>>> though, is that it means potentially executing a large amount of Python
>>> in order to load plugins.  This can build up to a significant
>>> performance issue as more and more plugins are installed.
>> 
>> I'd say that it's up to the application to deal with this problem.
>> 
>> An application which requires lots and lots of plugins could
>> define a registration protocol that does not require loading
>> all plugins at scanning time.
> 
> It's not fixable at the application level, at least in Twisted's plugin 
> system.  It sounds like Zope's system has the same problem, but all I know of 
> that system is what you wrote above.  The cost increases with the number of 
> plugins installed on the system, not the number of plugins the application 
> wants to load.

We do have a plan to address this in Twisted's plugin system (eventually): 
, although I'm not sure if that's 
relevant to the issue at hand.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1


On 01/08/2010 10:38, Georg Brandl wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I'm happy to announce the
first alpha preview release of Python 3.2.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* an overhauled GIL implementation that reduces contention
* many consistency and behavior fixes for numeric operations
* countless fixes regarding string/unicode issues; among them full
   support for a bytes environment (filenames, environment variables)
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger

For an extensive list of changes in 3.2, see Misc/NEWS in the Python
distribution.

To download Python 3.2 visit:

  http://www.python.org/download/releases/3.2/

3.2 documentation can be found at:

  http://docs.python.org/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

  http://bugs.python.org/


Enjoy!

- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkxVQJsACgkQN9GcIYhpnLBxIgCcCiVu/QUkFf0bYM2Vmi8St3mZ
2N4An04q36lr47OA+bslqG/4Zj7ZwVOX
=iL8N
-END PGP SIGNATURE-


If I had things my way I would immediately award you a Blue Peter Gold 
Badge. [1]


Kindest regards.

Mark Lawrence.

[1]  Blue Peter is the longest running kids' programme in the world 
having started on the BBC in 1958.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread exarkun


On 03:08 pm, [email protected] wrote:

Le 02/08/2010 14:31, [email protected] a �crit :

On 12:21 pm, [email protected] wrote:

Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?

Packages can already work as application plugins by simply defining
a plugins namespace package and then placing the plugin packages
into that namespace. [...]


This is also roughly how Twisted's plugin system works.  One drawback,
though, is that it means potentially executing a large amount of 
Python

in order to load plugins.  This can build up to a significant
performance issue as more and more plugins are installed.


If namespace packages make it into Python, they would indeed solve a
part of the problem in a nice, generic way.


I don't think this solves the problem.  Twisted's plugin system already 
uses namespace packages.  It helps slightly, by spreading out your 
plugins, but you can still end up with lots of plugins in a particular 
namespace.

Regarding the performance
issue, I wonder if functions in pkgutil or importlib could allow one to
iterate over the plugins (i.e. submodules and subpackages of the
namespace package) without actually loading then. We would get only
their names though, not their description or any other information
useful to decide to activate them or not.


The trick is to continue to provide enough information so that the code 
iterating over the data can make a correct decision.  It's not clear 
that names are enough.

Maybe importing is the way to
go, with a doc recommendation that people make their plugins 
subpackages

with an __init__ module containing only a docstring.

Regards


Jean-Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

2010-08-02 Thread Ronald Oussoren

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 things 
up.

> 
> 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 downside to
> that.  Most unix applications look in multiple places for configuration
> info.

A lot of tools seem to look both in a system location and a per user location 
(such as /etc/profile and ~/.profile).

OSX ads a 3th level to that, although I have never used that myself 
(technically there are 4 levels, but that isn't important unless you are Apple).

> 
> Michael seems to be arguing for not using the standard OSX locations
> because the Finder can't edit them anyway.  Is that true?

The Finder can open OSX locations just fine, but you cannot see dot-files (or 
-directories) in the Finder.

I won't argue this anymore, at least not this week. I'll work around the issue 
in my private tree if that's what's needed.

Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


At 01:53 PM 8/2/2010 +, [email protected] wrote:

On 01:27 pm, [email protected] wrote:

[email protected] wrote:

This is also roughly how Twisted's plugin system works.  One drawback,
though, is that it means potentially executing a large amount of Python
in order to load plugins.  This can build up to a significant
performance issue as more and more plugins are installed.


I'd say that it's up to the application to deal with this problem.

An application which requires lots and lots of plugins could
define a registration protocol that does not require loading
all plugins at scanning time.


Just for the record, solving this problem is precisely what entry 
points are for: they provide a discovery mechanism that doesn't 
require importing anything until you actually need it.


It's not fixable at the application level, at least in Twisted's 
plugin system.  It sounds like Zope's system has the same problem, 
but all I know of that system is what you wrote above.


I don't know about Zope in general, but there are certainly Zope 
corp. projects that use entry points instead of namespaces (buildout, 
for one), and I believe that there's been a long time push to move 
third-party code out of the common namespace package.  i.e., AFAIK, 
Zope 3 doesn't use package namespaces as a primary method of extension.



  The cost increases with the number of plugins installed on the 
system, not the number of plugins the application wants to load.


Pretty much any plugin discovery system is going to scale that way, 
but entry points only require file reads rather than imports, and 
have a shared cache for all code in use by the application.  So if, 
say, Twisted uses entry points and an application running on Twisted 
also uses entry points, the loading cost is only paid once for both 
sets of entry points inspected.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts


On 02/08/2010 03:54, Benjamin Peterson wrote:

2010/7/31 Éric Araujo:

Good call.

Alternative idea: Have a new status “unread” to make searching easier
for bug people. Or a predefined custom search for nosy_count == 1.


Please, let's stop messing with the tracker for everything. I think
the current set up works reasonably well, and we should focus on the
real problem: manpower



I disagree entirely with this comment.  Perhaps we should simply agree 
to disagree, but I can't see how having issues that have been sitting 
for years without any response at all ties in with "the current set up 
works reasonably well".  The number was over 500 when Terry Reedy put 
his orphan tracker request on c.l.py.  IMHO a reply along the lines of 
"bugger off we're far too busy" would be better than nothing.  Failing 
that the simple "please provide a code and unit test patch" seems to 
work quite well.  Failing that "I'm going to close this because nobody 
is interested" works extremely well in waking people up! :)  All of 
these are better than complete silence.  I also believe that the latter 
of my suggestions should be used when the OP has shown no interest in 
moving the issue despite being asked to do so.


Just me tuppence worth.

Mark Lawrence.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


At 01:10 PM 8/2/2010 +0200, Tarek Ziadé wrote:

I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.


Well, it's not a *bad* idea as such; actually, having conventions for 
such configuration, and libraries that help to implement the 
convention are a *good* idea, and I support it.  I just don't think 
it makes much sense to *impose* the convention on the app developers; 
there are, after all, use cases that don't need the extra configuration.


Setuptools was mainly designed to support the "application plugin 
directory" model for invasive sorts of plugins, and the "global 
plugin availability" model for the kind of plugins that a user has to 
explicitly select (e.g. file type converters, special distutils 
commands, etc.).  However, there are definitely use cases for 
"user-configured plugins", and the apps that do it generally use some 
sort of configuration file to identify which entry points they'll actually use.




IOW, have entry points like setuptools provides, but in a metadata
field instead of a entry_points.txt file.


May I suggest, then, that we keep entry_points.txt, but simply 
provide a summary in PKG-INFO?  (i.e., list the groups and names provided)


This would still make it easy for human browsing/discovery of entry 
points on PyPI, but it would allow easy forward/backward 
compatibility between setuptools and distutils2, while also providing 
faster lookup of entry points (because you can skip distributions 
that don't have an entry points file, vs. having to parse *every* 
PKG-INFO file).


Or to put it another way, when I implement PEP 376 support in 
setuptools 0.7, I'll only have to change the name of the .egg-info 
directory and copy the entry point summary into PKG-INFO.  And, even 
more to the point, people who define entry points with distutils2 
will then be able to have them work with setuptools-based projects, 
and vice versa, helping to smooth the transition.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Ralf Schmitt

Benjamin Peterson  writes:

> Please, let's stop messing with the tracker for everything. I think
> the current set up works reasonably well, and we should focus on the
> real problem: manpower

Ignoring issues (probably even with some patches attached) will drive
contributors away. That's not the way to increase manpower.

- Ralf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts


On 02/08/2010 17:39, Ralf Schmitt wrote:

Benjamin Peterson  writes:


Please, let's stop messing with the tracker for everything. I think
the current set up works reasonably well, and we should focus on the
real problem: manpower


Ignoring issues (probably even with some patches attached) will drive
contributors away. That's not the way to increase manpower.

- Ralf

+1

Mark Lawrence.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Brian Curtin

On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt  wrote:

> Benjamin Peterson  writes:
>
> > Please, let's stop messing with the tracker for everything. I think
> > the current set up works reasonably well, and we should focus on the
> > real problem: manpower
>
> Ignoring issues (probably even with some patches attached) will drive
> contributors away. That's not the way to increase manpower.
>
> - Ralf

Overall the "no response" query just passes the buck. Let's say we get that
query down to zero issues. What does that give us? Now we have 500 issues
with 2 responses. Sure, it makes further correspondence more likely, but
it's not solving any real issues and making any measurably significant
impact.

While I do think the "no response" query can be helpful, let's not attribute
too much value to tiny tweaks of the tracker and reporting. Benjamin is
right -- manpower is where we'll benefit the most, not in the manner we
paint the current issue situation.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread Ian Bicking

Just to add a general opinion in here:

Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways ZCML is used is pluginish), I'm not very excited about these.  The
plugin system that causes the least confusion and yet seems to accomplish
everything it needs is just listing objects in configuration -- nothing gets
activated implicitly with installation, and names are Python package/object
names without indirection.  The only thing I'd want to add is the ability to
also point to files, as a common use for plugins is adding ad hoc
functionality to an application, and the overhead of package creation isn't
always called for.  hg for example seems both simple and general enough, and
it doesn't use anything fancy.

Purely for the purpose of discovery and documentation it might be helpful to
have APIs, then some tool could show available plugins (especially if PyPI
had a query interface for this), or at least installed plugins, with the
necessary code to invoke them.

*Maybe* it would make sense to generalize the discovery of plugin types, so
that you can simply refer to an object and the application can determine
what kind of plugin it is.  But having described this, it actually doesn't
seem like a useful thing to generalize.

-- 
Ian Bicking  |  http://blog.ianbicking.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

On 02/08/2010 17:54, Brian Curtin wrote:
On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt > wrote:

Benjamin Peterson mailto:[email protected]>> writes:

> Please, let's stop messing with the tracker for everything. I think
> the current set up works reasonably well, and we should focus on the
> real problem: manpower

Ignoring issues (probably even with some patches attached) will drive
contributors away. That's not the way to increase manpower.

- Ralf

Overall the "no response" query just passes the buck. Let's say we get 
that query down to zero issues. What does that give us? Now we have 
500 issues with 2 responses. Sure, it makes further correspondence 
more likely, but it's not solving any real issues and making any 
measurably significant impact.

Sure it could make a difference. People who submit issues will 
appreciate *some* response a great deal more than no response. More than 
that, if we have people dedicated to looking at new issues then we are 
more likely to *resolve* some that would otherwise "slip through the net".

While I do think the "no response" query can be helpful, let's not 
attribute too much value to tiny tweaks of the tracker and reporting. 
Benjamin is right -- manpower is where we'll benefit the most, not in 
the manner we paint the current issue situation.

Sure. *Part* of drawing in more manpower can be engaging with those 
submitting issues and seeing if we can get them to post patches and / or 
tests - and suck them as far into Python development as we possibly can. 
;-) For many people submitting an issue may be their first contact with 
Python developers and the Python development process (just as for others 
posting to Python-dev will be their first contact - even if they really 
should be posting to comp.lang.python instead).

All the best,

Michael

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your 
employer, to release me from all obligations and waivers arising from any and all 
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, 
confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS 
AGREEMENTS") that I have entered into with your employer, its partners, licensors, 
agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. 
You further represent that you have the authority to release me from any BOGUS AGREEMENTS 
on behalf of your employer.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread Holger Krekel

On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking  wrote:
> Just to add a general opinion in here:
>
> Having worked with Setuptools' entry points, and a little with some Zope
> pluginish systems (Products.*, which I don't think anyone liked much, and
> some ways ZCML is used is pluginish), I'm not very excited about these.  The
> plugin system that causes the least confusion and yet seems to accomplish
> everything it needs is just listing objects in configuration -- nothing gets
> activated implicitly with installation, and names are Python package/object
> names without indirection.

This makes it a two-step process to use a plugin: install it and then
configure it correctly to have it used.

I'd much prefer a one-step process and rather provide a way to not-use
a plugin even if installed.  The difference is e.g. with py.test that i can
point users to e.g.

  pip install pytest-figleaf
  py.test --figleaf

instead of also having to explain a configuration file, its location
and exact content or some magic attribute variables on some
classes.

TBH, i'd like to have pip handle plugins, based on metadata
(especially some data signaling something is a plugin of otherthing).
This way i only once have to teach about "pip" and people leverage
 their knowledge for installing/managing plugins.

best,
holger

> The only thing I'd want to add is the ability to
> also point to files, as a common use for plugins is adding ad hoc
> functionality to an application, and the overhead of package creation isn't
> always called for.  hg for example seems both simple and general enough, and
> it doesn't use anything fancy.
>
> Purely for the purpose of discovery and documentation it might be helpful to
> have APIs, then some tool could show available plugins (especially if PyPI
> had a query interface for this), or at least installed plugins, with the
> necessary code to invoke them.
>
> *Maybe* it would make sense to generalize the discovery of plugin types, so
> that you can simply refer to an object and the application can determine
> what kind of plugin it is.  But having described this, it actually doesn't
> seem like a useful thing to generalize.
>
> --
> Ian Bicking  |  http://blog.ianbicking.org
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Mark Smith

If I may comment *as* a new contributor: Terry responded almost immediately
to my first issue raised, and that was a huge boost. If no-one had replied
at all, I suspect I would never have spent any more time contributing to any
part of Python. (And I contributed 8 more hours today.)

Incidentally, given that this is my first post: Hi everyone, my name's Mark
Smith. I'm a Python contractor based in Edinburgh, and my nick on IRC is
juD2k (for strange, yet dull historical reasons) :-)

--Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


On 02/08/2010 19:05, Holger Krekel wrote:

On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking  wrote:
   

Just to add a general opinion in here:

Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways ZCML is used is pluginish), I'm not very excited about these.  The
plugin system that causes the least confusion and yet seems to accomplish
everything it needs is just listing objects in configuration -- nothing gets
activated implicitly with installation, and names are Python package/object
names without indirection.
 

This makes it a two-step process to use a plugin: install it and then
configure it correctly to have it used.

I'd much prefer a one-step process and rather provide a way to not-use
a plugin even if installed.  The difference is e.g. with py.test that i can
point users to e.g.

   pip install pytest-figleaf
   py.test --figleaf
   


How do you achieve this currently?

Michael


instead of also having to explain a configuration file, its location
and exact content or some magic attribute variables on some
classes.

TBH, i'd like to have pip handle plugins, based on metadata
(especially some data signaling something is a plugin of otherthing).
This way i only once have to teach about "pip" and people leverage
  their knowledge for installing/managing plugins.

best,
holger

   

The only thing I'd want to add is the ability to
also point to files, as a common use for plugins is adding ad hoc
functionality to an application, and the overhead of package creation isn't
always called for.  hg for example seems both simple and general enough, and
it doesn't use anything fancy.

Purely for the purpose of discovery and documentation it might be helpful to
have APIs, then some tool could show available plugins (especially if PyPI
had a query interface for this), or at least installed plugins, with the
necessary code to invoke them.

*Maybe* it would make sense to generalize the discovery of plugin types, so
that you can simply refer to an object and the application can determine
what kind of plugin it is.  But having described this, it actually doesn't
seem like a useful thing to generalize.

--
Ian Bicking  |  http://blog.ianbicking.org

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com


 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Terry Reedy

On 8/2/2010 12:54 PM, Brian Curtin wrote:

On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt mailto:[email protected]>> wrote:

Benjamin Peterson mailto:[email protected]>>
writes:

 > Please, let's stop messing with the tracker for everything. I think
 > the current set up works reasonably well, and we should focus on the
 > real problem: manpower

Two months ago, I discovered and reported that about 1/5 of open issues 
had no responses. Is that 'reasonably well'? I do not remember other 
reports on that, at least not for a few years. A 'show unanswered' link 
might make it easier to recruit people to be first-responders by making 
it easier to do first response. This hardly amounts to 'messing with the 
tracker'. Rather, it is using the current mechanism by adding a link.

Ignoring issues (probably even with some patches attached) will drive
contributors away. That's not the way to increase manpower.

As a said before, I think people who have posted, certainly people who 
have had fixes committed, should get an invitation letter. One 
suggestion on that could be to click 'show unanswered' if that were 
available.

Overall the "no response" query just passes the buck. Let's say we get
that query down to zero issues. What does that give us? Now we have 500
issues with 2 responses. Sure, it makes further correspondence more
likely, but it's not solving any real issues and making any measurably
significant impact.

If a question response elicits no answer, the issue can be closed as 
out-of-date. But several times in the past two months, first responses 
have lead to more responses from both OP and developers who watch the 
tracker message list. Some have been closed as fixed already. Example:

   http://bugs.python.org/issue3874
The OP's first response was to gripe about no response earlier. His 
second was to write an entry that Georg could cut, paste, format, and 
commit.

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread Holger Krekel

On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord  wrote:
> On 02/08/2010 19:05, Holger Krekel wrote:
>>
>> On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking  wrote:
>>
>>>
>>> Just to add a general opinion in here:
>>>
>>> Having worked with Setuptools' entry points, and a little with some Zope
>>> pluginish systems (Products.*, which I don't think anyone liked much, and
>>> some ways ZCML is used is pluginish), I'm not very excited about these.
>>>  The
>>> plugin system that causes the least confusion and yet seems to accomplish
>>> everything it needs is just listing objects in configuration -- nothing
>>> gets
>>> activated implicitly with installation, and names are Python
>>> package/object
>>> names without indirection.
>>>
>>
>> This makes it a two-step process to use a plugin: install it and then
>> configure it correctly to have it used.
>>
>> I'd much prefer a one-step process and rather provide a way to not-use
>> a plugin even if installed.  The difference is e.g. with py.test that i
>> can
>> point users to e.g.
>>
>>   pip install pytest-figleaf
>>   py.test --figleaf
>>
>
> How do you achieve this currently?

it uses setuptools entrypoints, so with a setup.py param like

entry_points = {'pytest11': ['pytest_figleaf = pytest_figleaf'],},

py.test's pluginmanager.py does:

for ep in pkg_resources.iter_entry_points('pytest11'):
# ... ep.name == "pytest_figleaf" <- left side of above "*=*"
plugin = ep.load() # <- right side of above "*=*"
# ...

best,
holger


> Michael
>
>> instead of also having to explain a configuration file, its location
>> and exact content or some magic attribute variables on some
>> classes.
>>
>> TBH, i'd like to have pip handle plugins, based on metadata
>> (especially some data signaling something is a plugin of otherthing).
>> This way i only once have to teach about "pip" and people leverage
>>  their knowledge for installing/managing plugins.
>>
>> best,
>> holger
>>
>>
>>>
>>> The only thing I'd want to add is the ability to
>>> also point to files, as a common use for plugins is adding ad hoc
>>> functionality to an application, and the overhead of package creation
>>> isn't
>>> always called for.  hg for example seems both simple and general enough,
>>> and
>>> it doesn't use anything fancy.
>>>
>>> Purely for the purpose of discovery and documentation it might be helpful
>>> to
>>> have APIs, then some tool could show available plugins (especially if
>>> PyPI
>>> had a query interface for this), or at least installed plugins, with the
>>> necessary code to invoke them.
>>>
>>> *Maybe* it would make sense to generalize the discovery of plugin types,
>>> so
>>> that you can simply refer to an object and the application can determine
>>> what kind of plugin it is.  But having described this, it actually
>>> doesn't
>>> seem like a useful thing to generalize.
>>>
>>> --
>>> Ian Bicking  |  http://blog.ianbicking.org
>>>
>>> ___
>>> Python-Dev mailing list
>>> [email protected]
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>>
>>> http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com
>>>
>>>
>>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


On 02/08/2010 19:45, Holger Krekel wrote:

On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord  wrote:
   

On 02/08/2010 19:05, Holger Krekel wrote:
 

On Mon, Aug 2, 2010 at 6:57 PM, Ian Bickingwrote:

   

Just to add a general opinion in here:

Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways ZCML is used is pluginish), I'm not very excited about these.
  The
plugin system that causes the least confusion and yet seems to accomplish
everything it needs is just listing objects in configuration -- nothing
gets
activated implicitly with installation, and names are Python
package/object
names without indirection.

 

This makes it a two-step process to use a plugin: install it and then
configure it correctly to have it used.

I'd much prefer a one-step process and rather provide a way to not-use
a plugin even if installed.  The difference is e.g. with py.test that i
can
point users to e.g.

   pip install pytest-figleaf
   py.test --figleaf

   

How do you achieve this currently?
 

it uses setuptools entrypoints, so with a setup.py param like
   


Right. I can't use that for unittest. With the new proposal we *could* 
automatically use all available plugins, but I think I prefer to only 
have plugins active that the user has chosen.


Michael


 entry_points = {'pytest11': ['pytest_figleaf = pytest_figleaf'],},

py.test's pluginmanager.py does:

 for ep in pkg_resources.iter_entry_points('pytest11'):
 # ... ep.name == "pytest_figleaf"<- left side of above "*=*"
 plugin = ep.load() #<- right side of above "*=*"
 # ...

best,
holger


   

Michael

 

instead of also having to explain a configuration file, its location
and exact content or some magic attribute variables on some
classes.

TBH, i'd like to have pip handle plugins, based on metadata
(especially some data signaling something is a plugin of otherthing).
This way i only once have to teach about "pip" and people leverage
  their knowledge for installing/managing plugins.

best,
holger


   

The only thing I'd want to add is the ability to
also point to files, as a common use for plugins is adding ad hoc
functionality to an application, and the overhead of package creation
isn't
always called for.  hg for example seems both simple and general enough,
and
it doesn't use anything fancy.

Purely for the purpose of discovery and documentation it might be helpful
to
have APIs, then some tool could show available plugins (especially if
PyPI
had a query interface for this), or at least installed plugins, with the
necessary code to invoke them.

*Maybe* it would make sense to generalize the discovery of plugin types,
so
that you can simply refer to an object and the application can determine
what kind of plugin it is.  But having described this, it actually
doesn't
seem like a useful thing to generalize.

--
Ian Bicking  |  http://blog.ianbicking.org

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:

http://mail.python.org/mailman/options/python-dev/holger.krekel%40gmail.com



 

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

   


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from
any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
entered into with your employer, its partners, licensors, agents and
assigns, in perpetuity, without prejudice to my ongoing rights and
privileges. You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.



 



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


_

Re: [Python-Dev] No response to posts

2010-08-02 Thread Steve Holden

On 8/2/2010 1:18 PM, Michael Foord wrote:
> On 02/08/2010 17:54, Brian Curtin wrote:
>> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt > > wrote:
>>
>> Benjamin Peterson > > writes:
>>
>> > Please, let's stop messing with the tracker for everything. I think
>> > the current set up works reasonably well, and we should focus on the
>> > real problem: manpower
>>
>> Ignoring issues (probably even with some patches attached) will drive
>> contributors away. That's not the way to increase manpower.
>>
>> - Ralf
>>
>>
>> Overall the "no response" query just passes the buck. Let's say we get
>> that query down to zero issues. What does that give us? Now we have
>> 500 issues with 2 responses. Sure, it makes further correspondence
>> more likely, but it's not solving any real issues and making any
>> measurably significant impact.
>>
> 
> Sure it could make a difference. People who submit issues will
> appreciate *some* response a great deal more than no response. More than
> that, if we have people dedicated to looking at new issues then we are
> more likely to *resolve* some that would otherwise "slip through the net".
> 
> 
>> While I do think the "no response" query can be helpful, let's not
>> attribute too much value to tiny tweaks of the tracker and reporting.
>> Benjamin is right -- manpower is where we'll benefit the most, not in
>> the manner we paint the current issue situation.
> 
> Sure. *Part* of drawing in more manpower can be engaging with those
> submitting issues and seeing if we can get them to post patches and / or
> tests - and suck them as far into Python development as we possibly can.
> ;-) For many people submitting an issue may be their first contact with
> Python developers and the Python development process (just as for others
> posting to Python-dev will be their first contact - even if they really
> should be posting to comp.lang.python instead).
> 

I agree with Michael that response to first issue posting is an
important potential recruitment channel.

It's important, though, that the response is friendly and encouraging
(not that there's anyone on this list who doesn't have those two
characteristics :-). And certainly not automated - that wouldn't help at
all.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

2010-08-02 Thread Holger Krekel

On Mon, Aug 2, 2010 at 8:48 PM, Michael Foord  wrote:
> On 02/08/2010 19:45, Holger Krekel wrote:
[...]
 I'd much prefer a one-step process and rather provide a way to not-use
 a plugin even if installed.  The difference is e.g. with py.test that i
 can point users to e.g.

   pip install pytest-figleaf
   py.test --figleaf
>>>
>>> How do you achieve this currently?
>>>
>>
>> it uses setuptools entrypoints, so with a setup.py param like
>
> Right. I can't use that for unittest. With the new proposal we *could*
> automatically use all available plugins, but I think I prefer to only have
> plugins active that the user has chosen.

This sounds like a situation where a user has more installed
than he actually asked for.  I guess i am a big fan of "use virtualenv,
avoid global installations" and thus don't see the point to have
more installed than needed.

best,
holger
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

Michael Foord wrote:
> On 02/08/2010 13:31, [email protected] wrote:
>> On 12:21 pm, [email protected] wrote:
>>> Tarek Ziad� wrote:
 On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby  wrote:
 ..
>
> So without specific examples of why this is a problem, it's hard to
> see why
> a special Python-specific set of configuration files is needed to
> resolve
> it, vs. say, encouraging application authors to use the available
> alternatives for doing plugin directories, config files, etc.

 I don't have a specific example in mind, and I must admit that if an
 application does the right thing
 (provide the right configuration file), this activate feature is not
 useful at all. So it seems to be a bad idea.

 I propose that we drop the PLUGINS file idea and we add a new metadata
 field called Provides-Plugin
 in PEP 345, which will contain the info I've described minus the state
 field. This will allow us to expose
 plugins at PyPI.

 IOW, have entry points like setuptools provides, but in a metadata
 field instead of a entry_points.txt file.
>>>
>>> Do we really need to make Python packaging even more complicated by
>>> adding support for application-specific plugin mechanisms ?
>>>
>>> Packages can already work as application plugins by simply defining
>>> a plugins namespace package and then placing the plugin packages
>>> into that namespace.
>>>
>>> See Zope for an example of how well this simply mechanism works out in
>>> practice: it simply scans the "Products" namespace for sub-packages and
>>> then loads each sub-package it finds to have it register itself with
>>> Zope.
>>
>> This is also roughly how Twisted's plugin system works.  One drawback,
>> though, is that it means potentially executing a large amount of
>> Python in order to load plugins.  This can build up to a significant
>> performance issue as more and more plugins are installed.
>>
> 
> unittest will solve this problem by having plugins explicitly enabled in
> its own configuration system, and possibly managed through a separate
> tool like a plugins subcommand. The full package list will *only* need
> to be scanned when managing plugins, not during normal execution.
> 
> Having this distutils2 supported "plugin declaration and discovery" will
> be extremely useful for the unittest plugin system. Given that plugins
> may need configuring after installation, and tools that handle both
> activation and configuration can be provided, it doesn't seem a heavy cost.
> 
> The downside to this is that installing and activating plugins are two
> separate steps. Given that each project can have a different set of
> plugins enabled I don't see a way round it.

You might want to take a look at the Trac plugin system which
works in more or less the same way:

http://trac.edgewall.org/wiki/TracPlugins

Since applications tend to have a rather diverse set of needs for
plugins, I don't think we should add plugins support to PEP 376.

Users of applications will not want to edit a single configuration
file to maintain plugins of many different applications (they might
break some other application doing so) and sys admins
will have trouble with such a setup as well (they usually want to
have control over which plugins get used for various reasons).

In the end, you'd have a system wide plugin configuration (maintained
by the sys admin), a per user one (with local customizations) and a
per application one (providing application-specific defaults) -
which only increases complexity and doesn't really solve anything.

Instead, I'd suggest to let each application do its own little thing
to manage plugins, in a complex or simple way, with or without
configuration, and have them all live happily side-by-side.

The stdlib should really only provide tools to applications and
make useful suggestions, not try to enforce application design
choices. I think that's simply out of scope for the stdlib

Tarek:

What you might want to do is add new type fields to PEP 345,
making it easier to identify and list packages that work as
plugins for applications, e.g.

Type: Plugin for MyCoolApp

The MyCoolApp could then use the Type-field to identify all
installed plugins, get their installation directories, etc.
and work on from there.

Whether or not to use an installed plugin is really not
without the scope of Python's packaging system. This is
something the application must provide in its config file,
together with possible additional sections to configure
a particular plugin.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try our new mxO

Re: [Python-Dev] No response to posts

2010-08-02 Thread Martin v. Löwis

> Sure it could make a difference. People who submit issues will
> appreciate *some* response a great deal more than no response.

That depends. Sometimes, people post to the bug tracker to get help,
and they will get sad/driven away/angry when they get no response;
sometimes, if they get a response but no help, they will still get
sad/driven away/angry. Driving them away pointing out that the bug
tracker is not a place to obtain help might be as much help as "we"
can offer.

Other people post to the tracker to offer help. Those are the ones
that should not be driven away. Unfortunately, just responding to
them doesn't improve anything, IMO. If people only post to the issue
without any plan of actually doing something about the issue likely
still drives people away.

> Sure. *Part* of drawing in more manpower can be engaging with those
> submitting issues and seeing if we can get them to post patches and / or
> tests - and suck them as far into Python development as we possibly can.
> ;-) 

I think it's important to find out what people expect when posting
to the tracker. Maybe a mandatory radio list with these options
would help:

- I post this to get help from you
- I'm willing to work on other issues to expedite processing of this one
- The issue is not urgent, take your time

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Tim Golden


On 02/08/2010 8:40 PM, "Martin v. Löwis" wrote:

I think it's important to find out what people expect when posting
to the tracker. Maybe a mandatory radio list with these options
would help:

- I post this to get help from you
- I'm willing to work on other issues to expedite processing of this one
- The issue is not urgent, take your time


Or, clearly in some cases:

- I'm just letting you know and walking away; I'm not particularly
interested in pursuing it any further as I've already worked around it.

TJG
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


On 02/08/2010 20:36, M.-A. Lemburg wrote:

Michael Foord wrote:
   

On 02/08/2010 13:31, [email protected] wrote:
 

On 12:21 pm, [email protected] wrote:
   

Tarek Ziad� wrote:
 

On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby  wrote:
..
   

So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration files is needed to
resolve
it, vs. say, encouraging application authors to use the available
alternatives for doing plugin directories, config files, etc.
 

I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.

I propose that we drop the PLUGINS file idea and we add a new metadata
field called Provides-Plugin
in PEP 345, which will contain the info I've described minus the state
field. This will allow us to expose
plugins at PyPI.

IOW, have entry points like setuptools provides, but in a metadata
field instead of a entry_points.txt file.
   

Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?

Packages can already work as application plugins by simply defining
a plugins namespace package and then placing the plugin packages
into that namespace.

See Zope for an example of how well this simply mechanism works out in
practice: it simply scans the "Products" namespace for sub-packages and
then loads each sub-package it finds to have it register itself with
Zope.
 

This is also roughly how Twisted's plugin system works.  One drawback,
though, is that it means potentially executing a large amount of
Python in order to load plugins.  This can build up to a significant
performance issue as more and more plugins are installed.

   

unittest will solve this problem by having plugins explicitly enabled in
its own configuration system, and possibly managed through a separate
tool like a plugins subcommand. The full package list will *only* need
to be scanned when managing plugins, not during normal execution.

Having this distutils2 supported "plugin declaration and discovery" will
be extremely useful for the unittest plugin system. Given that plugins
may need configuring after installation, and tools that handle both
activation and configuration can be provided, it doesn't seem a heavy cost.

The downside to this is that installing and activating plugins are two
separate steps. Given that each project can have a different set of
plugins enabled I don't see a way round it.
 

You might want to take a look at the Trac plugin system which
works in more or less the same way:

http://trac.edgewall.org/wiki/TracPlugins


   


Ouch. I really don't want to emulate that system. For installing a 
plugin for a single project the recommended technique is:


* Unpack the source. It should provide a setup.py.
* Run:

  $ python setup.py bdist_egg

Then you will have a *.egg file. Examine the output of running 
python to find where this was created.


Once you have the plugin archive, you need to copy it into the 
plugins directory of the project environment


For global plugins it just uses entry points, which is similar to the 
functionality we are suggesting adding... However note:


Unlike plugins installed per-environment, you'll have to explicitly 
enable globally installed plugins via trac.ini.


Really this sounds *astonishingly* like the system we are proposing. :-) 
(Global discovery with per-application choice about whether or not 
installed plugins are actually used).



Since applications tend to have a rather diverse set of needs for
plugins, I don't think we should add plugins support to PEP 376.
   


We are really just suggesting adding entry points.

Users of applications will not want to edit a single configuration
file to maintain plugins of many different applications


This we are not proposing. Nor were we ever proposing it. The single 
file that was proposed (and in my understanding is no longer proposed) 
was to be maintained by distutils2 *anyway*.



(they might
break some other application doing so) and sys admins
will have trouble with such a setup as well (they usually want to
have control over which plugins get used for various reasons).

In the end, you'd have a system wide plugin configuration (maintained
by the sys admin), a per user one (with local customizations) and a
per application one (providing application-specific defaults) -
which only increases complexity and doesn't really solve anything.

   


We simply provide information about the availability of plugins. System 
administrators or users can control the use of this information (and the 
plugins) as per their own policies.



Instead, I'd suggest to let each application do its own little thing
to manage plugins, in a complex or simple way, with or w

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

Michael Foord wrote:
> On 02/08/2010 20:36, M.-A. Lemburg wrote:
>> Michael Foord wrote:
>>   
>>> On 02/08/2010 13:31, [email protected] wrote:
>>> 
 On 12:21 pm, [email protected] wrote:
   
> Tarek Ziad� wrote:
> 
>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby 
>> wrote:
>> ..
>>   
>>> So without specific examples of why this is a problem, it's hard to
>>> see why
>>> a special Python-specific set of configuration files is needed to
>>> resolve
>>> it, vs. say, encouraging application authors to use the available
>>> alternatives for doing plugin directories, config files, etc.
>>>  
>> I don't have a specific example in mind, and I must admit that if an
>> application does the right thing
>> (provide the right configuration file), this activate feature is not
>> useful at all. So it seems to be a bad idea.
>>
>> I propose that we drop the PLUGINS file idea and we add a new
>> metadata
>> field called Provides-Plugin
>> in PEP 345, which will contain the info I've described minus the
>> state
>> field. This will allow us to expose
>> plugins at PyPI.
>>
>> IOW, have entry points like setuptools provides, but in a metadata
>> field instead of a entry_points.txt file.
>>
> Do we really need to make Python packaging even more complicated by
> adding support for application-specific plugin mechanisms ?
>
> Packages can already work as application plugins by simply defining
> a plugins namespace package and then placing the plugin packages
> into that namespace.
>
> See Zope for an example of how well this simply mechanism works out in
> practice: it simply scans the "Products" namespace for sub-packages
> and
> then loads each sub-package it finds to have it register itself with
> Zope.
>  
 This is also roughly how Twisted's plugin system works.  One drawback,
 though, is that it means potentially executing a large amount of
 Python in order to load plugins.  This can build up to a significant
 performance issue as more and more plugins are installed.


>>> unittest will solve this problem by having plugins explicitly enabled in
>>> its own configuration system, and possibly managed through a separate
>>> tool like a plugins subcommand. The full package list will *only* need
>>> to be scanned when managing plugins, not during normal execution.
>>>
>>> Having this distutils2 supported "plugin declaration and discovery" will
>>> be extremely useful for the unittest plugin system. Given that plugins
>>> may need configuring after installation, and tools that handle both
>>> activation and configuration can be provided, it doesn't seem a heavy
>>> cost.
>>>
>>> The downside to this is that installing and activating plugins are two
>>> separate steps. Given that each project can have a different set of
>>> plugins enabled I don't see a way round it.
>>>  
>> You might want to take a look at the Trac plugin system which
>> works in more or less the same way:
>>
>> http://trac.edgewall.org/wiki/TracPlugins
>>
>>
>>
> 
> Ouch. I really don't want to emulate that system. For installing a
> plugin for a single project the recommended technique is:
> 
> * Unpack the source. It should provide a setup.py.
> * Run:
> 
>   $ python setup.py bdist_egg
> 
> Then you will have a *.egg file. Examine the output of running
> python to find where this was created.
> 
> Once you have the plugin archive, you need to copy it into the
> plugins directory of the project environment
> 
> For global plugins it just uses entry points, which is similar to the
> functionality we are suggesting adding... However note:
> 
> Unlike plugins installed per-environment, you'll have to explicitly
> enable globally installed plugins via trac.ini.
> 
> Really this sounds *astonishingly* like the system we are proposing. :-)
> (Global discovery with per-application choice about whether or not
> installed plugins are actually used).

The difference being that Trac is usually hosted using a
separate Python installation, so the pre-application choice is
really a per-Trac instance choice.

But yes, the system you are proposing does sound a lot like
what Trac uses and it works well - for that one application.

>> Since applications tend to have a rather diverse set of needs for
>> plugins, I don't think we should add plugins support to PEP 376.
> 
> We are really just suggesting adding entry points.

Tarek's email sounded a lot like the attempt to come up
with a universal plugin system, both in terms of managing
installed plugins and their configuration.

Perhaps I've just missed some twist in the thread :-)

>> Users of applications will not want to edit a single configuration
>> file to maintain plugins of many different applications
> 
> This we are not pr

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


At 05:08 PM 8/2/2010 +0200, Ãric Araujo wrote:
I wonder if functions in pkgutil or importlib could allow one to 
iterate over the plugins (i.e. submodules and subpackages of the 
namespace package) without actually loading then.


See pkgutil.walk_packages(), available since 2.5.

It has to load __init__.py files, especially because of namespace 
packages, but it doesn't load any non-package modules.


That being said, using namespace packages for plugins kind of defeats 
the true purpose of namespace packages, which is to give developers 
private package namespaces they can use across multiple projects, 
like zope.*, peak.*, twisted.*, etc., thereby avoiding naming 
conflicts in the root package namespace.


Granted, you can always re-nest namespaces and do something like 
someproject.plugins.mynamehere.myplugin, but with entry points you 
can just register something in mynamehere.mysomeprojectplugin, and 
flat is better than nested.  ;-)  (Plus, you can include information 
about the individual plugins/features residing in that module in the 
metadata, and avoid importing until/unless you need that feature.)


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


At 09:03 PM 8/2/2010 +0100, Michael Foord wrote:

Ouch. I really don't want to emulate that system. For installing a
plugin for a single project the recommended technique is:

 * Unpack the source. It should provide a setup.py.
 * Run:

   $ python setup.py bdist_egg

 Then you will have a *.egg file. Examine the output of running
python to find where this was created.

 Once you have the plugin archive, you need to copy it into the
plugins directory of the project environment


Those instructions are apparently out-of-date; you can actually just 
"easy_install -m" or "pip" the plugin directly to the plugins 
directory, without any additional intervening steps.


(The only reason to create an .egg file for Trac is if you intend to 
distribute to non-developer users who will be told to just drop it in 
the plugins directory.)




For global plugins it just uses entry points, which is similar to the
functionality we are suggesting adding...


I believe it's using entry points for both, actually.  It just has an 
(application-specific) filtering mechanism to restrict which entry 
points get loaded.




Really this sounds *astonishingly* like the system we are proposing. :-)


Which is why I keep pointing out that the code for doing most of it 
is already available in setuptools, distribute, pip, buildout, etc., 
and so (IMO) ought to just get copied into distutils2, the way 
easy_install's package index code was.  ;-)


(Of course, adding some filtering utilities to make it easier for 
apps to do explicit configuration would still be nice.)


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Benjamin Peterson

2010/8/2 Terry Reedy :
> On 8/2/2010 12:54 PM, Brian Curtin wrote:
>>
>> On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt > > wrote:
>>
>>    Benjamin Peterson mailto:[email protected]>>
>>    writes:
>>
>>     > Please, let's stop messing with the tracker for everything. I think
>>     > the current set up works reasonably well, and we should focus on the
>>     > real problem: manpower
>
> Two months ago, I discovered and reported that about 1/5 of open issues had
> no responses. Is that 'reasonably well'?

I'm only referring to the infrastructure when I say "the current
setup." I don't think repeatedly tweaking the tracker is likely to
close more issues.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support


At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:

If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other package managers update
a central SQLite database cache of the data found on disk.


Don't forget system packaging tools like .deb, .rpm, etc., which do 
not generally take kindly to updating such things.  For better or 
worse, the filesystem *is* our "central database" these days.


Btw, while adding PLUGINS to PEP 376 is a new proposal, it's 
essentially another spelling of the existing entry_points.txt used by 
eggs; it changes the format to csv instead of .ini, and adds 
"description" and "type" fields, but drops requirements information 
and I'm not sure if it can point to arbitrary objects the way 
entry_points.txt can.


Anyway, entry_points.txt has been around enough years in the field 
that the concept itself can't really be called "new" - it's actually 
quite proven.  Checking 
http://nullege.com/codes/search/pkg_resources.iter_entry_points/call 
, I find 187 modules using just that one entry points API.


Some projects do have more than one module loading plugins, but the 
majority of those 187 appear to be different projects.


Note that that's modules *loading plugins*, not plugins being 
provided...  so the total number of PyPI projects using entry points 
in some way is likely much higher, once you add in the plugins that 
these 187 lookups are, well, looking up.



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Nick Coghlan

On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson  wrote:
> I'm only referring to the infrastructure when I say "the current
> setup." I don't think repeatedly tweaking the tracker is likely to
> close more issues.

But tweaking the tracker to improve the way we *interact* with
potential contributors may get more developers in the long run, as
well as closing more issues. Currently, if a bug doesn't get responded
to immediately by people monitoring the bugs list, then there's no
easy way to go back and query "hey, are there any bugs nobody has even
looked at yet?". All this discussion is about is acknowledging that
that is something we should try to keep under control by listing them
in the weekly summary and by making them easy to look up.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Benjamin Peterson

2010/8/2 Nick Coghlan :
> On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson  wrote:
>> I'm only referring to the infrastructure when I say "the current
>> setup." I don't think repeatedly tweaking the tracker is likely to
>> close more issues.
>
> But tweaking the tracker to improve the way we *interact* with
> potential contributors may get more developers in the long run, as
> well as closing more issues. Currently, if a bug doesn't get responded
> to immediately by people monitoring the bugs list, then there's no
> easy way to go back and query "hey, are there any bugs nobody has even
> looked at yet?". All this discussion is about is acknowledging that
> that is something we should try to keep under control by listing them
> in the weekly summary and by making them easy to look up.

Well, I just feel like we keep changing things to little result,
creating an organic mess of fields and statuses. Adding more queries
is fine, but let's not bow to the temptation to add more fields.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Tracker status

2010-08-02 Thread Nick Coghlan

Are the bug tracker and meta-tracker down for anyone else, or is it just me?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Tracker down

2010-08-02 Thread Terry Reedy


6:22 EDT, tracker down and has been for a couple of minutes.
python.org and docs.python.org are fine.
Does the daemon program that now checks on Pypi also check the tracker?
Is there a particular place to report tracker down?
Or should I just assume someone else will notice and do something?

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker down

On Aug 02, 2010, at 06:25 PM, Terry Reedy wrote:

>6:22 EDT, tracker down and has been for a couple of minutes.
>python.org and docs.python.org are fine.
>Does the daemon program that now checks on Pypi also check the tracker?
>Is there a particular place to report tracker down?
>Or should I just assume someone else will notice and do something?

We've been talking about it on #python-dev and I've sent a message off to our
internal emergency list.  It's holding up the 2.6.6rc1 release.  (No, I do not
have access, nor can I answer your questions.)

-Barry

signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

On Mon, 2 Aug 2010 17:13:01 -0500
Benjamin Peterson  wrote:

> 2010/8/2 Nick Coghlan :
> > On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson  
> > wrote:
> >> I'm only referring to the infrastructure when I say "the current
> >> setup." I don't think repeatedly tweaking the tracker is likely to
> >> close more issues.
> >
> > But tweaking the tracker to improve the way we *interact* with
> > potential contributors may get more developers in the long run, as
> > well as closing more issues. Currently, if a bug doesn't get responded
> > to immediately by people monitoring the bugs list, then there's no
> > easy way to go back and query "hey, are there any bugs nobody has even
> > looked at yet?". All this discussion is about is acknowledging that
> > that is something we should try to keep under control by listing them
> > in the weekly summary and by making them easy to look up.
> 
> Well, I just feel like we keep changing things to little result,
> creating an organic mess of fields and statuses. Adding more queries
> is fine, but let's not bow to the temptation to add more fields.

FWIW, I completely agree with Benjamin.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is it intentional that "sys.debug = 1" is illegal in Python 2.7?

On Aug 01, 2010, at 09:56 PM, Benjamin Peterson wrote:

>2010/7/30 Barry Warsaw :
>>
>> It looks like Benjamin's change in r67171 was the relevant diff.
>
>The reason behind this was to make __debug__ assignment consistent
>with that of other reserved names. For example, x.None = 3 raised and
>thus, so should x.__debug__ = 3.

BTW, thanks to Georg for closing the documentation issue.
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

> Well, I just feel like we keep changing things to little result,
> creating an organic mess of fields and statuses. Adding more queries
> is fine, but let's not bow to the temptation to add more fields.

AFAICT, Ezio certainly wants to solve the status/stage/resolution
unclear overlap, and in general making the UI better (this means
removing things).

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

On 02/08/2010 22:18, Benjamin Peterson wrote:

2010/8/2 Terry Reedy:

On 8/2/2010 12:54 PM, Brian Curtin wrote:

On Mon, Aug 2, 2010 at 11:39, Ralf Schmittmailto:[email protected]>>  wrote:

Benjamin Petersonmailto:[email protected]>>
writes:

 >  Please, let's stop messing with the tracker for everything. I think
 >  the current set up works reasonably well, and we should focus on the
 >  real problem: manpower

Two months ago, I discovered and reported that about 1/5 of open issues had
no responses. Is that 'reasonably well'?

I'm only referring to the infrastructure when I say "the current
setup." I don't think repeatedly tweaking the tracker is likely to
close more issues.

I find this response quite pathetic.  The bulk of Terry's post has been 
snipped.  My own earlier response has been ignored.  Please Benjamin get 
out of your ivory tower, there are people such as myself who want to 
help, but we feel locked out.

Yes I am aware that I've more than trodden on a few toes as part of my 
learning curve, but all in all in I'm very proud of the fact that in my 
brief tenure I've helped the Python community.  The number of responses 
that I've had stating "Thanks I've forgotten that one" far out number 
the negative ones.  Actually I've never had any negative ones.  I guess 
that some of you are not as bold as I pretend to be.  Honestly by nature 
I'm very quiet and shy so when I start talking like this I'm being very 
serious and it's taken me years to get there.

Further, issues don't have to be closed, but what has to happen is that 
any issue that get raised *MUST* have a response.  This doesn't mean 
someone bumping the Python versions up five years after the issue was 
raised.

Fly back at me if you like.  I don't care about me.  I don't care about 
you.  I do care about Python.

Kindest regards.

Mark Lawrence.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts


On 02/08/2010 23:43, Antoine Pitrou wrote:

On Mon, 2 Aug 2010 17:13:01 -0500
Benjamin Peterson  wrote:


2010/8/2 Nick Coghlan:

On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson  wrote:

I'm only referring to the infrastructure when I say "the current
setup." I don't think repeatedly tweaking the tracker is likely to
close more issues.


But tweaking the tracker to improve the way we *interact* with
potential contributors may get more developers in the long run, as
well as closing more issues. Currently, if a bug doesn't get responded
to immediately by people monitoring the bugs list, then there's no
easy way to go back and query "hey, are there any bugs nobody has even
looked at yet?". All this discussion is about is acknowledging that
that is something we should try to keep under control by listing them
in the weekly summary and by making them easy to look up.


Well, I just feel like we keep changing things to little result,
creating an organic mess of fields and statuses. Adding more queries
is fine, but let's not bow to the temptation to add more fields.


FWIW, I completely agree with Benjamin.

Regards

Antoine.




I completely disagree.

Please see my other post.

Kindest regards.

Mark Lawrence.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

> What you might want to do is add new type fields to PEP 345,
> making it easier to identify and list packages that work as
> plugins for applications, e.g.
> 
> Type: Plugin for MyCoolApp
> 
> The MyCoolApp could then use the Type-field to identify all
> installed plugins, get their installation directories, etc.
> and work on from there.

Classifiers seem a good way to do that. They’re already defined in
accepted PEPs, extensible on demand, used by Web frameworks
components/applications/middlewares/things and other projects, and
queriable in PyPI.

We could use “Environment :: Plugins” and “Framework :: Something” or
define a new classifier (not all applications are frameworks, and
“plugins” seems a very strange value for “environment”).

It would be the first time that a classifier triggers specific
processing from distutils though, so we may prefer to define a new
Provides-Plugin field for consistency and explicitness.

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

2010-08-02 Thread David Bolen

Michael Foord  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 the command line (well, or Emacs shells), I think either
approach is workable for command line only tools.

I will say that if I need to find preferences or application-specific
files my first inclination is absolutely to look under ~/Library.
That's the "platform" location (just as looking for dot files under
Linux is my first choice, or "Documents and Settings/" for
Windows).  I don't think I shift mental gears automatically for
command line tools versus not, unless I have some prior knowledge
about the tool.

With that said, given all the third party and Unix-oriented stuff I
install under OSX, it's hardly rare (as has been pointed out
elsewhere) to be working with ~/. either, so it's not like
I'd consider it that unusual to find that's where I need to go.

In glancing at my current system, it does appear command line only
tools are more commonly using ~/. files rather than under
~/Library (which tends to be stuff packaged up as an application in
/Applications, even if they can also be run from the command line).

Though it might be a biased sample set since I'm more likely to have
brought in command line tools to OSX from the Unix side of things, I
suspect that's true of other users of command line tools as well.

I will say that it's rarer to find a native (Cocoa/Carbon) GUI
application that doesn't store preferences or application settings
beneath ~/Library, and in such a case I'd feel they were more "wrong"
and non-conforming if they didn't do that.  So it depends on how
"native" an application wishes to be perceived.  I guess in thinking
about it while writing this, having something installed in
/Applications is more strongly linked with ~/Library in my mind than
other tools.

Of course, even with /Applications, non-native GUI apps are more of a
mixed bag.  For example, the X versions of Gimp and Inkscape - Gimp
properly uses "~/Library/Application Support" while Inkscape still
uses ~/.inkscape.  Of course, as X apps, neither truly feels native or
conforming anyway.

So that probably helps make things as clear as mud :-)

-- David

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

On Tue, 03 Aug 2010 00:00:46 +0100
Mark Lawrence  wrote:
> 
> Fly back at me if you like.  I don't care about me.  I don't care about 
> you.  I do care about Python.

Well, you should care about people. Free software is as much as about
building welcoming communities than it is about writing good software.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts


On 03/08/2010 00:24, Antoine Pitrou wrote:

On Tue, 03 Aug 2010 00:00:46 +0100
Mark Lawrence  wrote:


Fly back at me if you like.  I don't care about me.  I don't care about
you.  I do care about Python.


Well, you should care about people. Free software is as much as about
building welcoming communities than it is about writing good software.

Regards

Antoine.



Do you build welcoming communities by ignoring posts for ten years?

Mark.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Benjamin Peterson

2010/8/2 Mark Lawrence :
> On 02/08/2010 22:18, Benjamin Peterson wrote:
>> I'm only referring to the infrastructure when I say "the current
>> setup." I don't think repeatedly tweaking the tracker is likely to
>> close more issues.
>>
>
> I find this response quite pathetic.  The bulk of Terry's post has been
> snipped.  My own earlier response has been ignored.  Please Benjamin get out
> of your ivory tower, there are people such as myself who want to help, but
> we feel locked out.

You feel locked out by the current tracker?



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Steven D'Aprano

On Tue, 3 Aug 2010 04:27:53 am Terry Reedy wrote:
> On 8/2/2010 12:54 PM, Brian Curtin wrote:
> > On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt  > > wrote:
> >
> > Benjamin Peterson  > >
> >
> > writes:
> >  > Please, let's stop messing with the tracker for everything.
> >  > I think the current set up works reasonably well, and we
> >  > should focus on the real problem: manpower
>
> Two months ago, I discovered and reported that about 1/5 of open
> issues had no responses. Is that 'reasonably well'? 

I don't know. What percentage of new issues get ever get a response? My 
wild guess is that it's probably about 99.9%, but the 0.1% that don't 
remain languishing forever, skewing the statistics. What's the average 
age of those 1 in 5 issues? Maybe 1 in 5 is exactly right, given the 
realities of people available to respond to issues versus people 
available to report issues. Maybe 1 in 5 is supernaturally good, given 
our resources available.

-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

On Aug 02, 2010, at 06:57 PM, Benjamin Peterson wrote:

>You feel locked out by the current tracker?

I do, but that's only because bugs.python.org is currently pinin' for the
fjords. ;)

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382 progress: import hooks

2010-08-02 Thread Brett Cannon

On Fri, Jul 23, 2010 at 09:54, P.J. Eby  wrote:

> At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:
>
>
>
>  On Thu, Jul 22, 2010 at 19:19, P.J. Eby <
>> [email protected]> wrote:
>>
>> What does "is not a package" actually mean in that context?
>>
>>
>> The module is a module but not a package.
>>
>
> Um...  that's not any clearer.  Are you saying that a module of the same
> name takes precedence over a package?  Is that the current precedence as
> well?
>

No, packages take precedence. I meant that something is a module but it is
not a package; a package implicitly includes a module, but a module is not
automatically a package.


>
>
>  Regarding load_module_with_path(), how does its specification differ from
>> simply creating a module in sys.modules, setting its __path__, and then
>> invoking the standard load_module()? Ā (i.e., is this method actually
>> needed, since a correct PEP 302 loader *must* reuse an existing module
>> object in sys.modules)
>>
>>
>> It must reuse the module itself but a proper reload would reset __path__
>> as leaving it unchanged is not a proper resetting of the module object. So
>> this module is needed in order to force the loader
>>
>
> Um, no.  Reloading doesn't reset the module contents, not even __path__.
>  Never has, from Python 2.2 through 2.7 -- even in 3.1.  At least, not for
> normal filesystem .py/.pyc files.  (I tested with 'os', adding an extra
> 'foo' attribute, and also setting a __path__; both were unaffected by
> reload(), in all 7 Python versions.
>
> Perhaps you're saying this happens with zipfiles, or packages that already
> have a __path__, or...?
>

It's how I implemented it in importlib and it passes Python's unit test
suite that way; zipimport also does it this way as it too does not
differentiate a reload from a clean load beyond grabbing the module from
sys.modules if it is already there. PEP 302 does not directly state that
reloading should not reset the attributes that import must set, simply that
a module from sys.modules must be reused. Since zipimport does it this way I
wouldn't count on other loaders not setting __path__.


>
>
>
>>
>> Am I correct in understanding that, as written, one would have to redefine
>> __import__ to implement this in a library for older Python versions? Ā Or is
>> it implementable as a meta_path importer?
>>
>>
>>
>> Redefine __import__ (unless Martin and I are missing something, but I
>> tried to think of how to implement this use sys.meta_path and couldn't come
>> up with a solution).
>>
>
> I'm thinking it *could* be done with a meta_path hook, but only by doubling
> the search length in the event that the search failed.  That seems a bit
> icky, but replacing the entire import process seems ickier (more code
> surface to maintain, more bug potential) in the case of supporting older
> Pythons.
>
>
I'm personally not worried about supporting older versions of Python as this
is a new feature. Better to design it properly than come up with some hack
solution as we will all have to live with this for a long time.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

2010-08-02 Thread Ned Deily

In article <[email protected]>,
 Michael Foord  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 in ~.

Terminal.app does?  What file is that?

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

2010-08-02 Thread Steve Holden

On 8/2/2010 7:39 PM, Mark Lawrence wrote:
> On 03/08/2010 00:24, Antoine Pitrou wrote:
>> On Tue, 03 Aug 2010 00:00:46 +0100
>> Mark Lawrence  wrote:
>>>
>>> Fly back at me if you like.  I don't care about me.  I don't care about
>>> you.  I do care about Python.
>>
>> Well, you should care about people. Free software is as much as about
>> building welcoming communities than it is about writing good software.
>>
>> Regards
>>
>> Antoine.
>>
>>
> Do you build welcoming communities by ignoring posts for ten years?
> 
No, you don't, and the current discussion about how to ensure that bug
reporters get at least the courtesy of a relatively quick reply is one
of the most promising developments in building a welcoming community
that I can remember.

I realise that some people are happier focusing purely on technical
issues, and that's fine. But let's not let that stop us trying to build
a crew of ambassadors to take care of the more touchy-feely side of
things as long as it operates to the language's ultimate benefit.

It takes all sorts to make a world ...

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker status

2010-08-02 Thread David Stanek

On Mon, Aug 2, 2010 at 6:17 PM, Nick Coghlan  wrote:
> Are the bug tracker and meta-tracker down for anyone else, or is it just me?
>

It is down for me as well. It appears to be accepting the connection
and then just doesn't return any content.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r83543 - python/branches/py3k/Lib/test/regrtest.py

2010-08-02 Thread R. David Murray

On Mon, 02 Aug 2010 20:59:52 +0200, georg.brandl  
wrote:
> Author: georg.brandl
> Date: Mon Aug  2 20:59:52 2010
> New Revision: 83543
> 
> Log:
> #8560: add progress indicator to regrtest.
[...]
> @@ -517,6 +517,9 @@
>  else:
>  tests = iter(selected)
>  
> +tests = list(tests)

I guess you didn't notice that just above this code is a clause that
says 'if forever' which implements -F/--forever by making tests into a
generator that never runs out...

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker status

2010-08-02 Thread Ray Allen

Down for me as well. Initially I though it was shield by "Great Firewall" since
I'm from China.

On Tue, Aug 3, 2010 at 9:29 AM, David Stanek  wrote:

> On Mon, Aug 2, 2010 at 6:17 PM, Nick Coghlan  wrote:
> > Are the bug tracker and meta-tracker down for anyone else, or is it just
> me?
> >
>
> It is down for me as well. It appears to be accepting the connection
> and then just doesn't return any content.
>
> --
> David
> blog: http://www.traceback.org
> twitter: http://twitter.com/dstanek
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ysj.ray%2Bpython-dev%40gmail.com
>



-- 
Ray Allen
Best wishes!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Postponing 2.6.6rc1

For several reasons, I'm postponing 2.6.6rc1 for one day.  Ezio has been doing
a lot of great work on the test suite, but there are still a few things to
fix.  On top of that, bugs.python.org crashed and we're waiting for our
hosting company to wake up and reboot it.

We'll try again, same time tomorrow: 2200 UTC.  Come join us on #python-dev if
you want to watch the circus. :)

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] checkins reply-to change

2010-08-02 Thread R. David Murray

On Mon, 02 Aug 2010 21:51:11 -0400, "R. David Murray"  
wrote:
> On Mon, 02 Aug 2010 20:59:52 +0200, georg.brandl  
> wrote:
> > Author: georg.brandl
> > Date: Mon Aug  2 20:59:52 2010
> > New Revision: 83543

Hmm.  Looking at the format of this message as it came back to me,
I can see that the change to the Reply-To for checkins breaks my email
filtering.  Previously I could catch replies to my checkins by looking
for my committer id in the 'To' field, and I would put those in a special
folder, and so I would see right away that I had a message.  Now they
just wind up in the general python-dev and python-checkins folders,
which I do not necessarily read every day.  So this change will actually
slow down my noticing replies.

I can't see any reliable identifying characteristic of the message
which I could use to move it into the 'alert' folder.  Checking the
message body for 'r.david.murray ' will work most of
the time, if people's email clients follow the normal quoting conventions
and the reply header is left in.  But it isn't going to be 100% reliable.

Would it be possible to include the committer id in the 'realname'
field on the To address? (Or on the CC address).

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r83596 - in python/branches/release26-maint: Doc/library/constants.rst

2010-08-02 Thread Ezio Melotti


 Hi,

On 03/08/2010 0.47, georg.brandl wrote:

Author: georg.brandl
Date: Mon Aug  2 23:47:02 2010
New Revision: 83596

Log:
Merged revisions 83567 via svnmerge from
svn+ssh://[email protected]/python/branches/release27-maint


   r83567 | georg.brandl | 2010-08-02 22:32:03 +0200 (Mo, 02 Aug 2010) | 9 lines

   Merged revisions 83552 via svnmerge from
   svn+ssh://[email protected]/python/branches/py3k

   
 r83552 | georg.brandl | 2010-08-02 21:36:36 +0200 (Mo, 02 Aug 2010) | 1 
line

 #9438: clarify that constant names also cannot be assigned as attributes.
   



Modified:
python/branches/release26-maint/   (props changed)
python/branches/release26-maint/Doc/library/constants.rst

Modified: python/branches/release26-maint/Doc/library/constants.rst
==
--- python/branches/release26-maint/Doc/library/constants.rst   (original)
+++ python/branches/release26-maint/Doc/library/constants.rst   Mon Aug  2 
23:47:02 2010
@@ -3,7 +3,6 @@

  A small number of constants live in the built-in namespace.  They are:

-
  .. data:: False

 The false value of the :class:`bool` type.
@@ -39,16 +38,23 @@

 Special value used in conjunction with extended slicing syntax.

-   .. XXX Someone who understands extended slicing should fill in here.
-

  .. data:: __debug__

 This constant is true if Python was not started with an :option:`-O` 
option.
-   Assignments to :const:`__debug__` are illegal and raise a 
:exc:`SyntaxError`.
 See also the :keyword:`assert` statement.


+.. note::
+
+   The names :data:`None` and :data:`__debug__` cannot be reassigned
+   (assignments to them, even as an attribute name, raise :exc:`SyntaxError`),
+   so they can be considered "true" constants.
+
+   .. versionchanged:: 2.7
+  Assignments to ``__debug__`` as an attribute became illegal.


this shouldn't be here.


+
+
  Constants added by the :mod:`site` module
  -

___
Python-checkins mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-checkins



Best Regards,
Ezio Melotti
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] co_firstlineno on decorated functions

2010-08-02 Thread Eli Bendersky

[Since I received no replies on this in python-list, perhaps python-dev is
more appropriate]


Hello,

I've been tinkering with __code__.co_firstlineno for testing the trace.py
module (Python Issue 9315), and ran into an interesting problem. Consider
this code:


def dummydecorator(f):
return f

def foo(a):
return a

@dummydecorator
def bar(a):
return a


if __name__ == "__main__":
print foo.__code__.co_firstlineno
print bar.__code__.co_firstlineno


The first print out correctly specifies the line "def foo" is in. However,
the second one points to the line with "@dummydecorator" instead of "def
bar". [Python 2.6]

The side-effects of this behavior can be easily seen in the output of
modules like trace and profile. Would you say it's normal, or could this be
considered a bug?

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 382 progress: import hooks


At 05:28 PM 8/2/2010 -0700, Brett Cannon wrote:


On Fri, Jul 23, 2010 at 09:54, P.J. Eby 
<[email protected]> wrote:

At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:



On Thu, Jul 22, 2010 at 19:19, P.J. Eby 
<[email protected]> wrote:


What does "is not a package" actually mean in that context?


The module is a module but not a package.


Um... Â that's not any clearer. Â Are you saying that a module of 
the same name takes precedence over a package? Â Is that the current 
precedence as well?



No, packages take precedence. I meant that something is a module but 
it is not a package; a package implicitly includes a module, but a 
module is not automatically a package.


That explanation still isn't making things any clearer for me.  That 
is, I don't know how to get from that statement to actual code, even 
if I were writing a filesystem or zip importer, let alone anything more exotic.



 zipimport also does it this way as it too does not differentiate a 
reload from a clean load beyond grabbing the module from 
sys.modules if it is already there. PEP 302 does not directly state 
that reloading should not reset the attributes that import must 
set, simply that a module from sys.modules must be reused. Since 
zipimport does it this way I wouldn't count on other loaders not 
setting __path__.


Fair enough, though certainly unfortunate.  In particular, it means 
that it's not actually possible to correctly/completely implement PEP 
382 on any already-released version of Python, without essentially 
replacing zipimport.  (Unless the spec can be tweaked a bit.)



I'm personally not worried about supporting older versions of Python 
as this is a new feature. Better to design it properly than come up 
with some hack solution as we will all have to live with this for a long time.


Currently, older Pythons are the only versions I *do* support, so I'm 
very concerned with it.  Otherwise, I'd not be asking all these questions.  ;-)


Personally, I think there are features in the PEP that make things 
unnecessarily complicated - for example, supporting both __init__.py 
*and* .pth files in the same directory.  If it were either/or, it 
would be a LOT easier to implement on older Pythons, since it 
wouldn't matter when you initialized the __path__ in that case.


(By the way, there were some other questions I asked about the PEP 
382 revisions, that you didn't reply to in previous emails (such as 
the format of the strings to be returned by find_path()); I hope 
either you or Martin can fill those in for me, and hopefully update 
the PEP with the things we have talked about in this thread.)


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

Ron Adam writes:

 > Yes, but when I do it, I either get a single specific day, or 2700
 > issues.

If your query specifies an activity date, you will get only issues
with activity that date.  If it sorts or groups on activity date, you
will get all issues (subject to other conditions), but you can easily
view either the first 50 or the last 50 by choosing direction of sort.

 > Have you tried it?  I tried various different spelling and could
 > only enter one specific day, "today" works, but "1 month" or "2
 > years" doesn't.

I hadn't tried it at that time; I just stated a general fact about
Roundup's capabilities.  Sorry for not making that clear.

A correct interval syntax, which was tested and works in the creation
and activity fields of XEmacs's Roundup tracker (Python's is refusing
to talk to me at the moment) is "from 2010-06-01 to 2010-07-31".
Another is "from -1m" (meaning from one month ago to now; other units
are "y" for year and "d" for day).

Many others are described in the Roundup User guide.  I don't have an
URL for the current upstream version offhand, but one adapted for
XEmacs's tracker is here:

http://tracker.xemacs.org/XEmacs/its/@@file/user_guide.html#interval-properties

(this part is just the upstream version verbatim, a couple years old).

 > What does work is entering a partial date, ie...  2010-07 for all issues 
 > with activity this july. Or 2010 for all issues with activity this year.

Warning: This didn't work as expected for me with the "from ... to
..."  syntax.  Apparently in from/to syntax, a number with no hyphens
is interpreted as day-of-month, and with one hyphen it's month-day,
with no sanity checking.  I'm not sure what it thinks 2010-07 means,
but it gave me everything in our tracker. :-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

Mark Lawrence writes:

 > I completely disagree.

Mark, please stop being disagreeable.  The above is *not true*.
You've made no statements I can recall insisting that the only way to
skin a cat is to use a GNOME theme, only that the cat needs skinning.

Before you posted that, Benjamin had already clarified that his worry
is that new fields will be added to the tracker, or available values
for some fields will be changed.  He's right, experience shows that
adding fields to the tracker confuses reporters and responders alike,
unless it's done very carefully.

But he has no objection to improving the tracker's reporting
capabilities.  I think the tracker currently has plenty of information
to do a much better job of responding in a timely fashion than was
done in the past, so there's plenty of room for you to do your work
without imposing new bureaucracy on others, yes?  There's no real
disagreement here (unless you think it would be a good idea for
Benjamin to stop doing release manager and do issue triage instead, in
which case, I certainly hope he disagrees!)


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts