[META-SIG] Re: Python a new opportunity.

Thu, 17 Jul 97 00:04:22 -0600

     Hi Sam, 

     Thanks for taking the time to respond.  

     I would be interested in your analysis of the opportunity and my 
     opinion of it's potential benefit to the Python / Freeware community.  

     If such a project is pursued what is your opinion about how to 
     maximise it's visibility to the new group of candidate programmers?  I 
     don't believe these people would normally access Python.com and time 
     would be of a essence so a body of Python projects could be created 
     prior to another solution arriving on the seen and confusing the 
     issue.

             Thanks,
                Joe E.

     *** My Response ***

     This represents a short term opportunity for Python which must be 
     brought to fruition soon if it is to actually deliver a new body of 
     engineers to the Python community before another alternative grabs the 
     mind share.  Currently this appears to be virgin territory but a 
     commercial venture of some sort is bound to recognise the gap and move 
     to fill it soon.

     I think other vendors will require a bit of time to exit their 
     "Windows/NT" unlimited Disk and RAM mentality and switch back to 
     designs that will approximate what Python does so well now.  A lot of 
     vendors will not even try and will take the approach that these 
     systems will scale up so quickly that in a year or so they will be 
     able to deploy their Win/95 applications in the same form factor.  I 
     cringe at this type of approach and hope Python can step in and 
     provide a workable solution quickly which will encourage a move to 
     maximising the effective use of the resources we have.

     If we have to wait until I have bandwidth to work on such a project it 
     may be the year 2000 and Microsoft will have recognised the gap and 
     deployed a different solution.  

     Your point about the functionality that can be packed in to Python 
     byte code is one of the primary reasons I was thinking Python would 
     make a great solution in this space.  I am predominately a vertical 
     application developer so I am thrilled by the idea of an environment 
     that would let me squeeze full size application logic into a congested 
     Memory space. This would allow me to pursue developing a class of 
     applications that I would currently consider out of scale for such a 
     device.  It is unfortunate that we can't get Python added to the 
     device's ROM so there would be no space overhead from the interpreter. 

     From the limited Python I have written I get the impression that 
     Python byte code "per logical feature point" seems to be smaller than 
     equivalent Java byte code but I am not sure why this occurs.  

     I am not an expert in this area but from what I have read so far it 
     appears that a sub set of MFC is actually embedded in the machines ROM 
     and they appear to be working some other magic to minimise the size of 
     programs generated using a custom version of MFC and a custom 
     compiler.  An associate of mine thinks that you must include a 
     reference to this special library in order to access the device's 
     special features such as the Object Store, TAPI interface and custom 
     GUI widgets but I have not validated this.

                Good luck,
                        Joe Ellsworth.

     P.S.
     My primary motivation is to see a language I think warrants a chance 
     at wider exposure take advantage of a momentary laps of the industry 
     giants gain a larger mind share.  Python's wider spread adoption could 
     encourage  industry giants to improve the quality of their product 
     offering to match. At the current time Python for all it's strength 
     does not seem to hold sufficient mind share to be used as such a lever 
     and it is playing in such a congested market segment that it will have 
     a difficult time growing to realise it's full potential.

______________________________ Reply Separator _________________________________
Subject: Re: Python a new opportunity.
Author:  Non-HP-rushing (rushing@nightmare.com) at HP-ColSprings,shargw5
Date:    7/15/97 10:32 PM

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "je" == JOE ELLSWORTH <JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com> writes:

    je>      I believe Python and a TK look alike could fill this 
    je> niche better than currently available development tools and 
    je> would benefit from doing so by attracting a new group of
    je> previously inaccessible pragmatic application developers.  Of 
    je> course marketing the availability of the tool would be as
    je> important as making it available in the first place.  Some non 
    je> trivial applications using the tool would also help.

    je>      The core MFC libraries are available for CE and as such a 
    je> porting effort should not be terribly difficult except for
    je> memory foot print and access to a few proprietary features of 
    je> the new device.

I don't know about MFC on the CE platform, but elsewhere MFC is nearly 
a megabyte.  [imagine what you could do with a megabyte of python byte 
code!]

    je>      Features Needed to compete in this space: Compatibility 
    je> with Windows CE.

    je>         A base memory foot print less than 500K, ideally less 
    je> than 300K.  multiple copies of interpreter should be able to 
    je> share base memory.

One thing you might want to explore is the fledgling 'class library' 
that's included with the 'calldll' module: Although it's very 
incomplete (I don't get to work on it much), it suffices for building 
windows applications.  It uses calldll to speak directly to the 
windows API: (i.e., it calls functions in user32.dll, gdi32.dll, 
kernel32.dll, etc...) Even with the message loop written entirely in 
Python, the performance is good: I've written applications that do 
scrolled scaled graphics...  Most of this is in about, hmmm... 50-60k 
of pyc files.

I think a Tk-like library (in other words, a well-designed, 
object-oriented library where widgets can be composed) could be built 
on this.  In fact, that was my goal when I started working on it.

[see http://www.nightmare.com/software.html for a description of the
 calldll]

- -Sam

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM8xOpGys8OGgJmJxAQHi7QQApRXBuBabCb74h5yMFCmvCcNVTuX6E8TV 
2usRLwsOSH19X3ONKjfNMhK69n/kQ1DnlrHTTFTHQleZICx11+pBgyS6hl+34DI7 
XKzU+zelMcE4ySQB+1q93oJzvAAHwbSu6FzXkqPYAIXEjV6NzQztqcg8na9zDxN1 
tnIPBqSoSf0=
=IXVm
-----END PGP SIGNATURE-----

_______________
META-SIG  - SIG on Python.Org SIGs and Mailing Lists

send messages to: meta-sig@python.org
administrivia to: meta-sig-request@python.org
_______________