On Sat, Feb 13, 2021 at 10:42 AM Dan Stromberg <drsali...@gmail.com> wrote:
>
>
> On Fri, Feb 12, 2021 at 2:26 PM Chris Angelico <ros...@gmail.com> wrote:
>>
>> On Sat, Feb 13, 2021 at 6:58 AM Dan Stromberg <drsali...@gmail.com> wrote:
>> > I believe Python needs to become more independent of CPython, for Python's 
>> > long term health.
>> >
>>
>> Since 1997, Python has been defined independently of CPython.
>
> Really?  It sounds like I missed something important then.  More 
> specifically, what changed in 1997?

Jython launched. I may have the year wrong, but it was about then, and
that's what Wikipedia says. The significance may have happened +/- a
year of that, I'm not sure, but the point is that that's when effort
started to be made to separate CPython from Python - allowing Jython
to know the language semantics.

>> There
>> are numerous documents that define the language semantics for the
>> benefit of other implementations.
>
> References please?  I'd love to find out this has already been done.

Mostly, the reference documentation. Anything that says how to use
something is also the definition of how to implement it.

>> Multiple implementations have
>> somehow managed to exist without any sort of ISO standard.
>
> Yes, the existence of a small number of other implementations (modulo web 
> implementations) is why I say Python has done pretty well despite the 
> existence of a reference implementation,
>
>> Can you explain what would be improved by having a formalized
>> standard?
>
> It's mostly about avoiding creeping featurism and painting other 
> implementations into corners.  Or - and this is equally important - leaving 
> other implementations in the dust.
>

Other implementations can still be left in the dust even if there's a
standard - just look at various other languages, standards and all,
and the difficulties of using standardized features across compilers.
(I'm not naming names, here, but cross-platform C code is harder than
it needs to be.)

> Consider how far back Jython and IronPython are.  If the "bureaucracy" (I see 
> it as measured progress) of a standard would allow them to catch up, without 
> having to study the CPython source code, the standard will have done its job.
>

Is studying the CPython source code what's keeping them back? Do you
have any evidence to support that?

> In all candor, I do not think that frequent releases with significant new 
> features in each are good for a language. I'll remind you that the complexity 
> of a language varies with the square of its feature count.
>
> There's probably been a rush to add features in the wake of the 2.x-to-3.x 
> transition, but hopefully we won't be continuing at that pace.
>

I, on the other hand, am very happy to have new features in the
language. Each year, Python grows better. If you don't like that,
you're welcome to continue to use Python 3.5 and define that as your
standard; I believe that, for instance, MicroPython has chosen a fixed
standard to aim for.

> And again: a good language has a small core but is extensible, enabling 
> extensive /libraries/.  Python is indeed nicely extensible.
>

Sure, and I've worked with languages that aren't easily extensible.
But there are language features too. Hamstringing the language is not
helping anyone.

>> So far this thread has just been vague ideas that a
>> bureaucratic procedure will somehow help things, without showing a
>> problem.
>
> I've outlined some, but you seem more than ready to dismiss them.

You've shown what MIGHT be a problem, but you haven't actually shown
any real problems.

> The things that got me thinking about this were:
> 1) The caution my comparative languages professor in school delivered about 
> reference implementations and how bad they can be for a language's maturation.
> 2) A comment on python-list about languages without standards not being grown 
> up, that I really couldn't disagree with.
> 3) The common confusion between "Python" and "CPython".  Many people still 
> think they're the same thing.

Please elaborate on the first two. The third one won't change even
with a standard. If reference implementations are bad, why do so many
things - not just languages - have them? There are reference
implementations for crypto algorithms, for example. Do they hurt those
algorithms?

The comment on python-list is, just like your post, lacking in
substantiation. In fact, I would call it nothing but FUD.

> Of course, Java is grown up and it has no formal standard.  But there's 
> always Perl's scary example lurking in the background.  And even Java really 
> doesn't appear to have that many competing implementations.  I'm aware of the 
> IBM JDK, OpenJDK, and gcj.  But for all Java's success, there probably should 
> be (have been) more.
>
> And having a comprehensive test suite can help a lot too - it sounds like 
> we're pretty close there?  ISTR hearing that Pypy was able to reuse much of 
> CPython's test suite.  Having a generic test suite that isn't tied to a 
> specific implementation would be fantastic.  One could argue this is what has 
> given rise to the alternative implementations of Python we have.  Unless you 
> count the ones that run in a web browser - there were at least 32 at my last 
> count, with frequently-superficial compatibility.
>

Yes, CPython's test suite is extensive and extremely useful.

> But we really should encourage more compatible implementations.  That's what 
> I'm trying to get at.  That's probably the main "problem" you seem to want me 
> to highlight, even though I'd rather not be very critical.
>

By "encourage", what do you mean? There are quite a few of them around
already. Are you saying that they're unable to do anything because
Python lacks an ISO standard? Please show how that would change with
one.

Every time there is a specific example of a conflict between CPython
and the reference documentation, it is dealt with (as a bug).  Every
time there's an ambiguity, it is dealt with (often by documenting
things more clearly - eg PEP 558). That's why I'm asking you to show
actual problems, not theoretical ones; actual problems can be solved,
theoretical problems are only really good for FUD.

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YEFHRRXKPKKKJF6WHOOXLQSJ3UQLHQC6/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to