301–310 of 339 posts
A lot of people are criticising dynamic typing for this. It doesn't seem to have anything to do with typing discipline. words = ( 'yes', 'correct', 'affirmative' 'agreed', ) Would be a tuple (immutable list) of strings, while words = ( 'yes', 'correct', 'affirmative', 'agreed', ) would also be a tuple of strings. If haskell had for some reason decided to have the same syntax sugar, it also would have caused an issue.
{
'key': (
'long string long string long string'
)
}
title = 'Hello world',
Earlier quoted context omitted.
I know that. I meant that “abc” + “def” is most likely illegal (although “abc” + ‘d’ is not).
You started talking about "adding strings" in a thread about adjacent literals, without mentioning any + operator.. String catenation ("adding") by adjacency (no visible operator) is a thing; "add" doesn't imply that we are talking about a + operator: $ awk 'BEGIN { x = "abc-" 2 + 2 "-def"; print x}' abc-4-def
Earlier quoted context omitted.
> The most common way to split a string in lines is using this concatenation formula. Is it really? I tend to avoid it in favour of ””” or ‘\n’.join( ), because it looks like a mistake. Triple quotes are kind of annoying if the string is indented, but you can just not indent the string to avoid the whitespace.
Both of your solutions are great but don't fully cover the use case. They are useful for multiline strings, but implicit concatenation is also often used to break long strings that may not have newlines.
No footgun potential, and as others have mentioned the “good usage” would often be bad simply because it ends up looking like a mistake even if it’s intentional.
Earlier quoted context omitted.
Presumably because parantheses don't really have anything to do with tuples, it's commas that do. Parantheses are there to help the parser group things in case of ambiguity, and to support expressions spanning multiple lines.
Since you typed it twice, I don't think it's a typo. It's parentheses not parantheses.
Earlier quoted context omitted.
If you use mypy (as anyone should for any non-hobby Python usage) then Python has one of the strongest type systems available. Optional types, generics, "Any" escape hatches, everything you could want.
Would mypy have caught any of the issues highlighted in the article?
The problem in the article is more related to syntax, not types, with the problem that both forms are valid syntax with different but still very similar outcome.
Pylint on the other hand can find it with implicit-str-concat check enabled.
Earlier quoted context omitted.
https://github.com/tensorflow/tensorflow/tree/0d8705c82c64df... STOP! This folder contains the legacy Keras code which is stale and about to be deleted. The current Keras code lives in github/keras-team/keras. Please do not use the code from this folder. Yeah, not the most obvious notice. The fact they didn't find the same mistake(s) in keras-team/keras (I assume they scanned, it's one of the most popular Python repo…
once tensorflow pointed to keras-team this happened https://github.com/keras-team/keras/issues/15854 resulting in https://github.com/keras-team/keras/pull/15876
"Absent comma results in unwatned string concatenation on line 330"
Bug-ception!
Earlier quoted context omitted.
If a person decides to add parentheses to some booleans or arithmetic, (4 + 5) * (8 + 2) (this and that) or (theother) These elements should not become 1-tuples after the interior contents are evaluated. I sometimes add parentheses even around single variables just for visual clarity. Also, this allows you to do dot-access on int / float literals, if you want to # doesn't work 4.to_bytes(8, 'little') # works (4).to_b…
In principle, a 1-tuple shouldn't even be a thing - any single value is a 1-tuple by itself already. However, in a dynamically typed language, this approach complicates things elsewhere - e.g. if you have a value / 1-tuple that is a list, you'd expect iteration over it to give you list elements, not the single element that is a list. But if you have a value that is a tuple of unknown size, you don't want to special-c…
I can see the value of a lint (if there's a newline without a comma, warn), but concatenating strings by multiplication is the correct thing to do (since it's also used this way in mathematics of parsers). Using the plus operator to concatenate strings is just weird. Think of the usual algebraic properties these operators are supposed to have. "+" always is supposed to be commutative--so "a"+"b" = "b"+"a", if those m…
Juxtaposition is not multiplication in this context - you can't write (2 3), for example, it has to be (2 * 3). Furthermore, Python already uses * for strings to indicate repetition: ("foo" * 2 == "foofoo"). String concatenation really just needs its own separate operator. & is an obvious candidate, if only it wasn't so commonly appropriated for bitwise AND - which is a very poor use of a single-char operator as it's…
Earlier quoted context omitted.
Keywords like namespace , no; but functions and classes and modules provide for a lot of scoping opportunities.
The problem is `fop` should be `foo`: foo = 5 fop = 6 Keywords like `let` solve this problem: let foo = 5 fop = 6 # error
Auto completion, highlight matching variable, gray out unread variables and warning of unused assignment.
I’ve written lots of python and can’t recall ever having this issue. More likely is a logic typo of two similar variables like length_x vs length_y, where a “let” wouldn’t have saved you anyway if both are already defined.
JavaScript, pre strict TS, on the other hand, where missing var implied global was a real motherload of bugs. Or kotlins “val” vs “var” changing semantics completely…wow. But those are different concepts from basic definition I know.