headers
Thorsten Kampe | 1 Apr 17:57
Picon
Favicon

Re: bug in coloured prompt

* Thorsten Kampe (Wed, 28 Mar 2007 22:30:25 +0100)
> [IPython 0.7.3 and 0.7.4]
> 
> Hi,
> 
> "\#" (maybe other special escapes, too) ignores the colour escape codes 
> in prompts. See for instance [1]. The "\#" is printed in green (although 
> it should be white. Same goes for the out prompt where it's printed in 
> red.
> 
> Thorsten
> [1] prompt_in1 '\C_White[\#\C_White]\C_LightCyan>>> '

Can someone confirm that this is a bug?
Permalink | Reply | 0 comments |
headers
Fernando Perez | 1 Apr 22:54
Picon
Gravatar

Re: [IPython-dev] bug in coloured prompt

On 4/1/07, Thorsten Kampe <thorsten <at> thorstenkampe.de> wrote:
> * Thorsten Kampe (Wed, 28 Mar 2007 22:30:25 +0100)
> > [IPython 0.7.3 and 0.7.4]
> >
> > Hi,
> >
> > "\#" (maybe other special escapes, too) ignores the colour escape codes
> > in prompts. See for instance [1]. The "\#" is printed in green (although
> > it should be white. Same goes for the out prompt where it's printed in
> > red.
> >
> > Thorsten
> > [1] prompt_in1 '\C_White[\#\C_White]\C_LightCyan>>> '
>
> Can someone confirm that this is a bug?

Well, it's more of a design limitation, or a not-implemented feature
than a 'oops, little bug we missed' kind of thing.  The original
coloring code, when I wrote it, hardcoded a color scheme for certain
items.  The templates that handle coloring perform this expansion:

    r'\#' : '${self.col_num}' '${self.cache.prompt_count}' '${self.col_p}',

With self.col_num being hardcoded in the color tables defined in
Prompts.py.  These are, at this point, not really user-extensible in
any convenient way.  Having a cleaner way for users to define their
own color schemes is certainly on the ToDo list, and we'll visit it
when we split out the I/O code.

In the meantime, you can work around the problem by using the raw
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patricio Olivares | 1 Apr 23:18

ipython 0.7.3 vs. django (python 2.5)

Hi,
I'm trying ipython 0.7.3 with django on a python 2.5 install.
When ipython try to index the modules (for example when I type "import
<TAB>"), I get a traceback from django. See <http://pastebin.ca/420048>.

The steps I did were:
- install a fresh python 2.5 release from sources on /tmp/yo
- install ipython 0.7.3 (using /tmp/yo/bin/python setup.py install)
- install django from svn
(<http://code.djangoproject.com/svn/django/trunk/>). The release 0.9.6
gives the error too.

All of this on ubuntu dapper. After entering ipython and doing "import
<TAB>" or "from <TAB>" I got the traceback.

Django has some weird setting requirements so maybe there's a way
to exclude it from the scanning?
Permalink | Reply | 11 comments |
headers
Robert Kern | 1 Apr 23:40
Picon
Gravatar

Re: ipython 0.7.3 vs. django (python 2.5)

Patricio Olivares wrote:
> Hi,
> I'm trying ipython 0.7.3 with django on a python 2.5 install.
> When ipython try to index the modules (for example when I type "import
> <TAB>"), I get a traceback from django. See <http://pastebin.ca/420048>.
> 
> The steps I did were:
> - install a fresh python 2.5 release from sources on /tmp/yo
> - install ipython 0.7.3 (using /tmp/yo/bin/python setup.py install)
> - install django from svn
> (<http://code.djangoproject.com/svn/django/trunk/>). The release 0.9.6
> gives the error too.
> 
> All of this on ubuntu dapper. After entering ipython and doing "import
> <TAB>" or "from <TAB>" I got the traceback.
> 
> 
> Django has some weird setting requirements so maybe there's a way
> to exclude it from the scanning?

I had too many problems with other packages, too, so I've turned off that
particular feature. It uses the standard library function
pkgutil.walk_packages() which has some unfortunate (and for my use,
unacceptable) side effects. Note this paragraph in its docstring:

    Note that this function must import all *packages* (NOT all
    modules!) on the given path, in order to access the __path__
    attribute to find submodules.

No, there's no real way to exclude a package except by using something other
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Perez | 2 Apr 07:40
Picon
Gravatar

Re: Fwd: Preparing for the 0.7.4 release

On 3/23/07, Stefan van der Walt <stefan <at> sun.ac.za> wrote:

> I don't suggest you apply the attached patch, but it serves to
> demonstrate the workaround.

Thanks, Stefan.  I did something slightly different, but r2195 works
for me with Jorgen's original problematic example.  I think the point
is to ensure that the various points in the code that produce
variables susceptible of being treated as a Python identifier do so
via

.encode('ascii')

since pyhton itself mandates pure ascii for identifiers.  I'm trying
to enforce that rule strictly now, though I may still have missed a
few locations.

I didn't modify _ofind because I expect that it should always be
called with valid ascii, so it shouldn't be protecting itself.  We
should rather ensure that we don't feed it unicode, there's only a few
points where data flows into it and those can be well controlled.
Since the bulk of those start with input from split_user_input(),
that's what I fixed.

Feel free to continue sumbitting problem reports...

Cheers,

f
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Perez | 2 Apr 08:09
Picon
Gravatar

New mailing lists for SVN commits and Trac tickets

Howdy,

thanks to R. Kern and Jeff Strunk (from Enthought) we now have mailing
lists that automatically generate messages when there are commits to
SVN (including diffs) and activity on Track tickets:

http://lists.ipython.scipy.org/mailman/listinfo/ipython-svndiff
http://lists.ipython.scipy.org/mailman/listinfo/ipython-tickets

Anyone is obviously free to sign up, but I'd like to especially
encourage the devs to be on at the very least the tickets one, so we
don't miss activity there for lack of checking the site.  If you have
a good RSS-based workflow you're happy with, using the Trac timeline
RSS feed, just feel free to ignore the suggestion.

Cheers,

f
Permalink | Reply | 0 comments |
headers
Robert Kern | 2 Apr 08:13
Picon
Gravatar

Re: New mailing lists for SVN commits and Trac tickets

Fernando Perez wrote:
> Howdy,
> 
> thanks to R. Kern and Jeff Strunk (from Enthought) we now have mailing
> lists that automatically generate messages when there are commits to
> SVN (including diffs) and activity on Track tickets:
> 
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-svndiff
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-tickets

There is also a list for SVN commits with just a summary and not the diffs
(which can sometimes be rather large).

  http://lists.ipython.scipy.org/mailman/listinfo/ipython-svn

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
Permalink | Reply | 0 comments |
headers
Fernando Perez | 2 Apr 08:29
Picon
Gravatar

Re: New mailing lists for SVN commits and Trac tickets

On 4/2/07, Robert Kern <robert.kern <at> gmail.com> wrote:

> There is also a list for SVN commits with just a summary and not the diffs
> (which can sometimes be rather large).

Thanks, somehow I missed that one.  Fixed the Moin wiki as well.

Cheers,

f
Permalink | Reply | 0 comments |
headers
Thorsten Kampe | 2 Apr 09:59
Picon
Favicon

Re: [IPython-dev] bug in coloured prompt

* Fernando Perez (Sun, 1 Apr 2007 14:54:20 -0600)
> On 4/1/07, Thorsten Kampe <thorsten <at> thorstenkampe.de> wrote:
> > * Thorsten Kampe (Wed, 28 Mar 2007 22:30:25 +0100)
> > > [IPython 0.7.3 and 0.7.4]
> > >
> > > Hi,
> > >
> > > "\#" (maybe other special escapes, too) ignores the colour escape codes
> > > in prompts. See for instance [1]. The "\#" is printed in green (although
> > > it should be white. Same goes for the out prompt where it's printed in
> > > red.
> > >
> > > Thorsten
> > > [1] prompt_in1 '\C_White[\#\C_White]\C_LightCyan>>> '
> >
> > Can someone confirm that this is a bug?
> 
> Well, it's more of a design limitation, or a not-implemented feature
> than a 'oops, little bug we missed' kind of thing.  The original
> coloring code, when I wrote it, hardcoded a color scheme for certain
> items.

Well, if you had mentioned that in the documentation, you wouldn't 
have had to write a patch ;-P .

> But if you update to SVN, I just added a new prompt escape,
> 
> \N
> 
> which is identical to \# but does NOT apply any coloring.  Using \N
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Pye | 2 Apr 11:50
Picon
Picon

Error when importing module into ipython

Hi all

I have a python module that I've developed. It's C++ code wrapped with
SWIG to provide steam properties for use in engineering calculations.

But I've just noticed that it won't import correctly under IPython 0.7.3
on Python 2.4.2 on Windows XP. I get an error message like shown below. 

The funny thing is that I can import the package fine under the standard 
vanilla python console, and there are no errors (even when I run type
'S = freesteam.steam_pT(); del S', which the following would suggest 
could have failed). And it imports fine under IPython 0.7.2 on Linux 
as well.

Any suggestions on what I could be doing wrong here?

Cheers
JP

http://freesteam.sourceforge.net/

In [1]: from freesteam import *
---------------------------------------------------------------------------
exceptions.AttributeError                            Traceback (most
recent call
 last)

C:\Documents and Settings\john\<ipython console>

C:\Python24\lib\site-packages\freesteam.py
(Continue reading)

Permalink | Reply | 4 comments |

Gmane