DEV Community

Jevon
Jevon

Posted on • Edited on

Teaching Yourself to Code (II)

Before we begin, let's take a quick review of some of the basics. As we go along, will list a few things for C# as they may or may not relate to Python accordingly. In this way, I hope to build a functional relationship between classes, objects, methods, variables, and other features of the languages.

Now, you may say that this would actually be quite difficult since python and C# are fundamentally different, and I would normally be inclined to agree (showing my inexperience). However, if we first assume that the line, "It is the programmer that makes the [language] seem simple" to be true, then surely there would be at least relatable topics/areas/ideas between the two languages. Thus, by induction, we may extend that idea of relatability to any other two language comparisons. In this case, we will hold the language of Python as constant, and perform comparisons thereof.

That being said, things like variables and variable assignments are much the same across the two languages. This may simply be a product of how I'm progressing through learning this language (SoloLearn is wonderful for quick tutorials), however the differences I began to note started at the commands and assignment operators. Notably, whereas in C#, and a few other languages, making a statement like "x++" is fine, such shorthand is unacceptable in Python; you must make a sentence such as "x+=1" or "x=x+1" even for unit incrementation.
Else, much remains the same. That is to say, even though the commands are clearly different, Console.Writeline("This is a string"); versus print("This is a string"), there are certain similarities. Before I continue, I do want to take a moment to observe Python's lack of semicolon. Yes. As I was saying, the structure of the languages is largely similar. Although there are certain differences.

Examples being, in both languages it is common to see things such as "for" and "while", it would be highly uncommon (and ineffective) to see "do { } while { }" or "foreach" sections in Python; it has no need of them. To implement these, it becomes a matter of "while: ... if: ..." or "for ... in ..." instead. Equivalently considerable, Python doesn't have a default "switch" case comparison. To accomplish this, you might have to employ a dictionary, where we would map each section to their respective functions, or you could define a particular class (or classes) where the specific method gets chosen at runtime. The following examples were initially listed on data-flair.

Using a dictionary:

Using a dictionary

Which, if I request the information to be printed,

using print()

Results in:

print(week())

Then, using classes:

using a class

Which, when printed,

again using print()

Gives us a similar result:

print(s.indirect(i)) and print(s.number_i())

Two things I'd like to make a quick note of here, I use a blank " " to insert a space, purely for output formatting purposes, and these would result in the same if you were to make the function calls from the command line instead.

Additionally, the simple case use of conditions is largely the same; x > 0, y <= a, even the logical operators such as "x==y", "x!=y", "x&&y", "x||y", are relatively interchangeable. However, for Python, many times these logical operations can be written literally as "x and y" or "x or y", although in certain cases, a few remain the same, such as "x==y", "x!=y". As for how to interpret the logical operations, the traditional arguments made of any boolean statements remain. That is to say, observe the following:

"x and y" is True if both x and y are true.
"x or y" is True if either x or y is true.
"x and y" is False if either x or y is false.
"x != y", along with "x == y", when appropriately read as "x not equal to y", "x exactly equal to y" respectively, retain their logical truthfulness as you'd naturally expect.

Similarly, for some constant a, or for some function g; where g can be evaluated to some constant value; any comparative statement made, "x > a", "y < g", follow the expectations of value comparison that you'd expect.

Top comments (0)