In Python is it right way to create separate functions for each functionality like in OO languages ?

[Monica Shiralkar]

I have been programming in Java since many years. In current project , I have been working on a Python code too. I went through few python learning resources online (including the Python wiki on the CodeRanch forum) and implemented the code. Now, the code is working fine.The way of coding I knew has been to take out every small functionality into separate methods and no lengthy methods.In python there is procedural code too which is line by line. In case of Python script to be called from outside , is it the right way of programming to have a main function, take command line args and break all functionality into small functions ?
Thanks.

[Campbell Ritchie]

Isn't it correct to break up code into small units in any language?

[Monica Shiralkar]

Campbell Ritchie wrote:Isn't it correct to break up code into small units in any language?

Yes. But the question arised in my mind that this way I am not doing anything procedural (and python is procedural as well as object oriented language ). Just trying to understand the significance of Python being procedural language and whether that would bring any difference in way of coding in python

[Tim Holloway]

Campbell Ritchie wrote:Isn't it correct to break up code into small units in any language?

Well, it wasn't common in the older languages, but that's in large part because there weren't very good tools or conventions for doing so back then.

Python is my most common pick for quick-and-dirty programming these days. Often, yes, a script will start out as straight-line code. But as the complexity of the program increases, I start carving out functions.

Two reasons for this:

1. A really large block of code is hard to think of in terms of its abstract functionality. So it makes sense to reduce the thought from 27 lines of code to a call to "prepare_for_nuclear_destruct()".

2. As the loops and conditions multiply, the indentation levels increase. I don't care how wide my monitor screen is, there are limits to what I'll tolerate. So I can reduce the overall indentation requirements by converting inner logic to function calls. This becomes even more important when I have to print stuff out and mark it up to make sense of it all. Paper is no wider now than it ever was. In fact, who uses 17-inch wide (mainframe) continuous forms anymore?

[Monica Shiralkar]

Thanks. I hadn't thought the 2nd reason.

As the script goes longer, I think it should be good to make it cleaner by moving some of these functions to a helper class and calling from the main script.

Tim Holloway wrote:
Well, it wasn't common in the older languages, but that's in large part because there weren't very good tools or conventions for doing so back then.

What does earlier tools/conventions not being there mean for this ?

[Jesse Silverman]

Coming from a long-term C background, and having used C++, a slight variation on the question which I'd still like to know is:

"Does most of the Python world often write purely procedural code, with just functions?"

I think it is terrible in almost any language to have very long pieces of code not factored into functions/procedures at least, despite the fact that Don Knuth does it and he is 100 times smarter than me (maybe if you are 100 times as smart as me it is okay because you can actually handle that).

On the other hand, altho I am still a relative beginner in Python it seems that I am seeing more stuff done like in C or how C++ allows, but NOT Java and C#, which is to say things are left function-based and no obsession with "everything is a class or a method except for some lambdas" that you .

Secondly, I see in the beginner-facing stuff I have been looking at a whole lot of use of dictionaries for things I would naturally always be making a class with class methods for.  They then just have functions operating on the dictionary instead of class methods acting on an object.

This is either because they want to show non-trivial programs before they get to classes, or simply because many Pythonistas are just not obsessed with classes and methods to the same degree C# and Java people are forced to be.

[Jesse Silverman]

Tim Holloway wrote:
Well, it wasn't common in the older languages, but that's in large part because there weren't very good tools or conventions for doing so back then.

What does earlier tools/conventions not being there mean for this ?

He might have missed this -- his answer to me just meant that now everyone has IDE's with auto-refactoring functionality built in, where you can right-click and break a block of code out into a function or method, and that in the old days (almost) nobody did, so if you wanted to it was a lot of work compared to now.

[Tim Holloway]

No, actually, I'm referring to the fact that to have even basic subroutines you had to load multiple decks of cards into the hopper and provide linkage information. Along with one-off job control language to manage the flow. The closest thing to a managed application build system on an IBM mainframe was only available for OS maintenance and it really only aped a general-purpose build rather than actually supporting one.

The Unix make utility was the first general build systems I ever heard of and even today there's really no standard for organizing and building C projects the way that tools like Maven and Gradle can.

[Jesse Silverman]

Like, wow, man!  That's a whole generation back past where I was except on my first college courses during high school.  I did start on the Mainframe (commercially, and in my first University classes) but we were all on 3270 terminals (with lowercase even!) by the time we came along and built a generally cmake-like build system in ReXX...eventually that became the main source management and build system and the code got pushed on the "port machine" to 15 or 20 other platforms, hitting every corner case of portability in C along the way...

Yeah, it was even harder before that, but sitting in an IDE that "knows" C, C++, Python, Java etc. and right-clicking "Refactor into a function" is still oodles easier than creating one yourself in an editor that had no idea what C or FORTRAN was, then deciding if the function was static or linkable and then editing the build files appropriately.  I remember arguing over whether to make particular functions static or not, because on our set-up, you could only set a breakpoint at linkable names, so to break at a static function you had to generate the assembly listing and do hex math.  And here we are in Python....

[Tim Holloway]

While I did use punched-cards on the mainframe in school, the worst of it pre-dates me. Still, I saw enough history to make me glad and I still remember the days of non-intelligent debugger/editors. Refactoring was something you did by brute force.

Here's a fun fact: IBM 3270 terminal keyboards actually transmitted originally in lower-case, but displayed in upper-case. They used a 6-bit BCDIC code. The brains of the system were in a separate shared control box.

Somewhere around 1980, the control electronics got swapped out for microprocessors (Zilog Z-80) and the color, display geometry and character set support all improved. Terminals weren't the only thing that got MPU support. The original control unit for the popular IBM 1403 line printer was based on the IBM 1401 computer, and it, too eventually got booted in favor of an MPU. Which was probably smarter than the 1401 anyway.

Nowadays, if you want a 3270, you install an app under Linux and connect via tcp/ip.

[Jesse Silverman]

This is getting really off-topic except to highlight how dang easy modern re-factoring is, but since the tree says "JavaRanch-->Java Forums-->Jython/Python" despite the URL saying "coderanch.com" this trivia is relevant.

When I first tried Java as a long-term C, FORTRAN, Assembly, Pascal and PL/I programmer, my initial thoughts were "What a piece of crap?  Someone thought this was production???"
Part of it was so many people writing and publishing things that really didn't understand how to use Java properly yet, but not all of it.

One of the most important IBM products for MS-DOS and OS/2 (the OS/2 versions were better) were the 3270 and 5250 emulators.  They took them very, very seriously and they were extremely well-written and bug free - they really cared about them.

I forget which year it was, but before I took Java seriously they "re-wrote" them in Java.
The initial ones were total crap, and as they were still supporting the classic (C++?? I can't believe I never looked back then, but they were classical .exe C or C++ I guess)...everyone or almost everyone ignored the Java versions for the classic.

But at a max a couple of years after they came out, nobody was using anything but the Java versions of those emulators.
Were the newer versions of Java that much better, or did they just have more debugging and re-factoring and attention and better knowledge of Java?

I never found out, but that was the moment I realized I'd need to take Java more seriously, it wasn't the piece of crap that the first 100 Java programs I'd run (many were applets, probably written by novices) had convinced me it was...

Java could be used to implement performant, production applications that had existed for years in C/C++, and hardcore users could prefer the Java implementations.

I still ignored Java more than I paid attention to it for years, it was always there but an afterthought, with the important stuff in C/C++...but I started worrying about ignoring it more than I had.

JDBC surpassing ODBC as the preferred way to connect to classical production databases might have been the next sign to me that Java indeed was "taking over", and the fact that "Everyone learned Java in school", first as a first language and then for more as their main/only one.

That seems to be getting surpassed by Python by a good bit, first language for so many, main language for a very good number of people, and even a good number of programmers.

So that brings us full circle back to Python and its ease of casual re-factoring.  I still see good old-fashioned C in almost every source-code reference in tutorials that do deeper dives under the covers, and the official Python tutorial is mostly filled with references to C and Pascal as previous languages they expected people to know before coming to Python...but those dang 3270 emulators were the first moment I realized I needed to take Java more seriously....

Are many people really still using Jython?  It seemed to really have fallen by the wayside and not really made it to Python 3.x intact.  I wonder if this forum would be called Jython/Python if it were freshly named today?