Suor

Writing things directly is tightly coupling code. Sometimes quite distant portions of it, i.e. database access and presentation logic. With ORM and some smarter lazy technics or introspection at least you can untie it, with hand written SQL there is no way. And the reason is strings are poorly composable. Unless you use some query generator, but then we are back to ORM-like something.

Never used this, but I see that it provides a context manager/decorator, which you can use to "shield" any code. And also some shortcuts for DjangoREST or something.

Regarding extra code, you can simply replace the Djangos' `render()`, with the one from this lib and you are done. I would have probably made a custom template extension or something to do that for all renders automatically though too.

cacheops is more of a general purpose ORM caching with automatic invalidation.

For that fetching in chunks is usually a way to go. I use something of these usually https://handy.readthedocs.io/en/latest/db.html#queryset_iter...

GraphQL makes it even more fun :)

I usually use `.values()` and `.values_list()` only when model creation is really slow. Usually many rows fetched.

Actually there is such thing already https://pypi.org/project/django-auto-prefetch/ Not a monkey patch though, so will only work on the models you inherit from this.

Here is an example of such thing https://github.com/Suor/django-cacheops/blob/8b3a79de29b2545...

Should be easy enough to implement. You only need a context manager that adds 1 to some threadlocal flag on enter and subrracts on exit then check this flag in the monkey patch. Not sure how costly that will be though.

cacheops can do the same, but it never came to my mind to actually go this way. I would rather write some special code to fetch with `id__in=[...]` and then cache individually.

HN keeps automatically replacing the URL. It used to be a redirect before, but not anymore

Thanks

Using framework has its cost, so you can be better of if you understand clearly what you are doing. OTOH, framework brings structure so it's less probable you skrew up your design.

There are sure some things I haven't covered. The major one is components, which make a big deal in factor, reuse and composition. But the post started to be too long and loosing point so I skipped it.

There are also ideas beyond React I left aside. I will probably write some follow up post later.

I've already emailed there, won't make a difference probably anyway. I hate this HN tricky rating, one my post got dumped from top 5 cause there were too many comments!

Reddit kind of saves the day :)

I announced on twitter and posted to reddit. Is this prohibited?

Maybe english?

Is there something wrong with it?

OTOH, if the program logic is mapping a sequence, then you better use map() on the sequence.

It's not lazy, it returns iterator. There is a difference, you can't slice or index its result anymore. Compare to Clojure or Haskell map, which are truly lazy.

No it won't, unless you `tee` an iterator first.

It's easy cause it's familiar. But it's not simple.

This excellent talk by Rich Hickey explains the difference http://www.infoq.com/presentations/Simple-Made-Easy

If core is small then such language should provide a way to extend it outside. Like macros.

Just

    zip(seq, seq[1:])

Won't work with iterator though.

It doesn't need direct port. But it can take advantage borrowing ideas or library design principles.

The first part of a post is mere reasoning showing how I got to the actual interface I use. @decorator works with `call` not with `func, args, *kwargs`.

funcy doesn't preserve function signature. The only way for now to do this is to use exec, e.g. compile code from source or AST, which I choose to avoid.

You will still need a wrapper function and update it's metadata. Which is even more boilerplate. Or you can hide that in base Decorator class, but then we'll back to another layer of abstraction.

So it's either more boilerplate or more abstraction. Choose exactly one.

This handles decorators with arguments and makes a general case of passing same arguments to function as to wrapper less cluttered.

This looks like even more boilerplate.