Python Code Style - My Opinionated Import Ordering / Styling Notes

Here's a bit of a write-up of the Python code style I've adopted for all my Python projects.  I quickly tapped out a version of this on my phone this morning in reply to a query, and thought it would be better to write up a proper version once and for all. So, here goes!

 

(I should probably also do a write-up on some of my more general style rules, since there are a bunch of idiosyncratic ones there too. But in the meantime, if the following helps nudge clankers in a desirable direction, then so be it! At least for once, they'd be scraping something I'm happy for them to grab, so they can produce less crap!) 

 

Overall Order 

1) Block 1 = System imports
"import sys" <-- If needed in that file.
"import os" <-- Sometimes... otherwise goes below
"import traceback" <-- Not always historically

2) Signal imports (usually only on the main.py file)
"import signal"
"signal.signal(..., ...)"

3) Stdlib Imports - Alphabetical

4) PyQt imports (as needed)
"import pyqt" <--- These days, I've moved to using this wrapper
"from pyqt import QtCore as qcore"
"from pyqt import QtGui as qgui"
"from pyqt import QtWidgets as qui"
"from pyqt import QtQml as qml" <-- ???
... then any individual direct imports
... then my aliases for "QtProperty" + "Signal"

5) All external libs

6) All libs from own project. Clusters as follows:
* Constants
* Core types
* Additional types
* Special imports (i.e. for the specific module)

 

Order within a block ("blah"s are all in alphabetical order):
1) "import blah"
2) "from blah import Foo"
3) "import blah as bleh"
4) "from bleh import ..."
5) "import blah2"
6) ...

 

"AI Smells" in 2026 Software Engineering

Just like how there used to be "Code Smells", there are some remarkably obvious "AI Smells" on code and interactions that feel less than savoury...

* 1) Comment blocks in code that are way more verbose than even most non-lazy humans would produce.  There's nothing quite "wrong" with it - and indeed, in some ways, some of the things it does are quite helpful even for whoever next has to try to unpick how it works - but it also just doesn't feel right...

* 2) Obvious markers and tells - like em-dashes and unicode arrows... (yeah, humans don't do those as they all require looking up the symbols as they're not on most keyboard layouts!)

* 3) Screeds of accompanying  documentation, more verbose than even the most prolific documenters out there (aka *me*!!!) would bother to produce, which also have a nasty habit of burying the lede / not making the key points very obvious to pick out

* 4) Code review comment responses that make you wonder if you should just start being less civil + helpful in your comments, and just more blunt / symbolic (i.e. to "maximise efficiency for the machines"), since it doesn't seem like there's gonna be a human on the other end actually reading those anymore...  

(Hmm... this last part I gotta say does sometimes make you feel a bit empty inside. 

Also, there was a time when I did comment on open source project that seemed to be going on the right track in many ways but had some annoying bugs, only for it to then transpire a few days later that the author admitted the whole thing was "an experiment in getting AI to fully do all the work"... Yeah, I think I swiftly stopped caring about that one right then and there...)

Meh...  😥️

20 Years and Counting as a Professional Software Engineer

Ooh... earlier today, I was suddenly reminded that this year marks 20 years since I've been developing software in a professional / semi-professional capacity (i.e. working with a medium-sized team, on an established codebase with millions of lines of code, wrangling bug trackers + wikis, and supporting software for which there are real users of the stuff we're building who depend on that to get their work done)

I started in around May 2006 (*), after managing to get Blender's code compiling on my machine at last, which enabled me to start tackling a few of my pet peeves...

It also happened that one of the first feature film productions using Blender was kicking off around that time too in Argentina (i.e. "Plumiferos" at "Manos Digitales" (sp?) IIRC), and had posted a long list of feature requests that happened to overlap with quite a few of the things on my list! In short, that's how I ended up entering the industry - burning through that feature request list, and becoming one of the major contributors to Blender for over a decade!

(*) I had actually been programming since early 2000, but had only worked on my own private "from scratch" projects up till then

January 2026 - Position on AI

Given the fast moving nature of these things, and how heavily it's still being pushed by all the Big Tech interests, I guess it's time for another update on my current position on AI stuff

 

General Position

Get your stupid effing "Large Lying Model" / "Grand Theft Autocorrect" / "Pervasive Spying Narks" away from me!!!

For the record (even if it's useless actually saying this):  

In general, I DO NOT consent to any of "my data" or any of my work / creative outputs being used for AI training / processing, except for very specific case-by-case purposes.

While I'm asking nicely: Please cease and desist any operations where this may have happened, and delete all relevant records or thus-trained models  🙂 

 

For Coding / Software Development 

For work stuff, my current position on this stuff is:
* 1) If I'm stuck on trying to resolve a sticky "compiler says no" problem (BUT only after having given it a decent stab), then I will now consider getting AI to suggest a fix / solution, since it's there and may be able to help.

I will however scrutinise whether it passes the sniff test for bad code... (and have on a few occasions just thrown that approach out and changed tack, after seeing how bad it can get!)

* 2) For big tricky changesets, I will also ask it to do a pass over the code and check for any obvious issues (since we have found it can catch or at least flag a whole bunch of stuff that tired eyes might miss)

* 3) I've had mixed results getting it to do any bulk code generation (mainly unit tests), and TBH don't trust it to do actual feature implementation (which is usually the fun bit that us humans should get to do anyway!)... so: So far there's really not much need / use for it on that front from my end!

 

Oh... and this only applies to work problems, where work has said we should experiment with these tools + fenced off some "approved" tools that appear suitably tame.

 

(*) EDIT (22 Jan): 

I have also had some luck with getting it to generate a whole bunch of boilerplate for translating between one enum definition, and a protobuf protocol one (that I got it to generate from the first), and then writing all the conversion logic (that would've been tedious to do by hand). The best solution of course is to not need that boilerplate (i.e. the language / compiler should really be able to deduce it itself), but since our environment isn't set up for that sort of "experimental" stuff, having this tooling available when cases like this call for it is certainly nice...

 

For personal stuff:
Nah, I like the challenge / can deal with whatever it is over a longer timespan when I can be bothered...  😜

 

Exceptions (for personal stuff):

* Wrangling intractible CSS / Javascript problems - As those are nasty, and I suck at that

* Wrangling compile errors stemming from trying to build publicly available third-party OSS repos 

Picasa Replacement Project - Day 1 Status Report

Following Monday's incident, I have decided to urgently bring forward + accelerate my plans to start developing a replacement solution to my Picasa-based Photo Management workflow. As this incident had highlighted, I do somewhat urgently need to find a reliable automated solution to migrate my almost 2 decade library of non-destructive edits over to a future-proof solution I fully control!

As a result, I made a bunch of promising progress on my Picasa Reverse Engineering project last night - i.e. the first night of a new journey!

Introducing... "WhioDoc" (formerly "Quack!" / "QuackDoc")

I guess this weekend can be considered somewhat successful on the projects front (even though I only really got around to 1 of the 3 projects I'd wanted to work on, though it *was* the most important one I wanted to knock off too)

Following a few sessions of toil, I have successfully put up an initial attempt at formalising all the conventions I've been using for writing inline code docs for all my projects over the years!

While there are still a few small loose ends to tack on, at least I can finally point to this thing and say: Here's the spec!

(And eventually: "Here's all the docs-compiler tools + editor plugins everyone asks for these days")

 

https://github.com/Aligorith/quackdoc

https://github.com/Aligorith/whiodoc

 

On Outsourcing, Delegation, Code Review + Mentoring of Juniors, and Alternative Paths Not Taken

This started as a series of response to a thread discussing Boeing's disasterous decision to outsource the coding of their firmware "to the lowest bidder", with the thread starter originally claiming that "you still have to spec and test" the outputs of those outsourced workers. In general I agree that, the senior folk who were responsible for writing the specs that the code followed (AND most likely should also be responsible for testing/verifying that the obtained results were fit for integration into the codebase)  *SHOULD* bear some responsibility for ensuring that the work done is up to required standards. However, I'd also like to point out that in many ways, this way of working is in many ways much harder for everyone involved, so the blame-torch shouldn't be aimed at these folks dropping the ball (save for complete systemic dereliction of duty). My own mini-thread of response follow (inlined together + tweaked to follow read a bit better).

UI / App Toolkits + Frameworks - The "Missing Middle-Layer"

Over the past decade and a bit, on almost every project I've worked on, I've come to realise that there is often quite a massive gulf between what the Standard Library + UI Toolkits typically offer, and what it is that you really typically require when building anything of consequence for the real world. The problem is such that really, you end up needing to spend quite a bit of time re-inventing the following sub-systems for each project OR end up paying the tax of not having these for each and every feature you add (by effectively reimplementing them *per feature* instead, but without the benefits that having the standardised system brings).

While the initial seeds of what I'm about to discuss date back to around 2010, things really started to take shape around 2018/2019, when I first seriously started mooting the idea of maybe creating my own Programming Language / Environment someday (i.e. "Kea"), a batteries-included environment for doing everything "my way"...

One of the key aspects of that language would be that the following functionality / capabilities would end up being "baked" into the language as first-class citizens. Before fully embarking on that journey again, I thought it would be good to first prototype these systems in other environments where they may help advance the overall state of the software industry. Hence this blog post.

 

The Short List - Core Functionality:

* 1) Property Metadata System  (i.e. something like Blender's "RNA" system)

* 2a) Bidirectional Property Binding (Data Objects <-> UI Widgets)

* 2b) Widget / Factory that creates standard auto-bound widgets, given only the Property ID + host object reference  (i.e. something like Blender's UI widgets)

* 3) Automatic hierarchical property serialisation system  (i.e. something like Skyline-X's Preference Sets)

* 4) Version patching  (i.e. something like what is used for Blender's SDNA system)

   * Includes utilities related to version number management and/or Git branch/revision info

* 5) System for Physically-Based Unit Handling and/or Unit Conversions

 

The Short List - Extended Functionality:

* 6) Static/Dynamic Expressions / Drivers, Expression-Evaluation, and/or String Template Substitutions

* 7) A "Datablocks" System + CRUD API's for managing those

* 8) "User Preferences" system

* 9) "Operator"-like system (for standardised logging / error handling, undo/redo, and background-exec of expensive long-running-processes) - inspired by what Blender uses since 2.5

* 10) Basic Extendable Templates/Base-Implementations for Handling the Following Functionality (Optional)

   * Standard logic for New / Load Project/ Save Project stuff

   * Standard logic for handling cache files / support data files

   * Built-in screenshot per-viewport/view-angle screenshot functionality (with repeatable / savable parametric configuration)

   * Grease Pencil / Built-in Freehand Annotation Tools

   * Node-editor 

* 11) UI Toolkit Extensions + Features

   * Collapsible Panel implementation   (Note: This is surprisingly absent from most UI toolkits in practice)

   * Control-Gain Ladders / Input Convenience mechanisms

   * Popup panels templates

   * "Overlay toolbar / interactive viewport tools" system 

   * Popup info panels / extended menus for Unit Conversions + String Templating functionality

 

Initial Thoughts on "Shortcut Editing" UI's

Is it just me, or do pretty much all the "Shortcut Editor" UI's in various apps suck?

I don't claim to have a fully fleshed out + well considered + tested alternative in this case (unlike with many of the UI problems that I've spent some time toying with), but just to throw some ideas out there to kickstart a conversation about these UI's that I think as an industry we need to have.

So, without further ado, here are a few ideas for how I'd go about making Shortcut Editor UI's better if / when I try to design one next time.

 

Thoughts on Rust - 2024 Edition

Here are some of my current thoughts on Rust, as initially prompted by a thread I saw this morning asking: "What features of Rust are most appealing to you?"

My reply follows.

~~~

Originally, what drew me most to Rust I guess were (in following order)

1) Complex compiled language with momentum that was not C++ 

This was by far the biggest motivation, back when I was still mostly a C/Python dev. Having spent a few years working professionally as a C++11 software engineer now (having learned on the job, thanks to working during code reviews with a bunch of top-notch Modern C++ gurus), it now just looks like Haskell-lite for Modern C++ devs  (which enforces all the best practices we generally do, *by default*).

 

2) Claims of speed + memory safety (esp around multithread type stuff - This was a big one coming from several bad Python codebases that struggled with really bad concurrency issues (i.e. random deadlocks on machines with different processor numbers than the original dev machines used), but also because Rust first started rising in prominence as I was looking into the Depsgraph stuff (which would have really benefited from being able to evaluate multiple things in parallel, to do background recalcs + caching of your scene)

3) Didn't have "cuddled else" / "caterpillar ifs" hard coded into the syntax (*cough* Go *cough*)

To this day, it still really annoys me running across code written that way. Like, really twitchy annoyed.

It's a real pity that there are a bunch of languages that hard enshrined it in their syntax (due to design decisions), and also that increasingly many examples across other C-like languages also do it. Ugh!

Principles and Frontiers for Creative Software Tools

Here's the long-promised "Manifesto + Roadmap" for the future of Creative Software Tools I'd been wanting to publish since May/June 2024, but was ultimately stalled from doing so by a bad first encounter with Covid ultimately sapping my strength to take on outside-work commitments for a few months.  

NOTE: To get this out, I may just publish it first then amend it later

 ~~~

Dabbling with designing up another DCC tool after a hiatus of a short break from that field has reminded me of a whole bunch of untapped / unsolved directions for the future of DCC tools to make them more useful to the humans who use them.

Collage Making App - Design Sketches

While trying to put together a collage yesterday showing an amusing sequence of shots of a silvereye swallowing a ball of fruit it had yanked from a nearby fruit from the Autumn Birdy Berry Tree, I was reminded yet again just how frustrating this process is, with practically none of the tools out there really letting me do what I need + want (or at least none of the ones I currently have access to). Sure, I could ultimately bolt this together using some scripts / command-line tools, but it's a bit of a pain iterating on visual stuff like this that way.

 

My Requirements / Process-To-Automate:

* 1) Arrange my chosen images in a line, side-by-side (with ability to reorder them, add/remove items in this lineup, preview different combinations, etc. to get the flow of images right)

   NOTE: You can somewhat do this with existing tools, but it's always *a pain* to do  (and in some, it requires starting over / creating multiple draft solutions)

* 2) Allow bulk cropping the width of these to just an interesting section 

   NOTE: This requires ability to interactively preview + see the effects of such cropping, to make the iteration process fast + painless. This practically rules out all the command-line / scripted approaches. Also, no simple collage maker tools come close to even considering this possibility.

* 3) Allow ability to adjust vertical alignment on each of these individually (to fix framing differences) then v-crop any messy / scraggly bits on either side due to image sizing differences

   NOTE: Same story as above with #2

* 4) Make the canvas fit the whole strip of images (i.e. typically a very wide but not very tall image), at the highest resolution possible (from which I can then compress / resize as needed to satisfy upload constrants)

   NOTES:

        i) This last step in particular *always* manages to stump most tools out there. I get it - those are all optimised for the Insta / FB / etc. folks who have fixed "square" templates to fit their shit into. But, I don't particularly care about that when doing this.

        ii) This is actually a major gripe I have with most of our "creative" digital tools too - from painting apps to music scoring systems: i.e. The need to know and specify up front a "box" that will be big enough to fit whatever you're trying to do into (and if not, to then continuously grapple with various resizing + re-fitting tools to get more space to work in).  In that sense, that's one of the things I'm particularly proud of with Grease Pencil - that it provides an infinite canvas, free from these constraints (and is why I use/used it as my drawing tool) :)

 

Hence, I finally decided to bite the bullet, and see if I could hack together a solution for this.

Python 3.11 - IntEnum str() representation changes

Got an unwanted surprise today trying to run my codebase ("TPMS Studio") using the latest Python (3.11) instead of the 3.7 / 3.8 combos I've been using for the past few years.

Turns out the core team made a breaking change to the behaviour of enums, which breaks our file format + causes the code to crash on startup (assert failures)!

The cause:
`str(eMyEnum.Value_1)` now evaluates to "1" instead of "eMyEnum.Value_1"

(Note: eMyEnum is defined as an IntEnum)

 

The solution I ended up with was based on:
https://github.com/python/cpython/issues/94763#issuecomment-1313058070

 

[EDIT: This was the old solution. I have since learned of an even easier fix, from the official docs. See below]

In short, I now do something like:
```

import sys
import enum

if sys.version_info >= (3, 11):
    # Python 3.11+ hack
    class IntEnum(int, enum.Enum):
        # Get back old "EnumName.VariantName" str() behaviour
        pass
else:
    # Use old defines for older Python versions
    IntEnum = enum.IntEnum
```

 

[Latest Update: This solution is easier to use. It comes from the official docs (i.e. example 2)]

```

from enum import Enum, IntEnum

class eMyEnum(IntEnum):

    __str__ = Enum.__str__      # <--- That's the key right there

``` 

 Reposting from my original Mastodon posts for easier searchability

VMWare - Getting copy-paste support working

While doing some work in a VM today, I discovered, much to my chagrin that VMware was not allowing me to copy text from the VM back out into the host machine! As can be imagined, this is a massive pain if you're trying to Google a frustrating error message, or even to extract the error logs to file bug reports.

The method I'm reposting here has been tested to work with "VMware Workstation 16 Player" (16.1.0 build-17198959) on Windows 10. I'm reposting it here mainly so that I can find it again easier the next time this breaks, but also since the original post may end up going away (given that shabby state of the forum it's hosted on).

 

Original Link (by "pyhoff")

https://communities.vmware.com/t5/VMware-Workstation-Pro/Copy-paste-not-working-in-VMWare-Workstation-15-Pro-after-the-15/m-p/1841561/highlight/true#M109372

 

Steps:

1) Ensure the VM isn't running

2) Locate the "Virtual Machines" folder. It should be under your Home Directory / Documents folder.

3) Navigate to the VM in question

4) Open up the ".vmx" file in a text editor

5) Add whichever of the following defines are missing from that file  (I just added all of them):

isolation.tools.copy.disable = "FALSE"

isolation.tools.dnd.disable = "FALSE"

isolation.tools.paste.disable = "FALSE"

isolation.tools.hgfs.disable = "FALSE"

6) Save the file and start the VM again

7) Bi-directional copy and paste should now be working.

QML Quirks - A laundry list of bizzare happenings, bugs, and dodgy incomplete crap

Over the past few years, I've built a fair few UI's using QML (Qt's DSL for writing UI code) - proper ones, including one for a mission-critical / safety-of-life application, and another powering the tool to be used across a large group of non CS types. In other words, things that had to work, and not just be interactive "nice to have" toys (aka research prototypes).

Memorably, I was once asked during an interview whether I would recommend using QML and/or how it compares to using the more battle-tested QWidgets. At the time, I'd only really used it for a bunch of research prototypes (i.e. implementing HCI experiments to be exact), where it presented a great environment for implementing the kinds of dynamic non-traditional interfaces I needed. For that it was great and saved a lot of time. But, admittedly, it did also throw up a bunch of glitches (e.g. randomly sampling garbage from the wrong texture buffers / other applications even, particles not showing when chaining several scenes together but being fine when used in isolation, etc.). At the time, I could only attribute some of these to me perhaps trying to combine a few too many highly experimental techniques where perhaps the framework hadn't been tested so great.

However, knowing what I do now, I would strongly recommend that unless you were building something non-mission critical, and where the thing is loaded with animations / dynamic effects, that you really shouldn't be using it. Sure, you may be able to knock out a prototype quite quickly - but at some point - often at ill-timed moments, you will randomly stumble across one or more intractable bugs / quirks from left field that have you scrambling to rewrite / refactor the whole lot.

 

Disclaimer: Just to be clear - I generally do still like the idea of the QML language, and I think it does many things right. However, there are also many ways in which the "declarative paradigm" is really awkward to work with (*ahem* creating dialogs / temporary items / sequential-flow-based-types / etc.) 

More disconcertingly though, implementation-wise, it is seriously lacking in quality / completeness / stability, etc. in enough ways that mean that I cannot in good conscience recommend any new greenfield projects to start adopting it now.

(Plus, the fact that the embedded scripting / logic programming language it uses is Javascript... blegh!)

Tips for Making a Google Summer of Code Proposal | Developing a Software Project Plan

Today I was contacted by a student asking for help writing a Google Summer of Code proposal. With the deadline fast approaching in the next day or so, it's probably cutting it a bit late to start working on a proposal for this year's GSoC - but as every student will know, it's not a deadline if you're not waiting till the last minute to scramble up something, right ;)

 

While the advice below was written with the particular student's project in mind, I think the general concepts here are applicable to any software project, so I've decided to repost this info here in the hope that it may help others out there build better software in future.

Draft Feature List for Aligorith's Unnamed/Hypothetical Programming Language - 2019 Edition

Perhaps it is finally time to think about creating my own programming language? It would be that long-term passion project that I can truly have complete control over, with the potential for truly minimal dependencies, and in which I can finally build that proper "property system" + "node evaluation engine" + UI toolkit" that will fully work the way that I want it to, and then use this as the basis for all the projects in my backlog which will require similar structural/framework support.  (I could also formalise that documentation system I've been using on all personal projects - the one I documented here once many years ago).

I'm not that crazy yet...   yet!

Then again, I have been thinking about these matters more and more over the past year, so it's highly possible that this may still happen. If I can muster up enough time/energy away from everything else I'm working on (OR if external constraints expedite this process for whatever reason).

So, if I was to write my own programming language/environment, what can you expect it to have. Here is an incomplete list of the important things I'd do.

Shell script to set up Ready-To-Use Blender Git Checkouts on Linux

Recently, I've been setting up quite a few copies/checkouts of Blender Git repositories (approximately 3-4 per machine I'm using - including twice on the same machine after the hard drive failed). Doing this has made me all too aware of all the steps needed to get these things into a nicely working state for development (including how you need to copy out a whole bunch of commands each time).

Today, I can announce that for Linux users, the wait is over! I've successfully put together a script that basically automates the entire procedure listed on the wiki, making it possible to relatively painlessly grab the Blender sources, and then proceed to compile and run them.

Get the script here (brepo_init.sh)

It's actually part of a larger repo of automated configuration-setup scripts/tools I've been putting together over the past few weeks to make it easier to get my computing setup deployed onto new machines faster. For the time being, I'm not quite prepared to release the actual repo where all these are housed publicly, as I still haven't managed to fully vet that no private details have managed to leak/leech into the config files contained. Unfortunately, the final release of that may have to wait until I'm back in NZ (as it seems that I ultimately ended up forgetting to transfer some critical files for a few of the programs).

The Battle Against Compartmentalisation - Curiculum Design Challenges

Recently there has been a lot of discussion about the need for ethics courses as part of Computer Science / Software Engineering (or really, any form of engineering) degrees for obvious reasons. While I don't dispute the need for such courses (and indeed, I firmly applaud and welcome the introduction of these as integral parts of the curriculum) experience suggests that we do need to think about how we're presenting such material to students.

Specifically, I have doubts about whether the standard model of "let's just include a course in there to tick that requirement off" is actually the most effective way of doing it. Examples of such courses include "Programming in Matlab", "Ethics", "Security", and to a lesser degree, parts of HCI/Usability/UX. Many of these also carry a bit of added baggage in that they are often designated as "required" courses for a particular degree (more on this later).

From personal experience (and from observing students over many years), topics like this cannot be easily "compartmentalised" into a "tidy little thing that you think about separately from other things". That is, you can't really say, "Here is the body of knowledge you need to know. Memorise it, and pull it out of a hat when you need it". Instead, true understanding and mastery of such material is actually only achieved by adopting the "fundamental mindset" involved. For example, a few crude examples of fundamental mindsets for the aforementioned fields are:
     * Security - Trust no inputs - Treat everything that the "user" inputted as being potentially compromised, and a potential attempted attack.
      - Alternative mindset: How can I hack/crack this?

     * Ethics - How could this go wrong in the worst case? Who could get hurt/harmed, how bad would that be, and are there better alternatives that won't cause anyone that sort of trouble?
      -  Alternative Summary 1: Don't be a jerk
      -  Alternative Summary 2: Would you subject yourself and your loved ones to this? Your mother? Your children/future-children/grandkids/great-grandkids?

     * Usability - Humans are clumsy and stupid creatures of habit (with limited memories, limited attention spans, limited physical capabilities, and a whole bunch of other handicaps).   The problem therefore becomes - how do we try to reduce confusion and/or the potential for things to go wrong so that the bumbling apes can still get their jobs done.
       - Alternative Summary: Could I still use this thing when drunk, sick, injured, all of the above, and I couldn't look up the code/docs to check what's going on?

     * Programming -  Computers are idiots - They can perform complex operations, lots of them, very very fast. But, you have to precisely tell that what to do, when to do it, and how to do it first.

However, you can only adopt/absorb a fundamental mindset if you spend time developing a new a set of skills and/or adopt new ways of thinking about problems.

"Hex to RGBA" and other Colour Conversion Tools for Sublime Text 2/3

Today I'm announcing the first release of a new plugin for Sublime Text 3 (ST2 untested, but may well be supported too, *fingers crossed*) that makes it easier to work with various colour representations in code. As anyone who spends any time working with various colour pickers and colour-related API's on different platforms knows, at some point you're going to have to convert your colours from one representation to another for some reason, and then you suddenly have to waste heaps of time converting and transcribing colour values between different representations. Clearly this can be optimised (we're using modern text editors for goodness sakes!)  So, without further ado, the plugin can be found at the following Github repo:

https://github.com/Aligorith/Hex-to-RGBA

Key Features:
* Convert Hex (i.e. #RRGGBB) color representation to a RGBA tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1))
* Convert RGB(A) tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1)  OR rgb(0-255, 0-255, 0-255)) to Hex (i.e. #RRGGBB)
* Convert individual colour values from 0-255 (unsigned byte) values to/from float (0.0-1.0) values
* Accessible from menus (shown in screenshot), using hotkeys (shown in screenshot too: Ctrl-Shift-R for "Convert to rgba", and Ctrl-Shift-H for "Convert to hex"), and from the command palette (Ctrl-Shift-P - I recommend searching for "hex" or "ub")

EDIT (20180215):  I've just tested it in Sublime Text 2, and it also works there. So, it's safe to say that it works on both now :)