To add to this, experienced users will often start typing without looking based on what they trust the eventual state of the UI will be. Moving the cursor immediately makes it explicit that this should work.
This is following a more important rule which is "Never make keyboard input timing dependent!" I'm looking at you new Windows start menu and VS Code quick open.
I'm also the happy owner of a StarLite Mk IV. The perfect travel laptop. Thin, light, fanless, excellent keyboard and touchpad, matt screen, rock solid chassis, good battery life. I'm dreading the day when it finally breaks as there's nothing comparable on the market today. I wish they could do another run.
Very different niche from the StarFighter but StarLabs make excellent machines.
By the way, I have raised a ticket to finalize method order before 1.0 release (https://github.com/bwhmather/ssort/issues/11). Please follow and comment if you would like to see a change.
It is a bit backwards, but in exchange you get predictability
With backwards sorting you know that, unless there is a cycle, you can always scroll up from a call site to find the definition or down from a definition to see where it is used. With forwards sorting you can scroll down to find a definition, unless the function was imported, or used as a decorator somewhere, or called by something that was used as a decorator, or used in some other way that I haven't thought of.
My personal experience is that this predictability is hugely useful. It almost entirely obviates the need for jump-to-definition within a module, and gives modules a very obvious shape and structure.
Will do. Examples directory isn't terribly helpful as documentation as it mostly contains real code with problematic syntax (and compatible licensing) that tripped up ssort when I ran it on a copy of my pip cache. I will move it into tests to avoid confusion
Implementation details at the top. Python is a scripting language so modules are actually evaluated from top to bottom. Putting high level logic up top is nice when you just have functions, which defer lookup until they are called, but you quickly run into places (decorators, base classes) where it doesn't work and then you have to switch. Better to use the same convention everywhere. You quickly get used to reading a module from bottom to top.
isort only sorts imports. ssort will sort all other statements within a module so that they go after any other statements they depend on. The two are complementary and I usually run both.
One thing worth mentioning is that the `git blame` ignore file trick doesn't work as well with ssort as it does with black because the changes ssort makes tend to be much less local.
I've had the same problem with pydantic. Currently, properties are special cased and moved to the top. Everything else, including classes, is grouped with methods. Meta classes will end up somewhere in the middle, which is probably the worst possible case.
SSort is currently used for several hundred kilobytes of python so I'm wary, but if I'm going to make a breaking change before 1.0 then I think this is likely to be it.
Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits.
This is following a more important rule which is "Never make keyboard input timing dependent!" I'm looking at you new Windows start menu and VS Code quick open.