spookylukey

3 bulan yang laludiscuss

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 bulan yang laludiscuss

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 tahun yang laludiscuss

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 tahun yang laludiscuss

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 tahun yang laludiscuss

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 tahun yang laludiscuss

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 tahun yang laludiscuss

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.

comments