Pretty good for a week and a half! I would recommend setting up a project using uv
and also adding type hints and check them with Pyright (NOT Mypy).
- 0 Posts
- 26 Comments
Instead you should just use an autoformatter. Black is good. Ruff is probably good too but I don’t have a lot of experience with it. YAPF is not good; don’t use it.
FizzyOrange@programming.devto Python@programming.dev•Python Performance: Why 'if not list' is 2x Faster Than Using len()71·12 days agoI mean, nobody uses Python for execution speed precisely because it is so slow.
FizzyOrange@programming.devto Python@programming.dev•Python in Visual Studio Code - April 2025 Release2·29 days agoYou could use uv workspaces. It means you only have one venv though.
A VSCode multi-root workspace might also work.
Yes, use them. One big advantage is if you hover something in an IDE it will show you the docstring.
If you’re writing Python you should be using Pylint (or Ruff) and it has a lint to ensure you write them.
The exception I usually make is for class member variables because it’s super weird that the docstring comes after the variable. I think that’s very confusing for people reading the code so I normally just use comments instead.
FizzyOrange@programming.devto Game Development@programming.dev•Is Unreal Engine 5 still too advanced for PC games?3·2 months agoIt literally says in the article. Hardware IO controllers that handle compression. I guess this is related to DirectStorage but it doesn’t seem like that takes advantage of dedicated hardware on PC (because as far as I know it doesn’t exist) and apparently only a handful of games actually use it.
They also have integrated RAM (like Apple M-series laptops).
FizzyOrange@programming.devto Game Development@programming.dev•Is Unreal Engine 5 still too advanced for PC games?311·2 months agoNot true. It takes advantage of hardware features that are available on consoles but not on PC. That isn’t laziness.
it does a great job yelling at me to keep methods short and simple
Yes style things like that are what I would consider trivial. I also think those are actively bad lints. Yes methods should be short in general, but making it a hard enforced limit means you end up getting sidetracked by refactoring when you only wanted to add one line to a method.
Yeah I tried Ruff about a year ago and it only had really trivial lints so it wasn’t a good replacement for Pylint. Is it on par yet?
Yeah Pylint catches this. If you aren’t using Pylint you are writing bad Python.
FizzyOrange@programming.devto Python@programming.dev•A year of uv: pros, cons, and should you migrate3·3 months agoI don’t know why you think maintaining uv will require magical superpowers. Writing it in the first place requires a ton of work, sure. But that seems to be mostly done.
FizzyOrange@programming.devto Python@programming.dev•A year of uv: pros, cons, and should you migrate31·3 months agoIt literally doesn’t matter how long it takes.
Found the Python dev…
FizzyOrange@programming.devto Python@programming.dev•A year of uv: pros, cons, and should you migrate11·3 months agoWell I can think of a couple:
- It makes heavy use of caching and occasionally that goes wrong and give confusing errors until you think to
uv clean
- It’s an extra step to install
uv
which you may not want to impose on users, or CI. - Astral might die.
But it’s sooooo much better than the official tooling (and the competition like Poetry) that the conclusion is still the same: you should definitely use it.
- It makes heavy use of caching and occasionally that goes wrong and give confusing errors until you think to
FizzyOrange@programming.devto Python@programming.dev•A year of uv: pros, cons, and should you migrate4·3 months agoThe biggest praise i have is, it follows the UNIX philosophy, do one thing and do it well.
That isn’t a pro on its own, and it’s also a very wooly rule. Uv does one thing and it does it well - Python project management.
the issue comes down to resources required to maintain a super complex thing
They seem to be managing fine. I guess having a company back it is enough. But that is also probably my biggest worry about it - what if Astral goes away (which given their apparent lack of business model I suspect they eventually will)? Hopefully uv is popular enough by that point it won’t die.
I DONT GIVE TWO SHIATS IF ITS FASTER
It’s literally 10x faster. I’m not sure what kind of person wouldn’t care about that.
FizzyOrange@programming.devto Python@programming.dev•Critique This! A Simple Qt Dock Widget which enables the whole widget to be 'folded' to use less screen space2·3 months agoWell… the else condition (
bar
) needs to be covered. I haven’t used branch coverage tools in Python but in any sane language you cover the actual semantics, not the lines. It shouldn’t make any difference if you write your code on one line, or with ternary expressions, or whatever.
FizzyOrange@programming.devto Python@programming.dev•Critique This! A Simple Qt Dock Widget which enables the whole widget to be 'folded' to use less screen space1·3 months agoIf you branch coverage tool can’t handle branches on the same line I would suggest you use a different one! Does it handle
if foo or bar
?Will not see the value that gets past into self.float_button.setIcon
Uhm, yes you will? Just step into the function.
FizzyOrange@programming.devto Python@programming.dev•Critique This! A Simple Qt Dock Widget which enables the whole widget to be 'folded' to use less screen space3·3 months agoEasily above average code for Python. I’m going to pick on one method:
def _set_float_icon(self, is_floating: bool): """ set the float icon depending on the status of the parent dock widget """ if is_floating: self.float_button.setIcon(self.icon_dock) else: self.float_button.setIcon(self.icon_float)
First, Python does have ternary expressions so you can
self.float_button.setIcon(self.icon_dock if is_floating else self.icon_float)
Second, what does this code do?
foo._set_float_icon(true)
Kind of surprising that it sets the icon to
icon_dock
right? There are two easy fixes:- Use
*, is_floating: bool
so you have to name the parameter when you call it. - I’d probably rename it to
_update_float_icon()
or something.
Also use Black or Ruff to auto-format your code (it’s pretty well formatted already but those will still improve it and for zero effort).
- Use
FizzyOrange@programming.devto Python@programming.dev•Astral is building a new static type checker for Python, from scratch, in Rust5·3 months agoBut don’t you loose polymorphism?
No. You’ll have to be more specific about what kind of polymorphism you mean (it’s an overloaded term), but you can have type unions, like
int | str
.Your points 1-3 are handled by running the code and reading the error messages, if any
Not unless you have ridiculously exhaustive tests, which you definitely don’t. And running tests is still slower than your editor telling you of your mistake immediately.
I probably didn’t explain 4-6 well enough if you haven’t actually ever used static types.
They make it easier to navigate because your IDE now understands your code and you can do things like “find all references”, and “go to definition”. With static types you can e.g. ctrl-click on
mystruct.myfield
and it will go straight to the definition ofmyfield
.They make the code easier to understand because knowing the types of variables tells you a lot of information about what they are and how to use them. You’ll often see in untyped code people add comments saying what type things are anyway.
Refactoring is easier because your IDE understands your code, so you can do things like renaming variables and moving code and it will update all the things it needs to correctly. Refactoring is also one of those areas where it tends to catch a lot of mistakes. E.g. if you change the type of something or the parameters of a function, it’s very easily to miss one place where it was used.
I don’t think “you need to learn it” really counts as slowing down development. It’s not that hard anyway.
I can understand the appeal for enterprise code but that kind of project seems doomed to go against the Zen of Python anyways, so it’s probably not the best language for that.
It’s probably best not to use Python for anything, but here we are.
I will grant that data science is probably one of the very few areas where you may not want to bother, since I would imagine most of your code is run exactly once. So that might explain why you don’t see it as worthwhile. For code that is long-lived it is very very obviously worth it.
FizzyOrange@programming.devto Python@programming.dev•Astral is building a new static type checker for Python, from scratch, in Rust3·3 months agoJust in case that’s a genuine question, the reasons people like static types are:
- Catch more bugs.
- Catches bugs earlier (while you are writing the code). This is sometimes called “shift left”.
- Fewer tests needed.
- Code is easier to understand.
- Code is easier to navigate.
- Refactoring is much easier.
- Development speed is faster (due to the above points).
Often people say it slows development down but it’s actually the opposite. Especially for large projects or ones involving multiple people.
The only downside really is that sometimes the types can get more complicated than they’re worth, but in that case you have an escape hatch via the
Any
type.
TL;DR, big-O ignores the constant factor. If you already know what that means you don’t need to read this…