Python end of file marker similar to perl's __END__
beginner
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
"Martin v. Löwis"
> 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
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 Aug 1, 5:53 am, beginner <zyzhu2...@gmail.com> 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?
>
> 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
> 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
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 +1 571 484 6266 +1 800 494 3119
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
> Stargaming wrote:
>> On Wed, 01 Aug 2007 05:44:21 +0000, Michele Simionato wrote:
>>
>>> On Aug 1, 5:53 am, beginner <zyzhu2...@gmail.com> 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?
>>> 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
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/TestDrivenDevelopmentInPython.pdf
beginner
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
> 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
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
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
.
.
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.
Neil Cerutti
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
> 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
> On 2007-08-01, Cameron Laird <cla...@lairds.us> wrote: .
>> 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
> beginner <zyzh...@gmail.com> writes:
>
>> 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.
Neil Cerutti
> Neil Cerutti wrote:
>> On 2007-08-01, Cameron Laird <cla...@lairds.us> wrote: .
>>> 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.
But then I couldn't use """ in my docstrings! ;) Actually, I
wound up converting all my multiline doctests to use
concatenation instead, since they were ruining my syntax
highlighting performance in Vim.
--
Neil Cerutti
We shall reach greater and greater platitudes of achievement. --Richard J.
Daley
kyos...@gmail.com
Python comes with an IDE that can do bulk commenting or uncommenting.
It's IDLE. Just select the test to comment out and press ALT+3. To
uncomment, press ALT+4.
It's cool!
Mike
Ben Finney
> 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