On 27 Mar, 2012, at 22:25, Guido van Rossum wrote:

On Tue, Mar 27, 2012 at 1:20 PM, Phil Vandry <vandry@tzone.org> wrote:

...

On 2012-03-26 10:57 , Guido van Rossum wrote:

...

On Mon, Mar 26, 2012 at 1:45 AM, Ronald Oussoren<ronaldoussoren@mac.com> wrote:

...

Yes. On what platform are you? On unixy platforms filename extensions are just a naming convention that can just as easily be used with directories.

IIUC that's how almost all filesystems treat them. However desktop software often assigns specific meanings to them -- the user can configure these, but there's a large set of predefined bindings too, and many key applications also play this game (since there is, frankly, not much else to go by -- some important file types are not

On the Mac, at least, there is much more to go by: a 4-character file type and a 4-character creator type associated with every file. The IANA registration form for MIME types even lets registrants specify the mapping between these 8 characters and a MIME type.

However, these do seem to have fallen into disuse in recent versions of MacOS. I never knew if this was an intentional downgrade or just a lack of upkeep.

Oh, I remember those from hacking MacOS decades ago... I suspect they have fallen by the wayside because only Mac-specific tools keep track of these as files are copied, moved, backed up, archived, restored, uploaded and downloaded, etc.

That, and probably also because the foundations of the osx architecture are based on nextstep which also didn't use the creator and filetype. The reason I didn't claim extensions are always a convention (and which I should have mentioned before) is that at the FAT filesystem has explicit support for extentensions (the old 8+3 filename length restriction). That's totally off-topic though. To get back on topic, I don't particularly dislike directory extensions and would prefer the ".pyp" extension for python packages withouth an __init__.py file because that is more explicit and makes it clear which directories are intented to be a python package. With the other proposal it is not clear which directories are python packages and which are directories that just happen to be on sys.path (for example because they are in the same directory as the python script you're running). Ronald

On 27 Mar, 2012, at 22:25, Guido van Rossum wrote:

On Tue, Mar 27, 2012 at 1:20 PM, Phil Vandry <vandry@tzone.org> wrote:

...

On 2012-03-26 10:57 , Guido van Rossum wrote:

...

On Mon, Mar 26, 2012 at 1:45 AM, Ronald Oussoren<ronaldoussoren@mac.com> wrote:

...

Yes. On what platform are you? On unixy platforms filename extensions are just a naming convention that can just as easily be used with directories.

IIUC that's how almost all filesystems treat them. However desktop software often assigns specific meanings to them -- the user can configure these, but there's a large set of predefined bindings too, and many key applications also play this game (since there is, frankly, not much else to go by -- some important file types are not

On the Mac, at least, there is much more to go by: a 4-character file type and a 4-character creator type associated with every file. The IANA registration form for MIME types even lets registrants specify the mapping between these 8 characters and a MIME type.

However, these do seem to have fallen into disuse in recent versions of MacOS. I never knew if this was an intentional downgrade or just a lack of upkeep.

Oh, I remember those from hacking MacOS decades ago... I suspect they have fallen by the wayside because only Mac-specific tools keep track of these as files are copied, moved, backed up, archived, restored, uploaded and downloaded, etc.

That, and probably also because the foundations of the osx architecture are based on nextstep which also didn't use the creator and filetype. The reason I didn't claim extensions are always a convention (and which I should have mentioned before) is that at the FAT filesystem has explicit support for extentensions (the old 8+3 filename length restriction). That's totally off-topic though. To get back on topic, I don't particularly dislike directory extensions and would prefer the ".pyp" extension for python packages withouth an __init__.py file because that is more explicit and makes it clear which directories are intented to be a python package. With the other proposal it is not clear which directories are python packages and which are directories that just happen to be on sys.path (for example because they are in the same directory as the python script you're running). Ronald