Earlier quoted context omitted.
"Private" fields and methods should use one underscore. Two underscores are for name mangling issues and __method__ is for "magic" methods.
I'd say that private methods are double underscored, and protected methods are single underscored, since the goal of the __ is to prevent child classes from being able to use the parent implementation via self.__meth.
A bite of Python
151–160 of 168 posts
Re: A bite of Python
#152Earlier quoted context omitted.
And the TL;DNR being: developers can't be expected to do a good job. Some of them in fact will do a terrible job. This can be said for every industry involving people.
Which is why any sane industry has lots of safety involved. We don't just shrug every time someone gets electrocuted to death and say "they forgot part c page 4 of the operations manual which indicates that the off switch doesn't work on tuesdays".
Re: A bite of Python
#153The behavior of 'assert' is not an anomaly. It comes from 'design by contract.' Assert is primarily meant to be documentation of constraints in code and secondarily a way of catching errors during development. "Contract conditions should never be violated during execution of a bug-free program. Contracts are therefore typically only checked in debug mode during software development. Later at release, the contract che…
That is certainly one approach, and the article agrees. > The root cause of this weakness is that the assert mechanism is designed purely for testing purposes, as is done in C++. However, C and C++ are perhaps unique in how much undefined behavior is possible and in how simple it is to create. Inserting into a vector while iterating through it, for instance. Or an uninitialized pointer. That's why many C++ experts be…
Re: A bite of Python
#154Earlier quoted context omitted.
almost everything is a method Not "almost". Just "everything is a method", in terms of function calls. Even user-defined standalone functions. Consider: def my_func(arg): return arg + 5 The following are equivalent, and show how things work: my_func(3) and my_func.__call__(3) and types.FunctionType.__call__(my_func, 3)
I'm not certain, but I think the C API can avoid that. I've learned to say "almost" because every time I say Python can't X, someone shows me it can.
Re: A bite of Python
#155One Python gotcha that has bitten people in my company a lot: fun_call('string1', 'string2' 'string3') That is, missing commas and subsequent string concatenations can lead to nasty errors. I wish Python didn't nick this from C and would have just enforced the use of + to concat over-length strings, if they need to be split to multiple lines.
They considered dropping that for Python 3. I forget the reason why they changed their minds, but there's probably a PEP about it. You may find that their discussion will change your mind as well.
Nothing mind-changing in here. Translations seem to take the biggest hit, but it's largely a matter of company conventions if this is a problem. IMO the grounds of rejection weren't discussed very thoroughly.
Re: A bite of Python
#156Earlier quoted context omitted.
They considered dropping that for Python 3. I forget the reason why they changed their minds, but there's probably a PEP about it. You may find that their discussion will change your mind as well.
https://www.python.org/dev/peps/pep-3126/ Nothing mind-changing in here. Translations seem to take the biggest hit, but it's largely a matter of company conventions if this is a problem. IMO the grounds of rejection weren't discussed very thoroughly.
I could imagine the new f-string interpolation might have some nice synergy.
Re: A bite of Python
#157I would never accuse Python of "language clarity and friendliness". Far from it. For someone who came up through C, Java, Perl, and Ruby, but who's wrangled with Python, Javascript, Go, and even Haskell in recent years, I still find Python mysterious, self-contradictory, and filled with implicit rules and assumptions that are entirely un-intuitive to me far more than other languages. And yet, people seem to like it.…
I find that with Python that's almost always caused by not quite understanding the underlying rules. Once understood, they're very consistent. For example: does Python pass function arguments by value or by reference? Neither! It passes them by object reference - not by variable reference like C/C++. Check out: >>> def foo(a): ... a = 2 ... >>> value = 1 >>> value 1 >>> foo(value) >>> value 1 and: >>> def mutate(dct)…
dicts are mutable, so, it doesn't create a new object to make an assignment
numbers are immutable, so, it does.
Re: A bite of Python
#158Earlier quoted context omitted.
But Python is OO from the bottom up. Unlike Java, everything in Python is an object. Perhaps your experience with objects in other languages has given you a different mental model for what an object is. I find Python objects to be more straightforward than in other languages, especially because classes are objects, too.
If it really is OO, then the global `len()` function and like explicitly declaring "self" in method declarations makes it _feel_ bolted on (to me). Why is `len()` special? I immediately question what other basic operations aren't methods, but global functions. And as for method declaration, if you aren't satisfied with implicit self, I much prefer Go's choice of having you declare the self reference for methods befor…
so is str and other shortcuts
Re: A bite of Python
#159"Reusable integers" is a real fail - it violates the principle of least surprise and introduces a nasty inconsistency - all integers should logically be (refer to) the same integer object, not just the first 100. Assert is a statement, not an expression, so do not use it as an expression. One should never compare floats. This is taught in any freshman CS course. The limitation is due to the standard encoding of float…
> "Reusable integers" is a real fail - it violates the principle of least surprise and introduces a nasty inconsistency - all integers should logically be (refer to) the same integer object, not just the first 100. I find the concept of special-casing ints to behave that way to be surprising and inconsistent. If ints act that way, shouldn't strings? And if they (very much unexpectedly) did, why not every other type?…
`str' can be interned in some situations, though the rules vary across implementations and versions. Most of these things just boil down to unintuitive caching optimizations. Like you mention, it's pretty rare to check the object identity for integers or strings, but if you are doing so, you probably want the real answer.
Aside Python's small integers, True, False, and None, Java has these rules for boxing in the specification [1]:
> If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.
> Ideally, boxing a primitive value would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rule above is a pragmatic compromise, requiring that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, the rule disallows any assumptions about the identity of the boxed values on the programmer's part
[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#...
Re: A bite of Python
#160I would never accuse Python of "language clarity and friendliness". Far from it. For someone who came up through C, Java, Perl, and Ruby, but who's wrangled with Python, Javascript, Go, and even Haskell in recent years, I still find Python mysterious, self-contradictory, and filled with implicit rules and assumptions that are entirely un-intuitive to me far more than other languages. And yet, people seem to like it.…
In my experience and implied by the rising popularity of python, you would be among the minority. Personally, I find python to be the most clear of any language I've worked with, most resembling natural language in the way I typically speak. Do you have some examples of how you find it self-contradictory? Here's an example of its expressiveness a colleague and mine I discussing the other day: Python: [os.remove(i.loc…