AeroEng43 / shedskin

Automatically exported from code.google.com/p/shedskin
0 stars 0 forks source link

Support "with" statement #49

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Hello,

It would be nice to have support for the "with" statement introduced in
 http://www.python.org/dev/peps/pep-0343/

It's available in CPython from version 2.5 (in the __future__
pseudo-module) and from version 2.6 (as a "normal" keyword).

Thanks,

Original issue reported on code.google.com by arkanosis on 6 Jan 2010 at 10:25

GoogleCodeExporter commented 8 years ago
would that be hard? :)

Original comment by mark.duf...@gmail.com on 6 Jan 2010 at 10:37

GoogleCodeExporter commented 8 years ago
Dunno ;-)

I'll look at it, maybe this week-end.

Regards,

Original comment by arkanosis on 7 Jan 2010 at 11:28

GoogleCodeExporter commented 8 years ago
I haven't looked at it closely, but it may have the same problem behind why 
'finally'
is not supported.. I wasn't sure at the time how to support this nicely in C++. 
so if
'with' can be supported, perhaps 'finally' can be too.. 

Original comment by mark.duf...@gmail.com on 7 Jan 2010 at 11:32

GoogleCodeExporter commented 8 years ago
Actually, the with statement is much easier to translate to C++ than the finally
construct:

  with foo() as bar:
    # do things

translates to something like:

{ // Local block
  T bar = With(foo());

} // Ends of local block, calls ~With()

with:

  template<class T>
  class With {
  public:
    With(T expr) 
      : _expr(expr) {
      _expr.__enter__();
    }
    ~With() {
      _expr.__exit__();
    }
    operator T&() const {
      return _expr;
    }
  private:
    T& _expr;
  };

It's much harder, IMHO, to support finally (maybe combining the local variable 
trick
with some goto statements in the destructor to the finally block in the try 
scope and
then back goto from the finally block to the destructor... but having a break 
or a
return statement in the finally block would "break" everything...).

Original comment by arkanosis on 7 Jan 2010 at 12:43

GoogleCodeExporter commented 8 years ago
interesting, I hadn't thought of using a block. sounds good!

Original comment by mark.duf...@gmail.com on 7 Jan 2010 at 12:53

GoogleCodeExporter commented 8 years ago
thanks again for the patch. do you consider this issue solved, so we can close 
it? it
would be nice to also support __enter__ and __exit__, but especially __exit__ 
seems
tricky.. then again, who writes their own context manager in a computationally
intensive program..

Original comment by mark.duf...@gmail.com on 8 Jan 2010 at 7:34

GoogleCodeExporter commented 8 years ago
Yeah, I'll do something for __enter__.

I don't see how to support __exit__ since it'd mean to pass a type as 
parameter...
Maybe at least we could support the right method prototype, in case the user 
only
uses the value parameter.

As far as I'm concerned, you may close the issue ; I'll send a patch later for 
the
__enter__ support which looks trivial.

Regards,

Original comment by arkanosis on 8 Jan 2010 at 8:59

GoogleCodeExporter commented 8 years ago
agreed, if we can add a clear warning this is probably more useful than 
nothing. but
please wait wait an __enter__ patch until you have something for __exit__..

closing this issue, thanks!!

Original comment by mark.duf...@gmail.com on 9 Jan 2010 at 10:15