Could Python supplant Java?

[James J. Besemer]

Will Newton wrote:

> I would certainly not be opposed to an optional type assertion mechanism, if
> a clear, concise and non-intrusive syntax can be devised.

Agreement!

How about:

    def fn( arg : type ): pass

where the ": type" was optional and indicated the name of the expected class or
type?

Positional and keyword args would similarly:

    def fn( arg1: type1, *pargs :type1, **kargs : type2 ): pass

provided pargs were all of type1 and kargs were all of type2.  (Else they would
have to be checked manually inline with the function.)

For "unions" of types you could push the envelope and say

    def fn( arg: [type1, type2, type3]): pass

or

    def fn( arg: (type1, type2, type3)): pass

Or we could require an auxilliary class for union types (multiple inheritance).

You'd definitely want subclasses to be allowed to be used where supers were
declared (but not the reverse) -- standard oop semantics -- like with exceptions.

> "Almost as good" in terms of actual end result, "possibly better" in terms of
> speed, "definitely longer" in terms of development time.

Agreed.  Python's GC is a principal advantage.

> Old fashioned it may be, at least it can handle basic standard compliant C++.

I've heard people mention this before as it it was a really big deal.  Can you
point me to a reliable reference listing the specific compliance deviations?

> 150k lines of C++ != 150k lines of Python. Take your 150k lines of C++, strip
> out all lines including "delete" and all declarations. Now take out all lines
> of the form:
>
>  a_type a = (a_type)b;
>
> Now take out all curly braces. Now take out all explicit mallocs, etc.
> You're getting close to the equivalent lines of Python.

These lexical changes do not make huge difference in lines of python vs. C++.
Maybe 5-10%.  For actual data I am grepping a "typical" ~ 70K C++ application I
happen to have lying around.

     (a) The Proper Way to use curley braces in C and white space in Python
     calls for "{" to be in the same place Python places ":".   K&R style
     calls for "}" to be on the same line as else.  Thus only single,
     trailing "}" get removed.  On my 70K app, there were only 313 lines of
     lone closing braces.  1/3 of 1%.  If you use an inferior C coding style
     then double or triple accordingly.

     (b) new/delete is 0 or 2 lines per object.  36 lines in my C++ app.
     You don't need new/delete per object, only for objects allocated on the
     heap.

     (c) you do NOT remove all data declarations, global (module global)
     data declarations and initialized const and constant or initialized
     structures all are retained in some form.  Similarly local vars that
     are initialized transliterate 1:1.  Many function type signatures don't
     add or loose lines as it's all included in one line.  The few that are
     multi-line would collapse to a single line.  Array and struct
     declarations each need a corresponding variable initialization of some
     sort.  Structs usually would end up being classes with a few more lines
     than the original structs.

     (d) inline ?: conditionals generally expand to multiple lines of
     Python.

     (e) Similarly inline assignments would have to be unraveled to the
     equivalant python and attendant additional auxilliary variables.

     (f) Switch statements needn't add lines but will require more text for
     each case.  However, instances that use the fall-through semantics
     might turn into a lot of code (in the absence of a goto).

     (g) In my handy big C++ example, there are some casts but usually
     they're of the form

         fn((cast)arg);

     which would not change line count, unlike the example you cite.
     Personally I find excessive use of casts to be an abuse of the language
     and avoid them for the most part.  They are handy in some projects when
     the "other guy" mucked up his declarations or did everything as
     "bytes", "words"  and "dwords" but for my code I'd say casts don't
     materially enter into the equation.

     I was tempted at first to conceed that, say, all the .h files could be
     discounted.  But in looking through my code, I am reminded of many
     cases that carry over to Python.

     (h) In a couple examples, ENTIRE class definitions live in the .h file
     (all inline functions, no global data).

     (i) Other cases, .h files include material constant definitions and
     #includes.

     (j) WE can get rid of #endifs, that's 691 lines.

     (k) The function prototypes in .h files are the approximate logical
     equivalant of a module's
     "__all__ = [ ... ]" directive, provided each __all__ entry is listed on
     a seperate line.  This is a we bit of a stretch but I'll take it.

     (l) that leaves declarations in Classes (which necessarily do not have
     initializers) and local declarations that don't happen to be
     initialized.

     (m) for globals referenced from local functions we need to ADD global
     declarations to ech function where they're used.  This

I have not effective way to measure (l) and (m).  For argument's sake for this
example app (big real-time with some legit. use of single instance globals) I'll
call them a net wash.  Most other instances of growth or shrinkage I'll also
argue wash out.  That leaves 36 explicit malloc/frees, 691 #endifs and 313 curley
braces for a total of 1,140 deleted lines out of around 70K or a around 1.5%.
Challange some of my assumptions above and maybe we're talking 3% or 5%.  But
again, it's not a huge difference.

> A proper build system with GCC should not be different in speed from VC++.

> I also suspect that your C++ was not in a single file either - if Python is
> broken down into smaller files compilation is always per-file and will not
> require recompiles like C++.

Good point.  Sometimes my argument get ahead of me.  ;o/

But from your initial claim that Python is better in this regard I think we're
agreed that (depending on specific environment) they can be about the same.

Incidentally, VC++ can detect and recompile individual functions from within a
module and incrementally relink them into a running application ("break and
continue") without recompiling or relinking the entire module.

> Without trying to sound arrogant, I rarely make such errors. I cannot
> rememeber the last time I made an error like this in writing around 2000
> lines of Python in the last few days.

Well, the experience relayed by one of my developers is that it's not a problem
with our code but rather generally cockpit errors by the customer.  Now most
people on this list I know would simply rail at the customer and tell them to
read the friggin' interface specs more carefully (all is documented) and when
they were truly up to speed and read all the FAQs and saw the world in a truly
Pythonic fashion then the problems would go away.

While for argument's sake I may even be willing to stipulate this is true, I
think I fairly view it as one small way in which the language could be improved.
Customer gets a specific error in the privacy of their own building and our code
looks less buggy.

Plus I believe it's a bigger issue for Python programmers generally than you/they
are willing to admit.

> ...of which you freely admit you have no experience -

with large apps yes, with large python, not yet.  Workin' on it....

> in fact you imply no-one does.

No.  I merely asked for data (and since have been shown some some).

> My Python code tends to be in small files because I can express
> what I want in a small number of lines and don't have endless helper
> functions to cover up the ugly realities of C/C++.

I have nothing against small files or modules.  However, there are two entirely
different architectures.  One is developing individual components for a generic
library only a few of which may be used in any particular appliction.  The other
is developing a large appliction from a large number of small modules, the
contents of virtually all of which are vital to the ap.  My point is that the
former architecture was not as difficult as the latter one.

Thank you for some insightful and thought provoking comments.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20020823/467023c8/attachment.html>