spookylukey

3 maanden geledendiscuss

The project pyastgrep https://pyastgrep.readthedocs.io/en/latest/ can use CSS selectors as a query language for Python syntax (default is XPath).

e.g.:

pyastgrep --css 'Call > func > Name#main'

spookylukey

6 maanden geledendiscuss

Please, please - just link to the actual "CUE" project. Not everyone has heard of your favourite thing. The first reference to `CUE` should be a hyperlink.

For other people: I'm pretty sure the author is talking about https://cuelang.org/

spookylukey

3 jaar geledendiscuss

https://lukeplant.me.uk/blog/

Over 200 posts, spanning nearly 20 years. Mostly on programming, Python, Web development, some personal and Christian stuff.

spookylukey

3 jaar geledendiscuss

I did a fairly detailed breakdown regarding the Python library Parsy: https://lukeplant.me.uk/blog/posts/python-type-hints-parsy-c...

This is not to make the general claim "Typing is a hindrance in parsing applications", or anything close. It's saying "the current static type system(s) available in Python would have made this Python library much worse".

spookylukey

4 jaar geledendiscuss

Just the other day I added a recent example to that page, from https://www.wsj.com/articles/internet-mangles-names-accents-... where it is obvious that databases are storing pre-escaped data.

This might be because of really old data and old code that saved it. But changing this decision is very hard, so I imagine many systems that adopted escape-on-input once are stuck with it.

spookylukey

4 jaar geledendiscuss

This is nice. With variable fonts, some of these fonts now are slightly under-represented - for example "Recursive" is really a large family, the website shows just one extreme point of a large multi-dimensional space.

I'm currently enjoying using the "Recursive Mono Semicasual" variant of Recursive - https://www.recursive.design/ . It adds just a little bit more fun that a typical mono font, especially at higher font sizes (e.g. for headings in Markdown in an editor).

spookylukey

5 jaar geledendiscuss

The default user model is fine, but I *always* start a project by extending it, for future-proofing. If you need to add to it, this is *so* much better than having to add a one-to-one, and at *some* point down the line you find you do want to add something. The problem is that doing it later when you need it is a pain, because of poor support by the migrations framework.

It's like 4 lines of code that saves you so much grief later on:

    from django.contrib.auth.models import AbstractUser
    class User(AbstractUser):
        pass

    AUTH_USER_MODEL = "myapp.User"

If you never need it, those 3 lines are not hurting you. In terms of a default, I think it probably would be nicer if Django pushed you to do this up front.

spookylukey

5 jaar geledendiscuss

I find it very strange to have claims about the database being tamper-evident etc without a clear description of the threat/trust model, and how/for whom it works. For example, what data does the client need to store to be sure no tampering has occurred?

spookylukey

5 jaar geledendiscuss

I think the case for server-side HTML rendering has never been stronger, and of all Django projects I work on, the ones I enjoy most are those that never got on the SPA bandwagon. From both a developer and user point of view I find them much faster and less painful. There are many cases where you really, really don't need the massive amount of extra complexity involved in designing APIs, adding JS frameworks etc.

When you need a bit of extra UI goodness, htmx https://htmx.org/ is a fantastic solution, and you can still use SPA-type approaches for things that need them.

You can also benefit from massively faster (and more reliable) functional testing when you are mostly standard HTML - see django-functest https://github.com/django-functest/django-functest/ for an example of this.

comments