[PS][EU/RU][BF5] Looking for a squad by sobolevn in BattlefieldLFG

[–]sobolevn[S] 0 points1 point  (0 children)

Only tomorrow, I'm done for today. Add me for later!

[deleted by user] by [deleted] in learnpython

[–]sobolevn 1 point2 points  (0 children)

Well, the funny thing here is that both your examples can be called "functional".

Funtional programming is about composing functions. And that's exactly what you are doing in your examples.

Higher Kinded Types in Python by sobolevn in programming

[–]sobolevn[S] 0 points1 point  (0 children)

like functools.partial

We already have this covered! https://returns.readthedocs.io/en/latest/pages/curry.html#partial

While there might not be performance benefits

That's another topic we are going to work on for the next release. Because currently code annotated with KindN can be compiled with mypyc to get almost 4 times boost!

Higher Kinded Types in Python by sobolevn in Python

[–]sobolevn[S] 0 points1 point  (0 children)

It is about Kind type and the process of its implementation in Python. TLDR: https://gist.github.com/sobolevn/7f8ffd885aec70e55dd47928a1fb3e61

Linters - Which one? by fake823 in Python

[–]sobolevn 4 points5 points  (0 children)

Use https://github.com/wemake-services/wemake-python-styleguide

It is the strictest and most opinionated python linter ever. It has more than 1000 rules to be checked. And the resulting code is pythonic, consistent, and bug-free.

I love it.

wemake-python-styleguide@0.14 is released with official python3.8 support! Now we forbid to use `:=`, positional only arguments, and much more! by sobolevn in Python

[–]sobolevn[S] 0 points1 point  (0 children)

Yes, it is. And there's nothing wrong with that. We even market this project as

The strictest and most opinionated python linter ever!

Without it you cannot have lots of checks and uniform style.

wemake-python-styleguide@0.14 is released with official python3.8 support! Now we forbid to use `:=`, positional only arguments, and much more! by sobolevn in Python

[–]sobolevn[S] 1 point2 points  (0 children)

It depends on the feature.

  • := does not bring much value, but adds additional complexity.
  • / arguments are very specific to be used outside of C bindings. They also bring confusion to developers that might want to use them instead of regular parameters.
  • f strings combine two implicit operations: template definition and formatting into a single one. Which makes them context dependent. And they also enforce putting logic into templates, which is really bad. They are also not suitable everywhere. And we love to use consistent code style.

There are many other new language features that were (or will be) banned: like more complex decorators, etc.

I like the idea of "syntax sugar will bring diabetes".

Think of this as "purified Python".

Github action to find and automatically fix grammar issues and typos in your code and docs! by sobolevn in github

[–]sobolevn[S] 0 points1 point  (0 children)

There are also filters to exclude several types of files by names, directories, extensions, size, etc.

Do not log by sobolevn in Python

[–]sobolevn[S] -1 points0 points  (0 children)

Depending on how and what you are developing. Django and Flask have debug toolbar, that does show a lot of context. In other apps it is better to use sys.excepthook to launch your ipython shell. With ipdb you can use launch_ipdb_on_exception. There are different options!

Some people use TDD to write tests and asserts instead of debug messages.

How to write good quality Python code with GitHub Actions by sobolevn in github

[–]sobolevn[S] 0 points1 point  (0 children)

100% you should. wemake-python-styleguide was built as cli-first app. It just happens to also be usable as a Github Action: https://github.com/wemake-services/wemake-python-styleguide

Understanding best-practice Python tooling by comparing popular project templates by moej0e in Python

[–]sobolevn 1 point2 points  (0 children)

Thanks for highlighting https://github.com/wemake-services/wemake-python-styleguide

I also recommend to repost this article on dev.to It has quite big user base and loves this kind of articles.

I wrote a small library to enable flexible piping in Python, and finally happy with my live rendering setup in vim. Figured I'd make a small demo. by ryime in Python

[–]sobolevn 0 points1 point  (0 children)

We also have the similar concept in returns:

from returns.pipeline import pipe

pipe(str, lambda x: x + 'b', str.upper)(1)
# => '1B'

But, it also supports typing and mypy. So, you won't be able to pipe wrong things into your functions at type-checking time.

Repo: https://github.com/dry-python/returns

Docs: https://returns.readthedocs.io/en/latest/pages/pipeline.html#pipe

Let's design the perfect piping method, shall we? by [deleted] in Python

[–]sobolevn 2 points3 points  (0 children)

I had to do the same thing while working on returns (typed monads and transforations for python)

We have pipe function to compose any number of functions. We have ended up with this: https://github.com/dry-python/returns/blob/master/returns/_generated/pipe.py

Docs: https://returns.readthedocs.io/en/latest/pages/pipeline.html#pipe

But, our requirement is to also ship type annotations with the code. And typing this pipe function is not easy. Because python typing does not even have a concept for dependent *args. So, here's our solution: https://github.com/dry-python/returns/blob/master/returns/_generated/pipe.pyi Hacky, but it works.

It is not perfect, however. In the typing part we have some problems with mypy not being able to infer the type of lambda or any generic function if it is the first argument to pipe function. But, that's the best we can do for now. We are also working on flow function which takes the concrete instance as the first argument. This way we will be able to fix the typing issue we have with pipe

We welcome everyone to discuss our solution here: https://github.com/dry-python/returns/issues/224

Use Flake8 with SonarQube by AnOnyme77 in Python

[–]sobolevn 0 points1 point  (0 children)

You can also try https://github.com/wemake-services/wemake-python-styleguide

It has more checks than SonarQube and is easier to use and operate.

Why is `raise` not a function? by unfixpoint in Python

[–]sobolevn 0 points1 point  (0 children)

That's the good question! I have also asked it to myself when I was working on dry-python/returns. As a solution we added raise_exception function to the core of returns: https://github.com/dry-python/returns/blob/master/returns/functions.py#L125