Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Michael Foord 

Steven D'Aprano wrote:

On Fri, 13 Nov 2009 04:27:48 am Ludvig Ericson wrote:
  

On 12 nov 2009, at 14:38, Steven D'Aprano wrote:


On Thu, 12 Nov 2009 08:44:32 pm Ludvig Ericson wrote:
  

Why are there comments on PyPI? Moreso, why are there comments
which I cannot control as a package author on my very own
packages? That's just absurd.


No, what's absurd is thinking that the act of publishing software
somehow gives you the right to demand control over what others say
about your software.
  
... on my own package's page. 



It's your package. It's the community's page about your package.

I think of PyPI as a community-owned noticeboard. Its primary purpose is 
to allow the community to find good packages -- the benefit to the 
community is why it exists, not the benefit to the author of the 
package.


In my opinion, the community is best served by a good comment/review 
system, one which avoids the worst trolling, and allows authors the 
right of reply, but does not allow authors to censor inconvenient but 
honest reviews. 

  

+1 :-)

Michael

--
http://www.ironpythoninaction.com/

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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Sriram Srinivasan 
you were thinking wrong. If suppose this feature is introduced it doesn't
mean python will become batteries removed!
you can ship the python release with the 'standard library packages' already
installed.
so what we get here is batteries included and ability to be changed after it
is discharged! ;) users did not get this feature before. what we experience
now is like 'use and throw' not the batteries but the whole python
distribution (like torchlight/flashlight) itself.
also users might get the ability to include other batteries too.

also say for example some X company wants its own python distribution
(including the standard libraries).
they may have the standard libraries removed or another custom library on
top of it (forget performance here). Now if the standard libraries were
available as packages a new version may be installed and tested at no time.
but if they get it by every release, there comes the problem.

this not only makes things easier on both sides (releasing side and user
side) it also makes the whole system transparent.
even patches for standard libraries may be available as soon as a bug has
been found, but not with the current system as Kevin mentioned.

say for example we take an opensouce project, the linux kernel as example.(
dont compare kernel with python each work differently and both scales are
not equal) just think it was another opensource software. i can say mostly
where there linux there is python (not talking about windows,embedded etc,
both software go hand in hand, so i took it for comparison). if there is a
bug/security issue found on the linux the patches are available in
days/mostly by the end of next week. but for python it must take more time.
may be some backward incompatible issue also comes along with it(eg. py3)
then they have to wait for the dependencies being updated. i am only
comparing the packaging and distributing system here not the softwares.
althought the rate at which the kernel development is at a very high scale,
the system is stable. and that is how open source works. every body can have
look into everything. that is what makes open source software best. if it
were (libraries) released as packages, by the time i install the patch
package, i may also get the patch package of the dependency too.


-- 

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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Yuval Greenfield 
On Fri, Nov 13, 2009 at 9:35 AM, Kevin Teague  wrote:
>
> It's also worth noting that there are three issues with respect to standard
> library packaging which are all orthologous:
>
>  * Packaging for metadata: The standard library could be packaged so that
> there is consistent metadata about the distributions which compromise the
> standard library (version, author, maintainer, etc). This could be useful so
> that it would be easier to see at a glance which packages changed between
> any two Python releases. For example, I have a script which compares two
> working sets of packages and generates a web page with a colour-coded list
> of differences between those two working sets, based on the size of the
> version number bump, e.g. major.medium.minor (doesn't work with packages
> which use odd version numbering schemes). I've used this to compare working
> sets between different Grok releases or Plone releases to help see where the
> activity or major API changes might be happening inside any given Zope-based
> release. However, this script only works on 80% of the code, the other 20%
> is in the standard library, which is currently a black-box.
>
>    Also, if PEP 376 is accepted, then the standard library will be
> inviolation of the stanard metadata for installed packages unless this
> happens.
>
>  * Packaging for release:  The standard library could be packaged so that
> releases happen on PyPI. This could be useful so that it's easier to consume
> newer versions of a package before those packages are included in the next
> Python release. It could also make Python upgrades easier, as you could
> hold-back packages which might otherwise break an application upon upgrade.
> I happened to find a bug in a standard library package today, and currently
> my option is to: Submit bug report to PyPI, wait for Python 2.7 release,
> then wait for Plone to update to Python 2.7. I'm looking at many years
> before this fix goes into my production application, so in the meantime I
> need to maintain a work-around for the bug as well account for the day when
> this bug is fixed. It makes a mess of the code. If it was possible to
> release this package on PyPI, this could reasonably happen in a few days or
> at worst a couple months. The setup.py for that package could be updated to
> require the newer version of the package, and the workaround could be
> removed from the code.
>
>  * Packaging for resizing: The standard library could be packaged so that it
> could be made smaller or larger, or there could be different sized standard
> libraries made with different Python releases.
>
> So there are benefits to packaging the standard library which would be
> useful, for reasons which would have no impact on the "batteries included"
> aspect of Python.
>
> Plus, if the standard library was packaged and releases were made on PyPI
> (in addition to including them normally in the Python releases), we *might*
> be able to use PyPI's commenting infrastructure on this packages (~evil
> grin~).
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com
>

I kinda like the idea that the only packages included in the python
trunk would be distribute and pip (maybe just svn:external). Upon
packaging python for distribution (by installer or by source) the
relevant batteries would be included. Moving packages in and out of
the standard library just becomes so standard.

But of course this really should be decided by the people who work
most with the trunk and as I understand
http://mail.python.org/pipermail/stdlib-sig/2009-September/000609.html
this discussion's already run its course.

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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Anand Balachandran Pillai 
On Fri, Nov 13, 2009 at 1:08 AM, "Martin v. Löwis" wrote:

> > I am not an expert, I am just another python learner. These are just my
> > views on the state of the standard libraries and to
> > make them state-of-the-art..! ;)
>
> If I understand correctly, you want the (current) standard library to be
> separated from the Python implementation, and available separately.
>
> Interestingly enough, people are very much split over whether that would
> be a good thing or not. Some like it the way Python does, some dislike
> it (and some quite strongly so).
>
> In any case, many Python users consider it a good thing that it comes
> "with batteries included", ie. with no need to add extra stuff for many
> tasks.
>
> Some of the Python maintainers have recently started objecting to this
> setup, asking that the standard library should be split into separate
> packages that are released and distributed independent of Python. Others
> of us feel strongly that such a change should not be made.
>
> So don't expect any immediate change to happen.
>

 I think the recent postings on "CPAN for Python"  in this list also stems
 from similar thoughts. As the size of the Python std library increases,
 and when it reaches a kind of implosion point (perhaps it is there
already),
 it does make sense to split it into some thing like a "core" group of
 modules and add-ons which could be updated dynamically as and when
 required by a  tool.

 It could be something as simple as a "require" keyword which could
 pull in the depdencies if not found. Perhaps at the top of your module,

 require (stuff, '1.27')
 import stuff

 Anyone who takes a quick look at the Python std library now is
 sure to feel that there is an overkill of stuff there, which could be
 classified and packaged better than dumping into the language
 build.


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



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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Masklinn 
On 13 Nov 2009, at 11:36 , Anand Balachandran Pillai wrote:
> I think the recent postings on "CPAN for Python"  in this list also stems
> from similar thoughts.
No. The CPAN for Python messages (in and out of the list) are about third-party 
packages and a better way to manage (and a better experience of installing) 
those.

Think Ruby, it has a significant stdlib (though not as extensive as Python's), 
but it also has gems (and the `gem` CLI util). Or Haskell, which also has a 
significant stdlib (GHC does anyway) but also has cabal and cabal-install.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Wolodja Wentland 
On Fri, Nov 13, 2009 at 18:00 +1100, Ben Finney wrote:
> Steven D'Aprano  writes:
> 
> > In my opinion, the community is best served by a good comment/review 
> > system, one which avoids the worst trolling, and allows authors the 
> > right of reply, but does not allow authors to censor inconvenient but 
> > honest reviews. 

> I also think, though, that the community is best served by an objective
> repository of third-party Python packages, with information derived only
> directly from the package itself and objective data. That allows the
> least barrier to having a package maintainer want to register their
> package with such a service, which is in the interest of having it be as
> complete a registry of packages as can be.
V> 
> A community forum, on the other hand, has many characteristics that will
> be *disincentives* to a package manager for having their package appear
> there. It's never going to attract as many package maintainers as an
> impartial, objective registry; the many reasons already given here as to
> why some package maintainers *don't* want their packages in such a
> system are evidence of that.
+1

I think that there are a lot of things that could be done to make PyPi a
place where users can find *high wuality* packages and one that makes it
desirerably for developers to have their packages listed there.
Unfortunately comments *on the package main page* is not among them.

I think the PyPi/Python developers should consider the following points:

* PyPi is the de facto *official* repository of third party packages
  that form the "enhanced" stdlib

* I as a developer chose PyPi to be the *official* website of my
  projects and I want to have control over this website.

I could name a plethora of things I would do to enhance PyPi and here
are some ideas:

Better UI
-

Right now the package consists of a single page and all information is
cramped in there. I would suggest having a "tab-style" bar containing
things like:

* Package description/Home (default)
* Documentation

  Right now I have to place a link to the documentation I uploaded
  to PyPi in the package description myself? Why? Include that
  automatically on the package site as soon as it is uploaded and
  tell the developers about that feature!

* Issue tracker (either hosted on PyPi or somewhere else)
* Downloads (for different releases)
* Comments

  Place comments on a different page, give developers the possibilty
  to enable this feature and react to comments. Maybe include a way
  to rate comments and those with a higher rating will bubble up
  reddit style.

* Changelog
* ...

Automatic Package testing
-

What I really like on PyPi is that my packages are tested automatically
with Cheesecake and the order of packages when searching is determined
by this rating. This gives a huge incentive to work on the package
quality, which is a great thing IMHO. Ratings by users could influence
this ranking as well...

I would take this idea even further.

All packages should be tested automatically and *REJECTED* if they don't
meet certain quality criteria. PyPi should become a place where high
quality packages can be found, not a dump for every single "Hello World"
ever developed.

Debian will run lintian (a Debian package checker) automatically against
newly uploaded packages and reject those that don't meet a basic set of
tests.

Tests could reject packages that:

* FTBFS
* do not install/uninstall cleanly
* miss important files (README, CHANGELOG, .. )
  
  This could leverage platform specific information as in: If it is
  a *nix package and includes scripts, it should have man pages for
  them, 

* rate poorly on automatic tests (pep8, cheesecake, pylint, ...)
* are not GPG signed
* have not specified a license
* ...

I admit that this makes PyPi a much stricter place and suggest that
sections are introduced that define different rules for inclusion (like
Debian's stable, testing, unstable - main, contrib, non-free). There
could be sections like this:

* main - manually checked packages of high quality
  This would comprise packages of a high enough quality to be deemed
  acceptable in the stdlib 

* tested - packages not in main that rank high on automatic tests
* ...
* junk (better name required)

Users could then decide which parts they want pip to retrieve packages
from. We could even encourage github, bitbucket, sourceforge, ... to
provide ways to automatically query their repositories from pip so they
could be included in pip's "sources.list" and used to install
dev-versions, packages of por quality.

*IF* Python plans to develop a fully fledged platform agnostic package
manager for Python programs/libraries it would be wise to learn from the
solutions people came up with until now (aptitude, yum, pkg_add, emerge,
...)

kind regards

Wolodja Wentland

Re: [Python-Dev] Python-Dev Digest, Vol 76, Issue 114

2009-11-13 Thread wa2n39 
Please don't send me again this email


--Pesan Asli--
Dari:[email protected]
Pengirim:[email protected]
Ke:[email protected]
Balas Ke:[email protected]
Perihal:Python-Dev Digest, Vol 76, Issue 114
Terkirim:13 Nov 2009 03:00

Send Python-Dev mailing list submissions to
[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
[email protected]

You can reach the person managing the list at
[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."


Today's Topics:

   1. Re: standard libraries don't behave like standard 'libraries'
  (Masklinn)


--

Message: 1
Date: Fri, 13 Nov 2009 11:50:49 +0100
From: Masklinn 
To: Python-Dev 
Subject: Re: [Python-Dev] standard libraries don't behave like
standard'libraries'
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

On 13 Nov 2009, at 11:36 , Anand Balachandran Pillai wrote:
> I think the recent postings on "CPAN for Python"  in this list also stems
> from similar thoughts.
No. The CPAN for Python messages (in and out of the list) are about third-party 
packages and a better way to manage (and a better experience of installing) 
those.

Think Ruby, it has a significant stdlib (though not as extensive as Python's), 
but it also has gems (and the `gem` CLI util). Or Haskell, which also has a 
significant stdlib (GHC does anyway) but also has cabal and cabal-install.

--

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


End of Python-Dev Digest, Vol 76, Issue 114
***


Sent from my BlackBerry®
powered by Sinyal Kuat INDOSAT
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Sriram Srinivasan 
as people like to compare languages take ruby for example (i am confident
that there will be no flame war here ;) )

we have PyPI
they have RAA

we have ?
they have rubyforge

i am seeing the rubyforge site now on my other tab, i find

Communications (365 projects)
Database (245 projects)
Desktop Environment (80 projects)
Education (81 projects)
Games/Entertainment (225 projects)
Internet (1339 projects)
Multimedia (296 projects)
Office/Business (226 projects)
Other/Nonlisted Topic (82 projects)
Printing (23 projects)
Religion (7 projects)
Scientific/Engineering (278 projects)
Security (86 projects)
Sociology (16 projects)
Software Development (1164 projects)
System (548 projects)
Terminals (37 projects)
Text Editors (136 projects)

these are the ongoing library development. although they are small in number
but it is put very clear.

in python the only way i have found about the libraries we have is by using
the doc (docs is great at this).
but i find less/no details about standalone/libraries that are not part of
python stdlib. (google is great at this)

lets take RAA now,

By Category
 Application
  114 subcategories
  553 projects
 Documentation
  14 subcategories
  31 projects
 Library
  150 subcategories
  1179 projects
 Ports
  8 subcategories
  10 projects

* By Project(ALL): 286 subcategories, 1773 projects
* By Owner: 905 owners

first of all they can never ever beat python's record of packages.

its funny i found a ruby project in pypi. on further inspection [rython
0.0.1] a library module for coding in ruby inside python code
transparently... how awesome..! its happy to see that libraries already has
taken the add-on feature. sad to see libraries mixed up with software
packages (no one will find about  the library amidst those 1000's of
software!

packaging libraries has some other advantages too, like accumulation of
ideas happen. what if i design a *library* and no one uses it? whats the
point in creating? but if i could upload that in pypi or something like
that, also one python core active developer has had a look in to that, and
might one day be integrated with the standard modules..!

the best thing for now i propose is that segregating libraries and
applications in pypi. if thats a first stage bring about an awesome library
for distribution of packages (already in progress). third is chunk the
standard library and start providing the packages. seems simple but already
the python community is waiting for a long time.

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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Sriram Srinivasan 
http://pypi.python.org/pypi?%3Aaction=search&term=library&submit=search

this lists all the packages with the term 'library' in it.

-- 

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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Nick Coghlan 
Sriram Srinivasan wrote:
> http://pypi.python.org/pypi?%3Aaction=search&term=library&submit=search
> 
> 
> this lists all the packages with the term 'library' in it.

Sriram,

Please take this discussion to catalog-sig - python-dev isn't the place
(the fact that many of us didn't immediately know the *right* place for
the discussion indicates where PyPI sits on our personal active level of
interest).

You should find more interested (and knowledgable) folks and catalog-sig.

Regards,
Nick.

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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Steven D'Aprano 
On Fri, 13 Nov 2009 09:36:10 pm Anand Balachandran Pillai wrote:

> It could be something as simple as a "require" keyword which could
>  pull in the depdencies if not found. Perhaps at the top of your
> module,
>
>  require (stuff, '1.27')
>  import stuff

So Python, the *language*, has to become a package management system as 
well as a programming language?

No thank you.

At most, perhaps there could be a package management tool in the 
standard library:

try:
  import stuff
except ImportError:
  import packman
  found = packman.requires(stuff, '1.27')
  if found:
import stuff
  else:
fail()



> Anyone who takes a quick look at the Python std library now is
>  sure to feel that there is an overkill of stuff there, which could
> be classified and packaged better than dumping into the language
> build.

I don't.

I think the std library could possibly be organised better, but just 
because something isn't useful to me right now, doesn't mean it isn't 
useful to someone, and may be useful to me tomorrow.



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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Anand Balachandran Pillai 
On Fri, Nov 13, 2009 at 6:44 PM, Steven D'Aprano wrote:

> On Fri, 13 Nov 2009 09:36:10 pm Anand Balachandran Pillai wrote:
>
> > It could be something as simple as a "require" keyword which could
> >  pull in the depdencies if not found. Perhaps at the top of your
> > module,
> >
> >  require (stuff, '1.27')
> >  import stuff
>
> So Python, the *language*, has to become a package management system as
> well as a programming language?
>
> No thank you.
>
> At most, perhaps there could be a package management tool in the
> standard library:
>
> try:
>  import stuff
> except ImportError:
>  import packman
>  found = packman.requires(stuff, '1.27')
>  if found:
>import stuff
>  else:
>fail()
>
>
>
 That was just a suggestion, don't take it literally. My intention
was something similar to the stuff you have written above.
 It would be however useful to standardize the pkg manager
 "packman" to something in the standard library however.


>
> > Anyone who takes a quick look at the Python std library now is
> >  sure to feel that there is an overkill of stuff there, which could
> > be classified and packaged better than dumping into the language
> > build.
>
> I don't.
>
> I think the std library could possibly be organised better, but just
> because something isn't useful to me right now, doesn't mean it isn't
> useful to someone, and may be useful to me tomorrow.
>
>
>
 Ah yes, the only problem is that for any updates/fixes to your
 module, you need to wait for the language release which is not
 very much an ideal situation IMHO. Especially now when we are
 in discussions about end of life of 2.x etc...

 W.r.t the original analogy, batteries v 1.1 are included with the torch
1.1,
 but if you want battery upgrade to 1.2, you need to buy torch 1.2..


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



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

[Python-Dev] Fwd: standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Sriram Srinivasan 
Sriram,
>
> Please take this discussion to catalog-sig - python-dev isn't the place
> (the fact that many of us didn't immediately know the *right* place for
> the discussion indicates where PyPI sits on our personal active level of
> interest).
>
> You should find more interested (and knowledgable) folks and catalog-sig.
>
> Regards,
> Nick.
>


sorry for posting the link in a lone post, i must have posted it with my
previous post, and the theme is how to make the standard libraries
state-of-the-art and i many feel it must be in py-dev as it is directly
connected with the development of python. As it required some comparison, i
compared pypi with the ruby's *rubyforge*. in fact what i found astonishing
is that there are a lot of libraries (3rd party) available in packaged
forms. which is a very good sign, the problem is there is no sorted out list
for libraries and software in pypi.

*rubyforge* is like a pypi for *libraries* (standard and 3rd party)

i guess some misplaced topics such as [Python-Dev] PyPI comments and
ratings, *really*? , [Python-Dev] PyPI front page
are also getting alarming responses in the py-dev list. including yours, ;)


As Anand says requiring a new update of battery v1.5 requires update of
python/flashlight which only occurs every release is the manin senario.

I would also like to add that what if a company doesn't need the batteries
that you give at the first place, they have developed their own batteries
and want to use them(or use some from the default with theit own), also
wants to use the same flashlight/python system? - it would be *easy* only if
the batteries included had a feature of being removed.

-- 

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

[Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Sriram Srinivasan 
> Sriram,
>
> Please take this discussion to catalog-sig - python-dev isn't the place
> (the fact that many of us didn't immediately know the *right* place for
> the discussion indicates where PyPI sits on our personal active level of
> interest).
>
> You should find more interested (and knowledgable) folks and catalog-sig.
>
> Regards,
> Nick.
>


sorry for posting the link in a lone post, i must have posted it with my
previous post, and the theme is how to make the standard libraries
state-of-the-art and i many feel it must be in py-dev as it is directly
connected with the development of python. As it required some comparison, i
compared pypi with the ruby's *rubyforge*. in fact what i found astonishing
is that there are a lot of libraries (3rd party) available in packaged
forms. which is a very good sign, the problem is there is no sorted out list
for libraries and software in pypi.

*rubyforge* is like a pypi for *libraries* (standard and 3rd party)

i guess some misplaced topics such as [Python-Dev] PyPI comments and
ratings, *really*? , [Python-Dev] PyPI front page
are also getting alarming responses in the py-dev list. including yours, ;)


As Anand says requiring a new update of battery v1.5 requires update of
python/flashlight which only occurs every release is the manin senario.

I would also like to add that what if a company doesn't need the batteries
that you give at the first place, they have developed their own batteries
and want to use them(or use some from the default with theit own), also
wants to use the same flashlight/python system? - it would be *easy* only if
the batteries included had a feature of being removed.

-- 

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

Re: [Python-Dev] PyPI front page

2009-11-13 Thread anatoly techtonik 
On Fri, Nov 13, 2009 at 9:35 AM, "Martin v. Löwis"  wrote:
>> Ben Finney  benfinney.id.au> writes:
>>> There's a problem with the poll's placement: on the front page of the
>>> PyPI website.
>>
>> Speaking of which, why is it that http://pypi.python.org/pypi and
>> http://pypi.python.org/pypi/ (note the ending slash) return different 
>> contents
>> (the latter being very voluminous)? I always mistake one for the other when
>> entering the URL directly.
>
> As Ian says: setuptools relies on it. It's part of the specification of
> the package index.

Where is that specification? Does it require only
http://pypi.python.org/pypi/ to be voluminous or also
http://pypi.python.org/pypi to provide some search interface for
automatic processing? There should be no problem in moving search page
to the root http://pypi.python.org/ if spec is silent about the
latter.

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

[Python-Dev] Summary of Python tracker Issues

2009-11-13 Thread Python tracker 

ACTIVITY SUMMARY (11/06/09 - 11/13/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2491 open (+27) / 16645 closed (+14) / 19136 total (+41)

Open issues with patches:   993

Average duration of open issues: 684 days.
Median duration of open issues: 442 days.

Open Issues Breakdown
   open  2455 (+27)
pending35 ( +0)

Issues Created Or Reopened (42)
___

test_debuglevel from test_telnetlib.py fails 11/06/09
CLOSED http://bugs.python.org/issue6748reopened r.david.murray  
  
   patch, buildbot 

json module apparently fails regression found at http://json.org 11/06/09
CLOSED http://bugs.python.org/issue7274created  DougShawhan 
  
   

CoverageResult fails to merge input file with non-empty callers  11/06/09
   http://bugs.python.org/issue7275created  glinsvad
  
   patch   

UnboundLocalError scoping problem with nested functions  11/06/09
CLOSED http://bugs.python.org/issue7276created  olau
  
   

online docs out-of-sync with sources and distributed .chm files  11/07/09
CLOSED http://bugs.python.org/issue7277created  gagenellina 
  
   

decimal.py: New instance vs. new reference   11/07/09
CLOSED http://bugs.python.org/issue7278created  skrah   
  
   

decimal.py: == and != comparisons involving NaNs 11/07/09
CLOSED http://bugs.python.org/issue7279created  skrah   
  
   

PCBuild instruction says to use nasmw.exe but it no longer exist 11/07/09
   http://bugs.python.org/issue7280created  blep
  
   patch   

copysign() with NaN arguments on OpenSolaris 11/07/09
CLOSED http://bugs.python.org/issue7281created  skrah   
  
   

RLocks leak references when used in raw threads  11/08/09
CLOSED http://bugs.python.org/issue7282created  pitrou  
  
   patch   

test_site failure when .local/lib/pythonX.Y/site-packages hasn't 11/08/09
   http://bugs.python.org/issue7283created  pitrou  
  
   

optparse - display version in usage by default   11/08/09
   http://bugs.python.org/issue7284created  techtonik   
  
   

multiprocessing module, example code error   11/08/09
   http://bugs.python.org/issue7285created  hsmtkk  
  
   patch   

odd exec() behavior or documentation 11/08/09
   http://bugs.python.org/issue7286created  pmawhorter  
  
   

import hook demo does not work   11/08/09
   http://bugs.python.org/issue7287created  blep
  
   

Detect improper leading whitespace in C files for Vim11/08/09
   http://bugs.python.org/issue7288created  brett.cannon
  
   easy

bad import in redemo.py script in v3.1   11/08/09
CLOSED http://bugs.python.org/issue7289created  [email protected]   
  
   

Update 'how do I set a global variable' faq entry11/09/09
CLOSED http://bugs.python.org/issue7290created  r.david.murray  
  
   patch   

urllib2 cannot handle https with proxy requiring auth11/09/09
   http://bugs.python.org/issue7291created  tsujikawa   
  
   patch

Re: [Python-Dev] decimal.py: == and != comparisons involving NaNs

2009-11-13 Thread Adam Olsen 
On Mon, Nov 9, 2009 at 06:01, Mark Dickinson  wrote:
> Well, when running in some form of 'non-stop' mode, where (quiet) NaN
> results are supposed to be propagated to the end of a computation, you
> certainly want equality comparisons with nan just to silently return false.
> E.g., in code like:
>
> if x == 0:
>    
> else:
>    
>
> nans should just end up in the second branch, without the programmer
> having had to think about it too hard.

if x != 0:

else:


nans should just end up in the first branch, without the programmer
having had to think about it too hard.

There is a more consistent alternative: have all comparisons involving
NaN also return NaN, signifying they're unordered.  Let bool coercion
raise the exception.  Thus, both examples would raise an exception,
but a programmer who wants to handle NaN could do so explicitly:

temp = x == 0
if temp.isnan() or temp:

else:


IEEE 754 is intended for a very different context.  I don't think it
makes sense to attempt literal conformance to it.


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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Paul Moore 
2009/11/13 Tres Seaver :
> I can see the information about the poll, and a link to view the
> results, without logging in.
>
>  http://pypi.python.org/pypi
>
> (second paragraph there).  That paragraph tells you that you need to log
> in to vote in the poll.

I don't want to create a PyPI account (more account details I'll
rarely use to remember) just to vote. I can see why anonymous votes
are bad, but the sample's going to be self-selecting - people like me
who don't want to create an account will be excluded.

By the way, there's no way for me to vote that I don't care what
option ends up being chosen, but I strongly oppose choosing something
that would tend to make developers avoid using PyPI.

The distutils/setuptools/distribute/... saga has fragmented Python's
package ecosystem enough already. Let's not have PyPI go the same way
:-(

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Georg Brandl 
Ben Finney schrieb:
> Michael Sparks  writes:
> 
>> On Fri, Nov 13, 2009 at 12:44 AM, Ben Finney  
>> wrote:
>> > So, the poll's audience is limited to those who visit the front page
>> > (which is hardly ever necessary for package maintainers), and those
>> > who already know it exists (e.g. through this discussion thread).
>> > You'll be missing the opinions of those maintainers who, like the OP
>> > of this thread, only discovered the behaviour much later.
>>
>> This poll is only visible if you're logged into PyPI. This strikes me
>> as a mistake. I went looking for a poll and didn't see it.
> 
> The mistake, I think, is having a poll basically asking “what should the
> PyPI maintainers do?”, instead of weighing evidence and reasoned
> arguments. A poll may be good for gathering preferences and opinion, but
> it's a poor way to make a *decision*.

I haven't seen Martin commit to doing whatever the poll's preferred outcome
was.  I think it's just to see if there is really so much silent resistance
or support as is claimed by both arguing sides.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Matthew Woodcraft 
Martin v. Löwis  wrote:
> Because I want to wait for the outcome of the poll first.

The pypi front page says:

| The poll will be closed on December 1, 2009. The option that receives
| most votes will be implemented.


As I write, the option with the most votes is /Allow both ratings and
comments/.

But between them, /Disallow comments/ and /Disallow both ratings and
comments/ have more votes.

It seems clear to me that, given those figures, allowing comments would
not be following the result of the vote.

So I think that simply implementing the option that receives most votes
is not a wise plan.


(There are two other options; I don't think their presence makes the
plan any wiser.)

-M-

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Antoine Pitrou 
Matthew Woodcraft  woodcraft.me.uk> writes:
> 
> It seems clear to me that, given those figures, allowing comments would
> not be following the result of the vote.
> 
> So I think that simply implementing the option that receives most votes
> is not a wise plan.

Can we defer any further discussion about this until the poll is closed?

Thank you

Antoine.


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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Ben Finney 
Paul Moore  writes:

> By the way, there's no way for me to vote that I don't care what
> option ends up being chosen, but I strongly oppose choosing something
> that would tend to make developers avoid using PyPI.

There's also no option to vote that decisions on how to manage Python
infrastructure (like PyPI) shouldn't be made by popular vote.

-- 
 \  “I like to reminisce with people I don't know. Granted, it |
  `\ takes longer.” —Steven Wright |
_o__)  |
Ben Finney

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

Re: [Python-Dev] decimal.py: == and != comparisons involving NaNs

2009-11-13 Thread Mark Dickinson 
On Fri, Nov 13, 2009 at 6:18 PM, Adam Olsen  wrote:
> On Mon, Nov 9, 2009 at 06:01, Mark Dickinson  wrote:
>> Well, when running in some form of 'non-stop' mode, where (quiet) NaN
>> results are supposed to be propagated to the end of a computation, you
>> certainly want equality comparisons with nan just to silently return false.
>> E.g., in code like:
>>
>> if x == 0:
>>    
>> else:
>>    
>>
>> nans should just end up in the second branch, without the programmer
>> having had to think about it too hard.
>
> if x != 0:
>    
> else:
>    
>
> nans should just end up in the first branch, without the programmer
> having had to think about it too hard.

And they do:  nan != 0 returns False.  Maybe I'm missing your point
here?

> IEEE 754 is intended for a very different context.  I don't think it
> makes sense to attempt literal conformance to it.

I disagree.  The decimal specification is tied closely to
IEEE 754 (the 2008 version), to the extent that even minor changes
made by the 754r working group were mirrored in the decimal
specification as it evolved;  it only stopped evolving after IEEE
754-2008 was complete.

IEEE 754-2008 also makes a point of targeting languages, rather than
just floating-point hardware;  to me it seems very much applicable
to decimal.py.

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

Re: [Python-Dev] decimal.py: == and != comparisons involving NaNs

2009-11-13 Thread Mark Dickinson 
On Fri, Nov 13, 2009 at 9:50 PM, Mark Dickinson  wrote:
> And they do:  nan != 0 returns False.  Maybe I'm missing your point
> here?

Aargh!  True!  I meant to say True!

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

Re: [Python-Dev] decimal.py: == and != comparisons involving NaNs

2009-11-13 Thread Adam Olsen 
On Fri, Nov 13, 2009 at 14:52, Mark Dickinson  wrote:
> On Fri, Nov 13, 2009 at 9:50 PM, Mark Dickinson  wrote:
>> And they do:  nan != 0 returns False.  Maybe I'm missing your point
>> here?
>
> Aargh!  True!  I meant to say True!

Huh.  Somewhere along the line I lost track of how python handled NaN.
 I thought "comparisons always evaluate to false" was the rule.


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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread A.M. Kuchling 
On Sat, Nov 14, 2009 at 08:43:25AM +1100, Ben Finney wrote:
> There's also no option to vote that decisions on how to manage Python
> infrastructure (like PyPI) shouldn't be made by popular vote.

If the open source approach of 'the maintainer decides' is followed,
well, both the maintainer of the code and the admin of the site is
Martin.  Comments stay, then.

If 'BDFL decides' is followed, GvR thinks the idea is reasonable
(http://mail.python.org/pipermail/python-dev/2009-November/094058.html),
though the implementation might be improved.  Again, comments stay.

If popular vote is ruled out, I don't see who else could possibly make
the decision to disable comments and/or ratings.

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Jacob Kaplan-Moss 
On Fri, Nov 13, 2009 at 1:33 PM, Paul Moore  wrote:
> By the way, there's no way for me to vote that I don't care what
> option ends up being chosen, but I strongly oppose choosing something
> that would tend to make developers avoid using PyPI.

I think the damage has already been done. There are enough people --
I'm one -- who feel this has revealed huge flaws in PyPI's
stewardship. I'm pretty convinced, results of the poll or not, that
the way PyPI is being run is fatally flawed.

This "poll" business is just smoke and mirrors, anyway -- notice the
way the "no comments" votors are split among three choices, while the
"pro comments" voters have just two choices. It's also worded in a way
that obscures the real debate. Regardless of the outcome, the poll's
not going to change anyone's mind, and it certainly won't change the
fact that PyPI's being run as a one-man show, not as a community
resource.

I'm just not comfortable with that. Unless PyPI changes its governance
radically, I'm not going to invest any more effort in it.

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Thomas Heller 
A.M. Kuchling schrieb:

> If the open source approach of 'the maintainer decides' is followed,
> well, both the maintainer of the code and the admin of the site is
> Martin.  Comments stay, then.
> 
> If 'BDFL decides' is followed, GvR thinks the idea is reasonable
> (http://mail.python.org/pipermail/python-dev/2009-November/094058.html),
> though the implementation might be improved.  Again, comments stay.
> 
> If popular vote is ruled out, I don't see who else could possibly make
> the decision to disable comments and/or ratings.

+1

-- 
Thanks,
Thomas

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Ben Finney 
"A.M. Kuchling"  writes:

> If popular vote is ruled out, I don't see who else could possibly make
> the decision to disable comments and/or ratings.

Reasoned argument with the person who decides. A bad idea with many
people's support is still a bad idea; a good idea with few people's
support is still a good idea.

-- 
 \“I have a microwave fireplace in my house. The other night I |
  `\   laid down in front of the fire for the evening in two minutes.” |
_o__)   —Steven Wright |
Ben Finney

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Steven D'Aprano 
On Sat, 14 Nov 2009 09:57:18 am Ben Finney wrote:
> "A.M. Kuchling"  writes:
> > If popular vote is ruled out, I don't see who else could possibly
> > make the decision to disable comments and/or ratings.
>
> Reasoned argument with the person who decides. A bad idea with many
> people's support is still a bad idea; a good idea with few people's
> support is still a good idea.


Okay, let's talk reasoned debate.

I understand the reason for making comments compulsory: they're for the 
benefit of the users, not the package owner. It helps prevent 
information about the package from being fragmented: there is One 
Obvious place to find out about a package on PyPI, which is the PyPI 
page, instead of having to search for blogs where people may or may not 
have made comments about the package. If individual package owners 
don't like this, too bad, because PyPI is run for the benefit of the 
community, not individual package owners.

I understand the reason for making comments optional: personal choice of 
the package owner is valuable in and of itself, even if it is against 
the best interests of the community.

But for the life of me, I can't understand the 1/3 of the votes that 
have been cast in favour of prohibiting comments for everybody, even 
those who want comments.


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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Steven D'Aprano 
On Sat, 14 Nov 2009 09:17:40 am Jacob Kaplan-Moss wrote:

> This "poll" business is just smoke and mirrors, anyway -- notice the
> way the "no comments" votors are split among three choices, while the
> "pro comments" voters have just two choices.

What?

Allow ratings and comments on all packages (status quo)
Allow package owners to disallow comments (ratings unmodified)
Allow comments, but only send them to package owners (ratings 
unmodified)
Disallow comments (ratings unmodified)
Disallow ratings and comments (status three months ago)

That's three choices for allowing comments, two for disallowing.




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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Steven D'Aprano 
On Sat, 14 Nov 2009 08:34:32 am Matthew Woodcraft wrote:

> As I write, the option with the most votes is /Allow both ratings and
> comments/.
>
> But between them, /Disallow comments/ and /Disallow both ratings and
> comments/ have more votes.

If that's an accurate characterisation, then things must have changed 
*radically* in just a few minutes, because the voting at 8:38am 
(Melbourne time) was running 2:1 in favour of allowing comments versus 
disallowing them. At 10:17 it's still running at the same ratio, 
although the individual votes have changed slightly.


> It seems clear to me that, given those figures, allowing comments
> would not be following the result of the vote.

Why do you think it is okay to combine the Disallow vote, without also 
combining the Allow vote? Less than a third of the total votes are in 
favour of disallowing comments, with two-thirds in favour of allowing 
them.




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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Steven D'Aprano 
On Sat, 14 Nov 2009 10:19:17 am Steven D'Aprano wrote:
> On Sat, 14 Nov 2009 09:17:40 am Jacob Kaplan-Moss wrote:
> > This "poll" business is just smoke and mirrors, anyway -- notice
> > the way the "no comments" votors are split among three choices,
> > while the "pro comments" voters have just two choices.
>
> What?
>
> Allow ratings and comments on all packages (status quo)
> Allow package owners to disallow comments (ratings unmodified)
> Allow comments, but only send them to package owners (ratings
> unmodified)
> Disallow comments (ratings unmodified)
> Disallow ratings and comments (status three months ago)
>
> That's three choices for allowing comments, two for disallowing.

Sorry, I should have been more explicit:

The first choice makes comments compulsory. In other words, comments are 
allowed.

The second choice makes comments optional. Whether it is opt-in or 
opt-out, PyPI still allows comments as an option.

The third choice makes comments available, but private. That's still 
allowing comments.

Only the fourth and fifth options disallow comments. If you don't want 
there to be comments on PyPI, you only have two choices: 4 or 5.



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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Matthew Woodcraft 
Steven D'Aprano   wrote:
> Why do you think it is okay to combine the Disallow vote, without also
> combining the Allow vote? Less than a third of the total votes are in
> favour of disallowing comments, with two-thirds in favour of allowing
> them.

I don't. I was giving one example of the problem with the plan of not
combining options at all.

I wasn't writing to take sides. I was trying to say that using 'first
past the post' voting with five options which are combinations of
different issues (comments, ratings, whether to allow package owners to
opt out) can't be expected to give a good decision.

I think there is no safe way to pick a winner from this vote (unless
more than half the voters choose a single option).


(As a general point, in any discussion it tends to be unhelpful to ask
"Why do you think X" unless the person you're asking has clearly
indicated that they do in fact think X.)

-M-

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

Re: [Python-Dev] Status of the Buildbot fleet and related bugs

2009-11-13 Thread Antoine Pitrou 
Martin v. Löwis  v.loewis.de> writes:
> 
> > The buildbots still show occasional oddities. For example, right now in 
> > the page "http://www.python.org/dev/buildbot/3.x/";, some results have 
> > disappeared (the columns for "AMD64 Ubuntu" builders have become empty). 
> 
> Yes, I noticed it too. It will go away after some page reloads.

It is still happening more or less randomly unfortunately.
http://www.python.org/dev/buildbot/3.x/


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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Robert Kern 
[We really should be discussing this on catalog-sig, but moving things 
mid-thread never works, so here we go. I apologize to python-dev. I also 
apologize for the length.]


On 2009-11-13 17:18 PM, Steven D'Aprano wrote:

On Sat, 14 Nov 2009 09:57:18 am Ben Finney wrote:

"A.M. Kuchling"  writes:

If popular vote is ruled out, I don't see who else could possibly
make the decision to disable comments and/or ratings.


Reasoned argument with the person who decides. A bad idea with many
people's support is still a bad idea; a good idea with few people's
support is still a good idea.


Okay, let's talk reasoned debate.

I understand the reason for making comments compulsory: they're for the
benefit of the users, not the package owner. It helps prevent
information about the package from being fragmented: there is One
Obvious place to find out about a package on PyPI, which is the PyPI
page, instead of having to search for blogs where people may or may not
have made comments about the package. If individual package owners
don't like this, too bad, because PyPI is run for the benefit of the
community, not individual package owners.

I understand the reason for making comments optional: personal choice of
the package owner is valuable in and of itself, even if it is against
the best interests of the community.

But for the life of me, I can't understand the 1/3 of the votes that
have been cast in favour of prohibiting comments for everybody, even
those who want comments.


While I do have a couple of packages on PyPI, I use PyPI as a consumer of 
packages much more frequently, every day in fact. I voted against comments and 
ratings because I think it is a detriment to my experience of PyPI as a user (I 
also think that they will be a detriment to the community, but that's a 
prediction, not a fact). Short form comments are simply not useful to me. 
Ratings are worse. They do not carry reliable information; they carry short 
statements of opinion from a wide variety of experiences, most of which are 
entirely unrelated to my own needs.


To make an example, I have a lot of experience making ornery stuff build. A lot 
of other people don't. Their personal experience of not managing to install a 
package correctly turns into a weird, objective-seeming statement that the 
"package is difficult to build". People have different thresholds, different 
experiences, and different standards.


When such opinions get numerically aggregated by a monolithic rating system, 
that's even worse. Even with short-form comments, they have the ability, though 
often not the propensity, to give a little bit of information ("I had trouble 
building it on Windows.") that can help me tease out whether their experiences 
will be relevant to mine, but one star is just one star.


I *do* like to read long-form reviews where people relate what their needs were, 
what they tried to use the package for, and exactly where the package succeeded 
and where it failed. I can compare that context with my own needs and extract 
the relevant parts of their experience. Blogs are great for that.


Now I do appreciate ratings and comments on shopping sites if they don't provide 
the capability for long-form reviews. But that's because the product is locked 
behind the barrier of payment and often shipping. There is no such barrier on 
PyPI. If I can get to a web view of their repository, thirty seconds with it 
will give a much better idea of whether the package is worth trying than any 
amount of comments I could read in that time. I can easily see how much 
documentation they have, if they have funny build requirements, if they are just 
prototyping, etc. without needing to trust that everyone else has needs and 
standards like mine. That's the key difference between comments and ratings on 
shopping sites and why I don't think that their success in that field translates 
to here.


If you want one idea that would make my use of PyPI much more pleasant and 
informative, it would be to add a "Repository-URL" entry to the recommended PyPI 
metadata so that I could always start looking at the code in one click. Or 
integrate the source code browsing into PyPI itself; it could open up the sdists 
and eggs and show a WebVCS-like browser interface.


Now, these are all reasons why commenting and rating are not beneficial to me. 
Where I think they are harmful is that when one is exposed to them, one cannot 
just ignore them. They have an emotional, unreasonable impact whether I want 
them to or not. And that's why I do not want to see them. Give me access to 
information, not opinions. If authors do want comments and ratings on their 
packages, let them use the services that already exist for *just* that purpose 
like Ohloh. They have the time and energy to implement these mechanisms with the 
care and attention that they need.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own ma

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread skip 

>> Frankly, I agree with him. As implemented, I *and others* think this
>> is broken. I've taken the stance of not publishing things to PyPi
>> until A> I find the time to contribute to make it better or B> It
>> changes.

Barry> That's distressing.  For better or worse PyPI is the central
Barry> repository of 3rd party packages.  It should be easy, desirable,
Barry> fun and socially encouraged to get your packages there.

I only realized people could comment on my packages when I got the poll
email from Martin.  It then took me awhile to figure out how to actually see
comments about my packages.


https://sourceforge.net/tracker/?func=detail&aid=2897527&group_id=66150&atid=513503

At the very least I think the feature needs to be easier for package
authors to use.

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread MRAB 

Matthew Woodcraft wrote:

Steven D'Aprano   wrote:

Why do you think it is okay to combine the Disallow vote, without also
combining the Allow vote? Less than a third of the total votes are in
favour of disallowing comments, with two-thirds in favour of allowing
them.


I don't. I was giving one example of the problem with the plan of not
combining options at all.

I wasn't writing to take sides. I was trying to say that using 'first
past the post' voting with five options which are combinations of
different issues (comments, ratings, whether to allow package owners to
opt out) can't be expected to give a good decision.

I think there is no safe way to pick a winner from this vote (unless
more than half the voters choose a single option).


(As a general point, in any discussion it tends to be unhelpful to ask
"Why do you think X" unless the person you're asking has clearly
indicated that they do in fact think X.)


Perhaps Approval voting should be used:

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

Re: [Python-Dev] PyPI governance

2009-11-13 Thread Chris Withers 

Jacob Kaplan-Moss wrote:

that obscures the real debate. Regardless of the outcome, the poll's
not going to change anyone's mind, and it certainly won't change the
fact that PyPI's being run as a one-man show, not as a community
resource.


While I may not agree on his choices regarding comments and ratings, I 
don't feel this is fair to Martin. No one else, as far as I know, has 
offered to step up and help with the maintenance of PyPI. I don't know 
if Richard is still active, but the lack of response from him would 
suggest not.


A test on your hypothesis would be to offer to help. I don't know who 
has access to the server the software runs on, but ultimately any core 
python committer can change the code in the subversion repository.


I did just actually have a look over the code and was happy to find it 
was a lot simpler than I had feared but a bit dismayed at the style of 
coding and total lack of unit tests ;-)


I might well be up for helping with the maintenance of PyPI if I'm 
welcome, especially as I'm already familiar with a lot of the components 
used, although I don't know how much time I can commit :-(

Martin, are you interested in help?

Chris

PS: While I'm sure a lot of python-dev people are interested in this 
topic, I'm pretty sure this whole huge sprawling thread belongs on 
catalog-sig...


--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread skip 

Jesse> I don't want us to impersonate the mindless, sub-useful drivel
Jesse> found in App store/YouTube/etc comments 99% of the time or the
Jesse> broken "5 star ratings" systems, etc. It's too easy to game.

I implemented a "5-star" system for Musi-Cal back in the day.  Now,
admittedly, rating musicians is a bit different than rating software, but
you would probably be surprised at how much offense one musician can take
when they discover that some other musician got a 4.7 rating and they only
got a 4.2.  :rolleyes:

It did take some effort to reduce the chance that the system would be
subverted.  Similar to a free software site such as PyPI (and unlike a
for-profit system such as the iTunes App Store), I think almost all people
realized that the rating system was there to help the community and that by
polluting the database they only hurt themselves.

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Chris Withers 

Steven D'Aprano wrote:

That's three choices for allowing comments, two for disallowing.


Sorry, I should have been more explicit:

The first choice makes comments compulsory. In other words, comments are 
allowed.


The second choice makes comments optional. Whether it is opt-in or 
opt-out, PyPI still allows comments as an option.


The third choice makes comments available, but private. That's still 
allowing comments.


Only the fourth and fifth options disallow comments. If you don't want 
there to be comments on PyPI, you only have two choices: 4 or 5.


The wording isn't ideal, unless you're in agreement with Martin:

http://mail.python.org/pipermail/catalog-sig/2009-November/002288.html

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyPI governance

2009-11-13 Thread Antoine Pitrou 
Chris Withers  simplistix.co.uk> writes:
> 
> PS: While I'm sure a lot of python-dev people are interested in this 
> topic, I'm pretty sure this whole huge sprawling thread belongs on 
> catalog-sig...

Yes, please :)


Antoine.


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

[Python-Dev] External module tests skipping on Windows build slaves?

2009-11-13 Thread David Bolen 
While working with the Windows (and now Windows 7) build slaves I've
been noticing that a number of "unexpected" test skips are occurring,
mostly for external modules like ssl, bz2, tk, etc...

However, I know for a fact that those libraries are being fetched and
built, so I was a little perplexed that they were being skipped for
testing.  I don't think it's a regression due to the recent slave work,
but something that may have been happening for a while, if not always.

Some manual testing I did would seem to indicate that there's a
problem related to loading the right MS CRT when loading these
modules.  But they seem to reference both debug and non-debug
versions, so even if I copy the CRT DLLs (from the SxS tre) into
pcbuild manually, then I get a CRT assertion about a bad
initialization.  I suspect this wouldn't be a problem when everything
is built in release mode.

I would have sworn they used to get run, but now I'm not so sure.
Perhaps I'm remembering older Python releases with VS.NET 2003, since
the MSVC9 versions of the CRT and the SXS stuff was new with VS 2008 I
think.

Does anyone happen to know if these tests have ever run recently on
the Windows build slaves?

-- David

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread skip 

Guido> Of course, as a user, I might not trust a module that has no
Guido> reviews or ratings.

I suspect the vast majority of projects will never acquire ratings or
reviews.

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

Re: [Python-Dev] PyPI governance

2009-11-13 Thread Jason Baker 
On Fri, Nov 13, 2009 at 6:44 PM, Chris Withers  wrote:
> PS: While I'm sure a lot of python-dev people are interested in this topic,
> I'm pretty sure this whole huge sprawling thread belongs on catalog-sig...

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

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

2009-11-13 Thread Greg Ewing 

Martin v. Löwis wrote:

> Some of the Python maintainers have recently started objecting to this
> setup, asking that the standard library should be split into separate
> packages that are released and distributed independent of Python. Others
> of us feel strongly that such a change should not be made.

I'd be worried, because I would no longer be able to
release an app or package and say "requires Python x.y".
I'd have to list the version numbers of all the micro
packages making up the standard library that I use.

Worse, I'd have to be aware of which ones I actually
*do* use so I could mantain that list, something I don't
have to think about at the moment.

It mightn't be so bad if the whole stdlib were a *single*
package, but I don't see much advantage in that.

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

2009-11-13 Thread Ben Finney 
Steven D'Aprano  writes:

> But for the life of me, I can't understand the 1/3 of the votes that
> have been cast in favour of prohibiting comments for everybody, even
> those who want comments.

You gave reason (and I agree with you) for why, on a service that
allows comments and/or ratings, that users might think less of a
project that chooses to be on the service but then chooses not to have
comments and/or ratings.

Thus, there's a good reason on such a system to *not* participate in the
service at all. A barrier to entry, on something that should be *the*
place to look for third-party Python packages.

To encourage as many third-party packages to register on PyPI, it seems
barriers like that should be removed.

-- 
 \“Please to bathe inside the tub.” —hotel room, Japan |
  `\   |
_o__)  |
Ben Finney

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

Re: [Python-Dev] Status of the Buildbot fleet and related bugs

2009-11-13 Thread R. David Murray 

On Sat, 14 Nov 2009 at 00:09, Antoine Pitrou wrote:

Martin v. L??wis  v.loewis.de> writes:



The buildbots still show occasional oddities. For example, right now in
the page "http://www.python.org/dev/buildbot/3.x/";, some results have
disappeared (the columns for "AMD64 Ubuntu" builders have become empty).


Yes, I noticed it too. It will go away after some page reloads.


It is still happening more or less randomly unfortunately.
http://www.python.org/dev/buildbot/3.x/


The buildbot pages appear to be pretty messed up now.  I get many 404s
(ex: the above url, the all stable builders page), although some seem to
work (ex: the all builders page), and if I stick an 'all' into the URL
for my buildbot page I can get to it, though that's is not the version
of the URL linked from the 'all builders' table header.

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

Re: [Python-Dev] External module tests skipping on Windows build slaves?

2009-11-13 Thread David Bolen 
David Bolen  writes:

> (...)
> I would have sworn they used to get run, but now I'm not so sure.
> Perhaps I'm remembering older Python releases with VS.NET 2003, since
> the MSVC9 versions of the CRT and the SXS stuff was new with VS 2008 I
> think.
>
> Does anyone happen to know if these tests have ever run recently on
> the Windows build slaves?

Just to follow up - after finding an old 2.6a0 tree I had manually
built that worked fine (so clearly it wasn't just VS 2008), I worked
my way through some 2.6 tags and this broke as of 2.6.1, so I think
the tests have been getting skipped since then.

The root problem appears to be the change (r67121 for 2.6 merged from
r67120 in trunk) that removed embedded manifests.

I'll follow up on the issue tracker.

-- David

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

Re: [Python-Dev] Status of the Buildbot fleet and related bugs

2009-11-13 Thread David Bolen 
"R. David Murray"  writes:

> The buildbot pages appear to be pretty messed up now.  I get many 404s
> (ex: the above url, the all stable builders page), although some seem to
> work (ex: the all builders page), and if I stick an 'all' into the URL
> for my buildbot page I can get to it, though that's is not the version
> of the URL linked from the 'all builders' table header.

Yes, I think this just started happening. I'm guessing that the main
site proxies the buildbot URL requests to the buildbot master process,
and when it's down you get the 404s from the main server.

I figured someone might be working on the master, though perhaps it
just burped on its own :-)

-- David

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