On Thu, May 1, 2008 at 4:24 PM, Terry Reedy <tjreedy(a)udel.edu> wrote:
>
> "Guido van Rossum" <guido(a)python.org> wrote in message
> news:ca471dc20805011541y63dd132eo6e67310eaeea3ffa@mail.gmail.com...
>
> | On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <tjreedy(a)udel.edu> wrote:
> | > As I understood this,one needs a diff to comment on.
> | > I can imagine wanting, or wanting others, to be able to comment on a
> file
> | > or lines of files without making a fake diff (of the file versus
> itself or
> | > a blank file). Then only one column would be needed.
> |
> | Yeah, this use case is not well supported. In my experience with the
> | internal tool at Google, I don't think that anybody has ever requested
> | that feature, so perhaps in practice it's not so common. I mean, who
> | wants to review a 5000-line file once it's checked in? :-) The right
> | point for such a review (certainly this is the case at Google) is when
> | it goes in.
>
> I am thinking of an entirely different scenario: a package of modules that
> are maybe a few hundred lines each and that accompany a book and are meant
> for human reading as much or more than for machine execution.
>
> Or this: 15 minutes ago I was reading a PEP and discovered that a link did
> not work. So I find the non-clickable author email at the top and notify
> the author with my email program. But how much nicer to double click an
> adjacent line and stick the comment in place (and let your system do the
> emailing). (I presume the sponsor of an item in your system can remove
> no-longer-needed comments.) So I guess I am thinking of your system as one
> for collaborative online editing rather than just patch review.
I agree that those are all great use cases. Eventually we'll be able
to support these; right now though, I'd like to focus on the more
immediate need (IMO) of patch reviews.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, May 1, 2008 at 2:42 PM, Terry Reedy <tjreedy(a)udel.edu> wrote:
> As I understood this,one needs a diff to comment on.
> I can imagine wanting, or wanting others, to be able to comment on a file
> or lines of files without making a fake diff (of the file versus itself or
> a blank file). Then only one column would be needed.
Yeah, this use case is not well supported. In my experience with the
internal tool at Google, I don't think that anybody has ever requested
that feature, so perhaps in practice it's not so common. I mean, who
wants to review a 5000-line file once it's checked in? :-) The right
point for such a review (certainly this is the case at Google) is when
it goes in.
> I presume the current site is for trial purposes.
Actually I'm hoping to keep it alive forever, just evolving the
functionality based on feedback.
> You obviously don't want
> hundreds of repositories listed.
Repository management is a bit of an open problem. Fortunately, when
you use upload.py, you don't need to have a repository listed --
upload.py will specify the correct base URL, especially for
repositories hosted at Google. (I should probably figure out how to
support SourceForge as well...)
> Are you planning, for instance, to
> suggest that Google project hosting add a Review tab or link to the project
> pages?
They've been following my release with interest...
> And I followed the link to pages about Rietveld ;-)
Thanks. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Folks:
Here's an experiment you can perform. Round up a Python programmer
and ask him the following three questions:
Q1. You type "import foo" and it works. What kind of thing is foo?
Q2. You go to the Python package index and download something named
"bar-1.0.0.tar.gz". What kind of thing is bar?
Q3. What is a "distribution"?
I'm willing to bet that you will get the following answers:
A1. foo is a module.
A2. bar is a package.
A3. A distribution is a version of Linux that comes with a lot of
Free Software.
Unfortunately these answers aren't quite right. A "package" is
actually a directory containing an __init__.py file, and a
distribution is actually what you think of when you say "package" --
a reusable package of Python code that you can, for example, get from
the Python package index.
Educational efforts such as the Python tutorial and the distutils
docs have not succeeded in training Python programmers to understand
the terminology for these things as used by the Python implementors,
so perhaps instead the implementors should start using the
terminology understood by the programmers:
1. A "module" shall henceforth be the name for either a foo.py file
(a single-file module), or a directory with an __init__.py in it (a
directory module).
2. A "package" shall henceforth be the name of the thing that is
currently called a "distribution".
Regards,
Zooko
who doesn't mind stirring up trouble on occasion...