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?

[Monica Shiralkar]

Tim Holloway wrote: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

I am trying to understand how the identation level increases. Suppose in the method there are several if else block or try catch blocks then each block would start one below the other and for example the code in each block would be 4 tabs on the right. So the width of screen would be width + 4 tabs.

[Jesse Silverman]

Each increased LEVEL of nesting gets indented 4 character positions from the one before it.
As each level of nesting ends, anything following that gets un-indented 4 characters per level.

Normally, we set tabs to 4 spaces for convenience in the editor.

Saying "4 tabs" is a little confusing.  Did you mean 16 spaces total as per PEP 8 and using the convenience of converting tabs to 4 spaces in the editor's settings?

print('Indentation Demo') def indented():    print("Hello from function "indented() by 4 spaces"')    if 2 > 1:        print("At one level of nesting so this source starts 8 characters over")        while True:            print("Two levels of nesting for a total of three, this line's source starts 12 characters in")            print("Which in many editors would be typing three tabs if we set it that way, saving source with 12 ' ' tho.")            if we_got_that:                print("Typing 16 space bars is annoying, so tabs are a popular editor shortcut!")                break

Most prefer that no lines extend past 79 chars whenever possible, and for things like comments and docstrings to stay at 72 chars width or below.

So not sure what you mean by 'width of the lines increasing'.
The levels of indentation reduce what you can say in a line of well-formatted standard Python by 4 characters each out of that 79.

If this starts to leave you with two few characters for your more indented lines, it is possible your code has lots of nesting or overlong identifiers, and could possibly be written differently.

[Monica Shiralkar]

Thanks. Yes, nesting creates increase in Identation.

[Paul Clapham]

Tim Holloway wrote:While I did use punched-cards on the mainframe in school, the worst of it pre-dates me.

Yeah. IDEs, hell no. You'd write your code in forms which were basically a grid with 72 columns and as many rows as would fit on the page. You'd carefully print so what you wrote was readable, because the next step was to hand the forms over to the keypunchers. These were usually middle-aged women in the environment I worked in, but it might have been different elsewhere. They would convert each row that you wrote into the forms into a punched card, pounding the keys on the keypunch machine. Of course they weren't perfect copiers, so you could ask for your job to be verified. This involved a second keypuncher redoing the data entry, only on a different machine which compared what they typed with what the first keypuncher had typed and beeped if there were differences to be fixed. This would improve the accuracy of the keypunching. Naturally that doubled the cost, so you might want to skip the verifying and catch the keypunching errors yourself when compiling (or worse, running) the code. Or if you were a starving student you could do the keypunching yourself.

You could get sequence numbers automatically punched into the last 8 columns of each card, starting at 00000001 and increasing from there. If you didn't do that, and you dropped your deck of punched cards, you had a big problem trying to put the deck back into the correct order. Otherwise there were sorting machines which could accept a deck of punched cards and sort in on the columns of one column. This was a stable sort, so if you needed to sort on more than one column (like the eight columns at the end of your code) you could repeat the sort for each of those columns and the end result would be what you wanted. If you sorted in the right order, that is.

[Jesse Silverman]

I did all my keypunching myself.  All of it was in 1984, I think, when I did one high school and one college course using FORTRAN and PL/I (actually PL/C)...

it was still a lot, and I had the disadvantage of having gotten used to Atari's full-screen editor for BASIC in 1981, 1982, 1983 and when I went home...I'd think about it while typing punch cards.

That did cause me to become a fussy typist, more concerned with error rates than people nowadays, as correcting errors was literally expensive.
I remember the re-type feature where you held down some key to copy the card up to the error was itself error-prone.  Hold it down a fraction of a second too long and you just repro'd the erroneous character as well....

My original point stands.  It is far easier to do these re-factorings with Language-sensitive contextual support.

Even in Vim, with no plugins, it is much easier than it was in the Pre-Cambrian times you were talking about.

[Paul Clapham]

Jesse Silverman wrote:I remember the re-type feature where you held down some key to copy the card up to the error was itself error-prone.  Hold it down a fraction of a second too long and you just repro'd the erroneous character as well....

And when you wanted to insert a character, you held the original card down with your thumb so it wouldn't jump forward, thus allowing you to punch a character in the new card and then carry on duplicating.

My original point stands.  It is far easier to do these re-factorings with Language-sensitive contextual support.

No kidding. I'm amazed that we managed to get anything done in those days.

[Jesse Silverman]

To get back to Monica's original question, let's focus on the fact that Python can be used to write one-liners or useful scripts that fit on half a page or less.

There's no reason to make a script that will be run once or a couple of times into three screens rather than just six lines due to some kind of ideological purity.

Python can also be used to write programs with a few thousand lines.

Python can be and sometimes is used to write things even larger now.  Some people don't like that, or think you need to write in a more modern way that brings static compile-time analysis to bear on its correctness at that point, but it is being done.

Very few people think it is good to have very long methods or functions or many lines in a row just sequentially.
Some of them, like Donald Knuth, are better programmers than most of the people who answer questions here, but that might be okay for them because they are actual geniuses.

Normal, remotely average programmers extremely avoid doing anything but the smallest or throw-away tasks as big globs of sequential lines with no structuring into methods or functions.
This is for reasons of comprehensibility, readability, testing, maintainability, re-use, all the standard ones.

I did have a question of how many people mostly ignore the OOPS aspects of Python and just program procedurally.

One new co-worker has answered "Lots, actually".

That is a slightly different question than Monica originally asked, but had a less obvious answer.