On Thu, Dec 14, 2017 at 10:53 PM, Rhodri James <rho...@kynesim.co.uk> wrote: > On 14/12/17 07:25, Chris Angelico wrote: >> >> So it's an imperfect solution even as far as it goes, and a highly >> limiting way to do things. I'm sure it made good sense back when >> MS-DOS file systems ruled the Windows world, and 8.3 was just the way >> of things. > > > Even then there was RiscOS, which divorced file names from file types > entirely. A file's type was part of its directory data, and that was what > determined what happened when you double-clicked on it. You were still > limited to only one default application (and icon, and so on) per file type, > so OS/2 still wins on that front, but I always felt that having names > determine types was somehow mucky. >
Having names as the *sole* way to determine types? I agree. But as one of a suite of methods? It makes a decent default. There are plenty of files out there whose names correctly match (a) their contents and (b) what you want to do with them, so forcing people to ALSO choose a type in some other way is redundant. But if a file can have an explicit type or "no type specified", and in the latter case it uses a filename-based mapping, that would be a slab of the functionality right there. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
