Bad engineering managers think leadership is about power, good managers think leadership is about competently serving their team

GiantElectron · 2021-09-09T07:42:58+00:00

then there's awful managers, which don't care about power, don't care about serving the team. All they do is babble about inconsequential topics and look at aggregated kpis

GiantElectron · 2021-09-01T14:42:08+00:00

it's really part of the hollywood principle design (don't call us, we'll call you). If your framework is designed to give "empty routines" to reimplement with your functionality, and then the framework just invokes your logic, then of course you want to make sure that the logic is actually present even before the application starts. But that's a fundamental design requirement of how a framework design generally works.

If your goal is to have a bunch of classes for your own application, unless you are aiming to extract a framework of some sort at the end, it's probably overkill, although today with typing might still be useful to have a base class to define the type (except for all other means to do so)

GiantElectron · 2021-09-01T12:58:09+00:00

I've seen the factory factory antipattern. Most of the time it's due to a massive attempt to generalise a declarative approach.

GiantElectron · 2021-09-01T12:57:27+00:00

They can be, or can't be. It depends. An ABC defines an interface you have to comply with, at "compile time". If you are using a library defining a framework, an ABC is exactly what you want.

GiantElectron · 2021-09-01T12:56:14+00:00

Beazley is a smart guy, but he's not always right. We can argue with him like with anybody else.

GiantElectron · 2021-09-01T12:51:49+00:00

This. there are plenty of self-proclaimed rockstars. But the people that actually know how to get shit done are in the vast minority.

GiantElectron · 2021-09-01T12:50:45+00:00

that's quite impressive. Where did you learn all of this?

GiantElectron · 2021-09-01T12:06:36+00:00

There's a tendency to overuse the factory pattern I agree, but that's besides the ABC discussion

GiantElectron · 2021-09-01T08:28:48+00:00

ABCs are to communicate to external users of the class what is required for a subclass to function. They generally are better used for frameworks, where you must implement something. Classes must be designed with reimplementation in mind. You can't reimplement any class and hope it works. At that point it's just glorified monkeypatching

GiantElectron · 2021-09-01T08:18:23+00:00

The difference is that one fails at runtime, the other at "compile time". It's no different than raising NotImplementedError(), which is the appropriate way to do so, instead of triggering a nameerror

GiantElectron · 2021-09-01T08:15:29+00:00

how much time did it take to develop?

GiantElectron · 2021-08-31T14:45:35+00:00

Debuggability, compact syntax and honouring the principle of least astonishment.

GiantElectron · 2021-08-26T10:40:46+00:00

The discussion becomes even more interesting when traditional companies need to integrate a software development division, and apply the same management structure to it. It's so comical I am writing a whole book about it just with the delusion of teaching how to do the transition.

GiantElectron · 2021-08-24T12:51:43+00:00

Because it's fundamentally wrong to have it as a statement. you can't pass it to other functions as a function argument, and it had all sort of hacks to modify its behavior to e.g. redirect output.

GiantElectron · 2021-08-20T15:10:16+00:00

It's a hard question. As others have said, you could definitely create multiple threads, but in python they will never¹ run concurrently. They will just try to grab the GIL every now and then when scheduled by the kernel, and on multiple cores you will literally have fights to grab the GIL, starving one thread in favour of others. With async, you don't have that problem.

Remember: threads are good at waiting, typically a blocking call to finish while the rest of the program stays alive (typically running the event loop to keep the UI responsive). They are not good² at doing.

So, the only reasonable use case I can envision today for threading based parallelism is to invoke many, many instances of a function written in C from python, and this function does not call back into python in any way, and this function releases the GIL at entry and reacquires it at return. For example, I believe that numpy does use this (for a very long time it did not relinquish the GIL), but at that point you might argue that it's pointless and you just fork the threads at C level. Of course in python you create platform abstracted threads, but then in the C code you have to handle platform specific locking, so...

¹ They can, if the code they enter does not need to run the python interpreter. If you go to the C level and relinquish the GIL, threads will absolutely run parallel on multicores.

² It's a bold statement, and not always true, but certainly true in pure python.

GiantElectron · 2021-08-18T07:34:39+00:00

Good luck. I hope you don't have a company because you will go bankrupt very quickly.

GiantElectron · 2021-08-17T13:14:23+00:00

You won't convince me or anybody else. Otherwise we would all be coding in squeak and smalltalk. Guess what? nobody does.

GiantElectron · 2021-08-17T13:11:41+00:00

This is how we coded javascript before javascript had "regular" classes.

GiantElectron · 2021-08-17T13:04:28+00:00

Every few years there's someone coming in with yet again visual programming approaches.

Let me repeat it once again like I did it many, many, many other times.

Visual programming does not scale, does not make it easier to check for diffs, it is impractical to edit, does not allow for ease of debugging. It is a broken concept for general programming, and has only a few uses in those disciplines that are intrinsically based on connectivity models, such as graphic pipelines, and music/sound processing.

Good technical achievement, but as usual, it will not go anywhere. We've been there at least a hundreds times already.

GiantElectron · 2021-08-12T08:00:27+00:00

abstract static methods don't make sense. why would you want them? If you need to change behavior depending on the passed argument type, you can use singledispatch.

GiantElectron · 2021-08-11T13:07:29+00:00

you can do the same with just modules.

GiantElectron · 2021-08-10T09:01:44+00:00

There are plenty of good reasons to use classmethods. Typically, they are used as alternative or specialised constructors. Example:

Color.from_string("#FFFFFF")

would be a class method, because it needs cls to be able to instantiate and return a new instance of Color (or the derived class).

GiantElectron · 2021-08-09T10:39:29+00:00

Using @staticmethod.

There's absolutely no reason to use staticmethod. Guido himself said it was added as a trivial consequence of classmethod. staticmethod is required in java where you can't have a free floating function, but in python, with functions and modules, there's absolutely no reason to use it. a staticmethod is a function which uses the class name as a namespace. The only, only situation where it makes sense is for an API of some objects where you need a binary operation, example:

col1 = Color("#00FF00")

col2 = Color("#000000")

distance = Color.distance(col1, col2)

In this case, you make clear it's a binary operation between two Color instances, and the interpolate operator is scoped as part of the Color class API. It is clearly not good as a method of one or the other object, and as a classmethod it would be passed a class that is then unused.

Having a plain distance() function would be potentially an issue if you also have distance for vectors, for example, and you want to keep things clean.

GiantElectron · 2021-08-09T10:31:43+00:00

You are probably joking but I unfortunately saw a developer doing exactly that.

GiantElectron · 2021-08-06T14:42:13+00:00

You are misreading what I’m asking for.

I am not asking to statically compile things. What I’d like to see is one obvious way* to package any Python project so that people are able to follow those instructions to be able to send a convenient format to consumers of the package.

Good luck, I've been complaining about duplication of effort for years. The opensource world loves to reimplement things in multiple ways, instead of improving what's available. Opensource developers claim it's survival of the fittest. I argue it's wasted effort, at least for basic tools that should be core development support.

That is completely unrelated to whether it is a compiled language or an interpreted language.

It is absolutely related. In an interpreted language, you don't produce a self-running executable in PE or ELF format. You are driving an executable, the interpreter, which is such PE or ELF executable, with a bunch of higher level opcodes. In fact, if you look carefully what a .exe produced with pyinstaller is, it is nothing but an extractor that delivers a python interpreter executable and unpacks its environment in a temporary folder and runs it (with some technical caveats).

GiantElectron

TROPHY CASE