Mailman 3 May 2008 - Python-Dev

Module properties for C modules
by Christian Heimes 02 May '08

02 May '08

Hello Python Dev! As you all know modules don't support properties. However several places and modules could use properties on module level. For example the sys.py3k_warnings flag could be implemented with a property. Other flags in the sys module could benefit from read only properties, too. How do you like the general idea of properties for builtin modules. That is modules written in C like the sys module. Christian

3 9

Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
by Guido van Rossum 02 May '08

02 May '08

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/)

1 0

Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
by Guido van Rossum 02 May '08

02 May '08

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/)

1 0

shal we redefine "module" and "package"?
by zooko 02 May '08

02 May '08

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

7 7