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

[M.-A. Lemburg]

Éric Araujo wrote:
>> 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”).

This would work to mark plugins as such, but we'd still would
have to have a field to name the app they belong to and
I don't think that the process of adding new classifiers is
flexible enough to handle those names.

A Type field would be under application control and allow easy
discovery of installed plugins for a specific app.

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

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 03 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
Python-Dev@python.org
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

[M.-A. Lemburg]

P.J. Eby wrote:
> 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.

I don't think that's a problem: the SQLite database would be a cache
like e.g. a font cache or TCSH command cache, not a replacement of
the meta files stored in directories.

Such a database would solve many things at once: faster access to
the meta-data of installed packages, fewer I/O calls during startup,
more flexible ways of doing queries on the meta-data, needed for
introspection and discovery, etc.

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

setuptools entry points are just one way of doing plugins. There
are other such systems that work well and which do not require
any special administration or setup, simply because the application
using the plugins defines the plugin protocol.

Since you are into comparing numbers, you might want to count
the number of Zope plugins that are available on PyPI and its plugin
system has been around much longer than setuptools has been.
I don't think that proves anything, though.

I simply don't see a good reason to complicate the Python
packaging system by trying to add a particular plugin support
to it.

Plugins are application scope features and should be treated
as such.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 03 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
Python-Dev@python.org
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

[Stephen J. Turnbull]

Steve Holden writes:

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

C'mon Steve, it's not hard to see that's unfair.  Mark deserves to be
complimented for the work he's doing, that side of your comment is
perfectly fair, but you of all people should take care to recognize
that python-dev is "welcoming people to the community" every day.

As Steven d'Aprano pointed out (admittedly with a bit of hyperbole) a
very high percentage of issues (about 97%) do get some response, and
nearly 87% of all issues ever submitted to Python have already been
closed (based on the end-of-July tracker summary).  Remember that many
of those that are still open are open because nobody's willing to call
them "walking dead" and close them as "unsalvagable."  Any serious
effort at triage by the people who would do the work to resolve them
will surely result in a very large fraction closed with "wontfix",
what is known as "a self-fulfilling prophecy".  It's not clear that's
a win; some users surely think so, others not.

Now, let's take a look at some recent numbers about issue flows.  Of
the 264 issues submitted in June, 126 (47.7%) have already been
closed.  Of the 138 still open, 38 (27.5% of open issues) have
activity in July, meaning that 62.1% of the sample of 264 recent
issues have either been resolved or are receiving ongoing support (and
maybe better than that).[1][2]

In fact, the numbers I'm looking at are really promising, too, and the
whole Python crew deserves a big round of applause for producing them
every day!  Those numbers mean that not only have hundreds of users
been "welcomed to the community", but a huge majority of them got some
kind of fix for their problems, too, or at least a comment from a
qualified expert.  That compares very favorably with my experience
with other products, both commercial and volunteer-developed.

I don't claim that these numbers are a reason for doing nothing about
issues that have been hanging fire for years.  But it clearly suggests
that those hangfires are mostly very hard issues for some reason.
They are not a systematic problem with the project's overall response
to issues; it is extremely effective in dealing with them.

What's left is a pure PR effort:

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

Nobody's interfering with that *at all*.  In fact, it's quite clear
that everybody is happy with Mark's work, and wants him to continue.
They just want him to give up on the idea that they're going to put in
a lot more effort on resolving issues than they already do, and his
claim that something's horribly wrong.  The numbers above show why.


Footnotes: 
[1]  "June" and "July" are approximations.  First, *creation date* was
queried with "from -2m to -1m", and then was filtered with *activity*
"from -1m" and *status* "open".

[2]  These are conservative estimates of activity in my opinion.  Eg,
depending on how many of the open issues not touched in July are
waiting on OP response, return of a developer from vacation, or
perhaps a release before being committed to a branch, it may be that
the number of issues waiting for developer attention is much smaller
than 100.

It's hard to develop more precise statistics, and this is obviously
not a random sample.  But the sample is probably not unrepresentative.
The corresponding numbers for May submissions, closures to date, and
June-July activity are 281, 151 (53.7%), and 44 (33.8% of still open
issues).  Interestingly enough, for issues submitted in May and still
open, the June activity is 23 and the July activity is 21, so they are
entirely disjoint!  This means that delays of a month or so don't
imply that an issue is being dropped on the floor at all in the May
sample, just that half the time it takes a developer a month or two to
get to his issues.

Footnote 1 applies here, too.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] logging package vs unicode

[INADA Naoki]

FWIW, I think the best way to avoid UnicodeError is: Don't use chars
out of ASCII in Python2.
I prefer '%r' to '%s' because it escapes chars not printable or out of
ASCII with backslash.

On Mon, Jul 5, 2010 at 9:34 PM, Chris Withers  wrote:
> Hi All,
>
> The documentation for the logging package doesn't include any mention of
> unicode.
>
> What's the recommended usage in terms of passing unicode vs encoded strings?
>
> How does this differ from Python 2 to Python 3?
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
>            - http://www.simplistix.co.uk
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>



-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
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]

On 03/08/2010 09:28, M.-A. Lemburg wrote:

P.J. Eby wrote:
   

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.
 

I don't think that's a problem: the SQLite database would be a cache
like e.g. a font cache or TCSH command cache, not a replacement of
the meta files stored in directories.

Such a database would solve many things at once: faster access to
the meta-data of installed packages, fewer I/O calls during startup,
more flexible ways of doing queries on the meta-data, needed for
introspection and discovery, etc.
   


Sounds good as an "optional extra" (i.e. it should be safe to completely 
delete the cache file and still have everything work) to me. If the API 
for using the feature is worked out well first this could be done as a 
behind the scenes optimisation...


   

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.
 

setuptools entry points are just one way of doing plugins. There
are other such systems that work well and which do not require
any special administration or setup, simply because the application
using the plugins defines the plugin protocol.
   
Right, and those won't magically stop working if this proposal is 
implemented.



Since you are into comparing numbers, you might want to count
the number of Zope plugins that are available on PyPI and its plugin
system has been around much longer than setuptools has been.
I don't think that proves anything, though.

I simply don't see a good reason to complicate the Python
packaging system by trying to add a particular plugin support
to it.

Plugins are application scope features and should be treated
as such.

   
The fact is that entry points *are* widely used and solve a problem that 
you *can't* solve without some feature like this. The success of entry 
points demonstrates their utility (and you talk vaguely about 'problems' 
setuptools caused without any concrete examples - do you know of any 
*specific* difficulties with entry points?).


I doubt I will change your mind, but the bottom line is that if you 
don't like this feature you don't have to use it. For applications that 
want it (like the unittest plugin system) it will be *enormously* useful 
and *reduce* complexity for the user (by allowing simpler plugin 
management tools).


All the best,

Michael

--
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
Python-Dev@python.org
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

[M.-A. Lemburg]

Michael Foord wrote:
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>   
>>> 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.
>>>  
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a database would solve many things at once: faster access to
>> the meta-data of installed packages, fewer I/O calls during startup,
>> more flexible ways of doing queries on the meta-data, needed for
>> introspection and discovery, etc.
>>
> 
> Sounds good as an "optional extra" (i.e. it should be safe to completely
> delete the cache file and still have everything work) to me. If the API
> for using the feature is worked out well first this could be done as a
> behind the scenes optimisation...

True, but is also allows more freedom in using existing resources:

The data put into the PLUGINS file is essentially not needed, since
this can be had from the meta-data (provided this gets some extra
fields for describing the plugin nature).

>>> 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.
>>>  
>> setuptools entry points are just one way of doing plugins. There
>> are other such systems that work well and which do not require
>> any special administration or setup, simply because the application
>> using the plugins defines the plugin protocol.
>>
> Right, and those won't magically stop working if this proposal is
> implemented.

Right, but the proposal does add an extra burden on the package
manager tools and it codifies one specific way of implementing
plugins.

>> Since you are into comparing numbers, you might want to count
>> the number of Zope plugins that are available on PyPI and its plugin
>> system has been around much longer than setuptools has been.
>> I don't think that proves anything, though.
>>
>> I simply don't see a good reason to complicate the Python
>> packaging system by trying to add a particular plugin support
>> to it.
>>
>> Plugins are application scope features and should be treated
>> as such.
>>
>>
> The fact is that entry points *are* widely used and solve a problem that
> you *can't* solve without some feature like this. The success of entry
> points demonstrates their utility (and you talk vaguely about 'problems'
> setuptools caused without any concrete examples - do you know of any
> *specific* difficulties with entry points?).

Not specific to entry points, but I do know a lot about of problems
that setuptools has introduced (and didn't want to start yet another
flame war based on these ;-).

> I doubt I will change your mind, but the bottom line is that if you
> don't like this feature you don't have to use it. For applications that
> want it (like the unittest plugin system) it will be *enormously* useful
> and *reduce* complexity for the user (by allowing simpler plugin
> management tools).

Sure and those tools can use such a system. No question there :-)

Maybe I just have to spell things out more clearly:

I support the idea of adding better query tools to the
installed package meta-data to make it easier to write plugin
systems or simplify existing ones.

I don't support the idea of using central configuration files
for plugins that span multiple applications (this reminds me
a lot of the early Windows win.ini file days and all the problems
this caused back then). It's better to have per application
configurations

Re: [Python-Dev] No response to posts

[Steve Holden]

On 8/3/2010 4:56 AM, Stephen J. Turnbull wrote:
> Steve Holden writes:
> 
>  > 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.
> 
> C'mon Steve, it's not hard to see that's unfair.  Mark deserves to be
> complimented for the work he's doing, that side of your comment is
> perfectly fair, but you of all people should take care to recognize
> that python-dev is "welcoming people to the community" every day.
> 
[...]

Well if my response exaggerated the situation (which your statistics
seem to make clear it did) then I am very pleased to hear it, and
apologize unreservedly to anyone who feels slighted by my remarks.

I agree the developers as a whole do a magnificent (and largely unsung)
job, and I suspect that not many people realise what a struggle it has
been maintaining four separate branches in the run-up to 2.x
end-of-life. Now we are down to three, with presumably a much more
limited requirement to back-port changes, things should be a little less
stressful.

Particularly when the issue tracker works ...

>  > 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.
> 
> Nobody's interfering with that *at all*.  In fact, it's quite clear
> that everybody is happy with Mark's work, and wants him to continue.
> They just want him to give up on the idea that they're going to put in
> a lot more effort on resolving issues than they already do, and his
> claim that something's horribly wrong.  The numbers above show why.

I don't think anyone can criticize those whose first priority is the
development of code. That is, after all, why we are here.

I believe Mark's claim isn't that something's horribly wring with the
whole process. It seems to me that something would be *really* wrong if
nobody cared about the relatively few issues that had received no
response. The fact that Mark is on that case means that those who want
to shrug their shoulders about it can do so.

Python is "a broad church" and not everyone has an appetite for all
aspects of the development process. I see the current efforts to ensure
that new issues *all* receive an effective as complementary to the other
activities that have always taken place.

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
Python-Dev@python.org
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

[Antoine Pitrou]

On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg"  wrote:
> > 
> > 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.
> 
> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
> 
> Such a database would solve many things at once: faster access to
> the meta-data of installed packages, fewer I/O calls during startup,
> more flexible ways of doing queries on the meta-data, needed for
> introspection and discovery, etc.

If the cache can become stale because of system package management
tools, how do you avoid I/O calls while checking that the database is
fresh enough at startup?

Regards

Antoine.


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

Re: [Python-Dev] co_firstlineno on decorated functions

[Nick Coghlan]

On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky  wrote:
> 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?

Since the decorator is as much a part of the function definition as
the def line is, I would say that it is correct (the name says
"firstlineno", not "deflineno"). inspect.getsource() and friends
actually rely on this behaviour, so changing it really isn't an
option.

However, that does mean *using* it as though it always points to the
def line is incorrect, suggesting there are related bugs in trace and
profile.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
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

[Nick Coghlan]

On Tue, Aug 3, 2010 at 6:56 PM, Stephen J. Turnbull  wrote:
> As Steven d'Aprano pointed out (admittedly with a bit of hyperbole) a
> very high percentage of issues (about 97%) do get some response, and
> nearly 87% of all issues ever submitted to Python have already been
> closed (based on the end-of-July tracker summary).  Remember that many
> of those that are still open are open because nobody's willing to call
> them "walking dead" and close them as "unsalvagable."  Any serious
> effort at triage by the people who would do the work to resolve them
> will surely result in a very large fraction closed with "wontfix",
> what is known as "a self-fulfilling prophecy".  It's not clear that's
> a win; some users surely think so, others not.

There's at least one low priority bug that I submitted a couple of
years ago (doctest freaking out a bit if you use angle brackets in the
nominal filename) that is still open because the workaround of "well,
don't do that then" is so much easier than actually figuring out why
it is freaking out (my initial diagnosis pointed the finger at one of
the regular expressions in linecache, but I never actually nailed a
definitive culprit). Normal filenames don't usually contain angle
brackets, and in my case, it was a completely invented filename so I
could easily drop the angle brackets from the name.

It's a real bug though, so I'd prefer not to see it closed as "wontfix".

While that kind of bug is low on the effort/reward scale from an
absolute point of view, someone could still learn a lot on a personal
level from fixing it. Having it brought to my attention again recently
let me provide some better information on how to reproduce it by
hacking a bit on the current test suite, so someone looking to learn
more about the dev process could definitely work through distilling it
down into a dedicated test case and then figuring out how to make the
new test case pass.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
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

[Ronald Oussoren]

On 2 Aug, 2010, at 2:03, Tarek Ziadé wrote:

> On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord  
> wrote:
>> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>> 
>>> [snip...]
 
 I don't think that unittest would use a distutils2 (or pkgutil) supplied
 API
 for activation.
 
>>> 
>>> But the discovery API you will use might just simply filter out
>>> disabled plugins.
>>> 
>> 
>> I did consider asking this but thought it was a silly question - there
>> *must* be an API to get all plugins otherwise applications couldn't activate
>> or deactivate them (or allow their users to do this) - and then how could
>> users activate a non-active plugin? (I guess there could be private APIs
>> that only distutils2 is supposed to use, or the script that you mentioned.)
> 
> yes, there will be a way to retrieve them all
> 
> ...
>> It sounds like it can fairly easily be bolted on as a new feature set later
>> *anyway*, so dropping it for now simplifies the initial implementation.
> 
> but then we would be back to the problem mentioned about entry points:
> installing projects can implicitly add a plugin and activate it, and break
> existing applications that iterate over entry points without further
> configuration. So being able to disable plugins from the beginning seems
> important to me

It should be the role of the application to manage which plugins are enabled 
and not the library.  The library can provide an API that applications can use 
to manage which plugins are activated, but the library should IMHO not force a 
specific scheme onto the application.

Keeping management outside of the libraries allows applications to provide 
their own mechanisms for it, such as the unittest2 configuration or even a 
configuration screen in a GUI application.   The latter is what's the most 
interesting to me, have a GUI application where users can optionally add 
functionality by adding a egg-file[*] to a plugin directory.  It would be nice 
if I could use the stdlib plugin API for that instead having to use my own 
inventions.

BTW. The spec seems to assume that the PLUGINS file is writeable, that needn't 
be true for example when packages are installed by a system tool or on 
multi-user systems where only sysadmins can install packages in a central 
site-packages location.

Ronald

[*] that is, a zipfile containing an installed distutils distribution

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

Re: [Python-Dev] co_firstlineno on decorated functions

[Antoine Pitrou]

On Tue, 3 Aug 2010 22:25:01 +1000
Nick Coghlan  wrote:
> On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky  wrote:
> > 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?
> 
> Since the decorator is as much a part of the function definition as
> the def line is, I would say that it is correct (the name says
> "firstlineno", not "deflineno").

That's debatable. Since writing:

@b
def a():
...

is equivalent to:

def a():
...
a = b(a)

and in the latter case co_firstlineno points to the "def a()" line.

Furthermore, co_firstlineno is an attribute of the code object, not the
function object, so it shouldn't ideally depend on whether a decorator
was applied or not.

Regards

Antoine.


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

Re: [Python-Dev] co_firstlineno on decorated functions

[Nick Coghlan]

On Tue, Aug 3, 2010 at 10:48 PM, Antoine Pitrou  wrote:
> Furthermore, co_firstlineno is an attribute of the code object, not the
> function object, so it shouldn't ideally depend on whether a decorator
> was applied or not.

You cut the part about the inspect module (and no doubt other code)
relying on the current meaning, though. While I'd agree with you for a
clean slate definition, that's not what we're dealing with here:
"co_firstlineno" has an existing meaning, and it *isn't* "the line
containing the def keyword", it's "the first line of the function,
including any decorator lines". The decision could (and arguably
should) have gone the other way when decorator syntax was first added,
but changing our minds now would be making the situation worse rather
than better.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
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

[Ray Allen]

Is the tracker OK now?

-- 
Ray Allen
Best wishes!
___
Python-Dev mailing list
Python-Dev@python.org
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

[Dirkjan Ochtman]

On Tue, Aug 3, 2010 at 07:01, Ray Allen  wrote:
> Is the tracker OK now?

Works for me.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
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

[Fred Drake]

On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen  wrote:
> Is the tracker OK now?

It's working for me.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
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

[Florent Xicluna]

There's no new issue posted this morning.
I tried to post an issue, and an error occurred on submit.

So...

-- 
Florent


2010/8/3 Fred Drake 

> On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen  wrote:
> > Is the tracker OK now?
>
> It's working for me.
>
>
>   -Fred
>
> --
> Fred L. Drake, Jr.
> "A storm broke loose in my mind."  --Albert Einstein
> ___
>
___
Python-Dev mailing list
Python-Dev@python.org
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

[Stephen J. Turnbull]

Steve, thanks for your care-full reply.

Steve Holden writes:

 > Particularly when the issue tracker works ...

Well, sometimes it's down.But Roundup is more flexible as
a database engine than a lot of people realize.  Better docs would
help, I'm sure, but we can also create new standard queries quite
easily.  While it's not really possible to get good statistics on
time-to-close, for example, we can do a pretty good job of identifying
"ignored" issues, and we can target reducing the count to some extent.

 > It seems to me that something would be *really* wrong if
 > nobody cared about the relatively few issues that had received no
 > response.

Phrased as "care about", that's a straw man.  Pretty much everybody
cares about those issues.  Phrased as "care for", well, now we've
found the friction, I suspect.  Applying real TLC to many of the
hangfire issues is going to require highlevel skills and/or lots of
time, resources that are scarce around here (because they're being
applied to other important tasks).

 > The fact that Mark is on that case means that those who want
 > to shrug their shoulders about it can do so.

Indeed, that's the way I feel about it.  But Mark clearly doesn't
think he alone is enough.  There's a genuine difference of opinion
here somewhere, even if I've misrepresented Mark's opinion.

Maybe it would help if we scheduled a bug day, and try to make sure
that a couple senior devs rendezvous with Mark so he can advocate some
of the issues that bother him the most, and he can get a look at the
issue resolution process in action.

 > I see the current efforts to ensure that new issues *all* receive
 > an effective as complementary to the other activities that have
 > always taken place.

Again, there's friction here.  Somebody said that it's really no help
if the acknowledgment is automatic, and that's true.  The reply was
that a polite response from a human isn't necessarily going to be much
better unless there's real help in it, and that's true too.  As I
understand Mark, that's a lot of his frustration; he doesn't yet know
enough to be of genuine help in most of the issues he handles, so he
has to be satisfied with either dropping it on the floor again, or
sending out an embarrassing "Hi, I'm from the Python triage team, and
I'm sorry to tell you that after five years of dead silence, we still
have nothing to say."  Anyway, I know *I* find that frustrating when I
have to do it!

Where do we find the resources to provide that "real help"?  Again,
maybe one bug day to show what can be done, and then more or less
regularly-scheduled bug days to keep up the momentum?

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

Re: [Python-Dev] co_firstlineno on decorated functions

[Guido van Rossum]

On Tue, Aug 3, 2010 at 6:05 AM, Nick Coghlan  wrote:
> On Tue, Aug 3, 2010 at 10:48 PM, Antoine Pitrou  wrote:
>> Furthermore, co_firstlineno is an attribute of the code object, not the
>> function object, so it shouldn't ideally depend on whether a decorator
>> was applied or not.
>
> You cut the part about the inspect module (and no doubt other code)
> relying on the current meaning, though. While I'd agree with you for a
> clean slate definition, that's not what we're dealing with here:
> "co_firstlineno" has an existing meaning, and it *isn't* "the line
> containing the def keyword", it's "the first line of the function,
> including any decorator lines". The decision could (and arguably
> should) have gone the other way when decorator syntax was first added,
> but changing our minds now would be making the situation worse rather
> than better.

What are the use cases for co_firstlineno? Even if it is for
displaying the source code, I can find virtue for both sides of this
argument.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
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

[David Cournapeau]

On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou  wrote:
> On Tue, 03 Aug 2010 10:28:07 +0200
> "M.-A. Lemburg"  wrote:
>> >
>> > 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.
>>
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a database would solve many things at once: faster access to
>> the meta-data of installed packages, fewer I/O calls during startup,
>> more flexible ways of doing queries on the meta-data, needed for
>> introspection and discovery, etc.
>
> If the cache can become stale because of system package management
> tools, how do you avoid I/O calls while checking that the database is
> fresh enough at startup?

There is a tension between the two approaches: either you want
"auto-discovery", or you want a system with explicit registration and
only the registered plugins would be visible to the system.

System-wise, I much prefer the later, and auto-discovery should be
left at the application discretion IMO. A library to deal with this at
the *app* level may be fine. But the current system of loading
packages and co is already complex enough in python that anything that
complexify at the system (interpreter) level sounds like a bad idea.

David
___
Python-Dev mailing list
Python-Dev@python.org
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

[Antoine Pitrou]

> There is a tension between the two approaches: either you want
> "auto-discovery", or you want a system with explicit registration and
> only the registered plugins would be visible to the system.

I think both are necessary. A discovery API should be available, but the
library or application should be free to do whatever it wants with the
discovered plugins - enable them automatically, present them to the
user, or nothing.

(a GUI application, for example, needs to be able to display a list of
available plugins, with checkboxes to enable or disable each of them. It
is not reasonable to expect the user to type the plugin name in a
textbox)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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

[P.J. Eby]

At 10:28 AM 8/3/2010 +0200, M.-A. Lemburg wrote:

Since you are into comparing numbers, you might want to count
the number of Zope plugins that are available on PyPI and its plugin
system has been around much longer than setuptools has been.
I don't think that proves anything, though.


Actually, some of the ones I found in the search using entry points 
*were* Zope, which, as I mentioned before, is increasingly moving 
away from the old approach in favor of entry points.


In any case, I am not advocating *setuptools* -- I'm advocating that 
if PEP 376 expands to add plugin support, that it do so with a file 
format and associated API based on that of entry points, so as to 
make migration of those ~187 modules and their associated plugins to 
distutils2 a little easier.


In other words, I'm trying to make it easier for people to move OFF 
of setuptools.


Crazy, I know, but there you go.  ;-)

___
Python-Dev mailing list
Python-Dev@python.org
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

[Antoine Pitrou]

Apparently you are not the only one experiencing it.
On #python-dev we get such notifications:

 alanwilter roundup * #9485/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...
 alanwilter roundup * #9486/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...  gutworth: Too late.  tarek is lost to us.
 alanwilter roundup * #9487/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...
 alanwilter roundup * #9488/signal.signal/signal.alarm not
working as expected: [new] I have this example code to illustrate a
problem I am ...

But the relevant bug entries don't exist.

Regards

Antoine.



On Tue, 3 Aug 2010 15:59:50 +0200
Florent Xicluna  wrote:

> There's no new issue posted this morning.
> I tried to post an issue, and an error occurred on submit.
> 
> So...
> 
> -- 
> Florent
> 
> 
> 2010/8/3 Fred Drake 
> 
> > On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen  wrote:
> > > Is the tracker OK now?
> >
> > It's working for me.
> >
> >
> >   -Fred
> >
> > --
> > Fred L. Drake, Jr.
> > "A storm broke loose in my mind."  --Albert Einstein
> > ___
> >
> 


___
Python-Dev mailing list
Python-Dev@python.org
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]

On 03/08/2010 15:19, David Cournapeau wrote:

On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou  wrote:
   

On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg"  wrote:
 

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.
 

I don't think that's a problem: the SQLite database would be a cache
like e.g. a font cache or TCSH command cache, not a replacement of
the meta files stored in directories.

Such a database would solve many things at once: faster access to
the meta-data of installed packages, fewer I/O calls during startup,
more flexible ways of doing queries on the meta-data, needed for
introspection and discovery, etc.
   

If the cache can become stale because of system package management
tools, how do you avoid I/O calls while checking that the database is
fresh enough at startup?
 

There is a tension between the two approaches: either you want
"auto-discovery", or you want a system with explicit registration and
only the registered plugins would be visible to the system.

   


Not true. Auto-discovery provides an API for applications to tell users 
which plugins are *available* whilst still allowing the app to decide 
which are active / enabled. It still leaves full control in the hands of 
the application.


It also allows the user / sysadmin to use their standard tools, whether 
that be disutils2 or package managers, to install the plugins instead of 
requiring ad-hoc approaches like "drop this file in this location".


All the best,

Michael Foord


System-wise, I much prefer the later, and auto-discovery should be
left at the application discretion IMO. A library to deal with this at
the *app* level may be fine. But the current system of loading
packages and co is already complex enough in python that anything that
complexify at the system (interpreter) level sounds like a bad idea.

David
___
Python-Dev mailing list
Python-Dev@python.org
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/

___
Python-Dev mailing list
Python-Dev@python.org
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

[P.J. Eby]

At 01:40 PM 8/3/2010 +0200, M.-A. Lemburg wrote:

If you look at the proposal, it is really just about adding a
new data store to manage a certain package type called "plugins".
Next time around, someone will want to see support for "skins" or
"themes". Then perhaps identify "script" packages, or
"application" packages, or "namespace" packages, or "stubs", etc.
All this can be had by providing this kind of extra
meta-information in the already existing format.


If by "existing format", you mean "entry points", then yes, that is 
true.  ;-)  They are used today for most of the things you listed; 
anything that's an importable Python object (module, class, function, 
package, constant, global) can be listed as an entry point belonging 
to a named group.  Heck, the first code sample on Nullege for 
iter_entry_points is some package called Apydia loading an entry 
point group called "apydia.themes"!


Seriously, though, PEP 376 is just setuptools' egg-info under a 
different name with uninstall support added.  And egg-info was 
designed to be able to hold all those things you're talking 
about.  The EggTranslations project, for example, defines 
i18n-support files that can be placed under egg-info, and provides 
its own APIs for looking those things up.  Applications using 
EggTranslations can not only have their own translations shipped as 
plugins, but plugins can provide translations for other plugins of 
the same application.  (I believe it also supports providing other 
i18n resources such as icons as well.)


So, it isn't actually necessary for the stdlib to provide any 
particular support for specific kinds of metadata within PEP 376, as 
long as the PEP 376 API supports finding packages with metadata files 
of a particular name.  (EggTranslations uses similar APIs provided by 
pkg_resources.)


However, since Tarek proposed adding a stdlib-supported plugins 
feature, I am suggesting it adopt the entry_points.txt file name and 
format, to avoid unnecessary API fragmentation.




If we add a new extra file to be managed by the package
managers every time someone comes up with a new use case,
we'd just clutter up the disk with more and more CSV file
extracts and make PEP 376 more and more complex.


The setuptools egg-info convention is not to create files that don't 
contain any useful content, so that their presence or absence conveys 
information.  If that convention is continued in PEP 376, features 
that aren't used won't take up any disk space.


As for cluttering the PEP, IMO any metadata files that aren't part of 
the "installation database" feature should probably have their own PEP.


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

Re: [Python-Dev] co_firstlineno on decorated functions

[Raghuram Devarakonda]

On Tue, Aug 3, 2010 at 10:14 AM, Guido van Rossum  wrote:

> What are the use cases for co_firstlineno? Even if it is for
> displaying the source code, I can find virtue for both sides of this
> argument.

nose uses co_firstlineno to determine order of the test functions and
decorating a test function can change such order. To keep the
ordering, it provides nose.tools.make_decorator() which explicitly
keeps the line number of the original function. Check the following
thread for a discussion in this regard:

http://groups.google.com/group/nose-users/browse_thread/thread/3e354cbb5b1fac6/107429c5abbf2e59

Thanks,
Raghu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] co_firstlineno on decorated functions

[Antoine Pitrou]

Le mardi 03 août 2010 à 11:05 -0400, Raghuram Devarakonda a écrit :
> On Tue, Aug 3, 2010 at 10:14 AM, Guido van Rossum  wrote:
> 
> > What are the use cases for co_firstlineno? Even if it is for
> > displaying the source code, I can find virtue for both sides of this
> > argument.
> 
> nose uses co_firstlineno to determine order of the test functions and
> decorating a test function can change such order. To keep the
> ordering, it provides nose.tools.make_decorator() which explicitly
> keeps the line number of the original function. Check the following
> thread for a discussion in this regard:

That's pretty much orthogonal, though. We're talking about the case of a
decorator which returns the original function object (and therefore
doesn't change co_firstlineno).

Anyway, when co_firstlineno is used for ordering purposes, it doesn't
matter whether some values are offset by one when a decorator is
applied.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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

[David Cournapeau]

On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
 wrote:
> On 03/08/2010 15:19, David Cournapeau wrote:
>>
>> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
>>  wrote:
>>
>>>
>>> On Tue, 03 Aug 2010 10:28:07 +0200
>>> "M.-A. Lemburg"  wrote:
>>>
>
> 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.
>

 I don't think that's a problem: the SQLite database would be a cache
 like e.g. a font cache or TCSH command cache, not a replacement of
 the meta files stored in directories.

 Such a database would solve many things at once: faster access to
 the meta-data of installed packages, fewer I/O calls during startup,
 more flexible ways of doing queries on the meta-data, needed for
 introspection and discovery, etc.

>>>
>>> If the cache can become stale because of system package management
>>> tools, how do you avoid I/O calls while checking that the database is
>>> fresh enough at startup?
>>>
>>
>> There is a tension between the two approaches: either you want
>> "auto-discovery", or you want a system with explicit registration and
>> only the registered plugins would be visible to the system.
>>
>>
>
> Not true. Auto-discovery provides an API for applications to tell users
> which plugins are *available* whilst still allowing the app to decide which
> are active / enabled. It still leaves full control in the hands of the
> application.

Maybe  I was not clear, but I don't understand how your statement
contradict mine. The issue is how to determine which plugins are
available: if you don't have an explicit registration, you need to
constantly restat every potential location (short of using OS specific
systems to to get notification from fs changes). The current python
solutions that I am familiar with are prohibitively computing
intensive for this reason (think about what happens when you stat
locations on NFS shares).

David
___
Python-Dev mailing list
Python-Dev@python.org
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]

On 03/08/2010 16:24, David Cournapeau wrote:

On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
  wrote:
   

On 03/08/2010 15:19, David Cournapeau wrote:
 

On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
  wrote:

   

On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg"wrote:

 

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.

 

I don't think that's a problem: the SQLite database would be a cache
like e.g. a font cache or TCSH command cache, not a replacement of
the meta files stored in directories.

Such a database would solve many things at once: faster access to
the meta-data of installed packages, fewer I/O calls during startup,
more flexible ways of doing queries on the meta-data, needed for
introspection and discovery, etc.

   

If the cache can become stale because of system package management
tools, how do you avoid I/O calls while checking that the database is
fresh enough at startup?

 

There is a tension between the two approaches: either you want
"auto-discovery", or you want a system with explicit registration and
only the registered plugins would be visible to the system.


   

Not true. Auto-discovery provides an API for applications to tell users
which plugins are *available* whilst still allowing the app to decide which
are active / enabled. It still leaves full control in the hands of the
application.
 

Maybe  I was not clear, but I don't understand how your statement
contradict mine. The issue is how to determine which plugins are
available: if you don't have an explicit registration, you need to
constantly restat every potential location (short of using OS specific
systems to to get notification from fs changes). The current python
solutions that I am familiar with are prohibitively computing
intensive for this reason (think about what happens when you stat
locations on NFS shares).
   


Ah, I thought you were arguing against the plugins proposal altogether. 
If you are merely saying that you prefer the proposal to maintain the 
list of plugins via an explicit registration process (i.e. a central 
file somewhere) rather than "stating around" then I don't *particularly* 
have an opinion on the matter.


I want to use the API and the implementation details are up to others to 
work out. :-)


Sorry for the confusion.

Michael


David
   



--
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] co_firstlineno on decorated functions

[Alexander Belopolsky]

On Tue, Aug 3, 2010 at 9:05 AM, Nick Coghlan  wrote:
> .. While I'd agree with you for a
> clean slate definition, that's not what we're dealing with here:
> "co_firstlineno" has an existing meaning, and it *isn't* "the line
> containing the def keyword", it's "the first line of the function,
> including any decorator lines". The decision could (and arguably
> should) have gone the other way when decorator syntax was first added,
> but changing our minds now would be making the situation worse rather
> than better.

I agree with Nick.  What I see here is an ambiguity with good
arguments available either way.  Since the decision has been made, it
is better to just stick to it and educate users through better
documentation.

Here is a copy of my private response to Eli a few days ago:
"""
I am not sure there is a bug there.
What is wrong with the following trace?

   1: def d(x):
   1: return x

   1: @d
  def f():
   1: x = 0
   6: for i in range(5):
   5: x += 2

   1: f()

Arguably, the "def" line should show up in coverage, but it is
not that dissimilar from

   1: def \
  f():
   1: x = 0
   6: for i in range(5):
   5: x += 2

   1: f()

If you think of decorator syntax as a part of the "def" line, the first
trace makes as much sense as the second.
"""
___
Python-Dev mailing list
Python-Dev@python.org
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

[Glyph Lefkowitz]

On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:

> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
> 
> Such a database would solve many things at once: faster access to
> the meta-data of installed packages, fewer I/O calls during startup,
> more flexible ways of doing queries on the meta-data, needed for
> introspection and discovery, etc.

This is exactly what Twisted already does with its plugin cache, and the 
previously-cited ticket in this thread should expand the types of metadata 
which can be obtained about plugins.

Packaging systems are perfectly capable of generating and updating such 
metadata caches, but various packages of Twisted (Debian's especially) didn't 
read our documentation and kept moving around the place where Python source 
files were installed, which routinely broke the post-installation hooks and 
caused all kinds of problems.

I would strongly recommend looping in the Python packaging teams from various 
distros *before* adding another such cache, unless you want to be fielding bugs 
from Launchpad.net for five years :).

___
Python-Dev mailing list
Python-Dev@python.org
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

[R. David Murray]

On Tue, 03 Aug 2010 16:35:01 +0200, Antoine Pitrou  wrote:
> Apparently you are not the only one experiencing it.
> On #python-dev we get such notifications:
> 
>  alanwilter roundup * #9485/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ...
>  alanwilter roundup * #9486/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ...  gutworth: Too late.  tarek is lost to us.
>  alanwilter roundup * #9487/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ...
>  alanwilter roundup * #9488/signal.signal/signal.alarm not
> working as expected: [new] I have this example code to illustrate a
> problem I am ...
> 
> But the relevant bug entries don't exist.

Fixed.  Apparently a line was dropped when applying a patch to
the tracker, but the mistake didn't surface until roundup
was restarted after the reboot.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
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

[Brian Curtin]

On Tue, Aug 3, 2010 at 11:58, R. David Murray  wrote:

> On Tue, 03 Aug 2010 16:35:01 +0200, Antoine Pitrou 
> wrote:
> > Apparently you are not the only one experiencing it.
> > On #python-dev we get such notifications:
> >
> >  alanwilter roundup * #9485/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ...
> >  alanwilter roundup * #9486/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ...  gutworth: Too late.  tarek is lost to us.
> >  alanwilter roundup * #9487/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ...
> >  alanwilter roundup * #9488/signal.signal/signal.alarm not
> > working as expected: [new] I have this example code to illustrate a
> > problem I am ...
> >
> > But the relevant bug entries don't exist.
>
> Fixed.  Apparently a line was dropped when applying a patch to
> the tracker, but the mistake didn't surface until roundup
> was restarted after the reboot.
>
> --
> R. David Murray  www.bitdance.com


Are these issues going to show up or are they lost? Via IRC, #9490 and it's
apparent dupe #9491 looked interesting to me (Windows service related).
___
Python-Dev mailing list
Python-Dev@python.org
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

[Steve Holden]

On 8/3/2010 12:33 PM, Glyph Lefkowitz wrote:
> 
> On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
> 
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a database would solve many things at once: faster access to
>> the meta-data of installed packages, fewer I/O calls during startup,
>> more flexible ways of doing queries on the meta-data, needed for
>> introspection and discovery, etc.
> 
> This is exactly what Twisted already does with its plugin cache, and the
> previously-cited ticket in this thread should expand the types of
> metadata which can be obtained about plugins.
> +1
> Packaging systems are perfectly capable of generating and updating such
> metadata caches, but various packages of Twisted (Debian's especially)
> didn't read our documentation and kept moving around the place where
> Python source files were installed, which routinely broke the
> post-installation hooks and caused all kinds of problems.
> 
> I would strongly recommend looping in the Python packaging teams from
> various distros *before* adding another such cache, unless you want to
> be fielding bugs from Launchpad.net  for five
> years :).
> 
+1
-- 
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] breaking an exception chain

[R. David Murray]

Working with Catherine on an argparse bug, we ran into a test that was
apparently failing by raising a SystemExit, when the test harness was
supposed to be catching that error.  It took us a bit to realize that
there wasn't really a SystemExit error, but that what we were seeing was
the SystemExit chained to the exception the test harness was purposfully
raising after catching the SystemExit.  In Python2, only the second,
intentionally raised exception would be printed by unittest.  In Python3,
the "main error" printed by unittest is the SystemExit, and the error
raised by the test harness appears after the "while processing the above
error" sentence.  Needless to say, this is a bit confusing.

So I thought I'd break the exception chain before raising the error the
test harness really wants to raise.  However, I can't figure out any way
to do that.  Am I missing something, or this a missing feature?

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

Re: [Python-Dev] breaking an exception chain

[Benjamin Peterson]

2010/8/3 R. David Murray :
> Working with Catherine on an argparse bug, we ran into a test that was
> apparently failing by raising a SystemExit, when the test harness was
> supposed to be catching that error.  It took us a bit to realize that
> there wasn't really a SystemExit error, but that what we were seeing was
> the SystemExit chained to the exception the test harness was purposfully
> raising after catching the SystemExit.  In Python2, only the second,
> intentionally raised exception would be printed by unittest.  In Python3,
> the "main error" printed by unittest is the SystemExit, and the error
> raised by the test harness appears after the "while processing the above
> error" sentence.  Needless to say, this is a bit confusing.
>
> So I thought I'd break the exception chain before raising the error the
> test harness really wants to raise.  However, I can't figure out any way
> to do that.  Am I missing something, or this a missing feature?

Missing feature; there's a bug report somewhere.



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

Re: [Python-Dev] co_firstlineno on decorated functions

[Terry Reedy]

On 8/3/2010 8:48 AM, Antoine Pitrou wrote:

On Tue, 3 Aug 2010 22:25:01 +1000
Nick Coghlan  wrote:

On Tue, Aug 3, 2010 at 1:40 PM, Eli Bendersky  wrote:

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?


Since the decorator is as much a part of the function definition as
the def line is, I would say that it is correct (the name says
"firstlineno", not "deflineno").


That's debatable. Since writing:

@b
def a():
 ...

is equivalent to:

def a():
 ...
a = b(a)


The difference is that 'a=b(a)' is a standalone statement which could 
moved down with other statements interposed, while '@b' is neither a 
statement nor expression but a def statement prefix, and is documented 
as such.


A dynamic difference between the constructs, as least with CPython, is 
that the decorator form does just one namespace binding instead of two.



and in the latter case co_firstlineno points to the "def a()" line.

Furthermore, co_firstlineno is an attribute of the code object, not the
function object, so it shouldn't ideally depend on whether a decorator
was applied or not.


Perhaps. A practical consideration is that it is easier to search 
forward from the first '@' line to the 'def' line than the reverse.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
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

[Georg Brandl]

Am 03.08.2010 19:05, schrieb Brian Curtin:
> On Tue, Aug 3, 2010 at 11:58, R. David Murray  Fixed.  Apparently a line was dropped when applying a patch to
> the tracker, but the mistake didn't surface until roundup
> was restarted after the reboot.
> 
> --
> R. David Murray  www.bitdance.com
> 
> 
> 
> Are these issues going to show up or are they lost? Via IRC, #9490 and it's
> apparent dupe #9491 looked interesting to me (Windows service related).
> 

I would recommend contacting the poster via the address he registered
in the tracker.

Georg

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

[Python-Dev] release26-maint semi-frozen

[Barry Warsaw]

We're going to go ahead and cut the 2.6.6rc1 release tonight, bugs.python.org
willing.  We've got a fairly clean test run on local hardware across OS X,
Linux (Debian, Ubuntu), and Brian is looking at Windows now (the buildbots are
a sad and sorry story).  Ezio has done a great amount of work on getting 2.6.6
pretty clean with -3 warnings too.

Please consider the release26-maint tree closed for commits (except svnmerges)
for the next 2.5 hours.  I'll send another message at about 2200 UTC when I
freeze the tree for those commits too.  You can request exceptions by pinging
me on #python-dev or (if you're feeling lucky ;) sending me an email.

-Barry


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

[Python-Dev] pickle output not unique

[Kristján Valur Jónsson]

Hi there.
I was made aware of this oddity here:
import cPickle

reffed = "xKITTENSx"[1:-1]
print repr(cPickle.dumps(reffed))

print repr(cPickle.dumps("xKITTENSx"[1:-1]))

These strings are different, presumably because of the (ob_refcnt == 1) 
optimization used during object pickling.
This might come as a suprise to many, and is potentially dangerous if pickling 
is being used as precursor to some hashing function.
For example, we use code that caches function calls, using something akin to:

myhash = hash(cPickle.dumps(arguments))
try:
  cached_args, cached_value = cache[myhash]
  if cached_args == arguments: return cached_value
except KeyError:
  value = Function(*args)
  cache[myhash] = artuments, value
  return value

The non-uniqueness of the pickle string will cause unnecessary cache misses in 
this code.  Pickling is useful as a precusor because it allows for more varied 
object types than hash() alone would.

I just wanted to point this out.  We'll attempt some local workarounds here, 
but it should otherwise be simple to modify pickling to optionally turn off 
this optimization and always generate the same output irrespective of the 
internal reference counts of the objects.

Cheers,

Kristján

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

Re: [Python-Dev] breaking an exception chain

[R. David Murray]

On Tue, 03 Aug 2010 12:22:30 -0500, Benjamin Peterson  
wrote:
> 2010/8/3 R. David Murray :
> > So I thought I'd break the exception chain before raising the error the
> > test harness really wants to raise.  However, I can't figure out any way
> > to do that.  Am I missing something, or this a missing feature?
> 
> Missing feature; there's a bug report somewhere.

Ah, thank you.  Issue 6210.  It has a workaround, too.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
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

[R. David Murray]

On Tue, 03 Aug 2010 20:36:36 +0200, Georg Brandl  wrote:
> Am 03.08.2010 19:05, schrieb Brian Curtin:
> > On Tue, Aug 3, 2010 at 11:58, R. David Murray  
> > Fixed.  Apparently a line was dropped when applying a patch to
> > the tracker, but the mistake didn't surface until roundup
> > was restarted after the reboot.
> > 
> > Are these issues going to show up or are they lost? Via IRC, #9490 and it's
> > apparent dupe #9491 looked interesting to me (Windows service related).
> 
> I would recommend contacting the poster via the address he registered
> in the tracker.

Yes, please do that.  As far as I know the issues never got created,
even though the issue counter did increment.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pickle output not unique

[Martin v. Löwis]

> I just wanted to point this out.  We‘ll attempt some local workarounds
> here, but it should otherwise be simple to modify pickling to optionally
> turn off this optimization and always generate the same output
> irrespective of the internal reference counts of the objects.

I think there are many other instances where values that compare equal
pickle differently in Python. By relying on this property for hashing,
you are really operating on thin ice.

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

Re: [Python-Dev] pickle output not unique

[Alexander Belopolsky]

2010/8/3 Kristján Valur Jónsson :
..
>
> These strings are different, presumably because of the (ob_refcnt == 1)
> optimization used during object pickling.
>
I have recently closed a similar issue because it is not a bug and the
problem is not present in 3.x: http://bugs.python.org/issue8738

..
> I just wanted to point this out.  We‘ll attempt some local workarounds here,
> but it should otherwise be simple to modify pickling to optionally turn off
> this optimization and always generate the same output irrespective of the
> internal reference counts of the objects.

I wonder if it would help if rather than trying to turn off the ad-hoc
optimization, you run your pickle strings through
pickletools.optimize.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pickle output not unique

[Alexander Belopolsky]

2010/8/3 "Martin v. Löwis" :
..
> I think there are many other instances where values that compare equal
> pickle differently in Python.

Indeed.  For example:

>>> 1.0 == 1
True
>>> dumps(1.0) == dumps(1)
False

or for objects of the same type

>>> 0.0 == -0.0
True
>>> dumps(0.0) == dumps(-0.0)
False
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] co_firstlineno on decorated functions

[Greg Ewing]

Guido van Rossum wrote:


What are the use cases for co_firstlineno? Even if it is for
displaying the source code, I can find virtue for both sides of this
argument.


Seems to me that if the code is being displayed to a
human, the decorators are an important thing to know
about, so including them is good.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Status of Lib/_threading_local.py ?

[Antoine Pitrou]

Hello,

While Lib/_threading_local.py is meant as a fallback Python
implementation of thread-local objects, it looks like it will never be
invoked in practice. The reason is that the thread-local code in
Modules/_threadmodule.c in unconditionally compiled. Furthermore,
_threading_local.py imports threading which itself imports _thread, so
it's not possible for _threading_local to function if for some reason
_thread fails to build or import.

What should we do with _threading_local? Keep it as an example of a
Python implementation (which is vastly slower than what a C
implementation can do and also currently less robust), or plainly
remove it?

Regards

Antoine.


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

[Python-Dev] Windows

[Steve Holden]

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.

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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows

[Brian Curtin]

On Tue, Aug 3, 2010 at 20:08, Steve Holden  wrote:

> It's a little disappointing to discover that despite the relatively
> large number of developers who have received MSDN licenses from
> Microsoft, none if us have the time to make sure that the buildbots are
> green for the 2.6.6 release.
>
> I wonder if anyone can think of a way we can get some Windows skillz
> into the group that could assist at ties like this. Some brainstorming
> might find a way through.
>
> regards
>  Steve


In my case, 2.6 in general just fell off the radar. 2/3 of the 2.6 Windows
buildbots are fine, with the failing one being the case of a very slow VM
machine and a time sensitive bsddb test. I looked into it this afternoon and
it's something we can improve test-wise -- I'll see if I can work up a
patch. It's not a problem with the module itself.

As for getting the attention of more Windows devs, there are a few names I
see pop up from time to time that would be nice to have on board if they
have the time. I'll see if I can reach out and gauge their interest level.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows

[Mark Hammond]

On 4/08/2010 11:08 AM, Steve Holden wrote:

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.


I never go looking at the buildbots to look for problems - maybe some 
way of explicitly bringing such failures to peoples attention would be 
good - I don't recall seeing anything recently on python-dev which would 
prompt me to take a look.


Visiting http://www.python.org/dev/buildbot/2.6/ shows a single Windows 
buildbot that seems to have been green for the last few builds - am I 
looking in the wrong place?


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

[Python-Dev] Windows MSI installer with minimal options

[Paul Kippes]

Martin,

For the most part, the information at
http://www.python.org/download/releases/2.4/msi/ assisted me with
automating a 2.7 installation on Windows XP.  The following initial
attempt, however, failed to provide a working python installation.
(Messages are either "The system cannot execute the specified
program." or "This application has failed to start because the
application configuration is incorrect.  Reinstalling the application
may fix this problem.")

msiexec /qb /i python-2.7.msi ALLUSERS=1 ADDLOCAL=Extensions

After looking through Tools/msi/msi.py, I was able to automate a
minimal and working Python installation with this adjustment:

ADDLOCAL=Extensions,SharedCRT

Since the only reference I could find to the above web page was when
the MSI installer was first announced
(http://www.python.org/download/releases/2.4.2), the installer options
may have changed since then.

Would you check if my change is what you intended and perhaps migrate
the web page of the 2.4 release note to 2.7?

Thanks!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] (no subject)

[Sarah Hasanlo Nikfar]

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

[Python-Dev] question

[Sarah Hasanlo Nikfar]

hi 
i face with problem when i run one sample on cygwin:
please help me
 
Exception happened during processing of request from ('127.0.0.1', 49154)
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/SocketServer.py", line 222, in handle_request
    self.process_request(request, client_address)
  File "/usr/local/lib/python2.5/SocketServer.py", line 241, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python2.5/SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python2.5/SocketServer.py", line 522, in __init__
    self.handle()
  File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 316, in handle
    self.handle_one_request()
  File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_req
uest
    method()
  File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 46, in do_GET
    self.copyfile(f, self.wfile)
  File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 175, in copyfile
    shutil.copyfileobj(source, outputfile)
  File "/usr/local/lib/python2.5/shutil.py", line 29, in copyfileobj
    fdst.write(buf)
  File "/usr/local/lib/python2.5/socket.py", line 274, in write
    self.flush()
  File "/usr/local/lib/python2.5/socket.py", line 261, in flush
    self._sock.sendall(buffer)
error: (113, 'Software caused connection abort')


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