In article [EMAIL PROTECTED], Terry
Hancock wrote:
[snip]
The terminator is evil. People will hate that. If there are no fields,
you should just be able to leave it off. This will have an additional
advantage in that many will already have compliant codetags if you leave
off this requirement.
I
[Tom Anderson]
ISO 8601 suggests writing date-and-times like 2005-09-26T12:34:56 -
using a T as the separator between date and time. I don't really like
the look of it, but it is a standard, so i'd suggest using it.
ISO 8601 suggests a few alternate writings, and the ``T`` you mention is
for
On Fri, 30 Sep 2005 13:27:57 -0400, =?iso-8859-1?Q?Fran=E7ois?= Pinard [EMAIL
PROTECTED] wrote:
[Tom Anderson]
ISO 8601 suggests writing date-and-times like 2005-09-26T12:34:56 -
using a T as the separator between date and time. I don't really like
the look of it, but it is a standard, so
[Bengt Richter]
The most detailed discussion I could find was
http://hydracen.com/dx/iso8601.htm
Also of interest::
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
IMO they [ISO] ought to think of another way to get funded).
People have been complaining for decades. ISO seemingly run
At 09:10 AM 9/28/2005 -0700, Micah Elliott wrote:
I agree that proof of value is necessary. Without a spec though it
will be hard to get people to know about a convention/toolset, so it's
a bit of a chicken-egg problem -- I can't have a pep until the tools are
in use, but the tools won't be used
On 9/29/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
My point about the lack of motivation was that there was little reason
shown why this should be a PEP instead of either:
1. Documentation for a specific tool, or group of tools
2. A specific project's process documentation
That's what I
Micah Elliott [EMAIL PROTECTED] wrote:
Josiah an unofficial spec is sufficient. See koders.com and search
Josiah for 'fixme' to see some common variants.
But that's the problem -- there are already a bunch of unofficial
specs, which don't serve much purpose as such. It's a cool site. I
On 2005-09-26, Micah Elliott [EMAIL PROTECTED] wrote:
:Objection: I aesthetically dislike for the comment to be terminated
with in the empty field case.
:Defense: It is necessary to have a terminator since codetags may be
followed by non-codetag comments. Or codetags could be
Terry Hancock wrote:
On Monday 26 September 2005 05:35 pm, Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at
Thanks to all who have read and/or provided feedback. There have been
some great ideas and admonitions that hadn't crossed my mind. I'll
paraphrase some of the responses for the sake of brevity; I don't mean
to misquote anyone.
Tom ISO 8601 includes a week notation.
That's great. Thanks for
Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at http://www.python.org/peps/pep-0350.html.
Thanks!
How about an
On Mon, 26 Sep 2005 15:35:21 -0700, Micah Elliott [EMAIL PROTECTED] wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at
[EMAIL PROTECTED] (Bengt Richter) writes:
2) In general, I think it might be good to meet Paul Rubin half way
re convention vs syntax, but I don't think code tagging should be
part of the language syntax per se. (-*- cookies -*- really are
defacto source syntax that snuck in by disguise IMO)
Le 27-09-2005, Paul http nous disait:
Maybe the checking functions don't really belong in the
compiler/interpreter. PyChecker might be a good home for them, if
it's made part of the distro. There could be an interpreter flag to
invoke PyChecker automatically.
Just to make a quick note that
At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at http://www.python.org/peps/pep-0350.html.
On Tue, 27 Sep 2005, Bengt Richter wrote:
5) Sometimes time of day can be handy, so maybe 2005-09-26 12:34:56
could be recognized?
ISO 8601 suggests writing date-and-times like 2005-09-26T12:34:56 - using
a T as the separator between date and time. I don't really like the look
of it, but it
On 9/27/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at http://www.python.org/peps/pep-0350.html.
On Monday 26 September 2005 10:25 pm, Paul Rubin wrote:
I really doubt you'll find much agreement for this (the compiler
should enforce it) position. The 'fewer conventions are better'
position might enjoy more support, but doesn't strike me as
particularly Pythonic (e.g. compare
On Tuesday 27 September 2005 03:07 am, Paul Rubin wrote:
[EMAIL PROTECTED] (Bengt Richter) writes:
2) In general, I think it might be good to meet Paul Rubin half way
re convention vs syntax, but I don't think code tagging should be
part of the language syntax per se. (-*- cookies -*-
Terry Hancock [EMAIL PROTECTED] writes:
But that's precisely why it would be valuable to have a PEP -- a
central catalog of such conventions makes it possible for checking
software to be consistent. If PyChecker were going to check for such
things, it would do so only because a standard
On Tue, 27 Sep 2005 18:53:03 +0100, Tom Anderson [EMAIL PROTECTED] wrote:
On Tue, 27 Sep 2005, Bengt Richter wrote:
5) Sometimes time of day can be handy, so maybe 2005-09-26 12:34:56
could be recognized?
ISO 8601 suggests writing date-and-times like 2005-09-26T12:34:56 - using
a T as the
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at http://www.python.org/peps/pep-0350.html.
Thanks!
--
Micah Elliott mde at tracos.org
On Mon, 26 Sep 2005, Micah Elliott wrote:
Please read/comment/vote. This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then. I'm reposting this since it is now Open (under consideration)
at http://www.python.org/peps/pep-0350.html.
I'm opposed to pretty much every proposal of this sort. If you want
to propose adding a feature to the language, add it in a way that the
compiler can know about it and notice when it's not used correctly.
Mere conventions that are not checked by the compiler are just more
stuff for people to
Micah Elliott [EMAIL PROTECTED] [CCed] wrote in message
[news:[EMAIL PROTECTED]
The nice thing about this is that I can use whatever part (or whatever
version) I want regardless of whether it becomes a standard library style
recommendation. I would prefer tags that are short and
Paul Rubin:
Mere conventions that are not checked by the compiler are just more
stuff for people to remember. That doesn't say they're always useless
but in general they should not be the subject of PEP's.
The PEP system allows for the documentation of a convention as an
Informational
Paul Rubin http://[EMAIL PROTECTED] wrote:
I'm opposed to pretty much every proposal of this sort. If you want
to propose adding a feature to the language, add it in a way that the
compiler can know about it and notice when it's not used correctly.
Mere conventions that are not checked by
Neil Hodgson [EMAIL PROTECTED] writes:
The PEP system allows for the documentation of a convention as an
Informational PEP. Documenting conventions is useful.
Where there are conventions, they should be documented. I'm in favor
of fewer conventions. If the preferred method of doing
On 27/09/2005, at 12:21 PM, Paul Rubin wrote:
Neil Hodgson [EMAIL PROTECTED] writes:
The PEP system allows for the documentation of a convention as an
Informational PEP. Documenting conventions is useful.
If the preferred method of doing something is
consistent enough that it can be
Tony Meyer [EMAIL PROTECTED] writes:
Does this mean that you think that PEP 8 (Python Code Style Guide)
should be enforced by the compiler? So that (e.g) lines that are too
long just don't compile?
I'd be ok with compiler warning messages from lines that are too long.
I think it's appropriate
32 matches
Mail list logo
