@drq @blue It's different when it's a library and when...

@drq @blue
It's different when it's a library and when it's a project.

When you're checking your 'dependencies.json', there are a lot of stuff there. So the clearer names are the better.

When other people check your code it could be hard to understand too.
Why the fuck do you 'import starlight'? What does it do? Lights the party up?

Like 21 Mar 2023 at 9:54 | Wall-to-wall | Open on lor.sh

4 comments

Ale xyū̀ thī̀ Krungtheph!

@skobkin @drq @blue You can get away with it though if it's a framework (Django, Flask, Rails) or is likely to be a center piece of software (Pandas, PyTorch, or more obscure Pedalboard, Satchless)

And even for “boring” libraries, you have certain room for creativity – the name could be a pun on the kind of thing you're building, for example

21 Mar 2023 at 10:15 | Open on mstdn.io

Ale xyū̀ thī̀ Krungtheph!

@skobkin @drq @blue
Finally, what you say is true for dependencies file, but in code is actually fine:

from starlette.applications import Starlette
from starlette.responses import JSONResponse
from starlette.routing import Route

already gives you a rough idea what Starlette might be, even if you're not familiar with it.

21 Mar 2023 at 10:21 | Open on mstdn.io

Alexey Skobkin

@ale @drq @blue
1. In Python.
2. 'from starlette.applications import Starlette' says nothing to me, sorry.

21 Mar 2023 at 10:38 | Open on lor.sh

Ale xyū̀ thī̀ Krungtheph!

@skobkin @drq @blue
1. And other languages with a similar import system. JS and Haskell come to mind, but I'm sure there's a lot more like that.

2. Yeah, out of context it doesn't mean much. It's unlikely that it would be the only import in that file, though.

21 Mar 2023 at 10:44 | Open on mstdn.io

Go Up