headers
Nick Coghlan | 1 May 2008 01:08
Picon
Gravatar

Re: shal we redefine "module" and "package"?

zooko wrote:
> 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?

foo is a package or a module. Not enough information is provide here to 
say which.

> Q2.  You go to the Python package index and download something named 
> "bar-1.0.0.tar.gz".  What kind of thing is bar?

bar is a package, a module, or a collection of a number of these things. 
Again, not enough information is provided in the question to say which 
is actually the case.

Cheers,
Nick.

P.S. People, including programmers, are often sloppy with terminology. 
This is not a new problem.

--

-- 
Nick Coghlan   |   ncoghlan <at> gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
(Continue reading)

Permalink | Reply | 1 comment |
headers
glyph | 1 May 2008 01:11
Gravatar

Re: shal we redefine "module" and "package"?


On 10:53 pm, steve <at> holdenweb.com wrote:
>zooko wrote:

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

The fact that the Python "package" index is a place where you get 
"distributions" does seem a bit weird to me, but this is not necessarily 
a problem that can be fixed.  Ambiguity is part of human language. 
Perhaps suggest transliterations of these terms for talking about python 
in lojban? :)
>>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).

I have a less disruptive counterproposal.  How about just starting to 
refer to directories (or "folders", or zip entries) with '__init__.py' 
in them as "package modules"?  A package is-a module anyway.
>>2.  A "package" shall henceforth be the name of the thing that is 
>>currently called a "distribution".

I belive a multi-word term here would be similarly more memorable and 
precise.  A "package distribution" would include the more familiar term 
while still being specific, consistent with the old terminology, and 
correct.  Using a qualifying word is probably a good idea in this 
context anyway.  I usually say "debian package", "RPM", "MSI", or
(Continue reading)

Permalink | Reply | 5 comments |
headers
Terry Reedy | 1 May 2008 03:07
Picon
Favicon

Re: shal we redefine "module" and "package"?


"zooko" <zooko <at> zooko.com> wrote in message 
news:50D35C20-ED3D-4A7D-965D-D5BBD76EDDC7 <at> zooko.com...
| Folks:
| 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.

If I go to a market, I may buy an individual food item (an apple, for 
instance), but most foods come in packages.  The items and packages are 
them put in distribution carriers (bags) for transport home, where they are 
unbagged.  A .tgz file is a bag, not a package.  Since I am buying food, 
not bags, I would not want the store called a distribution/bag store. 
Indeed, other types of stores use the same or similar distribution 
carriers, just as .tgz is used for things others than Python modules and 
packages. 

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Ben Finney | 1 May 2008 04:37
Picon

Re: shal we redefine "module" and "package"?

zooko <zooko <at> zooko.com> writes:

> I'm willing to bet that you will get the following answers:
> 
> A1.  foo [from 'import foo'] is a module.
> 
> A2.  bar [of 'bar-1.2.3.tar.gz'] 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.

More accurately, they're right in the context from which the speaker
learned them.

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

Only within Python's terminology. This, of course, conflicts with the
meanings that adhere to those words just about everywhere else on the
user's operating system.

> 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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armin Ronacher | 1 May 2008 10:42
Gravatar

Re: Problems with the new super()

Hi,

Guido van Rossum <guido <at> python.org> writes:

> The staticmethod thing isn't new; that's also the case in 2.x.
staticmethod hasn't changed, method has.  In the past Class.method gave
you a unbound method, now you get a function back as if it was a static
method.

> The super() thing is a case of practicality beats purity. Note that
> you pay a small but measurable cost for the implicit __class__ (it's
> implemented as a "cell variable", the same mechanism used for nested
> scopes) so we wouldn't want to introduce it unless it is used.
I do agree that super() is a lot easier to work with than regular way to
call it.  But the fact that it breaks if i do `_super = super` or that
it's impossible to emulate it from within Python.

Regards,
Armin

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 17 comments |
headers
Guido van Rossum | 1 May 2008 18:41
Favicon

Invitation to try out open source code review tool

Some of you may have seen a video recorded in November 2006 where I
showed off Mondrian, a code review tool that I was developing for
Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped
that I could release Mondrian as open source, but it was not to be:
due to its popularity inside Google, it became more and more tied to
proprietary Google infrastructure like Bigtable, and it remained
limited to Perforce, the commercial revision control system most used
at Google.

What I'm announcing now is the next best thing: an code review tool
for use with Subversion, inspired by Mondrian and (soon to be)
released as open source. Some of the code is even directly derived
from Mondrian. Most of the code is new though, written using Django
and running on Google App Engine.

I'm inviting the Python developer community to try out the tool on the
web for code reviews. I've added a few code reviews already, but I'm
hoping that more developers will upload at least one patch for review
and invite a reviewer to try it out.

To try it out, go here:

    http://codereview.appspot.com

Please use the Help link in the top right to read more on how to use
the app. Please sign in using your Google Account (either a Gmail
address or a non-Gmail address registered with Google) to interact
more with the app (you need to be signed in to create new issues and
to add comments to existing issues).
(Continue reading)

Permalink | Reply | 71 comments |
headers
Georg Brandl | 1 May 2008 19:57
Picon
Gravatar

Re: Module Suggestion: ast

Armin Ronacher schrieb:
> Hi all,
> 
> I would like to propose a new module for the stdlib for Python 2.6
> and higher:  "ast".  The motivation for this module is the pending
> deprecation for compiler.ast which is widely used (debugging,
> template engines, code coverage etc.).  _ast is a very solid module
> and is without a doubt easier to maintain then compiler.ast which
> was written in Python, it's lacking some features such as pretty
> printing the AST or traversing it.

If there are no further objections, I'll add this to PEP 361 so that the
proposal doesn't get lost.

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
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 4 comments |
headers
Georg Brandl | 1 May 2008 20:20
Picon
Gravatar

Re: Problems with the new super()

Armin Ronacher schrieb:

>> The super() thing is a case of practicality beats purity. Note that
>> you pay a small but measurable cost for the implicit __class__ (it's
>> implemented as a "cell variable", the same mechanism used for nested
>> scopes) so we wouldn't want to introduce it unless it is used.
> I do agree that super() is a lot easier to work with than regular way to
> call it.  But the fact that it breaks if i do `_super = super` or that
> it's impossible to emulate it from within Python.

That it isn't emulatable from Python doesn't bother me -- several functions
have that property.

But the other two magical things about super() really bother me too. I
haven't looked at the new super in detail so far (and I don't know how
many others have), and two things are really strikingly unpythonic in
my view:

* super() only works when named "super" [1]. It shouldn't be a function if
   it has that property; no other Python function has that.

* "__class__" is magical in classes. If you define a local called "__class__"
   super won't work anymore in that function.

   Also, you can access "__class__" from any method, without the "self."
   qualifier -- another magical name.

   There may be more implications and surprising behavior surrounding this.

I know that the implementation is a compromise, but I'd rather see a super()
(Continue reading)

Permalink | Reply | 16 comments |
headers
Christian Heimes | 1 May 2008 21:32
Picon

Re: Module properties for C modules

Guido van Rossum schrieb:
> But wouldn't this mean that those properties would no longer be
> available in the module's __dict__?

Correct. Module properties would behave exactly like instance
properties. They don't appear on the instance's __dict__ attribute, too.

By the way I was astonished that the vars() function dones't show
properties but dir() does list them.

>>> class Example(object):
...      <at> property
...     def x(self):
...         return 42
...
>>> example = Example()
>>> example.__dict__
{}
>>> vars(example)
{}
>>> dir(example)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__module__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__', 'x']

Christian
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
(Continue reading)

Permalink | Reply | 5 comments |
headers
Facundo Batista | 1 May 2008 21:38
Picon

Re: Problems with the new super()

2008/5/1, Georg Brandl <g.brandl <at> gmx.net>:

>   There may be more implications and surprising behavior surrounding this.
>
>  I know that the implementation is a compromise, but I'd rather see a
> super()
>  whose full semantics can be explained to programmers without using to
>  "cell variable", "f_localsplus" and "symtable".

In consideration of what's been said about super() in the past, and
what is handled here regarding its Py3 implementation, I want to make
a step  back, and ask:

Has super() proved more useful than harmful? Which is the value for
Py3 to keep it?

Regards,

--

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 6 comments |

Gmane