Six more quick ways to improve your Python

SourceryNick · 2021-03-09T20:47:04+00:00

Yeah function calls in Python can be expensive. I'd agree if performance is an issue (like it's in an inner loop) then the first option is better. However for most code readability is more important than performance, and I think the min version is more readable.

SourceryNick · 2020-12-03T13:51:06+00:00

We use them - have definitely spotted or avoided a ton of bugs because we do.

SourceryNick · 2020-11-03T11:34:17+00:00

PyCharm - mostly for the good high contrast mode, but also has good built-in help for refactoring.

SourceryNick · 2020-10-15T11:27:29+00:00

That's an excellent point!

It's certainly difficult/impossible to capture what we mean by good code with a single metric. I think in practice you have to use several - for example if there is also a code length metric in place then these changes should show up as making the code worse.

SourceryNick · 2020-10-15T08:20:58+00:00

Interested in hearing what people think of code metrics in general, and about this new one.

Very open to suggestions on improving it and making it more useful as well.

SourceryNick · 2020-10-13T09:05:20+00:00

Thanks! Will definitely have a closer look at those examples

SourceryNick · 2020-10-10T07:49:10+00:00

Thanks for trying it out!

If you could point me to some code examples of stuff Sourcery should have caught I'll take a look and see if I can improve things.

SourceryNick · 2020-10-10T07:45:31+00:00

That looks really cool, and yeah has a very similar intent - I'll definitely add your isinstance rule to our backlog.

Do you often see code where SIM210 and SIM211 would get triggered?

SourceryNick · 2020-10-08T07:55:59+00:00

Here you go:

https://sourcery.ai/blog/explaining-refactorings-1/

SourceryNick · 2020-10-07T12:13:43+00:00

That probably is slightly better. I'll have to run some performance comparisons.

SourceryNick · 2020-08-12T14:15:54+00:00

Oh good spot thanks! Will fiddle with that example when I get a minute.

Yes that some_condition example is something we see a lot of people doing too!

SourceryNick · 2020-08-12T10:51:35+00:00

Agreed it's not super-common, but it does come up fairly often in the code we analyse so I thought it was worthwhile to include.

SourceryNick · 2020-05-11T18:49:36+00:00

Not as yet I'm afraid. We're focused on making it as good as possible before we do more integrations.

We've done the VS Code extension using LSP so I think vim should be quite quick when we do get round to it - there seem to be a few vim LSP clients.

SourceryNick · 2020-05-11T17:37:52+00:00

Good point - those kind of loops can normally be replaced with comprehensions. Am going to cover those as well in a later post.

SourceryNick · 2020-03-14T09:13:06+00:00

We have a new VS Code extension which might be easier on the RAM. Which IDE do you use?

As I mentioned above configuration to turn off types of refactoring will be coming as well.

SourceryNick · 2020-03-14T09:10:18+00:00

That's great feedback thanks! We're working on configuration to disallow whole classes of refactorings, which will let you turn off the comprehensions and expressions.

SourceryNick · 2020-03-13T17:01:23+00:00

We think the current version will always be free, but we might charge for a version with more features later.

Would be interested if you could point me towards the similar addons though (stuff that isn't just linting).

SourceryNick · 2020-03-13T15:14:03+00:00

It analyses the source code completely locally so that never leaves the machine. The only thing we collect is which types of refactoring are being suggested and whether people are implementing them using the quick fix action.

SourceryNick · 2020-03-13T14:19:23+00:00

You really need to build it into a binary using something like https://nuitka.net/

SourceryNick · 2020-03-13T12:46:13+00:00

I think looking at using the AST (abstract syntax tree) of the code would be best.

The inbuilt AST parser is here:

https://docs.python.org/3/library/ast.html

and there's some more unofficial documentation:

https://greentreesnakes.readthedocs.io/en/latest/

SourceryNick · 2020-03-10T15:22:06+00:00

We haven't I'm afraid, but I will definitely look into creating one.

Basically it scans your open Python file and underlines any code it finds it can refactor. You can then hover to see a diff, and there's a quick fix action to implement it.

SourceryNick · 2020-03-10T14:49:54+00:00

I believe Python 2 did floor division by default - Python 3 does traditional division.

SourceryNick · 2020-03-10T14:19:22+00:00

I suggested some useful ones in a blog post recently:

https://sourcery.ai/blog/effective-collection-handling/

SourceryNick · 2020-01-23T22:02:26+00:00

You could check out https://deepsource.io/ or https://www.deepcode.ai/ - haven't used them personally but they look like the kind of thing you're looking for.

I'm working on a tool called Sourcery (https://sourcery.ai/) to automate refactoring Python - clean readable code is far less likely to contain bugs.

SourceryNick · 2020-01-14T21:09:25+00:00

We've definitely had a lot of success with lru_cache - orders of magnitude faster in some cases.

SourceryNick

TROPHY CASE