colpage.py

[Mekire]

Yes, I have had to use some systems libraries like that in an OS course as well. God was it awful. There is zero reason to try to emulate that in python (and often no good reason to do it in C either).

[Skaperen]

Implicitly.  No one ever explicitly returns None for __init__ or indeed many functions at all.  I would say only explicitly return None on a function where that has meaning.  If your function changes a mutable it was passed or simply is setting attributes on a class it is customary to leave it off.  Functions with no explicit return statement will return None regardless.

This goes for almost every return in the code you posted, but as stated specifically jumps out for the init.

i do remember the thought i had when coding that.  i wanted it to be short and knew that geometry() returned None so it could put the call on the return statement.  but i have changed to not depend on that.  i did do an explicit return None in the __init__ method per post #8.  is there a reason you believe in that suggests or mandates that an implicit None is better, as in just return?

[Mekire]

i did do an explicit return None in the __init__ method per post #8.  is there a reason you believe in that suggests or mandates that an implicit None is better, as in just return?

Not as in just return. As in nothing. Function end. Any function without a return statement returns None.

The reasoning is simply that no one explicitly writes returns for __init__ or functions that simply alter mutables. That is all I can offer you. Yes, generally explicit is better than implicit. This is not one of those cases.

The only thing stated about return None in pep8 is that if you have another non-None return in the same function the return None should be explicit. I would argue that even this is rare however. Usually you should raise an exception in cases like this rather than returning None for the exceptional case.

[Skaperen]

from the reference documentation (emphasis mine):

Because __new__() and __init__() work together in constructing objects (__new__() to create it, and __init__() to customize it), no [u]non-None[/u] value may be returned by __init__(); doing so will cause a TypeError to be raised at runtime.

it does not say, one way or the other, whether an explicit None or implicit None is the way to code this.  indeed, a quick look at several classes i did not code show a predominance of implicit returns by having no return coded at all.  it has been my general practice (with some exceptions) to code explicitly in the various languages i code in.

---

ok, so you are saying that no one codes a return statement on __init__(). what if complicated logic can be coded simpler by having a return in nested conditionals?

[Mekire]

ok, so you are saying that no one codes a return statement on __init__(). what if complicated logic can be coded simpler by having a return in nested conditionals?

If your class __init__ has the need for nested loops such that you need to break out of multiple levels, I would say there is probably something deeper wrong.  Also if I had something that complex that needed to be done in __init__, like in your code, it would be relegated to its own function called from __init__.

In principle I don't have a problem with a mid function return to get out of nested loops (None or otherwise) but in practice there are often better ways.  As usual it comes down to what is most readable, and what is considered "most readable" is driven by convention.

[Skaperen]

ok, so you are saying "no one does foo" -> "you should not do foo, either" == "so that everyone understands" (that which foo might have been part of).  where foo can be an explicit return with an explicit value which is the same as an implicit value or an implicit return.  so we trust everyone who is reading to understand every implicit nature or at least this one?

[volcano63]

From object.__init__ documentation

Because __new__() and __init__() work together in constructing objects (__new__() to create it, and __init__() to customize it), no non-None value may be returned by __init__(); doing so will cause a TypeError to be raised at runtime.

[Mekire]

From object.__init__ documentation

Because __new__() and __init__() work together in constructing objects (__new__() to create it, and __init__() to customize it), no non-None value may be returned by __init__(); doing so will cause a TypeError to be raised at runtime.

Yes, that has been established.  This discussion was as to whether or not you should explicitly include return None or even return in said function.  And of course, as established by convention (whether it be in pep8 or not) you should not.

[volcano63]

Yes, that has been established.  This discussion was as to whether or not you should explicitly include return None or even return in said function.  And of course, as established by convention (whether it be in pep8 or not) you should not.

I think that OP is not convinced. The problem is with the interpretation of explicit - I think it's pretty obvious that explicit is better than implicit only when explicit is useful or not misleading.

Useless return with method call is out of place. But I feel it's like talking to a .

[Skaperen]

Yes, I have had to use some systems libraries like that in an OS course as well.  God was it awful.  There is zero reason to try to emulate that in python (and often no good reason to do it in C either).

thinking about why they merged get and set functions, i guess it was memory.  memory scalability was a big issue back in those days.  the smaller the executable was, the less of other issues came up.  today, memory is cheap, and architecture are being built for lots of it.  when the get/set issue no longer has to worry about memory and programmers don't scale at all, then separate get and set makes sense.  so people like me need to think about their choices more to be sure we are working with today's need.

i still think explicit coding is better.  but i'll keep thinking about it.