By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,584 Members | 1,803 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,584 IT Pros & Developers. It's quick & easy.

2 new comment-like characters in Python to aid development?

P: n/a
Had a thought that's grown on me. No idea if it's original or not- too
inexperienced in programming- but I guess there's no harm floating it
out there.

Python wins big on readability, and there's no doubt that context-
dependent text formatting in IDEs (keywords, strings, comments etc) is
a massive help too, therefore benefitting development and maintenance.
This idea is in a similar vein, especially for when scripts grow
large.

What if 2 new 'special' comment-like characters were added to Python?:
1. The WIP (Work In Progress) comment:

A '?' placed in the preceding whitespace of a line as a means of
quickly highlighting a line or block of code for special attention.
The interpreter simply ignores these characters, and executes the code
as if each WIP character wasn't there. The value-added comes from how
IDEs can exploit this to color the line or code block (in a
customisable fashion as with other context-dependent IDE formatting).

Thus...
?a=6 #This line gets highlighted.
?class MyClass: #This entire class gets highlighted.
def __init__(self):
self.val=3
?def MyFn(): #This entire function gets highlighted.
return 'x'
?for each in range(9): #This entire block gets highlighted.
print each

Simply delete the ? and the associated highlighting vanishes
immediately.
Indeed if the interpreter can tolerate one '?' then perhaps it can
also allow '??' and '???', letting the IDE color each differently for
some additional flexibility.

Applications...
Lets you highlight / un-highlight entire blocks with a single
keystroke: to record which part of a long script you're working on, or
which part needs development or optimization. IDEs could add
additional functionality if they chose: options to remove all wip
comments, or step through them, or even to automatically add WIP
comments (to highlight syntax errors, potentially infinite loops, or
rate-limiting code blocks, perhaps?)
2. The HALT comment:

A '!' at the start of a line, indicating the end of the script proper.
The interpreter would register this one, and ignore everything after
it, a bit like a sys.exit() call but also stopping it from picking
syntax errors after the HALT. IDEs could then 'grey out' (or 'yellow
out' or whatever) all following characters, including later HALT
comments.

Applications...
Lets you mask / unmask the tailing parts of a py script with a single
keystroke: potentially quite useful during the writing / testing phase
of coding when you might not want to run the whole thing, or as
another means of adding extensive comments to the end of a file. Could
also be rather handy in 'tutorial scripts' and the like...

E.g...
# Welcome to my Python Tutorial Script
my_string="Hello World"
print my_string
! # Everything after this '!' is ignored and greyed out for now, but
when you're ready to move on to the next part of the tutorial script
just delete the '!' and run it again.
my_list=list(my_string)
print my_list
! # <-- delete '!' when ready, etc etc
my_list_reversed=my_list[::-1]
print my_list_reversed
As far as I can see, neither of these would break backwards
compatibility and, like the @ decorator, if you don't like it, you
wouldn't have to use it. I don't know enough about the guts of Python
to say much about ease of implementation, but it doesn't seem like it
would be too hard.

Personally I'd use these a lot, but I'm a rank amateur so maybe I just
don't develop code properly.
That's it. Useful? Pointless? Dangerous? Stupid?
Dave.

Mar 9 '07 #1
Share this Question
Share on Google+
29 Replies


P: n/a
En Fri, 09 Mar 2007 06:14:46 -0300, <db*******@googlemail.comescribió:
A '?' placed in the preceding whitespace of a line as a means of
quickly highlighting a line or block of code for special attention.
The interpreter simply ignores these characters, and executes the code
as if each WIP character wasn't there. The value-added comes from how
IDEs can exploit this to color the line or code block (in a
customisable fashion as with other context-dependent IDE formatting).
This could be implemented without new syntax: just make your editor
recognize some special comments, and apply the highlighting to the
following block. By example,

# XXX Remove this when FuruFaifa is fixed to always provide
# XXX the names in the same order
names.sort()
names.reverse()

if names==oldnames:
...

would highlight the first 4 lines (let's say, up to the next blank line or
dedent).
2. The HALT comment:

A '!' at the start of a line, indicating the end of the script proper.
The interpreter would register this one, and ignore everything after
it, a bit like a sys.exit() call but also stopping it from picking
syntax errors after the HALT. IDEs could then 'grey out' (or 'yellow
out' or whatever) all following characters, including later HALT
comments.
You accidentally type a ! somewhere, and your module stops working - not
so good :( and worse, hard to find.

I sometimes use '''this string marks''' to ignore whole blocks of code. It
works fine unless the block already contains the same kind of
triple-quoted string...
As far as I can see, neither of these would break backwards
compatibility and, like the @ decorator, if you don't like it, you
wouldn't have to use it. I don't know enough about the guts of Python
to say much about ease of implementation, but it doesn't seem like it
would be too hard.
The main problem with new syntax is breaking compatibility with older
versions, and I doubt it's worth the pain just for highlighting or playing
interactively, so you don't have a great chance of them being
implemented...

--
Gabriel Genellina

Mar 9 '07 #2

P: n/a
db*******@googlemail.com <db*******@googlemail.comwrote:
What if 2 new 'special' comment-like characters were added to Python?:
1. The WIP (Work In Progress) comment:
I use # FIXME for this purpose or /* FIXME */ in C etc.

I have an emacs macro which shows it up in bright red / yellow text so
it is easy to see and the company has a system which makes a web page
with a list of all the FIXMEs on.

FIXME is easy to grep for, language neutral and a lot of people use
something similar (eg XXX or TODO).
2. The HALT comment:
You can so this with triple quotes. ''' and ''' (if you normally use
""" """ for docstrings)

Python just ignores strings that lie around.

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Mar 9 '07 #3

P: n/a
Thanks for the thoughts.
This could be implemented without new syntax: just make your editor
recognize some special comments, and apply the highlighting to the
following block. By example,

# XXX Remove this when FuruFaifa is fixed to always provide
# XXX the names in the same order
names.sort()
names.reverse()
Yes I recognise that we can use existing comments for this purpose,
and if I was suitably gifted I guess I could try to make the IDE
recognise these 'special comments', and maybe even work out what block
they're meant to apply to. Of course I'll still argue that the WIP
character would be a more elegant, speedy and versatile alternative.

You accidentally type a ! somewhere, and your module stops working - not
so good :( and worse, hard to find.
By my reckoning it would be very very easy to find. Even if the IDE
wasn't greying out everything after it. And how often do you
accidentally mistype a ! at the beginning of a line?

I sometimes use '''this string marks''' to ignore whole blocks of code. It
works fine unless the block already contains the same kind of
triple-quoted string...
Indeed. Moreover those quotes have to be in pairs, so it's not exactly
a quick and dandy way of doing what I'd like.

The main problem with new syntax is breaking compatibility with older
versions...
Agreed. But both characters are currently disallowed in the positions
concerned, and in the proposal they're optional extras. This can't
stop old scripts from working, it can only stop new scripts from
working on old installations- just like any new feature.
>, and I doubt it's worth the pain just for highlighting or playing
interactively
Ah well there's the issue!
>, so you don't have a great chance of them being
implemented...
Obviously I like the idea, but I never hold out much hope that people
will agree with me!

Mar 9 '07 #4

P: n/a
Nick Craig-Wood a écrit :
db*******@googlemail.com <db*******@googlemail.comwrote:
> What if 2 new 'special' comment-like characters were added to Python?:
1. The WIP (Work In Progress) comment:

I use # FIXME for this purpose or /* FIXME */ in C etc.

I have an emacs macro which shows it up in bright red / yellow text so
it is easy to see
<ot>
Care to share this macro ?
</ot>
Mar 9 '07 #5

P: n/a
db*******@googlemail.com wrote:
Of course I'll still argue that the WIP character would be a more
elegant, speedy and versatile alternative.
I don't think so. Those characters have no syntactical meaning and
would, IMHO, make the language "dirty".

Regards,
Björn

--
BOFH excuse #73:

Daemons did it

Mar 9 '07 #6

P: n/a
On 9 Mar 2007 02:31:14 -0800, db*******@googlemail.com
<db*******@googlemail.comwrote:
Thanks for the thoughts.
This could be implemented without new syntax: just make your editor
recognize some special comments, and apply the highlighting to the
following block. By example,

# XXX Remove this when FuruFaifa is fixed to always provide
# XXX the names in the same order
names.sort()
names.reverse()

Yes I recognise that we can use existing comments for this purpose,
and if I was suitably gifted I guess I could try to make the IDE
recognise these 'special comments', and maybe even work out what block
they're meant to apply to. Of course I'll still argue that the WIP
character would be a more elegant, speedy and versatile alternative.
But you are overloading the ? character for a purpose which it totally
was not meant for. What the character means really depends on what
person you are asking. To me, it means that what precedes it is
something someone or something does not know and wants to know the
answer to. To me, it really does not mean that what follows it is work
in progress.

Even if I could intuitively tell that a question mark represents a
work in progress, that information is not very useful. Similarly to
the "under construction" animated gifs that were popular on the web in
the mid 90-ties, the symbol does not convey any useful information.
WHY is it a work in progress? Is there something wrong with it?

?def foobar():
do stuff

The question mark does not leave me any the wiser. Now if you replace
that question mark with a comment:

# foobar() is buggy because it throws weird exceptions when x = 42.
def foobar():
do stuff

That gives me some useful information.

--
mvh Björn
Mar 9 '07 #7

P: n/a
>Those characters have no syntactical meaning...

?
Neither does # until you give it syntactical meaning. I must be
missing what you mean.
would, IMHO, make the language "dirty".
Well I'm not a big fan of decorators so I know how you must feel. But
# FIXME + a hack doesn't seem clean to me. And commenting off the
bottom half of a long script with triple quotes is ugly and a pain and
you can't indicate multiple alternate halt points as in the 'tutorial
script' example I gave.

Mar 9 '07 #8

P: n/a
>
Well I'm not a big fan of decorators so I know how you must feel. But
# FIXME + a hack doesn't seem clean to me. And commenting off the
bottom half of a long script with triple quotes is ugly and a pain and
you can't indicate multiple alternate halt points as in the 'tutorial
script' example I gave.
It's not a hack. Without an IDE, there won't be support for that anyway -
after all, you're about to highlight blocks and the like, how is that
supposed to work?

And besides that - you might not _like_ decorators, but they do have a
semantic. Just inserting "random" characters into the source code that one
has to overread doesn't make any sense, it just clutters the code.

With an proper IDE, you could make that tagging of yours bound to a simple
keystroke, and the IDE could store the tagging information separately. E.g.
eric3 offers some bookmark features, I presume something like your proposal
would be possible, too.
Diez

Mar 9 '07 #9

P: n/a
On Mar 9, 10:59 am, "BJörn Lindqvist" <bjou...@gmail.comwrote:
On 9 Mar 2007 02:31:14 -0800, dbhbar...@googlemail.com

<dbhbar...@googlemail.comwrote:
Thanks for the thoughts.
This could be implemented without new syntax: just make your editor
recognize some special comments, and apply the highlighting to the
following block. By example,
# XXX Remove this when FuruFaifa is fixed to always provide
# XXX the names in the same order
names.sort()
names.reverse()
Yes I recognise that we can use existing comments for this purpose,
and if I was suitably gifted I guess I could try to make the IDE
recognise these 'special comments', and maybe even work out what block
they're meant to apply to. Of course I'll still argue that the WIP
character would be a more elegant, speedy and versatile alternative.

But you are overloading the ? character for a purpose which it totally
was not meant for. What the character means really depends on what
person you are asking. To me, it means that what precedes it is
something someone or something does not know and wants to know the
answer to. To me, it really does not mean that what follows it is work
in progress.

Even if I could intuitively tell that a question mark represents a
work in progress, that information is not very useful. Similarly to
the "under construction" animated gifs that were popular on the web in
the mid 90-ties, the symbol does not convey any useful information.
WHY is it a work in progress? Is there something wrong with it?

?def foobar():
do stuff

The question mark does not leave me any the wiser. Now if you replace
that question mark with a comment:

# foobar() is buggy because it throws weird exceptions when x = 42.
def foobar():
do stuff

That gives me some useful information.

--
mvh Björn- Hide quoted text -

- Show quoted text -
perhaps another character would be preferable. '~' perhaps. As to what
you use the WIP character for- in my mind the purpose is to allow an
extra type/level of commenting over and above #, which is inherently
flexible. I could for example choose to use ? (or ~) for blocks I'm
still writing, ?? (or ~~) for blocks that are buggy, and ??? (or ~~~)
for blocks that work but could use optimization. It's a commenting
shortcut for me as the script's developer and its advantage over #
comments are speed or insertion/removal.
Ah but I can see I'm not winning anybody over. I shall graciously
retire!

Mar 9 '07 #10

P: n/a
On Fri, 09 Mar 2007, Bruno Desthuilliers wrote:
>
Nick Craig-Wood a écrit :
>db*******@googlemail.com <db*******@googlemail.comwrote:
>> What if 2 new 'special' comment-like characters were added to
Python?:
1. The WIP (Work In Progress) comment:

I use # FIXME for this purpose or /* FIXME */ in C etc.

I have an emacs macro which shows it up in bright red / yellow text
so it is easy to see

<ot>
Care to share this macro ?
</ot>
I have this

(cond (window-system
(progn
(font-lock-add-keywords
'python-mode '(("\\<FIXME: .*$" 0 font-lock-warning-face prepend))))))

Robert
--
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/
Mar 9 '07 #11

P: n/a
db*******@googlemail.com wrote:
>Those characters have no syntactical meaning...

?
Neither does # until you give it syntactical meaning. I must be
missing what you mean.
Yes, it has. It says "disregard the following characters until EOL".
If you remove it, the following code will be interpreted as ...
code (and not be disregarded).

A "WIP character" would only be there for tagging and wouldn't
change the program logic. Thus, IMHO, it's useless as a part of the
Python language. Highlighting and tagging is task of editors/IDEs.
>would, IMHO, make the language "dirty".

Well I'm not a big fan of decorators so I know how you must feel.
Mh, not sure -- why do you have decorators in mind? I don't dislike
them.
But # FIXME + a hack doesn't seem clean to me.
I think it's much cleaner to have language and "fixme" levels
separate. "fixme" features can then depend fully on the editor/IDE
and don't have to be part of the source code (though they may).
And commenting off the bottom half of a long script with triple
quotes is ugly and a pain and you can't indicate multiple
alternate halt points as in the 'tutorial script' example I gave.
A proper editor can comment out multiple lines easily.

A smart script can have multiple halt points user-selectable, though
this is a big matter of taste. I think that in this case some kind
of learning environment is better.

Regards,
Björn

--
BOFH excuse #23:

improperly oriented keyboard

Mar 9 '07 #12

P: n/a
Robert Marshall <sp**@chezmarshall.freeserve.co.ukwrote:
On Fri, 09 Mar 2007, Bruno Desthuilliers wrote:

Nick Craig-Wood a ?crit :
db*******@googlemail.com <db*******@googlemail.comwrote:
What if 2 new 'special' comment-like characters were added to
Python?:
1. The WIP (Work In Progress) comment:

I use # FIXME for this purpose or /* FIXME */ in C etc.

I have an emacs macro which shows it up in bright red / yellow text
so it is easy to see
<ot>
Care to share this macro ?
</ot>

I have this

(cond (window-system
(progn
(font-lock-add-keywords
'python-mode '(("\\<FIXME: .*$" 0 font-lock-warning-face prepend))))))
This is what I use which is very similar

(font-lock-add-keywords 'python-mode
'(
("\\<\\(FIXME\\):?" 1 font-lock-warning-face prepend)
)
)

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Mar 9 '07 #13

P: n/a
Yes, it has. It says "disregard the following characters until EOL".
If you remove it, the following code will be interpreted as ...
code (and not be disregarded).
and ! would say "disregard the following characters until End Of
Program". Is it really so different?

Well I'm not a big fan of decorators so I know how you must feel.

Mh, not sure -- why do you have decorators in mind? I don't dislike
them.
Just because I remember reading similar aesthetic arguments against
the @ syntax- that it looked alien, messy, unpythonic and obfuscating.
I certainly agree with the latter point even if I find the former ones
a little hand-wavey for my tastes.

I think it's much cleaner to have language and "fixme" levels
separate. "fixme" features can then depend fully on the editor/IDE
and don't have to be part of the source code (though they may).
That's certainly a solid ideological argument against the "WIP
character". Maybe I should just change my editor!

It sounds like other Python users *do* like to do the kind of things I
suggested, but seasoned users would rather rely on macros and features
of specific editors. Unfortunately, to a newbie like myself, these
seem like obscure 'tricks' to be mastered rather than simple built-in
conveniences that any newbie can profit from.

I suppose my ideology is that Python's greatest strength is (and focus
should be) its visual simplicity and ease of learning, making
programming more accessible to the masses. But hey I'm just a fresh-
faced conscript. I guess I've got to leave the battle planning to the
five-star generals on the hill!

Thanks for all the comments and the spirit of tolerance.

dave
Mar 9 '07 #14

P: n/a
It sounds like other Python users *do* like to do the kind of things I
suggested, but seasoned users would rather rely on macros and features
of specific editors. Unfortunately, to a newbie like myself, these
seem like obscure 'tricks' to be mastered rather than simple built-in
conveniences that any newbie can profit from.
But you _can't_ profit from these conveniences, at least not the ?
character. It's just garbage put in there for some others to interpret,
meaningless to the interpreter. So it _always_ boils down to
editor-support.

Now obviously _one_ scheme supported by all editors would be a great thing -
so one could argue that a well-defined PEP that suggests a certain comment
style that allows for your desired functionality would be a good thing.

Diez

Mar 9 '07 #15

P: n/a
On 9 Mar, 14:05, "Diez B. Roggisch" <d...@nospam.web.dewrote:
But you _can't_ profit from these conveniences, at least not the ?
character. It's just garbage put in there for some others to interpret,
meaningless to the interpreter. So it _always_ boils down to
editor-support.
I'm sorry I don't follow your logic. Meaningless to the interpreter,
yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
conveniences"? Why ever not?

Mar 9 '07 #16

P: n/a
db*******@googlemail.com wrote:
On 9 Mar, 14:05, "Diez B. Roggisch" <d...@nospam.web.dewrote:
>But you _can't_ profit from these conveniences, at least not the ?
character. It's just garbage put in there for some others to interpret,
meaningless to the interpreter. So it _always_ boils down to
editor-support.

I'm sorry I don't follow your logic. Meaningless to the interpreter,
yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
conveniences"? Why ever not?
Exactly, the ? is meaningless to the language itself, it's only a comment
sign - but what you want is

"""
1. The WIP (Work In Progress) comment:

A '?' placed in the preceding whitespace of a line as a means of
quickly highlighting a line or block of code for special attention.
"""

Now tell me - how exactly do you highlight a text? That is solely part of
the editor you use, either it will parse the ? - the same way it would
parse a # fixme or # wip comment - and react accordingly, or it won't.

But for python itself, it has no meaning whatsoever, and would just be a
character to overread, introducing visual clutter.

So - if you want that feature, patch your editor of choice to deal with that
comments, make them added and removed with a key stroke, whatever - be my
guest. But it has nothing to do with _python_ the language, so it doesn't
belong there.

Besides, I don't see how "quick highlighting of text" is something that
needs to be persisted anyway - if it is quick, hightlight it within the
editor until the file is closed. If not, it might be well worth a comment
anyway why you think it needs special attention.

Diez
Mar 9 '07 #17

P: n/a
I'm sorry I don't follow your logic. Meaningless to the interpreter,
yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
conveniences"? Why ever not?

Exactly, the ? is meaningless to the language itself, it's only a comment
sign - ...
... it has nothing to do with _python_ the language, so it doesn't
belong there.
But # is 'only a comment sign' as well, and equally meaningless to the
interpreter. But it's still part of the language, very very useful and
I profit from its existence every day.

But for python itself, it has no meaning whatsoever, and would just be a
character to overread, introducing visual clutter.
If you can highlight an entire block with a single character, won't
there be _less_ visual clutter than the current way of achieving the
same effect with # comments?

So - if you want that feature, patch your editor of choice to deal with that
comments, make them added and removed with a key stroke, whatever - be my
guest.
Would if I could!
Besides, I don't see how "quick highlighting of text" is something that
needs to be persisted anyway - if it is quick, hightlight it within the
editor until the file is closed. If not, it might be well worth a comment
anyway why you think it needs special attention.
What we're talking about here is a form of 'alternate commenting
style'. With the IDE's cooperation it'd work on whole blocks at once,
it would highlight without disrupting the code concerned (at least the
way I'm envisaging it), it would be versatile (could probably be used
for as big a variety of purposes as the # comment), and yes, it'd be
persistent, which is how it would be different from any IDE-based
highlighting.

I think that'd be most useful. You don't. So far nobody else here does
either, and I've not persuaded anybody differently. Fair enough!

dave

Mar 9 '07 #18

P: n/a
db*******@googlemail.com wrote:
I'm sorry I don't follow your logic. Meaningless to the interpreter,
yes, meaningless to the IDE or to me, no. I "_can't_ profit from these
conveniences"? Why ever not?

Exactly, the ? is meaningless to the language itself, it's only a comment
sign - ...
... it has nothing to do with _python_ the language, so it doesn't
belong there.

But # is 'only a comment sign' as well, and equally meaningless to the
interpreter. But it's still part of the language, very very useful and
I profit from its existence every day.
A language has to have a comment mechanism, some even several.

But all of them are clear on how they work: they affect one line, or have a
bracket style like /* */ and thus demark clearly what they affect. Even
someone not fluent in the language in question will quickly grab what they
mean.

But the key-difference is that the comment in python has a meaning for the
interpreter - ignore this.

The ? has no meaning. It only has a meaning for an editor.
>But for python itself, it has no meaning whatsoever, and would just be a
character to overread, introducing visual clutter.

If you can highlight an entire block with a single character, won't
there be _less_ visual clutter than the current way of achieving the
same effect with # comments?
Not in my opinion -

# fixme
def foo():
pass

is much more clear than a rather obscure and by the occasional beholder
maybe misinterpreted

?def foo():
pass
Would if I could!
Well, grab eric3, it's written in python, and teach it to do so! It's an
exercise in python then :)

It already has some features like bookmarks, shouldn't be too hard to build
upon that.
What we're talking about here is a form of 'alternate commenting
style'. With the IDE's cooperation it'd work on whole blocks at once,
it would highlight without disrupting the code concerned (at least the
way I'm envisaging it), it would be versatile (could probably be used
for as big a variety of purposes as the # comment), and yes, it'd be
persistent, which is how it would be different from any IDE-based
highlighting.
I think you contradict yourself here. On the one side, you want it not
disturbing to the eye, yet it should be highlighted, so it will be directly
noticed by that same eyes.

This is why I believe that your idea by itself - the visually marking of
code parts - is a good thing, but the embedding into code is not, because
it _is_ an disturbance. And with an IDE that stores such information in
e.g. project metainformation, you can even have the persistence, without
the disturbance and without altering python.

Diez
Mar 9 '07 #19

P: n/a
Nick Craig-Wood a écrit :
Robert Marshall <sp**@chezmarshall.freeserve.co.ukwrote:
> On Fri, 09 Mar 2007, Bruno Desthuilliers wrote:
>>Nick Craig-Wood a ?crit :
db*******@googlemail.com <db*******@googlemail.comwrote:
What if 2 new 'special' comment-like characters were added to
Python?:
>
>
1. The WIP (Work In Progress) comment:
I use # FIXME for this purpose or /* FIXME */ in C etc.

I have an emacs macro which shows it up in bright red / yellow text
so it is easy to see
<ot>
Care to share this macro ?
</ot>
I have this

(cond (window-system
(progn
(font-lock-add-keywords
'python-mode '(("\\<FIXME: .*$" 0 font-lock-warning-face prepend))))))

This is what I use which is very similar

(font-lock-add-keywords 'python-mode
'(
("\\<\\(FIXME\\):?" 1 font-lock-warning-face prepend)
)
)
Thanks you both.
Mar 9 '07 #20

P: n/a
But all of them are clear on how they work: they affect one line, or have a
bracket style like /* */ and thus demark clearly what they affect. Even
someone not fluent in the language in question will quickly grab what they
mean.
There's nothing remotely fuzzy about how wip or halt comments would
work, nor anything unclear about what they would affect. Nor are they
remotely difficult to explain. They just haven't been employed before,
to my knowledge, even though the underlying effects seem to be a
reasonably common requirement.
But the key-difference is that the comment in python has a meaning for the
interpreter - ignore this.
OK that is true. But it's true for the halt comment as well.

The ? has no meaning. It only has a meaning for an editor.
So it _does_ have meaning! I'm sorry I just don't buy into this kind
of abstract programming ideology, and I never really have. I don't
care what the interpreter finds meaningful and neither, on a day to
day basis, do most users, I'm sure. It seems like the same kind of
aesthetic ideology that leads lots of programmers to feel repulsed by
Python's whitespace block delimiting. There's a more important
principle being missed by them: the human factor. The guy or gal who's
actually _using_ this stuff. BTW I don't mean to imply that you're not
thinking about human readability / useability, just that you don't
seem to be arguing from that basis.

Not in my opinion -
;p

Would if I could!

Well, grab eric3, it's written in python, and teach it to do so! It's an
exercise in python then :)
I may do that. Thanks for bringing it to my attention.

What we're talking about here is a form of 'alternate commenting
style'. With the IDE's cooperation it'd work on whole blocks at once,
it would highlight without disrupting the code concerned (at least the
way I'm envisaging it), it would be versatile (could probably be used
for as big a variety of purposes as the # comment), and yes, it'd be
persistent, which is how it would be different from any IDE-based
highlighting.

I think you contradict yourself here. On the one side, you want it not
disturbing to the eye, yet it should be highlighted, so it will be directly
noticed by that same eyes.
You misread me. I wasn't talking about visual disturbance but 'code
disturbance'. Let me rephrase..
"..it would highlight without causing the highlighted code to be
ignored by the interpreter.."

it _is_ an disturbance. And with an IDE that stores such information in
e.g. project metainformation, you can even have the persistence, without
the disturbance and without altering python.
So it's fine and wonderful to add a massive chunk of code to IDEs to
introduce jargon-strewn behaviour that newbies have little hope of
comprehending yet alone taking advantage of, and which will inevitably
behave differently in any IDE that does get around to providing it?
But adding two special characters to the core language is 'messy'?

I can't argue with your aesthetic dislike of the proposed syntax, it's
just the reasoning you use to support your stance that doesn't ring
true to me! (I trust no offense is caused.)

Mar 9 '07 #21

P: n/a
>The ? has no meaning. It only has a meaning for an editor.

So it _does_ have meaning! I'm sorry I just don't buy into this kind
of abstract programming ideology, and I never really have. I don't
care what the interpreter finds meaningful and neither, on a day to
day basis, do most users, I'm sure. It seems like the same kind of
aesthetic ideology that leads lots of programmers to feel repulsed by
Python's whitespace block delimiting. There's a more important
principle being missed by them: the human factor. The guy or gal who's
actually _using_ this stuff. BTW I don't mean to imply that you're not
thinking about human readability / useability, just that you don't
seem to be arguing from that basis.
I certainly do. Because a comment is always a comment. If you happen to
have a multi-line comment (in python that is) that spans more than a
page of your current terminal, you clearly will see it as such when
piped through less - a frequent tool for looking into code of libraries
for example. At least for me, and I guess some other coders as well.

But a tiny ? or !, the latter one massively changing the semantics of
the displayed code? I'm not too positive that this will be getting the
proper attention needed when comprehending the code.

Even the multiline-comments of C are easier, because they feature an
end-mark. Which for one _is_ easier to implement, thus even "less" might
implement some syntax hi-lighting based on it (if the terminal supports
that, that is. I've been doing my fair share of last-minute hacking
through malconfigured ssh-connections in vi, no syntax-highlighting
whatsoever) - while it is much less probable that "less" will grow a
full blown python parser just for the sake of hi-lighting a !-prefixed
block of code.
FWIW, I'm totally convinced that the addition of this feature to the
interpreter itself would be a minor operation that wouldn't cause much
headache from a implementation POV. It's just I don't buy into its
usefulness.
>
>>What we're talking about here is a form of 'alternate commenting
style'. With the IDE's cooperation it'd work on whole blocks at once,
it would highlight without disrupting the code concerned (at least the
way I'm envisaging it), it would be versatile (could probably be used
for as big a variety of purposes as the # comment), and yes, it'd be
persistent, which is how it would be different from any IDE-based
highlighting.
I think you contradict yourself here. On the one side, you want it not
disturbing to the eye, yet it should be highlighted, so it will be directly
noticed by that same eyes.

You misread me. I wasn't talking about visual disturbance but 'code
disturbance'. Let me rephrase..
"..it would highlight without causing the highlighted code to be
ignored by the interpreter.."

What do you mean by code-disturbance? Programming is usually something
that needs carefully assembled sequences of characters, with some
seemingly minor interpunction characters becoming extremly meaningful.
And you want to add to that the complexity of something that has _no_
meaning at all - for the language. To me that is a disturbance. Clearly
a matter of taste, though.
>
>it _is_ an disturbance. And with an IDE that stores such information in
e.g. project metainformation, you can even have the persistence, without
the disturbance and without altering python.

So it's fine and wonderful to add a massive chunk of code to IDEs to
introduce jargon-strewn behaviour that newbies have little hope of
comprehending yet alone taking advantage of, and which will inevitably
behave differently in any IDE that does get around to providing it?
But adding two special characters to the core language is 'messy'?
Adding two characters to the language from which one's only purpose is
to support the introduction of jargon-strewn behavior that newbies have
little hope of comprehending let alone taking advantage of, and which
will inevitable behave differently in any IDE that does get around
providing it.

I couldn't say it better. It is exactly my point: the ? is _nothing_
without an IDE, where _none_ of them is forced to interpret and
represent it by any means. Yet still you want to add it? Sorry, I can't
buy that.

Besides, the whole purpose of IDEs is to add massive chunks of code to
e.g. analyze class structures, show syntactic errors even before the
code is run and so on... so if you accept that editing code is more than
poking with a hex editor on your hard disk image, I fail to see the
problem of adding such chunks of code if it is feasible.
I can't argue with your aesthetic dislike of the proposed syntax, it's
just the reasoning you use to support your stance that doesn't ring
true to me! (I trust no offense is caused.)
Certainly not. And I don't intend to cause offense myself!

Diez
Mar 9 '07 #22

P: n/a
pyhelp,

I set up a table in SQLite3.

While running other modules I want to know if a
table exists.

SQL has a command "List Tables" but I don't think
SQLlite3 has this command.

I've tried
cursor.execute("select * from debtor where key
is not null ")

The table debtor does not exist so I get
"OperationalError"
which I want to trap with try/except or some other
way.

However python 2.5,
except OperationalError:
responds with
"OperationalError" is not defined.

Ideas on how to determine if a table exists would
be welcome.

jim-on-linux
Mar 9 '07 #23

P: n/a
On 3/9/07, jim-on-linux <in*****@verizon.netwrote:
However python 2.5,
except OperationalError:
responds with
"OperationalError" is not defined.
I believe that needs to be spelled
except sqlite3.OperationalError:
do_something()

--
Jerry
Mar 9 '07 #24

P: n/a
On Friday 09 March 2007 13:10, Jerry Hill wrote:
On 3/9/07, jim-on-linux <in*****@verizon.net>
wrote:
However python 2.5,
except OperationalError:
responds with
"OperationalError" is not defined.

I believe that needs to be spelled
except sqlite3.OperationalError:
do_something()

--
Jerry
Thanks,
except sqlite3.OperationalError:
works for me.

jim-on-linux
Mar 9 '07 #25

P: n/a
Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:
>>>Nick Craig-Wood a ecrit :
I use # FIXME for this purpose or /* FIXME */ in C etc.
>
I have an emacs macro which shows it up in bright red / yellow text
so it is easy to see
Thanks you both.
For what it's worth, sufficiently recent versions of emacs python-mode
have this built in.

-M-

Mar 9 '07 #26

P: n/a
On 09 Mar 2007, Matthew Woodcraft wrote:
Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:
>>>>Nick Craig-Wood a ecrit :
>I use # FIXME for this purpose or /* FIXME */ in C etc.
>>
>I have an emacs macro which shows it up in bright red / yellow
>text so it is easy to see
>Thanks you both.

For what it's worth, sufficiently recent versions of emacs
python-mode have this built in.
Is this with xemacs python mode or have you downloaded python mode
separately from emacs? I've got the latest emacs cvs (well a week
old) and it doesn't have it, or is it very,very recent?

Robert
--
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/
Mar 9 '07 #27

P: n/a
db*******@googlemail.com wrote:
But # is 'only a comment sign' as well, and equally meaningless to
the interpreter.
No! "#" means "disregard everything until EOL" to the interpreter.
Your proposed highlighting character means exactly nothing to the
interpreter. Get the difference?
But it's still part of the language, very very
useful and I profit from its existence every day.
See above, comment tokens do have syntactical meaning.
If you can highlight an entire block with a single character,
won't there be _less_ visual clutter than the current way of
achieving the same effect with # comments?
You can't "highlight" something with comments. It will become a
comment and not be executed.

Some editors may display comments in a different manner, yes. But
that's not what comments are for -- the different display is just
for convenience.
>So - if you want that feature, patch your editor of choice to
deal with that comments, make them added and removed with a key
stroke, whatever - be my guest.

Would if I could!
Why don't you grab a good editor ...
What we're talking about here is a form of 'alternate commenting
style'. With the IDE's cooperation it'd work on whole blocks at
once,
I know editors that can select blockwise without any special
characters in the source, just by keystrokes ...
it would highlight without disrupting the code concerned (at
least the way I'm envisaging it), it would be versatile (could
probably be used for as big a variety of purposes as the #
comment),
Any kind of highlighting is absolutely different from comments.
and yes, it'd be persistent, which is how it would be
different from any IDE-based highlighting.
(Why shouldn't other ways of highlighting be persistent? Metadata
exists.)
I think that'd be most useful. You don't. So far nobody else here
does either, and I've not persuaded anybody differently. Fair
enough!
Agreed.

Regards,
Björn

P.S.: More and more I'm getting the impression that everybody should
first learn to program with a most simple editor. The typical
Java+Eclipse start is wrong, IMHO ...

--
BOFH excuse #225:

It's those computer people in X {city of world}. They keep stuffing
things up.

Mar 9 '07 #28

P: n/a
jim-on-linux schrieb:
pyhelp,

I set up a table in SQLite3.

While running other modules I want to know if a
table exists.

SQL has a command "List Tables" but I don't think
SQLlite3 has this command.
I think "list tables" is a mysqlism
>
I've tried
cursor.execute("select * from debtor where key
is not null ")
FROM sqlite_master SELECT name WHERE type='table';

cheers
Paul

Mar 10 '07 #29

P: n/a
On Mar 9, 10:30 am, Nick Craig-Wood <n...@craig-wood.comwrote:
dbhbar...@googlemail.com <dbhbar...@googlemail.comwrote:
What if 2 new 'special' comment-like characters were added to Python?:
1. The WIP (Work In Progress) comment:

I use # FIXME for this purpose or /* FIXME */ in C etc.

I have an emacs macro which shows it up in bright red / yellow text so
it is easy to see and the company has a system which makes a web page
with a list of all the FIXMEs on.

FIXME is easy to grep for, language neutral and a lot of people use
something similar (eg XXX or TODO).
2. The HALT comment:

You can so this with triple quotes. ''' and ''' (if you normally use
""" """ for docstrings)

Python just ignores strings that lie around.

--
Nick Craig-Wood <n...@craig-wood.com--http://www.craig-wood.com/nick
Vim will highlight the following comments too:
#FIXME
#TODO
#XXX

- Paddy

Mar 11 '07 #30

This discussion thread is closed

Replies have been disabled for this discussion.