Live data from Hacker News

A bite of Python

access.redhat.com

151–160 of 168 posts

Re: A bite of Python

#151
post #115
post #27

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.

Not prevented from being able to use, but from accidentally using or overriding the parent's. The child can still use the mangled name.

Re: A bite of Python

#152
post #67
post #25

Earlier 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".

[deleted]

Re: A bite of Python

#153

The 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…

I think it depends on the job the program is being used for. If the program is used in a setting where occasional crash has no severe consequences, say search engine backend, it may be useful for the company to actually run in production a program that is allowed to crash whenever severe error condition occurs. In scenarios where lives or lots of money hinge on program being alive and functioning, such as plane autopilot, or rocket / space probe control, crash or fatal error of the main program often means disaster and thus should never occur. If error condition occurs during execution, the program should withstand that and continue with default path of execution. In the past lots of lives and money could be saved if only the software and hardware conformed to this paradigm.

Re: A bite of Python

#154
post #150

Earlier 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.

There are a few functions in the C API to let you call things, depending on the type of thing and set of arguments you feel like providing, and they rely on the Python API to handle the calling for you. I imagine if you really wanted to, and knew enough about the structure and expectations of the Python object you were working with, you could "manually" call without going through one of those C API functions, but I don't know that I'd recommend trying it...

Re: A bite of Python

#155
post #124
post #56

One 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.

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.

Re: A bite of Python

#156
post #124

Earlier 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.

Status quo is the sane default. But in this case... I've used this syntax both as a feature and a bug about in equal portion.

I could imagine the new f-string interpolation might have some nice synergy.

Re: A bite of Python

#157

I 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)…

haha, your explanation is exactly the mutable vs immutable thing.

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

#158
post #126

Earlier 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…

len is a method. it is just a shortcut for object.__len__()

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?…

> If ints act that way, shouldn't strings?

`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

#160

I 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…

Indent with four spaces to show code nicely on HN
Post reply on HN