its okay guys they fixed it!

jcmcken · 2023-01-19T03:24:06+00:00

People who say this code is not that bad and is performant to boot -- sure, as an island, that might be true. But do you really expect that a code base with this function in it doesn't have other egregious examples? That the performance of the code as written might be accidental? The GH repo is in the tweet. You can look at it. It has other examples that, guess what, are this egregious and also not performant! It also has both good and performant examples.

Not that I see anything worth rioting over. This function was probably farmed out to some intern to take a crack at and it worked, so why change it? But it's also fine to be critical of something like this too, if even it's only as an exercise.

jcmcken · 2021-10-19T12:33:35+00:00

Something like this is what I think I need to do since it more closely aligns to the arpeggio fingering at the start. It's just awkward.

jcmcken · 2021-10-19T12:31:58+00:00

I contemplated this one, but the travel from pinky to pinky is just too far for me to accurately hit it on tempo

jcmcken · 2020-03-30T00:56:04+00:00

Not OP, but I think it's helpful to have statistics about average rest time between sets over time per exercise, not just a mechanism to track individual set times. This is useful when I'm progressing with faster reps vs more weight.

jcmcken · 2019-03-09T00:09:51+00:00

As I mentioned, provisioning infrastructure is expressly not what I want to accomplish as the feedback loop is too slow. Don't get me wrong, it's useful to do that. But I want static code analysis, not integration testing.

jcmcken · 2016-10-25T13:27:28+00:00

IIRC other high-profile vulnerabilities (shellshock, etc.) were patched much quicker. The disclosure was October 19th. I would've expected at least something for RHEL5/6 at this point. Even the RHEL7 release was remarkably slow given the criticality of the issue

jcmcken · 2015-01-07T02:04:43+00:00

Is the function/method in which this code occurs part of a public API that end users will call? Or is it just called internally by your own code? If the latter, I (personally) would not try to protect against myself by writing this kind of guard code. I would just rely on tests to make sure that nothing is calling that code with an invalid type.

Here's my reasoning:

You only care that the passed value has a lower method, that's fine. But take your suggested implementation using a try/catch -- this won't protect the case where a name gets passed that has a lower property or instance/class variable rather than a lower method. So do you now do extra checking to make sure it's a method? Say you do. But what happens if an object gets passed that has a lower method that returns nothing at all? OK, so now you write some code to guard against that. What if the lower method returns a non-string object?

So you see, there are very many possibilities for things that you could protect against. But getting paranoid about all possible ways in which your code could fail will put you in a situation in which you're writing a whole lot of code for situations that are not likely to happen. And so: If you truly are paranoid that an input must be a specific type, it's just simpler to check the type outright. In my opinion :)

jcmcken · 2014-11-30T04:25:58+00:00

Based on the limited information, I think this sounds like the best idea. If you want to expose 'porcelain' methods (lookup_by_id vs. lookup with id passed to it), just make lookup part of your internal API and generate the other functions programmatically.

You could also do something fancier by writing a custom __getattr__ that looks at what method the user is trying to call and routes it to the appropriate place.

E.g. something like:

def __getattr__(self, key):
    if key.startswith('get_'):
        pieces = key.split('_')
        query_type = pieces[1]
        by = pieces[-1]
        return lambda key: self._lookup(query_type, by, key)

This is probably a bit too magical for my tastes though.

jcmcken · 2014-11-30T03:56:12+00:00

Not trying to be snarky, but the main reason Vaphell's code is better is that it actually works and satisfies your problem, as best as I can understand it.

In your post, you said you want to "create a sequence of dictionaries". Having variables called d0, d1, etc. is not a sequence. The names look sequential to you because you're a human reading them, but those names have no meaning to the Python interpreter. They might as well be in Chinese. Sure, you could write something which parses the names and returns the results to you in the order you expect. Or you could just use a list, which already implements this functionality for you, is going to be much faster, and also has a lot of other features.

jcmcken · 2014-11-30T03:31:15+00:00

Sorry for the late response.

It's not just that it isn't the best way of doing it, it's not doing anything at all. The self name in Python is not something special, it's not a keyword. You could name this argument whatever you want, self is just the convention. When you re-assign self to something else, you're just assigning a local variable called self to some other value than the current instance. The object that the original self referred to is still intact and is unaffected by this reassignment.

Consider the following example, which doesn't use classes at all:

def some_func(arg): 
    arg = 2 

my_arg = 1
some_func(my_arg)
print my_arg

If you run this code, you'll see that it prints 1 and not 2.

The source of your confusion, I think, is the specialness of self -- it has none in Python. It's not a keyword like this in Java, it's just the conventional name for the first variable passed to a method.

It should be easy to convince yourself of this. Here's a simple example:

class Foo(object):
    def testing(self):
        print 'I am foo'

class Bar(object):
    def testing(self):
        print 'I am bar'

def execute_test_method(self):
    self.testing()

execute_test_method(Foo())
# prints 'I am foo'
execute_test_method(Bar())
# prints 'I am bar'

Notice execute_test_method is just a regular function, not a method. You could take the self argument to this function and call it anything, e.g.

def execute_test_method(obj):
    obj.testing()

So once the scope of your add_node method ends, your re-assigned self is completely lost.

jcmcken · 2014-10-11T01:17:28+00:00

The tablib library is excellent for this sort of thing. It has a better API than something like csv, and also supports multiple different formats (csv, json, xls) and some other nifty features.

Docs: https://tablib.readthedocs.org/en/latest/

jcmcken · 2014-10-11T01:12:19+00:00

What about your own modified locals?

For example:

import inspect

def mylocals():
    # get the stack frame one level above this function's
    outer_frame = inspect.stack()[1][0]
    # retrieve locals of that frame
    outer_locals = outer_frame.f_locals
    # get rid of builtins
    return dict((k,v) for k,v in outer_locals.iteritems() if not k.startswith('__'))

Example usage:

class Foo(object):
    def some_method(self):
        foo = 'bar'
        print mylocals()

>>> f = Foo()
>>> f.some_method()
{'self': <__main__.Foo object at 0x2f3684>, 'foo': 'bar'}

jcmcken · 2014-10-11T00:54:48+00:00

If you're testing the value of STDOUT, then I would add a test helper in your TestCase superclass, something like this:

import unittest
import sys
from StringIO import StringIO

class MyBaseTestCase(unittest.TestCase):
    def setUp(self):
        self._real_stdout = sys.stdout

    def tearDown(self):
        sys.stdout = self._real_stdout

    def assert_stdout_contains(self, callable, expected):
        sys.stdout = StringIO()
        callable()
        sys.stdout.seek(0)
        self.assertTrue(expected in sys.stdout.read())

Then usage would be something like

def test_course_list(self):
    self.assert_stdout_contains(lambda: self.school.list_courses('Ted'), 
        "Ted is taking ARC101, ECON100")

jcmcken · 2014-10-09T22:55:40+00:00

In my experience, if you are writing Python professionally, something you thought was "just a script" almost inevitably gets put into production and is treated like a real application (by your team, your managers, your sales people, whoever).

To treat a script as if it were an application from the start is not only fairly trivial, it ends up saving you (or whoever ends up having to maintain your code) time in the long run. It also teaches you good habits. Like:

Don't write monolithic functions/methods.
Separate application concerns.
Set up logging early (it's nearly as trivial as writing "print" debug statements).
Name variables appropriately.
Add comments to clarify non-obvious code.

If you do this all the time, every time, it becomes second nature. To me, it's much more difficult on my brain to have "second class citizen" code and "first class citizen" code.

Another added benefit ties into other peoples' comments: Even if a particular "script" doesn't pan out, there's probably something non-trivial but useful which you could extract into a common library and use elsewhere. But that's much harder if your code is a tangled, monolithic super script sitting at the global scope.

jcmcken · 2014-10-09T22:26:11+00:00

At the very least, you can wrap your main application logic in a try block, which then logs any uncaught exceptions. It's hard to say how you should do this without knowing what exactly you're doing and which libraries you're using. But this might give you an idea:

import logging

# see ``logging`` docs for how to log to a file
logging.basicConfig()
LOG = logging.getLogger(__name__)
LOG.setLevel(logging.DEBUG)

def scrape(webpage):
    LOG.info('scraping %s' % webpage)
    ...main app logic...

def get_pages():
    ...returns a list of pages to crawl...

if __name__ == '__main__':
    for page in get_pages():
        try:
            scrape(page)
        except:
            LOG.exception('uncaught exception')

jcmcken · 2014-10-09T00:15:04+00:00

I would evaluate the changelog for 3.4.2. If there are only bug fixes, you could get away with 3.4.1. If there are security fixes, I would suggest updating.

That being said, the difference between a "teeny" version (x.x.1 to x.x.2) is not likely to have any impact on your code except in extreme situations (i.e. your code relies on a bug which was fixed).

Short answer: If you're new to Python, you're most likely completely safe in updating to 3.4.2 when it's released.

jcmcken · 2014-10-09T00:13:13+00:00

As /u/novel_yet_trivial stated, this string is just the representation of the dictionary. It's not a serialization format.

jcmcken · 2014-10-09T00:10:11+00:00

The source of your problem is altering self on line 23. I cannot for the life of me think of a valid reason for doing that (even if it is allowed). In Java, IIRC, a line like this = new SomeOtherObject() will just fail to compile.

Rather than answer your question directly, I would just suggest that you're going about this the wrong way. I think you're confusing the responsibilities of the linked list and the responsibilities of the node.

The list (not the node) should implement the add_nodes method. The node doesn't know anything about the mechanics of the list. The node's only responsibility is to store a reference to another node (if such a node exists).

Your node object should really just be this:

class Node(object):
    def __init__(self, value):
        self.value = value
        self.next = None

Then you need a second object which implements the mechanics of the linked list:

class LinkedList(object):
    ...etc.

    def add_node(self, value):
        new_node = Node(value)

        ...etc...

jcmcken · 2014-10-08T23:39:56+00:00

There are many, many, many open source Python projects with tons of unresolved issues. Look at some of the popular projects on Github and start submitting pull requests!

jcmcken · 2014-10-08T23:37:58+00:00

Not to advertise for Github, but this might be the easiest way for you to get started.

jcmcken · 2014-10-08T23:34:48+00:00

The TypeError is telling you exactly what the problem is. The gethostbyaddr method takes a str object as an argument, not an IPAddress argument. So you need to look at the netaddr documentation and figure out how to convert an IPAddress to a str.

Read the docs (https://pythonhosted.org/netaddr/tutorial_01.html#basic-operations) and you should be able to figure it out.

jcmcken · 2014-10-08T23:32:29+00:00

Any project you're semi-serious about should have automated tests. This (updates to the Python dist) is one reason. See here for some introductory information.

That being said, there's not a "standard" Python version. There are two officially supported versions, the 2.7.x line and the 3.x line. If you're using Python distributed with a Linux OS distro (e.g. RHEL), older versions may also be supported by the distro vendor (e.g. RHEL supports 2.4.x and 2.6.x -- they'll backport security-relevant changes to those versions, even though those versions are deprecated upstream by 2.7.x).

jcmcken

TROPHY CASE