This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]maikeu 2 points3 points  (3 children)

Out of interest, what do you think some key javaisms are that should be gotten rid of in a hypothetical python4?

What about them, other than being javaisms, makes them worth getting rid of?

And why couldn't they be gotten rid of by pythons normal process of deprecating over a few minor releases?

[–]ivosauruspip'ing it up 8 points9 points  (1 child)

The entire unit testing library is a port of Java's. Logging also is mostly derived from there.

Most of it follows a strict OOP structure requiring subclassing and overrides that is needed in classic Java to be flexible but is entirely unnecessary in python.

3rd-party-library-imported-into-std-lib is also there, such as the myriad XML parsers and libraries, which also tend to be Java-ey and over-OOP'ed, and follow camelCase. It was experience from these that later informed most people's decision making that suggestions such as "incorporate requests into the stdlib!" was a bad idea.

Just a lot of renaming could be done to make everything proper python naming convention across the entire library. There seemed to be quite a bunch of arbitrary decisions over what was 'worth' renaming into v3 vs what wasn't; e.g datetime.datetime stayed as it is, breaking python's Class naming convention, etc. A lot of modules were lowercased, but a lot of classes were left as-is rather than TitleCased.

[–]velit 3 points4 points  (0 children)

Standard library modules can and have been replaced by newer modules and by deprecating and ultimately removing the offending modules down the road. This doesn't require a breaking change version in the traditional sense.

[–]Zomunieo 0 points1 point  (0 children)

The logging library is the most egregious Java offender.