[Python-Dev] Relative Package Imports

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [MAL]
> > ...
> > Seems that we're a bit too healthy (see MarkH's post) sometimes,
> > i.e. there isn't all that much room for experiments.
> 
> The odds of a change making it into Python radically decreased when 1.0 hit
> the net, and have continued to decline (although slowly) since then.  In
> recent years, Guido appears to me to have gotten ever more reluctant to
> entertain even 100% compatible changes to the internals, if they affect a
> delicate area of the implementation (ceval.c is the most obvious one there).
> 
> But that's "normal & healthy" <wink> too.  Languages & implementations get
> brittle with age, and it's eventually better to start over -- if Guido
> didn't have Python2 plans in mind, he'd be the first language designer ever
> to stop where he started!
> 
> > Just think of cool developments like Chris' stackless python. Experience
> > shows that these kind of things will never make it into the distribution.
> 
> Unfortunately, circumstances piled up and Chris got distracted from that,
> while nobody else made time to push it in his absence.  Large changes have
> gone in, and even more may make it into the Python1 line, but it generally
> takes a large or "strategic" user base, and much persistence.  GregS
> mentioned his massive work on threads (still not all in), and I'll add the
> NumPy extensions (which I wouldn't be surprised to see "mainstreamed"),
> BarryW's string methods, and DavidA's rich comparisons.

Plus the coercion stuff that's still sleeping in one of my project 
subdirs (I'll have to get this done *before* 1.6 hits the shelves).
 
> > Unfortunately, maintaing patches to the dist across releases a real
> > pain and much work, so these ideas will just sit there unused and
> > untested. Much the same happened to gcc ... in the end corporate
> > strength made egcs possible. Perhaps we need such a branch too ?
> 
> Don't tell, but I've always been surprised at how few people have tried to
> release a variant Python!  The Alice version (case-insensitive names, and
> 1/2==0.5) is the only one that comes to mind, and the primary effect that
> had on today's Python is that raw expressions no longer print their value in
> non-interactive mode (before Alice,
> 
>     1 + 2
> 
> on a line by itself caused "3" to get printed even in batch scripts; this
> interfered with the Alice team's favored
> 
>     object.method1().method2().method3()
> 
> coding style, and Guido endured much pain to change "the real" Python to
> avoid a code split at that early stage of Python's life; ultimately futile,
> but then Alice Python didn't catch on anyway).
> 
> So there's very little Python-related history to go on here.  I don't mind
> seeing variants, but have to predict they won't get very far.  Just picture
> what Python 1.6V would look like if its feature set were drawn from a
> consensus among you, me, Christian, Greg Ewing, John Skaller and Tom
> Christiansen <wink>.

Actually, what I was thinking about here was a Python 2.0 branch
starting now rather than in a year or so and thus leaving much
room for experiments etc. The intention was the same as with egcs
and gcc: to fold the enhancements back into the main branch in a few
years.

E.g. if Guido points us in the right direction, we could start
hacking on that piece of revolutionary work now. 

BTW, I'd suggest using C++ with namespaces but without templates as target
language. By the time Python 2.0 will hit the shelves this setup
should have reached the same portability as C has now. Perhaps we
could even use RTTI (run time type information) to implement optional type
safety... ok, just dreaming a little ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   102 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/