Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

I dont think that's the same kind of thing. Your example is a tradeoff that anyone who uses a language that doesn't require explicit variable declaration faces, and it's pretty tough to argue such languages really shouldn't exist.

Missing an operator resulting in explicit behavior is much more subtle and not even obvious behavior. For those who use python, it is worse.

> ...it's pretty tough to argue such languages really shouldn't exist.

"Shouldn't exist" is too strong.

Dynamic languages that let you create a new variable via assignment shouldn't be used to create non-trivial software. How about that?

Scripting languages have a place. That place is 100% in creating quick-and-dirty scripts and tools. Or in doing some kind of one-off data transform (as is common in machine learning scenarios). Anything that has a life span of two weeks or less, or a code length of fewer than a hundred lines? Yeah, script languages rock for that.

Explicit/static typing adds vastly more value to large projects than the cost of the overhead. The fact that you can't really gain that value in Python means that Python should be relegated to quick and dirty scripts.

Same for JavaScript, Ruby, and other completely dynamic languages.

You'll note that all of these languages are getting types one way or another, meaning that there are a lot of people who do recognize their value. Though TypeScript is years ahead of the rest in the completeness and sophisticated of its type system; bugs like the comma bug detailed by OP, along with simply every JavaScript "wat" bug, simply can't happen in TypeScript in strict mode. And static types enables entire other categories of bugs to be detectable via a linter as well.

I've been building non-trivial software in dynamic languages for twenty years. They work great.

I'd take a project in a dynamic language with a decent test suite over a project without tests in a statically typed language any day of the week.

But a dynamic language needs all the tests a compiled language needs AND type/syntax tests (that are handled by the compiler in a static language).

There are reasons dynamic language (or specifically Python), but I haven't heard one explanation how it helps writing fewer tests.

> I'd take a project in a dynamic language with a decent test suite over a project without tests in a statically typed language any day of the week.

I'd take the opposite. I've read too many useless tests in python codebases that can be accomplished by a static type checker. "Decent" does a lot of heavy lifting in your comment. And what about a dynamically typed codebase without any tests? I'm sure they exist.

I'd rather dive into a big ball of mud with a compiler that will help point me to my mistakes before I release them, than having to sift through a ball of mud trying to find that mistake with production services flailing.

That all being said I've worked with both types of languages in successful projects. But I prefer the development experience of the statically typed variety.

  it's pretty tough to argue such languages really shouldn't exist

Well, I agree with OP so that is at least two people. I really don't see it as a good trade.

Explicit variable declaration is just adding a keyword (such as var or let) when you're declaring a new variable instead of modifying one.

The cognitive burden of having to memorize and look for which variables are new vs which are being modified is simply not worth it in my opinion, even for a scripting language. Maybe for esolangs, simple math or first time learning programming.

In any case, it's a short coming of the language (IMO) but not a deal breaker. We learn to live with it.

I'd say unexpected behavior is always worse than expected one.

Yes, you'll certainly find somebody who doesn't know what 'not statically typed' means, but ... And yes, there are also C(++) users, that expect strings to be concatenated like that.

You seem to also not know what "not statically typed" means. It certainly does not mean "not properly scoped".

Yes, of course. But you see that no scope keywords exist in Python. But there exists `+` to concatenate strings (too).

I left python around the times of 2/3 drama, are nonlocal and global not there anymore?

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

Not entirely:

  let foo = a();
  let foo = b(foo);
  let fop = c(foo);
  let foo = d(foo);

(Which is valid, e.g., in Rust.)

I hate variables shadowing, I'm very surprised that they allowed it in Rust, I saw an unpected behaviour caused by variable shadowing in C++ (global variable hidden by member variable) just last week..

You do get a warning, though. And most Rust projects I've seen usually adhere to 0 warnings.

A good IDE has many other safety nets for that 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.

Or := for declaration like Go and Toit

Yes, or another symbol instead of `=` for assignment, like `<-` (F#)

While I agree, this is somehow something I expect. Implicit string concatenation without operator or function around it sounds just like a terrible idea. It breaks the basic syntax concept of `foo X bar`. On the other hand it is probably very handy with DSLs and things like that.

Not so much DSLs, it's probably something as banal and ancient as

  usage = (
    'usage: foo [options] filenames...\n'
    '  -f force concatenation\n'
    '  -c for convenience\n'
  )
  print usage

Edit: forgot to add parentheses

Isn't that common for all/most languages that don't require explicit typing?

This is a scoping rule, not typing. Scoping is a mechanism of symbol resolution, i.e. what do you mean by `foo` at line N. Is it a local, an argument, a global, or addresses a symbol defined in an enclosing scope? Most languages use explicit local definitions, searching implicit ones in outer scopes bottom-up, ending at the global scope. Python was the first popular non-basic language which made implicit assignments to be local and shadowing and function-scoped:

  global x = 1
  def setx():
    if True:
      x = 2 # completely different x
    print x # prints 2, visible outside of `if`
  setx()
  print x # prints 1

This led to a funny keyword 'nonlocal', because you can't simply ignore scoping and pretend that you're BASIC in any serious program.

(To my opinion, python had a good start, but lost in the woods for no clear reason. It's a movie mutant of a language, which tried to appeal to non-programmers and somehow succeed, and then realized that non-programmers eventually become ones, and it's not hard. Now it's too late to fix this mess. End of opinion.)

JavaScript (strict mode) doesn't have explicit typing, but it still requires variables to be declared.

Same for Perl.

Uh? Perl optionally requires you to declare variables, which is a good idea IMHO, no noise for small script and any experimented Perl programmer will have learned that 'use strict' is a really good idea for big scripts..

It would be impossible in any language that requires either explicit typing or some kind of 'let' keyword. (Or, in the fringe case, a language like Go which uses a different operator for initialisation-plus-assignment.)

Exactly. That's why I asked about languages that don't require explicit typing. My point is that it's a feature of many languages rather than a Python idiosyncrasy.

Declaration and explicit typing are logically orthogonal, but few if any languages require typing but not declaration. Lots require declaration but not typing.

It is common tonall languages that have the same syntax for definitions and mutation.

In Scheme, for example, this is not an issue.

That’s a complaint against the entire type system, nothing to do with misspelling.

It has nothing to do with the type system? It's an issue with implicit declaration. You could very easily require explicit declaration while retaining the selfsame type system.

Huh, you're right. It would be bizarre to see something like this in Python though. I've never even thought of it as being implicit declaration.

I was going to comment something like "who would even use this?" and then I remembered that I have in fact used that feature :) It's a somewhat "nice" way to write long strings and keep the code from getting too wide. I never did it inside an array, but I found breaking up a long string into smaller ones and wrapping them in parens without a comma was convenient, for things like error messages.

But that's just what comes with a hyper flexible language like python. You can do lots of things in lots of different ways, but you can also screw things up just as easily, and your IDE won't tell you because technically it's valid code.

I completely get that. That is a very nice feature for building DSL or libraries with special needs. But it makes the overall language very dangerous.

Is this "operator" overloadable on each type in Python?

And that scares me a lot. I think I have to reevaluate my position towards Python.

It's not really an operator. It's part of the syntax of string literals. "foo" "bar" is an alternative way of writing the string literal "foobar". If foo is not a string literal, foo "bar" is invalid syntax.

Okay... So it is not a implicit operator. That is good. Some small reputation points are regained.

Thanks.

Why not just use plusses? Or perhaps a join func, which would accomplish the same.

I get the use case as you described it, but it just seems like minimal effort to accomplish and have some semblance of explicit/safety.

or if that's the use case, require the whitespace to include a \n or \r\n... It's not like python doesn't have significant whitespace already.

That wouldn't fix most of the cases highighted by the tool in the article.

So strange that Python has completely different syntax from C, but they chose to copy this obscure syntactic feature _even though they have the plus operator on strings_.

Heh. I use it all the time the way you do and didn't realize this is alien to many developers (no one in my team every complained about it).

It's common in some languages and used the way you use it. I looked in PEP8 and it seems they don't discuss this.

I think it's a perfectly valid use case, but clearly there are two camps to this. If this is so contentious, I would recommend PEP8 be revised to either explicitly endorse it as a way to split long lines or to explicitly discourage it and recommend the + operator instead.

You could have the same behavior by enforcing + operation in between

  mylongstring = "hello" +
    "world"

No idea if python's way of indentations allows this but sounds like it should

No, it doesn't:

    mylongstring = ("hello" +
       "world")

or, without `+`

      mylongstring = ("hello"
       "world")

Use \

    mylongstring = "hello " \
      "world " \
         "my " \
     "name " \
    "is"*

The use of \ is discouraged in Python. From PEP8:

> The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation.

See I knew Python just wants to be more like lisp.

Not sure if it's irony or not. After all, this is not really accidental string concatenation but an easy to make type error which can go undetected due to the dynamic typing (and the lack of thorough type annotation in most code).

The string concatenation in itself should not be a problem as it's really just string constants. (But again, it might be irony exactly because of this :) )

Unfortunately no irony.

I come from a programming platform (C#) where productivity is a key element of language design. I highly doubt that Anders Heijlsberg would have accepted such a error prone concept like a literal free implicit operator on a key type like strings.

Well, I guess it's true for most language that productivity is intended to be a key element of design. (For python, definitely. But I also remember James Gosling saying this about Java.) This implicit concatenation seems to come (inherited?) from C.

I kind of remembered that some languages do support it for braking strings into multiple lines conveniently. I'm a bit surprised that it works even on line (I've never used it, because why would have I), but you'll likely to make the mistake on multiline statements anyway. I've also checked and it doesn't work in java (which I kind of remembered, though I mostly do python these days).

> for braking strings into multiple lines conveniently

What is inconvenient about just adding a + at the end or beginning of the line?

In most languages an array with 3 elements has the same type as an array with 2 elements so the type system isn't going to warn you about the difference between

("foo" "bar", "baz")

and

("foo", "bar", "baz")

They still tend to differentiate between 2- and 3 element tuples (but I agree that the implicit concatenation is problematic).

Fair enough. I was only thinking about the str vs tuple case. So when you have 2 elements in the parenthesis.

C/C++ has the exact same thing, no?