Tag Info

Hot answers tagged

8

I would have your objects implement interfaces like ICharacter, IEnemy, IHorizontalMover. The relevant design guideline is known as Favor Composition over Inheritance, and it should allow your design to be more flexible. One difference is that interfaces tend to specify behavior and any given object can implement as much or as little as it needs. If you ...


7

Use the ast module import ast def extract_return(file, fname): for x in ast.walk(ast.parse(open(file).read())): if ...


6

Short answer It was a bug. With Python 3, the ceil and floor return integers (see also delnan's comment). Some details are here: http://www.afpy.org/doc/python/2.7/whatsnew/2.6.html Why it should be an integer The fact that integer 8 is also a real number does mean that we should return a floating point value after doing floor(8.2), exactly because we ...


6

When the HTTP request is completed, it will return some data, and the model gets updated by the responsible part of your system. Then raise an event which tells everyone who subscribed to it "new data has arrived", but do not pass the actual data in this event, only the relevant information for the subscribers which part of the model has changed. The event ...


6

At first glance it sounds reasonable to use inheritance to separate different types of entities: this is the "real-world" approach to OOAD that most colleges teach in CS101. In other words, classes are named based on real-world objects that we can see: desk, dresser, door, etc. However, that makes little sense in the context of a video game. There are ...


5

What you could do, is factor out the filtering and breaking into a generator, which can be really handy if that logic is used multiple times, with different processing in the middle. def relevant_items(items): for item in items: # logic to continue or break/return goes here yield item def process_many_items(items): for item in ...


5

Given a Python class which will be instantiated only once, i.e. there will be only one object of the class. I was wondering in which cases it makes sense to create a single class instance instead of working directly with the class instead. So it's this: class Singleton: '''don't bother instantiating me''' clsvar1 = 'foo' @classmethod ...


4

I would suggest defining your common properties in the base class and simply assign them as such in the constructor for your child class. I would also put sanity checks ensuring that your necessary properties are set before you can use a given character on your field/map. You shouldn't need to pass all of the properties to the constructor as this will ...


4

Because 8 is a perfectly good floating point number. Let's generalize the concept of math.ceil to include a "digits" parameter; that is, you get to choose the number of digits after the decimal point that you want to keep. This isn't as far-fetched as it sounds; the Round function already has this ability. By this new definition, Math.Ceil(12.755, 2) ...


4

How is your code used by developers? In other words, what exactly do they do to determine which arguments should be used and how? If they rely on documentation automatically generated from your code, and the generator has no clue what to do with **kwargs, this is indeed problematic. Instead of finding the list of arguments and their meaning in the ...


3

You might look into the Reader or State monads; they can be used for sharing data between (pure, monadic) functions, without resorting to explicit parameters or the like. There's a tutorial series on F# for fun and profit about the State monad (AKA Workflow in F# parlence). I also gave a description of it in this SO answer that appears to be fairly ...


2

You can use enumerated types instead of strings, and keep your implementation. Or, if you don't mind using exceptions you can write: try: for item in items: if shall_process(item): process_the_item(item) except StopIteration: pass Here, shall_process returns a boolean and can throw an exception to exit the iteration.


2

Why is IO impure? Because it may return different values at different times. There is a dependency on time that must be accounted for, one way or another. This is even more crucial with lazy evaluation. Consider the following program: main = do putStrLn "Please enter your name" name <- getLine putStrLn $ "Hello, " ++ name Without ...


2

It's hard to be sure exactly what you mean by "purely academic", but I think the answer is mostly "no". As explained in Tackling the Awkward Squad by Simon Peyton Jones (strongly recommended reading!), monadic I/O was meant to solve real problems with the way Haskell used to handle I/O. Read the example of the server with Requests and Responses, which I ...


2

I would leave them completely separate. Services and servers (notice I carefully separate the abstracted hardware and the abstracted software) are separate things. I would let each Service object have one Remote (or VMInstance or whatever you want to call it) property, possibly passed in a contructor, that could potentially be changeable (service ...


2

I don't see the problem with your approach. I think you are almost there. If you change your generator to yield None when there is nothing to return, then you can simply test for that. See the following example: #!/usr/bin/python import sys import time tailpath = "./tailfile" fd = open(tailpath) def tail_follow(file): while True: line = ...


2

I was wondering in which cases it makes sense to create a single class instance instead of working directly with the class instead. This is one of those things that will cause a religious war if you get into it to much. But in general a practice that I have seen many times is that class methods should concern themselves only with creating instances of ...


2

I'd keep the data versioned separately. I don't know what your gradual data change workflow is. You could use version control or just named directories, with some sort of de-duplication or plainly. VCSs are usually a poor choice for large binary data. This way you can always check out the data independently of code, and check in code independently of the ...


2

It could be worse, but it's overly coupled, and a sign your do_stuff is too big. I would only do it if I needed the extra performance, and couldn't think of any other way. You didn't give us much to go on, but usually problems like that can be much more cleanly decomposed in the following way: common = [my_object.get_common() for my_object in all_objects] ...


2

Since you wrote in your comment you want to make the output of the unchanged program stable when it is not changed between two runs, you already excluded "accidental changes to module variables" - without any changes, there can be no "accidental changes". The SO link you posted in your question mentioned how to initialize Python's hash seed to a fixed ...


1

I would add a bunch of unit tests for the individual modules and use something like Jenkins to compile and run the tests every time you make code changes. If you are finding variations when running, this should help you narrow it down so that you can change module logic to ensure repeatability.


1

I'd say that mutation inside a list comprehension looks unexpected and thus can be more error prone. On a code review I'd ask to rewrite it using an explicit loop which is typical for mutation. Also, you don't need [element for element in my_set] to transform a set to a list, list(my_set) suffices. You can also just iterate over a set as you'd do over a ...


1

It's better (and less confusing) to have the empty [0] placeholder at the beginning of the array so that you can just plug the month directly into the array indexer, than it is to start January at month 0 and have to perform a bit of conversion math to get the correct array index each time. Sensible date implementations should not allow a month zero. Note ...


1

Instead of trying to figure out the exact class hierarchy you need, how about letting it grow organically? The big advantage of inheritance is avoiding repetition. When you put functionality in a base class, you can share that functionality among many different classes without having to put the same code in each one. So just inherit from Object, write ...


1

I find that naming intermediate results often provides semantic clarity to the humans reading it later, even if it doesn't change the end result. Like focusing a lens, sometimes the proper point is easiest to see by taking it to extremes then backing off. The extreme version of explicitness is: def travel(): yellow_cab_sequence = [call_yellow_cab, ...


1

In Python, we have packages and modules. A module is "just" a .py file, and a package is "just" a directory with an __init__.py file (which is often empty). You can import any package or module which is in a directory listed in sys.path, modules within such a package, subpackages within such a package, modules within such subpackages, and so on. While you ...


1

In Python, switching between an attribute and a property isn't a breaking change, it doesn't alter the interface at all, so there's not much point to an auto-property system. You can start with a public attribute, then later on switch to a property without needing to alter the code that interfaces with your class at all. This is also why defining get_ and ...


1

The functionality for that is located in the pcap API. The implementation of that is in library libpcap for Unix/Linux and library Winpcap for Windows. There are Python wrappers, e.g. pypcap, to access those libraries. Depending on your system, you might need 'elevated privileges' (root/administrator) to gain access to packet data. Wireshark is built on ...


1

The problem is well known and the keyword you may be searching for is pooling. The idea is that opening a connection is a complicated task: is usually requires reaching the server, doing authentication, checking the rights, auditing, etc. On the other hand, preserving the same connection through the application by either storing it in a static variable or ...



Only top voted, non community-wiki answers of a minimum length are eligible