I don't mean to flame, but Python protocol dictates that methods/members
preceded by "_" are generally not supposed to be referred to. I guess you
could kind of consider them 'protected', whilst members preceded by a
double-underscore are considered 'private' (despite being accessible if you
de-ma
Unfortunately, it turns out that at this point it is not possible to get access to the version control without being Contributor or higher. I hope that this will change sometimes in the future, but for the moment, the only way to get access to the contents of the IronPython source control is
Dino Viehland wrote:
> Sys._getframe() is likely significantly harder to implement. I'd be
> a little bit surprised if we get this into 1.1 but it'd be nice to
> get at some point in the future. The hard part of this probably
> isn't supporting sys._getframe() but actually supporting
> sys._getfr
The core of IronPython is currently simply defined as IronPython.dll, therefore
socket is currently part of it (as all of our modules are). You could actually
make an argument against socket being there as in CPython it's actually an
external .pyd that gets loaded at runtime if you import _sock
On 10/5/06, Dino Viehland <[EMAIL PROTECTED]> wrote:
>The hard part of this probably isn't supporting
> sys._getframe() but actually supporting sys._getframe(depth).
> Do you know if the parameterless version will unblock you, or do you need
> the full blown functionality?
One thing I'm dying to
Sys._getframe() is likely significantly harder to implement. I’d
be a little bit surprised if we get this into 1.1 but it’d be nice to get at
some point in the future. The hard part of this probably isn’t supporting
sys._getframe() but actually supporting sys._getframe(depth).
Do yo
Can you use the .Net stack trace mechanisms to "look back up the call stack"?
I would think that you could, but I don't know how you'd necessarily get the
value of the PythonEngine that you find.
Could you have a "static constructor" in your C# assemblies that does the right
thing? Such code
I recall the discussions (thanks for the links, which jogged the memory). But
how is a socket (or any other) module part of "the IronPython core"? I would
have thought that the core would be the execution engine, parser, code
generator, etc -- not an arbitrary module that in many cases could b
Dino Viehland wrote:
> This is definitely a bug - I've opened CodePlex issue 3982 to track this
> Any input on how we should prioritize this?
>
It doesn't block us, no urgency from our side.
We worked around this problem by comparing all elements in lists instead
of comparing lists.
Andrzej
Jean-Yves MENGANT wrote:
> Complementary : Looking at the 1042 , I saw another unclear topic around the
> the sys_getframe entry which is marked as not supported already throwing a
> ValueError exception + 'The sys._getframe() function is not supported by
> IronPython' is also written in the 'diffe
Complementary : Looking at the 1042 , I
saw another unclear topic around the the sys_getframe entry which is marked as
not supported already throwing a ValueError exception + ‘The
sys._getframe() function is not supported by IronPython‘
is also written in the ‘differences between IronPython
11 matches
Mail list logo
