111–120 of 146 posts
Earlier quoted context omitted.
Under both Python 2.7 and Python 3.3 I get: >>> x=(,) File " ", line 1 x=(,) ^ SyntaxError: invalid syntax
From the Python docs ( https://docs.python.org/3/tutorial/datastructures.html#tuple... ) > Empty tuples are constructed by an empty pair of parentheses; And it works fine >>> x = () >>> x () I guess Herge mean that? After all, his argument was that a tuple is not always defined by the comma.
This list is an excellent summary. If tasked with a #11 I'd probably add the slightly more obscure, but still super painful (when you do run into it) implicit string concatenation: >>> l = ["a", ... "b", ... "c" ... "d"] >>> l ['a', 'b', 'cd']
Still hugely useful when you want to write long string constants. Imho, adding a comma after each list element is a good practice. You can easily swap them, add more, and never run into a an issue you describe: foo = [ "a", "bc", "def", # comma here, too ]
"Explicit is better than implicit"
It seems someone thought along similar lines and took action: http://legacy.python.org/dev/peps/pep-3126/ but the issue got rejected.
def get_analytics_data(options = {})
options = options.merge({'ids' => GAReadonly.configuration.id })
Does someone knows if the first mistake is also present in Ruby? I ran into this code: def get_analytics_data(options = {}) options = options.merge({'ids' => GAReadonly.configuration.id }) and I wonder if I should fix it.
Earlier quoted context omitted.
> No languages are inherently "compiled" or "interpreted", that's a property of the implementation. A language and it's implementation are usually designed at the same time. Compiled or interpreted will affect design choices that go into the language. While additional implementations may follow, it can be hard/impossible to design a compiler (machine code, not byte code) for a language that was designed to be interpr…
I feel that what most people actually mean when they say "compiled" vs. "interpreted" is whether or not the language specification has additional static checking beyond what is required by parsing. Essentially it is whether the language defers all errors to run-time or attempts to detect classes of them at compile-time. A language like JavaScript accepts as a program any string that parses, while a language like Java…
> You can run C++ or Java with run-time type-checking, but it doesn't conform the to spec.
I'm not sure what you mean by "conforming with the spec". You can opt out of type checking by using only `object` or `void*`. But golang has a mode where you run a go file directly and a mode where you generate a binary. There are no traditional interpreted languages anymore (or at least only very few). And what we call "compiled" languages today are not actually compiled ones. The way Java runs is closer to how JavaScript runs than to how C runs. It's only about the interface the offer to developers.
Earlier quoted context omitted.
>really it's the behaviour of the two cases taken together that can seem inconsistent. Why do you think so? I think that both cases seem consistent, or rather, correct (and therefore this example should not be treated as a common Python mistake), because x is not assigned a value anywhere in class C, and C inherits from A, so it should be clear to anyone knowing OOP and inheritance, that C's x is the same as A's x. (…
What's happening here is that a variable is inheriting its value from the superclass, except for when it doesn't. And when it doesn't, why is that? Well presumably it's because something's been overridden - OO tells us that's how we change the properties that are inherited from the superclass. No wait, that's not it; nothing's been overridden here. All that's happened is we've assigned a value to B.x, and doing so se…
Does this link crash anyone else's Safari on iPhone 5s?
>>> def foo(bar=None):
... if not bar:
... bar = []
... bar.append("baz")
... return bar
...
>>> bar = []
>>> foo(bar)
["baz"]
>>> bar
[]