Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Wed, Feb 18, 2015 at 10:16 PM, Paul Moore wrote: > On 18 February 2015 at 20:48, Jim J. Jewett wrote: >> Barry Warsaw wrote: I don't know exactly what the procedure would be to claim .pyz for *nix, e.g. updating /etc/mime.types, but I think the PEP should at least mention this. I think we want to get as official support for .pyz files on *nix as possible. >> >> Paul Moore wrote: >>> I'll add a note to the PEP, but I have no idea how we would even go >>> about that, so that's all I can do, unfortunately. >> >> Are you just looking for >> >> http://www.iana.org/assignments/media-types/media-types.xhtml >> >> and its references, including the registration procedures >> >> http://tools.ietf.org/html/rfc6838#section-4.2.5 >> >> and the application form at >> >> http://www.iana.org/form/media-types >> >> ? > > That covers mime types, but not file extensions, so it's not really > what *I* thought Barry was talking about. > > Actually, I guess the first question is whether ".py" is reserved for > Python scripts. If it is, then certainly /pyz should be reserved in a > similar way for Python Zip Applications. If there's no formal > registration of .py, then it seems a bit unreasonable to bother for > .pyz... > > Also, I don't think reserving anything is something I, as an > individual (and specifically a non-Unix user) should do. It probably > should be handled by the PSF, as the process seems to need a contact > email address... There is no extension registry for Unixy systems, because extensions traditionally don't matter. File types are identified by their contents; there is a "magic"* database that maps file contents to types (MIME types, nowadays). The `file` command is the CLI interface for that. Some programs will fall back on the extension if that doesn't give a result, but that would depend on the program. For a pyz file to run when you "open" it (for most values of "open"), it needs to have the executable bit set, and have a shebang line. * /usr/share/misc/magic – it originally contained just magic numbers, such as those you might find at the beginning of a .pyc file. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On Wed, Feb 18, 2015 at 4:16 PM, Paul Moore wrote: > On 18 February 2015 at 20:48, Jim J. Jewett wrote: >> Barry Warsaw wrote: I don't know exactly what the procedure would be to claim .pyz for *nix, e.g. updating /etc/mime.types, ... >> Are you just looking for >> http://www.iana.org/assignments/media-types/media-types.xhtml and ... > That covers mime types, but not file extensions, so it's not really > what *I* thought Barry was talking about. Question 13 at http://www.iana.org/form/media-types asks for additional information, and specifically calls out Magic Number and File Extension, among others. I doubt there is any more official repository for file extension meaning within MIME or unix. > Also, I don't think reserving anything is something I, as an > individual (and specifically a non-Unix user) should do. It probably > should be handled by the PSF, as the process seems to need a contact > email address... Ideally, it would be a long-lasting organizational address, such as pep-edi...@python.org. But often, it isn't. -jJ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
On 19 February 2015 at 18:11, Jim J. Jewett wrote: >> Also, I don't think reserving anything is something I, as an >> individual (and specifically a non-Unix user) should do. It probably >> should be handled by the PSF, as the process seems to need a contact >> email address... > > Ideally, it would be a long-lasting organizational address, such as > pep-edi...@python.org. But often, it isn't. Given that .py isn't on that list in any form I could locate, I don't think it's reasonable to add .pyz. If someone wants to propose adding both, I'd be fine with that, but it can be done independently of PEP 441. I'll add a note to the PEP to that effect. On that note, I intend to post the latest version of the PEP, and the reference implementation, tomorrow. I'll get the official version of the PEP on python.org updated at the same time. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TypeError messages
Different patterns for TypeError messages are used in the stdlib:
expected X, Y found
expected X, found Y
expected X, but Y found
expected X instance, Y found
X expected, not Y
expect X, not Y
need X, Y found
X is required, not Y
Z must be X, not Y
Z should be X, not Y
and more.
What the pattern is most preferable?
Some messages use the article before X or Y. Should the article be used
or omitted?
Some messages (only in C) truncate actual type name (%.50s, %.80s,
%.200s, %.500s). Should type name be truncated at all and for how limit?
Type names newer truncated in TypeError messages raised in Python code.
Some messages enclose actual type name with single quotes ('%s',
'%.200s'). Should type name be quoted? It is uncommon if type name
contains spaces.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On 2015-02-19 22:50, Serhiy Storchaka wrote:> Different patterns for
TypeError messages are used in the stdlib:
>
> expected X, Y found
> expected X, found Y
> expected X, but Y found
> expected X instance, Y found
> X expected, not Y
> expect X, not Y
> need X, Y found
> X is required, not Y
> Z must be X, not Y
> Z should be X, not Y
>
> and more.
>
> What the pattern is most preferable?
>
Stylistically, if the first part is in the active voice, then the
second part should also be in the active voice:
expected X, but found Y
The active voice tends to be simpler and easier to parse than the
passive voice.
I think that the word "but" adds clarity here.
Strictly speaking, that message is OK only if it's expecting X itself;
if, in fact, it's expecting an instance of X, then you should really be
saying something along the lines of:
expected X instance, but found Y instance
or:
expected instance of X, but found instance of Y
> Some messages use the article before X or Y. Should the article be
> used or omitted?
>
Messages tend not to be complete sentences anyway, so I think that it
would be fitting to omit articles.
> Some messages (only in C) truncate actual type name (%.50s, %.80s,
> %.200s, %.500s). Should type name be truncated at all and for how
> limit? Type names newer truncated in TypeError messages raised in
> Python code.
>
Truncating type names is probably not a good idea.
> Some messages enclose actual type name with single quotes ('%s',
> '%.200s'). Should type name be quoted? It is uncommon if type name
> contains spaces.
>
I think that it should be quoted only if it's expecting those
characters, e.g. if it's expecting a closing parenthesis, then it
should say ')'. If, on the other hand, it's expecting a certain type,
then it should give that type unquoted.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TypeError messages
On 19/02/2015 23:57, MRAB wrote:
On 2015-02-19 22:50, Serhiy Storchaka wrote:> Different patterns for
TypeError messages are used in the stdlib:
>
> expected X, Y found
> expected X, found Y
> expected X, but Y found
> expected X instance, Y found
> X expected, not Y
> expect X, not Y
> need X, Y found
> X is required, not Y
> Z must be X, not Y
> Z should be X, not Y
>
> and more.
>
> What the pattern is most preferable?
>
Stylistically, if the first part is in the active voice, then the
second part should also be in the active voice:
expected X, but found Y
The active voice tends to be simpler and easier to parse than the
passive voice.
I think that the word "but" adds clarity here.
Strictly speaking, that message is OK only if it's expecting X itself;
if, in fact, it's expecting an instance of X, then you should really be
saying something along the lines of:
expected X instance, but found Y instance
or:
expected instance of X, but found instance of Y
To me that is a purist argument, but in practice
expected int, but found tuple
is perfectly clear (I have received such messages myself!), and extra
verbiage is just clutter.
Identifying Z may be helpful however, so my feeling would be to stick to
2 patterns - the one above and
Z should be int, not tuple
(You may prefer e.g. "got" to "found", or "must" to "should". But
ideally the usage should be the same throughout.)
Rob Cliffe
> Some messages use the article before X or Y. Should the article be
> used or omitted?
>
Messages tend not to be complete sentences anyway, so I think that it
would be fitting to omit articles.
> Some messages (only in C) truncate actual type name (%.50s, %.80s,
> %.200s, %.500s). Should type name be truncated at all and for how
> limit? Type names newer truncated in TypeError messages raised in
> Python code.
>
Truncating type names is probably not a good idea.
> Some messages enclose actual type name with single quotes ('%s',
> '%.200s'). Should type name be quoted? It is uncommon if type name
> contains spaces.
>
I think that it should be quoted only if it's expecting those
characters, e.g. if it's expecting a closing parenthesis, then it
should say ')'. If, on the other hand, it's expecting a certain type,
then it should give that type unquoted.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4800 / Virus Database: 4257/9145 - Release Date: 02/19/15
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
