headers
Steven Lott | 1 Jun 2002 04:45
Picon
Favicon
Gravatar

RE: Re: Adding Optik to the standard library

The class isn't really the unit of reuse.  The old
one-class-per-file rules from C++ aren't helpful for good
reusable design.  They are for optimizing compiling and making.

This is great book on large-scale design considerations.  Much
of it is C++ specific, but parts apply to Python.

Large-Scale C++ Software Design, John Lakos Addison-Wesley,
Paperback, Published July 1996, 845 pages, ISBN 0201633620.

The module of related classes is the unit of reuse.  A cluster
of related modules can make sense for a large, complex reusable
component, like an application program.

As a user, anything in a module file that is not class
definition (or the odd occaisional convenience function) is a
show-stopper.  If there is some funny business to implement
submodules, that ends my interest.  Part of the open source
social contract is that if I'm going to use it, I'd better be
able to support it.  Even if you win the lottery and retire to a
fishing boat in the Caribbean. 

The question of <was>Optik</was><is>options</is> having several
reusable elements pushes my envelope.  If it's job is to parse
command line arguments, how many different reusable elements can
their really be?  Perhaps there are several candidate modules
here.  It seems difficult to justify putting them all into a
library.  The problem doesn't seem complex enough to justify a
complex solution.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Ward | 1 Jun 2002 04:57
Favicon

Re: Re: Adding Optik to the standard library

On 31 May 2002, Steven Lott said:
> The question of <was>Optik</was><is>options</is> having several
> reusable elements pushes my envelope.  If it's job is to parse
> command line arguments, how many different reusable elements can
> their really be?  Perhaps there are several candidate modules
> here.  It seems difficult to justify putting them all into a
> library.  The problem doesn't seem complex enough to justify a
> complex solution. 

I think I agree with everything you said.  There are only two important
classes in Optik: OptionParser and Option.  Together with one trivial
support class (OptionValue) and some exception classes, that is the
module -- the unit of reusability, in your terms.

For convenience while developing, I split Optik into three source files
-- optik/option_parser.py, optik/option.py, and optik/errors.py.
There's not that much code; about 1100 lines.  And it's all pretty
tightly related -- the OptionParser class is useless without Option, and
vice-versa.

If you just want to use the code, it doesn't much matter if optik (or
OptionParser) is a package with three sub-modules or a single file.  If
you just want to read the code, it's probably easier to have a single
file.  If you're hacking on it, it's probably easier to split the code
up.  I think Optik is now moving into that long, happy phase where it is
mostly read and rarely hacked on, so I think it's time to merge the
three separate source files into one.  I very much doubt that it's too
complex for this -- I have worked hard to keep it tightly focussed on
doing one thing well.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guido van Rossum | 13 Jun 2002 19:55
Favicon

Re: change to compiler implementations

> I just checked in two sets of changes to distutils.  I refactored in
> the implementation of compile() methods and I added some simple
> dependency tracking.  I've only been able to test the changes on Unix,
> and expect Guido will soon test it with MSVC.  I'd appreciate it if
> people with other affected compilers (Borland, Cygwin, EMX) could test
> it.

Um, I don't use setup.py with MSVC on Windows.  The MSVC project, for
better or for worse, has entries to build all the extensions we need,
and I don't have any 3rd party extensions I'd like to build.

--Guido van Rossum (home page: http://www.python.org/~guido/)
Permalink | Reply | 0 comments |
headers
Thomas Heller | 13 Jun 2002 20:04

Re: [Distutils] change to compiler implementations

From: "Jeremy Hylton" <jeremy <at> zope.com>
> I just checked in two sets of changes to distutils.  I refactored in
> the implementation of compile() methods and I added some simple
> dependency tracking.  I've only been able to test the changes on Unix,
> and expect Guido will soon test it with MSVC.  I'd appreciate it if
> people with other affected compilers (Borland, Cygwin, EMX) could test
> it.
> 
I've tested some of my extensions with MSVC, and it works fine.

Thomas
Permalink | Reply | 0 comments |
headers
Paul F Dubois | 13 Jun 2002 20:59

RE: [Distutils] Re: change to compiler implementations

Numeric is a suitable stress test on Windows that uses a setup.py.

> -----Original Message-----
> From: distutils-sig-admin <at> python.org 
> [mailto:distutils-sig-admin <at> python.org] On Behalf Of Guido van Rossum
> Sent: Thursday, June 13, 2002 10:55 AM
> To: jeremy <at> zope.com
> Cc: python-dev <at> python.org; distutils-sig <at> python.org
> Subject: [Distutils] Re: [Python-Dev] change to compiler 
> implementations
> 
> 
> > I just checked in two sets of changes to distutils.  I 
> refactored in 
> > the implementation of compile() methods and I added some simple 
> > dependency tracking.  I've only been able to test the 
> changes on Unix, 
> > and expect Guido will soon test it with MSVC.  I'd appreciate it if 
> > people with other affected compilers (Borland, Cygwin, EMX) 
> could test 
> > it.
> 
> Um, I don't use setup.py with MSVC on Windows.  The MSVC 
> project, for better or for worse, has entries to build all 
> the extensions we need, and I don't have any 3rd party 
> extensions I'd like to build.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Heller | 14 Jun 2002 22:23

Re: addressing distutils inability to track file dependencies

From: "Skip Montanaro" <skip <at> pobox.com>
> 
>     >> Gcc has had good dependency checking for probably ten years.
> 
>     Guido> How do you invoke this?  Maybe we can use this to our advantage.
> 
> "gcc -M" gives you all dependencies.  "gcc -MM" gives you just the stuff
> included via '#include "file"' and omits the headers included via '#include
> <file>'.  Programmers use <file> and "file" inconsistently enough that it's
> probably better to just use -M and eliminate the files you don't care about
> (or leave them in and have Python rebuild automatically after OS upgrades).
> There are several other variants as well.  Search the GCC man page for "-M".
> 
> It seems to me that distutils' base compiler class could provide a generic
> makedepend-like method which could be overridden in subclasses where
> specific compilers have better builtin schemes for dependency generation.
> 

MSVC could do something similar with the /E or /P flag (preprocess
to standard out or to file). A simple python filter looking for #line
directives could then collect the dependencies.
Isn't -E and -P also available in any unixish compiler?

Thomas
Permalink | Reply | 0 comments |
headers
Guido van Rossum | 19 Jun 2002 17:07
Favicon

Re: Tcl adept wanted for Stackless problem

> My big question is:
> When does Tcl use C stack entries as globals, which
> are passed as function arguments to interpreter calls?

It's a performance hack, just as stackless :-).

Tcl's interpreter data structure has a return value field which can
receive a string of arbitrary length.  In order to make this
efficient, this is initialized with a pointer to a limited-size array
on the stack of the caller; when the return value is longer, a
malloc()'ed buffer is used.  There is a little dance you have to do to
free the malloc()'ed buffer.  The big win is that most calls return
short strings and hence you save a call to malloc() and one to free()
per invocation.  This is used *all over* the Tcl source, so good luck
getting rid of it.

--Guido van Rossum (home page: http://www.python.org/~guido/)
Permalink | Reply | 0 comments |
headers
Christian Tismer | 19 Jun 2002 17:28

Re: Tcl adept wanted for Stackless problem

Guido van Rossum wrote:
>>My big question is:
>>When does Tcl use C stack entries as globals, which
>>are passed as function arguments to interpreter calls?
> 
> 
> It's a performance hack, just as stackless :-).

Where the effect of my hack is slightly bigger.
We can fight that out in Charleroi. :-)

> Tcl's interpreter data structure has a return value field which can
> receive a string of arbitrary length.  In order to make this
> efficient, this is initialized with a pointer to a limited-size array
> on the stack of the caller; when the return value is longer, a
> malloc()'ed buffer is used.  There is a little dance you have to do to
> free the malloc()'ed buffer.  The big win is that most calls return
> short strings and hence you save a call to malloc() and one to free()
> per invocation.  This is used *all over* the Tcl source, so good luck
> getting rid of it.

Thank you! I should better not try this. Instead, I'd like
not to touch it at all.
I have patched tkinter in a way that it does not slice the stack
while some Tcl stuff is running (maybe I didn't catch all).
That should mean that the small stack stings are all alive.
That is, in the context of Tcl, I dispensed with the
"stackless" concept.

The remaining problem is switching of tasklets which contain
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guido van Rossum | 1 Jun 2002 03:21
Favicon

Re: Customization docs

I'll leave the doc questions for Fred (maybe better open a SF bug for
them though).  Then:

> From what I could find in the docs, it's completely non-obvious how the
> following works for immutable objects in containers:
> 
> >>> x = [ 1, 2, 3]
> >>> x[1] += 3
> >>> x
> [1, 5, 3]
> 
> Is the sequence of operations described someplace?

Um, in the code. :-( Using dis(), you'll find that x[1]+=3 executes
the following:

          6 LOAD_FAST                0 (x)
          9 LOAD_CONST               1 (1)
         12 DUP_TOPX                 2
         15 BINARY_SUBSCR       
         16 LOAD_CONST               2 (3)
         19 INPLACE_ADD         
         20 ROT_THREE           
         21 STORE_SUBSCR        

> How does Python decide that sequence elements are immutable?

Huh?  It doesn't.  If they were mutable, had you expected something
else?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Steven Lott | 1 Jun 2002 04:11
Picon
Favicon
Gravatar

Re: deprecating string module?

In python, you don't need overloading, you have a variety of
optional parameter mechanisms.

I think the "member functions" issues from C++ don't apply to
Python becuase C++ is strongly typed, meaning that many similar
functions have to be written with slightly different type
signatures.  The lack of strong typing makes it practical to
write generic operations.

I find that use of free functions defeats good object-oriented
design and leads to functionality being informally bound by a
cluster of free functions that have similar names.  I'm
suspicious of this, finding it tiresome to maintain and debug.

--- "Martin v. Loewis" <martin <at> v.loewis.de> wrote:
> Guido van Rossum <guido <at> python.org> writes:
> 
> > Is this still relevant to Python?  Why are C++ member
> functions
> > difficult to generic programs?  Does the same apply to
> Python methods?
> 
> In a generic algorithm foo, you can write
> 
> def foo1(x):
>   bar(x)
> 
> if you have global functions. With methods, you need to write
> 
> def foo1(x):
(Continue reading)

Permalink | Reply | 5 comments |

Gmane