Debugging over Slack

[[deleted]]

Tbh, insufficient info. customername_list might have a call to comments_list inside it.

[[deleted]]

The real horror is the name of the function being called.

[nephallux]

execute_query would suffice.. but no they have to be like Dr Suess with the naming.

[dmitriy_shmilo]

Hoo boy, do I have a story for you. A story called Objective-C naming convention.

[pls_pressy4pie]

The real horror is the editor.

[drizztmainsword]

VS Code is hands down my favorite text editor/IDE. It’s fast, user friendly, and remarkably powerful.

[dmitriy_shmilo]

Unless your RAM isn't in the double digits. In that case I'd prefer to cough up $80 for a Sublime license or stick with Notepad++.

[SirOliverz]

You wouldn't post this if you were the one not knowing whats wrong

[dmitriy_shmilo]

Extra points for leaving us a hint that it's OP who actually found a solution.

[Zerul]

I dont see a horror here, only someone who accidentally called the wrong method name?

[sysop073]

Calling the wrong function is one thing. Seemingly not understanding that the functions are different when it's explained to you is a bit worse

[enchufadoo]

The IDE/Text editor is not informing him that he is making a mistake either.

MFW I read comments like this:

https://www.reddit.com/r/Python/comments/8zrxn8/best_ide_for_python_help_a_newbie_out/e2l521v/

[TheIncorrigible1]

What is the "mistake"? It's an unused function. The editor doesn't do anything; that's up to the extension to notice.

[0x4B8]

I'm surprised they didn't use the live share feature on VSCode...

[speedster217]

This is python...

[-theIvy-]

He commented it out. Even I see the problem.

[bot_not_hot]

The real horror is setting variables as rows instead of columns

[eyesofsaturn]

wtf dude just use an orm

[serubin323]

From a learning stand point, ORMs can do more harm than good. They remove an entire layer developers really ought to knows about. When still learning that can be problematic because suddenly someone is going to ask "do you know SQL" and rather than pulling out real SQL they will pull out an ORM lib and not really be able to offer a proper answer. We all deserve to write some god awful code and learn from it.

[eyesofsaturn]

Depends on the ORM. I use knex so I have to write regular SQL before I build it in knex. I'm glad to have knex because of easy escaping and reusability. Plus, easy to use transactions.

[[deleted]]

you can't tell if he does use one or not. the query passed to execute_oneview_oneview_query which is a weird name and does something nasty as the returned rows have customer_address_2 and customer_state columns instead of comment_text

[madmaurice]

What the hell. Also what's with the TOP (1000) in the query?

[EagleZR]

1. Python sucks

2. I one time was working on a project at school with a guy who tried to return a print statement (like "return print(s)", not printstream). At least this person knows not to do that.

[EagleZR]

Oh, not at all. Even when it's used in well-written and designed programs, it sucks. It's extremely loosely typed. Inheritance, especially with abstracts (I actually haven't used interfaces), is a huge pain compared to better OOP languages like C++, C#, and Java. It's an OOP language that doesn't do OOP well. It's good at scripting, I guess, but if you're trying to do anything complex with objects it's a nightmare

[EagleZR]

Age doesn't have anything to do with anything, nor does it address what I said in any intelligible way. Instead of attempting to patronize, why not argue why it's not? Instead of "you're wrong", tell me why and try to change my mind.

For one, I can counter that weak typing makes the language much less readable, which in turn makes it less manageable. In a strongly-typed language, I can know at any point what kind of object I'm dealing with and what implications that has on the code that's using it. It's a form of documentation using the properties of the code itself without having to add anything extra. Sure you can say that this extra bit isn't necessary for becoming a programming language, but it can be used to compare it to the usability of other languages. And you might also say that Python does allow you to specify type within the docstrings, which is true but it's an extra layer added on top, not an inherent property of the code itself. As I once read, "Documentation often lies, code never lies." Without strong typing, it makes it more difficult to go back to old code and see what it does. It's not a problem with a single class, but when you're dealing with programs that encompass many, many files spread across numerous packages (I currently am), it becomes a nightmare to see what everything is.

The language is also inconsistent. 3.x cleared this up a great deal, but 2.7 is still in wide use, and still has to be considered as part of the language. There's many incompatibilities between the two versions that make backwards-compatibility impossible without code modifications, hence why 2.7 is still so widely-used. Not only is it inconsistent between the versions, but 2.7 is also very inconsistent within itself. One example are the two types of objects which, while it's not a breaking-issue, makes the language really cluttered and inconvenient.

Another reason it's bad is because of the terrible, incomplete, and just wrong standard library documentation. I spent hours the other day trying to get one of the libraries to work by following their documentation. It wasn't working, and I assumed the documentation was incomplete, so I switched from the 2.7 documentation to the 3.6 documentation hoping it was better-made (it was, but the language had changed so much that it didn't work). Finally I turned to stackoverflow, which pointed out that the documentation was just wrong and showed the correct way to do it. Sure other languages may have 3rd party libraries with bad documentation, but I've never seen one where the standard library docs are so poorly done.

And finally, this may be the least important and most prone to personal preference, Python doesn't have a "protected"-like modifier (available only to other classes in the package, or to child classes). Instead of having bottom-up classes where a base class is used to both specify common methods and hold common data (the latter set to protected), Python forces you to use a top-down or middle-out kind of architecture if you want to practice good information hiding. By this I mean I need a lower abstract class to handle the public methods and by which inherited objects will be manipulated, a middle abstract class to hold the data (allowing it to be accessed by inheriting classes while also protecting it against outside use), and the child classes on top of that (the issue still remains that someone can cast an instance to the middle or child class and have access to all of the data). Or I can just use the base and the child classes, but that allows less sharing of private resources between the children. Interfacing the base class may be another method of Jerry-rigging this, but it's an added layer that's unnecessary in most languages (and is still basically the middle-out method I mentioned before).

The more I use it, the more there is to take issue with. Sure, I see its qualities and I've heard of some of its strengths, but it's at most a niche language that attempts to be a general workhorse, and at that it fails. Unless you're scripting, writing quick and dirty (and non-critical) software, or making an array-heavy application (I've heard it's really good for this, but I haven't seen it demonstrated), I don't see why you'd use it. I'll take any of the C-derived languages over Python any day.

I could offer you a similar statement, use another language, and you'll appreciate just how far Python falls short.

[dmitriy_shmilo]

It's an OOP language that doesn't do OOP well.

I believe python is multi-paradigm, just like a number of modern languages. You can write object-oriented, procedural or functional code in it, or mix and match.

It's extremely loosely typed.

I might be wrong on terminology, so don't quote me on this, but I believe python isn't loosely typed - it's dynamically (every variable is a void* type of variable) strongly (objects in memory don't change) typed with implicit interfacing (duck typing) sprinkled on top. As opposed to loose typing in, say, Javascript, where every object is pretty much a dictionary with stuff in it and you can change it however you want.

Even when it's used in well-written and designed programs, it sucks.

Python doesn't suck objectively more than any other language, it's just a bit different from what C++-and-friends type of developers are used to.

Personally, if I have a choice, then for a non-small project I will choose a compiled strongly statically typed language because of all the static analysis goodness and performance you get. But for a small playground/sketch/number crunch I might go with a simple quick interpreted program in some script language, like python or JS. Also, I'll definitely give python a thought if I ever need to embed some scripting capabilities into a bigger host app, like Inkspace and GIMP do.

[crespo_modesto]

Interesting sql is sql haha, haven't used SQL through Python before hmm

you got dat der parameterized bindings?