From Fernando.Perez at colorado.edu  Wed Aug  9 03:18:56 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 09 Aug 2006 01:18:56 -0600
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
 python2.3-ipython: help built-in function does not work]]
Message-ID: <44D98C60.9060809@colorado.edu>

Hi all,

attached is a bug report from the Debian maintainer, which I can confirm. 
Here's my take on this one, after trying a little to fix it and failing.  The 
bug is particularly strange in that the entire traceback generated only 
pertains to code in the python library, NOT to any ipython code.  So, somehow, 
we're getting inspect.py in trouble by our use of FakeModule (which is a hack, 
but a necessary one for other reasons).

Additionally, the bug only manifests itself once, as far as I can see:

import sample
help(sample) --> Big error traceback
help(sample) --> All OK

I've had over the years, no end of trouble with the inspect module in 
python2.3, it's buggy as all hell.  But since we won't get py23 fixed, perhaps 
we can find a solution in the meantime.  I see a few options:

1. Since the problem happens (as far as I can see) only once, we can hack 
things.  Instead of having help() be site._Helper(), we make it a light 
wrapper which discards first-invocation exceptions (with a warning).  This is 
very, very inelegant, but can be done in a few minutes and will be isolated to 
python 2.3.  The patch would be small, and hence easy to apply for the ipython 
maintainers, who won't be moving to our current SVN wholesale.

2. We dig deep enough to understand the real problem and find a cleaner 
workaround.  It's not impossible that in this case inspect.py is not the 
problem but our own code.


2 is obviously the better solution, but requires more time and effort.  If 
anyone thinks they can have a go at it, let me know.  Otherwise, I'd like to 
hear from the maintainers if 1 is OK with them, case in which I'll gladly code 
up a patch.

Cheers,

f

-------- Original Message --------
Subject: [afayolle at debian.org: Bug#374625: python2.3-ipython: help built-in 
function does not work]
Date: Sun, 6 Aug 2006 01:54:46 +0200
From: Norbert Tretkowski <norbert at tretkowski.de>
To: fperez at colorado.edu

Hi Fernando,

could you please take a look at the attached bugreport? I'm able to
reproduce the problem with python 2.3, but not with python 2.4.

                 Norbert

-------------- next part --------------
An embedded message was scrubbed...
From: Alexandre Fayolle <afayolle at debian.org>
Subject: Bug#374625: python2.3-ipython: help built-in function does not work
Date: Tue, 20 Jun 2006 12:12:48 +0200
Size: 9363
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060809/3d36d58c/attachment.eml>

From fperez.net at gmail.com  Wed Aug  9 03:50:50 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 9 Aug 2006 01:50:50 -0600
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <44D98C60.9060809@colorado.edu>
References: <44D98C60.9060809@colorado.edu>
Message-ID: <db6b5ecc0608090050r583532edodc0f3b7525858f75@mail.gmail.com>

On 8/9/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> I've had over the years, no end of trouble with the inspect module in
> python2.3, it's buggy as all hell.  But since we won't get py23 fixed, perhaps
> we can find a solution in the meantime.  I see a few options:
>
> 1. Since the problem happens (as far as I can see) only once, we can hack
> things.  Instead of having help() be site._Helper(), we make it a light
> wrapper which discards first-invocation exceptions (with a warning).  This is
> very, very inelegant, but can be done in a few minutes and will be isolated to
> python 2.3.  The patch would be small, and hence easy to apply for the ipython
> maintainers, who won't be moving to our current SVN wholesale.
>
> 2. We dig deep enough to understand the real problem and find a cleaner
> workaround.  It's not impossible that in this case inspect.py is not the
> problem but our own code.

Well, there's always

3. Steal the fix from python2.4 and monkeypatch 2.3's inspect.  This
gives us a time machine-type fix for users of 2.3.

Attached is a patch to do precisely this, which hopefully the Debian
gang can use.  The differences between the monkeypatched function in
2.3 and 2.4 are very small (but critical for us), so I'm not too
worried about this creating any hidden bugs.  Here's the relevant part
of the diff for the curious:

--- /usr/lib/python2.3/inspect.py       2006-02-02 13:45:16.000000000 -0700
+++ /usr/lib/python2.4/inspect.py       2006-04-27 09:28:08.000000000 -0600
@@ -369,7 +369,7 @@
     """Return the module an object was defined in, or None if not found."""
     if ismodule(object):
         return object
-    if isclass(object):
+    if hasattr(object, '__module__'):
         return sys.modules.get(object.__module__)
     try:
         file = getabsfile(object)
@@ -379,7 +379,9 @@
         return sys.modules.get(modulesbyfile[file])
     for module in sys.modules.values():
         if hasattr(module, '__file__'):
-            modulesbyfile[getabsfile(module)] = module.__name__
+            modulesbyfile[
+                os.path.realpath(
+                        getabsfile(module))] = module.__name__
     if file in modulesbyfile:
         return sys.modules.get(modulesbyfile[file])
     main = sys.modules['__main__']


I'm committing this in as a fix in trunk, and hopefully it will also
be enough for the Debian team.  Please let me know if it either
doesn't fix this particular problem, or if it causes new ones.


Cheers,

f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipy-inspect.diff
Type: text/x-patch
Size: 2193 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060809/7ceaee2c/attachment.bin>

From vivainio at gmail.com  Wed Aug  9 04:24:26 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 9 Aug 2006 11:24:26 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <44D98C60.9060809@colorado.edu>
References: <44D98C60.9060809@colorado.edu>
Message-ID: <46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>

> pertains to code in the python library, NOT to any ipython code.  So, somehow,
> we're getting inspect.py in trouble by our use of FakeModule (which is a hack,
> but a necessary one for other reasons).

If FakeModule is also behind problems for py2.5 beta, I think we
should consider getting rid of it. Is it needed for something apart
from pickling/shelving ipython-declared data?

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Wed Aug  9 13:30:15 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 9 Aug 2006 11:30:15 -0600
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
Message-ID: <db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>

On 8/9/06, Ville Vainio <vivainio at gmail.com> wrote:
> > pertains to code in the python library, NOT to any ipython code.  So, somehow,
> > we're getting inspect.py in trouble by our use of FakeModule (which is a hack,
> > but a necessary one for other reasons).
>
> If FakeModule is also behind problems for py2.5 beta, I think we
> should consider getting rid of it. Is it needed for something apart
> from pickling/shelving ipython-declared data?

I honestly don't remember the exact details, but it's there to protect
against some bugs which were reported a while back with users pickling
and unpickling normal data during an interactive session, not
necessarily ipython-specific variables or macros.

I'm all for getting rid of it, but we'd need to scour the changelog
carefully and try to find out exactly what the problem it 'fixes' was.
 I hope I was reasonably detailed in explaining why we needed it.

It's also quite possible that the problem can be better addressed with
a different approach, case in which we could just get rid of it
altogether.

In summary: +1 for getting rid of it, but it needs to be done very
carefully.  The bugs it fixed were not obvious nor easy to trigger
with most usage patterns, so we could easily reintroduce them
inadvertedly.

Cheers,

f


From vivainio at gmail.com  Thu Aug 10 03:26:59 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 10 Aug 2006 10:26:59 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
Message-ID: <46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>

On 8/9/06, Fernando Perez <fperez.net at gmail.com> wrote:

> I honestly don't remember the exact details, but it's there to protect
> against some bugs which were reported a while back with users pickling
> and unpickling normal data during an interactive session, not
> necessarily ipython-specific variables or macros.

I'll try to look for the rationale for FakeModule tonight; I have a
faint memory that it was introduced after %store, so that user was
warned properly when trying %store instances of classes declared
interactively.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From bialix at ukr.net  Thu Aug 10 04:00:55 2006
From: bialix at ukr.net (Alexander Belchenko)
Date: Thu, 10 Aug 2006 11:00:55 +0300
Subject: [IPython-dev] Bug: unicode and IPython
Message-ID: <ebep0f$c6i$1@sea.gmane.org>

This bug appears in IPython with readline installed and without also. It 
was with in Gary Bishop UNC readline and is with pyreadline 1.3 too. 
When I type russian text as unicode string (u"") IPython does not decode 
it to unicode correctly. Standard python interpreter does it well.

Below is reproduction for russian word "????" (it's means "Test" in english)

Standard python interpreter:

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = u"????"
>>> a
u'\u0422\u0435\u0441\u0442'

All correct.


IPython session:

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.7.2 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: a = u"????"

In [2]: a
Out[2]: u'\x92\xa5\xe1\xe2'

As you can see it's incorrect -- it's not russian unicode string.


When I uninstall pyreadline:

WARNING: Readline services not available on this platform.
WARNING: Proper color support under MS Windows requires Gary Bishop's
readline library.
You can find it at:
http://sourceforge.net/projects/uncpythontools
Gary's readline needs the ctypes module, from:
http://starship.python.net/crew/theller/ctypes

Defaulting color scheme to 'NoColor'
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.7.2 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: a = u"????"

In [2]: a
Out[2]: u'\x92\xa5\xe1\xe2'


Again: unicode conversion is broken.

So I think it's a bug inside IPython, not inside pyreadline.

--
Alexander



From vivainio at gmail.com  Thu Aug 10 12:40:27 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 10 Aug 2006 19:40:27 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
Message-ID: <46cb515a0608100940i19327d1cx3d5b650522a2bd30@mail.gmail.com>

On 8/10/06, Ville Vainio <vivainio at gmail.com> wrote:

> > I honestly don't remember the exact details, but it's there to protect
> > against some bugs which were reported a while back with users pickling
> > and unpickling normal data during an interactive session, not
> > necessarily ipython-specific variables or macros.
>
> I'll try to look for the rationale for FakeModule tonight; I have a
> faint memory that it was introduced after %store, so that user was
> warned properly when trying %store instances of classes declared
> interactively.

The attached patch inherits FakeModule from types.ModuleType and fixes
the reported problem;  unfortunately, this implies that the __dict__
of the module can't point directly at user_ns, which MIGHT break some
stuff; take a look at it and tell me what you think.

Note that you'll need to do

svn merge -r HEAD:1570

to revert your monkeypatching fix.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fm.diff
Type: text/x-patch
Size: 1438 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060810/c1dcb9c5/attachment.bin>

From vivainio at gmail.com  Thu Aug 10 13:14:42 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 10 Aug 2006 20:14:42 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <46cb515a0608100940i19327d1cx3d5b650522a2bd30@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
	<46cb515a0608100940i19327d1cx3d5b650522a2bd30@mail.gmail.com>
Message-ID: <46cb515a0608101014t25fede8ak1aeab54fb0efeea4@mail.gmail.com>

On 8/10/06, Ville Vainio <vivainio at gmail.com> wrote:

> The attached patch inherits FakeModule from types.ModuleType and fixes
> the reported problem;  unfortunately, this implies that the __dict__
> of the module can't point directly at user_ns, which MIGHT break some
> stuff; take a look at it and tell me what you think.

Disregard previous patch (fm.diff); the attached fm2.diff also makes
pickles in %run:ed files work (they didn't in fm.diff).

pickles of instances of classes declared in straight interactive
sessions (whew!) still don't work, but that's a hit we can take.

fm2.diff also reverts the monkeypatch of OInspect.py.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fm2.diff
Type: text/x-patch
Size: 6912 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060810/820a9aac/attachment.bin>

From fperez.net at gmail.com  Thu Aug 10 14:11:46 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 10 Aug 2006 12:11:46 -0600
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
Message-ID: <db6b5ecc0608101111y720493ebkbed3f72b6bd02a02@mail.gmail.com>

On 8/10/06, Ville Vainio <vivainio at gmail.com> wrote:
> On 8/9/06, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > I honestly don't remember the exact details, but it's there to protect
> > against some bugs which were reported a while back with users pickling
> > and unpickling normal data during an interactive session, not
> > necessarily ipython-specific variables or macros.
>
> I'll try to look for the rationale for FakeModule tonight; I have a
> faint memory that it was introduced after %store, so that user was
> warned properly when trying %store instances of classes declared
> interactively.

No, FakeModule is much, much older.  I wrote that code years ago,
because users reported various obscure pickling-related problems.
Scan the changelog a little, there may be something either with
'FakeModule' or 'pickle' in there that hints at the rationale.

I'm swamped til next week, so I won't be able to really look at these
patches until then.  But for testing purposes, try various
combinations of pickling reasonably complex things from the command
line and unpickling them, and do so crossing boundaries between
pickling things interactively and unpickling them from a pure python
script (run without ipython) and viceversa.  There's a chance the
problem was some kind of bad interaction between pickling in ipython
and unpickling elsewhere.

Cheers,

f


From fperez.net at gmail.com  Thu Aug 10 14:28:08 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 10 Aug 2006 12:28:08 -0600
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <ebep0f$c6i$1@sea.gmane.org>
References: <ebep0f$c6i$1@sea.gmane.org>
Message-ID: <db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>

On 8/10/06, Alexander Belchenko <bialix at ukr.net> wrote:
> This bug appears in IPython with readline installed and without also. It
> was with in Gary Bishop UNC readline and is with pyreadline 1.3 too.
> When I type russian text as unicode string (u"") IPython does not decode
> it to unicode correctly. Standard python interpreter does it well.
>
> Below is reproduction for russian word "????" (it's means "Test" in english)
>
> Standard python interpreter:
>
> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> a = u"????"
> >>> a
> u'\u0422\u0435\u0441\u0442'
>
> All correct.
>
>
> IPython session:
>
> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.7.2 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
>
> In [1]: a = u"????"
>
> In [2]: a
> Out[2]: u'\x92\xa5\xe1\xe2'
>
> As you can see it's incorrect -- it's not russian unicode string.

Hmm, I know precious little about unicode, so I'm not too surprised to
hear of problems.  Here's what I see on my system:

planck[travel]> python
Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
[GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = u"????"
>>> a
u'\xd0\xa2\xd0\xb5\xd1\x81\xd1\x82'

Could you please try this?

>>> str(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-7: ordinal not in range(128)
>>>

I actually get identical results for python and ipython, so it must be
a locale-related thing.  If you can tell us what environment variables
need to be set, perhaps we might track this one down.

Help from non-US-based users would be greatly appreciated, I'm a bit lost here.

Cheers,

f

From vivainio at gmail.com  Thu Aug 10 14:45:23 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 10 Aug 2006 21:45:23 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <db6b5ecc0608101111y720493ebkbed3f72b6bd02a02@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
	<db6b5ecc0608101111y720493ebkbed3f72b6bd02a02@mail.gmail.com>
Message-ID: <46cb515a0608101145x7c36c31fwe38e1b364407fc39@mail.gmail.com>

On 8/10/06, Fernando Perez <fperez.net at gmail.com> wrote:

> No, FakeModule is much, much older.  I wrote that code years ago,

Yeah, rev 8 in fact.
> patches until then.  But for testing purposes, try various
> combinations of pickling reasonably complex things from the command
> line and unpickling them, and do so crossing boundaries between
> pickling things interactively and unpickling them from a pure python
> script (run without ipython) and viceversa.  There's a chance the
> problem was some kind of bad interaction between pickling in ipython
> and unpickling elsewhere.

It's almost certain that every instance from non-__main__ module
pickles correctly b/w python and ipython.

In %run, the following works correctly w/ fm2.diff patch:

class C:
    def hi(self):
        self.a = 10

c = C()

import pickle
pickle.dump(c,open("a.pickle","w"))
print pickle.load(open("a.pickle"))

However, that one fails in interactive prompt because InteractiveShell
thinks it's in FakeModule (iplib.py line 317) and with fm2.diff, the
user_ns != FakeModule.__dict__ and unpickle fails with:

/usr/lib/python2.3/pickle.py in find_class(self, module, name)
   1138         __import__(module)
   1139         mod = sys.modules[module]
-> 1140         klass = getattr(mod, name)
   1141         return klass
   1142

AttributeError: 'FakeModule' object has no attribute 'C'

It's a hard call, but I guess this is functionality we *could* afford
to lose, esp. if it fixes inspect.py problems. I'll still try to make
this work though.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From vivainio at gmail.com  Thu Aug 10 15:08:25 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 10 Aug 2006 22:08:25 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <46cb515a0608101145x7c36c31fwe38e1b364407fc39@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
	<db6b5ecc0608101111y720493ebkbed3f72b6bd02a02@mail.gmail.com>
	<46cb515a0608101145x7c36c31fwe38e1b364407fc39@mail.gmail.com>
Message-ID: <46cb515a0608101208h2fe164f0j7ffe30a24fd0f70@mail.gmail.com>

On 8/10/06, Ville Vainio <vivainio at gmail.com> wrote:

> It's a hard call, but I guess this is functionality we *could* afford
> to lose, esp. if it fixes inspect.py problems. I'll still try to make
> this work though.

I think it works now (fm3.diff, attached. Please apply against HEAD,
not fm2.diff).

FakeModule now "forwards" all getattr calls to the dictionary it was
instantiated with:

     def __getattr__(self,key):
-        try:
-            return self.__dict__[key]
-        except KeyError, e:
-            raise AttributeError("FakeModule object has no attribute %s" % e)
-
+       try:
+           return self.__origdict[key]
+       except KeyError, e:
+           raise AttributeError("FakeModule object has no attribute %s" % e)
+

If everything goes w/o a hitch tomorrow I think I'll push this to
trunk for the unwary users :-).

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fm3.diff
Type: text/x-patch
Size: 7053 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060810/69515df2/attachment.bin>

From vivainio at gmail.com  Thu Aug 10 15:14:14 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 10 Aug 2006 22:14:14 +0300
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>
References: <ebep0f$c6i$1@sea.gmane.org>
	<db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>
Message-ID: <46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>

On 8/10/06, Fernando Perez <fperez.net at gmail.com> wrote:

> Help from non-US-based users would be greatly appreciated, I'm a bit lost here.

Or non-scandinavian. Things work fine for iso-8859-15 because
scandinavian characters fit into the 8 bits.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From walter at livinglogic.de  Thu Aug 10 19:12:36 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 11 Aug 2006 01:12:36 +0200
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>
References: <ebep0f$c6i$1@sea.gmane.org>	<db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>
	<46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>
Message-ID: <44DBBD64.5060201@livinglogic.de>

Ville Vainio wrote:
> On 8/10/06, Fernando Perez <fperez.net at gmail.com> wrote:
> 
>> Help from non-US-based users would be greatly appreciated, I'm a bit lost here.
> 
> Or non-scandinavian. Things work fine for iso-8859-15 because
> scandinavian characters fit into the 8 bits.

It might have to do with locale settings. What does the following output 
on the OPs computer?

In [1]: import sys
In [2]: sys.stdin.encoding

Servus,
    Walter


From bialix at ukr.net  Fri Aug 11 02:56:51 2006
From: bialix at ukr.net (Alexander Belchenko)
Date: Fri, 11 Aug 2006 09:56:51 +0300
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <44DBBD64.5060201@livinglogic.de>
References: <ebep0f$c6i$1@sea.gmane.org>	<db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>	<46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>
	<44DBBD64.5060201@livinglogic.de>
Message-ID: <ebh9k8$2hb$1@sea.gmane.org>

Walter D?rwald ?????:
> Ville Vainio wrote:
>> On 8/10/06, Fernando Perez <fperez.net at gmail.com> wrote:
>>
>>> Help from non-US-based users would be greatly appreciated, I'm a bit lost here.
>> Or non-scandinavian. Things work fine for iso-8859-15 because
>> scandinavian characters fit into the 8 bits.
> 
> It might have to do with locale settings. What does the following output 
> on the OPs computer?
> 
> In [1]: import sys
> In [2]: sys.stdin.encoding

My console encoding is cp866 (russian windows console):

In [1]: import sys

In [2]: sys.stdout.encoding
Out[2]: 'cp866'

In [3]: sys.stdin.encoding
Out[3]: 'cp866'

--
Alexander



From vivainio at gmail.com  Fri Aug 11 04:50:08 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 11 Aug 2006 11:50:08 +0300
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <ebh9k8$2hb$1@sea.gmane.org>
References: <ebep0f$c6i$1@sea.gmane.org>
	<db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>
	<46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>
	<44DBBD64.5060201@livinglogic.de> <ebh9k8$2hb$1@sea.gmane.org>
Message-ID: <46cb515a0608110150h1e684f15o2e1a9153d733b6d@mail.gmail.com>

On 8/11/06, Alexander Belchenko <bialix at ukr.net> wrote:

> My console encoding is cp866 (russian windows console):
>
> In [1]: import sys
>
> In [2]: sys.stdout.encoding
> Out[2]: 'cp866'
>
> In [3]: sys.stdin.encoding
> Out[3]: 'cp866'

And what's the encoding in normal python prompt?

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From vivainio at gmail.com  Fri Aug 11 05:21:31 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 11 Aug 2006 12:21:31 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <46cb515a0608101208h2fe164f0j7ffe30a24fd0f70@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
	<db6b5ecc0608101111y720493ebkbed3f72b6bd02a02@mail.gmail.com>
	<46cb515a0608101145x7c36c31fwe38e1b364407fc39@mail.gmail.com>
	<46cb515a0608101208h2fe164f0j7ffe30a24fd0f70@mail.gmail.com>
Message-ID: <46cb515a0608110221r471c661ex1ee2d24a94e15699@mail.gmail.com>

On 8/10/06, Ville Vainio <vivainio at gmail.com> wrote:

> I think it works now (fm3.diff, attached. Please apply against HEAD,
> not fm2.diff).
>
> FakeModule now "forwards" all getattr calls to the dictionary it was
> instantiated with:
>
>      def __getattr__(self,key):
> -        try:
> -            return self.__dict__[key]
> -        except KeyError, e:
> -            raise AttributeError("FakeModule object has no attribute %s" % e)
> -
> +       try:
> +           return self.__origdict[key]
> +       except KeyError, e:
> +           raise AttributeError("FakeModule object has no attribute %s" % e)
> +
>
> If everything goes w/o a hitch tomorrow I think I'll push this to
> trunk for the unwary users :-).

It's now in trunk; the only thing that needed changing was
FakeModule.py, Magic.py changes were made redundant by forwarding
fakemodule getattr's to the provided dictionary.

The monkeypatch is now removed.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From bialix at ukr.net  Fri Aug 11 05:31:30 2006
From: bialix at ukr.net (Alexander Belchenko)
Date: Fri, 11 Aug 2006 12:31:30 +0300
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <46cb515a0608110150h1e684f15o2e1a9153d733b6d@mail.gmail.com>
References: <ebep0f$c6i$1@sea.gmane.org>	<db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>	<46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>	<44DBBD64.5060201@livinglogic.de>
	<ebh9k8$2hb$1@sea.gmane.org>
	<46cb515a0608110150h1e684f15o2e1a9153d733b6d@mail.gmail.com>
Message-ID: <ebhim6$skf$1@sea.gmane.org>

Ville Vainio ?????:
> On 8/11/06, Alexander Belchenko <bialix at ukr.net> wrote:
> 
>> My console encoding is cp866 (russian windows console):
>>
>> In [1]: import sys
>>
>> In [2]: sys.stdout.encoding
>> Out[2]: 'cp866'
>>
>> In [3]: sys.stdin.encoding
>> Out[3]: 'cp866'
> 
> And what's the encoding in normal python prompt?
> 
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys
 >>> sys.stdout.encoding
'cp866'
 >>> sys.stdin.encoding
'cp866'
 >>>



From fperez.net at gmail.com  Fri Aug 11 22:27:08 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 11 Aug 2006 20:27:08 -0600
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <46cb515a0608110221r471c661ex1ee2d24a94e15699@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
	<db6b5ecc0608101111y720493ebkbed3f72b6bd02a02@mail.gmail.com>
	<46cb515a0608101145x7c36c31fwe38e1b364407fc39@mail.gmail.com>
	<46cb515a0608101208h2fe164f0j7ffe30a24fd0f70@mail.gmail.com>
	<46cb515a0608110221r471c661ex1ee2d24a94e15699@mail.gmail.com>
Message-ID: <db6b5ecc0608111927i16f9c34bu7579b0a92459afe4@mail.gmail.com>

On 8/11/06, Ville Vainio <vivainio at gmail.com> wrote:

> > If everything goes w/o a hitch tomorrow I think I'll push this to
> > trunk for the unwary users :-).
>
> It's now in trunk; the only thing that needed changing was
> FakeModule.py, Magic.py changes were made redundant by forwarding
> fakemodule getattr's to the provided dictionary.
>
> The monkeypatch is now removed.

Well, the unwary user would be me in this case :(

Your patch broke unittest somehow.  Using

#Listing for unitt.py
"Trivial unittest example"
import unittest
class fooTestCase(unittest.TestCase):
    def test1(self): pass
    def test2(self): pass
unittest.main()
# EOF

I get with revision 1601:
In [1]: run -e unitt
..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

which is the expected result.  But r1602, which is where you applied
this, gives:


In [1]: run -e unitt

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK


All unit tests are silently ignored.

I'm leaving for a conference (scipy'06) on Monday and have a TON of
stuff to prepare, so I'll simply revert my private copy to r1601 while
you have a chance to work on this.  If we can't get to a satisfactory
solution, we'll revert this and go back to the monkeypatch solution.
It may not be elegant, but 'actually working' counts in my book for a
lot.

Cheers,

f


From vivainio at gmail.com  Sat Aug 12 05:32:25 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 12 Aug 2006 12:32:25 +0300
Subject: [IPython-dev] [Fwd: [afayolle@debian.org: Bug#374625:
	python2.3-ipython: help built-in function does not work]]
In-Reply-To: <db6b5ecc0608111927i16f9c34bu7579b0a92459afe4@mail.gmail.com>
References: <44D98C60.9060809@colorado.edu>
	<46cb515a0608090124r216167b9v12239f3a87aa1091@mail.gmail.com>
	<db6b5ecc0608091030j5df06f55ycc32c55e519daf9d@mail.gmail.com>
	<46cb515a0608100026k54310832lb0a45de466c6a5f3@mail.gmail.com>
	<db6b5ecc0608101111y720493ebkbed3f72b6bd02a02@mail.gmail.com>
	<46cb515a0608101145x7c36c31fwe38e1b364407fc39@mail.gmail.com>
	<46cb515a0608101208h2fe164f0j7ffe30a24fd0f70@mail.gmail.com>
	<46cb515a0608110221r471c661ex1ee2d24a94e15699@mail.gmail.com>
	<db6b5ecc0608111927i16f9c34bu7579b0a92459afe4@mail.gmail.com>
Message-ID: <46cb515a0608120232p3025e97bi505c8973f94e3c87@mail.gmail.com>

On 8/12/06, Fernando Perez <fperez.net at gmail.com> wrote:

> All unit tests are silently ignored.
>
> I'm leaving for a conference (scipy'06) on Monday and have a TON of
> stuff to prepare, so I'll simply revert my private copy to r1601 while
> you have a chance to work on this.  If we can't get to a satisfactory
> solution, we'll revert this and go back to the monkeypatch solution.
> It may not be elegant, but 'actually working' counts in my book for a
> lot.

Damnit, I guess we'll need to go with the monkeypatch then :-(.

The whole issue is in the "works for some reason" area of python, so
elegance can be ignored at this point I guess...

-- 
Ville Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From akinoame1 at gmail.com  Sun Aug 13 09:47:27 2006
From: akinoame1 at gmail.com (Denis Simakov)
Date: Sun, 13 Aug 2006 16:47:27 +0300
Subject: [IPython-dev] Bug: unicode and IPython
In-Reply-To: <46cb515a0608110150h1e684f15o2e1a9153d733b6d@mail.gmail.com>
References: <ebep0f$c6i$1@sea.gmane.org>
	<db6b5ecc0608101128m1ae8c941r181a48d3eed5fae2@mail.gmail.com>
	<46cb515a0608101214t38476876neaa159601bbe79bf@mail.gmail.com>
	<44DBBD64.5060201@livinglogic.de> <ebh9k8$2hb$1@sea.gmane.org>
	<46cb515a0608110150h1e684f15o2e1a9153d733b6d@mail.gmail.com>
Message-ID: <73eb51090608130647q7e4b119dl317afac351dc3778@mail.gmail.com>

I have 'UTF-8' for all the cases (ipython and python,
sys.stdin.encoding and sys.stdout.encoding).

(And I see the same bug with unicode as described by Alexander.)

Denis


On 8/11/06, Ville Vainio <vivainio at gmail.com> wrote:
> On 8/11/06, Alexander Belchenko <bialix at ukr.net> wrote:
>
> > My console encoding is cp866 (russian windows console):
> >
> > In [1]: import sys
> >
> > In [2]: sys.stdout.encoding
> > Out[2]: 'cp866'
> >
> > In [3]: sys.stdin.encoding
> > Out[3]: 'cp866'
>
> And what's the encoding in normal python prompt?
>
> --
> Ville Vainio - vivainio.googlepages.com
> vainio.blogspot.com - g[mail | talk]='vivainio'


From stefan at sun.ac.za  Tue Aug 15 13:13:50 2006
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Tue, 15 Aug 2006 19:13:50 +0200
Subject: [IPython-dev] timeit bug
Message-ID: <20060815171350.GA32301@mentat.za.net>

Hi all,

Can anyone confirm the following behaviour with the latest trunk?

In [1]: timeit print('x')
---------------------------------------------------------------------------
exceptions.NameError                                 Traceback (most recent call last)

/tmp/<ipython console>

/home/stefan/lib/python2.4/site-packages/IPython/iplib.py in ipmagic(self, arg_s)
    866         else:
    867             magic_args = self.var_expand(magic_args)
--> 868             return fn(magic_args)
    869
    870     def ipalias(self,arg_s):

/home/stefan/lib/python2.4/site-packages/IPython/Magic.py in magic_timeit(self, parameter_s)
   1677             for i in range(1, 10):
   1678                 number *= 10
-> 1679                 if timer.timeit(number) >= 0.2:
   1680                     break
   1681

/usr/lib/python2.4/timeit.py in timeit(self, number)
    159         gcold = gc.isenabled()
    160         gc.disable()
--> 161         timing = self.inner(it, self.timer)
    162         if gcold:
    163             gc.enable()

/tmp/<magic-timeit> in inner(_it, _timer)

NameError: global name 'x' is not defined

Regards
St?fan


From vivainio at gmail.com  Thu Aug 17 11:24:05 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 17 Aug 2006 18:24:05 +0300
Subject: [IPython-dev] sys.path in python != sys.path in ipython
Message-ID: <46cb515a0608170824o6d004354vceb0774e44e530c0@mail.gmail.com>

Just noticed this in a blog (via planet python):

http://bruynooghe.blogspot.com/2006/08/todays-wtf-syspath-in-python-syspath.html

Just a heads up; I am unable to look into this at the moment (waiting
to get my home computer fixed and using an "interim" computer in the
meantime), perhaps next week.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From walter at livinglogic.de  Thu Aug 17 13:24:09 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 17 Aug 2006 19:24:09 +0200
Subject: [IPython-dev] sys.path in python != sys.path in ipython
In-Reply-To: <46cb515a0608170824o6d004354vceb0774e44e530c0@mail.gmail.com>
References: <46cb515a0608170824o6d004354vceb0774e44e530c0@mail.gmail.com>
Message-ID: <44E4A639.9040606@livinglogic.de>

Ville Vainio wrote:
> Just noticed this in a blog (via planet python):
> 
> http://bruynooghe.blogspot.com/2006/08/todays-wtf-syspath-in-python-syspath.html
> 
> Just a heads up; I am unable to look into this at the moment (waiting
> to get my home computer fixed and using an "interim" computer in the
> meantime), perhaps next week.

Somewhat related. It's unfortunate that the package IPython.Extensions
is itself on the path, which leads to strange things like:

In [1]: from IPython.Extensions import path as p1
In [2]: import path as p2
In [3]: p1
Out[3]: <module 'IPython.Extensions.path' from
'/usr/local/lib/python2.4/site-packages/ipython-0.7.2-py2.4.egg/IPython/Extensions/path.pyc'>
In [4]: p2
Out[4]: <module 'path' from
'/usr/local/lib/python2.4/site-packages/ipython-0.7.2-py2.4.egg/IPython/Extensions/path.pyc'>
In [5]: p1 is p2
Out[5]: False
In [6]: p1.path is p2.path
Out[6]: False
In [7]:

Servus,
   Walter