New answers tagged

0

A practical argument in favor of using the public interface is that it makes your class a bit more flexible. For example, if your property ever changes to: @property def x(self): return self._container.some_better_accessor_method() You now need to hunt all occurrences of self._container.some_accessor_method and modify them to self._container....


0

Use public API when possible. Being a public API it is not expected to change and will future-proof your private references. However, if your public API is narrow (it should be) don't hesitate to use internal access for publicly unavailable functions.


0

It depends. The benefits of using the getter/setter pattern backed by private fields vary by usage, but there are multiple, see this question and the answers, which has a number of reasons, some of which may or may not be important to you when getting or setting fields on your class. One of the main reasons to use that pattern is to prevent outside consumers ...


1

I'm not exactly clear on what you are trying to do but like you, I start wondering if there is a better way if a method has many parameters or returns a tuple of more than 2 elements. Classes in Python are great for encapsulating complexity (I never use them for polymorphism) I think it aides in understanding if you have classes that wrap the data. In ...


1

In theory - as mentioned by others - you can substitute Regex with basic string operations or different operations with various libraries. The question remains why you would want to do this as it is way more code and way more effort. I use Regex a lot - and I keep forgetting what what does basically all the time. Usually I go to RegexOne for a quick reminder....


0

I personally would use a function that returns a dictionary instead of a class in config.py, e.g. like this: import pathlib def configure(experiment_name): config = {} config["simulation_base"] = pathlib.Path("~/simulation") config["experiment_base"] = pathlib.Path("~/experiments", experiment_name) ...


5

This depends entirely how you will handle the errors. If you can't handle the errors meaningfully, don't. If your functions raise errors that can be meaningfully handled, then the errors should be meaningful. Often, no error handling is the most appropriate approach. In many contexts, just letting errors propagate can be totally acceptable. Sometimes, a ...


2

Here is the answer I already scetched in the comments: Let us start without the requirement of filters first: I would recommend not to precalculate and store the "Opening active" and "Closing active" values in the database, only the acquired, renewed and churned values per day, as well as the number of changed subscriptions per day (...


0

Passing arguments to a method, where each argument is part of self, is an immediate code smell: my_colors = self.get_my_colors(self.layers, self.color_converter_dict) If using an object, why would you not use the object? This is much cleaner, easier to understand and write: my_colors = self.get_my_colors() This part of your question is the real problem you ...


0

A command line interpreter also performs read, evaluate, print, loop functions, but I don't think there is a difference beyond REPL being the word used in the context of interpreting high level languages whereas command line interpreter shell is used in the context of a command line interface or scripting language. Both of them have to maintain internal ...


6

All user data sent to you end up in bytes. Even the strings. Taking the data as not-strings rather than as strings only means you’re taking them as something else. So long as you understand that something else as well as you understand strings there’s no problem with bytes. However, user data shouldn’t be trusted. It should be validated to ensure it only has ...


9

"I have to use regex" and "What alternatives are there?" sounds contradictory... With regular expressions as with any special-purpose tool, sure, there are alternatives to them. The case for using them becomes stronger the more your problem resembles the archteypical use case: concisely describing a small language of low to moderate ...


0

gRPC might be a good fit for this as it will be pretty performant and fairly lightweight. Alternatives include queues and even unix sockets.


0

An exception means the program is in an invalid state and cannot run forward from this point. So what to do now? The options are- Stop the program (which happens by default). Try to recover the program into a valid state. This is actually what being called "catching" and "handling" the exception. This can be done in three ways- Put some ...


0

Is catching generic exceptions that wrong an approach? Had a lot of cases (been burnt trying to catch specific ones) where we did not know what to anticipate, while the behavior would be the same for all, e.g. log and continue with execution. No. "Wrong" is a matter of context. It is wrong to catch generic exceptions when your code flow and ...


2

Actually, your question has hundreds of correct answers. because it's completely related to your application scope and design. Let's review the definition of "Best Solution" in this case. The structure of your files needs to be organized enough to avoid confusion, conflicts, and misuse and they Must Be meaningful, useful, maintainable, and reusable....


0

The best way to deal with exceptions, as a default behavior, is to simply ignore their existence. That is what exceptions are for in the first place. If you write code like this (which, let us here acknowledge, may be necessary sometimes): try: do_something() except Exception: # deal with it somehow then your logic would be just as easily written ...


2

I think this is an example of the XY problem. You are looking for an answer to the question 'Is there a better way to run sequential tests?' but you're using a framework that is built around running tests in whatever order they're discovered (i.e. the name). It seems fundamental to your task in hand that: steps are performed sequentially, iff the previous ...


3

Use an adaptation of Joe Armstrong's "Let It Crash" philosophy. (Adaptation, because the original design applies to extremely lightweight threads; here I am presenting a shortened, adapted-to-Java version.) The approach is this: Distinguish between exceptions that your code already knows how to deal with, and exceptions where your code doesn't. ...


0

My experience in languages with exceptions is that you have to assume each line may fail in order to write code that is robust to failure, a bit like when you use transactions: at the end of the function you commit your changes or let the exceptions rollback them. For example you only build and validate an object locally before adding it to a container, etc (...


0

In theory: try: do_something() except Exception: log_error("logged in this function: " + except) **throw except** Always throw it back up the chain if unable to safely handle it. If nothing else handles it, the program needs to crash. This could be a serious error. You could be reading random junk values. Users are not happy once all ...


0

Is catching generic exceptions that wrong an approach? Had a lot of cases (been burnt trying to catch specific ones) where we did not know what to anticipate, while the behavior would be the same for all, e.g. log and continue with execution. If you just want to log the exceptions, that's fine. But you're not just logging in such a case, you're handling ...


11

A lot depends on the context. A pattern like: try: do_something() except Exception: log_error() wouldn't be that unusual in certain cases. If do_something is a user-supplied callback, or a request handler, or otherwise a "unit of self-contained work" being processed, this pattern could be sensible. By the time you catch the exception here, ...


64

This code: try: do_something() except Exception: log_error() is dangerous. Not because you caught a generic Exception but because you suppressed the exception without doing any recovery or halting the system. Now the system is in an undefined state. It might be about to corrupt the database, format the hard drive, or send the president threatening ...


53

we did not know what to anticipate, while the behavior would be the same for all, e.g. log and continue with execution. To me, this is your major problem. If an exception occurs and you don't know how to handle it, you should not continue with execution because you don't know what state your system is in. Just pass it up to the next level and let that ...


Top 50 recent answers are included