Python information and short questions megathread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Python information and short questions megathread.

«‹›484 »

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

QuarkJets posted:

Thermopyle, why is a """single-line docstring""" better than #single-line docstring? They serve the same purpose and do the same thing but # is a lot cleaner looking when you only have one line

For one thing, # comments are not docstrings. As I mentioned, docstrings have a rigid definition as "a string literal that's the first statement in a module, class or function". Comments are not strings; they are completely ignored by the parser.

Python code:

In [1]: def square(x):
   ...:     # Returns x * x.
   ...:     return x * x
   ...: 

In [2]: square.__doc__

In [3]: square?
Type:       function
String Form:<function square at 0x7f4efdfc1f80>
File:       /home/me/<ipython-input-1-3fe8f57745da>
Definition: square(x)
Docstring:  <no docstring>

EDIT: beaten; may as well leave this here

# ? Jun 4, 2013 15:20

Adbot: ADBOT LOVES YOU

# ? May 24, 2024 17:27

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Lysidas posted:

Guido's absolutely right in that it's good to avoid ambiguity, but lots of the functions/classes in the standard library are clear enough on their own.

Yeah, I mostly don't disagree with you here. Personally, I don't like from functools import partial. While you or I might not ever have named a function partial, it's still not clear from the function name what it actually does. That would be a problem for me as I haven't had an occasion to use partial in a long time. There was a period where I was using it a lot, and if I would have seen its use in some code I would have immediately thought it was functools.partial, and I would have been right. But, it's also possible I could be looking at code from a programmer who had named a function partial and I would have been wrong in that instance.

What partial actually is may or may not be clear from the context of where its used, but I'd prefer to avoid the issue altogether. Explicit is better than implicit.

But yeah, it's not a terrible sin or anything.

QuarkJets posted:

Thermopyle, why is a """single-line docstring""" better than #single-line docstring? They serve the same purpose and do the same thing but # is a lot cleaner looking when you only have one line

A comment is not a docstring. Tools and introspection won't recognize it as such.
Consistency.
When your method is refactored a little bit and your comment expands you'll have to convert it to a docstring anyway.
Once you've got to the point where you've read a lot of code, or you're using an IDE that does formatting of docstrings, comments won't stand out as a description of the function, whereas a docstring will.

QuarkJets posted:

Seriously, is there any reason to use MySQLdb's variable substitution mechanisms instead of just building the strings yourself?

Consistency. Sure, there are scenarios where you're not vulnerable to injection attacks, but you surely don't want to be using python string formatting AND MySQL interpolation.

Most of this stuff is no big deal in isolation. But consistency is important. It helps you avoid bugs and it helps you understand your own code next week.

At first blush, you might think you're ok if you're always consistent in what you do. There's a couple problems with that. First off, if you build up consistent habits that aren't in line with wide spread standards then you're going to have issues working with other programmers, and other programmers are going to have problems reading your code. Secondly, wide spread standards have been hammered on by a lot of people with a lot of experience, and, in general, there's reasons for these kind of standards.

Something I always keep in mind is that when you're writing code, you're always working with at least one other programmer. That other programmer is yourself in the future. In the future, you're working on different kinds of problems so you're not using the same libraries. In the future, you're working with other programmers so you're sticking more closely to some sort of code standard. In the future, you're a manager and not doing a lot of coding. In the future, you're different.

Now, with experience, you'll be able to know when to break the "rules". I'm certainly not going to type out BeautifulSoup every time I use it, so I'll import BeautifulSoup as BS. (Actually, I'd use lxml instead)

I'm not militant about any of this stuff, but there are good reasons for the "rules". You just have to have the experience to know how to weigh those good reasons against your reasons for not following them.

# ? Jun 4, 2013 17:30

Civil Twilight: Apr 2, 2011

Because it hasn't been explicitly mentioned in this discussion: if a function has an actual docstring (not just a comment), calling "help(name_of_function)" in the python repl will print that docstring.

# ? Jun 4, 2013 17:44

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

QuarkJets posted:

Seriously, is there any reason to use MySQLdb's variable substitution mechanisms instead of just building the strings yourself?

So, prepared statements are a thing. It turns out that MySQLdb is quite terrible and just does string interpolation inside the library itself (note the maintainer committing merge conflicts to the file everywhere, even to an autogenerated file), but MySQL has native support for prepared statements, where the data and query are sent to the server separately.

You'd never do this in Python:

Python code:

post_count = eval("users['%s']['post_count']" % (user_name,))

Why do it in SQL?

It also turns out that this can improve performance, just like "not using eval" would as well. Instead of parsing, optimizing and compiling the statement into internal bytecode to be executed every single time, a prepared statement can be parsed, optimized (often times it optimizes more heavily, because it knows it's going to be reused), compiled and cached. Also, the DB server communicates over a socket, and now you only have to send the SQL statement over the wire once — at statement compilation time. Any time after that, you just send over the data and say "use query ID 5 please".

oursql is a database driver that supports all of this, plus other things.

# ? Jun 4, 2013 18:06

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Is it good style to use assert statements as a form of documentation? i.e. "I know that at this point in the function, condition X must hold because it follows from something I did a few lines ago. But the reader trying to understand the function might benefit from having this pointed out to them, so put in an 'assert X'."

# ? Jun 4, 2013 20:12

n0manarmy: Mar 18, 2003

I'm just having a hell of a time with GUI development. I can easily write a single window application that opens, a person clicks some buttons, a function performs and then its done. I am struggling when it comes to complex GUIs with multiple windows and tying in the function program.

Any good docs on where to go next? I can't find anything free that covers a more complex view for PyQt/PySide so maybe its worth it to move on to the next GUI for Python?

# ? Jun 4, 2013 21:40

Dren: Jan 5, 2001; Pillbug

Dominoes, I noticed you have the idea that you should write as little code as possible. That's not quite the right idea. The right idea is to avoid reusing code, not to write the shortest possible syntactically correct code. It's often better to write a little more code for the sake of clarity. e.g. os.path.join(dir, "filename") as opposed to dir + "filename". Not to mention that in the former case you get cross platform compatibility.

I vastly prefer import X over from X import Y, though I will sometimes break that rule. The reason is simple. If I encounter:

Python code:

m = hashlib.md5()

I know what m is. If it were

Python code:

m = md5()

I would have to grep around the file to figure out what m is.

Something that bothers me about python is that you pay a performance penalty for the . lookup every time the function is called when you use the long form of a function name. So there's actually a performance reason to use the 'from X import Y' syntax or to alias a function before using it a lot.

# ? Jun 4, 2013 22:41

duck monster: Dec 15, 2004

Nybble posted:

Just a end-of-day frustration I just found in our code:
code:
sql = '''
   SELECT %s FROM table_number_%s 
   WHERE agency_id = %%s
''' % column, number

result = self._query(sql, (agency_id))
Resulting SQL:
code:
 SELECT vehicle FROM table_number_4 WHERE agency_id=16 
Yes. That's two string substitutions in a row, with no other instructions inbetween. The Double Percentage (%%) which is commonly used to do a literal '%' is in place so it can be substituted later.

This is tame. Some of the PHP I've been forced to maintain stuff, has had these sorts of substitutions, pulled directly from the command line using register globals and no cleansing. Its.... terrifying, and worst of all, the boss doesn't understand why its bad and is incredibly resistant to me refactoring it ("Every time you code, the files actually get shorter, thats not productive!")

# ? Jun 5, 2013 03:26

BeefofAges: Jun 5, 2004; Cry 'Havoc!', and let slip the cows of war.

Dren posted:

Something that bothers me about python is that you pay a performance penalty for the . lookup every time the function is called when you use the long form of a function name. So there's actually a performance reason to use the 'from X import Y' syntax or to alias a function before using it a lot.

Note that this kind of performance penalty totally doesn't matter the vast majority of the time. Ruining readability to gain some tiny potential performance increase isn't worth it. After all, this is Python, not C++.

# ? Jun 5, 2013 04:34

QuarkJets: Sep 8, 2008

Civil Twilight posted:

Because it hasn't been explicitly mentioned in this discussion: if a function has an actual docstring (not just a comment), calling "help(name_of_function)" in the python repl will print that docstring.

Okay, but "help(name_of_function)" seems to work just fine with my single-line #-style comments. So does that imply that # really does create a docstring?

For instance:

code:

#Some helpful comment about a function
def x(test):
    print test

Calling help(x) prints:

Help on function x in module test:

x(test)
#Some helpful comment about a function

e: I've been doing it this way for years, and it has worked everywhere that I've tried it. What is this behavior?

QuarkJets fucked around with this message at 04:41 on Jun 5, 2013

# ? Jun 5, 2013 04:38

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

QuarkJets posted:

Okay, but "help(name_of_function)" seems to work just fine with my single-line #-style comments. So does that imply that # really does create a docstring?

For instance:
code:
#Some helpful comment about a function
def x(test):
    print test
Calling help(x) prints:

Help on function x in module test:

x(test)
#Some helpful comment about a function

e: I've been doing it this way for years, and it has worked everywhere that I've tried it. What is this behavior?

Python code:

def comment_docstring():
        # comment_docstring help text
        x = 7

def string_literal_docstring():
        """string_literal_docstring help text"""
        x=7

# prepended_comment help text
def prepend_comment():
        x=7

In python2:

code:

In [4]: help(comment_docstring)
comment_docstring()   #### No result as expected

In [5]: help(string_literal_docstring)
string_literal_docstring()
    string_literal_docstring help text    #### Result as expected

In [6]: help(prepend_comment)
prepend_comment()
    # prepended_comment help text   ### I have no idea what this is.

I suspect the fact that help() prints out a prepended comment like that is an implementation side effect that wasn't intended. I don't feel like tracking down the source to help() to find out for sure. I certainly haven't seen prepended comments like that before.

Some more stuff:

code:

In [6]: comment_docstring.__doc__

In [7]: string_literal_docstring.__doc__
Out[7]: 'string_literal_docstring help text'

In [8]: prepend_comment.__doc__

# ? Jun 5, 2013 05:24

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Hammerite posted:

Is it good style to use assert statements as a form of documentation? i.e. "I know that at this point in the function, condition X must hold because it follows from something I did a few lines ago. But the reader trying to understand the function might benefit from having this pointed out to them, so put in an 'assert X'."

Documentation is likely a better form of documentation when the code isn't clear enough on its own.

# ? Jun 5, 2013 12:00

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Misogynist posted:

Documentation is likely a better form of documentation when the code isn't clear enough on its own.

Explanatory comments are good, it's just that in this case a comment would have been along the lines of

# Remember, myCondition is False here, because we filtered out cases
# where it is True in an elif above this point.

It's that or just

assert not myCondition

which signals to a reader that the author of the code has a good reason to believe that myCondition is False at that point in execution. If they're curious as to why that is, they can go figure it out.

# ? Jun 5, 2013 12:19

Dren: Jan 5, 2001; Pillbug

Hammerite posted:

Explanatory comments are good, it's just that in this case a comment would have been along the lines of

# Remember, myCondition is False here, because we filtered out cases
# where it is True in an elif above this point.

It's that or just

assert not myCondition

which signals to a reader that the author of the code has a good reason to believe that myCondition is False at that point in execution. If they're curious as to why that is, they can go figure it out.

Why not both? The comment explains things so the programmer (future you) doesn't have to figure it out (again). That the assert never shows up in production guarantees that the comment is still true.

# ? Jun 5, 2013 14:05

Nybble: Jun 28, 2008; praise chuck, raise heck

duck monster posted:

This is tame. Some of the PHP I've been forced to maintain stuff, has had these sorts of substitutions, pulled directly from the command line using register globals and no cleansing. Its.... terrifying, and worst of all, the boss doesn't understand why its bad and is incredibly resistant to me refactoring it ("Every time you code, the files actually get shorter, thats not productive!")

I cede it to you; that last quote would have me looking for a different job if possible. Mine is just an annoyance, of course.

# ? Jun 5, 2013 16:39

fart simpson: Jul 2, 2005; DEATH TO AMERICA

duck monster posted:

("Every time you code, the files actually get shorter, thats not productive!")

Is this a real quote because :laffo:

# ? Jun 5, 2013 17:47

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Can someone explain to me what is going on here? Is f(2) a function, or an integer, or both, or neither? And how do I get the expected answer of 4?

Edit: I figured it out. lru_cache is not in fact a decorator. It is a function that returns a decorator. Changing @c to @c() makes it work. They could have made this clearer in the docs.

Hammerite fucked around with this message at 18:45 on Jun 5, 2013

# ? Jun 5, 2013 18:36

b2n: Dec 29, 2005

Hey

I need a python library which allows for plotting of 3d bars. I've started out with matplotlib, but its 'bar3d' function is buggy when it comes to correctly displaying lots of bars that are close together.
I've tried to run Glumpy with no success. I would now try Mantid, unless someone has a better idea

Thanks

# ? Jun 6, 2013 12:54

BigRedDot: Mar 6, 2008

VTK python bindings are an option, albeit a super heavyweight one. The real question is why do you want 3D bars? I hope this is just for fun and you are not intending them for any kind of real or honest data vis because they are perceptually terrible.

# ? Jun 6, 2013 15:22

Synthesizer Patel: Feb 16, 2004; But, despite this, Synthesizer and others must stay constantly vigilant as synthesizer theft is rife.

n0manarmy posted:

I'm just having a hell of a time with GUI development. I can easily write a single window application that opens, a person clicks some buttons, a function performs and then its done. I am struggling when it comes to complex GUIs with multiple windows and tying in the function program.

Any good docs on where to go next? I can't find anything free that covers a more complex view for PyQt/PySide so maybe its worth it to move on to the next GUI for Python?

Having used all the available windowing toolkits that Python can use - PySide's my favorite and I'd urge you to stick with it. (if you get past what I'm about to say next)

Basically, desktop applications are dead. There's little to no reason to develop native applications and the few outlier situations that require a native application will be so
few and far between that you'll probably never notice them. Write your backend in Python, your front-end in Javascript. Audio, 3D, 'the cloud', browsers have everything
you want or need and have the added benefit of not cutting you off from 80% or 20% of the market because you're not using the write operating system. If you need to
develop a commercial app or 'ship' something - use chrome shell like Brackets.io does.

Anyway. As far as how to learn PySide - go download all the examples and get the tests from the source code. Most of what I learned I figured out from poking through
that stuff before I ended up buying a couple books.

The best PyQt/Pyside books are the Mark Summerfield ones - even the C++ ones are great because of Qt's syntax it's really easy to make the few mental adjustments
to convert the C++ examples to Python.

http://qt-project.org/books/view/introduction-to-design-patterns-in-c-with-qt
http://qt-project.org/books/view/c_gui_programming_with_qt_4_2nd_edition_the_official_c_qt_book
http://qt-project.org/books/view/advanced_qt_programming_creating_great_software_with_c_and_qt_4

# ? Jun 7, 2013 14:07

Dominoes: Sep 20, 2007

Dren posted:

Dominoes, I noticed you have the idea that you should write as little code as possible. That's not quite the right idea. The right idea is to avoid reusing code, not to write the shortest possible syntactically correct code. It's often better to write a little more code for the sake of clarity. e.g. os.path.join(dir, "filename") as opposed to dir + "filename". Not to mention that in the former case you get cross platform compatibility.

I'm coming from a perspective of someone new to programming. It's easier to comprehend code that's more succinct, especially if you don't know what all of it does.

For example:

Python code:

pyqt4.QtGui.QFileDialog.getSaveFileName(os.path.join(dir, filename), QtCore.QDir.homePath()))

QFileDialog.getSaveFileName(ospj(dir, filename), homePath()))

The second example's easier to read. It's conveying the same information if you know what QFileDialog, ospj and homePath do. I don't look at short code as a goal, but given a choice, I prefer it, providing it's worth associated downsides.

# ? Jun 7, 2013 17:13

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Dominoes posted:

I'm coming from a perspective of someone new to programming. It's easier to comprehend code that's more succinct, especially if you don't know what all of it does.

For example:
Python code:
pyqt4.QtGui.QFileDialog.getSaveFileName(os.path.join(dir, filename), QtCore.QDir.homePath()))

QFileDialog.getSaveFileName(ospj(dir, filename), homePath()))
The second example's easier to read. It's conveying the same information if you know what QFileDialog, ospj and homePath do. I don't look at short code as a goal, but given a choice, I prefer it, providing it's worth associated downsides.

Python code:

from pyqt4.QtGui import QFileDialog

path = os.path.join(dir, filename)
homepath = QtCore.QDir.homePath()

QfileDialog.getSaveFileName(path, homepath)

# ? Jun 7, 2013 18:33

Dren: Jan 5, 2001; Pillbug

Dominoes posted:

I'm coming from a perspective of someone new to programming. It's easier to comprehend code that's more succinct, especially if you don't know what all of it does.

For example:
Python code:
pyqt4.QtGui.QFileDialog.getSaveFileName(os.path.join(dir, filename), QtCore.QDir.homePath()))

QFileDialog.getSaveFileName(ospj(dir, filename), homePath()))
The second example's easier to read. It's conveying the same information if you know what QFileDialog, ospj and homePath do. I don't look at short code as a goal, but given a choice, I prefer it, providing it's worth associated downsides.

Pardon my language, but you have this rear end backwards. The appropriate way to approach making code more succinct is to stick to one or two operations per line the way Thermopyle showed, not by creating custom aliases for operations so that they take up less visual space on the line.

For something like pyqt4.QtGui.QFileDialog.getSaveFileName I agree that using from to import QFileDialog is helpful if not necessary. os.path.join() --> ospj(), on the other hand, threw me for a loop. That's a fairly strange thing to do.

# ? Jun 7, 2013 20:55

Dominoes: Sep 20, 2007

Thermopyle posted:

Python code:

from pyqt4.QtGui import QFileDialog

path = os.path.join(dir, filename)
homepath = QtCore.QDir.homePath()

QfileDialog.getSaveFileName(path, homepath)

Dren posted:

Pardon my language, but you have this rear end backwards. The appropriate way to approach making code more succinct is to stick to one or two operations per line the way Thermopyle showed, not by creating custom aliases for operations so that they take up less visual space on the line.

For something like pyqt4.QtGui.QFileDialog.getSaveFileName I agree that using from to import QFileDialog is helpful if not necessary. os.path.join() --> ospj(), on the other hand, threw me for a loop. That's a fairly strange thing to do.

That makes sense.

# ? Jun 7, 2013 21:34

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

FWIW, the reason I'm ok with from pyqt4.QtGui import QFileDialog, is that to most people, most of the time, it's pretty obvious where something called QFileDialog comes from, and I'm not fuckin typing pyqt4.QtGui.QfileDialog all the time.

# ? Jun 7, 2013 22:45

Dominoes: Sep 20, 2007

Is there a trick to installing Numpy? I tried PIP, but get a list of errors, the final being "Command python setup.py egg_info failed with error code 1". Googling this brings up links to mostly Mac issues, but I'm using Windows/Python 3.

edit: Got it working with a binary from this website. Kind of surprised Pip didn't work - it's been great so far.

Dominoes fucked around with this message at 00:52 on Jun 9, 2013

# ? Jun 9, 2013 00:43

duck monster: Dec 15, 2004

MeramJert posted:

Is this a real quote because

It's not the first time it's happened to me either. An older job had me dragged before management to explain why I had "negative sloc".

Overly complicated and hard to understand code is almost always poorly conceived code.

# ? Jun 9, 2013 00:51

Cat Plus Plus: Apr 8, 2011

Dominoes posted:

Is there a trick to installing Numpy? I tried PIP, but get a list of errors, the final being "Command python setup.py egg_info failed with error code 1". Googling this brings up links to mostly Mac issues, but I'm using Windows/Python 3.

You need to have a working C and possibly Fortran compiler to get NumPy running from sources, which is what pip does. Stick to binaries if you're just a Python user (fyi there are also official packages).

# ? Jun 9, 2013 00:59

BeefofAges: Jun 5, 2004; Cry 'Havoc!', and let slip the cows of war.

Libraries that have non-Python parts are often pretty difficult to install from source. Pycrypto is another one that's difficult to install unless you download a binary.

# ? Jun 9, 2013 01:06

BigRedDot: Mar 6, 2008

Anaconda is another option. Its a free python distribution that packages numpy and alot more, sees regular updates, is self-contained on your system, and allows the creation of multiple segregated python environments.

(disclosure: I work for Continuum. We created Anaconda to solve a devops problem but we released it because we figure Python package management aggravetes other folks just as much as us.)

BigRedDot fucked around with this message at 01:17 on Jun 9, 2013

# ? Jun 9, 2013 01:14

QuarkJets: Sep 8, 2008

My preferred Windows-based Python installation is definitely PythonXY. It's made by people who want to ease the transition for scientists and engineers coming over from interpreted languages (MATLAB, IDL) and compiled languages (C++, Fortran) to Python.

It comes with a bunch of IDEs (so you can try them all and pick your favorite) plus just about every module that you could ever need for science and engineering applications (PyQt, NumPy, h5py, OpenCV, etc etc etc)

But I think that PythonXY only supports Python 2.X right now, with a goal of supporting 3.X

# ? Jun 9, 2013 03:25

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

duck monster posted:

An older job had me dragged before management to explain why I had "negative sloc".

What did you tell them, and did they accept what you had to say?

# ? Jun 9, 2013 03:28

The Gripper: Sep 14, 2004; i am winner

duck monster posted:

It's not the first time it's happened to me either. An older job had me dragged before management to explain why I had "negative sloc".

Overly complicated and hard to understand code is almost always poorly conceived code.

A friend of mine is currently in a job where his team leader uses sloc as a performance metric, giving pretty graphs straight to upper management. Currently nobody on his team is allowed to make changes to existing lines of code at all because if they do it's reported as "cosmetic changes" or "replacing existing working code" and looked on negatively, so their codebase in some parts has 5-10 copies of the same code smashed together to avoid touching existing variables/commenting anything out.

There's a particular data-heavy task that used to take ~30 seconds to complete that now takes over 8 minutes because the function is running variations on the same code multiple times.

Upper management is still "very happy" with the improvements the team has made in the number of lines of code they've written (therefore their intervention has been a success), so nobody on the team even cares that they're writing the most horrible thing. It's amazing.

Edit; I forgot the best part - in code that writes to the database each iteration of the code deletes the previous iterations from the table. By that I mean the program flow for those functions goes Write 1->Delete 1->Write 2->Delete 2->Write 3->Delete 3->Write Final->Return success. Each of those writes is the same thing, they just don't want to remove the previous writes from old code because of the above bullshit.

The Gripper fucked around with this message at 06:24 on Jun 9, 2013

# ? Jun 9, 2013 06:16

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Mercedes-Benz had an ad campaign a little while ago by telling the story that their cars are so complex, so luxurious, that they have over 20 million lines of code in them. The high number was supposed to be impressive but I remember revolting at how badly something needed to be engineered before it reached 20 million lines of code.

(Well, eventually I did a bit of research and found out that their cars contain custom copies of the Linux kernel across the diagnostics, entertainment, and navigation subsystems, and that everything was actually pretty-well separated so that errors in one wouldn't shut down the car, but that doesn't make for a good story, so...)

I also wonder if other types of engineers have similar horror stories about numbers that might be impressive to laymen being more abject horror about the complexity that would imply.

# ? Jun 9, 2013 06:31

evensevenone: May 12, 2001; Glass is a solid.

Yeah, cars have dozens of computers/microcontrollers now, most of which serve to replace a single formerly non-computer part. Much more reliable than trying to make some kind of monolithic system that does everything, especially most of them don't really need to talk to each other.

edit: that said, most of them probably aren't running linux or even an OS at all.

# ? Jun 9, 2013 07:42

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

The Gripper posted:

A friend of mine is currently in a job where his team leader uses sloc as a performance metric, giving pretty graphs straight to upper management. Currently nobody on his team is allowed to make changes to existing lines of code at all because if they do it's reported as "cosmetic changes" or "replacing existing working code" and looked on negatively, so their codebase in some parts has 5-10 copies of the same code smashed together to avoid touching existing variables/commenting anything out.

There's a particular data-heavy task that used to take ~30 seconds to complete that now takes over 8 minutes because the function is running variations on the same code multiple times.

Upper management is still "very happy" with the improvements the team has made in the number of lines of code they've written (therefore their intervention has been a success), so nobody on the team even cares that they're writing the most horrible thing. It's amazing.

Edit; I forgot the best part - in code that writes to the database each iteration of the code deletes the previous iterations from the table. By that I mean the program flow for those functions goes Write 1->Delete 1->Write 2->Delete 2->Write 3->Delete 3->Write Final->Return success. Each of those writes is the same thing, they just don't want to remove the previous writes from old code because of the above bullshit.

I hate it when goons do the whole "Somebody buy this guy an account!! :haw:

" thing, but you should buy this friend of yours an account and get him to post about his experiences in the Coding Horrors thread.

# ? Jun 9, 2013 12:43

duck monster: Dec 15, 2004

Thermopyle posted:

What did you tell them, and did they accept what you had to say?

Pretty much that SLOC is an idiot measurement for retards and that if they want me to stop refactoring and improving code, then tell me so and I'll quit and go work for some place NOT doomed by stupidity.

I kept the job, but later they folded.

# ? Jun 9, 2013 14:12

Dominoes: Sep 20, 2007

The Gripper posted:

A friend of mine is currently in a job where his team leader uses sloc as a performance metric, giving pretty graphs straight to upper management. Currently nobody on his team is allowed to make changes to existing lines of code at all because if they do it's reported as "cosmetic changes" or "replacing existing working code" and looked on negatively, so their codebase in some parts has 5-10 copies of the same code smashed together to avoid touching existing variables/commenting anything out.

There's a particular data-heavy task that used to take ~30 seconds to complete that now takes over 8 minutes because the function is running variations on the same code multiple times.

Upper management is still "very happy" with the improvements the team has made in the number of lines of code they've written (therefore their intervention has been a success), so nobody on the team even cares that they're writing the most horrible thing. It's amazing.

Edit; I forgot the best part - in code that writes to the database each iteration of the code deletes the previous iterations from the table. By that I mean the program flow for those functions goes Write 1->Delete 1->Write 2->Delete 2->Write 3->Delete 3->Write Final->Return success. Each of those writes is the same thing, they just don't want to remove the previous writes from old code because of the above bullshit.

Is this why most corporate and government computers run so slowly?

# ? Jun 9, 2013 14:52

accipter: Sep 12, 2003

Dominoes posted:

Is there a trick to installing Numpy? I tried PIP, but get a list of errors, the final being "Command python setup.py egg_info failed with error code 1". Googling this brings up links to mostly Mac issues, but I'm using Windows/Python 3.

edit: Got it working with a binary from this website. Kind of surprised Pip didn't work - it's been great so far.

I have always found this to be an excellent source for precompiled Python binaries for Windows:
http://www.lfd.uci.edu/~gohlke/pythonlibs/

# ? Jun 9, 2013 18:45

Adbot: ADBOT LOVES YOU

# ? May 24, 2024 17:27

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

accipter posted:

I have always found this to be an excellent source for precompiled Python binaries for Windows:
http://www.lfd.uci.edu/~gohlke/pythonlibs/

Yeah, I used that page a lot when I was on Windows. Compiling packages on Windows is a son of a bitch and is a large part of the reason I just run Ubuntu full time now. Things just compile with no fuss.

# ? Jun 9, 2013 19:07

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Python information and short questions megathread.

«‹›484 »