Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Guido van Rossum]

On Mon, Mar 12, 2012 at 10:10 PM, Senthil Kumaran <[hidden email]> wrote:

> On Mon, Mar 12, 2012 at 07:23:11PM -0700, Andrey Petrov wrote:
>> I've had the pleasure of speaking with Guido at PyCon and it became evident
>> that some of Python's included batteries are significantly lagging behind the
>> rapidly-evolving defacto standards of the community specifically in cases like
>> urllib and urllib2, which lack important features provided by alternatives like
>> httplib2, requests, and my own urllib3.
>
> Well, I think I have address this because I am the maintainer of those
> modules in standard lib.
>
> First things first, it looks to me that trashing something gives good
> motivation to you (and others working on related modules). I don't
> have a problem with that.
>
> But on the other hand, if you think things can be improved in stdlib,
> you are welcome to contribute. Just remember that new features,
> refactoring with backwards compatibility, 'cool api' for new features
> should go in 3.3+ onwards. Bug fixes, confusions on what's RFC
> supported vs what's defacto standards, fine line between bugs and
> features, those can be considered for 2.7.
>
> I am personally in favor of constantly improving the standard library
> modules along with mention of any good libraries which can be useful
> for the purposes of the user.
>
> We already have lots of such references in standard library
> documentation. If there is a well maintained package, as long as the
> external package is active and maintained, we can have it as link in
> the docs. Sometimes those external packages become inactive too, in
> those cases, those should pruned. Its' all about maintaining libraries
> and docs and being helpful.

Well said. Improving existing stdlib modules is always welcome of
course! (And the bar is much lower than for adding new modules.)

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Paul Moore]

On 13 March 2012 13:34, Donald Stufft <[hidden email]> wrote:

> http://python-guide.org ?

Hmm, yes maybe. I had seen this before (it's where I found out about
requests, IIRC).

As it says, it "is mostly a skeleton at the moment". With some
fleshing out, then it's probably a good start. I have some problems
with its recommendations (notably "If you’re starting work on a new
Python module, I recommend you write it for Python 2.5 or 2.6, and add
support for Python3 in a later iteration." which is probably not
appropriate for something that would be officially sanctioned by the
core developers). Also, I don't think we want something advertised as
"opinionated".

And it covers a much wider area than the original suggestion. I'd
envisaged something more like a simple list of "obvious" modules:

"""
Requests - URL

Requests is a module designed to make getting resources from the web
as easy as possible. It is a simpler and more powerful alternative to
the stdlib urllib and urllib2 modules. ...

Some code samples here giving basic usage.
"""

My ideal would be something I could scan in a few spare moments, and
pick up pointers to particular modules that I'd find useful.
Basically, take the "Scenario Guide" section of python-guide, flesh it
out, and turn it into a flat list. (I don't like the "Scenario"
approach as it tends to force people into a particular view of the
world, but maybe that's just me, my applications tend to be more
eclectic than any of the "normal" categories).

Paul.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Glenn Linderman-3]

On 3/13/2012 6:31 AM, Paul Moore wrote:

It can be very hard to separate the good from the indifferent (or even
bad) when browsing PyPI. I've found some very good packages recently
which I'd never have known about without some random comment on a
mailing list.

+1

However, I'm not keen on having the stdlib documentation suggest that
I should be using something else. No code should ever be documenting
"don't use me, there are better alternatives" unless it is deprecated
or obsolete.

+0

On the other hand, I would love to see a community-maintained document
that described packages that are acknowledged as "best of breed". That
applies whether or not those packages replace something in the stdlib.
Things like pywin32, lxml, and requests would be examples in my
experience. 

+1

There's no reason this *has* to be in the core
documentation - it may be relevant that nothing has sprung up
independently yet...

Hmm.

Maybe a separate item in the Python documentation, "External Modules",
could be created and maintained by the community? By being in the
documentation, it has a level of "official recommendation" status, and
by being a top-level document it's visible (more so than, for example,
a HOWTO document would be). Because it's in the released
documentation, it is relatively stable, which implies that external
modules would need to have a genuine track record to get in there, but
because it's community maintained it should reflect a wider consensus
than just the core developers' views.

+1  This is the best proposal I've seen for including references to external modules.  It gets it in the core documentation, hopefully with enough keywords that search would typically find external modules that are supersets of stdlib modules in the same result set that the stdlib module would be found.  Yet it doesn't intrude on the documentation for the stdlib module.  And beyond a 1-2 paragraph description, would not be fully documented, except by referencing the external module's documentation.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Kenneth Reitz]

I think the cheesehop trove classifiers would be the ideal way to agnostically link to a page of packages related to the standard package in question. No need for sort order.

The beauty of this solution is that packages that aren't maintained won't add the appropriate classifier to their package, and therefore not show up in the list.

-- 

Kenneth Reitz

On Monday, March 12, 2012 at 9:23 PM, Brian Curtin wrote:

On Mon, Mar 12, 2012 at 21:14, Andrey Petrov <[hidden email]> wrote:

On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin <[hidden email]> wrote:

On Mon, Mar 12, 2012 at 19:23, Andrey Petrov <[hidden email]> wrote:

What such a snippet might look like:

"Batteries are included with Python but sometimes they are old and

leaky—this is one of those cases. Please have a look in PyPI for more modern

alternatives provided by the Python community."

What does "leaky" mean here? Someone's going to see that, think it has

memory leaks, then rant on the internet about how we ship crap and

just document it as so.

I agree Brian and David, the choice of "leaky" in the wording is poor.

It was supposed to be maintaining the "batteries" metaphor but it's

clearly ambiguous.

Perhaps something along the lines of...

"Batteries are included with Python but for stability and backwards

compatibility, some of the standard library is not always as modern as

alternatives provided by the Python community—this is one of those

cases. Please have a look at PyPI for more cutting-edge alternatives."

Sorry for another color choice on the bikeshed, but I would drop the

word or references to "batteries". *We* know what "batteries included"

means, but there are undoubtedly people who won't get it. It's just

code - let's call it code.

Part 2:

I propose we add a new category of package identifiers such as "Topic ::

Standard Library Alternative :: {stdlib_package_name}" which authors of

libraries can tag themselves under. The documentation warning snippet will

provide a link to the appropriate PyPI query to list packages claiming to be

alternatives to the stdlib package in question.

Automating it to something on PyPI is the not the right answer. People

will use it incorrectly, either in that they'll add it to packages for

which it isn't accurate, and people just flat out won't use it or know

about it. It won't be accurate this way, and anything that we're

documenting needs to be vetted.

It's not often that a great alternative comes up, so I don't see the

manual burden being too great.

There are a dozen or more urllib/httplib/pycurl competitors on PyPI,

and new ones spring up all the time. I'm not sure how we would go

about objectively blessing the best "official" option at any given

moment, or how frequently we would have to do this.

The same way we choose to accept libraries into the standard library.

New ones spring up all the time - mature, proven, and widely used ones

do not. If someone thinks libfoo is ready, they suggest it. If we

haven't heard of it, the conversation ends. If we have people who know

it, maybe we have them look deeper and figure out if it's something we

can put our stamp on just like we might with the recent talk of

"experimental package" inclusion.

With self-identifying, we could sort by some sort metric (monthly

downloads? magical score?) and create a somewhat-actionable list.

Downloads don't mean the code is good. Voting is gamed. I really don't

think there's a good automated solution to tell us what the

high-quality replacement projects are.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Brian Curtin]

On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz <[hidden email]> wrote:
> I think the cheesehop trove classifiers would be the ideal way to
> agnostically link to a page of packages related to the standard package in
> question. No need for sort order.

Randomize the order for all I care. We still need to ensure we're
suggesting quality projects. It doesn't make sense for us to suggest
alternatives that we wouldn't want to use ourselves by just polling
some list that anyone can get on.

This is documentation that receives hundreds of thousands of views a
month*. We need to be picky about what goes in it.

> The beauty of this solution is that packages that aren't maintained won't
> add the appropriate classifier to their package, and therefore not show up
> in the list.

Just because it's maintained doesn't mean it's not garbage. I think we
really need to start every project off with a 0 and make them prove
that they're a 10. Just being active means nothing.



* http://www.python.org/webstats/usage_201202.html#TOPURLS - I don't
know what page "Documentation" means since it doesn't have a specific
link, but whatever page that is got hit 960K times in February.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Terry Reedy]

On 3/13/2012 12:40 AM, Guido van Rossum wrote:
> On Mon, Mar 12, 2012 at 9:22 PM, Terry Reedy<[hidden email]>  wrote:
>> I would rather we figure out how to encourage authors of advancing packages
>> to contribute better implementations of existing features and well-tested
>> new features back to the stdlib module.
>
> I would not.

I think you misunderstood me and are talking about something other than
what I meant. There are about 3250 open issues (this slowly but steadily
grows). Of them, 1450 are behavior (bug) issues. We need more people,
especially people with specialized expertise, writing and reviewing
patches. As you said in response to Senthil

 > Improving existing stdlib modules is always welcome

Exactly. So I would like to figure out how to encourage more such
improvements.

> There are many excellent packages out there that should
> not be made into stdlib packages simply because their authors are not
> done adding new features.

Or because the package is outside the reasonable scope of the stdlib, or
requires a different type of expertise than most core development, or
for other reasons.

Authors of separately maintained packages are, from our viewpoint, as
eligible to help with tracker issues as anyone else, even while they
continue work on their external package. Some of them are more likely
than most contributors to have the knowledge needed for some particular
issues.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Thomas Wouters-4]

On Tue, Mar 13, 2012 at 12:38, Brian Curtin <[hidden email]> wrote:

On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz <[hidden email]> wrote:
> I think the cheesehop trove classifiers would be the ideal way to
> agnostically link to a page of packages related to the standard package in
> question. No need for sort order.

Randomize the order for all I care. We still need to ensure we're
suggesting quality projects. It doesn't make sense for us to suggest
alternatives that we wouldn't want to use ourselves by just polling
some list that anyone can get on.

This is documentation that receives hundreds of thousands of views a
month*. We need to be picky about what goes in it.

> The beauty of this solution is that packages that aren't maintained won't
> add the appropriate classifier to their package, and therefore not show up
> in the list.

Just because it's maintained doesn't mean it's not garbage. I think we
really need to start every project off with a 0 and make them prove
that they're a 10. Just being active means nothing.



* http://www.python.org/webstats/usage_201202.html#TOPURLS - I don't
know what page "Documentation" means since it doesn't have a specific
link, but whatever page that is got hit 960K times in February.

GroupURL        /doc/*          Documentation

So it's anything that's in www.python.org/doc/. I don't believe it counts doc.python.org and docs.python.org.

--
Thomas Wouters <[hidden email]>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Guido van Rossum]

On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy <[hidden email]> wrote:
> Authors of separately maintained packages are, from our viewpoint, as
> eligible to help with tracker issues as anyone else, even while they
> continue work on their external package. Some of them are more likely than
> most contributors to have the knowledge needed for some particular issues.

This is a good idea. I was chatting w. Senthil this morning about
adding improvements to urllib/request.py based upon ideas from
urllib3, requests, httplib2 (?), and we came to the conclusion that it
might be a good idea to let those packages' authors review the
proposed stdlib improvements.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Antoine Pitrou]

On Tue, 13 Mar 2012 14:16:40 -0700
Guido van Rossum <[hidden email]> wrote:

> On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy <[hidden email]> wrote:
> > Authors of separately maintained packages are, from our viewpoint, as
> > eligible to help with tracker issues as anyone else, even while they
> > continue work on their external package. Some of them are more likely than
> > most contributors to have the knowledge needed for some particular issues.
>
> This is a good idea. I was chatting w. Senthil this morning about
> adding improvements to urllib/request.py based upon ideas from
> urllib3, requests, httplib2 (?), and we came to the conclusion that it
> might be a good idea to let those packages' authors review the
> proposed stdlib improvements.

We don't have any provisions against reviewal by third-party
developers already. I think the main problem (for us, of course) is that
these people generally aren't interested enough to really dive in
stdlib patches and proposals.

For example, for the ssl module, I have sometimes tried to involve
authors of third-party packages such as pyOpenSSL (or, IIRC, M2Crypto),
but I got very little or no reviewing.

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Guido van Rossum]

On Tue, Mar 13, 2012 at 2:21 PM, Antoine Pitrou <[hidden email]> wrote:

> On Tue, 13 Mar 2012 14:16:40 -0700
> Guido van Rossum <[hidden email]> wrote:
>
>> On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy <[hidden email]> wrote:
>> > Authors of separately maintained packages are, from our viewpoint, as
>> > eligible to help with tracker issues as anyone else, even while they
>> > continue work on their external package. Some of them are more likely than
>> > most contributors to have the knowledge needed for some particular issues.
>>
>> This is a good idea. I was chatting w. Senthil this morning about
>> adding improvements to urllib/request.py based upon ideas from
>> urllib3, requests, httplib2 (?), and we came to the conclusion that it
>> might be a good idea to let those packages' authors review the
>> proposed stdlib improvements.
>
> We don't have any provisions against reviewal by third-party
> developers already. I think the main problem (for us, of course) is that
> these people generally aren't interested enough to really dive in
> stdlib patches and proposals.
>
> For example, for the ssl module, I have sometimes tried to involve
> authors of third-party packages such as pyOpenSSL (or, IIRC, M2Crypto),
> but I got very little or no reviewing.

IIRC M2Crypto is currently unmaintained, so that doesn't surprise me.
(In general it seems most crypto wrappers seem unmaintained -- it must
be a thankless job.)

Still, AFAICT both requests and urllib3 are very actively maintained
by people who know what they are doing, and it would be nice if we
could build bridges instead of competition. So let's at least try.
(But I'm not asking you, Antoine, to try and approach them personally.
:-)

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Steven D'Aprano-8]

Brian Curtin wrote:
> On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz <[hidden email]> wrote:
>> I think the cheesehop trove classifiers would be the ideal way to
>> agnostically link to a page of packages related to the standard package in
>> question. No need for sort order.
>
> Randomize the order for all I care. We still need to ensure we're
> suggesting quality projects. It doesn't make sense for us to suggest
> alternatives that we wouldn't want to use ourselves by just polling
> some list that anyone can get on.

"Need" is awfully strong. I don't believe it is the responsibility of the
standard library to be judge and reviewer of third party packages that it
doesn't control.

-1 on adding *any* sort of recommendations about third-party software except,
at most, a case-by-case basis where absolutely necessary.

What problem are we actually trying to solve here? Do we think that there are
users who really have no clue where to find 3rd party software AND don't know
how to use Google, BUT read the Python docs? I find it difficult to believe
that there are people who both read the docs and are so clueless that they
need to be told that there are alternatives available and which they should be
using.

Personally I think this is a solution in search of a problem. Judging by the
python-tutor mailing list, even *beginners* know that they aren't limited to
the stdlib and how to go about finding third party software. There are many
more questions about PyGame and wxPython than there are about tkinter. There
are plenty of questions about numpy. There are lots of questions about niche
packages I'd never even heard of.

I simply don't think there is any evidence that there are appreciable numbers
of Python coders, beginners or expert, who need to be told about third party
software. Who are these people we're trying to reach out to?


> This is documentation that receives hundreds of thousands of views a
> month*. We need to be picky about what goes in it.

Exactly why we should be wary of recommending specific packages.

Should we recommend wxPython over Pyjamas or PyGUI or PyGtk? On what basis?
Whatever choice we make is going to be wrong for some people, and is
potentially unfair to the maintainers of the packages left out. Should we
recommend them all? That's no help to anyone. Make no recommendation at all?
That's the status quo.

What counts as "best of breed" can change rapidly -- software churn is part of
the reason that the packages aren't in the stdlib in the first place. It can
also be a matter of taste and convention. There are a few non-brainers, like
numpy, but everything else, no, let's not open this can of worms.

I can see no benefit to this suggestion, and all sorts of ways that this might
go badly.



--
Steven

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Matt Joiner]

On Mar 14, 2012 5:27 AM, "Antoine Pitrou" <[hidden email]> wrote:
>
> On Tue, 13 Mar 2012 14:16:40 -0700
> Guido van Rossum <[hidden email]> wrote:
>
> > On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy <[hidden email]> wrote:
> > > Authors of separately maintained packages are, from our viewpoint, as
> > > eligible to help with tracker issues as anyone else, even while they
> > > continue work on their external package. Some of them are more likely than
> > > most contributors to have the knowledge needed for some particular issues.
> >
> > This is a good idea. I was chatting w. Senthil this morning about
> > adding improvements to urllib/request.py based upon ideas from
> > urllib3, requests, httplib2 (?), and we came to the conclusion that it
> > might be a good idea to let those packages' authors review the
> > proposed stdlib improvements.
>
> We don't have any provisions against reviewal by third-party
> developers already. I think the main problem (for us, of course) is that
> these people generally aren't interested enough to really dive in
> stdlib patches and proposals.
>
> For example, for the ssl module, I have sometimes tried to involve
> authors of third-party packages such as pyOpenSSL (or, IIRC, M2Crypto),
> but I got very little or no reviewing.

Rather than indicating apathy on the party of third party developers, this might be a sign that core Python is unapproachable or not worth the effort.

For instance I have several one line patches languishing, I can't imagine how disappointing it would be to have significantly larger patches ignored, but it happens.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Eli Bendersky]

> Rather than indicating apathy on the party of third party developers, this
> might be a sign that core Python is unapproachable or not worth the effort.
>
> For instance I have several one line patches languishing, I can't imagine
> how disappointing it would be to have significantly larger patches ignored,
> but it happens.
>

A one-line patch for a complex module or piece of code may require
much more than looking at that single line to really review. I hope
you understand that.

That said, if you find any issues in the bug tracker that in your
opinion need only a few minutes of attention from a core developer,
feel free to send a note to the mentorship mailing list. People
sometimes come there asking for precisely this thing (help reviewing a
simple patch they submitted), and usually get help quickly if their
request is justified.

Eli
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[R. David Murray]

On Wed, 14 Mar 2012 06:03:10 +0200, Eli Bendersky <[hidden email]> wrote:

> > Rather than indicating apathy on the party of third party developers, this
> > might be a sign that core Python is unapproachable or not worth the effort.
> >
> > For instance I have several one line patches languishing, I can't imagine
> > how disappointing it would be to have significantly larger patches ignored,
> > but it happens.
>
> A one-line patch for a complex module or piece of code may require
> much more than looking at that single line to really review. I hope
> you understand that.

In addition, sometimes patches just get forgotten.  It's not like
there are enough core devs with enough time that we are actually doing
searches for open issues with patches...generally we have enough to do
in our interest areas, and so stay there unless an issue is brought to
our attention.

So to bring an issue to our attention, you can first ping the issue with
a status query, or get someone (anyone, pretty much) to do a review and
post it to the issue.  You can also look to see if you can figure out,
either from the experts list in the devguide, or hg history, or tracker
activity, who might be a reasonable person to look at the issue, and
add them to the nosy list.

Either of these actions will often "wake up" an issue, and if it is not
one of the complex (or controversial) ones Eli alluded to, it will often
then get committed.

If that fails, and the patch has been on the tracker for a while, it is
perfectly reasonable to ask about it here.

What we really need most are *reviews*.  And we need these for two
reasons.

First, there aren't enough active committers to keep up with the patch
inflow.  Reviews really help, because they usually simplify the commit
review process for the committer, saving time, and making it more
appealing to work on the issue.

Second, it is as much (or more) from quality reviews as quality patches
that we recognize people who it would be beneficial to invite to be
committers.  And every new committer increases the chances that new
patches will actually get committed....

--David
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Matt Joiner]

Thanks for the suggestions.

On Mar 14, 2012 12:03 PM, "Eli Bendersky" <[hidden email]> wrote:

> Rather than indicating apathy on the party of third party developers, this
> might be a sign that core Python is unapproachable or not worth the effort.
>
> For instance I have several one line patches languishing, I can't imagine
> how disappointing it would be to have significantly larger patches ignored,
> but it happens.
>

A one-line patch for a complex module or piece of code may require
much more than looking at that single line to really review. I hope
you understand that.

That said, if you find any issues in the bug tracker that in your
opinion need only a few minutes of attention from a core developer,
feel free to send a note to the mentorship mailing list. People
sometimes come there asking for precisely this thing (help reviewing a
simple patch they submitted), and usually get help quickly if their
request is justified.

Eli

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Antoine Pitrou]

On Wed, 14 Mar 2012 10:55:35 +1100
Steven D'Aprano <[hidden email]> wrote:
>
> What problem are we actually trying to solve here? Do we think that there are
> users who really have no clue where to find 3rd party software AND don't know
> how to use Google, BUT read the Python docs? I find it difficult to believe
> that there are people who both read the docs and are so clueless that they
> need to be told that there are alternatives available and which they should be
> using.

I find it quite easy to believe myself. Many people will learn some
Python by reading the docs, without knowing the rest of the ecosystem.

So, yes, publicizing the widely accepted alternatives (such as Twisted
for asyncore) *is* helpful.

(that doesn't mean any shiny new gadget must be advocated, though;
third-party libraries should be mature enough before we start
mentioning them)

> Should we recommend wxPython over Pyjamas or PyGUI or PyGtk? On what basis?

You don't have to recommend anything. Just mention them.
You know what, we *already* do that job:
http://docs.python.org/dev/library/othergui.html#other-gui-packages

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Antoine Pitrou]

On Wed, 14 Mar 2012 11:31:34 +0800
Matt Joiner <[hidden email]> wrote:
>
> Rather than indicating apathy on the party of third party developers, this
> might be a sign that core Python is unapproachable or not worth the effort.
>
> For instance I have several one line patches languishing, I can't imagine
> how disappointing it would be to have significantly larger patches ignored,
> but it happens.

Can you give a pointer to these one-liners?
Once a patch gets a month old or older, it tends to disappear from
everyone's radar unless you somehow "ping" on the tracker, or post a
message to the mailing-list.

(of course, you shouldn't spam the list with open issues either)

Thanks

Antoine.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Stefan Krah-3]

Antoine Pitrou <[hidden email]> wrote:
> > For instance I have several one line patches languishing, I can't imagine
> > how disappointing it would be to have significantly larger patches ignored,
> > but it happens.
>
> Can you give a pointer to these one-liners?

Almost a one-liner, but vast knowledge required (how do you prove that
using (freefunc) is safe if it's the first usage in the tree?).

http://bugs.python.org/file21610/atexit-leak.patch


I think there are many issues like that one where the implications
of a short patch can only be assessed by small number of committers.


Stefan Krah


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Antoine Pitrou]

On Wed, 14 Mar 2012 10:58:10 +0100
Stefan Krah <[hidden email]> wrote:

> Antoine Pitrou <[hidden email]> wrote:
> > > For instance I have several one line patches languishing, I can't imagine
> > > how disappointing it would be to have significantly larger patches ignored,
> > > but it happens.
> >
> > Can you give a pointer to these one-liners?
>
> Almost a one-liner, but vast knowledge required (how do you prove that
> using (freefunc) is safe if it's the first usage in the tree?).
>
> http://bugs.python.org/file21610/atexit-leak.patch

Well, can you please post a URL to the issue itself?

Thanks

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Mark Shannon-3]

Stefan Krah wrote:

> Antoine Pitrou <[hidden email]> wrote:
>>> For instance I have several one line patches languishing, I can't imagine
>>> how disappointing it would be to have significantly larger patches ignored,
>>> but it happens.
>> Can you give a pointer to these one-liners?
>
> Almost a one-liner, but vast knowledge required (how do you prove that
> using (freefunc) is safe if it's the first usage in the tree?).
>
> http://bugs.python.org/file21610/atexit-leak.patch
>

But how do you find issues?

I want to do some reviews, but I don't want to wade through issues on
components I know little or nothing about in order to find the ones I
can review.

There does not seem to be a way to filter search results in the tracker.

Cheers,
Mark
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com