181–190 of 339 posts
For those looking to avoid this specific problem, there is a flake8 rule: https://pypi.org/project/flake8-no-implicit-concat . More broadly, the https://codereview.doctors makers are making the point that their tool caught an easy-to-miss issue that most wouldn't think to add a rule for. A bit of an open question to me how many of those there really are at the language level, but still seems like a neat project.
Earlier quoted context omitted.
That's one way. If these things are classes in a plain old single-dispatch oop system, you can havec a json-parser and csv-parser which have parse methods. There could be packages/namespaces. So csv:parse and json:parse. These packages are standard and so they just exist; nothing to import. In Python, you cannot use anything without an import! The top-level modules (which serve as de facto namespaces) themselves are…
It lets you debug. E.g. if they have made a file called cvs.py in the same directory, then print (cvs.__file__) will show you this. If they have some weirdly screwed up paths with multiple pythons installed and multiple copies of the modules etc., same. I will not Go lang has the same feature carried forward from C. It helps a lot in the reading code side of the code lifecycle. And Go compiler makes you keep the impo…
It lets you debug Python problems which the system created in the first place.
> If they have some weirdly screwed up paths with multiple pythons installed and multiple copies of the modules etc., same.
Doesn't happen in a sane language. Or, even not a sanely defined language/implementation.
I can easily have multiple different GCC copies (possibly for different processor targets) on the same machine. Each one knows where its own files are; an #include compiled with your /path/to/arm-linux-eabi-gcc will positively not use your /usr/include/stdio.h, unless you explicitly do stupid things, like -I/usr/include on the command line.
Earlier quoted context omitted.
Does Python support the concept of allowing code to opt in to new safety features? I can understand rejecting something like this for the sake of legacy compatibility (something Python has abandoned too readily in the past), but it seems like an option—or maybe even a default—might be nice. I suppose this is also something you could catch with a linter?
Yes: import from __future__ https://docs.python.org/3/library/__future__.html
Not in Lisp! ("foo" "bar") and ("foobar") are lists of length 2 and 1, respectively. (Python copies some bad ideas from C. Another one is having to import everything you use. It seems that since Python is written in C, its designer took it for granted that there will be something analogous to #include for using libraries, even standard ones that come with the language.) Implicit string literal catenation is tempting…
You mean long %s stringnicely breaks upwith indentation and all" ? In my experience, this always gets ugly when you want to insert spaces (= about always). Do you put them at the end or at the start of each string (apart from the first or last string) I think scala’s mkString ( https://superruzafa.github.io/visual-scala-reference/mkStrin... ) is the best solution, visually, for such things, but unfortunately, it woul…
Earlier quoted context omitted.
I mean the zen being wrong is kind of a meme at this point. The whole “only one obvious way to do it” isn’t just false but the exact opposite is true. Python is one of the most flexible languages with many many ways to do the same thing; more than any other language I can think of.
Notice that, in the original quote, There should be one-- and preferably only one --obvious way to do it. the author used two different ways of hyphenating (three, if you count the whole PEP 20). PEP 20 is clearly not meant to be taken as law. Nor PEP 8. Nor PEP 257. People frequently mistake "one obvious way" with "one way". There are lots of ways to iterate through something, for example, but there is really one ob…
There should be at least one-- preferably only one --obvious way to do it.
Not in Lisp! ("foo" "bar") and ("foobar") are lists of length 2 and 1, respectively. (Python copies some bad ideas from C. Another one is having to import everything you use. It seems that since Python is written in C, its designer took it for granted that there will be something analogous to #include for using libraries, even standard ones that come with the language.) Implicit string literal catenation is tempting…
Having everything be imported is what makes the language be useable. Especially if you never import * you can easily find the definition and meaning of everything you read on the screen. A prime example of explicit is better than implicit. And backslash doesn’t let you have the literal obey the proper indenting. Might as well use “””
I don't want to be finding definitions of things that the language provides in the code.
Languages that don't work this way have IDE's, editor plug-ins or other tools for easily finding the definitions of things that are in the language, without hunting for them through intermediate definition steps in the same file.
"I've spent all my life in and out of jails, so I expect bars on doors and windows ..."
Earlier quoted context omitted.
It is positively not illegal in any standard verision of C since ANSI C 89. It's an essential feature used in all sorts of everyday code. C99 added printf conversion specifiers that are hidden behind macros, and idomatic usage of them relies on string catenation. uint32_t x = 0; printf("x = " PRIx32 "\n", x); where PRIx32 might expand to "%lx" (if uint32_t is the same as unsigned long in that compiler). All sorts of…
Interesting. Arguably tho this shows how C is aging. I find that PRIx32 a bit ugly. Although I just had a (logging) use case in go where I missed cpp macros - wanted the log statement to get something from the file and just had to pass it in as another parameter.
If I have a uint32_t which needs printing I cast it to (unsigned long) and use %lu or %lx. This requires more typing in the argument list, but keeps the format string tidy. It's important for the format string to be tidy, because that's the reason of its existence: to clearly and concisely convey the shape of what is being printed.
Earlier quoted context omitted.
I mean the zen being wrong is kind of a meme at this point. The whole “only one obvious way to do it” isn’t just false but the exact opposite is true. Python is one of the most flexible languages with many many ways to do the same thing; more than any other language I can think of.
the zen of python was written in the 90s. from that context it makes sense, because the only goal of python in the 1990s was to be more popular than perl, which was notorious in having many ways of doing the same thing. but yeah, python had had significant feature creep over the years, it's nowhere near the small clear lang it used to be.
Earlier quoted context omitted.
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 c…
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.
Earlier quoted context omitted.
"require 'json'" is just another #include in disguise, and if it monkey patches existing classes, it ... probably should not exist in any form. If the language supports json, it should just do that. 1> #J[1,2,3] #(1.0 2.0 3.0) 2> (get-json "[1,2,3,{\"foo\":true}]") #(1.0 2.0 3.0 #H(() ("foo" t))) 3> (put-json #(1.0 2.0 t)) [1,2,true]t
Welcome to Ruby. $ irb irb(main):001:0> { hello: "world" }.to_json NoMethodError (undefined method `to_json' for {:hello=>"world"}:Hash) irb(main):002:0> require 'json' irb(main):003:0> { hello: "world" }.to_json => "{\"hello\":\"world\"}"
If it was CLOS with multiple dispatch, it would be easier to swallow. Because it would look like:
(to-json { hello: "world" })
;; error: no such function!
I regard the ability to add new methods to a class as good, but with a valid use case, like extending some third party piece with new methods in your own application. And the fact of not having to declare methods in a class definition, which is cumbersome. Just write a new method in that class's file, at the bottom, and there it is.
I ideally don't want that third-party piece itself to be divided into three pieces that I have to separately load to get all of the methods. Or worse, pieces from separate third parties that add methods to each other.
I copied a thing or two from Ruby in TXR Lisp. The object system as a derived hook, and that was inspired by something in Ruby:
1> (defstruct foo ()
(:function derived (super sub) (prinl `derived @super @sub`)))
#
2> (defstruct bar foo)
"derived # #"
#
3> (defstruct xyzzy bar)
"derived # #"
#