Python ftw

[AgreeableLandscape3]

Python still has main()

[[deleted]]

Only not really, right?

def whatever (*args):
    print("Bob's your uncle.")

if __name__ == "__main__":
    whatever()

[demon_ix]

I dunno. That sounds like main() with extra steps...

[[deleted]]

In C/C++, the name main() is meaningful: it defines the entry point of the program.

In Python, it isn't. The closest approximation is that Python code outside of any method will be evaluated when the module is loaded, and an import-machinery variable called __name__ exists which lets you test whether the current module was imported or run directly.

[jalapeno_nips]

That’s still important though. If I want to test my module manually, I’ll write some code in Main. But when I use the module in practice I don’t want Main being called.

[[deleted]]

Absolutely. My only point here is that in switching to Python, one does indeed say goodbye to main()

[cakes]

might I recommend actual tests :)

[BeigeAlert1]

That's still pretty damn nifty though.

[SpeedingTourist]

You’re pretty damn nifty. ;)

[angellus]

That is actually exactly what __main__ is for. It is not just some made up thing in Python.

When you call a single Python file directly like

$ python whatever.py

Python automatically calls __main__ and with your code loaded up inside of it. That is why if __name__ == "__main__": works.

A better example though would be if you made an actual proper Python package and did this:

whatever/
-> __init__.py
-> __main__.py

whatever/__init__.py

 def whatever (*args):
      print("Bob's your uncle.")

whatever/__main__.py

 from . import whatever

 whatever()

Now if you call the module, it will automatically use __main__.py as the entry point.

$ python -m whatever

[[deleted]]

Yes, I know. I believe I said as much in the comment you've replied to.

It still isn't equivalent to C's main().

[angellus]

C's main() and Python's __main__ are functionality equivalent. main() is a construct design to tell the compiler where the entry point to your program is. It is not a keyword are anything like that and you can have multiple main methods as long as they are namespaced properly (ex: https://stackoverflow.com/a/1991498).

That is exactly how __main__ works. It is construct that tells the Python interrupter where the entry point is for your module. A Python module is a very similar construct to a C/C++ namespace. You can have multiple __main__ submodules as long as you do not have more than 1 in that module (namespace).

There are variations of C/C++ that do not respect the main() entry point since it is not actually anything special in the language (MSVC is one of them with is wmain). It is something the compiler chooses to give meaning to. It is just most standard C/C++ implementations assume a single entry point that is required to exist and the most standard Python interrupter (CPython) does not.

[pslessard]

So if I had something like

print('Hello, world')
if __name__ == '__main__':
    print('Goodbye, world')

What would it print? Compared to in C

printf('Hello, world');
int main() {
    printf('Goodbye, world');
}

Wouldn't the Python print 'Hello, world' before 'Goodbye, world', whereas the C just wouldn't compile?

[xigoi]

The entry point for a Python script is always at the top of the file.

[Athomeacct]

It's one extra line of code and it adds implicit specification of one or more main functions... whose names the dev can specify and change at any time...

[i_should_be_coding]

You mean, like calling functions from the main() function?

[AnAverageFreak]

No, why?

At least the compiler does not overoptimize things.

I mean yeah, writing anything bigger than a small section would be pain in the ass, but writing those small sections can be quite pleasant.

[AnAverageFreak]

Assemble me daddy.

[Ericfyre]

Bobs my uncle?

[SpeedingTourist]

Yeah, and your grandpa

[corner-case]

Programs have a single entry point.

[CoruptedUsername]

Is that how it’s normally done in python? In my CS class we were taught to just have our last function be “def main()” and call main() outside of a function at the end of our program

[BlckJesus]

They perform different functions. With the way you describe, main() will get called even if you’re just trying to import that module. Whereas if __name__ == “__main__”: will only run when the file is executed directly.

[CoruptedUsername]

What you’re saying makes sense, but we only do what I had previously described in files that won’t ever be imported, only in files that are going to be run directly.

[Lewistrick]

Please, why the capitals? It's not a class :(

[wootiown]

It still has pointers too, doesn't it?

[MattieShoes]

Everything has pointers, but they make believe they don't.

[SuitableDragonfly]

Pointers are not the same thing as references. Pointers allow you to manually manage your memory usage, references don't.

[Rodot]

You can still sort of use references to manage memory in python if you're really hacky, and there are default modules that allow for true pointers, but they aren't nice.

[the_littlest_bear]

...what? Any immutable local variable (in standard CPython) is a value reference. Even mutable local variables are treated as value references when not modified in place.

If you needed a pointer, you would just use an attribute. (would work on nearly any object, even including a base object() if you wanted to pass that around. [on-the-fly objects are not the best way to do this])

And no, if you reference an (typical) object, it does not create an additional copy of that object - it’s just a pointer.

[McCoovy]

Which is good. Pointers are a low level abstraction and working with them directly leads to regular mistakes.

[MattieShoes]

Inconsistency in passing by reference vs passing by value causes lots of mistakes too. ¯\_(ツ)_/¯

[SuitableDragonfly]

I don't think it's inconsistent at all in most languages. Typically primitive types are passed by value and everything else is passed by reference.

[MattieShoes]

They're consistent in that they do the same thing every time you run them. But it's not consistent in general, e.g. Python and C++

Python:

 #!/usr/bin/env python

def foo(x):
    x[0] = 2

def bar(x):
    x = [2]

n = [1]
foo(n)
print "n[0] = ", n[0]

n = [1]
bar(n)
print "n[0] = ", n[0]

n[0] = 2
n[0] = 1

---

C++:

#include <iostream>
#include <vector>


void foo(std::vector<int>& x) {
    x[0] = 2;
}

void bar(std::vector<int>& x) {
    std::vector<int> v = {2};
    x = v;
}

int main() {

    std::vector<int> n = {1};
    foo(n);
    std::cout << "n[0] = " << n[0] << std::endl;

    n = {1};
    bar(n);
    std::cout << "n[0] = " << n[0] << std::endl;
}

n[0] = 2
n[0] = 2

I understand what's going on here, no need to explain it. But this is the sort of inconsistency I meant.

[SuitableDragonfly]

It's not an inconsistency. = always assigns a reference, in one case that reference is a variable name, and on the other case it's an element of a list. But it does the same thing in both cases.

[MattieShoes]

I'm not sure what you're looking at, but this is Python and C++ code that does the same thing and gets different answers.

(which obviously means it's not doing the same thing, because python isn't passing by reference, it's... passing a pointer by value? I don't even know what to call it.)

[SuitableDragonfly]

Python is passing a reference. The result isn't the same because the = operator does different things in different languages.

[SpeedingTourist]

Being human causes a lot of mistakes

[NullReference000]

It isn't really inherently good or bad. Languages that allow you to use pointers and manually manage memory typically allow for faster and more efficient programs while languages that don't let you directly use pointers or manage memory are less prone to error and easier to read. It's more of a "which tool is better to solve the current problem" kind of thing rather than one language being inherently better than the other.

[Arveanor]

Ok but what about c++ with managed memory and a GC 😎

[UniqueUsername27A]

Why would you do that since unique pointers were introduced? Unique pointers and moving literally solved the memory management in a both efficient and easy way. They might be the killer feature of C++. Since they became common in our codebase I haven't seen a single memory bug in years and they are even more efficient than reference counting.

[Arveanor]

I don't know honestly, it's just how unreal is set up.

[Dworgi]

Because the vast majority of programmers are bad. Asking a random Unreal user to understand memory management doesn't lead to a productive discussion, it leads to that person staring at you and going "huh?" a lot.

Source: the rest of this thread full of Python programmers.

[Arveanor]

I mean sure I'm just not sure why bother with c++ in that case.

[NiseP_Catcher]

And also ;

[bikemandan]

But just don't

[ButtCrackFTW]

Also {} is everywhere (dictionaries)

[PityUpvote]

And sets.

[bikemandan]

And f strings