Python end of file marker similar to perl's __END__

[beginner]

Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

Thanks,
Geoffrey

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

In perl, I can write __END__ in a file and the perl interpreter will

ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

Sorry, no, it doesn't.

Regards,
Martin

[Michele Simionato]

On Aug 1, 5:53 am, beginner <[e-mail]:

Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

Thanks,
Geoffrey

I wished from something like that. What you can do at the
moment, is to comment or triple quote the code you
don't want to run.

Michele Simionato

[Stargaming]

On Wed, 01 Aug 2007 05:44:21 +0000, Michele Simionato wrote:

On Aug 1, 5:53 am, beginner <[e-mail]:

>Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

I wished from something like that. What you can do at the moment, is to
comment or triple quote the code you don't want to run.

Or, if in a function body, you could insert a `return` statement. When in
top-level code, invoking `sys.exit` (or exit/quit) can do the trick. A
``raise Exception`` might help, too, but could be kinda distracting
sometimes.

So, there is no general purpose solution as perl has it (I guess that
__END__ works everywhere at least), rather different solutions for
different cases.

[Ben Finney]

beginner <zy*******@gmail.comwrites:

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line.

IIRC, this Perl feature is specifically intended to work with its
feature of reading data from the same file, as all the lines following
that marker.

This is very handy when testing my program.

If my understanding above is correct, then your use of it is a happy
repurposing of the feature, and not an intended use.

Does python have something similar?

Since it doesn't have the behaviour that inspired that feature in
Perl, I doubt it.

--
\ "Everything is futile." -- Marvin of Borg |
`\ |
_o__) |
Ben Finney

[Steve Holden]

Stargaming wrote:

On Wed, 01 Aug 2007 05:44:21 +0000, Michele Simionato wrote:

>On Aug 1, 5:53 am, beginner <[e-mail]:

>>Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

I wished from something like that. What you can do at the moment, is to
comment or triple quote the code you don't want to run.

Or, if in a function body, you could insert a `return` statement. When in
top-level code, invoking `sys.exit` (or exit/quit) can do the trick. A
``raise Exception`` might help, too, but could be kinda distracting
sometimes.

So, there is no general purpose solution as perl has it (I guess that
__END__ works everywhere at least), rather different solutions for
different cases.

I think you have missed the point. A return statement or call to
sys.exit() doesn't remove the requirement that the rest ofthe source
file be legal Python. In a Perl program you can put anything you like
after __END__.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

[Stargaming]

On Wed, 01 Aug 2007 06:56:36 -0400, Steve Holden wrote:

Stargaming wrote:

>On Wed, 01 Aug 2007 05:44:21 +0000, Michele Simionato wrote:

>>On Aug 1, 5:53 am, beginner <[e-mail]:
Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?
I wished from something like that. What you can do at the moment, is
to comment or triple quote the code you don't want to run.

Or, if in a function body, you could insert a `return` statement. When
in top-level code, invoking `sys.exit` (or exit/quit) can do the trick.
A ``raise Exception`` might help, too, but could be kinda distracting
sometimes.

So, there is no general purpose solution as perl has it (I guess that
__END__ works everywhere at least), rather different solutions for
different cases.

I think you have missed the point. A return statement or call to
sys.exit() doesn't remove the requirement that the rest ofthe source
file be legal Python. In a Perl program you can put anything you like
after __END__.

regards
Steve

That was my point actually. No, there is no such general purpose solution
as in perl, but if he just wanted to quit execution (to, eg., not commit
changes to his database), this would be the way to go. Multiline strings
are the other way to include (nearly) arbitrary data.

[Magnus Lycka]

beginner wrote:

Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

raise SystemExit() exits the program at that point (unless you
catch the exception...) "import sys;sys.exit(0)" is basically
another spelling of the same thing. It doesn't mean that the
interpreter ignores the rest of the file though, so it will
complain about syntax in the whole file.

Since I don't usually write linear top-to-bottom scripts in Python,
I don't really see the use of splitting a file in an interpreted
top and an ignored bottom though.

I'd suggest employing a test driven approach to development. Then
you don't usually have big chunks of code that you don't want to
run. All that's there works (almost)...

See e.g.
http://powertwenty.com/kpd/downloads...ntInPython.pdf

[beginner]

On Jul 31, 10:53 pm, beginner <[e-mail]:

Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

Thanks,
Geoffrey

Thanks everyone for responding. It doesn't look like python has it. I
would definitely miss it. As Steve said, the nice thing about __END__
is that things below __END__ do not have to have legit syntax. That
let me focus on the lines of code I am debugging and do not have to
worry about some bad syntax down the line. This feature is especially
handy if I am, saying, replacing modoules or changing data structures.

[Neil Cerutti]

On 2007-08-01, beginner <zy*******@gmail.comwrote:

Thanks everyone for responding. It doesn't look like python has
it. I would definitely miss it. As Steve said, the nice thing
about __END__ is that things below __END__ do not have to have
legit syntax. That let me focus on the lines of code I am
debugging and do not have to worry about some bad syntax down
the line. This feature is especially handy if I am, saying,
replacing modoules or changing data structures.

A C-like trick might be helpful while refactoring:

<working code>
if False:
<non-working code>

You have to indent all the non-working code by one level, but
with a good editor that's a snap.

Python will still parse the following lines (it must be valid
Python syntax), but the resulting parse tree won't be executed.

--
Neil Cerutti

[Diez B. Roggisch]

beginner wrote:

On Jul 31, 10:53 pm, beginner <[e-mail]:

>Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

Thanks,
Geoffrey

Thanks everyone for responding. It doesn't look like python has it. I
would definitely miss it. As Steve said, the nice thing about __END__
is that things below __END__ do not have to have legit syntax. That
let me focus on the lines of code I am debugging and do not have to
worry about some bad syntax down the line. This feature is especially
handy if I am, saying, replacing modoules or changing data structures.

In emacs, I simply mark that portion of code and do

M-x comment-region

That's it. And I don't think a language should support things __END__ -
commenting is enough. It's unfortunate that Python doesn't support
multi-line-comments though. But as I said, that my Editor can handle for
me.

Diez

[Chris Mellon]

On 8/1/07, beginner <zy*******@gmail.comwrote:

On Jul 31, 10:53 pm, beginner <[e-mail]:

Hi All,

This is just a very simple question about a python trick.

In perl, I can write __END__ in a file and the perl interpreter will
ignore everything below that line. This is very handy when testing my
program. Does python have something similar?

Thanks,
Geoffrey

Thanks everyone for responding. It doesn't look like python has it. I
would definitely miss it. As Steve said, the nice thing about __END__
is that things below __END__ do not have to have legit syntax. That
let me focus on the lines of code I am debugging and do not have to
worry about some bad syntax down the line. This feature is especially
handy if I am, saying, replacing modoules or changing data structures.

You'll probably find greater gains by embracing the limitation and
using it to help you refactor your code into smaller, more discrete
modules. Many of pythons limitations that beginners complain about are
of this nature.

[Cameron Laird]

In article <sl********************@FIAD06.norwich.edu>,
Neil Cerutti <ho*****@yahoo.comwrote:

>On 2007-08-01, beginner <zy*******@gmail.comwrote:

>Thanks everyone for responding. It doesn't look like python has
it. I would definitely miss it. As Steve said, the nice thing
about __END__ is that things below __END__ do not have to have
legit syntax. That let me focus on the lines of code I am
debugging and do not have to worry about some bad syntax down
the line. This feature is especially handy if I am, saying,
replacing modoules or changing data structures.

A C-like trick might be helpful while refactoring:

<working code>
if False:
<non-working code>

You have to indent all the non-working code by one level, but
with a good editor that's a snap.

Python will still parse the following lines (it must be valid
Python syntax), but the resulting parse tree won't be executed.

[Neil Cerutti]

On 2007-08-01, Cameron Laird <cl****@lairds.uswrote:

In article <sl********************@FIAD06.norwich.edu>,
Neil Cerutti <ho*****@yahoo.comwrote:

>>On 2007-08-01, beginner <zy*******@gmail.comwrote:

>>Thanks everyone for responding. It doesn't look like python has
it. I would definitely miss it. As Steve said, the nice thing
about __END__ is that things below __END__ do not have to have
legit syntax. That let me focus on the lines of code I am
debugging and do not have to worry about some bad syntax down
the line. This feature is especially handy if I am, saying,
replacing modoules or changing data structures.

A C-like trick might be helpful while refactoring:

<working code>
if False:
<non-working code>

You have to indent all the non-working code by one level, but
with a good editor that's a snap.

Python will still parse the following lines (it must be valid
Python syntax), but the resulting parse tree won't be executed.

.
.
.
I want to re-emphasize the "triple-quote it" tip mentioned
earlier in this thread. I think the original questioner
will find this quite satisfying, if I understand his situ-
ation at all.

*I* certainly have source code with embedded "junk"
commented out as multi-line strings.

I used to do that, but now that I use doctests so much it's
infeasible to comment out arbitrary code that way, since they
can't necessarily nest.

But Diez suggestion is even easier than the if False suggestion I
made.

--
Neil Cerutti

[Ben Finney]

beginner <zy*******@gmail.comwrites:

Thanks everyone for responding. It doesn't look like python has
it. I would definitely miss it. As Steve said, the nice thing about
__END__ is that things below __END__ do not have to have legit
syntax.

I think the unaddressed question is: Why is there so much code in your
module with invalid syntax that this trick would be useful?

That let me focus on the lines of code I am debugging and do not
have to worry about some bad syntax down the line. This feature is
especially handy if I am, saying, replacing modoules or changing
data structures.

I would strongly recommend you examine what part of your practice is
leading you to write so much code with invalid syntax, without
immediately testing and fixing it. Eliminate that part of the process
— possibly with test-driven development.

--
\ "Holy unrefillable prescriptions, Batman!" -- Robin |
`\ |
_o__) |
Ben Finney

[Magnus Lycka]

Neil Cerutti wrote:

On 2007-08-01, Cameron Laird <cl****@lairds.uswrote: .

>I want to re-emphasize the "triple-quote it" tip mentioned
earlier in this thread. I think the original questioner
will find this quite satisfying, if I understand his situ-
ation at all.

*I* certainly have source code with embedded "junk"
commented out as multi-line strings.

I used to do that, but now that I use doctests so much it's
infeasible to comment out arbitrary code that way, since they
can't necessarily nest.

If you consistently use e.g. ''' for doc strings, you can use
""" to comment out code blocks.

I still think it's better to do test-driven programming though.
Then you will very rarely have large blocks on non-working code.

[Steven D'Aprano]

On Thu, 02 Aug 2007 10:00:04 +1000, Ben Finney wrote:

beginner <zy*******@gmail.comwrites:

>Thanks everyone for responding. It doesn't look like python has
it. I would definitely miss it. As Steve said, the nice thing about
__END__ is that things below __END__ do not have to have legit
syntax.

I think the unaddressed question is: Why is there so much code in your
module with invalid syntax that this trick would be useful?

It's not just "bad syntax" that makes the triple-quote or comment trick
useful. Sometimes you're experimenting, or perhaps tinkering is a better
description. Your aim isn't to end up with a working piece of code, but to
learn something (e.g. "how do decorators work?"). You may end up with
working code at the end, but the finished code isn't the aim of the
exercise and may not be kept.

Because you're experimenting, you might end up with ten different versions
of a function, and not all of them will compile, let alone execute
correctly. It's handy to be able to comment them out and reload() the
file, and while some editors will do bulk comment/uncomment of text, the
triple-quoted string trick is easy enough that you can use it in
Microsoft's Notepad.

>That let me focus on the lines of code I am debugging and do not
have to worry about some bad syntax down the line. This feature is
especially handy if I am, saying, replacing modoules or changing
data structures.

I would strongly recommend you examine what part of your practice is
leading you to write so much code with invalid syntax, without
immediately testing and fixing it. Eliminate that part of the process
-- possibly with test-driven development.

While the discipline of TDD is good and useful, there's a time and place
for unstructured and informal experimentation too.
--
Steven.

[Ben Finney]

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:

It's not just "bad syntax" that makes the triple-quote or comment
trick useful.

Okay. That was the original reason given for refusing suggestions like
"return early from the function" etc. I answered in that context.

Because you're experimenting, you might end up with ten different
versions of a function, and not all of them will compile, let alone
execute correctly.

If a function doesn't compile, I don't understand why you're not
either throwing it away or fixing it.

As for multiple versions? That's what version control is for. With
client-only, distributed VCSes like Bazaar and Mercurial (both written
in Python) you don't even have to do anything other than install the
software to begin using it.

There's no reason not to be using a version control system any time
you're coding — even (especially!) while "just experimenting".

It's handy to be able to comment them out and reload() the file

Why not simply fix them and reload() instead? Why keep something
inside the module that doesn't work, and indeed has just been proven
not to work? (If the only reason is "because I might need it later",
again, that's what a VCS is for.)

--
\ "I'd take the awe of understanding over the awe of ignorance |
`\ any day." -- Douglas Adams |
_o__) |
Ben Finney