Re: Using Inline Python to import Python vars

From: Chris Nighswonger

> This fixes the problem! Fantastic!

>> It's possibly a little convoluted at the moment ... maybe someone can
>> improve on that.
>
> Is there any case where the marker would not be on a line by itself?

If it's not on a line by itself, it will be deemed to *not* be a marker.
If it matches /__\S+?__\n/ and is on a line by itself, it *will* be regarded 
as a marker.

There is therefore still an opening (in Inline::C, at least) to break 
Inline.

Even after the alteration to sub read_DATA has been made, this Inline::C 
code is still broken:

void foo() {
       printf ("%d\n",
                  __MINGW32__
                 + 7);
}

Similarly, if it's valid python to rewrite

  return __version__

as

  return
  __version__

then Inline::Python would still be broken by the latter.

I reckon it's probably a real can of worms to try and fix that - so I'll 
just leave it as is (until someone complains, anyway).
I think we would have to start checking for matches against known markers 
(__C__, __Python__, etc.) as you originally suggested. Even then there would 
be nothing to stop me from breaking Inline::C by defining a symbol named 
__Python__ (or __CPP__, etc.) and using that symbol in my Inline::C code.

Hopefully, everyone writes their code *across* the page, not *down* the page 
!!

> If not perhaps we could just do such as
>
>    @{$DATA{$pkg}} = split /(?m)^(__\S+?__\n)/, $data;
>
> and eliminate the need to remove whitespace?

In the past, Inline has removed the whitespace that precedes the marker - 
and it performs a check to verify that the whitespace has been removed.
So ... we need to remove the whitespace to satisfy that check. 
(Alternatively, I could rewrite the check, but I think it's safer to stick 
to  the original formatting rules.)

In fact, in the past, Inline has removed everything (not just whitespace) 
that precedes the marker on the line. So, in the past, you should have been 
able to write:

__DATA__
some arbitrary stuff  __Python__
......

Inline would then remove the  " some arbitrary stuff  " that precedes the 
__Python__ marker.

This will no longer be the case. If the marker is preceded by anything other 
than whitespace, it will be regarded as not being a marker.
So .... if anyone has been preceding the marker with anything other than 
whitespace, they'll find their code broken.
Surely, no-one has been doing that ?

Anyway, I'll chew things over for a day or two - wait and see if there's any 
other thoughts on what ought to be done.
Then I'll upload a 0.52_01 release that contains this amendment to 
Inline.pm. (I'll let the list know when that happens.)

Thanks for pursuing this, Chris, Stefan.

Cheers,
Rob