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

[dbhbarton@googlemail.com]

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

On 9 Mar, 14:05, "Diez B. Roggisch" <d...@nospam.we b.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?

[Diez B. Roggisch]

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

dbhbarton@googl email.com wrote:

On 9 Mar, 14:05, "Diez B. Roggisch" <d...@nospam.we b.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

[dbhbarton@googlemail.com]

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

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

[Diez B. Roggisch]

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

dbhbarton@googl email.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

[Bruno Desthuilliers]

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

Nick Craig-Wood a écrit :

Robert Marshall <spam@chezmarsh all.freeserve.c o.ukwrote:

> On Fri, 09 Mar 2007, Bruno Desthuilliers wrote:
>>

>>Nick Craig-Wood a ?crit :
>>>dbhbarton@googl email.com <dbhbarton@goog lemail.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.

[dbhbarton@googlemail.com]

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

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.)

[Diez B. Roggisch]

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

>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
>>highlightin g.

>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

[jim-on-linux]

SQLite3 trapping OperationalErro r

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
"OperationalErr or"
which I want to trap with try/except or some other
way.

However python 2.5,
except OperationalErro r:
responds with
"OperationalErr or" is not defined.

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

jim-on-linux

[Jerry Hill]

Re: SQLite3 trapping OperationalErro r

On 3/9/07, jim-on-linux <inq1ltd@verizo n.netwrote:

However python 2.5,
except OperationalErro r:
responds with
"OperationalErr or" is not defined.

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

--
Jerry

[jim-on-linux]

Re: SQLite3 trapping OperationalErro r

On Friday 09 March 2007 13:10, Jerry Hill wrote:

On 3/9/07, jim-on-linux <inq1ltd@verizo n.net>

wrote:

However python 2.5,
except OperationalErro r:
responds with
"OperationalErr or" is not defined.

>
I believe that needs to be spelled
except sqlite3.Operati onalError:
do_something()
>
--
Jerry

Thanks,
except sqlite3.Operati onalError:
works for me.

jim-on-linux

[Matthew Woodcraft]

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

Bruno Desthuilliers <bruno.42.desth uilliers@wtf.we bsiteburo.oops. comwrote:

>>>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-

[Robert Marshall]

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

On 09 Mar 2007, Matthew Woodcraft wrote:

Bruno Desthuilliers <bruno.42.desth uilliers@wtf.we bsiteburo.oops. comwrote:

>>>>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/

[Bjoern Schliessmann]

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

dbhbarton@googl email.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.

[paul]

Re: SQLite3 trapping OperationalErro r

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

[Paddy]

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

On Mar 9, 10:30 am, Nick Craig-Wood <n...@craig-wood.comwrote:

dbhbar...@googl email.com <dbhbar...@goog lemail.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