From vivainio at gmail.com  Thu Jan  5 08:05:47 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 5 Jan 2006 15:05:47 +0200
Subject: [IPython-dev] Autocall doesn't work when function requires no
	arguments - where is	the FULL option?
Message-ID: <46cb515a0601050505q394d9787m19bd1cdfe8fa635b@mail.gmail.com>

I'm using the latest SVN and am trying to call a function that takes
only keyword args - should be readily autocallable even without args.
Wasn't there supposed to be a FULL option in addition to SMART mode?

Here's the session that illustrates the point:

[opt\environmentswitch]|1> up??
Type:           function
Base Class:     <type 'function'>
String Form:    <function up at 0x01018F30>
Namespace:      Interactive
File:           c:\home\_ipython\gutils.py
Definition:     up(levels=1)
Source:
def up(levels=1):
    """ chdir up in tree, optionally specifying depth """
    for l in range(levels):
        os.chdir("..")
        if levels!=1:
            print "->",os.getcwd()
[opt\environmentswitch]|2> up 1
-------------------------> up(1)
[C:\opt]|3> up
        <3> <function up at 0x01018F30>
[C:\opt]|4> %autocall
Automatic calling is: OFF
[C:\opt]|5> %autocall
Automatic calling is: Smart
[C:\opt]|6> %autocall
Automatic calling is: OFF
[C:\opt]|7> %autocall
Automatic calling is: Smart
[C:\opt]|8> up
        <8> <function up at 0x01018F30>

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Thu Jan  5 12:04:16 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 05 Jan 2006 10:04:16 -0700
Subject: [IPython-dev] Autocall doesn't work when function requires no
 arguments - where is	the FULL option?
In-Reply-To: <46cb515a0601050505q394d9787m19bd1cdfe8fa635b@mail.gmail.com>
References: <46cb515a0601050505q394d9787m19bd1cdfe8fa635b@mail.gmail.com>
Message-ID: <43BD5190.5040702@colorado.edu>

Ville Vainio wrote:
> I'm using the latest SVN and am trying to call a function that takes
> only keyword args - should be readily autocallable even without args.
> Wasn't there supposed to be a FULL option in addition to SMART mode?
> 
> Here's the session that illustrates the point:

Yup: set 'autocall' to 2 for the FULL mode.

Let me know if it doesn't work (I did test it on my box, and it was OK).

Cheers,

f



From Fernando.Perez at colorado.edu  Thu Jan  5 13:54:15 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 05 Jan 2006 11:54:15 -0700
Subject: [IPython-dev] Autocall doesn't work when function requires no
 arguments - where is	the FULL option?
In-Reply-To: <46cb515a0601050505q394d9787m19bd1cdfe8fa635b@mail.gmail.com>
References: <46cb515a0601050505q394d9787m19bd1cdfe8fa635b@mail.gmail.com>
Message-ID: <43BD6B57.9000505@colorado.edu>

Ville Vainio wrote:
> I'm using the latest SVN and am trying to call a function that takes
> only keyword args - should be readily autocallable even without args.
> Wasn't there supposed to be a FULL option in addition to SMART mode?

sorry, the %autocall toggle is broken, I'll fix it tonight (busy now).

In the meantime, you can set the value manually

__IP.rc.autocall = {0->off,1->smart,2->full}

Cheers,

f



From Fernando.Perez at colorado.edu  Sun Jan  8 03:27:55 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 08 Jan 2006 01:27:55 -0700
Subject: [IPython-dev] Autocall doesn't work when function requires no
 arguments - where is	the FULL option?
In-Reply-To: <43BD6B57.9000505@colorado.edu>
References: <46cb515a0601050505q394d9787m19bd1cdfe8fa635b@mail.gmail.com>
	<43BD6B57.9000505@colorado.edu>
Message-ID: <43C0CD0B.5010205@colorado.edu>

Fernando Perez wrote:
> Ville Vainio wrote:
> 
>>I'm using the latest SVN and am trying to call a function that takes
>>only keyword args - should be readily autocallable even without args.
>>Wasn't there supposed to be a FULL option in addition to SMART mode?
> 
> 
> sorry, the %autocall toggle is broken, I'll fix it tonight (busy now).
> 
> In the meantime, you can set the value manually
> 
> __IP.rc.autocall = {0->off,1->smart,2->full}


Fixed.

f



From arnd.baecker at web.de  Sun Jan  8 09:19:54 2006
From: arnd.baecker at web.de (Arnd Baecker)
Date: Sun, 8 Jan 2006 15:19:54 +0100 (CET)
Subject: [IPython-dev] traits/tvtk objects and completion
Message-ID: <Pine.LNX.4.51.0601081516500.17184@ptpcp8.phy.tu-dresden.de>

Hi,

the attached example shows some weirdness
with traits/tvtk objects in that
TAB completion does not work for objects
defined in an embedded shell.

I know, there is quite some magic
going on with the embedding, so this
might be a difficult one...

Best, Arnd

# ----- tab_completion_tst.py
from enthought.tvtk import tvtk

from IPython.Shell import IPShellEmbed
ipshell = IPShellEmbed()

cone = tvtk.ConeSource()

print "At the prompt do:"
print "c = cone"
print "then try"
print "  cone.<TAB>"
print "vs."
print "  c.<TAB>"
print "note: `c==cone` gives True"

ipshell()



-------------- next part --------------
A non-text attachment was scrubbed...
Name: tab_completion_tst.py
Type: text/x-python
Size: 327 bytes
Desc: 
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060108/ee33a03f/attachment.py>

From prabhu_r at users.sf.net  Sun Jan  8 10:53:05 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sun, 8 Jan 2006 21:23:05 +0530
Subject: [IPython-dev] traits/tvtk objects and completion
In-Reply-To: <Pine.LNX.4.51.0601081516500.17184@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0601081516500.17184@ptpcp8.phy.tu-dresden.de>
Message-ID: <17345.13665.486838.590330@monster.iitb.ac.in>

>>>>> "Arnd" == Arnd Baecker <arnd.baecker at web.de> writes:

    Arnd> Hi, the attached example shows some weirdness with
    Arnd> traits/tvtk objects in that TAB completion does not work for
    Arnd> objects defined in an embedded shell.

FWIW this seems to work for me under IPython-0.6.15.

cheers,
prabhu



From arnd.baecker at web.de  Sun Jan  8 11:18:27 2006
From: arnd.baecker at web.de (Arnd Baecker)
Date: Sun, 8 Jan 2006 17:18:27 +0100 (CET)
Subject: [IPython-dev] traits/tvtk objects and completion
In-Reply-To: <17345.13665.486838.590330@monster.iitb.ac.in>
References: <Pine.LNX.4.51.0601081516500.17184@ptpcp8.phy.tu-dresden.de>
	<17345.13665.486838.590330@monster.iitb.ac.in>
Message-ID: <Pine.LNX.4.51.0601081716240.17698@ptpcp8.phy.tu-dresden.de>

On Sun, 8 Jan 2006, Prabhu Ramachandran wrote:

> >>>>> "Arnd" == Arnd Baecker <arnd.baecker at web.de> writes:
>
>     Arnd> Hi, the attached example shows some weirdness with
>     Arnd> traits/tvtk objects in that TAB completion does not work for
>     Arnd> objects defined in an embedded shell.
>
> FWIW this seems to work for me under IPython-0.6.15.

And I just realized, that blaming traits/tvtk is not ok ;-)
just doing this with `import os` and
saying `os_=os` at the ipshell prompt does the same...
(this is for IPython.__version__  '0.7.0.rc8')

Best, Arnd



From Fernando.Perez at colorado.edu  Sun Jan  8 11:19:42 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 08 Jan 2006 09:19:42 -0700
Subject: [IPython-dev] traits/tvtk objects and completion
In-Reply-To: <Pine.LNX.4.51.0601081716240.17698@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0601081516500.17184@ptpcp8.phy.tu-dresden.de>
	<17345.13665.486838.590330@monster.iitb.ac.in>
	<Pine.LNX.4.51.0601081716240.17698@ptpcp8.phy.tu-dresden.de>
Message-ID: <43C13B9E.60904@colorado.edu>

Arnd Baecker wrote:
> On Sun, 8 Jan 2006, Prabhu Ramachandran wrote:
> 
> 
>>>>>>>"Arnd" == Arnd Baecker <arnd.baecker at web.de> writes:
>>
>>    Arnd> Hi, the attached example shows some weirdness with
>>    Arnd> traits/tvtk objects in that TAB completion does not work for
>>    Arnd> objects defined in an embedded shell.
>>
>>FWIW this seems to work for me under IPython-0.6.15.
> 
> 
> And I just realized, that blaming traits/tvtk is not ok ;-)
> just doing this with `import os` and
> saying `os_=os` at the ipshell prompt does the same...
> (this is for IPython.__version__  '0.7.0.rc8')

Gimme a second, will you?  Fix coming... :)

f



From Fernando.Perez at colorado.edu  Sun Jan  8 11:24:30 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 08 Jan 2006 09:24:30 -0700
Subject: [IPython-dev] traits/tvtk objects and completion
In-Reply-To: <43C13B9E.60904@colorado.edu>
References: <Pine.LNX.4.51.0601081516500.17184@ptpcp8.phy.tu-dresden.de>
	<17345.13665.486838.590330@monster.iitb.ac.in>
	<Pine.LNX.4.51.0601081716240.17698@ptpcp8.phy.tu-dresden.de>
	<43C13B9E.60904@colorado.edu>
Message-ID: <43C13CBE.7070204@colorado.edu>

Fernando Perez wrote:
> Arnd Baecker wrote:
> 
>>On Sun, 8 Jan 2006, Prabhu Ramachandran wrote:
>>
>>
>>
>>>>>>>>"Arnd" == Arnd Baecker <arnd.baecker at web.de> writes:
>>>
>>>   Arnd> Hi, the attached example shows some weirdness with
>>>   Arnd> traits/tvtk objects in that TAB completion does not work for
>>>   Arnd> objects defined in an embedded shell.
>>>
>>>FWIW this seems to work for me under IPython-0.6.15.
>>
>>
>>And I just realized, that blaming traits/tvtk is not ok ;-)
>>just doing this with `import os` and
>>saying `os_=os` at the ipshell prompt does the same...
>>(this is for IPython.__version__  '0.7.0.rc8')
> 
> 
> Gimme a second, will you?  Fix coming... :)

Now, that's better.  Please check SVN and let me know how it goes (and yes, 
the bug was not traits-related, it was happening for any local variable 
defined at the embedded prompt).

Good thing I got up early today :)

Cheers,

f



From prabhu_r at users.sf.net  Sun Jan  8 14:05:14 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 9 Jan 2006 00:35:14 +0530
Subject: [IPython-dev] Patch to completer.py
Message-ID: <17345.25194.88304.652490@monster.iitb.ac.in>

Hi Fernando,

I had send you a note off-list about an error with my earlier patch to
support traits.  I haven't heard from you on that.  Attached is a
patch.  I noticed that you are using set.  Set is part of Python-2.4.
So is SVN only for 2.4?

cheers,
prabhu

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: completer.py.patch
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060109/e8303e1d/attachment.ksh>

From Fernando.Perez at colorado.edu  Sun Jan  8 14:59:32 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 08 Jan 2006 12:59:32 -0700
Subject: [IPython-dev] Patch to completer.py
In-Reply-To: <17345.25194.88304.652490@monster.iitb.ac.in>
References: <17345.25194.88304.652490@monster.iitb.ac.in>
Message-ID: <43C16F24.90806@colorado.edu>

Prabhu Ramachandran wrote:
> Hi Fernando,
> 
> I had send you a note off-list about an error with my earlier patch to
> support traits.  I haven't heard from you on that.  Attached is a
> patch.  I noticed that you are using set.  Set is part of Python-2.4.
> So is SVN only for 2.4?

Mmh, I hadn't replied because I never got your message.  I even checked my 
spam inbox for an accidental false positive, but nothing.  Weird.

In any case, I just applied and committed your attached patch, many thanks.

Sets are OK for 2.3 (though they're a module there), so it's no problem (my 
default python is 2.3, so I would have noticed :)

However, this just made me realize that we're not 2.2 compatible anymore...

I'm torn, b/c I've tried to keep 2.2 compatibility for a while, but I just 
realized there's more than the sets call now in ipython.  The sets use could 
easily be avoided with a dict, but there's more, and I don't even know what 
anymore.

So I suspect I'm going to punt and call 0.7.0 a python2.3-based release.  If 
anyone is still stuck with 2.2, I guess they'll just have to live with 0.6.15 
from now on...

I'm too close to a release, and too tight on time, to go hunting for every 
possible non-2.2 feature I may have inadvertedly left slip.

Oh well, 2.3 has been out for quite a while now.

Cheers,

f



From prabhu_r at users.sf.net  Sun Jan  8 23:13:21 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 9 Jan 2006 09:43:21 +0530
Subject: [IPython-dev] Patch to completer.py
In-Reply-To: <43C16F24.90806@colorado.edu>
References: <17345.25194.88304.652490@monster.iitb.ac.in>
	<43C16F24.90806@colorado.edu>
Message-ID: <17345.58081.813150.499995@prpc.aero.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    Fernando> Prabhu Ramachandran wrote:
    >> Hi Fernando,
    >>
    >> I had send you a note off-list about an error with my earlier
    >> patch to support traits.  I haven't heard from you on that.
    >> Attached is a patch.  I noticed that you are using set.  Set is
    >> part of Python-2.4.  So is SVN only for 2.4?

    Fernando> Mmh, I hadn't replied because I never got your message.
    Fernando> I even checked my spam inbox for an accidental false
    Fernando> positive, but nothing.  Weird.

Very wierd.  The message headers should have had this:

 Date: Thu, 5 Jan 2006 23:38:34 +0530
 To: Fernando . dot . Perez [ at ] colorado . dot . edu
 Subject: Error in the patch to support traits.

My MTA logs claim that the message was delivered to the smarthost
here.

    Fernando> In any case, I just applied and committed your attached
    Fernando> patch, many thanks.

Thanks!

    Fernando> Sets are OK for 2.3 (though they're a module there), so
    Fernando> it's no problem (my default python is 2.3, so I would
    Fernando> have noticed :)

Right, I did not look hard enough for set and somehow had the
impression that set is 2.4 only.

    Fernando> However, this just made me realize that we're not 2.2
    Fernando> compatible anymore...
[...]
    Fernando> Oh well, 2.3 has been out for quite a while now.

Yes, 2.3 is fine.  I should have moved to 2.4 but there is so much to
do...

regards,
prabhu



From Fernando.Perez at colorado.edu  Mon Jan  9 00:58:23 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 08 Jan 2006 22:58:23 -0700
Subject: [IPython-dev] Patch to completer.py
In-Reply-To: <17345.58081.813150.499995@prpc.aero.iitb.ac.in>
References: <17345.25194.88304.652490@monster.iitb.ac.in>
	<43C16F24.90806@colorado.edu>
	<17345.58081.813150.499995@prpc.aero.iitb.ac.in>
Message-ID: <43C1FB7F.3040306@colorado.edu>

Prabhu Ramachandran wrote:

> Very wierd.  The message headers should have had this:
> 
>  Date: Thu, 5 Jan 2006 23:38:34 +0530
>  To: Fernando . dot . Perez [ at ] colorado . dot . edu
>  Subject: Error in the patch to support traits.
> 
> My MTA logs claim that the message was delivered to the smarthost
> here.

OK, my fault.  I have no idea how, but I did accidentally delete it.  With the 
subject line, I found it.  Sorry about that.  I certainly wasn't trying to 
ignore you :)

>     Fernando> In any case, I just applied and committed your attached
>     Fernando> patch, many thanks.
> 
> Thanks!
> 
>     Fernando> Sets are OK for 2.3 (though they're a module there), so
>     Fernando> it's no problem (my default python is 2.3, so I would
>     Fernando> have noticed :)
> 
> Right, I did not look hard enough for set and somehow had the
> impression that set is 2.4 only.

We're good.  The way I pulled it in, it will use the normal type from 2.4 
onwards, but it remains 2.3 compatible (though with 2.4-like syntax).

>     Fernando> However, this just made me realize that we're not 2.2
>     Fernando> compatible anymore...
> [...]
>     Fernando> Oh well, 2.3 has been out for quite a while now.
> 
> Yes, 2.3 is fine.  I should have moved to 2.4 but there is so much to
> do...

2.3 was released on July 29, 2003, should be OK.  So I'm going to call it a 
fact and leave it at that, though I will announce this on the release.  Thanks 
for the comments which made me catch this.

Best, and sorry again for the email mixup.  I don't know what happened to me.

f



From prabhu_r at users.sf.net  Mon Jan  9 03:01:20 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 9 Jan 2006 13:31:20 +0530
Subject: [IPython-dev] Patch to completer.py
In-Reply-To: <43C1FB7F.3040306@colorado.edu>
References: <17345.25194.88304.652490@monster.iitb.ac.in>
	<43C16F24.90806@colorado.edu>
	<17345.58081.813150.499995@prpc.aero.iitb.ac.in>
	<43C1FB7F.3040306@colorado.edu>
Message-ID: <17346.6224.802638.305686@prpc.aero.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> My MTA logs claim that the message was delivered to the
    >> smarthost here.

    Fernando> OK, my fault.  I have no idea how, but I did
    Fernando> accidentally delete it.  With the subject line, I found
    Fernando> it.  Sorry about that.  I certainly wasn't trying to
    Fernando> ignore you :)
[...]
    Fernando> Best, and sorry again for the email mixup.  I don't know
    Fernando> what happened to me.

No problem.  Sometimes spam mails have malformed mime and break a mail
reader.  I've lost a few emails that way.  Also, given the amount of
email we handle it is easy to loose them once in a while.  So,
relax. :)

cheers,
prabhu




From arnd.baecker at web.de  Mon Jan  9 03:06:11 2006
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 9 Jan 2006 09:06:11 +0100 (CET)
Subject: [IPython-dev] traits/tvtk objects and completion
In-Reply-To: <43C13CBE.7070204@colorado.edu>
References: <Pine.LNX.4.51.0601081516500.17184@ptpcp8.phy.tu-dresden.de>
	<17345.13665.486838.590330@monster.iitb.ac.in>
	<Pine.LNX.4.51.0601081716240.17698@ptpcp8.phy.tu-dresden.de>
	<43C13B9E.60904@colorado.edu> <43C13CBE.7070204@colorado.edu>
Message-ID: <Pine.LNX.4.51.0601081948200.18171@ptpcp8.phy.tu-dresden.de>

On Sun, 8 Jan 2006, Fernando Perez wrote:

> Fernando Perez wrote:

[...]

> > Gimme a second, will you?  Fix coming... :)

Sure - even though I am normally spoilt by your time-machines ;-)
((not that this mail comes really late, as I could not send
mails last night ...))

> Now, that's better.  Please check SVN and let me know how it goes (and yes,
> the bug was not traits-related, it was happening for any local variable
> defined at the embedded prompt).
>
> Good thing I got up early today :)

Excellent - works fine now!

Many thanks, Arnd



From Fernando.Perez at colorado.edu  Tue Jan 10 03:48:38 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 10 Jan 2006 01:48:38 -0700
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
Message-ID: <43C374E6.8030602@colorado.edu>

Hi all,

After a long hiatus (0.6.15 was out in June of 2005), I'm glad to announce the 
release of IPython 0.7.0, with lots of new features (the _code_ diff from the 
previous release is almost 9000 lines long, so there's quite a bit in here).

IPython's homepage is at:

http://ipython.scipy.org

and downloads are at:

http://ipython.scipy.org/dist

I've provided:

  - source downloads (.tar.gz)
  - RPMs (for Python 2.3 and 2.4, built under Fedora Core 3).
  - Python Eggs (http://peak.telecommunity.com/DevCenter/PythonEggs).
  - a native win32 installer for both Python 2.3 and 2.4.

Fedora users should note that IPython is now officially part of the Extras 
repository, so they can get the update from there as well (though it may lag 
by a few days).

Debian, Fink and BSD packages for this version should be coming soon, as the
respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice
Liu) have the time to follow their packaging procedures.

A lot of new features have gone into this release, the bulk of which were 
driven by user feedback and requests, and more importantly by patches from 
IPython users.  I greatly appreciate these contributions, and hope they will 
continue in the future.  In particular, thanks to Vivian de Smedt, Jorgen 
Stenarsson and Ville Vainio, who contributed large patches with much of the 
new significant functionality.  I've tried to provide credit in the notes 
below and the project's ChangeLog, please let me know if I've accidentally 
ommitted you.

Many thanks to Enthought for their continued hosting support for IPython.


Release notes
-------------

*** WARNING: compatibility changes ***

   - IPython now requires at least Python 2.3.  If you can't upgrade from 2.2, 
you'll need to continue using IPython 0.6.15.

*** End warning.


As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and
the full ChangeLog at http://ipython.scipy.org/ChangeLog.  The highlights of
this release follow.

    - Wildcard patterns in searches, supported by the %psearch magic, as well 
as the '?' operator.  Type psearch? for the full details. Extremely useful, 
thanks to J?rgen Stenarson.

    - Major improvements to the pdb mode.  It now has tab-completion, syntax
highlighting and better stack handling.  Thanks to Vivian De Smedt for this
work (double-points given that pdb has a well-deserved reputation for being
very unpleasant to work with).

    - Support for input with empty lines.  If you have auto-indent on, this
means that you need to either hit enter _twice_, or add/remove a space to your
last blank line, to indicate you're done entering input.  These changes also
allow us to provide copy/paste of code with blank lines.

    - Support for pasting multiline input even with autoindent on.  The code
will look wrong on screen, but it will be stored and executed correctly
internally.

    - TAB on an otherwise empty line actually inserts a tab.  Convenient for
indenting (for those who don't use autoindent).

    - Significant improvements for all multithreaded versions of ipython.  Now,
if your threaded code raises exceptions, instead of seeing a crash report, a
normal (colored, verbose, etc.) exception is printed.  Additionally, if you
have pdb on, it will activate in your threaded code.  Very nice for
interactively debugging GUI programs.

    - Many fixes to embedded ipython, including proper handling of globals and
tab completion.

    - New -t and -o options to %logstart, to respectively put timestamps in
your logs, and to also log all output (tagged as #[Out]#).  The default log
name is now ipython_log.py, to better reflect that logs remain valid Python
source.

    - Lightweight persistence mechanism via %store.  IPython had always had
%save, to write out a group of input lines directly to a file.  Now, its
%store companion stores persistently (associated with your profile, and
auto-loaded at startup) not just source, but any python variable which can be
pickled.  Thanks to Matt Wilkie for the request, and ville for the patches.

    - Macros (created with %macro) can now be edited with %edit (just say 
'%edit macroname').  This, coupled with the ability to store them 
persistently, makes the macro system much more useful.

    - New guarantee that, if you disable autocalling, ipython will never call
getattr() on your objects.  This solves problems with code that has
side-effects on attribute access.  Note that TAB-completion inevitably does
call getattr(), so not all forms of side-effects can be eliminated.

    - Unicode support for prompts.

    - Improvements to path handling under win32.  Thanks to Ville and Jorgen
for the patches.

    - Improvements to pager under win32.  Contributed by Alexander Belchenko.

    - Demo class for interactive demos using ipython.

    - %pycat magic for showing syntax-highlighted python sources

    - support for download_url in setup.py, so PyPI (and setuptools) work
transparently with ipython.

    - New exit/quit magics to exit, conditionally asking (%Exit/%Quit don't)

    - Automatically reopen the editor if your file has a syntax error in it
(when using the %edit system).

    - New notation N-M for indicating the range of lines N,...,M (including 
both endpoints), in magic commands such as %macro, %save and %edit.

    - The IPython instance has a new attribute, .meta, which is an empty 
namespace (an instance of 'class Bunch:pass').  This is meant to provide 
extension writers with a safe namespace to store metadata of any kind, without 
the risk of name clashes with IPython's internals.

    - Added tab-completion support for objects with Traits, a sophisticated 
type definition system for Python: http://code.enthought.com/traits.

    - Several patches related to Emacs support.  Thanks to Alex Schmolck and 
John Barnard.

    - New 'smart' autocall mode, which avoids autocalling if a function with 
no arguments is the input.  The old 'full' mode can be obtained by setting the 
autocall parameter in the ipythonrc to 2, or via the %autocall magic.

    - A large amount of internal reorganization and cleanup, to allow the code
to be more readily moved over to the chainsaw branch (see below).

    - Many other small fixes and enhancements.  The changelog has full details.


Enjoy, and as usual please report any problems.

Regards,

Fernando.



From hans_meine at gmx.net  Tue Jan 10 07:42:58 2006
From: hans_meine at gmx.net (Hans Meine)
Date: Tue, 10 Jan 2006 13:42:58 +0100
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <43C374E6.8030602@colorado.edu>
References: <43C374E6.8030602@colorado.edu>
Message-ID: <200601101343.11173.hans_meine@gmx.net>

Hi!

On Tuesday 10 January 2006 09:48, Fernando Perez wrote:
>     - Major improvements to the pdb mode.  It now has tab-completion,
> syntax highlighting and better stack handling.  Thanks to Vivian De Smedt
> for this work (double-points given that pdb has a well-deserved reputation
> for being very unpleasant to work with).
This is something I was really looking forward to, but I did not run SVN 
until .. half an hour ago (I was just too busy the last days).  
Unfortunately, I read your announcement from today when I was about to post 
the following problem..

>     - Support for pasting multiline input even with autoindent on.  The
> code will look wrong on screen, but it will be stored and executed
> correctly internally.
Is it possible that there is a conflict between this and the %macro feature?
Testcase follows.. oh no, it's the fault of -qthread, without that it works:

hans# ipython -qthread
Python 2.4.2 (#1, Oct 25 2005, 09:51:50)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.0 -- 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]:foo = []

In [2]:for i in range(42):
   ...:         foo.append(i)
   ...:
   ...:

In [3]:macro bar 1:3
Macro `bar` created. To execute, type its name (without quotes).
Macro contents:
foo = []
for i in range(42):
        foo.append(i)


In [4]:bar
Out[4]:Executing Macro...

In [6]:

Here, IPython hangs.  First, I wondered about the [6], but that seems to be 
normal, due to the multi-line macro?  But I cannot revive the prompt; I have 
to kill IPython.

For your convenience, here's code to paste:

foo = []
for i in range(42):
	foo.append(i)

%macro bar 1:3
bar

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060110/69db5ef9/attachment.sig>

From prabhu_r at users.sf.net  Wed Jan 11 01:27:15 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Wed, 11 Jan 2006 11:57:15 +0530
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
Message-ID: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>

Hi, 

I get this error when I use the GTKAgg backend and pylab.

$ ipython -pylab
pygtk.require() must be called before importing gtk
PyGTK version 1.99.16 or greater is required to run the GTK Matplotlib backends

OTOH, this works:

$ ipython -gthread

Matplotlib version 0.82?  Is this a matplotlib bug?  BTW, things work
fine with the WXAgg backend.  I just thought that if this was a bug in
IPython that you should know.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Wed Jan 11 01:34:57 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 10 Jan 2006 23:34:57 -0700
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
Message-ID: <43C4A711.5020605@colorado.edu>

Prabhu Ramachandran wrote:
> Hi, 
> 
> I get this error when I use the GTKAgg backend and pylab.
> 
> $ ipython -pylab
> pygtk.require() must be called before importing gtk
> PyGTK version 1.99.16 or greater is required to run the GTK Matplotlib backends
> 
> OTOH, this works:
> 
> $ ipython -gthread
> 
> Matplotlib version 0.82?  Is this a matplotlib bug?  BTW, things work
> fine with the WXAgg backend.  I just thought that if this was a bug in
> IPython that you should know.

Which version of pygtk are you running?  With reasonably recent pygtk (from 
fecora 3) and matplotlib, I don't see any of this:

In [1]: matplotlib.__version__
Out[1]: '0.83.2'

In [2]: import pygtk

In [3]: pygtk._get_available_versions()
Out[3]: {'2.0': '/usr/lib/python2.3/site-packages/gtk-2.0'}


I remember there used to be a require() call before, but at some point in the 
last 6 months it was removed, I believe in order to follow the conventions of 
more current pygtk.  I may have been wrong in that though, I know precious 
little about the GTK API (as evidenced by the thread with C. Moad an S. Moore 
on ipython-user).

Cheers,

f



From prabhu_r at users.sf.net  Wed Jan 11 02:04:10 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Wed, 11 Jan 2006 12:34:10 +0530
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <43C4A711.5020605@colorado.edu>
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
	<43C4A711.5020605@colorado.edu>
Message-ID: <17348.44522.242468.153978@prpc.aero.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> Matplotlib version 0.82?  Is this a matplotlib bug?  BTW,
    >> things work fine with the WXAgg backend.  I just thought that
    >> if this was a bug in IPython that you should know.

    Fernando> Which version of pygtk are you running?  With reasonably
    Fernando> recent pygtk (from fecora 3) and matplotlib, I don't see
    Fernando> any of this:

In [2]: pygtk._get_available_versions()
Out[2]: {'2.0': '/usr/lib/python2.3/site-packages/gtk-2.0'}

In [4]: matplotlib.__version__
Out[4]: '0.82'

cheers,
prabhu



From Fernando.Perez at colorado.edu  Wed Jan 11 02:09:17 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 11 Jan 2006 00:09:17 -0700
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <17348.44522.242468.153978@prpc.aero.iitb.ac.in>
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
	<43C4A711.5020605@colorado.edu>
	<17348.44522.242468.153978@prpc.aero.iitb.ac.in>
Message-ID: <43C4AF1D.6080608@colorado.edu>

Prabhu Ramachandran wrote:
>>>>>>"Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
> 
> 
>     >> Matplotlib version 0.82?  Is this a matplotlib bug?  BTW,
>     >> things work fine with the WXAgg backend.  I just thought that
>     >> if this was a bug in IPython that you should know.
> 
>     Fernando> Which version of pygtk are you running?  With reasonably
>     Fernando> recent pygtk (from fecora 3) and matplotlib, I don't see
>     Fernando> any of this:
> 
> In [2]: pygtk._get_available_versions()
> Out[2]: {'2.0': '/usr/lib/python2.3/site-packages/gtk-2.0'}
> 
> In [4]: matplotlib.__version__
> Out[4]: '0.82'

Any chance you can update to a more recent mpl?  I really don't want to go out 
of my way into fixing this, if it turns out to be a matplotlib issue simply 
from an old version (0.86 was just released, with new-numpy support, fresh to 
lure you in :)

Given that I don't see it with 0.83, and others in the mpl list aren't 
reporting any problems (all most likely running more recent mpl versions), it 
really may be an issue that would just go away with an mpl upgrade.

Cheers,

f



From Fernando.Perez at colorado.edu  Wed Jan 11 03:55:16 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 11 Jan 2006 01:55:16 -0700
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <200601101343.11173.hans_meine@gmx.net>
References: <43C374E6.8030602@colorado.edu>
	<200601101343.11173.hans_meine@gmx.net>
Message-ID: <43C4C7F4.3000002@colorado.edu>

Hans Meine wrote:
> Hi!
> 

> Is it possible that there is a conflict between this and the %macro feature?
> Testcase follows.. oh no, it's the fault of -qthread, without that it works:

[...]

> Here, IPython hangs.  First, I wondered about the [6], but that seems to be 
> normal, due to the multi-line macro?  But I cannot revive the prompt; I have 
> to kill IPython.
> 
> For your convenience, here's code to paste:
> 
> foo = []
> for i in range(42):
> 	foo.append(i)
> 
> %macro bar 1:3
> bar

I see the problem, with ALL threaded backends (-g/w/qthread).  I'll look into 
this once I find a bit of time (most likely this weekend).

Cheers,

f



From prabhu_r at users.sf.net  Wed Jan 11 04:22:52 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Wed, 11 Jan 2006 14:52:52 +0530
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <43C4AF1D.6080608@colorado.edu>
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
	<43C4A711.5020605@colorado.edu>
	<17348.44522.242468.153978@prpc.aero.iitb.ac.in>
	<43C4AF1D.6080608@colorado.edu>
Message-ID: <17348.52844.430301.280618@prpc.aero.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> In [4]: matplotlib.__version__ Out[4]: '0.82'

    Fernando> Any chance you can update to a more recent mpl?  I

I'm afraid, I don't have the time, but I will try.

    Fernando> really don't want to go out of my way into fixing this,
    Fernando> if it turns out to be a matplotlib issue simply from an
    Fernando> old version (0.86 was just released, with new-numpy
    Fernando> support, fresh to lure you in :)

If its not an IPython issue, forget it.  I just reported it in the
case that it was an issue with 0.7.0.

    Fernando> Given that I don't see it with 0.83, and others in the
    Fernando> mpl list aren't reporting any problems (all most likely
    Fernando> running more recent mpl versions), it really may be an
    Fernando> issue that would just go away with an mpl upgrade.

OK.

Thanks.
cheers,
prabhu



From vds at aisystems.be  Wed Jan 11 04:59:40 2006
From: vds at aisystems.be (Vivian De Smedt)
Date: Wed, 11 Jan 2006 10:59:40 +0100 (CET)
Subject: [IPython-dev] access to __file__
Message-ID: <1510.83.206.43.56.1136973580.squirrel@83.206.43.56>

Fernando,

I use the svn version of IPython and I notice a small difference between
python brol.py and IPython run brol.py.

It seems that IPython run brol.py do not have access to the special
__file__ attribute of the brol.py module.

To be more explicit suppose you have a brol.py file:
print __file__

python brol.py produce:
brol.py

IPython run brol.py produce:
---------------------------------------------------------------------------
exceptions.NameError                                 Traceback (most
recent call last)

C:\Documents and Settings\vds.AISYSTEMS\Desktop\brol.py
     -3 print __file__

NameError: name '__file__' is not defined
WARNING: Failure executing file: <brol.py>

I'm not hundred percent sure but I'm pretty sure this is new for IPython.

Kindest regards,
Vivian.



From jdhunter at ace.bsd.uchicago.edu  Wed Jan 11 09:21:39 2006
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Wed, 11 Jan 2006 08:21:39 -0600
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <17348.52844.430301.280618@prpc.aero.iitb.ac.in> (Prabhu
	Ramachandran's message of "Wed, 11 Jan 2006 14:52:52 +0530")
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
	<43C4A711.5020605@colorado.edu>
	<17348.44522.242468.153978@prpc.aero.iitb.ac.in>
	<43C4AF1D.6080608@colorado.edu>
	<17348.52844.430301.280618@prpc.aero.iitb.ac.in>
Message-ID: <87hd8asv4c.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Prabhu" == Prabhu Ramachandran <prabhu_r at users.sf.net> writes:

    Fernando> Given that I don't see it with 0.83, and others in the
    Fernando> mpl list aren't reporting any problems (all most likely
    Fernando> running more recent mpl versions), it really may be an
    Fernando> issue that would just go away with an mpl upgrade.

You just need to make sure that neither matplotlib (in backend_gtk.py)
or IPython (in Shell.py).

Just remove all these and you should be fine.

Basically, pygtk.require should not be used in any code that may be
used in a library, such as mpl or ipython...

JDH



From Fernando.Perez at colorado.edu  Wed Jan 11 13:24:59 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 11 Jan 2006 11:24:59 -0700
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <17348.52844.430301.280618@prpc.aero.iitb.ac.in>
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
	<43C4A711.5020605@colorado.edu>
	<17348.44522.242468.153978@prpc.aero.iitb.ac.in>
	<43C4AF1D.6080608@colorado.edu>
	<17348.52844.430301.280618@prpc.aero.iitb.ac.in>
Message-ID: <43C54D7B.2050300@colorado.edu>

Prabhu Ramachandran wrote:
>>>>>>"Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
> 
> 
>     >> In [4]: matplotlib.__version__ Out[4]: '0.82'
> 
>     Fernando> Any chance you can update to a more recent mpl?  I
> 
> I'm afraid, I don't have the time, but I will try.
> 
>     Fernando> really don't want to go out of my way into fixing this,
>     Fernando> if it turns out to be a matplotlib issue simply from an
>     Fernando> old version (0.86 was just released, with new-numpy
>     Fernando> support, fresh to lure you in :)
> 
> If its not an IPython issue, forget it.  I just reported it in the
> case that it was an issue with 0.7.0.

Thanks for the info, I do want _all_ reports of problems.  Much appreciated. 
If you do get a chance to update mpl and still have troubles, by all means 
yell loudly, and we'll revisit this one.

Take care,

f



From Fernando.Perez at colorado.edu  Wed Jan 11 13:49:06 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 11 Jan 2006 11:49:06 -0700
Subject: [IPython-dev] Welcoming Ville as the new maintainer for IPython
	0.7.x
Message-ID: <43C55322.8070906@colorado.edu>

Hi all,

as you will have noticed, I keep on promising to stop working on development 
in the trunk/ of IPython to concentrate on the 'big cleanup' and new ideas in 
the chainsaw/ branch.  And you have no doubt sneered many times, given the 
regularity of my breaking such promise.

Well, I am trying to put a stop to such mockery, and regain a shred of my 
honor.  For this, I have enlisted the help of one of our most active 
contributors, who has a tendency to back his ideas, requests and suggestions 
with working patches.

For the rest of the life of the 'current' ipython, Ville Vainio will be the 
official maintainer.  I expect to put out a 0.7.1 myself next week, with fixes 
for the few inevitable problems that were found in 0.7.0; I'm already working 
on it.  But after that I'll be able to start working on the chainsaw branch in 
earnest, where Brian Granger has been dutifully making progress already. 
Knowing that Ville is at the controls will let me concentrate better on the 
new work, without fearing that the plane will fly itself into a mountain.

I will continue to be available on the list, and will assist Ville as needed, 
but I'll try to spend all my ipython hacking time on the new work, which is a 
longer term effort.

I'd like to thank Ville for accepting my plea for help; he's done very good 
work so far with IPython and I expect things will only get better.  It will be 
my responsibility to track his changes into the new architecture, so that when 
the new ipython is born, it isn't missing important features that Ville may 
have added after 0.7.1.

Regards,

f



From jorgen.stenarson at bostream.nu  Wed Jan 11 16:50:06 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 11 Jan 2006 22:50:06 +0100
Subject: [IPython-dev] Build doc script patch
Message-ID: <43C57D8E.4040508@bostream.nu>

Hi,

the 0.7.0 is working fine for me. But today I tried to generate the 
pdf-doc for the first time. And I realized the build scripts are 
hardcore unix and does not work on windows (without cygwin). This seems 
unecessary since the functionality could be easily implemented in 
python. I have attached a patch that implements this for windows. I have 
left out the modifications necessary for unix. The patch contains three 
files:


update_manual.bat:
batchfile that calls the update_manual.py script with ipython 
update_manual.py

build_doc_instruction.txt:	
Some instructions on how to build the manual. Since the readme files in 
this directory does not contain any information on how to build the docs

update_manual.py:
python program that performs the duties of update_magic.sh and 
update_version.sh if called by ipython update_manual.py.


Perhaps update_manual.py should be changed to run using just python. But 
  I could not figure out how to do this. It would also be nice if the 
script exits when finished, but I'm not sure how to do this either.

/J?rgen

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: build_doc.diff
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060111/cdc6604e/attachment.ksh>

From vivainio at gmail.com  Wed Jan 11 17:44:30 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 12 Jan 2006 00:44:30 +0200
Subject: [IPython-dev] Build doc script patch
In-Reply-To: <43C57D8E.4040508@bostream.nu>
References: <43C57D8E.4040508@bostream.nu>
Message-ID: <46cb515a0601111444l28b4811fg6370bdc43b580879@mail.gmail.com>

Thanks for the patch, I added a slightly corrected version to svn -
ipmagic("magic") is the correct way to call %magic. I'll add "-f"
(force) option to %exit tomorrow to enable exiting without
confirmation prompt, so the file will change soon.

I'm not sure we need a .bat file, I'd also like to deprecate
update_*.sh scripts, though there is no rush. We should stick with
pure python as far as possible.

PS. In the future send patches as attachments, copy-pasting can be
slightly error prone.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Wed Jan 11 17:48:59 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 11 Jan 2006 15:48:59 -0700
Subject: [IPython-dev] Build doc script patch
In-Reply-To: <46cb515a0601111444l28b4811fg6370bdc43b580879@mail.gmail.com>
References: <43C57D8E.4040508@bostream.nu>
	<46cb515a0601111444l28b4811fg6370bdc43b580879@mail.gmail.com>
Message-ID: <43C58B5B.2010208@colorado.edu>

Ville Vainio wrote:
> Thanks for the patch, I added a slightly corrected version to svn -
> ipmagic("magic") is the correct way to call %magic. I'll add "-f"
> (force) option to %exit tomorrow to enable exiting without
> confirmation prompt, so the file will change soon.

Great.  Note that %Exit is the no-confirmation function, no need to add a -f 
option.

> I'm not sure we need a .bat file, I'd also like to deprecate
> update_*.sh scripts, though there is no rush. We should stick with
> pure python as far as possible.

Sure.  In a *nix world though, I still shoot for sh when the task at hand is 
little more than a sequential concatenation of commands.  But given the 
absolute lack of decent text tools at the command line in win32, I'm happy 
with the idea of porting our support tools to pure python, in the interest of 
portability.

> PS. In the future send patches as attachments, copy-pasting can be
> slightly error prone.

Yes, VERY important (I've had problems with this in the past).  Also Ville, 
watch out for patches with tabs in them, some of those have cost me a fair bit 
of hair-pulling.  If that ever happens, in addition to reminding the submitter 
about the policy stated on the wiki, 'untabify -t 4' is your friend.

Cheers,

f



From Fernando.Perez at colorado.edu  Thu Jan 12 01:21:59 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 11 Jan 2006 23:21:59 -0700
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to 0.7.0 via
	easy_install
Message-ID: <43C5F587.8040104@colorado.edu>

Hi all,

this is a plea for help, hoping others on the list can bail me out on this 
problem.  I don't have a clue.  I am forwarding Travis' message unmodified, in 
the hope that somebody who knows about eggs can help us a little here.

[ Travis, thanks for 'doing the right thing and filing  a proper bug report. 
In this case, however, I'm going to have to move this to the -dev list, 
because I'm out of my league on this problem, so I need to enlist the help of 
others who may have some ideas.  I've whitelisted you on the -dev list so your 
posts don't bounce.  You still may want to subscribe to get the replies. ]


I added egg construction as part of 0.7.0 mostly to satisfy user requests, but 
I have to admit that my experiences with the system haven't been the best, so 
a) I don't really know how to help here b) I'm not terribly interested in 
learning any more about eggs.  I find the system unpleasant to use and to 
cause (in IPython's case, I know there are contexts where it's indispensable) 
more problems than it solves.  If providing ipython in egg format continues to 
create hassles to users (and to myself) I may just discontinue the practice. 
So far eggs have cost me quite a few hours, with no discernible benefit (kind 
of like win32, but that's a monopoly I can't really fight ;-)


Cheers,

f

=========================================================================
Subject:Issue with upgrading from 0.6.15 to 0.7.0 via easy_install
From:Travis Caldwell <travis_caldwell2000 at yahoo.com>
Date:Wed, 11 Jan 2006 18:53:54 -0800 (PST)
To:ipython-dev at scipy.net

  Hi,

  I had installed Ipython 0.6.15 via easy_install and that was working
great.

  I then did a 'easy_install -U ipython' and it went out grabbed the new
egg and did the install.

  Everthing looked great untill I tried to run Ipython and then I
noticed that it was still running the previous 0.6.15 version.

  I initially thought that this was a path or script installation issue,
but it looks like some of the setuptools magic is going wrong.

  The new ipython script that got installed in bin is basicly:

__requires__ = 'ipython==0.7.0'
import pkg_resources
pkg_resources.run_script('ipython==0.7.0', 'ipython')


I know very little about easy_install or setuptools, but I read up on
it a bit and tried to use pkg_resources.resource_string() to read out
the script that gets run by run_script()

This may be user error with setuptools, but when I try this I get an:

ImportError: No module named ipython==0.7.0

Here a transcript of my session attempting to "manually" run Ipython:

pinky-1234% python2.4
Python 2.4.2 (#1, Jan  6 2006, 12:06:26)
[GCC 3.2.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

 >>>>>> __requires__ = 'ipython==0.7.0'
 >>>>>> import pkg_resources
 >>>>>> pkg_resources.resource_string('ipython==0.7.0', 'ipython')

Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File
"/home/travisc/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 688, in resource_string
     return get_provider(package_or_requirement).get_resource_string(
   File
"/home/travisc/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 119, in get_provider
     __import__(moduleOrReq)
ImportError: No module named ipython==0.7.0

 >>>>>> pkg_resources.get_provider('ipython==0.7.0')

Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File
"/home/travisc/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 119, in get_provider
     __import__(moduleOrReq)
ImportError: No module named ipython==0.7.0

 >>>>>> pkg_resources.run_script('ipython==0.7.0', 'ipython')

Python 2.4.2 (#1, Jan  6 2006, 12:06:26)
Type "copyright", "credits" or "license" for more information.



IPython 0.6.15 -- 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]:


Any pointers on where to look next would be appreciated.

The easy_install tool seems really great and I'd love to be able to get
it working.


              _Travis_Caldwell_



From robert.kern at gmail.com  Thu Jan 12 01:44:28 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 12 Jan 2006 00:44:28 -0600
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to 0.7.0 via
	easy_install
In-Reply-To: <43C5F587.8040104@colorado.edu>
References: <43C5F587.8040104@colorado.edu>
Message-ID: <dq4tse$8kk$1@sea.gmane.org>

Fernando Perez wrote:
> Hi all,
> 
> this is a plea for help, hoping others on the list can bail me out on this 
> problem.  I don't have a clue.  I am forwarding Travis' message unmodified, in 
> the hope that somebody who knows about eggs can help us a little here.
> 
> [ Travis, thanks for 'doing the right thing and filing  a proper bug report. 
> In this case, however, I'm going to have to move this to the -dev list, 
> because I'm out of my league on this problem, so I need to enlist the help of 
> others who may have some ideas.  I've whitelisted you on the -dev list so your 
> posts don't bounce.  You still may want to subscribe to get the replies. ]
> 
> 
> I added egg construction as part of 0.7.0 mostly to satisfy user requests, but 
> I have to admit that my experiences with the system haven't been the best, so 
> a) I don't really know how to help here b) I'm not terribly interested in 
> learning any more about eggs.  I find the system unpleasant to use and to 
> cause (in IPython's case, I know there are contexts where it's indispensable) 
> more problems than it solves.  If providing ipython in egg format continues to 
> create hassles to users (and to myself) I may just discontinue the practice. 
> So far eggs have cost me quite a few hours, with no discernible benefit (kind 
> of like win32, but that's a monopoly I can't really fight ;-)
> 
> 
> Cheers,
> 
> f
> 
> =========================================================================
> Subject:Issue with upgrading from 0.6.15 to 0.7.0 via easy_install
> From:Travis Caldwell <travis_caldwell2000 at yahoo.com>
> Date:Wed, 11 Jan 2006 18:53:54 -0800 (PST)
> To:ipython-dev at scipy.net
> 
>   Hi,
> 
>   I had installed Ipython 0.6.15 via easy_install and that was working
> great.
> 
>   I then did a 'easy_install -U ipython' and it went out grabbed the new
> egg and did the install.
> 
>   Everthing looked great untill I tried to run Ipython and then I
> noticed that it was still running the previous 0.6.15 version.
> 
>   I initially thought that this was a path or script installation issue,
> but it looks like some of the setuptools magic is going wrong.
> 
>   The new ipython script that got installed in bin is basicly:
> 
> __requires__ = 'ipython==0.7.0'
> import pkg_resources
> pkg_resources.run_script('ipython==0.7.0', 'ipython')
> 
> 
> I know very little about easy_install or setuptools, but I read up on
> it a bit and tried to use pkg_resources.resource_string() to read out
> the script that gets run by run_script()
> 
> This may be user error with setuptools, but when I try this I get an:
> 
> ImportError: No module named ipython==0.7.0
> 
> Here a transcript of my session attempting to "manually" run Ipython:
> 
> pinky-1234% python2.4
> Python 2.4.2 (#1, Jan  6 2006, 12:06:26)
> [GCC 3.2.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> 
>  >>>>>> __requires__ = 'ipython==0.7.0'
>  >>>>>> import pkg_resources
>  >>>>>> pkg_resources.resource_string('ipython==0.7.0', 'ipython')
> 
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File
> "/home/travisc/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
> line 688, in resource_string
>      return get_provider(package_or_requirement).get_resource_string(
>    File
> "/home/travisc/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
> line 119, in get_provider
>      __import__(moduleOrReq)
> ImportError: No module named ipython==0.7.0
> 
>  >>>>>> pkg_resources.get_provider('ipython==0.7.0')
> 
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File
> "/home/travisc/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
> line 119, in get_provider
>      __import__(moduleOrReq)
> ImportError: No module named ipython==0.7.0

Neither of these functions take the same kind of argument that
pkg_resources.run_script() takes, so it's not surprising that what you wrote
doesn't work.

It's a bit difficult to diagnose without seeing your filesystem. Where are both
of the ipython eggs? Are they both in
/home/travisc/lib/python2.4/site-packages/? Is that a local site-packages for a
system Python executable, or is your Python executable ~/bin/python2.4, too?

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



From travis_caldwell2000 at yahoo.com  Thu Jan 12 03:28:03 2006
From: travis_caldwell2000 at yahoo.com (Travis Caldwell)
Date: Thu, 12 Jan 2006 00:28:03 -0800 (PST)
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to 0.7.0
	via	easy_install
Message-ID: <20060112082803.61434.qmail@web35901.mail.mud.yahoo.com>


 [snip]

 > I added egg construction as part of 0.7.0 mostly to satisfy  
 > user requests, but 
 > I have to admit that my experiences with the system haven't 
 > been the best, so 
 > a) I don't really know how to help here b) I'm not terribly  
 > interested in 
 > learning any more about eggs.  I find the system unpleasant to  
 > use and to 
 > cause (in IPython's case, I know there are contexts where it's  
 > indispensable) 
 > more problems than it solves.  If providing ipython in egg 
 > format continues to 
 > create hassles to users (and to myself) I may just discontinue  
 > the practice. 
 > So far eggs have cost me quite a few hours, with no 
 > discernible benefit (kind 
 > of like win32, but that's a monopoly I can't really fight ;-)

 While not too familiar with the details of eggs, I really like the
capabilities that eggs and easy_install provide. 

 Eventually, being able to 'easy_install ipython' and have everything
just work would be great.

 I think that ipthon would be a great shell for a number of other
projects and if easy_install could automatically grab ipython as a
dependancy it would lower the barrier for this use model.

 I'd hate to be the last straw that caused egg support to be
discontinued.

 [snip]
 > Neither of these functions take the same kind of argument that
 > pkg_resources.run_script() takes, so it's not surprising that    
 >    
 > what you wrote
 > doesn't work.

Sorry about that. I'm not too familiar with setup tools and I saw:

  resource_string(package_or_requirement, resource_name)
    Return the specified resource as a string. The resource is   read
in binary fashion, such that the returned string contains exactly the
bytes that are stored in the resource.

In the API doc and thought I could call it with a requirement string.

 > It's a bit difficult to diagnose without seeing your filesystem.   
 > Where are both
 > of the ipython eggs? Are they both in
 > /home/travisc/lib/python2.4/site-packages/? Is that a local    
 > site-packages for a
 > system Python executable, or is your Python executable   
 > ~/bin/python2.4, too?

 Yes, both eggs are in /home/travisc/lib/python2.4/site-packages/

 This is a local install of python in ~/bin/python2.4

                  _Travis_Caldwell_


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From Fernando.Perez at colorado.edu  Thu Jan 12 03:34:50 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 01:34:50 -0700
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to
	0.7.0	via	easy_install
In-Reply-To: <20060112082803.61434.qmail@web35901.mail.mud.yahoo.com>
References: <20060112082803.61434.qmail@web35901.mail.mud.yahoo.com>
Message-ID: <43C614AA.7010209@colorado.edu>

Travis Caldwell wrote:

>  I think that ipthon would be a great shell for a number of other
> projects and if easy_install could automatically grab ipython as a
> dependancy it would lower the barrier for this use model.
> 
>  I'd hate to be the last straw that caused egg support to be
> discontinued.

No worries: if users find them useful, I'll swallow my pride and impatience 
and deal with them.  And if I don't want to, Robert will kindly convince me to :)

>  [snip]
>  > Neither of these functions take the same kind of argument that
>  > pkg_resources.run_script() takes, so it's not surprising that    
>  >    
>  > what you wrote
>  > doesn't work.
> 
> Sorry about that. I'm not too familiar with setup tools and I saw:
> 
>   resource_string(package_or_requirement, resource_name)
>     Return the specified resource as a string. The resource is   read
> in binary fashion, such that the returned string contains exactly the
> bytes that are stored in the resource.
> 
> In the API doc and thought I could call it with a requirement string.
> 
>  > It's a bit difficult to diagnose without seeing your filesystem.   
>  > Where are both
>  > of the ipython eggs? Are they both in
>  > /home/travisc/lib/python2.4/site-packages/? Is that a local    
>  > site-packages for a
>  > system Python executable, or is your Python executable   
>  > ~/bin/python2.4, too?
> 
>  Yes, both eggs are in /home/travisc/lib/python2.4/site-packages/
> 
>  This is a local install of python in ~/bin/python2.4

Can you somehow just blow out the 0.6.15 egg and install the 0.7.0 one?  Do 
eggs have a 'delete' command that just removes them altogether?  0.6.15 was 
never 'officially' an egg, so perhaps doing this may help.

But remember: I don't really know how they work, so perhaps what I'm saying is 
just stupid.

Best,

f



From Fernando.Perez at colorado.edu  Thu Jan 12 03:37:26 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 01:37:26 -0700
Subject: [IPython-dev] access to __file__
In-Reply-To: <1510.83.206.43.56.1136973580.squirrel@83.206.43.56>
References: <1510.83.206.43.56.1136973580.squirrel@83.206.43.56>
Message-ID: <43C61546.6090608@colorado.edu>

Vivian De Smedt wrote:
> Fernando,
> 
> I use the svn version of IPython and I notice a small difference between
> python brol.py and IPython run brol.py.
> 
> It seems that IPython run brol.py do not have access to the special
> __file__ attribute of the brol.py module.

Confirmed bug, I'll try to clear it this weekend.

Best,

f



From vivainio at gmail.com  Thu Jan 12 05:27:43 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 12 Jan 2006 12:27:43 +0200
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to 0.7.0
	via	easy_install
In-Reply-To: <43C614AA.7010209@colorado.edu>
References: <20060112082803.61434.qmail@web35901.mail.mud.yahoo.com>
	<43C614AA.7010209@colorado.edu>
Message-ID: <46cb515a0601120227k1a04e0d5p56887e6022211793@mail.gmail.com>

On 1/12/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> No worries: if users find them useful, I'll swallow my pride and impatience
> and deal with them.  And if I don't want to, Robert will kindly convince me to :)

I'm also more than willing to deal with eggs and easy-install, I would
even like to see the ability to add extensions/plugins to ipython via
eggs some day. Imagine the pleasure of saying to someone that they
just need to do

% easy_install ipython-pipe-filters

and start using the extension immediately (possibly without editing
any config files). Using a browser, sourceforge, unzipper etc. to get
stuff seems rather "unprofessional" in comparison. cpan was a great
booster for perl, easy_install, cheeseshop and eggs is about to do the
same to python.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From robert.kern at gmail.com  Thu Jan 12 11:07:42 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 12 Jan 2006 10:07:42 -0600
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to 0.7.0 via
	easy_install
In-Reply-To: <43C614AA.7010209@colorado.edu>
References: <20060112082803.61434.qmail@web35901.mail.mud.yahoo.com>
	<43C614AA.7010209@colorado.edu>
Message-ID: <dq5usg$20n$1@sea.gmane.org>

Fernando Perez wrote:

> Can you somehow just blow out the 0.6.15 egg and install the 0.7.0 one?  Do 
> eggs have a 'delete' command that just removes them altogether? 

Sort of.

  $ rm /path/to/ipython-0.6.15-py2.4.egg

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



From travis_caldwell2000 at yahoo.com  Thu Jan 12 11:44:37 2006
From: travis_caldwell2000 at yahoo.com (Travis Caldwell)
Date: Thu, 12 Jan 2006 08:44:37 -0800 (PST)
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to 0.7.0
	via	easy_install
Message-ID: <20060112164438.8300.qmail@web35907.mail.mud.yahoo.com>

 > 
 > Fernando Perez wrote:
 >
 > > Can you somehow just blow out the 0.6.15 egg and install the  
 > 0.7.0 one?  Do 
 > > eggs have a 'delete' command that just removes them altogether? 
 > 
 > Sort of.
 > 
 >   $ rm /path/to/ipython-0.6.15-py2.4.egg

I tried this and 0.6.15 still came up. So now I was really puzzled. 

After some digging I realized that I still had my PYTHONPATH set for
the sytem python2.3 installation. And that the ipython install in
PYTHONPATH was the one gettting run.

After blowing away PYTHONPATH, 0.7.0 worked just fine.

(I also didn't realize that the egg's in site-packages are actually
directories. If I had realized that I could just 'cd' into them, I
wouldn't have messed with the setuptools API)

 So this can basically be chalked up to user error.

 Thanks for the help.

                 _Travis_Caldwell_


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From robert.kern at gmail.com  Thu Jan 12 11:56:04 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 12 Jan 2006 10:56:04 -0600
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to 0.7.0 via
	easy_install
In-Reply-To: <20060112164438.8300.qmail@web35907.mail.mud.yahoo.com>
References: <20060112164438.8300.qmail@web35907.mail.mud.yahoo.com>
Message-ID: <dq61n4$dlt$1@sea.gmane.org>

Travis Caldwell wrote:

> After blowing away PYTHONPATH, 0.7.0 worked just fine.

Excellent.

> (I also didn't realize that the egg's in site-packages are actually
> directories. If I had realized that I could just 'cd' into them, I
> wouldn't have messed with the setuptools API)

It depends. If the package is not "zip-safe", then easy_install will unzip the
egg appropriately. ipython is not zip-safe (and that's okay).

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



From vivainio at gmail.com  Thu Jan 12 12:26:48 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 12 Jan 2006 19:26:48 +0200
Subject: [IPython-dev] Magics, aliases now use raw strings!
Message-ID: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>

I just committed a patch to SVN which extends the functionality
previously only apparent in !system escapes - namely, using of raw
strings and passing \ characters directly to aliases and magics. This
more closely reflects the experience you get with system commands in
bash et. al (and especially cmd.exe!).

Thanks go to Jerry McRae for the (justified) complaints about the
previous functionality.

I hope some of you have the time to do "svn up" and play with it a
bit. Multiline magics and aliases don't work, but they never did and
I'm not sure if they ever should in the first place.

%cd magic is still broken due to using shlex.split for arg parsing. I
have some ideas on how to get around it though...

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Thu Jan 12 13:00:28 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 11:00:28 -0700
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to
	0.7.0	via	easy_install
In-Reply-To: <20060112164438.8300.qmail@web35907.mail.mud.yahoo.com>
References: <20060112164438.8300.qmail@web35907.mail.mud.yahoo.com>
Message-ID: <43C6993C.2090804@colorado.edu>

Travis Caldwell wrote:

>  So this can basically be chalked up to user error.
> 
>  Thanks for the help.

OK, I'll then close the bug on the tracker.  Thanks to Robert for the help, 
much appreciated.

Cheers,

f



From Fernando.Perez at colorado.edu  Thu Jan 12 13:17:06 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 11:17:06 -0700
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
Message-ID: <43C69D22.8030305@colorado.edu>

Ville Vainio wrote:
> I just committed a patch to SVN which extends the functionality
> previously only apparent in !system escapes - namely, using of raw
> strings and passing \ characters directly to aliases and magics. This
> more closely reflects the experience you get with system commands in
> bash et. al (and especially cmd.exe!).
> 
> Thanks go to Jerry McRae for the (justified) complaints about the
> previous functionality.

Thanks, Ville.  I suspect this will matter more to win32 users, who have to 
deal with \ path separators.

> I hope some of you have the time to do "svn up" and play with it a
> bit. Multiline magics and aliases don't work, but they never did and
> I'm not sure if they ever should in the first place.
> 
> %cd magic is still broken due to using shlex.split for arg parsing. I
> have some ideas on how to get around it though...

Please be _very_ careful when dealing with that code: we need to be able to 
parse a plain string of the kind

%run foo -a val1 --optionb=val2

and we need to construct a valid sys.argv out of that thing, just like the one 
the user would get, were he to run

python foo.py -a val1 --optionb=val2


I'm not saying not to make changes there, but simply to be really careful that 
you don't break all the possible corner cases with quote characters, escaped 
variables and more.  It took me quite a few tries to get that code reasonably 
right (and I'm still not sure it's 100% correct). Tread lightly :)

Cheers,

f



From Fernando.Perez at colorado.edu  Thu Jan 12 13:22:17 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 11:22:17 -0700
Subject: [IPython-dev] Issue with upgrading from 0.6.15 to
	0.7.0	via	easy_install
In-Reply-To: <46cb515a0601120227k1a04e0d5p56887e6022211793@mail.gmail.com>
References: <20060112082803.61434.qmail@web35901.mail.mud.yahoo.com>
	<43C614AA.7010209@colorado.edu>
	<46cb515a0601120227k1a04e0d5p56887e6022211793@mail.gmail.com>
Message-ID: <43C69E59.8090904@colorado.edu>

Ville Vainio wrote:
> On 1/12/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>No worries: if users find them useful, I'll swallow my pride and impatience
>>and deal with them.  And if I don't want to, Robert will kindly convince me to :)
> 
> 
> I'm also more than willing to deal with eggs and easy-install, I would
> even like to see the ability to add extensions/plugins to ipython via
> eggs some day. Imagine the pleasure of saying to someone that they
> just need to do
> 
> % easy_install ipython-pipe-filters
> 
> and start using the extension immediately (possibly without editing
> any config files). Using a browser, sourceforge, unzipper etc. to get
> stuff seems rather "unprofessional" in comparison. cpan was a great
> booster for perl, easy_install, cheeseshop and eggs is about to do the
> same to python.

See? There's nothing to worry.  Between Robert's infinite patience with my 
antisocial tendencies, and Ville's help, not only will we have good egg 
support but I may even learn a thing or two and reform my character in the 
process :)

So eggs will stay.  For 0.7.1, I'll even make an omelette :)

Cheers,

f



From prabhu_r at users.sf.net  Thu Jan 12 14:02:07 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 13 Jan 2006 00:32:07 +0530
Subject: [IPython-dev] Problem with autoindent
Message-ID: <17350.42927.403115.622828@monster.iitb.ac.in>

Hi,

With my SVN checkout of a few days back I get this nasty error:

In [1]: x = 1

In [2]: if x>0:
   ...:     print 'g'
   ...: elif x == 0:
------------------------------------------------------------
IndentationError: unindent does not match any outer indentation level (<ipython console>, line 3)


Very embarrasing, especially when this happens live in class! ;-)

If I turn off autoindent then things are fine.

cheers,
prabhu



From prabhu_r at users.sf.net  Thu Jan 12 14:16:45 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 13 Jan 2006 00:46:45 +0530
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <43C54D7B.2050300@colorado.edu>
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
	<43C4A711.5020605@colorado.edu>
	<17348.44522.242468.153978@prpc.aero.iitb.ac.in>
	<43C4AF1D.6080608@colorado.edu>
	<17348.52844.430301.280618@prpc.aero.iitb.ac.in>
	<43C54D7B.2050300@colorado.edu>
Message-ID: <17350.43805.327062.838792@monster.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    Fernando> Prabhu Ramachandran wrote:
    >> If its not an IPython issue, forget it.  I just reported it in
    >> the case that it was an issue with 0.7.0.

    Fernando> Thanks for the info, I do want _all_ reports of
    Fernando> problems.  Much appreciated. If you do get a chance to
    Fernando> update mpl and still have troubles, by all means yell
    Fernando> loudly, and we'll revisit this one.

Just FYI, it works fine with mpl 0.86.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Thu Jan 12 14:21:48 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 12:21:48 -0700
Subject: [IPython-dev] Problem with autoindent
In-Reply-To: <17350.42927.403115.622828@monster.iitb.ac.in>
References: <17350.42927.403115.622828@monster.iitb.ac.in>
Message-ID: <43C6AC4C.3030408@colorado.edu>

Prabhu Ramachandran wrote:
> Hi,
> 
> With my SVN checkout of a few days back I get this nasty error:
> 
> In [1]: x = 1
> 
> In [2]: if x>0:
>    ...:     print 'g'
>    ...: elif x == 0:
> ------------------------------------------------------------
> IndentationError: unindent does not match any outer indentation level (<ipython console>, line 3)
> 
> 
> Very embarrasing, especially when this happens live in class! ;-)
> 
> If I turn off autoindent then things are fine.

Nasty, nasty.  Sorry.  Will get fixed.

Cheers,

f



From Fernando.Perez at colorado.edu  Thu Jan 12 14:23:14 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 12:23:14 -0700
Subject: [IPython-dev] Problem with gtk/pylab (with SVN)
In-Reply-To: <17350.43805.327062.838792@monster.iitb.ac.in>
References: <17348.42307.316676.764946@prpc.aero.iitb.ac.in>
	<43C4A711.5020605@colorado.edu>
	<17348.44522.242468.153978@prpc.aero.iitb.ac.in>
	<43C4AF1D.6080608@colorado.edu>
	<17348.52844.430301.280618@prpc.aero.iitb.ac.in>
	<43C54D7B.2050300@colorado.edu>
	<17350.43805.327062.838792@monster.iitb.ac.in>
Message-ID: <43C6ACA2.30301@colorado.edu>

Prabhu Ramachandran wrote:
>>>>>>"Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
> 
> 
>     Fernando> Prabhu Ramachandran wrote:
>     >> If its not an IPython issue, forget it.  I just reported it in
>     >> the case that it was an issue with 0.7.0.
> 
>     Fernando> Thanks for the info, I do want _all_ reports of
>     Fernando> problems.  Much appreciated. If you do get a chance to
>     Fernando> update mpl and still have troubles, by all means yell
>     Fernando> loudly, and we'll revisit this one.
> 
> Just FYI, it works fine with mpl 0.86.

OK, glad to hear that.  We have enough other little critters to worry about...

Cheers,

f



From vivainio at gmail.com  Thu Jan 12 14:55:07 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 12 Jan 2006 21:55:07 +0200
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <43C69D22.8030305@colorado.edu>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
Message-ID: <46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>

On 1/12/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Thanks, Ville.  I suspect this will matter more to win32 users, who have to
> deal with \ path separators.

True, but also Unix users will benefit. If a system command wants a
backslash, that's what it's going to get. Think regexps, for example,
they use lots of backslashes. Now you can copy-paste a system command
that uses regexps directly, without doubling the backslashes.

> Please be _very_ careful when dealing with that code: we need to be able to

You can relax, my changes would be all in magic_cd(). I'll look into
it tomorrow.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Thu Jan 12 16:02:20 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 14:02:20 -0700
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
	<46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
Message-ID: <43C6C3DC.4010900@colorado.edu>

Ville Vainio wrote:
> On 1/12/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>Thanks, Ville.  I suspect this will matter more to win32 users, who have to
>>deal with \ path separators.
> 
> 
> True, but also Unix users will benefit. If a system command wants a
> backslash, that's what it's going to get. Think regexps, for example,
> they use lots of backslashes. Now you can copy-paste a system command
> that uses regexps directly, without doubling the backslashes.

Good point.  Make sure to log this kind of brief info in the ChangeLog, this 
is precisely the kind of blurb that becomes super-handy when writing the 
announcement for the new version, so users know what the new candy actually 
tastes like.

>>Please be _very_ careful when dealing with that code: we need to be able to
> 
> 
> You can relax, my changes would be all in magic_cd(). I'll look into
> it tomorrow.

Just letting you know where the booby traps are.  Ipython has many :)

Cheers,

f



From bialix at ukr.net  Thu Jan 12 18:43:31 2006
From: bialix at ukr.net (Alexander Belchenko)
Date: Fri, 13 Jan 2006 01:43:31 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
Message-ID: <dq6pc4$ea5$2@sea.gmane.org>

I use IPython on Windows in separate console or sometimes from FAR (file 
manager) console. And I massively use edit magic feature to make my life 
easier. For editing I use console test editor FTE (http://fte.sf.net).

FTE usually change title string of console window with their own string 
something like this:

FTE - ipython_edit_hghfjd.py - [full path to file]

After closing FTE and returning to IPython title string of console 
window remains the same as when FTE invoked. It's slightly not 
good-looking for me and I willing to fix this.

Here proposed code for changing title of console window to IPython after 
editing (probably this code should also be executed and when console 
IPython started):


# after editor closed set title of console window to 'IPython'
if sys.platform == "win32":
     try:
         import win32api # part of Mark Hammond's pywin32 package
         win32api.SetConsoleTitle('IPython')
     except ImportError:
         try:
             import ctypes
             ctypes.windll.kernel32.SetConsoleTitleA('IPython')
         except ImportError:
             pass


Do you add this code to appropriate place of magic_edit methods or give 
me the hint where it should be so I'll create the patch? I use IPython 
only as console application but I hear that IPython also support some 
sort of GUI mode. In this case proposed code for changing title should 
not be executed when IPython in GUI mode.

What you think about?

--
Alexander



From Fernando.Perez at colorado.edu  Fri Jan 13 01:18:05 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 12 Jan 2006 23:18:05 -0700
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <dq6pc4$ea5$2@sea.gmane.org>
References: <dq6pc4$ea5$2@sea.gmane.org>
Message-ID: <43C7461D.2000909@colorado.edu>

Alexander Belchenko wrote:

> Here proposed code for changing title of console window to IPython after 
> editing (probably this code should also be executed and when console 
> IPython started):
> 
> 
> # after editor closed set title of console window to 'IPython'
> if sys.platform == "win32":
>      try:
>          import win32api # part of Mark Hammond's pywin32 package
>          win32api.SetConsoleTitle('IPython')
>      except ImportError:
>          try:
>              import ctypes
>              ctypes.windll.kernel32.SetConsoleTitleA('IPython')
>          except ImportError:
>              pass
> 
> 
> Do you add this code to appropriate place of magic_edit methods or give 
> me the hint where it should be so I'll create the patch? I use IPython 
> only as console application but I hear that IPython also support some 
> sort of GUI mode. In this case proposed code for changing title should 
> not be executed when IPython in GUI mode.
> 
> What you think about?

This is WAY too intrusive and too much of a platform-specific, special-use 
hack to go into ipython proper.  However, the beauty of ipython is that you 
can, trivially, define your own magic function which does precisely this (and 
whatever else you want).

See:

http://ipython.scipy.org/doc/manual/node6.html#SECTION00062000000000000000

for an example of how to customize your own magics.  Just write your own, 
which calls the builtin and at the end, does anything you can possibly want.

The point of ipython is not to be everything to everybody, but to be flexible 
enough that everybody can customize it to fit their needs.

Cheers,

f



From prabhu_r at users.sf.net  Fri Jan 13 01:28:00 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 13 Jan 2006 11:58:00 +0530
Subject: [IPython-dev] Problem with autoindent
In-Reply-To: <43C6AC4C.3030408@colorado.edu>
References: <17350.42927.403115.622828@monster.iitb.ac.in>
	<43C6AC4C.3030408@colorado.edu>
Message-ID: <17351.18544.541463.602415@prpc.aero.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    Fernando> Prabhu Ramachandran wrote:
    >> With my SVN checkout of a few days back I get this nasty error:
[...]
    >> If I turn off autoindent then things are fine.

    Fernando> Nasty, nasty.  Sorry.  Will get fixed.

No problem.  Thanks.

cheers,
prabhu



From hans_meine at gmx.net  Fri Jan 13 04:03:43 2006
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 13 Jan 2006 10:03:43 +0100
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <dq6pc4$ea5$2@sea.gmane.org>
References: <dq6pc4$ea5$2@sea.gmane.org>
Message-ID: <200601131003.48574.hans_meine@gmx.net>

On Friday 13 January 2006 00:43, Alexander Belchenko wrote:
> I use IPython on Windows in separate console or sometimes from FAR (file
> manager) console. And I massively use edit magic feature to make my life
> easier. For editing I use console test editor FTE (http://fte.sf.net).
>
> FTE usually change title string of console window with their own string
> something like this:
>
> FTE - ipython_edit_hghfjd.py - [full path to file]
>
> After closing FTE and returning to IPython title string of console
> window remains the same as when FTE invoked.

Sounds very much like a bug in your editor to me.
So, Fernando's proposed solution sounds like the way to go, since your patch 
is not even needed for every Windoze user, but just for users of this 
(specific version of) editor.

BTW: Why use the try..except if the except branch seems to work always?  
AFAICS, I would skip use of the extra package and always use the general 
fallback method.

Greetings,
  Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060113/547439d7/attachment.sig>

From vivainio at gmail.com  Fri Jan 13 04:40:39 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 11:40:39 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <dq6pc4$ea5$2@sea.gmane.org>
References: <dq6pc4$ea5$2@sea.gmane.org>
Message-ID: <46cb515a0601130140h4ee88116ue35ba1e292058c0a@mail.gmail.com>

On 1/13/06, Alexander Belchenko <bialix at ukr.net> wrote:

> Do you add this code to appropriate place of magic_edit methods or give
> me the hint where it should be so I'll create the patch? I use IPython

Try making it an edit hook. Look in hooks.py.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 04:52:33 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 11:52:33 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <46cb515a0601130140h4ee88116ue35ba1e292058c0a@mail.gmail.com>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130140h4ee88116ue35ba1e292058c0a@mail.gmail.com>
Message-ID: <46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>

> Try making it an edit hook. Look in hooks.py.

Extending this a bit further - your setconsoletitle sounds like
something I would like to add to general utility functions. I have too
much c:\python... windows, I'd rather have
os.path.basename(os.getcwd()) there so I can distinguish between
different windows.

I seem to remember a way to change it in unix GUI terminals as well,
perhaps through an escape sequence... but I'll make it a no-op in
non-win32 for the first iterations (help appreciated).

Furthermore, once I do that you can just put ipmagic('cd .') in your
edit hook or not do it at all.

Of course even better would be if you could whip up a patch for doing
all of this. Put your implementation in genutils.py and call it from
Magic.magic_cd() in the end.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 08:09:33 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 15:09:33 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130140h4ee88116ue35ba1e292058c0a@mail.gmail.com>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
Message-ID: <46cb515a0601130509g5020030y9b6998d0f738cbb3@mail.gmail.com>

> Of course even better would be if you could whip up a patch for doing
> all of this. Put your implementation in genutils.py and call it from
> Magic.magic_cd() in the end.

On further elaboration, it might be entertaining to have an IPython icon, and


--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 08:12:30 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 15:12:30 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <46cb515a0601130509g5020030y9b6998d0f738cbb3@mail.gmail.com>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130140h4ee88116ue35ba1e292058c0a@mail.gmail.com>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
	<46cb515a0601130509g5020030y9b6998d0f738cbb3@mail.gmail.com>
Message-ID: <46cb515a0601130512s4c9d7782k1d5d0663ef22c481@mail.gmail.com>

> On further elaboration, it might be entertaining to have an IPython icon, and

(please ignore this, I did notice that we have an icon already before
posting and mistakenly sent out this mail anyway...)

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Fri Jan 13 11:11:13 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 13 Jan 2006 09:11:13 -0700
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130140h4ee88116ue35ba1e292058c0a@mail.gmail.com>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
Message-ID: <43C7D121.5040801@colorado.edu>

Ville Vainio wrote:
>>Try making it an edit hook. Look in hooks.py.
> 
> 
> Extending this a bit further - your setconsoletitle sounds like
> something I would like to add to general utility functions. I have too
> much c:\python... windows, I'd rather have
> os.path.basename(os.getcwd()) there so I can distinguish between
> different windows.
> 
> I seem to remember a way to change it in unix GUI terminals as well,
> perhaps through an escape sequence... but I'll make it a no-op in
> non-win32 for the first iterations (help appreciated).
> 
> Furthermore, once I do that you can just put ipmagic('cd .') in your
> edit hook or not do it at all.
> 
> Of course even better would be if you could whip up a patch for doing
> all of this. Put your implementation in genutils.py and call it from
> Magic.magic_cd() in the end.

Let's not put this into genutils, that file is already too crowded, and this 
is purely platform-specific code.  Instead, go ahead and make a winutils.py 
module, where all whe win32 tricks will be nicely isolated.  You can move 
what's in winconsole today into that one.

This keeps the code cleaner, and avoids unnecessary os checks in genutils. 
Think of how os.path is implemented in the stdlib.

And once those are there, users can rely on those utilities to write their own 
magic functions (or anything else).

Cheers,

f



From vivainio at gmail.com  Fri Jan 13 11:23:12 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 18:23:12 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <43C7D121.5040801@colorado.edu>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130140h4ee88116ue35ba1e292058c0a@mail.gmail.com>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
	<43C7D121.5040801@colorado.edu>
Message-ID: <46cb515a0601130823r7aae0497w43cf8827c57339c0@mail.gmail.com>

On 1/13/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Let's not put this into genutils, that file is already too crowded, and this
> is purely platform-specific code.  Instead, go ahead and make a winutils.py
> module, where all whe win32 tricks will be nicely isolated.  You can move
> what's in winconsole today into that one.
>
> This keeps the code cleaner, and avoids unnecessary os checks in genutils.
> Think of how os.path is implemented in the stdlib.

Makes sense - perhaps we should have "platutils" for platform specific
utility functions, and do either "from win32platutils import *" or
"from posixplatutils import *".

The win32platutils still needs to do it's own switching according to
whether win32all or ctypes are available, but it's not a huge chore.
Both should also have all the same functions (with dummy
implementation if need be), but that's rather easy to control too.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From hans_meine at gmx.net  Fri Jan 13 11:31:17 2006
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 13 Jan 2006 17:31:17 +0100
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <43C7D121.5040801@colorado.edu>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
	<43C7D121.5040801@colorado.edu>
Message-ID: <200601131731.17753.hans_meine@gmx.net>

On Friday 13 January 2006 17:11, Fernando Perez wrote:
> Let's not put this into genutils, that file is already too crowded, and
> this is purely platform-specific code.  Instead, go ahead and make a
> winutils.py module, where all whe win32 tricks will be nicely isolated. 

OTOH, a platform-independent setConsoleTitle() would be nice, no?

FWIW, I have "\e]2;\w [\u@\h]\a" in my PS1.  (Guarded by "\[...\]" to tell the 
shell that this does not add to the prompt length within the window.)

Quoted from http://www.faqs.org/docs/Linux-mini/Xterm-Title.html :

The following sequences are useful in this respect: 
- ESC]0;stringBEL -- Set icon name and window title to string
- ESC]1;stringBEL -- Set icon name to string
- ESC]2;stringBEL -- Set window title to string
where ESC is the escape character (\033), and BEL is the bell character 
(\007).

Ciao, /  /
     /--/
    /  / ANS

PS: Sorry, re-sent due to wrong sender..



From vivainio at gmail.com  Fri Jan 13 11:44:20 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 18:44:20 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <200601131731.17753.hans_meine@gmx.net>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
	<43C7D121.5040801@colorado.edu>
	<200601131731.17753.hans_meine@gmx.net>
Message-ID: <46cb515a0601130844q59f5690dse413396d467b7289@mail.gmail.com>

On 1/13/06, Hans Meine <hans_meine at gmx.net> wrote:

> OTOH, a platform-independent setConsoleTitle() would be nice, no?

That's partly the point - platutils.set_console_title() will be a
no-op in posix until someone implements a function for it. I tried
your escape sequences one day and they didn't work properly (some
weird coincidence or oversight probably, I was using gnome-terminal).

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Fri Jan 13 11:57:21 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 13 Jan 2006 09:57:21 -0700
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <46cb515a0601130844q59f5690dse413396d467b7289@mail.gmail.com>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
	<43C7D121.5040801@colorado.edu>	<200601131731.17753.hans_meine@gmx.net>
	<46cb515a0601130844q59f5690dse413396d467b7289@mail.gmail.com>
Message-ID: <43C7DBF1.5050800@colorado.edu>

Ville Vainio wrote:
> On 1/13/06, Hans Meine <hans_meine at gmx.net> wrote:
> 
> 
>>OTOH, a platform-independent setConsoleTitle() would be nice, no?
> 
> 
> That's partly the point - platutils.set_console_title() will be a
> no-op in posix until someone implements a function for it.

Exactly.

Cheers,

f



From vivainio at gmail.com  Fri Jan 13 12:20:09 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 19:20:09 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <200601131731.17753.hans_meine@gmx.net>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
	<43C7D121.5040801@colorado.edu>
	<200601131731.17753.hans_meine@gmx.net>
Message-ID: <46cb515a0601130920p3d31ba4ey72125e5ecbe51d45@mail.gmail.com>

On 1/13/06, Hans Meine <hans_meine at gmx.net> wrote:

> FWIW, I have "\e]2;\w [\u@\h]\a" in my PS1.  (Guarded by "\[...\]" to tell the
> shell that this does not add to the prompt length within the window.)

Confirmed -

def set_title(title,mode=0):
        sys.stdout.write('\033]%d;%s\007' % (mode,title))

works fine, though the mode does not seem to do anything.

konsole seems to only change the first part of the name, so I get "foo
- Shell - ipython" while gnome-terminal goes all the way.

Now there's our posix implementation for this functionality, I suppose
it's harmless on plain old tty as well.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 12:33:02 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 19:33:02 +0200
Subject: [IPython-dev] RFC: IPython.ipapi for "public" ipython API.
Message-ID: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>

It's not immediately obvious where the extension points for ipython
are, so I figured we ought to have one module that user
extensions/config files would use to plug into ipython.

I'm of course thinking of

import IPython.ipapi as ip

ip.ipmagic("%alias ls ls -F")

def f(..): ...

ip.set_hook("editor",f)

def mymagic_impl(self,param):
  ...

ip.declare_magic("mymagic",mumagic_impl)

# takes place in working ns.

ip.exec("import os,sys")
ip.exec("from re import *")

It should be pretty easy to do (most funcs are just references to
existing funcs elsewhere), and it would help people willing to get
started quickly quite a bit.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Fri Jan 13 13:25:31 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 13 Jan 2006 11:25:31 -0700
Subject: [IPython-dev] RFC: IPython.ipapi for "public" ipython API.
In-Reply-To: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>
References: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>
Message-ID: <43C7F09B.2050803@colorado.edu>

Ville Vainio wrote:
> It's not immediately obvious where the extension points for ipython
> are, so I figured we ought to have one module that user
> extensions/config files would use to plug into ipython.
> 
> I'm of course thinking of
> 
> import IPython.ipapi as ip
> 
> ip.ipmagic("%alias ls ls -F")

The basic idea is correct, and I've been trying to slowly move in that 
direction already, with more consistent names and calling interfaces (the ip* 
functions).

There are a few things to note though:

- I don't think this can be done as a module: what ipython would those 
functions talk to?  Remember, in an embedded ipython situation, there can be 
multiple ipython instances simultaneously active within one python process, 
and those can even be nested within one another.

Embedded ipython does have its users (myself, for example :), so we need to be 
careful about how this is implemented.

- Let's make sure that users are aware that some of this may change in the 
chainsaw branch to some extent.  We should try to make decent decisions now, 
so the same code and API can carry forward to the new ipython, but in the new 
branch clean design will win over backwards compatibility.  In the current 
branch, the priorities are inverted: any changes made in trunk/ should be 
minimally disruptive to current users.

This page has some notes on extension issues:

http://projects.scipy.org/ipython/ipython/wiki/RefactoringIPython

I need to move the information in the new_design PDF from the docs into this 
wiki, so we centralize and organize the results of all design discussions in a 
clean public area.

Note that I don't think a wiki is a good place to _hold_ the discussion, for 
that a mailing list is IMHO far better.  But once a minimal idea has somewhat 
solidified, noting it down on the wiki allows the process to move forward. 
Things can still be changed, but the wiki becomes the record of the current 
state of the issue, after the back-and-forth of the arguments on the list.


Cheers,

f



From vivainio at gmail.com  Fri Jan 13 14:18:44 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 21:18:44 +0200
Subject: [IPython-dev] [RFC] I want to fix some behaviour. Hints needed
In-Reply-To: <46cb515a0601130920p3d31ba4ey72125e5ecbe51d45@mail.gmail.com>
References: <dq6pc4$ea5$2@sea.gmane.org>
	<46cb515a0601130152x1a03458asd210501f44d2429e@mail.gmail.com>
	<43C7D121.5040801@colorado.edu>
	<200601131731.17753.hans_meine@gmx.net>
	<46cb515a0601130920p3d31ba4ey72125e5ecbe51d45@mail.gmail.com>
Message-ID: <46cb515a0601131118u4e503c43jdf4009cd9956fc12@mail.gmail.com>

> Now there's our posix implementation for this functionality, I suppose
> it's harmless on plain old tty as well.

Implemented in SVN (for posix), including the "platutils" module.

platutils_win32 is also there for Alexander to seek his teeth into.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 14:31:59 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 21:31:59 +0200
Subject: [IPython-dev] RFC: IPython.ipapi for "public" ipython API.
In-Reply-To: <43C7F09B.2050803@colorado.edu>
References: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>
	<43C7F09B.2050803@colorado.edu>
Message-ID: <46cb515a0601131131v70df25a1p6a7df6ea49eaeba4@mail.gmail.com>

On 1/13/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> There are a few things to note though:
>
> - I don't think this can be done as a module: what ipython would those
> functions talk to?  Remember, in an embedded ipython situation, there can be

The answer is "it doesn't matter for now". Therefore I suggested

import IPython.ipapi as ip

At later date "ip" may be an instance of another kind of object. I
guess we could in Ipython.ipapi.instance() to acquire an instance of
ipython api for a good measure right now, even if it only returned the
module itself in the first phase.

I figure that modules that use ipapi are imported ("installed") from
already running ipython, therefore they only have access to the
resources of that ipython instance.

> Embedded ipython does have its users (myself, for example :), so we need to be
> careful about how this is implemented.

Should not be a problem if the situation is as above.

> - Let's make sure that users are aware that some of this may change in the
> chainsaw branch to some extent.  We should try to make decent decisions now,

Yes, it's "for your convenience only, though we hope to keep it as
stable as possible. Use at your own risk".

When the chainsaw:ing is done, old ipapi can be a wrapper over the new
ipapi, so the breakage can be avoided (to the extent that it matters,
considering the documented api break in 1.0).

> so the same code and API can carry forward to the new ipython, but in the new
> branch clean design will win over backwards compatibility.  In the current
> branch, the priorities are inverted: any changes made in trunk/ should be
> minimally disruptive to current users.

The disruption to current users is of course zero - it's a new module
that only wraps old functionality in a more friendly and "contained"
fashion.

I think we should be "agile" and do the simple thing at this point,
most of the work is very easy. We would of course not advertise the
new module until we are satisfied with it.

At this point I'd like to create the module and expose TryNextHook
exception - Walter's gonna need it with the displayhook stuff. :-)

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 14:36:53 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 21:36:53 +0200
Subject: [IPython-dev] Displayhook configuration (Walter take heed!)
Message-ID: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>

I guess it's time to implement configurable display hooks.

I think the most lightweight chain-of-command implemention would be:

- Rewrite Prompts.py/CachedOutput._display() to do:

for displayer in ip_display_hooks():
  try:
    displayer.display(arg)
    break
  except TryNextHook:
    pass

- Move current CachedOutput._display to another class Default

ip_display_hooks() return the list with the current display hook as
the last item. It's also the "public api" for setting display hooks -
people just prepend their own display hooks by doing

ip_display_hooks().insert(0,PipePrinter())

(other places than 0 are legal too if the user thinks he knows what he's doing)

The fictional PipePrinter would check if it is of the wanted type, and
raise TryNextHook if not (or if the processing is only partial).

I could do this, but since Walter asked for this he might be the one
to give it a shot?

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 14:42:21 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 13 Jan 2006 21:42:21 +0200
Subject: [IPython-dev] Displayhook configuration (Walter take heed!)
In-Reply-To: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>
References: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>
Message-ID: <46cb515a0601131142t71721dffk286de44f78474f96@mail.gmail.com>

On 1/13/06, Ville Vainio <vivainio at gmail.com> wrote:

> - Move current CachedOutput._display to another class Default

DefaultDisplayer, I meant to say.

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 18:02:50 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 14 Jan 2006 01:02:50 +0200
Subject: [IPython-dev] RFC: IPython.ipapi for "public" ipython API.
In-Reply-To: <88583952-E86A-4E0F-B004-30F15F2689A7@scu.edu>
References: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>
	<43C7F09B.2050803@colorado.edu>
	<46cb515a0601131131v70df25a1p6a7df6ea49eaeba4@mail.gmail.com>
	<88583952-E86A-4E0F-B004-30F15F2689A7@scu.edu>
Message-ID: <46cb515a0601131502x250ab5bcr185ddeeb0a89a068@mail.gmail.com>

CC-ing to list...

On 1/14/06, Brian Granger <bgranger at scu.edu> wrote:

> different manner.  The reason is that the new IPython is designed to
> be used in a distributed and multiprocess environment - so
> customizations need to be able to be rolled out to IPython instances
> running on _different hosts_ or in diferent processes.

Ok; I thought it would be relayed via the mechanism through which
normal ipython "front end" would be speaking to back ends - i.e.,
ip.exec("import os") would do what a normal front end does and sends
the command to remote processes.

Remoting kills direct callback funcs, of course, so instead of

ip.set_hook("blah",mymod.myfunc)

it would need to be

ip.set_hook("blah","mymod.myfunc")

and mymod would need to be installed on all the machines.

> I don't think it is a problem to add some sort of API in trunk right
> now, but we should definitely be very clear that the API will likely
> go away in the future.  The customization capabilities will remain

Ok, no problem - as it stands, it would only be a low-effort
pedagogical move to have all customization in one place. Also, the
current configuration system frightens me, I just tried adding a
config option to ipmaker with poor results and would like to offer an
alternative (for myself if noone else). :-)

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Fri Jan 13 19:59:54 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 14 Jan 2006 02:59:54 +0200
Subject: [IPython-dev] RFC: IPython.ipapi for "public" ipython API.
In-Reply-To: <46cb515a0601131502x250ab5bcr185ddeeb0a89a068@mail.gmail.com>
References: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>
	<43C7F09B.2050803@colorado.edu>
	<46cb515a0601131131v70df25a1p6a7df6ea49eaeba4@mail.gmail.com>
	<88583952-E86A-4E0F-B004-30F15F2689A7@scu.edu>
	<46cb515a0601131502x250ab5bcr185ddeeb0a89a068@mail.gmail.com>
Message-ID: <46cb515a0601131659o5b7e17fdt210dcfb6e51ae855@mail.gmail.com>

It is accomplished :-D.

In SVN now, here's a "config file" example

-----------------------------------------------
import IPython.ipapi as ip

def ankka_f(self, arg):
    print "Ankka",self,"says uppercase:",arg.upper()

ip.expose_magic("ankka",ankka_f)

ip.magic('alias sayhi echo "Testing, hi ok"')
ip.magic('alias helloworld echo "Hello world"')
ip.system('pwd')

ip.ex('import re')
ip.ex("""
def funcci(a,b):
    print a+b
print funcci(3,4)
""")
ip.ex("funcci(348,9)")

def jed_editor(self,filename, linenum=None):
    print "Calling my own editor, jed ... via hook!"
    import os
    if linenum is None: linenum = 0
    os.system('jed +%d %s' % (linenum, filename))
    print "exiting jed"

ip.set_hook('editor',jed_editor)
print "done!"
--------------------

Just put it in a file and import it... no need to %run/whatever.



From vivainio at gmail.com  Sat Jan 14 06:34:50 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 14 Jan 2006 13:34:50 +0200
Subject: [IPython-dev] Displayhook configuration (Walter take heed!)
In-Reply-To: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>
References: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>
Message-ID: <46cb515a0601140334k3f2c47f3y35bd339d0f208b07@mail.gmail.com>

On 1/13/06, Ville Vainio <vivainio at gmail.com> wrote:

> I could do this, but since Walter asked for this he might be the one
> to give it a shot?

Nevermind, I'll implement it myself (I thought we should do this via
"normal" hook mechanism and I'm converting the hooks to
chain-of-command list using an optional priority).

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From vivainio at gmail.com  Sat Jan 14 08:26:21 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 14 Jan 2006 15:26:21 +0200
Subject: [IPython-dev] Displayhook configuration (Walter take heed!)
In-Reply-To: <46cb515a0601140334k3f2c47f3y35bd339d0f208b07@mail.gmail.com>
References: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>
	<46cb515a0601140334k3f2c47f3y35bd339d0f208b07@mail.gmail.com>
Message-ID: <46cb515a0601140526l14a87edey731fa0c7268de77d@mail.gmail.com>

On 1/14/06, Ville Vainio <vivainio at gmail.com> wrote:

> Nevermind, I'll implement it myself (I thought we should do this via
> "normal" hook mechanism and I'm converting the hooks to
> chain-of-command list using an optional priority).

Implemented in svn.

Use as expected -

import IPython.ipapi as ip

def f(self,arg): ...

ip.set_hook("result_display",f)

Raise IPython.hooks.TryNext if you want to pass the result on to next
hook handler.

(Yes, I figure TryNext could be in another place as well)

--
Ville Vainio    http://tinyurl.com/2prnb
  Can't you see the world is burning
  Can't you feel its Fire burning
  Don't you know we all are burning
  The Fire of Life       -- R.N.Taylor / Changes



From Fernando.Perez at colorado.edu  Mon Jan 16 13:29:09 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 16 Jan 2006 11:29:09 -0700
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
Message-ID: <43CBE5F5.4020103@colorado.edu>

Bug report from a user - I'm forwarding it just so it's recorded here and we 
don't miss it.  I told him not to bother with filing on the tracker, as this 
should get taken are of soon by me or Ville, before the 0.7.1 bugfix release.

Cheers,

f

-------- Original Message --------
Subject: IPython 0.7 - possible bug with "%edit -p"
Date: Mon, 16 Jan 2006 11:05:51 +0000 (GMT)
From: IAN OZSVALD <i.m.ozsvald at btinternet.com>
To: Fernando.Perez at colorado.edu

Hi Fernando.  I think I have a bug, I wanted to check
that I'm not being foolish before I file a bug report.
  I've upgraded from 0.6.15 to 0.7, and I've lost the
functionality for editing the previous temporary file.


Normally I'd start to prototype new code using:
> edit
> # do some work in Textpad on Windows
> edit -p # to continue working on that previous
temporary file
but now if I use -p it just starts a new temporary
file, rather than using the code I'd generated
previously.  If I edit a file that I have saved, I can
use -p to call up that file, so '-p' is still an
option in your code, it just works differently I
think.

I've upgraded to 0.7 on two machines and the behaviour
is the same on both machines, previously it worked on
both machines.

I see a possibly-relevant Changelog entry:
http://ipython.scipy.org/ChangeLog
2006-01-02  Fernando Perez
<Fernando.Perez at colorado.edu>
	* IPython/Magic.py (magic_edit): added support to
edit in-memory
	macros (automatically creates the necessary temp
files).  %edit
	also doesn't return the file contents anymore, it's
just noise.

Is it something to do with %edit not returning file
contents for temp files?
	
Whilst going over you site looking for tips on this
problem, I noticed two broken links:
via http://ipython.scipy.org/
# If you want to browse the whole repository with a
clean inteface, use this Trac link.
# The new IPython Trac system is here, with a Wiki for
development, SVN access and more.
http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/
http://projects.scipy.org/ipython/ipython
both give 404 Not Found reports.

Assuming both are bugs, I'll figure out how to file a
bug report on each if you'd like?

I'd like to take a moment to say Thanks to you - I've
been using IPython for over a year now, it is a
fantastic system!  I do a lot of research/development
code using Python in a commercial physics research
lab, your software certainly makes my life a lot more
comfortable.

Thanks Fernando,
Ian.

Ian Ozsvald
i.m.ozsvald at btinternet.com

Personal - http://ianozsvald.com
Founder  - http://showmedo.com
Owner    - http://morconsulting.com



From vivainio at gmail.com  Mon Jan 16 13:47:11 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 16 Jan 2006 10:47:11 -0800
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
In-Reply-To: <43CBE5F5.4020103@colorado.edu>
References: <43CBE5F5.4020103@colorado.edu>
Message-ID: <46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>

On 1/16/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> Bug report from a user - I'm forwarding it just so it's recorded here and we
> don't miss it.  I told him not to bother with filing on the tracker, as this
> should get taken are of soon by me or Ville, before the 0.7.1 bugfix release.

I guess we'll need to revert to the old %edit functionality, this is
the same problem as with Alexander Belchenko. I'll take it.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Mon Jan 16 13:52:52 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 16 Jan 2006 11:52:52 -0700
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
In-Reply-To: <46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>
References: <43CBE5F5.4020103@colorado.edu>
	<46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>
Message-ID: <43CBEB84.7040307@colorado.edu>

Ville Vainio wrote:
> On 1/16/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
>>Bug report from a user - I'm forwarding it just so it's recorded here and we
>>don't miss it.  I told him not to bother with filing on the tracker, as this
>>should get taken are of soon by me or Ville, before the 0.7.1 bugfix release.
> 
> 
> I guess we'll need to revert to the old %edit functionality, this is
> the same problem as with Alexander Belchenko. I'll take it.

Yes, it's the same problem.  Thanks for looking into it.  Reverting to the old:

         if use_temp:
	            contents = file(filename).read()
  	            return contents

should be enough, though that code should read instead:

if use_temp:
     return file_read(filename)

This uses file_read from genutils, which guarantees closing the file object 
(which Python doesn't automatically enforce on file objects which go out of 
scope).

Cheers,

f



From vivainio at gmail.com  Mon Jan 16 14:15:32 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 16 Jan 2006 21:15:32 +0200
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
In-Reply-To: <43CBEB84.7040307@colorado.edu>
References: <43CBE5F5.4020103@colorado.edu>
	<46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>
	<43CBEB84.7040307@colorado.edu>
Message-ID: <46cb515a0601161115l4bae7495ib9fcfe1ac53f5523@mail.gmail.com>

On 1/16/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Yes, it's the same problem.  Thanks for looking into it.  Reverting to the old:
>
>          if use_temp:
>                     contents = file(filename).read()
>                     return contents
>
> should be enough, though that code should read instead:

Done, it works, in svn.

> if use_temp:
>      return file_read(filename)
>
> This uses file_read from genutils, which guarantees closing the file object
> (which Python doesn't automatically enforce on file objects which go out of
> scope).

Actually, CPython does, Jython doesn't. There are so much CPython
dependencies anyway that it's probably safe to assume it...

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Mon Jan 16 14:33:40 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 16 Jan 2006 12:33:40 -0700
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
In-Reply-To: <46cb515a0601161115l4bae7495ib9fcfe1ac53f5523@mail.gmail.com>
References: <43CBE5F5.4020103@colorado.edu>
	<46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>
	<43CBEB84.7040307@colorado.edu>
	<46cb515a0601161115l4bae7495ib9fcfe1ac53f5523@mail.gmail.com>
Message-ID: <43CBF514.8040004@colorado.edu>

Ville Vainio wrote:

>>This uses file_read from genutils, which guarantees closing the file object
>>(which Python doesn't automatically enforce on file objects which go out of
>>scope).
> 
> 
> Actually, CPython does, Jython doesn't. There are so much CPython
> dependencies anyway that it's probably safe to assume it...

Well, let's not assume it and use file_read in general: at some point, someone 
might want to hack on Jython/IronPython ports, and the more compatible we are, 
the better.  I know that _today_ we have sys._getframe (and probably other) 
dependencies on CPython, but it doesn't cost us anything right now to keep the 
code as open to compatibility as possible.

Cheers,

f



From vivainio at gmail.com  Mon Jan 16 14:57:51 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 16 Jan 2006 21:57:51 +0200
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
In-Reply-To: <43CBF514.8040004@colorado.edu>
References: <43CBE5F5.4020103@colorado.edu>
	<46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>
	<43CBEB84.7040307@colorado.edu>
	<46cb515a0601161115l4bae7495ib9fcfe1ac53f5523@mail.gmail.com>
	<43CBF514.8040004@colorado.edu>
Message-ID: <46cb515a0601161157w43a64c55l4c9089f7e8e1e092@mail.gmail.com>

On 1/16/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Well, let's not assume it and use file_read in general: at some point, someone
> might want to hack on Jython/IronPython ports, and the more compatible we are,
> the better.  I know that _today_ we have sys._getframe (and probably other)
> dependencies on CPython, but it doesn't cost us anything right now to keep the
> code as open to compatibility as possible.

It that case, it might be more comfortable to go with something that
wraps it all (vs having our own wrappers for operations), I'm of
course talking about the "path" module:

http://www.jorendorff.com/articles/python/path/

It greatly increases the comfort of file manipulation and I use it for
most of my python scripting at work. The "license" is liberal enough
to just copy the module over to IPython source tree and call it BSD
code.

Of course I'm not talking about porting already existing code over to
the path module, but for new code it's worth the shot.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Mon Jan 16 15:03:10 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 16 Jan 2006 13:03:10 -0700
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
In-Reply-To: <46cb515a0601161157w43a64c55l4c9089f7e8e1e092@mail.gmail.com>
References: <43CBE5F5.4020103@colorado.edu>
	<46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>
	<43CBEB84.7040307@colorado.edu>
	<46cb515a0601161115l4bae7495ib9fcfe1ac53f5523@mail.gmail.com>
	<43CBF514.8040004@colorado.edu>
	<46cb515a0601161157w43a64c55l4c9089f7e8e1e092@mail.gmail.com>
Message-ID: <43CBFBFE.9060703@colorado.edu>

Ville Vainio wrote:
> On 1/16/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>Well, let's not assume it and use file_read in general: at some point, someone
>>might want to hack on Jython/IronPython ports, and the more compatible we are,
>>the better.  I know that _today_ we have sys._getframe (and probably other)
>>dependencies on CPython, but it doesn't cost us anything right now to keep the
>>code as open to compatibility as possible.
> 
> 
> It that case, it might be more comfortable to go with something that
> wraps it all (vs having our own wrappers for operations), I'm of
> course talking about the "path" module:
> 
> http://www.jorendorff.com/articles/python/path/
> 
> It greatly increases the comfort of file manipulation and I use it for
> most of my python scripting at work. The "license" is liberal enough
> to just copy the module over to IPython source tree and call it BSD
> code.
> 
> Of course I'm not talking about porting already existing code over to
> the path module, but for new code it's worth the shot.

I've looked at path in the past, and I liked it a lot.  I'd add a note to the 
file copying this language about the license:

License: You may use path.py for whatever you wish, at your own risk. (For 
example, you may modify, relicense, and redistribute it.) It is provided 
without any guarantee or warranty of any kind, not even for merchantability or 
fitness for any purpose.

and would indicate that we're including it unmodified (for now, unless we need 
to fix anything in it), just as a convenience feature so users don't have an 
extra dependency when using ipython.

Given that ipython is strongly used as for shell-like usage, I'd say that 
shipping path makes perfect sense.  Toss it in.

Cheers,

f



From Fernando.Perez at colorado.edu  Mon Jan 16 15:28:07 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 16 Jan 2006 13:28:07 -0700
Subject: [IPython-dev] [Fwd: IPython 0.7 - possible bug with "%edit -p"]
In-Reply-To: <43CBFBFE.9060703@colorado.edu>
References: <43CBE5F5.4020103@colorado.edu>
	<46cb515a0601161047m2a652f0nb7e8b78ec24dd33a@mail.gmail.com>
	<43CBEB84.7040307@colorado.edu>
	<46cb515a0601161115l4bae7495ib9fcfe1ac53f5523@mail.gmail.com>
	<43CBF514.8040004@colorado.edu>
	<46cb515a0601161157w43a64c55l4c9089f7e8e1e092@mail.gmail.com>
	<43CBFBFE.9060703@colorado.edu>
Message-ID: <43CC01D7.1080500@colorado.edu>

Fernando Perez wrote:
> Given that ipython is strongly used as for shell-like usage
                                          ^^^^^^^^^^^^^^^^^^^^
Ugh.

Given that ipython is strongly used as a shell-like system


never half-edit a sentence, switch your attention to something else, and 
return to hit 'send' immediately.  You end up with illegible junk like this.

Sorry,

f



From Fernando.Perez at colorado.edu  Wed Jan 18 01:32:44 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 17 Jan 2006 23:32:44 -0700
Subject: [IPython-dev] access to __file__
In-Reply-To: <43C61546.6090608@colorado.edu>
References: <1510.83.206.43.56.1136973580.squirrel@83.206.43.56>
	<43C61546.6090608@colorado.edu>
Message-ID: <43CDE10C.3060306@colorado.edu>

Fernando Perez wrote:
> Vivian De Smedt wrote:
> 
>>Fernando,
>>
>>I use the svn version of IPython and I notice a small difference between
>>python brol.py and IPython run brol.py.
>>
>>It seems that IPython run brol.py do not have access to the special
>>__file__ attribute of the brol.py module.
> 
> 
> Confirmed bug, I'll try to clear it this weekend.

Fixed, will commit shortly.

Note that the bug had been present already in 0.6.15 and before, you just 
hadn't seen it (nor had I).

Thanks for the report,

f



From Fernando.Perez at colorado.edu  Wed Jan 18 01:36:44 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 17 Jan 2006 23:36:44 -0700
Subject: [IPython-dev] Displayhook configuration (Walter take heed!)
In-Reply-To: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>
References: <46cb515a0601131136y6f0aecc8jfbba91692e4d3b17@mail.gmail.com>
Message-ID: <43CDE1FC.3090502@colorado.edu>

Ville Vainio wrote:
> I guess it's time to implement configurable display hooks.
> 
> I think the most lightweight chain-of-command implemention would be:
> 
> - Rewrite Prompts.py/CachedOutput._display() to do:
> 
> for displayer in ip_display_hooks():
>   try:
>     displayer.display(arg)
>     break
>   except TryNextHook:
>     pass

Great.  I look forward to seeing what comes out of this, as ideas and some 
experimentation on this front will greatly help us on the design for the 
chainsaw work.

The pipe-filters ideas are also very interesting, so let's see what comes out 
of that.

Cheers,

f



From Fernando.Perez at colorado.edu  Wed Jan 18 01:38:29 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 17 Jan 2006 23:38:29 -0700
Subject: [IPython-dev] RFC: IPython.ipapi for "public" ipython API.
In-Reply-To: <46cb515a0601131131v70df25a1p6a7df6ea49eaeba4@mail.gmail.com>
References: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>
	<43C7F09B.2050803@colorado.edu>
	<46cb515a0601131131v70df25a1p6a7df6ea49eaeba4@mail.gmail.com>
Message-ID: <43CDE265.2080306@colorado.edu>

Ville Vainio wrote:
> On 1/13/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>There are a few things to note though:
>>
>>- I don't think this can be done as a module: what ipython would those
>>functions talk to?  Remember, in an embedded ipython situation, there can be
> 
> 
> The answer is "it doesn't matter for now". Therefore I suggested
> 
> import IPython.ipapi as ip

Good enough for now: I see you're hacking into the __IP global, which is fine 
for the stable branch.  That's something that WILL change, and the module 
approach may need to go, but we'll cross that bridge when we get to it.  For 
now, this offers already a cleaner interface, which is a net win for the users 
of the stable branch.


Cheers,

f



From vds at aisystems.be  Wed Jan 18 03:01:28 2006
From: vds at aisystems.be (Vivian De Smedt)
Date: Wed, 18 Jan 2006 09:01:28 +0100 (CET)
Subject: [IPython-dev] access to __file__
Message-ID: <53133.212.89.8.99.1137571288.squirrel@212.89.8.99>

Fernando,

I'm impressed and impatient to test it :-)
I'll be only be able to get the new version friday but be sure I'll test it.

Thanks again for your wonderfull IPython.

Cheers,
Vivian.



From Fernando.Perez at colorado.edu  Wed Jan 18 02:34:23 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 18 Jan 2006 00:34:23 -0700
Subject: [IPython-dev] access to __file__
In-Reply-To: <53133.212.89.8.99.1137571288.squirrel@212.89.8.99>
References: <53133.212.89.8.99.1137571288.squirrel@212.89.8.99>
Message-ID: <43CDEF7F.3030509@colorado.edu>

Vivian De Smedt wrote:
> Fernando,
> 
> I'm impressed and impatient to test it :-)
> I'll be only be able to get the new version friday but be sure I'll test it.

Just committed to SVN, let me know how it goes when you get a chance.


> Thanks again for your wonderfull IPython.

Glad it's useful.

Best,

f



From vivainio at gmail.com  Wed Jan 18 03:37:58 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 18 Jan 2006 10:37:58 +0200
Subject: [IPython-dev] RFC: IPython.ipapi for "public" ipython API.
In-Reply-To: <43CDE265.2080306@colorado.edu>
References: <46cb515a0601130933l78a2e75ch6b94f671b25b8c09@mail.gmail.com>
	<43C7F09B.2050803@colorado.edu>
	<46cb515a0601131131v70df25a1p6a7df6ea49eaeba4@mail.gmail.com>
	<43CDE265.2080306@colorado.edu>
Message-ID: <46cb515a0601180037n558ad03fvdadef73495707386@mail.gmail.com>

On 1/18/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Good enough for now: I see you're hacking into the __IP global, which is fine
> for the stable branch.  That's something that WILL change, and the module

Actually, I'm not - the __IP is set in _init_with_shell() with which
the interpreter object "introduces" itself to the module. It just
happens to be called __IP, I can rename it if it's confusing.

> approach may need to go, but we'll cross that bridge when we get to it.  For

I admit that the current module approach breaks if multiple ipython
shells exist in the same process and introduce themselves to the IP
api (how common is that anyway?). I think I'll add a factory function
"get_api()" that returns what is now used as "ip" in the examples.

So instead of

import IPython.ipapi as ip

we do

import IPython.ipapi
ip = IPython.ipapi.get_api()

Which for now returns the module itself, but in the future will be
guaranteed (at least pre-1.0) to point at the same shell instance even
when multiple shells are instantiated.

Incidentally, anyone have a good idea how to return the current module?

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From jorgen.stenarson at bostream.nu  Wed Jan 18 16:02:45 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 18 Jan 2006 22:02:45 +0100
Subject: [IPython-dev] Bug in revision 1029+
Message-ID: <43CEACF5.6080603@bostream.nu>

Hi

%run seems to have changed how it handles stack frames from revision 
1029. The attached python file a.py and b.py works when executed from 
the commandline with python a.py and python b.py respectively. See 
transcript below.

In revision 1028 %run b.py works but not a.py. 1029+ fails on both %run 
a.py and %run b.py. Importing a before executing %run a.py work, but not 
%run b.py. Importing b before makes both %run a.py and %run b.py work.

I use this technique to get a function that can return the source of the 
  module that the caller is in. If someone knows a better way I'd love 
to hear it.

I have done most of the testing of this on windows.


/J?rgen

transcript of commandline use:
 > python a.py
import inspect

def g():
     q=inspect.stack()[1]
     m=inspect.getmodule(q[0])
     src=inspect.getsource(m)
     return src

t=g()
print t

 > python b.py
import inspect

def g():
     q=inspect.stack()[1]
     m=inspect.getmodule(q[0])
     src=inspect.getsource(m)
     return src

t=g()
print t

----------------------------------------------------------------------
import a

print "-"*70
print a.g()




From vivainio at gmail.com  Wed Jan 18 16:22:52 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 18 Jan 2006 23:22:52 +0200
Subject: [IPython-dev] Bug in revision 1029+
In-Reply-To: <43CEACF5.6080603@bostream.nu>
References: <43CEACF5.6080603@bostream.nu>
Message-ID: <46cb515a0601181322p6818d52eq28c131b76cb052bc@mail.gmail.com>

On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> Hi
>
> %run seems to have changed how it handles stack frames from revision
> 1029. The attached python file a.py and b.py works when executed from

http://projects.scipy.org/ipython/ipython/changeset/1029

Apparently assigning the __file__ variable screws up "inspect" operations.

It all seems rather magical, perhaps there are also other evil side
effects on assigning __file__? I'm thinking that perhaps we should
leave __file__ unassigned after all.

Though what you are doing here doesn't seem too safe/predictable either :-).

> I use this technique to get a function that can return the source of the
>   module that the caller is in. If someone knows a better way I'd love
> to hear it.

I don't have much time for this right now, but why do you use
inspect.getmodule and inspect.getsource? Now that I'm looking at
inspect.stack() contents, it seems to have the file name and line
number directly available...

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From jorgen.stenarson at bostream.nu  Wed Jan 18 16:25:40 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 18 Jan 2006 22:25:40 +0100
Subject: [IPython-dev] Bug in ??
Message-ID: <43CEB254.3070402@bostream.nu>

Hi again,

thought I'd mention another bug I have meant to report for a while. When 
doing ?? on a compiled module you get the binary dumped as if it was the 
source of the module.

/J?rgen



From vivainio at gmail.com  Wed Jan 18 16:31:45 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 18 Jan 2006 23:31:45 +0200
Subject: [IPython-dev] Bug in ??
In-Reply-To: <43CEB254.3070402@bostream.nu>
References: <43CEB254.3070402@bostream.nu>
Message-ID: <46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>

On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> thought I'd mention another bug I have meant to report for a while. When
> doing ?? on a compiled module you get the binary dumped as if it was the
> source of the module.

Thanks for the report, I'll fix it tomorrow.

Keep the reports coming, 0.7.1 is just around the corner. :-)

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Wed Jan 18 16:31:59 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 18 Jan 2006 14:31:59 -0700
Subject: [IPython-dev] Bug in ??
In-Reply-To: <43CEB254.3070402@bostream.nu>
References: <43CEB254.3070402@bostream.nu>
Message-ID: <43CEB3CF.4060400@colorado.edu>

J?rgen Stenarson wrote:
> Hi again,
> 
> thought I'd mention another bug I have meant to report for a while. When 
> doing ?? on a compiled module you get the binary dumped as if it was the 
> source of the module.

Yup, I'd never seen it but you are right, it happens.

We should be able to easily fix this one, by only showing source for files 
that end in .py.

Cheers,

f



From jorgen.stenarson at bostream.nu  Wed Jan 18 16:32:15 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 18 Jan 2006 22:32:15 +0100
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
	<46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
Message-ID: <43CEB3DF.9020108@bostream.nu>

Ville Vainio skrev:
> On 1/12/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
>> Thanks, Ville.  I suspect this will matter more to win32 users, who have to
>> deal with \ path separators.
> 
This reminds me of a few changes I have done to Gary Bishops readline 
module.

1. Added paste from clipboard. Two version one direct paste and one that 
tries to do some smart modifications of the pasted data. If it looks 
like a path (essentially short string <250bytes, no tabs or newlines) 
then all \ are replaced by / all spaces are escaped by \. If the pasted 
string contains tabs it assume you want to paste tabseparated data and 
will build a nested list structure if all data is numeric it will be a 
call to array as well (quite handy for pasting data from excel).

2. Fixed support for some international characters (i.e. swedish 
??????). This is quite a hack but it makes it possible to type most path 
names I encounter. The hack requires a switch from DOS codepage 850 to 
the codepage that is standard on windows on my machine 1252 and a change 
of font in the console window to lucida console. (Code page is changed 
by chcp 1252). For some reason (even in plain interactive python) if I 
try to open a file with a name containing swedish characters it won't 
work unless I do this switch of code pages.

3. I have also added ctrl-k ctrl-y. At this time they are connected to 
the clipboard, I don't know if this is standard readline behaviour or not.

4. and some stuff I don't remember

I did send patches for this to Gary some time before christmas but I 
haven't heard from him and there have not been any changes in CVS on 
sourceforge. Does any one knows if the email in the setup.py is correct?

I could post it to this list if there is an interest.

/J?rgen









From Fernando.Perez at colorado.edu  Wed Jan 18 16:35:10 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 18 Jan 2006 14:35:10 -0700
Subject: [IPython-dev] Bug in ??
In-Reply-To: <46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
References: <43CEB254.3070402@bostream.nu>
	<46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
Message-ID: <43CEB48E.2050106@colorado.edu>

Ville Vainio wrote:
> On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
> 
>>thought I'd mention another bug I have meant to report for a while. When
>>doing ?? on a compiled module you get the binary dumped as if it was the
>>source of the module.
> 
> 
> Thanks for the report, I'll fix it tomorrow.
> 
> Keep the reports coming, 0.7.1 is just around the corner. :-)

Yes.  I have on my plate a threading and an auto-indenting bug, and I'll call 
it done.  I need it out quick, as I'll be using it at a conference Feb. 4.

Cheers,

f



From Fernando.Perez at colorado.edu  Wed Jan 18 16:38:23 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 18 Jan 2006 14:38:23 -0700
Subject: [IPython-dev] Bug in revision 1029+
In-Reply-To: <46cb515a0601181322p6818d52eq28c131b76cb052bc@mail.gmail.com>
References: <43CEACF5.6080603@bostream.nu>
	<46cb515a0601181322p6818d52eq28c131b76cb052bc@mail.gmail.com>
Message-ID: <43CEB54F.3020807@colorado.edu>

Ville Vainio wrote:
> On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
> 
>>Hi
>>
>>%run seems to have changed how it handles stack frames from revision
>>1029. The attached python file a.py and b.py works when executed from
> 
> 
> http://projects.scipy.org/ipython/ipython/changeset/1029
> 
> Apparently assigning the __file__ variable screws up "inspect" operations.
> 
> It all seems rather magical, perhaps there are also other evil side
> effects on assigning __file__? I'm thinking that perhaps we should
> leave __file__ unassigned after all.

Shoot.  I added __file__ to try and match the behavior of the standard 
interpreter, which DOES define such names in the script's namespace.  This was 
reported as a bug by Vivian a few days ago.  I'll try to look into Jorgen's 
report in more detail tonight, and at least find what the proper solution is.

I do think that, since Python determines that __file__ IS always defined in 
the execution namespace of a script, we should certainly declare it.

Cheers,

f



From vivainio at gmail.com  Wed Jan 18 16:54:31 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 18 Jan 2006 23:54:31 +0200
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <43CEB3DF.9020108@bostream.nu>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
	<46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
	<43CEB3DF.9020108@bostream.nu>
Message-ID: <46cb515a0601181354t5c5ec714j81e6bb3285a2b27@mail.gmail.com>

On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> 2. Fixed support for some international characters (i.e. swedish
> ??????). This is quite a hack but it makes it possible to type most path

This is great stuff! Someone else said to have done it but it's a long
while ago, and nothing came of it.

I say we put a fork of the windows readline on ipython svn (though not
under ipython tree). The author of readline said a while ago that it's
open source, and he wondered why people can't get around to fixing it
on their own and put out their own version. We shouldn't wait for the
author to put out the patched version, this is a feature that is
sorely needed by quite a few.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Wed Jan 18 17:05:58 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 18 Jan 2006 15:05:58 -0700
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <46cb515a0601181354t5c5ec714j81e6bb3285a2b27@mail.gmail.com>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
	<46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
	<43CEB3DF.9020108@bostream.nu>
	<46cb515a0601181354t5c5ec714j81e6bb3285a2b27@mail.gmail.com>
Message-ID: <43CEBBC6.2060400@colorado.edu>

Ville Vainio wrote:
> On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
> 
>>2. Fixed support for some international characters (i.e. swedish
>>??????). This is quite a hack but it makes it possible to type most path
> 
> 
> This is great stuff! Someone else said to have done it but it's a long
> while ago, and nothing came of it.
> 
> I say we put a fork of the windows readline on ipython svn (though not
> under ipython tree). The author of readline said a while ago that it's
> open source, and he wondered why people can't get around to fixing it
> on their own and put out their own version. We shouldn't wait for the
> author to put out the patched version, this is a feature that is
> sorely needed by quite a few.

Well, actually we could ship it as a subpackage:

import IPython.winreadline

This would also shield us from collisions with stray readline-like libraries 
which are out there and have caused problems in the past.  Adding this as a 
subpackage to the tree is trivial, and since this module is pure python, it 
won't cause any problems either at distribution nor at install time.

It adds a little to the package, but it's just 20Kb, that's peanuts these 
days, even if it gets carried around in *nix pacakges.

I can send Gary a note to this effect, but I remember he explicitly said he 
was Ok with the idea, as he has little time for readline maintenance.  We'll 
keep all original authorship notices, as well as adding a credit in the manual.

Let's leave this for next week though: I want to push 0.7.1 this weekend, so I 
don't have any funny surprises on my trip.  So please don't commit it yet, 
until we've shipped 0.7.1 (or work on a branch if you want to get started, SVN 
branching is cheap and easy).

Cheers,

f



From rocky at panix.com  Wed Jan 18 17:39:26 2006
From: rocky at panix.com (R. Bernstein)
Date: Wed, 18 Jan 2006 17:39:26 -0500
Subject: [IPython-dev] 0.7.1 around the corner? (Was  Bug in ??)
In-Reply-To: <46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
References: <43CEB254.3070402@bostream.nu>
	<46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
Message-ID: <17358.50078.792764.992788@panix3.panix.com>

Ville Vainio writes:
 > Thanks for the report, I'll fix it tomorrow.
 > 
 > Keep the reports coming, 0.7.1 is just around the corner. :-)

I guess I better speak up then.... 

I've been working on a little revision of the pdb.py to make it more
usuable. Things like adding a gdb "run" (restart), turning line
tracing on/off, filling out the command set using gdb as a guidance.

I'd like this to be usable from ipython with minimal fuss. Also to the
extent possible, I'd like for both the stock pdb debugger and this new
one coexist. So if folks have suggestions for how to keep
interoperability in both these areas, I'd be grateful.

Right now the module is pydb (file pydb.py) while the class is Pdb --
same as the stock debugger. Having two Pdb classes is is bad from the
standpoint of being able to have both around at the same time and
possibly the confusion as to which is currently in use. However Pdb
may be desirable from ipython standpoint since that's what it imports.

Does ipython right now have any existing mechanism for handling the
two debugger problem? If not, is there something simple that
could/should be added?

Thanks.


The CVS for what I've been doing is here: 
 http://cvs.sourceforge.net/viewcvs.py/bashdb/pydb/

There was also an initial release of the code that you can find on
sourceforge, but things have progressed a bit beyond that. In that,
the class was called Pydb which (if I'm not mistaken) would make
ipython interoperability harder.



From Fernando.Perez at colorado.edu  Wed Jan 18 17:45:39 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 18 Jan 2006 15:45:39 -0700
Subject: [IPython-dev] 0.7.1 around the corner? (Was  Bug in ??)
In-Reply-To: <17358.50078.792764.992788@panix3.panix.com>
References: <43CEB254.3070402@bostream.nu>
	<46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
	<17358.50078.792764.992788@panix3.panix.com>
Message-ID: <43CEC513.4020007@colorado.edu>

R. Bernstein wrote:
> Ville Vainio writes:
>  > Thanks for the report, I'll fix it tomorrow.
>  > 
>  > Keep the reports coming, 0.7.1 is just around the corner. :-)
> 
> I guess I better speak up then.... 

Thanks for pitching in with this, but note that as I said before, I want to 
draw the line on new features for 0.7.1.   I need to present a talk using 
ipython at a conference in a week, so I just want to close the current 
regressions that 0.7.0 introduced from 0.6.15.  Once we fix the remaining 
glitches, I want to ship WITHOUT any more new code (which opens the door to 
new bugs).  This will be done this coming weekend, so all new ideas can move 
forward then.

At that point, I'll shift attention from ipython/trunk to chainsaw/, and Ville 
can continue the effort here.  I just wanted to leave him with a clean release 
before switching gears.

Cheers,

f



From Fernando.Perez at colorado.edu  Wed Jan 18 17:53:30 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 18 Jan 2006 15:53:30 -0700
Subject: [IPython-dev] 0.7.1 around the corner? (Was  Bug in ??)
In-Reply-To: <17358.50078.792764.992788@panix3.panix.com>
References: <43CEB254.3070402@bostream.nu>
	<46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
	<17358.50078.792764.992788@panix3.panix.com>
Message-ID: <43CEC6EA.1090000@colorado.edu>

R. Bernstein wrote:

> I've been working on a little revision of the pdb.py to make it more
> usuable. Things like adding a gdb "run" (restart), turning line
> tracing on/off, filling out the command set using gdb as a guidance.
> 
> I'd like this to be usable from ipython with minimal fuss. Also to the
> extent possible, I'd like for both the stock pdb debugger and this new
> one coexist. So if folks have suggestions for how to keep
> interoperability in both these areas, I'd be grateful.

Having said that (my previous message...), this does look like perfect grounds 
for interoperability with ipython, so thanks for coming here.  Hopefully we 
can play with your code soon and see how to best make it work.

best,

f



From vivainio at gmail.com  Thu Jan 19 02:53:38 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 19 Jan 2006 09:53:38 +0200
Subject: [IPython-dev] 0.7.1 around the corner? (Was Bug in ??)
In-Reply-To: <17358.50078.792764.992788@panix3.panix.com>
References: <43CEB254.3070402@bostream.nu>
	<46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
	<17358.50078.792764.992788@panix3.panix.com>
Message-ID: <46cb515a0601182353l2f1ddbddl30617fe2a7ae7d0d@mail.gmail.com>

On 1/19/06, R. Bernstein <rocky at panix.com> wrote:

> I've been working on a little revision of the pdb.py to make it more
> usuable. Things like adding a gdb "run" (restart), turning line
> tracing on/off, filling out the command set using gdb as a guidance.
>
> I'd like this to be usable from ipython with minimal fuss. Also to the
> extent possible, I'd like for both the stock pdb debugger and this new
> one coexist. So if folks have suggestions for how to keep
> interoperability in both these areas, I'd be grateful.

We can add more hooks, that's the plan in any case post-0.7.1. There's
no need to rush anything in, I imagine the time period between 0.7.1 -
0.7.2 is not going to be as long as between 0.6.15 - 0.7.0.

This is also something where you can help; look for suitable hook
candidates and submit a patch. With your debugger implementation you
could ship an ipython extension that installs the required hooks, and
then import the extension in the ipython startup config files.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From jorgen.stenarson at bostream.nu  Thu Jan 19 13:24:00 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 19 Jan 2006 19:24:00 +0100
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <43CEBBC6.2060400@colorado.edu>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
	<46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
	<43CEB3DF.9020108@bostream.nu>
	<46cb515a0601181354t5c5ec714j81e6bb3285a2b27@mail.gmail.com>
	<43CEBBC6.2060400@colorado.edu>
Message-ID: <43CFD940.9090201@bostream.nu>

Fernando Perez skrev:
> Ville Vainio wrote:
>> On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
>>
>>
>>> 2. Fixed support for some international characters (i.e. swedish
>>> ??????). This is quite a hack but it makes it possible to type most path
>>
>>
>> This is great stuff! Someone else said to have done it but it's a long
>> while ago, and nothing came of it.
>>
>> I say we put a fork of the windows readline on ipython svn (though not
>> under ipython tree). The author of readline said a while ago that it's
>> open source, and he wondered why people can't get around to fixing it
>> on their own and put out their own version. We shouldn't wait for the
>> author to put out the patched version, this is a feature that is
>> sorely needed by quite a few.
> 
> Well, actually we could ship it as a subpackage:
> 
> import IPython.winreadline
> 
> This would also shield us from collisions with stray readline-like 
> libraries which are out there and have caused problems in the past.  
> Adding this as a subpackage to the tree is trivial, and since this 
> module is pure python, it won't cause any problems either at 
> distribution nor at install time.
There is the issue with ctypes dependence for this feature. But it 
reduces the dependence to just one package.


> 
> It adds a little to the package, but it's just 20Kb, that's peanuts 
> these days, even if it gets carried around in *nix pacakges.
> 
> I can send Gary a note to this effect, but I remember he explicitly said 
> he was Ok with the idea, as he has little time for readline 
> maintenance.  We'll keep all original authorship notices, as well as 
> adding a credit in the manual.
> 
> Let's leave this for next week though: I want to push 0.7.1 this 
> weekend, so I don't have any funny surprises on my trip.  So please 
> don't commit it yet, until we've shipped 0.7.1 (or work on a branch if 
> you want to get started, SVN branching is cheap and easy).
> 
Ok, I'll look into packaging my work so far and post during the weekend.

/J?rgen






From vivainio at gmail.com  Thu Jan 19 14:52:48 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 19 Jan 2006 11:52:48 -0800
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <43CFD940.9090201@bostream.nu>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
	<46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
	<43CEB3DF.9020108@bostream.nu>
	<46cb515a0601181354t5c5ec714j81e6bb3285a2b27@mail.gmail.com>
	<43CEBBC6.2060400@colorado.edu> <43CFD940.9090201@bostream.nu>
Message-ID: <46cb515a0601191152r6a38fbam9c886e66d02888a9@mail.gmail.com>

On 1/19/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> Ok, I'll look into packaging my work so far and post during the weekend.

Great. Let's do it in two phases:

1. Commit the pristine readline

2. Commit the version with your patches.

That way we may be able to apply your patches to a new upstream
version of readline if/when such a thing is released.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Thu Jan 19 16:13:54 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 19 Jan 2006 14:13:54 -0700
Subject: [IPython-dev] Magics, aliases now use raw strings!
In-Reply-To: <43CFD940.9090201@bostream.nu>
References: <46cb515a0601120926r610e52ddld15d0d7c21088180@mail.gmail.com>
	<43C69D22.8030305@colorado.edu>
	<46cb515a0601121155i23bb72ddo66f8a23131011615@mail.gmail.com>
	<43CEB3DF.9020108@bostream.nu>
	<46cb515a0601181354t5c5ec714j81e6bb3285a2b27@mail.gmail.com>
	<43CEBBC6.2060400@colorado.edu> <43CFD940.9090201@bostream.nu>
Message-ID: <43D00112.7060309@colorado.edu>

J?rgen Stenarson wrote:

>>Well, actually we could ship it as a subpackage:
>>
>>import IPython.winreadline
>>
>>This would also shield us from collisions with stray readline-like 
>>libraries which are out there and have caused problems in the past.  
>>Adding this as a subpackage to the tree is trivial, and since this 
>>module is pure python, it won't cause any problems either at 
>>distribution nor at install time.
> 
> There is the issue with ctypes dependence for this feature. But it 
> reduces the dependence to just one package.

Yes, win32 users will still need ctypes and win32all.  But that's OK: those 
are well-maintained packages (and ctypes is going into the python stdlib for 
2.5, so that will be one less dependency).

Ville: when you bring it in, please make sure to call it winreadline, NOT 
readline, so we don't shadow the stdlib readline on local imports.

Cheers,

f



From Fernando.Perez at colorado.edu  Fri Jan 20 04:15:23 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 02:15:23 -0700
Subject: [IPython-dev] Problem with autoindent
In-Reply-To: <43C6AC4C.3030408@colorado.edu>
References: <17350.42927.403115.622828@monster.iitb.ac.in>
	<43C6AC4C.3030408@colorado.edu>
Message-ID: <43D0AA2B.40602@colorado.edu>

Fernando Perez wrote:
> Prabhu Ramachandran wrote:
> 
>>Hi,
>>
>>With my SVN checkout of a few days back I get this nasty error:
>>
>>In [1]: x = 1
>>
>>In [2]: if x>0:
>>   ...:     print 'g'
>>   ...: elif x == 0:
>>------------------------------------------------------------
>>IndentationError: unindent does not match any outer indentation level (<ipython console>, line 3)
>>
>>
>>Very embarrasing, especially when this happens live in class! ;-)
>>
>>If I turn off autoindent then things are fine.
> 
> 
> Nasty, nasty.  Sorry.  Will get fixed.

This should be good in SVN now, along with having restored the multiline paste 
capabilities.  Let's see if I got this right (it took me a while to realize 
that the right approach, as usual, was actually the simplest).

Cheers,

f



From Fernando.Perez at colorado.edu  Fri Jan 20 04:20:10 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 02:20:10 -0700
Subject: [IPython-dev] SVN testers?
Message-ID: <43D0AB4A.40608@colorado.edu>

Hi all,

if I can get the threading bug fixed this weekend, I'll try to release 0.7.2 
soon.  I'd greatly appreciate anyone willing to run off SVN to let me know of 
any problems.  I just checked in a tentative fix for the pasting of multiline 
input when autoindent is on.  It works so far for me, but that logic is a 
little subtle, and I've seen corner cases before where I've broken it.  I'd 
really like this to work, but I'm not 100% convinced that it _can_ really work 
unambiguously.

Ville, in case you have a chance to play with the storage mechanism:

In [1]: class foo: pass
    ...:

In [2]: f = foo()

In [3]: store foo
Stored 'foo' (18 bytes)

In [4]: store f
Stored 'f' (25 bytes)

In [5]: quit

abdul[homepage]> ip
Unable to restore variable 'foo', ignoring (use %store -d to forget!)
The error was: exceptions.AttributeError
Unable to restore variable 'f', ignoring (use %store -d to forget!)
The error was: exceptions.AttributeError
Python 2.3.4 (#1, Feb  2 2005, 12:11:53)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.1.svn -- An enhanced Interactive Python.
[...]


It seems that instances of classes defined interactively can't be %stored.

Cheers,

f



From prabhu_r at users.sf.net  Fri Jan 20 04:26:19 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 20 Jan 2006 14:56:19 +0530
Subject: [IPython-dev] Problem with autoindent
In-Reply-To: <43D0AA2B.40602@colorado.edu>
References: <17350.42927.403115.622828@monster.iitb.ac.in>
	<43C6AC4C.3030408@colorado.edu> <43D0AA2B.40602@colorado.edu>
Message-ID: <17360.44219.371468.281018@prpc.aero.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >>> If I turn off autoindent then things are fine.
    >> Nasty, nasty.  Sorry.  Will get fixed.

    Fernando> This should be good in SVN now, along with having
    Fernando> restored the multiline paste capabilities.  Let's see if
    Fernando> I got this right (it took me a while to realize that the
    Fernando> right approach, as usual, was actually the simplest).

Thanks, I'll test it out when I can and let you know if I see any
problems.

cheers,
prabhu



From vivainio at gmail.com  Fri Jan 20 08:00:30 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 20 Jan 2006 15:00:30 +0200
Subject: [IPython-dev] SVN testers?
In-Reply-To: <43D0AB4A.40608@colorado.edu>
References: <43D0AB4A.40608@colorado.edu>
Message-ID: <46cb515a0601200500q7247f5ecv7b04b2d6797bac3b@mail.gmail.com>

On 1/20/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> It seems that instances of classes defined interactively can't be %stored.

True. I changed %store to complain when trying to store such objects. In SVN.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Fri Jan 20 09:24:30 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 20 Jan 2006 16:24:30 +0200
Subject: [IPython-dev] SVN testers?
In-Reply-To: <43D0AB4A.40608@colorado.edu>
References: <43D0AB4A.40608@colorado.edu>
Message-ID: <46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>

On 1/20/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> any problems.  I just checked in a tentative fix for the pasting of multiline
> input when autoindent is on.  It works so far for me, but that logic is a

Doesn't work for me when there are tabs as indent marks. Spaces are ok:

if 1:
	print "hi"
else:
	print "haaoa"

(with tabs)

Outputs the following (weirdly, it outputs directory contents!)

[c:\Temp]|13> if 1:
         |..>
cssTrace.txt              ncf_uninstall.txt         Python_S60_SDK1_2_err.log
mtiwrapper.txt            Pyhton_S60_SDK1_2.log
         |..>     \tprint "hi"
         |..> else:
         |..>
cssTrace.txt              ncf_uninstall.txt         Python_S60_SDK1_2_err.log
mtiwrapper.txt            Pyhton_S60_SDK1_2.log
         |..>     \tprint "haaoa"
         |..>
hi






--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Fri Jan 20 10:53:05 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 20 Jan 2006 17:53:05 +0200
Subject: [IPython-dev] SVN testers?
In-Reply-To: <46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
Message-ID: <46cb515a0601200753v181cfbcayef12507d83823e8f@mail.gmail.com>

On 1/20/06, Ville Vainio <vivainio at gmail.com> wrote:

> Outputs the following (weirdly, it outputs directory contents!)

Of course this is because readline thinks pasted tab is an attempt at
filename expansion... I guess there is no way around that. Nice gotcha
though.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Fri Jan 20 12:55:22 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 10:55:22 -0700
Subject: [IPython-dev] SVN testers?
In-Reply-To: <46cb515a0601200500q7247f5ecv7b04b2d6797bac3b@mail.gmail.com>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200500q7247f5ecv7b04b2d6797bac3b@mail.gmail.com>
Message-ID: <43D1240A.7020607@colorado.edu>

Ville Vainio wrote:
> On 1/20/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>It seems that instances of classes defined interactively can't be %stored.
> 
> 
> True. I changed %store to complain when trying to store such objects. In SVN.

Is it fixable?  It certainly doesn't work even for plain python:

 >>> class foo: pass
...
 >>> pickle.dump(foo,file('foo.pkl','w'))

[new session]

 >>> foo = pickle.load(file('foo.pkl'))
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.3/pickle.py", line 1390, in load
     return Unpickler(file).load()
   File "/usr/lib/python2.3/pickle.py", line 872, in load
     dispatch[key](self)
   File "/usr/lib/python2.3/pickle.py", line 1104, in load_global
     klass = self.find_class(module, name)
   File "/usr/lib/python2.3/pickle.py", line 1140, in find_class
     klass = getattr(mod, name)
AttributeError: 'module' object has no attribute 'foo'


So it's not an ipython regression re. plain python.  But it would be nice at 
some point to come up with some namespace trick that helps here.  Oh well, 
let's not worry abou this for now.  Thahks for putting the warning in, better 
than failing upon reload later.

Cheers,

f



From Fernando.Perez at colorado.edu  Fri Jan 20 13:08:41 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 11:08:41 -0700
Subject: [IPython-dev] SVN testers?
In-Reply-To: <46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
Message-ID: <43D12729.2010208@colorado.edu>

Ville Vainio wrote:
> On 1/20/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>any problems.  I just checked in a tentative fix for the pasting of multiline
>>input when autoindent is on.  It works so far for me, but that logic is a
> 
> 
> Doesn't work for me when there are tabs as indent marks. Spaces are ok:

Well, it does work under Linux (these are pasted from files open in an editor, 
not typed in):

In [8]: if 1:
    ...:         print 'indented with spaces'
    ...:     print 'more'
    ...: else:
    ...:         print 'nothing'
    ...:
indented with spaces
more


In [10]: if 1:
    ....:        print 'indented with tabs'
    ....:         print 'more'
    ....: else:
    ....:        print 'nothing'
    ....:
indented with tabs
more


It may be a win32/readline thing, dunno.

Thanks for testing, at least we seem to be finally on track with this, even if 
the system isn't 100% perfect.  At least it doesn't seem to do the WRONG thing 
(like Prabhu reported a few days back), and it does add convenience in a 
number of cases.

Cheers,

f



From vivainio at gmail.com  Fri Jan 20 13:24:16 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 20 Jan 2006 20:24:16 +0200
Subject: [IPython-dev] SVN testers?
In-Reply-To: <43D1240A.7020607@colorado.edu>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200500q7247f5ecv7b04b2d6797bac3b@mail.gmail.com>
	<43D1240A.7020607@colorado.edu>
Message-ID: <46cb515a0601201024x3c57a9eayeaacb5310f312111@mail.gmail.com>

On 1/20/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> > True. I changed %store to complain when trying to store such objects. In SVN.
>
> Is it fixable?  It certainly doesn't work even for plain python:

Not easily, you can't pickle code (and the code is forgotten between sessions).

"marshall" should be usable for this but looking into that could take a while...

An easier pseudo-solution would be to store a Struct for objects like
this, so that at least the attributes (if not methods) could be saved.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Fri Jan 20 13:26:52 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 11:26:52 -0700
Subject: [IPython-dev] SVN testers?
In-Reply-To: <46cb515a0601201024x3c57a9eayeaacb5310f312111@mail.gmail.com>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200500q7247f5ecv7b04b2d6797bac3b@mail.gmail.com>
	<43D1240A.7020607@colorado.edu>
	<46cb515a0601201024x3c57a9eayeaacb5310f312111@mail.gmail.com>
Message-ID: <43D12B6C.7010108@colorado.edu>

Ville Vainio wrote:
> On 1/20/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>>True. I changed %store to complain when trying to store such objects. In SVN.
>>
>>Is it fixable?  It certainly doesn't work even for plain python:
> 
> 
> Not easily, you can't pickle code (and the code is forgotten between sessions).
> 
> "marshall" should be usable for this but looking into that could take a while...
> 
> An easier pseudo-solution would be to store a Struct for objects like
> this, so that at least the attributes (if not methods) could be saved.

Well, I'll leave it up to you to decide on a decent long-term solution; you've 
thought more about the storage system than I have.

I think I have a way to fix the threading bug that's been nagging us, I'll try 
to work on that tomorrow.  If I get it all done, I'll put the 0.7.1 release 
out, I'm really pressed for time.  Then you can experiment at a more leisurely 
pace.

Regards,

f



From jorgen.stenarson at bostream.nu  Fri Jan 20 15:35:54 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Fri, 20 Jan 2006 21:35:54 +0100
Subject: [IPython-dev] winreadline
Message-ID: <43D149AA.6090005@bostream.nu>

Hi

attached is a patch for integrating winreadline with ipython. This patch 
defaults to use winreadline on windows (sys.platform=="win32" and if not 
available tries readline, we may want to make winreadline optional. I 
have not tested this extensively yet. Is there something else that needs 
changing besides init_readline in iplib.py?

The patch includes:
iplib.py    change to use winreadline on win32
IPython.winreadline  new package directory copied from UNC readline 1.12


How do we proceed? Should I get a subversion account so I can start a 
branch for the winreadline patch? Or should we do this work over the 
list? Any way I have identified a few things that need to be considered:

* Add notice that this is originally from Gary Bishop.
* How use ipython.winreadline with plain interactive python?
* Force use of winreadline or user choice on windows? Default 
winreadline user can change?
* What lineendings? Currently mixed windows, unix. By the way, seems 
ipython is also mixed.
* Change to 4 space indents

/J?rgen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: winreadline.patch
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060120/2dfc673e/attachment.ksh>

From arnd.baecker at web.de  Fri Jan 20 16:04:56 2006
From: arnd.baecker at web.de (Arnd Baecker)
Date: Fri, 20 Jan 2006 22:04:56 +0100 (CET)
Subject: [IPython-dev] SVN testers?
In-Reply-To: <46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
Message-ID: <Pine.LNX.4.51.0601202203380.3472@ptpcp8.phy.tu-dresden.de>

I just updated from svn - Pasting the following:

class Rectangle:
    def __init__(self, l1=1.0, l2=2.0):
        self.l1 = l1
        self.l2 = l2

    def get_area(self):
        return self.l1 * self.l2

    area = property(get_area)


gives:

In [14]: %autoindent
Automatic indentation is: ON
In [15]: class Rectangle:
   ....:         def __init__(self, l1=1.0, l2=2.0):
   ....:             self.l1 = l1
   ....:         self.l2 = l2
   ....:
In [16]:     def get_area(self):
------------------------------------------------------------
   File "<ipython console>", line 1
     def get_area(self):
     ^
SyntaxError: invalid syntax

In [17]:         return self.l1 * self.l2

Is this to be expected? Somehow I thought that after function or class
definitionsit needs two lines to end the block?

Best, Arnd




From Fernando.Perez at colorado.edu  Fri Jan 20 16:47:18 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 14:47:18 -0700
Subject: [IPython-dev] SVN testers?
In-Reply-To: <Pine.LNX.4.51.0601202203380.3472@ptpcp8.phy.tu-dresden.de>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
	<Pine.LNX.4.51.0601202203380.3472@ptpcp8.phy.tu-dresden.de>
Message-ID: <43D15A66.9080404@colorado.edu>

Arnd Baecker wrote:
> I just updated from svn - Pasting the following:
> 
> class Rectangle:
>     def __init__(self, l1=1.0, l2=2.0):
>         self.l1 = l1
>         self.l2 = l2
> 
>     def get_area(self):
>         return self.l1 * self.l2
> 
>     area = property(get_area)

Mmh.  This stuff is maddening.  I've been thinking about just sitting down and 
_proving_ that it can't be done.  Meaning: that there are inescapably 
ambiguous situations which can't be decided without holding context, while 
keeping autoindent capabilities.  Without autoindent, you can do this, 
provided that you don't leave _empty_ lines:


class Rectangle:
     def __init__(self, l1=1.0, l2=2.0):
         self.l1 = l1
         self.l2 = l2

     def get_area(self):
         return self.l1 * self.l2

     area = property(get_area)

(this one has whitespace in the intermediate lines).  Then  it works:

In [19]: %autoindent
Automatic indentation is: OFF

In [20]: class Rectangle:
    ....:     def __init__(self, l1=1.0, l2=2.0):
    ....:         self.l1 = l1
    ....:         self.l2 = l2
    ....:
    ....:     def get_area(self):
    ....:         return self.l1 * self.l2
    ....:
    ....:     area = property(get_area)
    ....:

In [21]:


Oh well, I'll try it again tomorrow, we'll see where I get.

Cheers,

f



From jorgen.stenarson at bostream.nu  Fri Jan 20 16:54:17 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Fri, 20 Jan 2006 22:54:17 +0100
Subject: [IPython-dev] winreadline
In-Reply-To: <43D149AA.6090005@bostream.nu>
References: <43D149AA.6090005@bostream.nu>
Message-ID: <43D15C09.7060702@bostream.nu>

Hi again,

for some reason the svn diff on my windows machine is acting up and 
produced a patchfile which patches the same files twice. Which results 
in files twice as large as they should be. I switched to use the cygwin 
svn client and I think the new patch attached is ok.

/J?rgen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: winreadline_2.patch
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060120/1edca414/attachment.ksh>

From vivainio at gmail.com  Fri Jan 20 19:20:00 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 02:20:00 +0200
Subject: [IPython-dev] winreadline
In-Reply-To: <43D15C09.7060702@bostream.nu>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
Message-ID: <46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>

Regarding winreadline -

To be honest, I don't think making it a subpackage for ipython is the
best way to go through this. Your modifications to readline are of
general value, not limited just to ipython. It should be a stand-alone
package that just gets imported by ipython if available.

We should make the package easy_install:able for the whole world, but
also ship it in the same tarball as ipython. It should probably also
be maintained in the IPython SVN repo.

I don't expect the net work to be significantly larger, but the net
gain can potentially be. Thoughts?



From Fernando.Perez at colorado.edu  Fri Jan 20 20:13:44 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 18:13:44 -0700
Subject: [IPython-dev] winreadline
In-Reply-To: <46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
Message-ID: <43D18AC8.4010608@colorado.edu>

Ville Vainio wrote:
> Regarding winreadline -
> 
> To be honest, I don't think making it a subpackage for ipython is the
> best way to go through this. Your modifications to readline are of
> general value, not limited just to ipython. It should be a stand-alone
> package that just gets imported by ipython if available.
> 
> We should make the package easy_install:able for the whole world, but
> also ship it in the same tarball as ipython. It should probably also
> be maintained in the IPython SVN repo.
> 
> I don't expect the net work to be significantly larger, but the net
> gain can potentially be. Thoughts?

I don't really care much, but if you put it at the top-level, make sure that 
the setup.py file is correctly constructed so that readline is only added to 
the package list under win32.

We _certainly_ don't want to be overwriting the default readline under *nix/osx.

Being that this is mostly for the benefit of win32 users, I trust your 
judgement, since it affects you personally :)

Cheers,

f



From Fernando.Perez at colorado.edu  Fri Jan 20 20:16:37 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 20 Jan 2006 18:16:37 -0700
Subject: [IPython-dev] winreadline
In-Reply-To: <43D18AC8.4010608@colorado.edu>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
	<43D18AC8.4010608@colorado.edu>
Message-ID: <43D18B75.8040904@colorado.edu>

Fernando Perez wrote:
> Ville Vainio wrote:
> 
>>Regarding winreadline -
>>
>>To be honest, I don't think making it a subpackage for ipython is the
>>best way to go through this. Your modifications to readline are of
>>general value, not limited just to ipython. It should be a stand-alone
>>package that just gets imported by ipython if available.
>>
>>We should make the package easy_install:able for the whole world, but
>>also ship it in the same tarball as ipython. It should probably also
>>be maintained in the IPython SVN repo.
>>
>>I don't expect the net work to be significantly larger, but the net
>>gain can potentially be. Thoughts?
> 
> 
> I don't really care much, but if you put it at the top-level, make sure that 
> the setup.py file is correctly constructed so that readline is only added to 
> the package list under win32.

One more thing: let's hold this til I put out .7.1, so it doesn't get in the 
way.  I can't afford last-minute surprises right now.

f



From vivainio at gmail.com  Sat Jan 21 04:00:16 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 01:00:16 -0800
Subject: [IPython-dev] Nearing release, please be careful
In-Reply-To: <46cb515a0601210027t4e40c3d3p3da9e43e2e16676d@mail.gmail.com>
References: <43D1E779.4020908@colorado.edu>
	<46cb515a0601210027t4e40c3d3p3da9e43e2e16676d@mail.gmail.com>
Message-ID: <46cb515a0601210100l6ebcdd8elf61be4be9d36c509@mail.gmail.com>

On 1/21/06, Ville Vainio <vivainio at gmail.com> wrote:

> > ImportError: No module named ipy_user_conf
>
> It's not a bug, it was added to UserConfig - just copy the file from
> there. It will automatically be there for "new" installations.

I think the one thing we might do in the trunk is to, in the first
run, do a "light" upgrade such as:

- Copy * from UserConfig over to .ipython for files that don't already
exist (apart from ipythonrc*)

- Write out .ipython/currentversion.txt that has the version tag in
it, after that a straightforward comparison can deduce that the
subsequent comparisons are not "first runs".

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivian at vdesmedt.com  Sat Jan 21 04:13:35 2006
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sat, 21 Jan 2006 10:13:35 +0100
Subject: [IPython-dev] winreadline
In-Reply-To: <43D18B75.8040904@colorado.edu>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
	<43D18AC8.4010608@colorado.edu> <43D18B75.8040904@colorado.edu>
Message-ID: <43D1FB3F.9090200@vdesmedt.com>

Dear All,

I dare I take this thread in middle and I'm not sure I understand well 
what you are saying but I started to imagine that you imagine to ship 
with with IPython a version of a readline like package.

Is so I vote pro. As a Belgium keyboard user I have trouble with the 
Gary Bishop's readline.
With the original version Belgium user aren't able to type  ' [', '{', 
... which make the life of a programmer a bit difficult.

As I wrote some month ago to get rid of these problems.  I had to have 
my own version of the the Gary Bishop's readline.

I submitted to Gary but it never replied so I'll be glad to submit them 
to the IPython team.

That could ease a lot the installation of IPython for Belgium user which 
is a bit painful for the time being.

Tell me if I was right when thinking that you plan to ship IPython with 
its own improved version of readline.
If so tell me what you think making the Belgium keyboard compatible with 
that version of readline ;-)

Vivian De Smedt



From vivainio at gmail.com  Sat Jan 21 04:36:33 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 11:36:33 +0200
Subject: [IPython-dev] winreadline
In-Reply-To: <43D1FB3F.9090200@vdesmedt.com>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
	<43D18AC8.4010608@colorado.edu> <43D18B75.8040904@colorado.edu>
	<43D1FB3F.9090200@vdesmedt.com>
Message-ID: <46cb515a0601210136n561c655fwb7055b5d9778af36@mail.gmail.com>

On 1/21/06, Vivian De Smedt <vivian at vdesmedt.com> wrote:

> As I wrote some month ago to get rid of these problems.  I had to have
> my own version of the the Gary Bishop's readline.
>
> I submitted to Gary but it never replied so I'll be glad to submit them
> to the IPython team.

Ah, it was you, I remembered someone did this a while ago. You could
take a look at Jorgens patches and see whether you have something
extra that he didn't provide. Let's do it next week when 0.7.1 is out
and we agree on place to put it and how it gets there.

> Tell me if I was right when thinking that you plan to ship IPython with
> its own improved version of readline.

You were right.

> If so tell me what you think making the Belgium keyboard compatible with
> that version of readline ;-)

Not working with one's keyboard is quite a show-stopper, so clearing
this is going to be a major milestone.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From jorgen.stenarson at bostream.nu  Sat Jan 21 06:08:48 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sat, 21 Jan 2006 12:08:48 +0100
Subject: [IPython-dev] winreadline
In-Reply-To: <46cb515a0601210136n561c655fwb7055b5d9778af36@mail.gmail.com>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
	<43D18AC8.4010608@colorado.edu> <43D18B75.8040904@colorado.edu>
	<43D1FB3F.9090200@vdesmedt.com>
	<46cb515a0601210136n561c655fwb7055b5d9778af36@mail.gmail.com>
Message-ID: <43D21640.5090607@bostream.nu>



Ville Vainio skrev:
> On 1/21/06, Vivian De Smedt <vivian at vdesmedt.com> wrote:
> 
>> As I wrote some month ago to get rid of these problems.  I had to have
>> my own version of the the Gary Bishop's readline.
>>
>> I submitted to Gary but it never replied so I'll be glad to submit them
>> to the IPython team.
> 
> Ah, it was you, I remembered someone did this a while ago. You could
> take a look at Jorgens patches and see whether you have something
> extra that he didn't provide. Let's do it next week when 0.7.1 is out
> and we agree on place to put it and how it gets there.
> 
Is it possible to get a separate branch/place in the svn tree now so we 
can get going. The sharing/comparing between Vivian and me would become 
easier. Then we could integrate to trunk after 0.7.1.


>> Tell me if I was right when thinking that you plan to ship IPython with
>> its own improved version of readline.
> 
> You were right.
> 
I agree, I'm curious to see how Vivian's solution.

>> If so tell me what you think making the Belgium keyboard compatible with
>> that version of readline ;-)
> 
> Not working with one's keyboard is quite a show-stopper, so clearing
> this is going to be a major milestone.
> 
I agree.

If we don't integrate winreadline into ipython directly but keeps it as 
a separate project then perhaps we should use another package name than 
readline just to avoid clobbering other peoples readline. The drawback 
being other packages looking for readline won't find it. Or we could 
just avoid automatic install.

/J?rgen




From vivainio at gmail.com  Sat Jan 21 06:36:44 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 03:36:44 -0800
Subject: [IPython-dev] winreadline
In-Reply-To: <43D21608.1000407@bostream.nu>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
	<43D18AC8.4010608@colorado.edu> <43D18B75.8040904@colorado.edu>
	<43D1FB3F.9090200@vdesmedt.com>
	<46cb515a0601210136n561c655fwb7055b5d9778af36@mail.gmail.com>
	<43D21608.1000407@bostream.nu>
Message-ID: <46cb515a0601210336s5c5c8a79tcc4edf3663715fa0@mail.gmail.com>

On 1/21/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> Is it possible to get a separate branch/place in the svn tree now so we
> can get going. The sharing/comparing between Vivian and me would become
> easier. Then we could integrate to trunk after 0.7.1.

Yes, I can create it. I assume this is ok for Fernando as well?

I thought the right place would be next to ipython,nbdoc etc. here:

http://projects.scipy.org/ipython/ipython/browser

> If we don't integrate winreadline into ipython directly but keeps it as
> a separate project then perhaps we should use another package name than
> readline just to avoid clobbering other peoples readline. The drawback

What's it going to be? winreadline, wreadline? I assume it's always
going to be Windows-specific.

> being other packages looking for readline won't find it. Or we could
> just avoid automatic install.

We can ship readline.py that does

from winreadline import *

And suggest the users should put it somewhere in their search path if
they want to
use the library with non-ipython projects.

I'll create the svn tree the moment Fernando okays it, and we can get
the ball rolling!

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sat Jan 21 07:16:04 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 04:16:04 -0800
Subject: [IPython-dev] winreadline
In-Reply-To: <46cb515a0601210336s5c5c8a79tcc4edf3663715fa0@mail.gmail.com>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
	<43D18AC8.4010608@colorado.edu> <43D18B75.8040904@colorado.edu>
	<43D1FB3F.9090200@vdesmedt.com>
	<46cb515a0601210136n561c655fwb7055b5d9778af36@mail.gmail.com>
	<43D21608.1000407@bostream.nu>
	<46cb515a0601210336s5c5c8a79tcc4edf3663715fa0@mail.gmail.com>
Message-ID: <46cb515a0601210416v444e8c9ao5b12aacd42bacf51@mail.gmail.com>

I've created a ticket for this.

http://projects.scipy.org/ipython/ipython/ticket/42

Patches should be attached to this ticket so they don't get lost (the
mailing list eats attachments).

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Sat Jan 21 08:26:44 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 21 Jan 2006 06:26:44 -0700
Subject: [IPython-dev] winreadline
In-Reply-To: <46cb515a0601210336s5c5c8a79tcc4edf3663715fa0@mail.gmail.com>
References: <43D149AA.6090005@bostream.nu> <43D15C09.7060702@bostream.nu>
	<46cb515a0601201620l75ea01bdm3a5137eaf8822d2d@mail.gmail.com>
	<43D18AC8.4010608@colorado.edu> <43D18B75.8040904@colorado.edu>
	<43D1FB3F.9090200@vdesmedt.com>
	<46cb515a0601210136n561c655fwb7055b5d9778af36@mail.gmail.com>
	<43D21608.1000407@bostream.nu>
	<46cb515a0601210336s5c5c8a79tcc4edf3663715fa0@mail.gmail.com>
Message-ID: <43D23694.2030009@colorado.edu>

Ville Vainio wrote:
> On 1/21/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
> 
>>Is it possible to get a separate branch/place in the svn tree now so we
>>can get going. The sharing/comparing between Vivian and me would become
>>easier. Then we could integrate to trunk after 0.7.1.
> 
> 
> Yes, I can create it. I assume this is ok for Fernando as well?
> 
> I thought the right place would be next to ipython,nbdoc etc. here:
> 
> http://projects.scipy.org/ipython/ipython/browser

Sure, go ahead with a branch.  This one should be fairly short-lived, I 
imagine, as it will quickly merge back.  I'll drop Gary a line regarding this.

>>If we don't integrate winreadline into ipython directly but keeps it as
>>a separate project then perhaps we should use another package name than
>>readline just to avoid clobbering other peoples readline. The drawback
> 
> 
> What's it going to be? winreadline, wreadline? I assume it's always
> going to be Windows-specific.
>>being other packages looking for readline won't find it. Or we could
>>just avoid automatic install.

Well, Gary's was called plain readline, as a top-level.  Since Python does not 
have a readline package by default under windows, and the only other one out 
there is broken:

http://ipython.scipy.org/doc/manual/node2.html#SECTION00023000000000000000

I guess it would be OK to just call it 'readline' as Gary did.  On the other 
hand, changing names to 'winreadline', having IPython use 'import winreadline 
as readline' internally, and

> We can ship readline.py that does
> 
> from winreadline import *
> 
> And suggest the users should put it somewhere in their search path if
> they want to
> use the library with non-ipython projects.

would shield us from problems if people ever install the broken one on top. 
Other things might break for them, but ipython would continue OK.

So for long-term sanity protection for us, my vote is

1. name -> winreadline

2. readline.py -> from winreadline import *.  This will go alongside 
winreadline wherever the installer puts it, so people calling 'readline' will 
get it, but we have the winreadline name available to protect us from rogue 
overwriting of the readline.py name.

3. This is active ONLY if the os is win32 in setup.py.  No touching the python 
readline under any other OS.  It's OK to _ship_ it in the tarballs if that 
makes life easier, as it's such a small thing.  For example, python itself 
does this:

abdul[python2.3]> d *path*py
/usr/lib/python2.3
-rw-r--r--  1 root  7352 Feb  2  2005 macpath.py
-rw-r--r--  1 root  3099 Feb  2  2005 macurl2path.py
-rw-r--r--  1 root 15737 Feb  2  2005 ntpath.py
-rw-r--r--  1 root  2032 Feb  2  2005 nturl2path.py
-rw-r--r--  1 root 12679 Feb  2  2005 os2emxpath.py
-rw-r--r--  1 root 12698 Feb  2  2005 posixpath.py


> I'll create the svn tree the moment Fernando okays it, and we can get
> the ball rolling!

Go for it.  I'll be working all day on trying to get the last pieces of .7.1 out.

Cheers,

f



From Fernando.Perez at colorado.edu  Sat Jan 21 08:40:27 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 21 Jan 2006 06:40:27 -0700
Subject: [IPython-dev] UNC readline and ipython
Message-ID: <43D239CB.3020700@colorado.edu>

Hi Gary,

I hope all is well on your side.  I just wanted to contact you regarding the 
UNC readline library.  In the past, you've mentioned how you don't have much 
time to work on it these days, and that you'd be OK with others continuing 
maintenance of it.  In these threads (and some others before this)

http://scipy.net/pipermail/ipython-dev/2006-January/000817.html
http://scipy.net/pipermail/ipython-dev/2006-January/000828.html

we've been discussing doing this, and starting to distribute your readline as 
part of ipython.  Several ipython users are willing to contribute patches, and 
the new maintainer of the stable branch (Ville Vainio) is a win32 user who can 
test and incorporate these contributions, so I expect this to improve the 
library, in particular regarding support for non-US keyboards.

We'll begin merging this code and testing integration soon.  I was wondering 
if you'd like us to drop you a note when a new version of ipython which has 
this into it begins shipping, as you may perhaps want to put a note mentioning 
this on your site.  This would point new users to the actively-developed 
version of the library.

Please let us know (this is cc-d to ipython-dev) if you have any 
comments/ideas/suggestions/objections regarding this.  Needless to say, all 
original authorship notices will be maintained.

One last, important, question: before we can officially ship this, we need to 
be sure that the license conditions are OK.  IPython is BSD-licensed.  Is it 
OK with you that we distribute your code in this manner?  If so, we would add 
a license tag to the files, to make sure this is explicitly indicated.

Thanks for having written this in the first place.  Without it, ipython would 
never have been a really useful tool under a win32 environment.

Regards,

f



From gb at cs.unc.edu  Sat Jan 21 08:52:07 2006
From: gb at cs.unc.edu (Gary Bishop)
Date: Sat, 21 Jan 2006 08:52:07 -0500
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D239CB.3020700@colorado.edu>
References: <43D239CB.3020700@colorado.edu>
Message-ID: <f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>

I am glad that folks find it useful. I know I do.

I can take my version down anytime. I put it there as a service. I guess
there are pointers all over the web, so I should, as you say, add a note
that it has been superceded.

Something you guys should consider, IMO, is replacing readline for all other
OS! Python would benefit greatly from having its own readline written in
Python. To first order all that would be required is a Linux version of
Console.py. The rest of the code is mostly os independent.

Whatever license is fine with me as long as it doesn't restrict folks from
using and modifying it.

gb

On 1/21/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
>
> Hi Gary,
>
> I hope all is well on your side.  I just wanted to contact you regarding
> the
> UNC readline library.  In the past, you've mentioned how you don't have
> much
> time to work on it these days, and that you'd be OK with others continuing
> maintenance of it.  In these threads (and some others before this)
>
> http://scipy.net/pipermail/ipython-dev/2006-January/000817.html
> http://scipy.net/pipermail/ipython-dev/2006-January/000828.html
>
> we've been discussing doing this, and starting to distribute your readline
> as
> part of ipython.  Several ipython users are willing to contribute patches,
> and
> the new maintainer of the stable branch (Ville Vainio) is a win32 user who
> can
> test and incorporate these contributions, so I expect this to improve the
> library, in particular regarding support for non-US keyboards.
>
> We'll begin merging this code and testing integration soon.  I was
> wondering
> if you'd like us to drop you a note when a new version of ipython which
> has
> this into it begins shipping, as you may perhaps want to put a note
> mentioning
> this on your site.  This would point new users to the actively-developed
> version of the library.
>
> Please let us know (this is cc-d to ipython-dev) if you have any
> comments/ideas/suggestions/objections regarding this.  Needless to say,
> all
> original authorship notices will be maintained.
>
> One last, important, question: before we can officially ship this, we need
> to
> be sure that the license conditions are OK.  IPython is BSD-licensed.  Is
> it
> OK with you that we distribute your code in this manner?  If so, we would
> add
> a license tag to the files, to make sure this is explicitly indicated.
>
> Thanks for having written this in the first place.  Without it, ipython
> would
> never have been a really useful tool under a win32 environment.
>
> Regards,
>
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060121/02030d0e/attachment.html>

From Fernando.Perez at colorado.edu  Sat Jan 21 09:02:25 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 21 Jan 2006 07:02:25 -0700
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
Message-ID: <43D23EF1.2080107@colorado.edu>

Gary Bishop wrote:
> I am glad that folks find it useful. I know I do.
> 
> I can take my version down anytime. I put it there as a service. I guess
> there are pointers all over the web, so I should, as you say, add a note
> that it has been superceded.

Great, many thanks!  We'll drop you a line when this is released, so you can 
add such a note.

> Something you guys should consider, IMO, is replacing readline for all other
> OS! Python would benefit greatly from having its own readline written in
> Python. To first order all that would be required is a Linux version of
> Console.py. The rest of the code is mostly os independent.

Good point.  In fact, just this week on python-dev there's been talk of 
_removing_ readline from python altogether in the future, due to licensing 
concerns.  readline is GPL, and it's unclear whether the FSF could come after 
Python for GPL violations.  Thread here:

http://mail.python.org/pipermail/python-dev/2006-January/059868.html

This could future-proof us as well.  All the more reason to move forward with 
this plan, then!  Over time, we may experiment with enabling this under linux.

Note to ipython-dev: in light of this, should we reconsider using winreadline 
as the package name?  Perhaps 'uncreadline' or 'gbreadline'?  Thoughts?


> Whatever license is fine with me as long as it doesn't restrict folks from
> using and modifying it.

Thanks.  BSD is about as liberal a license as they come, so we're OK here 
then.  And it fits with the rest of ipython in this regard.


Best,

f



From gb at cs.unc.edu  Sat Jan 21 09:10:47 2006
From: gb at cs.unc.edu (Gary Bishop)
Date: Sat, 21 Jan 2006 09:10:47 -0500
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D23EF1.2080107@colorado.edu>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
Message-ID: <f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>

I suggest PythonReadline or some such as the name. That is what really
distinguishes it. It is written in python. Check out Ben Last's comments
about it associated with his shell Quasi. He actually derived his own class
from it allowing him to extend its capabilities, something that is
impossible with the gnu readline.

I claim (he said knowing he wouldn't have to back it up) that I could have a
Linux version of Console going in less than 1 week of work and I don't know
curses and I'm an old guy. Some Linux hacking kid on the list should be able
to do it in a few hours!

Also, do you know about Mike Graz <mnsgraz at mnsgraz.plus.com> adding vi
editing mode to it? One giant merge would be the right thing to do.

gb

On 1/21/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
>
> Gary Bishop wrote:
> > I am glad that folks find it useful. I know I do.
> >
> > I can take my version down anytime. I put it there as a service. I guess
> > there are pointers all over the web, so I should, as you say, add a note
> > that it has been superceded.
>
> Great, many thanks!  We'll drop you a line when this is released, so you
> can
> add such a note.
>
> > Something you guys should consider, IMO, is replacing readline for all
> other
> > OS! Python would benefit greatly from having its own readline written in
> > Python. To first order all that would be required is a Linux version of
> > Console.py. The rest of the code is mostly os independent.
>
> Good point.  In fact, just this week on python-dev there's been talk of
> _removing_ readline from python altogether in the future, due to licensing
> concerns.  readline is GPL, and it's unclear whether the FSF could come
> after
> Python for GPL violations.  Thread here:
>
> http://mail.python.org/pipermail/python-dev/2006-January/059868.html
>
> This could future-proof us as well.  All the more reason to move forward
> with
> this plan, then!  Over time, we may experiment with enabling this under
> linux.
>
> Note to ipython-dev: in light of this, should we reconsider using
> winreadline
> as the package name?  Perhaps 'uncreadline' or 'gbreadline'?  Thoughts?
>
>
> > Whatever license is fine with me as long as it doesn't restrict folks
> from
> > using and modifying it.
>
> Thanks.  BSD is about as liberal a license as they come, so we're OK here
> then.  And it fits with the rest of ipython in this regard.
>
>
> Best,
>
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060121/02ef1d42/attachment.html>

From Fernando.Perez at colorado.edu  Sat Jan 21 09:18:11 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 21 Jan 2006 07:18:11 -0700
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
	<f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
Message-ID: <43D242A3.5040703@colorado.edu>

Gary Bishop wrote:
> I suggest PythonReadline or some such as the name. That is what really
> distinguishes it. It is written in python. Check out Ben Last's comments
> about it associated with his shell Quasi. He actually derived his own class
> from it allowing him to extend its capabilities, something that is
> impossible with the gnu readline.

I'd then vote for

pyreadline

The Python naming PEP suggests all-lowercase, no-underscores names for 
packages and modules.  Since this could potentially be stdlib material in the 
future (_especially_ if they remove gnu-readline), might as well be compatible 
with their names.

> I claim (he said knowing he wouldn't have to back it up) that I could have a
> Linux version of Console going in less than 1 week of work and I don't know
> curses and I'm an old guy. Some Linux hacking kid on the list should be able
> to do it in a few hours!

I'm sure it's doable: not my priority right now, esp. given that we still have 
readline, but it will be excellent to have the foundation.  And given how we 
have some very enterprising users on the ipython lists, maybe someone will 
pick this ball up and run with it...

> Also, do you know about Mike Graz <mnsgraz at mnsgraz.plus.com> adding vi
> editing mode to it? One giant merge would be the right thing to do.

I didn't, we should probably drop him a line once the merge starts.  Ville, 
Vivian, Jorgen (our pyreadline team :): can one of you contact him and perhaps 
arrange for his patches to come through as well?

Cheers,

f



From vivainio at gmail.com  Sat Jan 21 09:29:04 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 06:29:04 -0800
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D242A3.5040703@colorado.edu>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
	<f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
	<43D242A3.5040703@colorado.edu>
Message-ID: <46cb515a0601210629y568d9256va93715fd67d7788c@mail.gmail.com>

On 1/21/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> Gary Bishop wrote:
> > I suggest PythonReadline or some such as the name. That is what really
> > distinguishes it. It is written in python. Check out Ben Last's comments
> > about it associated with his shell Quasi. He a  ctually derived his own class
> > from it allowing him to extend its capabilities, something that is
> > impossible with the gnu readline.
>
> I'd then vote for
>
> pyreadline
>
> The Python naming PEP suggests all-lowercase, no-underscores names for
> packages and modules.  Since this could potentially be stdlib material in the
> future (_especially_ if they remove gnu-readline), might as well be compatible
> with their names.
>
> > I claim (he said knowing he wouldn't have to back it up) that I could have a
> > Linux version of Console going in less than 1 week of work and I don't know
> > curses and I'm an old guy. Some Linux hacking kid on the list should be able
> > to do it in a few hours!
>
> I'm sure it's doable: not my priority right now, esp. given that we still have
> readline, but it will be excellent to have the foundation.  And given how we
> have some very enterprising users on the ipython lists, maybe someone will
> pick this ball up and run with it...
>
> > Also, do you know about Mike Graz <mnsgraz at mnsgraz.plus.com> adding vi
> > editing mode to it? One giant merge would be the right thing to do.
>
> I didn't, we should probably drop him a line once the merge starts.  Ville,
> Vivian, Jorgen (our pyreadline team :): can one of you contact him and perhaps
> arrange for his patches to come through as well?
>
> Cheers,
>
> f
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.net
> http://scipy.net/mailman/listinfo/ipython-dev
>


--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sat Jan 21 09:35:19 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 06:35:19 -0800
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D242A3.5040703@colorado.edu>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
	<f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
	<43D242A3.5040703@colorado.edu>
Message-ID: <46cb515a0601210635s447af04ftfa72b5c2a43617f1@mail.gmail.com>

On 1/21/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> I didn't, we should probably drop him a line once the merge starts.  Ville,
> Vivian, Jorgen (our pyreadline team :): can one of you contact him and perhaps
> arrange for his patches to come through as well?

Damn, I pressend "send" accidentally.

My suggestion is, since there seems to be a handful of work with
pyreadline after all, you could give SVN access to one extra person -
Jorgen asked for them so he seems like a good bet. If Jorgen is
willing to take up the task, of course.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Sat Jan 21 10:05:45 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 21 Jan 2006 08:05:45 -0700
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <46cb515a0601210635s447af04ftfa72b5c2a43617f1@mail.gmail.com>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
	<f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
	<43D242A3.5040703@colorado.edu>
	<46cb515a0601210635s447af04ftfa72b5c2a43617f1@mail.gmail.com>
Message-ID: <43D24DC9.5030006@colorado.edu>

Ville Vainio wrote:
> On 1/21/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>I didn't, we should probably drop him a line once the merge starts.  Ville,
>>Vivian, Jorgen (our pyreadline team :): can one of you contact him and perhaps
>>arrange for his patches to come through as well?
> 
> 
> Damn, I pressend "send" accidentally.
> 
> My suggestion is, since there seems to be a handful of work with
> pyreadline after all, you could give SVN access to one extra person -
> Jorgen asked for them so he seems like a good bet. If Jorgen is
> willing to take up the task, of course.

Jorgen, interested?  I'd be happy to give you SVN access if you will really 
work on this, though I'd ask you that in the beginning, you limit commits to 
the readline area.  The ipython codebase is messy and brittle, so it's quite 
easy to break things you don't know well.  If you want to make non-trivial 
commits elsewhere, it's a good idea to first run the patch by the list (even 
if you end up being the one applying it, we can thus review it on-list 
beforehand).

Also, as we get more people actually working on ipython itself, code style 
consistency becomes more important.  Whether you are committing directly or 
sending patches, please take a moment to read, and actually FOLLOW:

http://projects.scipy.org/ipython/ipython/wiki/DeveloperGuidelines

Clear, consistenly styled code is important, as it makes the mental flow over 
a large codebase function much more smoothly.  Feel free to comment on these 
if you feel that any of it is either over the top, or missing something important.

f



From jorgen.stenarson at bostream.nu  Sat Jan 21 10:23:07 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sat, 21 Jan 2006 16:23:07 +0100
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D24DC9.5030006@colorado.edu>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
	<f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
	<43D242A3.5040703@colorado.edu>
	<46cb515a0601210635s447af04ftfa72b5c2a43617f1@mail.gmail.com>
	<43D24DC9.5030006@colorado.edu>
Message-ID: <43D251DB.1010903@bostream.nu>

Fernando Perez skrev:
> Ville Vainio wrote:
>> On 1/21/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
>>
>>
>>> I didn't, we should probably drop him a line once the merge starts.  Ville,
>>> Vivian, Jorgen (our pyreadline team :): can one of you contact him and perhaps
>>> arrange for his patches to come through as well?
>>
>> Damn, I pressend "send" accidentally.
>>
>> My suggestion is, since there seems to be a handful of work with
>> pyreadline after all, you could give SVN access to one extra person -
>> Jorgen asked for them so he seems like a good bet. If Jorgen is
>> willing to take up the task, of course.
> 
> Jorgen, interested?  I'd be happy to give you SVN access if you will really 
> work on this, though I'd ask you that in the beginning, you limit commits to 
> the readline area.  
I'm interested. I'll limit myself to the readline area, at the moment 
that is my main interest anyway.


>The ipython codebase is messy and brittle, so it's quite 
> easy to break things you don't know well.  If you want to make non-trivial 
> commits elsewhere, it's a good idea to first run the patch by the list (even 
> if you end up being the one applying it, we can thus review it on-list 
> beforehand).
> 
> Also, as we get more people actually working on ipython itself, code style 
> consistency becomes more important.  Whether you are committing directly or 
> sending patches, please take a moment to read, and actually FOLLOW:
> 
> http://projects.scipy.org/ipython/ipython/wiki/DeveloperGuidelines
> 
> Clear, consistenly styled code is important, as it makes the mental flow over 
> a large codebase function much more smoothly.  Feel free to comment on these 
> if you feel that any of it is either over the top, or missing something important.

As one of the first steps I will make the pythonreadline conform to the 
4 space indent policy.

/J?rgen



From Fernando.Perez at colorado.edu  Sat Jan 21 11:18:47 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 21 Jan 2006 09:18:47 -0700
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D25DD5.80904@bostream.nu>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
	<f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
	<43D242A3.5040703@colorado.edu>
	<46cb515a0601210635s447af04ftfa72b5c2a43617f1@mail.gmail.com>
	<43D24DC9.5030006@colorado.edu> <43D251DB.1010903@bostream.nu>
	<43D25299.7000102@colorado.edu> <43D256D5.7040700@bostream.nu>
	<43D257B9.4020904@colorado.edu> <43D25DD5.80904@bostream.nu>
Message-ID: <43D25EE7.2000505@colorado.edu>

J?rgen Stenarson wrote:
> Fernando Perez skrev:
> 
>>J?rgen Stenarson wrote:
>>
>>
>>>username: jstenar
>>
>>Done.  First, let's check that you can actually make some trivial commit 
>>(edit the readme for windows file for example, with a trivial change).
>>
> 
> Looks like the commit worked.

OK, great.  back on-list.

 >>>Where should we put the readline tree?

I think Gary's arguments point to it being a top-level package, called 
'pyreadline' for now.  We'll use Ville's suggestion of a trivial readline.py 
which does 'from pyreadline import *' under win32.

The setup.py file will need to be adjusted so this does NEVER get added for 
any OS other than win32, for now.  If in the future we add *nix support here, 
great, but for now let's make sure we don't mess with the default readline.

Welcome!

f



From vivainio at gmail.com  Sat Jan 21 11:40:35 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sat, 21 Jan 2006 08:40:35 -0800
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D25EE7.2000505@colorado.edu>
References: <43D239CB.3020700@colorado.edu> <43D242A3.5040703@colorado.edu>
	<46cb515a0601210635s447af04ftfa72b5c2a43617f1@mail.gmail.com>
	<43D24DC9.5030006@colorado.edu> <43D251DB.1010903@bostream.nu>
	<43D25299.7000102@colorado.edu> <43D256D5.7040700@bostream.nu>
	<43D257B9.4020904@colorado.edu> <43D25DD5.80904@bostream.nu>
	<43D25EE7.2000505@colorado.edu>
Message-ID: <46cb515a0601210840w6265890endeff8a974e4370c2@mail.gmail.com>

On 1/21/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

>  >>>Where should we put the readline tree?

http://ipython.scipy.org/svn/ipython/

seems like a good place.

Open it in your browser to ensure that you put it next to the other projects.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From jorgen.stenarson at bostream.nu  Sat Jan 21 11:45:15 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sat, 21 Jan 2006 17:45:15 +0100
Subject: [IPython-dev] UNC readline and ipython
In-Reply-To: <43D25EE7.2000505@colorado.edu>
References: <43D239CB.3020700@colorado.edu>
	<f7a4ba220601210552v597128f3x34bdc84f7a54408f@mail.gmail.com>
	<43D23EF1.2080107@colorado.edu>
	<f7a4ba220601210610t371b22ep581dc8aed8802649@mail.gmail.com>
	<43D242A3.5040703@colorado.edu>
	<46cb515a0601210635s447af04ftfa72b5c2a43617f1@mail.gmail.com>
	<43D24DC9.5030006@colorado.edu> <43D251DB.1010903@bostream.nu>
	<43D25299.7000102@colorado.edu> <43D256D5.7040700@bostream.nu>
	<43D257B9.4020904@colorado.edu> <43D25DD5.80904@bostream.nu>
	<43D25EE7.2000505@colorado.edu>
Message-ID: <43D2651B.2070002@bostream.nu>

Fernando Perez skrev:
> J?rgen Stenarson wrote:
>> Fernando Perez skrev:
>>
>>> J?rgen Stenarson wrote:
>>>
>>>
>>>> username: jstenar
>>>
>>> Done.  First, let's check that you can actually make some trivial 
>>> commit (edit the readme for windows file for example, with a trivial 
>>> change).
>>>
>>
>> Looks like the commit worked.
> 
> OK, great.  back on-list.
> 
>  >>>Where should we put the readline tree?
> 
> I think Gary's arguments point to it being a top-level package, called 
> 'pyreadline' for now.  We'll use Ville's suggestion of a trivial 
> readline.py which does 'from pyreadline import *' under win32.
> 
So putting it at http://ipython.scipy.org/svn/ipython/pyreadline is the 
way to go for now?


> The setup.py file will need to be adjusted so this does NEVER get added 
> for any OS other than win32, for now.  If in the future we add *nix 
> support here, great, but for now let's make sure we don't mess with the 
> default readline.
> 
> Welcome!
> 
Thanks,
J?rgen



From jorgen.stenarson at bostream.nu  Sat Jan 21 12:59:12 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sat, 21 Jan 2006 18:59:12 +0100
Subject: [IPython-dev] New pyreadline added
Message-ID: <43D27670.8060600@bostream.nu>

Hi

I have added Garys Bishops readline as is from version 1.12. The 
repository location is: 
http://ipython.scipy.org/svn/ipython/pyreadline/trunk

next step is to change the code to conform to the 4 space indent convention.

/J?rgen



From Fernando.Perez at colorado.edu  Sat Jan 21 17:16:52 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 21 Jan 2006 15:16:52 -0700
Subject: [IPython-dev] New pyreadline added
In-Reply-To: <43D27670.8060600@bostream.nu>
References: <43D27670.8060600@bostream.nu>
Message-ID: <43D2B2D4.8040708@colorado.edu>

J?rgen Stenarson wrote:
> Hi
> 
> I have added Garys Bishops readline as is from version 1.12. The 
> repository location is: 
> http://ipython.scipy.org/svn/ipython/pyreadline/trunk
> 
> next step is to change the code to conform to the 4 space indent convention.

Excellent.  I guess from here you guys can move forward with this.  Keep me 
posted, but I doubt I'll contribute anything specific on this front.

Thanks for pitching in, and welcome to ipython-SVN!

Cheers,

f



From Fernando.Perez at colorado.edu  Sun Jan 22 04:01:41 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 02:01:41 -0700
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <43C4C7F4.3000002@colorado.edu>
References: <43C374E6.8030602@colorado.edu>
	<200601101343.11173.hans_meine@gmx.net> <43C4C7F4.3000002@colorado.edu>
Message-ID: <43D349F5.9070809@colorado.edu>

Fernando Perez wrote:
> Hans Meine wrote:
> 
>>Hi!
>>
> 
> 
>>Is it possible that there is a conflict between this and the %macro feature?
>>Testcase follows.. oh no, it's the fault of -qthread, without that it works:
> 
> 
> [...]
> 
> 
>>Here, IPython hangs.  First, I wondered about the [6], but that seems to be 
>>normal, due to the multi-line macro?  But I cannot revive the prompt; I have 
>>to kill IPython.
>>
>>For your convenience, here's code to paste:
>>
>>foo = []
>>for i in range(42):
>>	foo.append(i)
>>
>>%macro bar 1:3
>>bar
> 
> 
> I see the problem, with ALL threaded backends (-g/w/qthread).  I'll look into 
> this once I find a bit of time (most likely this weekend).

OK, I _think_ I got this.  If you can test the 0.7.1.rc1 and let me know how 
it goes, I'd be grateful.  Announcement coming shortly...

f



From Fernando.Perez at colorado.edu  Sun Jan 22 04:04:18 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 02:04:18 -0700
Subject: [IPython-dev] Bug in revision 1029+
In-Reply-To: <46cb515a0601181322p6818d52eq28c131b76cb052bc@mail.gmail.com>
References: <43CEACF5.6080603@bostream.nu>
	<46cb515a0601181322p6818d52eq28c131b76cb052bc@mail.gmail.com>
Message-ID: <43D34A92.2040303@colorado.edu>

Ville Vainio wrote:
> On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
> 
>>Hi
>>
>>%run seems to have changed how it handles stack frames from revision
>>1029. The attached python file a.py and b.py works when executed from
> 
> 
> http://projects.scipy.org/ipython/ipython/changeset/1029
> 
> Apparently assigning the __file__ variable screws up "inspect" operations.
> 
> It all seems rather magical, perhaps there are also other evil side
> effects on assigning __file__? I'm thinking that perhaps we should
> leave __file__ unassigned after all.

Just a note: __file__ is a valid attribute that is supposed to exist in 
modules, so I don't think we should leave it unassigned.  We may be doing 
something incorrect with it (or it may be an inspect bug, there's a LOT of 
those), but we certainly should assing it.  I've put this in 0.7.1, please 
don't remove it unless you can ascertain that you have a full solution which 
covers normal use like:

In [1]: cat bug__file__.py
print '__file__ is:',__file__

In [2]: run bug__file__.py
__file__ is: bug__file__.py

and which helps with Jorgen's situation as well.

Cheers,

f



From Fernando.Perez at colorado.edu  Sun Jan 22 04:17:37 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 02:17:37 -0700
Subject: [IPython-dev] Bug in ??
In-Reply-To: <46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
References: <43CEB254.3070402@bostream.nu>
	<46cb515a0601181331oaece13l9c88486cc563370@mail.gmail.com>
Message-ID: <43D34DB1.5000408@colorado.edu>

Ville Vainio wrote:
> On 1/18/06, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
> 
>>thought I'd mention another bug I have meant to report for a while. When
>>doing ?? on a compiled module you get the binary dumped as if it was the
>>source of the module.
> 
> 
> Thanks for the report, I'll fix it tomorrow.

Fixed in 0.7.1, I'll commit and put an rc out in a moment.

f



From Fernando.Perez at colorado.edu  Sun Jan 22 04:18:53 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 02:18:53 -0700
Subject: [IPython-dev] SVN testers?
In-Reply-To: <43D15A66.9080404@colorado.edu>
References: <43D0AB4A.40608@colorado.edu>
	<46cb515a0601200624q63d91cb7t14384e7c57c1ce28@mail.gmail.com>
	<Pine.LNX.4.51.0601202203380.3472@ptpcp8.phy.tu-dresden.de>
	<43D15A66.9080404@colorado.edu>
Message-ID: <43D34DFD.1010803@colorado.edu>

Fernando Perez wrote:
> Arnd Baecker wrote:
> 
>>I just updated from svn - Pasting the following:
>>
>>class Rectangle:
>>    def __init__(self, l1=1.0, l2=2.0):
>>        self.l1 = l1
>>        self.l2 = l2
>>
>>    def get_area(self):
>>        return self.l1 * self.l2
>>
>>    area = property(get_area)
> 
> 
> Mmh.  This stuff is maddening.  I've been thinking about just sitting down and 
> _proving_ that it can't be done.  Meaning: that there are inescapably 
> ambiguous situations which can't be decided without holding context, while 
> keeping autoindent capabilities.  Without autoindent, you can do this, 
> provided that you don't leave _empty_ lines:

OK, one more try.  I'll put out an 0.7.1.rc1 shortly, and all the 
indentation/pasting cases I've tried seem to work OK.  It would be great if 
you could pound on it a little.

Cheers,

f



From Fernando.Perez at colorado.edu  Sun Jan 22 04:43:48 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 02:43:48 -0700
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
Message-ID: <43D353D4.4020102@colorado.edu>

Hi all,

I think I've been able to fix all the bugs which were reported after 0.7.0. 
I've put up a release candidate at the usual location:

http://ipython.scipy.org/dist/testing/

I'd greatly appreciate any feedback on remaining problems.  Note that this is 
NOT trunk/ of SVN anymore, Ville is working on that and this comes off a 
branch.  Those of you using SVN for daily work can test this branch by using

svn switch http://ipython.scipy.org/svn/ipython/ipython/branches/0.7.1

inside your working copy.  You can then revert to trunk with

svn switch http://ipython.scipy.org/svn/ipython/ipython/trunk


(I think, I'm not an SVN expert, so I hope I didn't misunderstand the 
instructions).

I am very pressed for time, so unfortunately I won't be able to leave the rc 
in testing for long (I intended to release today, but didn't manage).  I'll 
probably release mid-week.  On the other hand, the changes are mostly 
localized to fixing the reported bugs, so perhaps we'll get lucky and no major 
problems will arise.  I can dream...

Best,

f



From vivainio at gmail.com  Sun Jan 22 06:18:47 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 03:18:47 -0800
Subject: [IPython-dev] Editing manifest.in
Message-ID: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>

I'd like to make ipython.py in the ipython root dir a standard part of
the source distribution (setup.py sdist). Can I just add it to
Manifest.in, or is there something else to do? It's handy in Windows,
but it's also helpful on non-root Unix installs.

(I already added a note about it in README_Windows.txt)

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sun Jan 22 06:58:19 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 03:58:19 -0800
Subject: [IPython-dev] egg doesn't install scripts on windows
Message-ID: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>

Egg fails to install scripts properly on windows. In windows they
should have the .py suffix or they won't work.

Solution: rename scripts/ipython -> scripts/ipython.py
same for pycolor

And change setup.py to install all files in scripts as, well, scripts.

It should work in posix too, doesn't distutils strip the .py suffix
for scripts there?

running win32_manual_postinstall should be redundant if
python24\scripts is in system path...

Patch attached.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: install_scripts_properly.diff
Type: application/octet-stream
Size: 2137 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060122/2f19ff81/attachment.obj>

From vivainio at gmail.com  Sun Jan 22 07:00:17 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 04:00:17 -0800
Subject: [IPython-dev] egg doesn't install scripts on windows
In-Reply-To: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>
References: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>
Message-ID: <46cb515a0601220400m40c77daco365de0868d41dd61@mail.gmail.com>

On 1/22/06, Ville Vainio <vivainio at gmail.com> wrote:

> Patch attached.

Ok, that patch sucked, apparently they don't do renames well.

Just do the renames manually and use the patch for seeing how setup.py
needs to be changed (it's all pretty trivial, really)

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From hans_meine at gmx.net  Sun Jan 22 08:46:48 2006
From: hans_meine at gmx.net (Hans Meine)
Date: Sun, 22 Jan 2006 14:46:48 +0100
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <43D349F5.9070809@colorado.edu>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>
Message-ID: <200601221446.56186.hans_meine@gmx.net>

On Sunday 22 January 2006 10:01, you wrote:
> > I see the problem, with ALL threaded backends (-g/w/qthread).  I'll look
> > into this once I find a bit of time (most likely this weekend).
>
> OK, I _think_ I got this.  If you can test the 0.7.1.rc1 and let me know
> how it goes, I'd be grateful.  Announcement coming shortly...
Fernando, please ignore my last mail (which should have gone to the list 
anyways).

I now switched to http://ipython.scipy.org/svn/ipython/ipython/branches/0.7.1 
after reading your announcement and it works.  (A little confusing maybe, 
that the trunk does not contain the fix, but displays "0.7.1" as version.)

I am happy with the branch, and hope that Ville will apply your changes to the 
trunk soon.

Greetings,
  Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060122/ec3f5388/attachment.sig>

From vivainio at gmail.com  Sun Jan 22 09:31:53 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 16:31:53 +0200
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <200601221446.56186.hans_meine@gmx.net>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>
	<200601221446.56186.hans_meine@gmx.net>
Message-ID: <46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>

On 1/22/06, Hans Meine <hans_meine at gmx.net> wrote:

> I am happy with the branch, and hope that Ville will apply your changes to the
> trunk soon.

Done. However, I'd advise everyone to keep running branches/0.7.1
until the release is out.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sun Jan 22 10:09:51 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 17:09:51 +0200
Subject: [IPython-dev] egg doesn't install scripts on windows
In-Reply-To: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>
References: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>
Message-ID: <46cb515a0601220709g39ba2c3ar135dfaafcbe7fd93@mail.gmail.com>

On 1/22/06, Ville Vainio <vivainio at gmail.com> wrote:

> It should work in posix too, doesn't distutils strip the .py suffix
> for scripts there?

And the answer seems to be "no". Bummer.

This needs more exploration, but it's going to happen in trunk/

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sun Jan 22 11:04:34 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 18:04:34 +0200
Subject: [IPython-dev] Editing manifest.in
In-Reply-To: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
References: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
Message-ID: <46cb515a0601220804w50b847b6qb5680d9418312087@mail.gmail.com>

Continuing on the "replying to myself" tradition:

On 1/22/06, Ville Vainio <vivainio at gmail.com> wrote:

> I'd like to make ipython.py in the ipython root dir a standard part of
> the source distribution (setup.py sdist). Can I just add it to
> Manifest.in, or is there something else to do? It's handy in Windows,
> but it's also helpful on non-root Unix installs.

Well, I've already added this to trunk (rev. 1060) and I don't think
there will be any problems elsewhere.

Regarding installation of scripts w/ or w/o extensions - I'm going to
leave "scripts" as is, and turn my attention towards setuptools to do
this right.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sun Jan 22 11:37:10 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 18:37:10 +0200
Subject: [IPython-dev] egg doesn't install scripts on windows
In-Reply-To: <46cb515a0601220709g39ba2c3ar135dfaafcbe7fd93@mail.gmail.com>
References: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>
	<46cb515a0601220709g39ba2c3ar135dfaafcbe7fd93@mail.gmail.com>
Message-ID: <46cb515a0601220837y327f667drf26cef51bd9ccede@mail.gmail.com>

On 1/22/06, Ville Vainio <vivainio at gmail.com> wrote:

> > It should work in posix too, doesn't distutils strip the .py suffix
> > for scripts there?
>
> And the answer seems to be "no". Bummer.
>
> This needs more exploration, but it's going to happen in trunk/

Ok, now I've added eggsetup.py to trunk that creates an egg that
install the scripts properly. Here's the diff to normal setup.py for
the curious:


ville at badger[~/ipython]|35> diff setup.py eggsetup.py
39c39,40
< from distutils.core import setup
---
> #from distutils.core import setup
> from setuptools import setup
141c142
<       scripts          = scriptfiles,
---
>       #scripts          = scriptfiles,
149c150,157
<                           ('lib', 'IPython/UserConfig', cfgfiles)]
---
>                           ('lib', 'IPython/UserConfig', cfgfiles)],
>         # egg options
>         entry_points = {
>             'console_scripts': [
>                 'ipython = IPython.ipapi:launch_new_instance',
>                 'pycolor = IPython.PyColorize:main'
>             ],
>         }


--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Sun Jan 22 14:38:54 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 12:38:54 -0700
Subject: [IPython-dev] Editing manifest.in
In-Reply-To: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
References: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
Message-ID: <43D3DF4E.6010707@colorado.edu>

Ville Vainio wrote:
> I'd like to make ipython.py in the ipython root dir a standard part of
> the source distribution (setup.py sdist). Can I just add it to
> Manifest.in, or is there something else to do? It's handy in Windows,
> but it's also helpful on non-root Unix installs.

No: the trick this relies on, which is that it says

import IPython

and since the 'IPython/' directory is directly below, it imports it right 
away, will cease to work very soon:

http://www.python.org/peps/pep-0328.html

On Unix, or even on windows with NTFS, there is no need for this at all, you 
just use a symlink.  I'm constantly switching between the development version 
of ipython and old releases, trunks and branches, and there's no need for this 
root-level ipython.py at all.  In fact, I wanted to explain this to you 
earlier, because I don't like polluting things like this with duplicated scripts.

All you need to do is to drop a symlink to the version you are currently 
running in a directory which is in your PYTHONPATH.  This is what mine looks like:

abdul[~/ipython]> d
/home/fperez/ipython
total 108
drwxr-xr-x   9 fperez 4096 Jun  2  2005 0.6.15/
lrwxrwxrwx   1 fperez   47 Jan 21 18:17 0.7.1 -> 
/home/fperez/ipython/svn/ipython/branches/0.7.1/
drwxr-xr-x   5 fperez 4096 Jul 16  2005 attic/
drwxr-xr-x   3 fperez 4096 Jan 10 01:10 backup/
lrwxrwxrwx   1 fperez   29 Oct 23 22:16 chainsaw -> svn/ipython/branches/chainsaw/
drwxr-xr-x   2 fperez 4096 Jan 21 17:18 contrib/
drwxr-xr-x   4 fperez 4096 Dec 21 10:33 epydocs/
drwxr-xr-x   8 fperez 4096 Dec 29 11:56 homepage/
lrwxrwxrwx   1 fperez    5 Jan 21 18:17 ipython -> 0.7.1/
drwxr-xr-x   4 fperez 4096 Oct  7 17:30 misc/
-rw-r--r--   1 fperez 2396 Aug 15 15:43 notes_svn
drwxr-xr-x   6 fperez 4096 Jan 10 13:23 projects.svn/
-rw-r--r--   1 fperez  380 Jul 17  2005 py_questions
-rw-r--r--   1 fperez  775 Sep  5 15:09 rkern
drwxr-xr-x   2 fperez 4096 Jan 12 23:41 sf.net/
drwxr-xr-x   7 fperez 4096 Aug 24 17:07 svn/
drwxr-xr-x  15 fperez 4096 Jan 22 01:43 test/
lrwxrwxrwx   1 fperez   17 Oct 23 22:16 trunk -> svn/ipython/trunk/


As you see, there I have an 'ipython' link, which is currently pointed at teh 
0.7.1 dir, so ipython/IPython resolves out to 0.7.1.  But I have sitting there 
0.6.15, trunk and chainsaw, and I can switch between all 4 in a second just by 
repointing a symlink.

This solution will work on any system with symlinks, which only excludes 
FAT32.  Since the one you propose causes duplication of scripts, and will stop 
working anyway for 2.5, I think this is cleaner.

Cheers,

f



From Fernando.Perez at colorado.edu  Sun Jan 22 14:50:52 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 12:50:52 -0700
Subject: [IPython-dev] egg doesn't install scripts on windows
In-Reply-To: <46cb515a0601220709g39ba2c3ar135dfaafcbe7fd93@mail.gmail.com>
References: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>
	<46cb515a0601220709g39ba2c3ar135dfaafcbe7fd93@mail.gmail.com>
Message-ID: <43D3E21C.2020002@colorado.edu>

Ville Vainio wrote:
> On 1/22/06, Ville Vainio <vivainio at gmail.com> wrote:
> 
> 
>>It should work in posix too, doesn't distutils strip the .py suffix
>>for scripts there?
> 
> 
> And the answer seems to be "no". Bummer.
> 
> This needs more exploration, but it's going to happen in trunk/

Well, we're NOT going to have scripts under *nix with .py extensions.  Nobody 
in a *nix box is going to have to type

ipython.py

at a command line to start ipython.  I'm happy supporting eggs, as long as 
they follow the proper conventions of each platform.  If they don't, this 
should be reported as an egg bug, but we're not going to break a standard of 
the *nix platform.

Cheers,

f



From vivainio at gmail.com  Sun Jan 22 14:53:20 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 21:53:20 +0200
Subject: [IPython-dev] Editing manifest.in
In-Reply-To: <43D3DF4E.6010707@colorado.edu>
References: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
	<43D3DF4E.6010707@colorado.edu>
Message-ID: <46cb515a0601221153q1dbe1920lbe1c6e7def0dca3f@mail.gmail.com>

On 1/22/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> No: the trick this relies on, which is that it says
>
> import IPython
>
> and since the 'IPython/' directory is directly below, it imports it right
> away, will cease to work very soon:
>
> http://www.python.org/peps/pep-0328.html

I don't think it will - the pep suggests that intra-package *module*
imports will break. This script relies on the IPython *package* being
under the current dir, and that will definitely continue working.
Current-dir-in-pythonpath is not going away soon.

> On Unix, or even on windows with NTFS, there is no need for this at all, you
> just use a symlink.  I'm constantly switching between the development version

It's not quite so simple with NT. Only hard links are supported
(IIRC), and absolutely nobody uses them.

> All you need to do is to drop a symlink to the version you are currently
> running in a directory which is in your PYTHONPATH.  This is what mine looks like:

It's still preferable for people who want to use it on Windows to not
have to do anything, just tar xzvf & go, if necessary.

> This solution will work on any system with symlinks, which only excludes
> FAT32.  Since the one you propose causes duplication of scripts, and will stop
> working anyway for 2.5, I think this is cleaner.

Incidentally, I only have fat32 partitions on my home Windows machine
(I dual boot, NTFS sucks with Linux). But that's not really the issue,
it's just the big improvement in convenience. I like to run "local"
ipython sessions that are separate from official installed ipython,
and having it working straight out of SVN and source distribution is
very handy.

It's also quite user friendly, for Windows users the intuitive
reaction after opening the tarball is double-clicking ipython.py.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sun Jan 22 14:54:42 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 21:54:42 +0200
Subject: [IPython-dev] egg doesn't install scripts on windows
In-Reply-To: <43D3E21C.2020002@colorado.edu>
References: <46cb515a0601220358x181fb0a7h179b5d7e21127fa0@mail.gmail.com>
	<46cb515a0601220709g39ba2c3ar135dfaafcbe7fd93@mail.gmail.com>
	<43D3E21C.2020002@colorado.edu>
Message-ID: <46cb515a0601221154v3f570dbci48f0acde7b750b7e@mail.gmail.com>

On 1/22/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Well, we're NOT going to have scripts under *nix with .py extensions.  Nobody

Yes, we aren't, read the next message. :-)

setuptools does most of the things right that distutils botches miserably.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Sun Jan 22 15:02:00 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 13:02:00 -0700
Subject: [IPython-dev] Editing manifest.in
In-Reply-To: <46cb515a0601221153q1dbe1920lbe1c6e7def0dca3f@mail.gmail.com>
References: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
	<43D3DF4E.6010707@colorado.edu>
	<46cb515a0601221153q1dbe1920lbe1c6e7def0dca3f@mail.gmail.com>
Message-ID: <43D3E4B8.7040208@colorado.edu>

Ville Vainio wrote:

>>On Unix, or even on windows with NTFS, there is no need for this at all, you
>>just use a symlink.  I'm constantly switching between the development version
> 
> 
> It's not quite so simple with NT. Only hard links are supported
> (IIRC), and absolutely nobody uses them.

Ah, I didn't know that detail.  Somehow I thought that NTFS was a real 
filesystem ;)

Well, in that case go ahead.  I hate duplication and find it ugly, but I can 
see the convenience value.  It will be your job to keep the two in sync anyway :)

Note that this may break in the future, because the package structure for 
chainsaw will probably grow to something much more complex, so that running 
off the unpacked directory _may_ be impossible (as it is with many large 
python packages).  But we'll cross that bridge when we get to it...

Cheers,

f



From Fernando.Perez at colorado.edu  Sun Jan 22 15:04:33 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 13:04:33 -0700
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>	<200601221446.56186.hans_meine@gmx.net>
	<46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>
Message-ID: <43D3E551.5040208@colorado.edu>

Ville Vainio wrote:
> On 1/22/06, Hans Meine <hans_meine at gmx.net> wrote:
> 
> 
>>I am happy with the branch, and hope that Ville will apply your changes to the
>>trunk soon.
> 
> 
> Done. However, I'd advise everyone to keep running branches/0.7.1
> until the release is out.

Ville, can you quickly summarize for me which changes in trunk you think I 
should apply to the release branch?  Is it only the setup.py stuff?

f



From vivainio at gmail.com  Sun Jan 22 15:17:01 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 22:17:01 +0200
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <43D3E551.5040208@colorado.edu>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>
	<200601221446.56186.hans_meine@gmx.net>
	<46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>
	<43D3E551.5040208@colorado.edu>
Message-ID: <46cb515a0601221217m467f7406jeaebdc67e06a64c0@mail.gmail.com>

On 1/22/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Ville, can you quickly summarize for me which changes in trunk you think I
> should apply to the release branch?  Is it only the setup.py stuff?

I think you should try applying 1062 and 1064 to create proper eggs,
if you can find the time. Those patches have no chance of breaking
anything already in place.

Note that I stripped lots of stuff from eggsetup.py. I thought it
would be a good idea to make the egg minimal, with no examples and
documentation. Nobody looks for the docs under site-packages/wherever
anyway, and it would make it more feasible to make ipython a
"dependency" when people easy_install stuff like turbogears etc (which
is often done to places with limited disk quotas).

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Sun Jan 22 15:24:54 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 22:24:54 +0200
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <46cb515a0601221217m467f7406jeaebdc67e06a64c0@mail.gmail.com>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>
	<200601221446.56186.hans_meine@gmx.net>
	<46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>
	<43D3E551.5040208@colorado.edu>
	<46cb515a0601221217m467f7406jeaebdc67e06a64c0@mail.gmail.com>
Message-ID: <46cb515a0601221224l118d73d6wfd84a54e1b218270@mail.gmail.com>

On 1/22/06, Ville Vainio <vivainio at gmail.com> wrote:

> "dependency" when people easy_install stuff like turbogears etc (which
> is often done to places with limited disk quotas).

Incidentally, eggs can be easy_install:ed just great in setups without
root access (I remember you worrying about this).

I used this method:

http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-python

"Creating a virtual python" sounds scary, but it only consists of
downloading and running a single python script. No chroot or other
unpleasantness is involved.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Sun Jan 22 15:40:13 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 13:40:13 -0700
Subject: [IPython-dev] Editing manifest.in
In-Reply-To: <46cb515a0601221153q1dbe1920lbe1c6e7def0dca3f@mail.gmail.com>
References: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
	<43D3DF4E.6010707@colorado.edu>
	<46cb515a0601221153q1dbe1920lbe1c6e7def0dca3f@mail.gmail.com>
Message-ID: <43D3EDAD.9050307@colorado.edu>

Ville Vainio wrote:
> On 1/22/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>No: the trick this relies on, which is that it says
>>
>>import IPython
>>
>>and since the 'IPython/' directory is directly below, it imports it right
>>away, will cease to work very soon:
>>
>>http://www.python.org/peps/pep-0328.html
> 
> 
> I don't think it will - the pep suggests that intra-package *module*
> imports will break. This script relies on the IPython *package* being
> under the current dir, and that will definitely continue working.
> Current-dir-in-pythonpath is not going away soon.

As I said before, in the absence of true symlinks on NTFS, go ahead with this.

But just out of understanding curiosity, the way I read the section titled 
"Guido's decision" on that pep, I do think that unqualified imports like  we 
use today will break _both_ for packages and modules.  At least that's how I 
understand this:

<quote>
... following are correct usages of the new syntax:

from .moduleY import spam
from .moduleY import spam as ham
from . import moduleY
from ..subpackage1 import moduleY
from ..subpackage2.moduleZ import eggs
from ..moduleA import foo
from ...package import bar
from ...sys import path

Note that while that last case is legal, it is certainly discouraged ("insane" 
was the word Guido used).

Relative imports must always use from <> import; import <> is always absolute.

</quote>

The examples they show all use the '.' import, which is why I'm thinking what 
I'm thinking.  But maybe I'm just confused...   That pep could be worded a 
little clearer, I think...

f



From vivainio at gmail.com  Sun Jan 22 15:52:36 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 22 Jan 2006 22:52:36 +0200
Subject: [IPython-dev] Editing manifest.in
In-Reply-To: <43D3EDAD.9050307@colorado.edu>
References: <46cb515a0601220318m62ce201bte6690a4d103b72cd@mail.gmail.com>
	<43D3DF4E.6010707@colorado.edu>
	<46cb515a0601221153q1dbe1920lbe1c6e7def0dca3f@mail.gmail.com>
	<43D3EDAD.9050307@colorado.edu>
Message-ID: <46cb515a0601221252h64b30f3cle81c7aab85d043b@mail.gmail.com>

On 1/22/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> The examples they show all use the '.' import, which is why I'm thinking what
> I'm thinking.  But maybe I'm just confused...   That pep could be worded a
> little clearer, I think...

You may have confused "absolute import" with import from "installed"
library as opposed to importing a package under current working
folder, while in fact every folder under sys.path is just as
"absolute" - and CWD is one of those directories.

Of course the peps are mostly optimized for covering the discussion
that has taken place on python-dev instead of pedagogic factors. :-)

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From prabhu_r at users.sf.net  Mon Jan 23 00:31:56 2006
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 23 Jan 2006 11:01:56 +0530
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
In-Reply-To: <43D353D4.4020102@colorado.edu>
References: <43D353D4.4020102@colorado.edu>
Message-ID: <17364.27212.158279.678614@prpc.aero.iitb.ac.in>

>>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    Fernando> Hi all, I think I've been able to fix all the bugs which
    Fernando> were reported after 0.7.0. I've put up a release
    Fernando> candidate at the usual location:

    Fernando> http://ipython.scipy.org/dist/testing/

It looks like the 0.7.1 branch has Python 2.4 dependencies in the form
of decorators.

byte-compiling /usr/local/stow/ipython/lib/python2.3/site-packages/IPython/Extensions/ext_rehashdir.py to ext_rehashdir.pyc
  File "/usr/local/stow/ipython/lib/python2.3/site-packages/IPython/Extensions/ext_rehashdir.py", line 32
    @ip.asmagic("rehashdir")
    ^
SyntaxError: invalid syntax

Otherwise, things seem to look OK.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Mon Jan 23 00:39:26 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 22:39:26 -0700
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
In-Reply-To: <17364.27212.158279.678614@prpc.aero.iitb.ac.in>
References: <43D353D4.4020102@colorado.edu>
	<17364.27212.158279.678614@prpc.aero.iitb.ac.in>
Message-ID: <43D46C0E.8020304@colorado.edu>

Prabhu Ramachandran wrote:

> It looks like the 0.7.1 branch has Python 2.4 dependencies in the form
> of decorators.
> 
> byte-compiling /usr/local/stow/ipython/lib/python2.3/site-packages/IPython/Extensions/ext_rehashdir.py to ext_rehashdir.pyc
>   File "/usr/local/stow/ipython/lib/python2.3/site-packages/IPython/Extensions/ext_rehashdir.py", line 32
>     @ip.asmagic("rehashdir")
>     ^
> SyntaxError: invalid syntax
> 
> Otherwise, things seem to look OK.

Ville?  We're certainly keeping 2.3 compatibility in trunk.    I didn't write 
that code, and right now I won't be able to look at it.  I plan on cutting the 
release tomorrow, so if you have a chance to fix these by then, great. 
Otherwise I'll just delete all that code from this branch, and you can fix it 
later in trunk/ to not require 2.4.

Decorators are just syntactic sugar, so for now the functionality can be 
obtained in a 2.3-compatible manner.

To be clear: ipython trunk will remain, for the foreseeable future, 2.3 
compatible.  The chainsaw branch does require 2.4.

Thanks for catching this one, Prabhu.

Cheers,

f



From vivainio at gmail.com  Mon Jan 23 00:50:13 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 23 Jan 2006 07:50:13 +0200
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
In-Reply-To: <43D46C0E.8020304@colorado.edu>
References: <43D353D4.4020102@colorado.edu>
	<17364.27212.158279.678614@prpc.aero.iitb.ac.in>
	<43D46C0E.8020304@colorado.edu>
Message-ID: <46cb515a0601222150o734a36cq24ab5459b9d12348@mail.gmail.com>

On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> > It looks like the 0.7.1 branch has Python 2.4 dependencies in the form
> > of decorators.
> >
> > byte-compiling

Ah, I forgot that it did byte-compile and whines about the decorators
at that point. I'll change it to non-decorated style asap.

My idea was that it wouldn't even be imported in old python's (it's an
"extension") but you can't really supress the bytecompile time
warning.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Mon Jan 23 00:52:13 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 22 Jan 2006 22:52:13 -0700
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
In-Reply-To: <46cb515a0601222150o734a36cq24ab5459b9d12348@mail.gmail.com>
References: <43D353D4.4020102@colorado.edu>
	<17364.27212.158279.678614@prpc.aero.iitb.ac.in>
	<43D46C0E.8020304@colorado.edu>
	<46cb515a0601222150o734a36cq24ab5459b9d12348@mail.gmail.com>
Message-ID: <43D46F0D.7030104@colorado.edu>

Ville Vainio wrote:
> On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>>It looks like the 0.7.1 branch has Python 2.4 dependencies in the form
>>>of decorators.
>>>
>>>byte-compiling
> 
> 
> Ah, I forgot that it did byte-compile and whines about the decorators
> at that point. I'll change it to non-decorated style asap.

great, thanks.

> 
> My idea was that it wouldn't even be imported in old python's (it's an
> "extension") but you can't really supress the bytecompile time
> warning.

Yeah, and even if it's an extension, we want users of ipython to be able to 
access all of its features.  I don't want to tell them 'this subset of ipython 
requires 2.4'.

Thanks for looking into this,

f



From arnd.baecker at web.de  Mon Jan 23 04:07:52 2006
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 23 Jan 2006 10:07:52 +0100 (CET)
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
In-Reply-To: <17364.27212.158279.678614@prpc.aero.iitb.ac.in>
References: <43D353D4.4020102@colorado.edu>
	<17364.27212.158279.678614@prpc.aero.iitb.ac.in>
Message-ID: <Pine.LNX.4.51.0601231001500.23728@ptpcp8.phy.tu-dresden.de>

Hi,

On Mon, 23 Jan 2006, Prabhu Ramachandran wrote:

> >>>>> "Fernando" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
>
>     Fernando> Hi all, I think I've been able to fix all the bugs which
>     Fernando> were reported after 0.7.0. I've put up a release
>     Fernando> candidate at the usual location:
>
>     Fernando> http://ipython.scipy.org/dist/testing/

Hmm, is this the one where pasting multiple lines of code,
including single empty lines, should work?

For example, pasting the following does not work for me:

##################################
def f(x):
    print x

    print x+1
##################################

In [2]: def f(x):
   ...:     print x
   ...:

In [3]:     print x+1
------------------------------------------------------------
   File "<ipython console>", line 1
     print x+1
     ^
SyntaxError: invalid syntax


(I moved the .ipython directory out of the way
before installation; I also tried the svn switch variant)
Do I have to activate any settings before the above will work?

Best,

Arnd



From vivainio at gmail.com  Mon Jan 23 05:39:17 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 23 Jan 2006 12:39:17 +0200
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
In-Reply-To: <Pine.LNX.4.51.0601231001500.23728@ptpcp8.phy.tu-dresden.de>
References: <43D353D4.4020102@colorado.edu>
	<17364.27212.158279.678614@prpc.aero.iitb.ac.in>
	<Pine.LNX.4.51.0601231001500.23728@ptpcp8.phy.tu-dresden.de>
Message-ID: <46cb515a0601230239i2366cb9fp54737afcf579e36f@mail.gmail.com>

On 1/23/06, Arnd Baecker <arnd.baecker at web.de> wrote:

> Hmm, is this the one where pasting multiple lines of code,
> including single empty lines, should work?
>
> For example, pasting the following does not work for me:
>
> ##################################
> def f(x):
>     print x
>
>     print x+1
> ##################################
>
> In [2]: def f(x):
>    ...:     print x
>    ...:
>
> In [3]:     print x+1

I admit to not have worked on this feature (it's on fernando's turf)
but it seems so complicated that I'm starting to think we should add a
magic %paste that would read a bunch of text and just terminate on
some special sentinel, e.g. "-- "

Here's a hypothetical example:

ipython> %paste
Ready to paste code! Terminate the section with "--"
if 1:
  print "hello world"


 print "blah"

--
.. Ready, evaluating:
hello world
blah

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Mon Jan 23 06:05:00 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 23 Jan 2006 13:05:00 +0200
Subject: [IPython-dev] Extensions & version dependency
Message-ID: <46cb515a0601230305l72422961n352e546a48a00990@mail.gmail.com>

On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Yeah, and even if it's an extension, we want users of ipython to be able to
> access all of its features.  I don't want to tell them 'this subset of ipython
> requires 2.4'.

I think we can refrain from making extensions dependent on syntax of
new python versions, but I'm not so sure about libraries (esp. if a
version of the library can be installed on older python versions).

I'm thinking of writing an extension for some level of job control
(processes, not threads) using the "subprocess" module one of these
days.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Mon Jan 23 12:43:00 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 10:43:00 -0700
Subject: [IPython-dev] IPython 0.7.1.rc1 is ready
In-Reply-To: <46cb515a0601230239i2366cb9fp54737afcf579e36f@mail.gmail.com>
References: <43D353D4.4020102@colorado.edu>
	<17364.27212.158279.678614@prpc.aero.iitb.ac.in>
	<Pine.LNX.4.51.0601231001500.23728@ptpcp8.phy.tu-dresden.de>
	<46cb515a0601230239i2366cb9fp54737afcf579e36f@mail.gmail.com>
Message-ID: <43D515A4.6070708@colorado.edu>

Ville Vainio wrote:
> On 1/23/06, Arnd Baecker <arnd.baecker at web.de> wrote:
> 
> 
>>Hmm, is this the one where pasting multiple lines of code,
>>including single empty lines, should work?
>>
>>For example, pasting the following does not work for me:
>>
>>##################################
>>def f(x):
>>    print x
>>
>>    print x+1
>>##################################
>>
>>In [2]: def f(x):
>>   ...:     print x
>>   ...:
>>
>>In [3]:     print x+1

Well, this feature is a balancing act of tricky heuristics.  It turns out that 
what you want CAN be made to work.  Try pasting this:

def f(x):
     print x

     print 'hi'

Here it is on my system:

In [8]: def f(x):
    ...:     print x
    ...:
    ...:     print 'hi'
    ...:

In [9]: f(1)
1
hi

The following, however, doesn't work:

def f(x):
     print x

     print 'hi'


In [10]: def f(x):
    ....:     print x
    ....:

In [11]:     print 'hi'
------------------------------------------------------------
    File "<ipython console>", line 1
      print 'hi'
      ^
SyntaxError: invalid syntax


In [12]:

The difference between those two seemingly identical chunks of code is that 
the first (that works) has the blank line with consistent indentation compared 
to the rest (the blank line has 4 spaces).  The second code has a purely empty 
blank line.  Note that the second case doesn't even work with plain python:

 >>> def f(x):
...     print x
...
 >>>     print 'hi'
   File "<stdin>", line 1
     print 'hi'
     ^
SyntaxError: invalid syntax

while the first does:

 >>> def f(x):
...     print x
...
...     print 'hi'
...
...
 >>>

So at least I've been able to:

1. Reach parity in behavior regarding lines with whitespace with plain python.

2. Make all of this work even when autoindent is active.

But it is true that the limitation of having the blank lines be consistently 
indented with their surroundings remains.  Given all the magic going on here, 
I think this is impossible to remove, or at least it would be trickier than 
I'm interested in trying to do.  I've already sunk MANY hours of work into 
this little beast alone.

> I admit to not have worked on this feature (it's on fernando's turf)
> but it seems so complicated that I'm starting to think we should add a
> magic %paste that would read a bunch of text and just terminate on
> some special sentinel, e.g. "-- "
> 
> Here's a hypothetical example:
> 
> ipython> %paste

This is not a bad idea at all.  You could even provide the sentinel if you 
wanted to change it, with a default like '--':

%paste

would stop on '--'

but

%paste ...

would use '...' to mark the end.

So that somebody could paste a hypothetical chunk with a string containing a 
single '--' in a line.

But this is 0.7.2 material: given that at least the autoindent/paste combo is 
working as well as it can be made to work right now, I'm going to leave it at 
that.

In my defense, even very mature tools like emacs *running in a terminal* and 
jed also screw up the pasting of indented code by reindenting it.  It boils 
down to the fact that from a terminal, there is no way to distinguish between 
a paste event and input typed by the user manually.  (X)emacs running under 
X11 do the right thing, but because they can process the paste event and 
basically do what Ville suggests automatically.  We could do the same thing if 
we were running in a GUI environment, where we'd get a true paste event.  But 
in a line-oriented terminal we don't have this information, so we're forced to 
try and guess what's going on from analyzing the structure of the input on the 
fly.

I'm still quite happy that it works in most cases, and if you keep your 
whitespace consistenly indented (which emacs does by default when you edit 
code), you can even make it work 'always'.  So I'm calling this feature done.

Cheers,

f



From Fernando.Perez at colorado.edu  Mon Jan 23 13:25:25 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 11:25:25 -0700
Subject: [IPython-dev] Extensions & version dependency
In-Reply-To: <46cb515a0601230305l72422961n352e546a48a00990@mail.gmail.com>
References: <46cb515a0601230305l72422961n352e546a48a00990@mail.gmail.com>
Message-ID: <43D51F95.7020506@colorado.edu>

Ville Vainio wrote:
> On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>Yeah, and even if it's an extension, we want users of ipython to be able to
>>access all of its features.  I don't want to tell them 'this subset of ipython
>>requires 2.4'.
> 
> 
> I think we can refrain from making extensions dependent on syntax of
> new python versions, but I'm not so sure about libraries (esp. if a
> version of the library can be installed on older python versions).
> 
> I'm thinking of writing an extension for some level of job control
> (processes, not threads) using the "subprocess" module one of these
> days.

Well, then we should ship the backported version as a private copy, and do 
something like:

try:
   import foo_new_module  # from 2.4
except ImportError:
   from IPython import foo_new_backport as foo_new_module

It's extra work for us, but that's the life of a developer who wants to be 
nice to his users :)  I did similar things in ipython to support 2.3 features 
in 2.2 for quite a while (I guess we could clean all that up now).

2.3 is still the default on way too many in-production OSes out there to drop 
even partial support for it.  If we want features that rely on 2.4, either we 
include the backport ourselves, or they will be user-only installation things 
(which we can put up for separate download on the website).  But the official 
ipython trunk should remain 2.3-safe for now (Mac OSX Panther ships with 2.3, 
for example, as do many of the 'enterprise' Linuxes, which tend to be managed 
with tight no-out-of-tree-updates policies).

Cheers,

f



From vivainio at gmail.com  Mon Jan 23 15:37:29 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 23 Jan 2006 12:37:29 -0800
Subject: [IPython-dev] %paste
Message-ID: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>

On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

(regarding %paste for pasting code even when autoindent is on)

> This is not a bad idea at all.  You could even provide the sentinel if you
> wanted to change it, with a default like '--':

I'm not sure how useful it would be, because -- at the start of line
isn't a very useful python statement in the first place.

I've added %paste to trunk/. It garbles the output when pasting code
on Windows, I suppose it's a bug with pyreadline. We should probably
take a look at it one of these days.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Mon Jan 23 15:41:04 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 13:41:04 -0700
Subject: [IPython-dev] %paste
In-Reply-To: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
Message-ID: <43D53F60.7090001@colorado.edu>

Ville Vainio wrote:
> On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> (regarding %paste for pasting code even when autoindent is on)
> 
> 
>>This is not a bad idea at all.  You could even provide the sentinel if you
>>wanted to change it, with a default like '--':
> 
> 
> I'm not sure how useful it would be, because -- at the start of line
> isn't a very useful python statement in the first place.

What if it's in the middle of a triple-quoted string?

print """
hi, this is something

--

and now, here's more..."""
print 2+3

The current paste would truncate this in the middle, since it's not tokenizing 
the input to know that you are inside a string.

That's why a configurable sentinel is a good idea.

Cheers,

f



From vivainio at gmail.com  Mon Jan 23 15:55:38 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 23 Jan 2006 12:55:38 -0800
Subject: [IPython-dev] %paste
In-Reply-To: <43D53F60.7090001@colorado.edu>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
Message-ID: <46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>

On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> > I'm not sure how useful it would be, because -- at the start of line
> > isn't a very useful python statement in the first place.
>
> What if it's in the middle of a triple-quoted string?

It would rarely be in column one (the typical thing people paste are
function/class definitions), and even if it was, my advice in that
case would be to
paste it in two parts. I already use the argument for something else.

I'd go for "worse is better" and simplicity here. The user would
probably be two lazy to provide a custom sentinel in the first place,
esp. if he had to do it like '%paste -s @@@".

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Mon Jan 23 16:01:17 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 14:01:17 -0700
Subject: [IPython-dev] %paste
In-Reply-To: <46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
	<46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
Message-ID: <43D5441D.6020208@colorado.edu>

Ville Vainio wrote:
> On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>>I'm not sure how useful it would be, because -- at the start of line
>>>isn't a very useful python statement in the first place.
>>
>>What if it's in the middle of a triple-quoted string?
> 
> 
> It would rarely be in column one (the typical thing people paste are
> function/class definitions), and even if it was, my advice in that
> case would be to
> paste it in two parts. I already use the argument for something else.

You can't "paste in two parts" if the string is in the middle of code, as a 
print statement.

> I'd go for "worse is better" and simplicity here. The user would
> probably be two lazy to provide a custom sentinel in the first place,
> esp. if he had to do it like '%paste -s @@@".

It's worth giving users the option to do it correctly, if they want to.  And 
this doesn't change any of the default behavior (using an option such as -s).

After 0.7.1 is out and things calm down a little (a few weeks, at least), I'll 
find a free minute to fix this in trunk/ to work correctly.

Cheers,

f



From vivainio at gmail.com  Mon Jan 23 16:32:04 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 23 Jan 2006 13:32:04 -0800
Subject: [IPython-dev] %paste
In-Reply-To: <43D5441D.6020208@colorado.edu>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
	<46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
	<43D5441D.6020208@colorado.edu>
Message-ID: <46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>

On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> You can't "paste in two parts" if the string is in the middle of code, as a
> print statement.

Actually, you can:

1. Paste all lines before --
2. Paste all lines after --
3. Enter -- to terminate the block.

Not that it matters, I already committed a configurable version to SVN
(-s option). :-)

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Mon Jan 23 16:48:08 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 23 Jan 2006 13:48:08 -0800
Subject: [IPython-dev] %paste
In-Reply-To: <46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
	<46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
	<43D5441D.6020208@colorado.edu>
	<46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>
Message-ID: <46cb515a0601231348w36a17e81i963caf86b4b99c7d@mail.gmail.com>

Ok, apparently paste is a bad name, because the system command "paste"
shadows it and you have to use %paste. Suggestions welcome, or I'll
just use something goofy from the top of my head tomorrow.



From Fernando.Perez at colorado.edu  Mon Jan 23 17:03:51 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 15:03:51 -0700
Subject: [IPython-dev] %paste
In-Reply-To: <46cb515a0601231348w36a17e81i963caf86b4b99c7d@mail.gmail.com>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
	<46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
	<43D5441D.6020208@colorado.edu>
	<46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>
	<46cb515a0601231348w36a17e81i963caf86b4b99c7d@mail.gmail.com>
Message-ID: <43D552C7.40008@colorado.edu>

Ville Vainio wrote:
> Ok, apparently paste is a bad name, because the system command "paste"
> shadows it and you have to use %paste. Suggestions welcome, or I'll
> just use something goofy from the top of my head tomorrow.

cpaste?  Short for 'code paste'

f



From robert.kern at gmail.com  Mon Jan 23 17:14:24 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 23 Jan 2006 16:14:24 -0600
Subject: [IPython-dev] %paste
In-Reply-To: <43D552C7.40008@colorado.edu>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
	<46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
	<43D5441D.6020208@colorado.edu>
	<46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>
	<46cb515a0601231348w36a17e81i963caf86b4b99c7d@mail.gmail.com>
	<43D552C7.40008@colorado.edu>
Message-ID: <dr3kg0$sdk$1@sea.gmane.org>

Fernando Perez wrote:
> Ville Vainio wrote:
> 
>>Ok, apparently paste is a bad name, because the system command "paste"
>>shadows it and you have to use %paste. Suggestions welcome, or I'll
>>just use something goofy from the top of my head tomorrow.
> 
> cpaste?  Short for 'code paste'

%code_paste?

Or (more usually),

%cod<tab>

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



From Fernando.Perez at colorado.edu  Mon Jan 23 21:12:14 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 19:12:14 -0700
Subject: [IPython-dev] %paste
In-Reply-To: <46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
	<46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
	<43D5441D.6020208@colorado.edu>
	<46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>
Message-ID: <43D58CFE.8020500@colorado.edu>

Ville Vainio wrote:
> On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>You can't "paste in two parts" if the string is in the middle of code, as a
>>print statement.
> 
> 
> Actually, you can:
> 
> 1. Paste all lines before --
> 2. Paste all lines after --
> 3. Enter -- to terminate the block.

Yes, but then you lose the --, which was part of what you were trying to paste 
in the first place.  If the presence of that '--' in the string is all that 
stands between humanity and your program triggering planetary nuclear 
destruction, imagine the consequences!

> Not that it matters, I already committed a configurable version to SVN
> (-s option). :-)

Good.  The planet has been saved.  We can all sleep now.

f



From Fernando.Perez at colorado.edu  Tue Jan 24 00:19:18 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 22:19:18 -0700
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <46cb515a0601221217m467f7406jeaebdc67e06a64c0@mail.gmail.com>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>	
	<200601221446.56186.hans_meine@gmx.net>
	<46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>
	<43D3E551.5040208@colorado.edu>
	<46cb515a0601221217m467f7406jeaebdc67e06a64c0@mail.gmail.com>
Message-ID: <43D5B8D6.8000404@colorado.edu>

Ville Vainio wrote:
> On 1/22/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>Ville, can you quickly summarize for me which changes in trunk you think I
>>should apply to the release branch?  Is it only the setup.py stuff?
> 
> 
> I think you should try applying 1062 and 1064 to create proper eggs,
> if you can find the time. Those patches have no chance of breaking
> anything already in place.
> 
> Note that I stripped lots of stuff from eggsetup.py. I thought it
> would be a good idea to make the egg minimal, with no examples and
> documentation. Nobody looks for the docs under site-packages/wherever
> anyway, and it would make it more feasible to make ipython a
> "dependency" when people easy_install stuff like turbogears etc (which
> is often done to places with limited disk quotas).

OK, I'll apply these unmodified.  If egg users disagree with your choices, you 
can later revisit these, or perhaps make a 'lite' and 'full' pair, if such a 
thing is possible.

The win32 installer puts the manual with a link in the start menu, and the 
*nix ones do put the docs and manpages in the proper places (/usr/share/doc). 
  Did you remove them altogether?  What happens if someone installs the egg 
and they want to read the manual?  Do they need to go online?

Cheers,

f



From robert.kern at gmail.com  Tue Jan 24 00:47:17 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 23 Jan 2006 23:47:17 -0600
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <43D5B8D6.8000404@colorado.edu>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>		<200601221446.56186.hans_meine@gmx.net>
	<46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>
	<43D3E551.5040208@colorado.edu>
	<46cb515a0601221217m467f7406jeaebdc67e06a64c0@mail.gmail.com>
	<43D5B8D6.8000404@colorado.edu>
Message-ID: <dr4f16$dvm$1@sea.gmane.org>

Fernando Perez wrote:

> The win32 installer puts the manual with a link in the start menu, and the 
> *nix ones do put the docs and manpages in the proper places (/usr/share/doc). 

That's not necessarily the proper place.

>   Did you remove them altogether?  What happens if someone installs the egg 
> and they want to read the manual?  Do they need to go online?

This is one issue with using eggs as a packaging system. There's no place in an
egg (with out-of-box setuptools[1]) to put docs and examples. Just think of eggs
as Java jars, and not .rpms or .debs.

That said, I never liked using install_data to install these kinds of things.
The package author (you, in this case, but others are worse) inevitably makes
too many assumptions about where I want things. And each package author makes
different assumptions, so I can't even pick a location and set it in
.pydistutils.cfg. I say, nuts to that.

Eggs aren't a replacement for getting the source tarball or manual. They aren't
intended to be.

[1] One could, relatively easily, write a setup.py that places the docs in a
directory inside the EGG-INFO directory inside the egg, just as the scripts are
located inside there, too. It might even be worthwhile pushing for
EGG-INFO/docs/ as the canonical place to put package documentation. If you like,
we can try this with ipython and see if it catches on with other folks.

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



From Fernando.Perez at colorado.edu  Tue Jan 24 01:56:40 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 23 Jan 2006 23:56:40 -0700
Subject: [IPython-dev] IPython 0.7.1 is out.
Message-ID: <43D5CFA8.2000904@colorado.edu>

Hi all,

I have released IPython 0.7.1, which is mainly a bugfix release over 0.7.0.
As expected in that release, given the large changes made, some problems
inevitably appeared.  I believe all regressions and known bugs have been
fixed, along with some useful new features.

This release marks the end of my tenure on the stable branch of ipython.
Ville Vainio will continue as maintainer of the ipython trunk/, while I will
continue working on the development branch of IPython (chainsaw).  I will
remain available on the list as usual, both to assist Ville as needed, and to
discuss withe anyone interested.  But I'll try to limit my time and effort
spent on trunk to a minimum, so we can really advance the (fairly ambitious)
chainsaw project.


Where to get it
---------------

IPython's homepage is at:

http://ipython.scipy.org

and downloads are at:

http://ipython.scipy.org/dist

I've provided:

     - source downloads (.tar.gz)
     - RPMs (for Python 2.3 and 2.4, built under Fedora Core 3).
     - Python Eggs (http://peak.telecommunity.com/DevCenter/PythonEggs).
     - a native win32 installer for both Python 2.3 and 2.4.

Fedora users should note that IPython is now officially part of the Extras
repository, so they can get the update from there as well (though it may lag
by a few days).

Debian, Fink and BSD packages for this version should be coming soon, as the
respective maintainers have the time to follow their packaging procedures.
Many thanks to Jack Moffit, Norbert Tretkowski, Andrea Riciputi and Dryice Liu).

The eggs included now are lighter, as they don't include documentation and
other ancillary data.  If you want a full ipython installation, use the source
tarball or your distribution's favorite system.

Many thanks to Enthought for their continued hosting support for IPython.


Release notes
-------------

As always, the full ChangeLog is at http://ipython.scipy.org/ChangeLog.  The
highlights of this release follow.

    - *FIXED: this wasn't really working right in 0.7.0* Support for input with
empty lines.  If you have auto-indent on, this means that you need to either
hit enter _twice_, or add/remove a space to your last blank line, to indicate
you're done entering input.  These changes also allow us to provide copy/paste
of code with blank lines.

    - *FIXED: this wasn't really working right in 0.7.0* Support for pasting
multiline input even with autoindent on.  The code will look wrong on screen,
but it will be stored and executed correctly internally.  Note that if you
have blank lines in your code, these need to be indented like their
surroundings (pure empty lines will make ipython assume you are finished with
your input).  This is a limitation also of the plain python interpreter, and
can't really be fixed in a line-oriented system like ipython.

    - Fixed bug where macros were not working correctly in threaded shells.

    - Catch exceptions which can be triggered asynchronously by signal
handlers.  This fixes a rare and obscure problem, but which could crash
ipython; reported by Colin Kingsley <tercel-AT-gentoo.org>.

    - Added new '-r' option to %hist, to see the raw input history (without
conversions like %ls -> ipmagic("ls")).

    - Fix problems with GTK under win32 (excessive keyboard lag and cpu usage).

    - Added ipython.py script to root directory of download.  This allows you
to unpack ipython and execute it in-place, without needing to install it at all.

    - Improved handling of backslashes (\) in magics.  This improves the
usability of ipython especially under win32, which uses \ as a path separator
(though it also benefits Unix for escaping characters in shell usage).

    - More autocall fixes (rare, but critical).

    - New IPython.ipapi module to begin exposing 'officially' IPython's public
API.  This should ease the task of those building systems on top of ipython.

    - New IPython.platutils module, exposing various platform-dependent
utilities (such as terminal title control).

    - Implemented exception-based 'chain of command' for IPython's hooks.

    - Added Jason Orendorff's "path" module to IPython tree,
http://www.jorendorff.com/articles/python/path/.
	
	You can get path objects conveniently through %sc, and !!, e.g.:
	 sc files=ls
	 for p in files.paths: # or files.p
	     print p,p.mtime

    - Fix '%run -d' with Python 2.4 (pdb changed in Python 2.4).

    - Various other small fixes and enhancements.


Enjoy, and as usual please report any problems.


Regards, and thanks for all this time using IPython!

Fernando.



From Fernando.Perez at colorado.edu  Tue Jan 24 02:13:39 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 24 Jan 2006 00:13:39 -0700
Subject: [IPython-dev] [IPython-user] IPython 0.7.0 is out.
In-Reply-To: <dr4f16$dvm$1@sea.gmane.org>
References: <43C374E6.8030602@colorado.edu> <43C4C7F4.3000002@colorado.edu>
	<43D349F5.9070809@colorado.edu>		<200601221446.56186.hans_meine@gmx.net>
	<46cb515a0601220631u7753032bieca6b9586eae8400@mail.gmail.com>
	<43D3E551.5040208@colorado.edu>
	<46cb515a0601221217m467f7406jeaebdc67e06a64c0@mail.gmail.com>
	<43D5B8D6.8000404@colorado.edu> <dr4f16$dvm$1@sea.gmane.org>
Message-ID: <43D5D3A3.4050907@colorado.edu>

Robert Kern wrote:
> Fernando Perez wrote:
> 
> 
>>The win32 installer puts the manual with a link in the start menu, and the 
>>*nix ones do put the docs and manpages in the proper places (/usr/share/doc). 
> 
> 
> That's not necessarily the proper place.

Well, take it up with the distutils authors :)  My setup.py is fairly 
conservative, I think (it's really $PREFIX/... what's used, not hard-wired to 
/usr/).

> This is one issue with using eggs as a packaging system. There's no place in an
> egg (with out-of-box setuptools[1]) to put docs and examples. Just think of eggs
> as Java jars, and not .rpms or .debs.
> 
> That said, I never liked using install_data to install these kinds of things.
> The package author (you, in this case, but others are worse) inevitably makes
> too many assumptions about where I want things. And each package author makes
> different assumptions, so I can't even pick a location and set it in
> .pydistutils.cfg. I say, nuts to that.
> 
> Eggs aren't a replacement for getting the source tarball or manual. They aren't
> intended to be.

Thanks for the clarification.  I actually _had_ thought of them as rpm/debs.

> [1] One could, relatively easily, write a setup.py that places the docs in a
> directory inside the EGG-INFO directory inside the egg, just as the scripts are
> located inside there, too. It might even be worthwhile pushing for
> EGG-INFO/docs/ as the canonical place to put package documentation. If you like,
> we can try this with ipython and see if it catches on with other folks.

Sure, that could be done.

Cheers,

f



From vivainio at gmail.com  Tue Jan 24 12:28:28 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Tue, 24 Jan 2006 09:28:28 -0800
Subject: [IPython-dev] %paste
In-Reply-To: <43D552C7.40008@colorado.edu>
References: <46cb515a0601231237k6c786b19h1126dfd688306234@mail.gmail.com>
	<43D53F60.7090001@colorado.edu>
	<46cb515a0601231255j297929e9n4dcb924ac7e81667@mail.gmail.com>
	<43D5441D.6020208@colorado.edu>
	<46cb515a0601231332t6712df30sc472a5ff4a45c601@mail.gmail.com>
	<46cb515a0601231348w36a17e81i963caf86b4b99c7d@mail.gmail.com>
	<43D552C7.40008@colorado.edu>
Message-ID: <46cb515a0601240928s45ca9fa8g63c525b1c1feee78@mail.gmail.com>

On 1/23/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> cpaste?  Short for 'code paste'

Done. Rationale - it's also short for 'copy-paste", %cpaste varname
format doesn't require
the pastee to be python code.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Tue Jan 24 13:33:12 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Tue, 24 Jan 2006 20:33:12 +0200
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs &
	examples
In-Reply-To: <43D66630.1000306@colorado.edu>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
Message-ID: <46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>

On 1/24/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> In light of this, then perhaps the idea of the doc-eggs may be a good one.  I

Doc-eggs is not a well-supported idea (IIUC), because it would put the
docs under site-packages (esp. in Windows there is no standard place
for docs). Documentation and examples in a plain old zip file would be
better, users can put them anywhere they want.

Here's an idea - we could put a few-page quick-reference into IPython,
accessible by typing 'quickref'. It would have all the handy "%sc
var=ls *.cpp" stuff that users might forget.

> like to make sure that users without always-on net access can get the full
> functionality of ipython, and if we are to provide eggs, might as well make
> them 'first class citizens'.

Offline users will of course get full *functionality*, only the
"static" documentation is lost (so that nobody misunderstands the egg
as a "crippled" version of IPython).

In fact, I think of the egg as the non-intrusive, humble, simple
version of IPython that doesn't require post-install actions even on
Windows. :-)

> Ville, can you please post a note both on -user and -dev once you've merged
> the 0.7.1 branch back into trunk?  That will be the time for our SVN users
> (including myself) to do an 'svn switch /path/to/trunk' again.

Done, you are good to go.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Tue Jan 24 13:37:17 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Tue, 24 Jan 2006 20:37:17 +0200
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs &
	examples
In-Reply-To: <46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
Message-ID: <46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>

> Here's an idea - we could put a few-page quick-reference into IPython,
> accessible by typing 'quickref'. It would have all the handy "%sc
> var=ls *.cpp" stuff that users might forget.

Bah, didn't realize there was just '?'. It may be a bit verbose for
quick reference, but something like that could be added to the start
of the output.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Tue Jan 24 13:47:03 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Tue, 24 Jan 2006 20:47:03 +0200
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd simplification
Message-ID: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>

I figured we could implement a handy and intuitive way to grab
both magic return values and system command output:

var = %mymagic args a plenty

var = !command args a plenty

The regexp to catch these reliably is trivial (provided that var name
is (\w+) and both are illegal python. Anyone have any
doubt/objections? $$var = cmd syntax is there but it's not as easy to
remember or obvious.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Tue Jan 24 13:53:44 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Tue, 24 Jan 2006 20:53:44 +0200
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd simplification
In-Reply-To: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
References: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
Message-ID: <46cb515a0601241053n2f8b1373y66bf2c6d5211163@mail.gmail.com>

On 1/24/06, Ville Vainio <vivainio at gmail.com> wrote:

> The regexp to catch these reliably is trivial (provided that var name
> is (\w+) and both are illegal python. Anyone have any
> doubt/objections? $$var = cmd syntax is there but it's not as easy to
> remember or obvious.

An extra idea - we could add a "pluggable prefilter" system a'la:

import IPython.ipapi as ip

def grab_sys_cmd_output(orig_line):
  ...
  return "%s = popen(%s).read()" % (varname, cmd)

ip.register_prefilter(r"(\w+)\s*=\s*!(.*)", grab_sys_cmd_output)

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Tue Jan 24 13:53:54 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 24 Jan 2006 11:53:54 -0700
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd	simplification
In-Reply-To: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
References: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
Message-ID: <43D677C2.4000707@colorado.edu>

Ville Vainio wrote:
> I figured we could implement a handy and intuitive way to grab
> both magic return values and system command output:
> 
> var = %mymagic args a plenty
> 
> var = !command args a plenty
> 
> The regexp to catch these reliably is trivial (provided that var name
> is (\w+) and both are illegal python. Anyone have any
> doubt/objections? $$var = cmd syntax is there but it's not as easy to
> remember or obvious.

+1: it looks like it can be done safely, at least in single-line input.  I'd 
avoid this in continuation lines, because you could be in the middle of a 
string (triple-quoted).  In multiline input, people can always use

foo = ipmagic()

and friends.  Even for ipython, which tries as hard as possible to be 
convenient, correctness trumps convenience.

I'd suggest adding a test/ directory to ipython, where we can start at least 
storing primitive testing scripts.  For now, even if it's just plain files 
that we can copy/paste into a session to see whether we haven't totally blown 
something would be good.  I've many times in the past made a seemingly 
innocuous change to a regexp, just to find out that I broke something 
fundamental in input processing.

Having lines of valid python that we can just highlight and paste in would be 
good, and it would provide a minimal measure of safety when experimenting with 
extensions like this.

As time goes, this can grow into a proper unittest framework (for chainsaw, we 
WILL enforce unittest coverage for all code; no reason we can't start a little 
now).

Cheers,

f



From vivainio at gmail.com  Tue Jan 24 14:03:09 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Tue, 24 Jan 2006 21:03:09 +0200
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd	simplification
In-Reply-To: <43D677C2.4000707@colorado.edu>
References: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
	<43D677C2.4000707@colorado.edu>
Message-ID: <46cb515a0601241103m2a283252t64cdd3b4151f2104@mail.gmail.com>

On 1/24/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> I'd suggest adding a test/ directory to ipython, where we can start at least
> storing primitive testing scripts.  For now, even if it's just plain files
> that we can copy/paste into a session to see whether we haven't totally blown
> something would be good.  I've many times in the past made a seemingly

I've also thought of this, it's something that has been lacking. We
could go there and %run every file and report regressions... with some
extra effort, we could also edit the files after-the-fact and add some
"assert _.isfile()" conditions,

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Tue Jan 24 14:08:51 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 24 Jan 2006 12:08:51 -0700
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd	simplification
In-Reply-To: <46cb515a0601241103m2a283252t64cdd3b4151f2104@mail.gmail.com>
References: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
	<43D677C2.4000707@colorado.edu>
	<46cb515a0601241103m2a283252t64cdd3b4151f2104@mail.gmail.com>
Message-ID: <43D67B43.1040406@colorado.edu>

Ville Vainio wrote:
> On 1/24/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>I'd suggest adding a test/ directory to ipython, where we can start at least
>>storing primitive testing scripts.  For now, even if it's just plain files
>>that we can copy/paste into a session to see whether we haven't totally blown
>>something would be good.  I've many times in the past made a seemingly
> 
> 
> I've also thought of this, it's something that has been lacking. We
> could go there and %run every file and report regressions... with some
> extra effort, we could also edit the files after-the-fact and add some
> "assert _.isfile()" conditions,

Yup.  At this point, ANY testing is better than we have :)

Some of these need to be pasted interactively and can't be scripted, because 
we also need to check the behavior of autoindent and whatnot, but still.

But even an automatic script that does

ip = an_ipython_instance()
for file in dir_list('*.py'):
   ip.magic_run(file)

will be an improvement.

Cheers,

f



From Fernando.Perez at colorado.edu  Tue Jan 24 14:10:20 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 24 Jan 2006 12:10:20 -0700
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd	simplification
In-Reply-To: <46cb515a0601241053n2f8b1373y66bf2c6d5211163@mail.gmail.com>
References: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
	<46cb515a0601241053n2f8b1373y66bf2c6d5211163@mail.gmail.com>
Message-ID: <43D67B9C.80607@colorado.edu>

Ville Vainio wrote:
> On 1/24/06, Ville Vainio <vivainio at gmail.com> wrote:
> 
> 
>>The regexp to catch these reliably is trivial (provided that var name
>>is (\w+) and both are illegal python. Anyone have any
>>doubt/objections? $$var = cmd syntax is there but it's not as easy to
>>remember or obvious.
> 
> 
> An extra idea - we could add a "pluggable prefilter" system a'la:

Yes, prefilters are obviously one of the prime candidates for extension 
points.  Pysh is an example, and SAGE (http://modular.ucsd.edu/sage/) takes 
this idea quite far, but it would be nice to make this kind of usage as simple 
as possible for new extension writers.

Cheers,

f



From Fernando.Perez at colorado.edu  Wed Jan 25 02:31:56 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 25 Jan 2006 00:31:56 -0700
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs &
	examples
In-Reply-To: <46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
Message-ID: <43D7296C.7050807@colorado.edu>

Ville Vainio wrote:
>>Here's an idea - we could put a few-page quick-reference into IPython,
>>accessible by typing 'quickref'. It would have all the handy "%sc
>>var=ls *.cpp" stuff that users might forget.
> 
> 
> Bah, didn't realize there was just '?'. It may be a bit verbose for
> quick reference, but something like that could be added to the start
> of the output.

I think we could just edit it a bit, and include right in there a pointer to 
some of the online resources that have sprung around ipython:

http://ipython.scipy.org/doc/manual/node4.html
http://www.onlamp.com/pub/a/python/2005/01/27/ipython.html
http://showmedo.com/videoListPage?listKey=PythonIPythonSeries
http://www.python-industries.com/clepy/ipython/

I prefer to have a single point of entrance for newcomers to get off the 
ground, even if it's just plain text and slightly long.  They can always read 
it a few times, the first just getting the basics, and later coming back to 
read details.  That text should mostly describe how to find more info (use of 
? even for magics), along with highlighting the key magics for various tasks 
(not all are equally useful, and probably %run and %edit are the main ones).

I think a plain text document (or reST), cleanly formatted, should do the 
trick just fine with '?'.  The current one is not bad, but VERY old and 
unchanged for a long time.  It could certainly use a face-lift.

Cheers,

f



From vds at aisystems.be  Wed Jan 25 03:06:20 2006
From: vds at aisystems.be (Vivian De Smedt)
Date: Wed, 25 Jan 2006 09:06:20 +0100 (CET)
Subject: [IPython-dev] IPython help systems fails with 0.7.1 under windows
Message-ID: <3895.83.206.34.167.1138176380.squirrel@83.206.34.167>

Dear All,

This is a bug report. I just download the last IPython version 0.7.1.

As some of you know I'm running IPython under windows and it seems that
that the help functionality of IPython is broken on my station.

the following code:

    import os
    os ?

lead to a huge stack print that end with:

C:\Documents and
Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\iplib.py in
_prefilter(self, line, continue_prompt
)
   1848             handler = self.esc_handlers.get(iFun[0:1])
   1849         if handler is not None:
-> 1850             return handler(line,continue_prompt,pre,iFun,theRest)
   1851         # Emacs ipython-mode tags certain input lines
   1852         if line.endswith('# PYTHON-MODE'):

C:\Documents and
Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\iplib.py in
handle_help(self, line, continue_promp
t, pre, iFun, theRest)
   2070             self.log('#?'+line)
   2071             if line:
-> 2072                 self.magic_pinfo(line)
   2073             else:
   2074                 page(self.usage,screen_lines=self.rc.screen_length)

C:\Documents and
Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\Magic.py in
magic_pinfo(self, parameter_s)
    674             self.magic_psearch(oname)
    675         else:
--> 676             self._inspect('pinfo',oname,detail_level=detail_level)
    677
    678     def magic_psearch(self, parameter_s=''):

C:\Documents and
Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\Magic.py in
_inspect(self, meth, oname, **kw)
    609                 pmethod(info.obj,oname,formatter)
    610             elif meth == 'pinfo':
--> 611                 pmethod(info.obj,oname,formatter,info,**kw)
    612             else:
    613                 pmethod(info.obj,oname)

C:\Documents and
Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\OInspect.py in
pinfo(self, obj, oname, formatter,
info, detail_level)
    417         output = out.getvalue()
    418         if output:
--> 419             page(output)
    420         # end pinfo
    421

C:\Documents and
Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\genutils.py in
page(strng, start, screen_lines, pa
ger_cmd)
   1362
   1363     if os.name == "nt":
-> 1364         screen_lines_def = get_console_size(defaulty=25)[1]
   1365     else:
   1366         screen_lines_def = 25 # default value if we can't
auto-determine

C:\Documents and
Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\winconsole.py in
get_console_size(defaultx, defaul
ty)
     33
     34     h = ctypes.windll.kernel32.GetStdHandle(-11)
---> 35     csbi = ctypes.create_string_buffer(22)
     36     res = ctypes.windll.kernel32.GetConsoleScreenBufferInfo(h, csbi)
     37

AttributeError: 'module' object has no attribute 'create_string_buffer'

Cheers,
Vivian.



From Fernando.Perez at colorado.edu  Wed Jan 25 02:37:35 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 25 Jan 2006 00:37:35 -0700
Subject: [IPython-dev] IPython help systems fails with 0.7.1 under
	windows
In-Reply-To: <3895.83.206.34.167.1138176380.squirrel@83.206.34.167>
References: <3895.83.206.34.167.1138176380.squirrel@83.206.34.167>
Message-ID: <43D72ABF.8040202@colorado.edu>

Vivian De Smedt wrote:
> Dear All,
> 
> This is a bug report. I just download the last IPython version 0.7.1.
> 

> C:\Documents and
> Settings\vds.AISYSTEMS\Desktop\ipython-0.7.1\IPython\winconsole.py in
> get_console_size(defaultx, defaul
> ty)
>      33
>      34     h = ctypes.windll.kernel32.GetStdHandle(-11)
> ---> 35     csbi = ctypes.create_string_buffer(22)
>      36     res = ctypes.windll.kernel32.GetConsoleScreenBufferInfo(h, csbi)
>      37
> 
> AttributeError: 'module' object has no attribute 'create_string_buffer'

What version of ctypes are you running?  I can't test this code (win32), but I 
just downloaded ctypes current (0.9.6), and a quick grep does show that 
function in a LOT of places:

abdul[ctypes-0.9.6]> egrep -rn create_string_buffer *
ctypes/__init__.py:43:def create_string_buffer(init, size=None):
ctypes/__init__.py:44:    """create_string_buffer(aString) -> character array
ctypes/__init__.py:45:    create_string_buffer(anInteger) -> character array
ctypes/__init__.py:46:    create_string_buffer(aString, anInteger) -> 
character array
ctypes/__init__.py:62:##    "deprecated, use create_string_buffer instead"
ctypes/__init__.py:64:##    warnings.warn("c_buffer is deprecated, use 
create_string_buffer instead",
ctypes/__init__.py:66:    return create_string_buffer(init, size)
ctypes/decorators.py:13:...     buf = create_string_buffer(256)
docs/tutorial.stx:232:    blocks, ctypes has a 'create_string_buffer' function 
which creates these in
docs/tutorial.stx:238:      >>> p = create_string_buffer(3)      # create a 3 
byte buffer, initialized to NUL bytes
docs/tutorial.stx:241:      >>> p = create_string_buffer("Hello")      # 
create a buffer containing a NUL terminated string
docs/tutorial.stx:246:      >>> p = create_string_buffer("Hello", 10)  # 
create a 10 byte buffer
docs/tutorial.stx:254:    The 'create_string_buffer' function replaces the 
'c_buffer'
docs/tutorial.stx:454:      >>> s = create_string_buffer('\000' * 32)
NEWS.txt:30:    Both create_string_buffer and create_unicode_buffer can now be
unittests/test_unicode.py:102:            buf = 
ctypes.create_string_buffer(u"abc")
unittests/test_unicode.py:106:            buf = 
ctypes.create_string_buffer(u"ab?")
unittests/test_unicode.py:110:            buf = 
ctypes.create_string_buffer(u"ab?")
unittests/test_memfunctions.py:6:        a = create_string_buffer(32)
unittests/test_memfunctions.py:16:        a = create_string_buffer(32)
unittests/test_buffers.py:7:        b = create_string_buffer(32)
unittests/test_buffers.py:12:        b = create_string_buffer("abc")
unittests/test_buffers.py:20:        b = create_string_buffer(u"abc")


Perhaps you could try updating ctypes, and seeing what happens.

f



From vds at aisystems.be  Wed Jan 25 03:17:36 2006
From: vds at aisystems.be (Vivian De Smedt)
Date: Wed, 25 Jan 2006 09:17:36 +0100 (CET)
Subject: [IPython-dev] IPython help systems fails with 0.7.1 under
 windows
In-Reply-To: <43D72ABF.8040202@colorado.edu>
References: <3895.83.206.34.167.1138176380.squirrel@83.206.34.167>
	<43D72ABF.8040202@colorado.edu>
Message-ID: <2325.83.206.34.167.1138177056.squirrel@83.206.34.167>

Fernando,

I which I never sent that mail. I just install the last version of ctypes
and now IPython help system run nicely again :-)

Sorry :-|

Cheers,
Vivian.



From Fernando.Perez at colorado.edu  Wed Jan 25 02:45:46 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 25 Jan 2006 00:45:46 -0700
Subject: [IPython-dev] IPython help systems fails with 0.7.1 under
	windows
In-Reply-To: <2325.83.206.34.167.1138177056.squirrel@83.206.34.167>
References: <3895.83.206.34.167.1138176380.squirrel@83.206.34.167>
	<43D72ABF.8040202@colorado.edu>
	<2325.83.206.34.167.1138177056.squirrel@83.206.34.167>
Message-ID: <43D72CAA.8020801@colorado.edu>

Vivian De Smedt wrote:
> Fernando,
> 
> I which I never sent that mail. I just install the last version of ctypes
> and now IPython help system run nicely again :-)

OK, good to know.

> Sorry :-|

No worries,

f



From vivainio at gmail.com  Wed Jan 25 03:01:47 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 25 Jan 2006 10:01:47 +0200
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs &
	examples
In-Reply-To: <43D7296C.7050807@colorado.edu>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
	<43D7296C.7050807@colorado.edu>
Message-ID: <46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>

On 1/25/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> ground, even if it's just plain text and slightly long.  They can always read
> it a few times, the first just getting the basics, and later coming back to
> read details.  That text should mostly describe how to find more info (use of

I wasn't really thinking of a tutorial / getting started guide, but a
quick reference, like those printable emacs/vi keybinding charts.

With oneliners like:

'cd', '%cd': Call magic function cd
'%cd?': Get help for magic function cd

It's an easy thing to get going, and worth a shot for offline users,
even advanced ones (certainly better than externally launched
documentation, people are lazy).

I think importing the 'usage' module only when needed would be doable
as well, to conserve a bit of memory (probably only cosmetic effect
though).

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Wed Jan 25 03:06:02 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 25 Jan 2006 01:06:02 -0700
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs
 &	examples
In-Reply-To: <46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
	<43D7296C.7050807@colorado.edu>
	<46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>
Message-ID: <43D7316A.9020403@colorado.edu>

Ville Vainio wrote:
> On 1/25/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>ground, even if it's just plain text and slightly long.  They can always read
>>it a few times, the first just getting the basics, and later coming back to
>>read details.  That text should mostly describe how to find more info (use of
> 
> 
> I wasn't really thinking of a tutorial / getting started guide, but a
> quick reference, like those printable emacs/vi keybinding charts.
> 
> With oneliners like:
> 
> 'cd', '%cd': Call magic function cd
> '%cd?': Get help for magic function cd
> 
> It's an easy thing to get going, and worth a shot for offline users,
> even advanced ones (certainly better than externally launched
> documentation, people are lazy).

Actually, if we were more systematic in making sure that all magics had a true 
one-line description (I think most do, but not all), the quickref could 
summarize these.  Kind of what 'magic' does, but just printing the first line. 
  That would be useful.


> I think importing the 'usage' module only when needed would be doable
> as well, to conserve a bit of memory (probably only cosmetic effect
> though).

That one is _definitely_ cosmetic :)

Cheers,

f



From vivainio at gmail.com  Wed Jan 25 04:04:08 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 25 Jan 2006 11:04:08 +0200
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs
	&	examples
In-Reply-To: <43D7316A.9020403@colorado.edu>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
	<43D7296C.7050807@colorado.edu>
	<46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>
	<43D7316A.9020403@colorado.edu>
Message-ID: <46cb515a0601250104l78e8e67fj12a4f20c3ebd321a@mail.gmail.com>

On 1/25/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Actually, if we were more systematic in making sure that all magics had a true
> one-line description (I think most do, but not all), the quickref could
> summarize these.  Kind of what 'magic' does, but just printing the first line.
>   That would be useful.

Yeah, that compounded with quick runover of prefix characters; sounds
like a plan.

I've also thought of hiding/undocumenting some magics (pdoc, psource)
etc.; ? notation is probably what people will use anyway.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Wed Jan 25 22:17:59 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 25 Jan 2006 20:17:59 -0700
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs &
 examples
In-Reply-To: <46cb515a0601250104l78e8e67fj12a4f20c3ebd321a@mail.gmail.com>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
	<43D7296C.7050807@colorado.edu>
	<46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>
	<43D7316A.9020403@colorado.edu>
	<46cb515a0601250104l78e8e67fj12a4f20c3ebd321a@mail.gmail.com>
Message-ID: <43D83F67.6040701@colorado.edu>

Ville Vainio wrote:
> On 1/25/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>Actually, if we were more systematic in making sure that all magics had a true
>>one-line description (I think most do, but not all), the quickref could
>>summarize these.  Kind of what 'magic' does, but just printing the first line.
>>  That would be useful.
> 
> 
> Yeah, that compounded with quick runover of prefix characters; sounds
> like a plan.

Good.

> I've also thought of hiding/undocumenting some magics (pdoc, psource)
> etc.; ? notation is probably what people will use anyway.

No, don't.  There are users of this stuff out there.  These folks

http://casa.nrao.edu/demo1.shtml

have gone as far as documenting it in their tutorials.

The stable branch should live up to its name: let's not break backwards 
compatibility unless there is a _strong, compelling_ reason to do so. 
Convenience, cleanup, tidyness, are NOT strong and compelling.

That's the price of having established users, I'm afraid: IPython has a 
reasonably large user base, and there are various institutions which have 
built their interactive control environments using ipython as the engine. 
This is _exactly_ what I'd always wanted, but for such users any kind of 
gratuitous breakage with new versions is likely to be very unwelcome.  Let's 
not do it unless it's _really_ necessary.

The other things you've been doing, like adding new features, or exposing old 
crufty internals with a cleaner interface (the ipapi stuff) are all very 
welcome even by such users, as it gives them new ways of doing things better. 
  But at this point, we really need to avoid any break in backwards 
compatibility as much as possible.

Cheers,

f



From vivainio at gmail.com  Thu Jan 26 03:13:11 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 26 Jan 2006 10:13:11 +0200
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs
	&	examples
In-Reply-To: <43D83F67.6040701@colorado.edu>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
	<43D7296C.7050807@colorado.edu>
	<46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>
	<43D7316A.9020403@colorado.edu>
	<46cb515a0601250104l78e8e67fj12a4f20c3ebd321a@mail.gmail.com>
	<43D83F67.6040701@colorado.edu>
Message-ID: <46cb515a0601260013y607260c0lda0765dab585b459@mail.gmail.com>

On 1/26/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> The stable branch should live up to its name: let's not break backwards
> compatibility unless there is a _strong, compelling_ reason to do so.
> Convenience, cleanup, tidyness, are NOT strong and compelling.

I have no intention to break backwards compatibility anywhere so you
can relax about this; it's more of a documentation/encouragement
issue. It would still work as usual.

Not that I'm actually going to do it anytime soon, there are things of
higher priority pending.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Thu Jan 26 03:18:44 2006
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Thu, 26 Jan 2006 01:18:44 -0700
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs
	&	examples
In-Reply-To: <46cb515a0601260013y607260c0lda0765dab585b459@mail.gmail.com>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<43D66630.1000306@colorado.edu>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
	<43D7296C.7050807@colorado.edu>
	<46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>
	<43D7316A.9020403@colorado.edu>
	<46cb515a0601250104l78e8e67fj12a4f20c3ebd321a@mail.gmail.com>
	<43D83F67.6040701@colorado.edu>
	<46cb515a0601260013y607260c0lda0765dab585b459@mail.gmail.com>
Message-ID: <1138263524.43d885e4a1017@webmail.colorado.edu>

Quoting Ville Vainio <vivainio at gmail.com>:

> On 1/26/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
>
> > The stable branch should live up to its name: let's not break backwards
> > compatibility unless there is a _strong, compelling_ reason to do so.
> > Convenience, cleanup, tidyness, are NOT strong and compelling.
>
> I have no intention to break backwards compatibility anywhere so you
> can relax about this; it's more of a documentation/encouragement
> issue. It would still work as usual.

OK, good.  Encouraging people to use ?, that I fully agree with.  I never use
the p* functions myself, but seeing that tutorial made me realize someone out
there may like them.  I happen to think that ? does the job better, and that's
pretty much all I ever use.

I just wanted to make sure we're on the same page regarding backwards
compatibility, for the benefit of users who may rely on ipython as a component
of a larger system.

Cheers,

f



From vivainio at gmail.com  Thu Jan 26 04:07:28 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 26 Jan 2006 11:07:28 +0200
Subject: [IPython-dev] [IPython-user] On Eggs and the striping of docs
	&	examples
In-Reply-To: <1138263524.43d885e4a1017@webmail.colorado.edu>
References: <46cb515a0601240000j560cff0coc7fa84968ef1fd8c@mail.gmail.com>
	<46cb515a0601241033u3ed4d898w9f1e424bd80b31ed@mail.gmail.com>
	<46cb515a0601241037v4c945568idf38b16a353c0edf@mail.gmail.com>
	<43D7296C.7050807@colorado.edu>
	<46cb515a0601250001sf788317nf5ab83dc6e8f77e0@mail.gmail.com>
	<43D7316A.9020403@colorado.edu>
	<46cb515a0601250104l78e8e67fj12a4f20c3ebd321a@mail.gmail.com>
	<43D83F67.6040701@colorado.edu>
	<46cb515a0601260013y607260c0lda0765dab585b459@mail.gmail.com>
	<1138263524.43d885e4a1017@webmail.colorado.edu>
Message-ID: <46cb515a0601260107i1d675c2m17ed282c825eedfe@mail.gmail.com>

On 1/26/06, Fernando.Perez at colorado.edu <Fernando.Perez at colorado.edu> wrote:

> I just wanted to make sure we're on the same page regarding backwards
> compatibility, for the benefit of users who may rely on ipython as a component
> of a larger system.

Definitely.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Fri Jan 27 14:10:23 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 27 Jan 2006 21:10:23 +0200
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd simplification
In-Reply-To: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
References: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
Message-ID: <46cb515a0601271110n15f939c0mbe27fb67d668aa33@mail.gmail.com>

On 1/24/06, Ville Vainio <vivainio at gmail.com> wrote:

> I figured we could implement a handy and intuitive way to grab
> both magic return values and system command output:
>
> var = %mymagic args a plenty
>
> var = !command args a plenty

Both are implemented in SVN, it'd be great if some of you had time to play
with it. The only magic that currently returns a value is %alias without args,
but I think there will be more now.

I also added a deprecation text in docs for %sc. I won't remove it but thought
users would prefer the 'files = !ls' format.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivainio at gmail.com  Fri Jan 27 14:13:21 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 27 Jan 2006 21:13:21 +0200
Subject: [IPython-dev] Magics that have return values,
	$$var=cmd	simplification
In-Reply-To: <43D67B9C.80607@colorado.edu>
References: <46cb515a0601241047j3522a087u79807ba4a4c2cd36@mail.gmail.com>
	<46cb515a0601241053n2f8b1373y66bf2c6d5211163@mail.gmail.com>
	<43D67B9C.80607@colorado.edu>
Message-ID: <46cb515a0601271113s5b664979r23cd1cd6ea57e4e5@mail.gmail.com>

On 1/24/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Yes, prefilters are obviously one of the prime candidates for extension
> points.  Pysh is an example, and SAGE (http://modular.ucsd.edu/sage/) takes
> this idea quite far, but it would be nice to make this kind of usage as simple
> as possible for new extension writers.

It's very simple now, ext_rescapture.py has an extensible example. I
think I could extract the generic "regexp prefilter" part for use by
other extensions, but I couldn't think of a good place yet.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From vivian at vdesmedt.com  Sun Jan 29 03:16:54 2006
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sun, 29 Jan 2006 09:16:54 +0100
Subject: [IPython-dev] IPython pyreadline improvement of IPython
Message-ID: <43DC79F6.8030800@vdesmedt.com>

Dear All,

I was in the juggle for a week so I just slowly catch up with the mails 
of the list :-)

I'm very glad you decide to carry your own version of readline inside 
IPython.
I like the idea of Gary of having our own version of readline for every 
platform.

Few times ago I was planning to improve the way IPython deal with:
 - Cut and Paste
 - Multi-line statements

For Multi-line statement my idea is.

    History is only made of one line statement and the first line of the
    multi-line statement.
    When we start editing a multi-line statement the down arrows let us
    add the lines of the multi-line statement.

    Suppose you made a mistake in the third line of a three lines
    statement. Now you have to type.
    up-up-up-return up-up-return up-up-[correction]-return
    And with my proposition you will have to type
    up-return down-return down-[correction]-return


And at the end it appears that the only way to improve that 
significantly was to have more readline callback and if we have our own 
version we are free to add the one we need.

I know that Fernando is on something big that will make all that 
pathetic but I would like to know what some of you think about that to 
improve the situation in the meantime. One of the first think that make 
me love python was the console and I'm pretty sure I'm not the only one 
so I'm quite enthusiast at the idea to improve it but tell me what do 
you think about it.

Cheers,
Vivian.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060129/018c31fd/attachment.html>

From vivian at vdesmedt.com  Sun Jan 29 03:28:45 2006
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sun, 29 Jan 2006 09:28:45 +0100
Subject: [IPython-dev] new way to go out of multi-line statements
Message-ID: <43DC7CBD.6060707@vdesmedt.com>

Dear All,

I notice that when typing a multi-line statement in IPython we have to 
type two consecutive full white space lines or one empty line to go out 
of the multi-line mode instead on just one full white space line. Is it 
a side effect of a bug correction or a new feature ?

Vivian.



From Fernando.Perez at colorado.edu  Sun Jan 29 03:32:48 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 29 Jan 2006 01:32:48 -0700
Subject: [IPython-dev] new way to go out of multi-line statements
In-Reply-To: <43DC7CBD.6060707@vdesmedt.com>
References: <43DC7CBD.6060707@vdesmedt.com>
Message-ID: <43DC7DB0.2000003@colorado.edu>

Vivian De Smedt wrote:
> Dear All,
> 
> I notice that when typing a multi-line statement in IPython we have to 
> type two consecutive full white space lines or one empty line to go out 
> of the multi-line mode instead on just one full white space line. Is it 
> a side effect of a bug correction or a new feature ?

This is also how the plain python shell behaves, to allow you to paste (or 
type) multiline code with blank lines in it (such as class definitions, where 
each method is typically separated by a blank line).

But note this, from the release notes:

Support for input with empty lines.  If you have auto-indent on, this means 
that you need to either hit enter _twice_, or add/remove a space to your last 
blank line, to indicate you're done entering input.  These changes also allow 
us to provide copy/paste of code with blank lines.


So you don't need a totally empty line: just adding or removing a single space 
will do.

Cheers,

f



From vivian at vdesmedt.com  Sun Jan 29 03:40:18 2006
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sun, 29 Jan 2006 09:40:18 +0100
Subject: [IPython-dev] new way to go out of multi-line statements
In-Reply-To: <43DC7DB0.2000003@colorado.edu>
References: <43DC7CBD.6060707@vdesmedt.com> <43DC7DB0.2000003@colorado.edu>
Message-ID: <43DC7F72.80602@vdesmedt.com>

Thanks :-)

Vivian.



From Fernando.Perez at colorado.edu  Sun Jan 29 16:42:52 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 29 Jan 2006 14:42:52 -0700
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <43DC79F6.8030800@vdesmedt.com>
References: <43DC79F6.8030800@vdesmedt.com>
Message-ID: <43DD36DC.1090802@colorado.edu>

Vivian De Smedt wrote:

> I know that Fernando is on something big that will make all that 
> pathetic

Not at all: what I'm working on is long-term, and will take a while to bear 
fruit in a way that directly benefits today's ipython users.  It's important 
to understand that much of what is happening in the chainsaw effort is geared 
towards other goals, mostly ones of direct relevance to scientific computing 
(high-level access to parallel computing resources, GUIs which integrate with 
Latex and matplotlib to produce scientific documents, etc.).

This same architecture will allow, at the end, a new ipython to be built with
similar features to today's, and on top of a cleaner set of internals, but it 
won't necessarily provide many new features for plain-terminal usage.

For these reasons, the current cleanup and improvements Ville and others like 
yourself are working on are very important, and I expect the stable branch to 
remain the tool of choice for interactive work for quite a while.  I simply 
needed to move my energy into something more in line with my 'regular' 
professional activities (applied mathematics and scientific computing).

So by all means continue the work on trunk/: it's where the payoff is today, 
and we will all benefit from it.  I will also contribute there when I can, but 
I'm glad that Ville and others with more time than myself to work here are 
leading the charge.

Finally, it's important to note that there are rumblings in python-dev about 
perhaps dropping readline support from Python in the future.  The problem is 
that readline is GPL, and it's not 100% clear whether Python may be violating 
the GPL by linking to it as it does today.  This is all the more reason to 
push for the development of our own readline, as it might even solve a problem 
for the Python core in the future.  Note that python-dev has NOT decided to 
drop readline, they've just been going back and forth about the problem. 
Google for the info if you are curious (it's scattered on various threads).

> For Multi-line statement my idea is.
> 
>     History is only made of one line statement and the first line of the
>     multi-line statement.
>     When we start editing a multi-line statement the down arrows let us
>     add the lines of the multi-line statement.
> 
>     Suppose you made a mistake in the third line of a three lines
>     statement. Now you have to type.
>     up-up-up-return up-up-return up-up-[correction]-return
>     And with my proposition you will have to type
>     up-return down-return down-[correction]-return

This has actually been requested for ipython by SAGE, but we can't offer it 
today (given readline's limitations).  Having our own readline where this 
could be done would be great.

Cheers,

f



From vivainio at gmail.com  Sun Jan 29 16:50:20 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 29 Jan 2006 13:50:20 -0800
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <43DD36DC.1090802@colorado.edu>
References: <43DC79F6.8030800@vdesmedt.com> <43DD36DC.1090802@colorado.edu>
Message-ID: <46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>

On 1/29/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Finally, it's important to note that there are rumblings in python-dev about
> perhaps dropping readline support from Python in the future.  The problem is
> that readline is GPL, and it's not 100% clear whether Python may be violating
> the GPL by linking to it as it does today.  This is all the more reason to

It may also be said that dropping readline from official python distro
would be a slight boost for ipython, which doesn't need to care about
GPL (BSD license is GPL compatible). I rarely find myself using the
plain old python console anymore.

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Sun Jan 29 16:55:37 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 29 Jan 2006 14:55:37 -0700
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>
References: <43DC79F6.8030800@vdesmedt.com> <43DD36DC.1090802@colorado.edu>
	<46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>
Message-ID: <43DD39D9.9090404@colorado.edu>

Ville Vainio wrote:
> On 1/29/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>Finally, it's important to note that there are rumblings in python-dev about
>>perhaps dropping readline support from Python in the future.  The problem is
>>that readline is GPL, and it's not 100% clear whether Python may be violating
>>the GPL by linking to it as it does today.  This is all the more reason to
> 
> 
> It may also be said that dropping readline from official python distro
> would be a slight boost for ipython, which doesn't need to care about
> GPL (BSD license is GPL compatible). I rarely find myself using the
> plain old python console anymore.

Well, the point is that since we'd be writing our _own_ readline, the license 
of the FSF readline wouldn't matter: we wouldn't be using it.  If such an 
effort were successful across platforms, core python could take our own 
readline to replace their bindings to FSF-readline without fear.  The problem 
is the 'viral' nature of the GPL: technically, Python _may_ be in violation of 
the GPL by using readline and Python not being ALL GPL.  If the FSF went after 
Python, they'd have to either:

1. Change ALL of python to GPL

2. Drop readline.

Since 1 is out of the question, 2 would be the inevitable outcome.

Given that readline is absolutely central to ipython's functionality, the 
timing of our incorporating Gary's readline into our tree, and his idea of 
porting this to *nix, appears perfect.

Cheers,

f



From robert.kern at gmail.com  Sun Jan 29 17:00:36 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 29 Jan 2006 16:00:36 -0600
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <43DD39D9.9090404@colorado.edu>
References: <43DC79F6.8030800@vdesmedt.com> <43DD36DC.1090802@colorado.edu>
	<46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>
	<43DD39D9.9090404@colorado.edu>
Message-ID: <drjdu5$6po$1@sea.gmane.org>

Fernando Perez wrote:

> Well, the point is that since we'd be writing our _own_ readline, the license 
> of the FSF readline wouldn't matter: we wouldn't be using it.  If such an 
> effort were successful across platforms, core python could take our own 
> readline to replace their bindings to FSF-readline without fear.  The problem 
> is the 'viral' nature of the GPL: technically, Python _may_ be in violation of 
> the GPL by using readline and Python not being ALL GPL.

That's not how the GPL works. That's not even how the FSF thinks the GPL works. Oy.

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



From vivainio at gmail.com  Sun Jan 29 17:03:14 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Sun, 29 Jan 2006 14:03:14 -0800
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <43DD39D9.9090404@colorado.edu>
References: <43DC79F6.8030800@vdesmedt.com> <43DD36DC.1090802@colorado.edu>
	<46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>
	<43DD39D9.9090404@colorado.edu>
Message-ID: <46cb515a0601291403t1aa5a05nfb0efa40380cc825@mail.gmail.com>

On 1/29/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Given that readline is absolutely central to ipython's functionality, the
> timing of our incorporating Gary's readline into our tree, and his idea of
> porting this to *nix, appears perfect.

There's still the job of actual porting... I don't know how hard it
would be, but someone needs to have enough motivation to do it, it's
mostly a political issue after all and there are several workarounds
(one of which is using ipython).

Incidentally, isn't there a BSD readline?

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Sun Jan 29 17:04:47 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 29 Jan 2006 15:04:47 -0700
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <drjdu5$6po$1@sea.gmane.org>
References: <43DC79F6.8030800@vdesmedt.com> <43DD36DC.1090802@colorado.edu>
	<46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>
	<43DD39D9.9090404@colorado.edu> <drjdu5$6po$1@sea.gmane.org>
Message-ID: <43DD3BFF.3040704@colorado.edu>

Robert Kern wrote:
> Fernando Perez wrote:
> 
> 
>>Well, the point is that since we'd be writing our _own_ readline, the license 
>>of the FSF readline wouldn't matter: we wouldn't be using it.  If such an 
>>effort were successful across platforms, core python could take our own 
>>readline to replace their bindings to FSF-readline without fear.  The problem 
>>is the 'viral' nature of the GPL: technically, Python _may_ be in violation of 
>>the GPL by using readline and Python not being ALL GPL.
> 
> 
> That's not how the GPL works. That's not even how the FSF thinks the GPL works. Oy.

Well, that seems to be how python-dev is worried it might be interpreted, 
unless _I_ misunderstood something (quite possible, given how 
low-level-legal-detail this discussion can get).  But the point remains that 
there ARE worries in python-dev about the status of readline, so having a plan 
  B strikes me as a good thing (tm).

Cheers,

f




From Fernando.Perez at colorado.edu  Sun Jan 29 17:07:19 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 29 Jan 2006 15:07:19 -0700
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <46cb515a0601291403t1aa5a05nfb0efa40380cc825@mail.gmail.com>
References: <43DC79F6.8030800@vdesmedt.com> <43DD36DC.1090802@colorado.edu>
	<46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>
	<43DD39D9.9090404@colorado.edu>
	<46cb515a0601291403t1aa5a05nfb0efa40380cc825@mail.gmail.com>
Message-ID: <43DD3C97.70704@colorado.edu>

Ville Vainio wrote:
> On 1/29/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
> 
>>Given that readline is absolutely central to ipython's functionality, the
>>timing of our incorporating Gary's readline into our tree, and his idea of
>>porting this to *nix, appears perfect.
> 
> 
> There's still the job of actual porting... I don't know how hard it
> would be, but someone needs to have enough motivation to do it, it's
> mostly a political issue after all and there are several workarounds
> (one of which is using ipython).

Well, using ipython would NOT be a workaround (under *nix) if python dropped 
readline: ipython itself would lose the readline features in that case.

> Incidentally, isn't there a BSD readline?

There's some readline-lite which Apple uses under OSX, and which they even 
call libreadline (which fools readline-detection code), but it's apparently 
quite limited compared to the real thing.  But I don't know the details.

Cheers,

f



From robert.kern at gmail.com  Sun Jan 29 17:10:39 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 29 Jan 2006 16:10:39 -0600
Subject: [IPython-dev] IPython pyreadline improvement of IPython
In-Reply-To: <46cb515a0601291403t1aa5a05nfb0efa40380cc825@mail.gmail.com>
References: <43DC79F6.8030800@vdesmedt.com> <43DD36DC.1090802@colorado.edu>
	<46cb515a0601291350n58af0dd6h107c8f6c26d3334e@mail.gmail.com>
	<43DD39D9.9090404@colorado.edu>
	<46cb515a0601291403t1aa5a05nfb0efa40380cc825@mail.gmail.com>
Message-ID: <drjeh0$96q$1@sea.gmane.org>

Ville Vainio wrote:
> On 1/29/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
> 
>>Given that readline is absolutely central to ipython's functionality, the
>>timing of our incorporating Gary's readline into our tree, and his idea of
>>porting this to *nix, appears perfect.
> 
> There's still the job of actual porting... I don't know how hard it
> would be, but someone needs to have enough motivation to do it, it's
> mostly a political issue after all and there are several workarounds
> (one of which is using ipython).
> 
> Incidentally, isn't there a BSD readline?

libedit. It's missing some functionality in GNU readline which the readline
module uses, and is abandoned (I think). It's possible that libedit may provide
just enough functionality for us, though.

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



From vivainio at gmail.com  Mon Jan 30 16:18:54 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Mon, 30 Jan 2006 23:18:54 +0200
Subject: [IPython-dev] ipalias deprecated
Message-ID: <46cb515a0601301318x1d9ecbb2la63df2885703bf9f@mail.gmail.com>

ipalias is now redundant (though it still works):

[~/ipython]|1> ls /tmp
gconfd-arja/   hsperfdata_ville/  mapping-arja=   orbit-arja/   ssh-HtHjo10614/
gconfd-ville/  keyring-OXhMgA/    mapping-ville=  orbit-ville/

[~/ipython]|2> hist
1: _ip.system("ls -F --color=auto /tmp")
2: _ip.magic("hist ")

Note how the ls-alias is expanded and then called with _ip.system().

--
Ville Vainio - http://tinyurl.com/2prnb
http://vainio.blogspot.com



From Fernando.Perez at colorado.edu  Tue Jan 31 14:22:00 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 31 Jan 2006 12:22:00 -0700
Subject: [IPython-dev] easy_install ipython==dev
In-Reply-To: <46cb515a0601310006w62becbdic451fc496cda436a@mail.gmail.com>
References: <46cb515a0601301215h76fd6a17ud01abd4938d0ffe6@mail.gmail.com>
	<43DEDAAD.8000104@colorado.edu>
	<46cb515a0601302338t1d5599e5w257b1f6443b18d68@mail.gmail.com>
	<46cb515a0601310006w62becbdic451fc496cda436a@mail.gmail.com>
Message-ID: <43DFB8D8.4040301@colorado.edu>

Hi Ville,

Ville Vainio wrote:
> Damn, it of course runs setup.py instead of eggsetup.py, which results
> in broken ipython scripts. Gotta explore it further, I think we need
> to roll setup and eggsetup into one script to make this work.

I'm moving this over to ipython-dev, where I think it belongs from now.  If 
you are going to try to integrate the normal setup.py with an eggs-aware one, 
it might be good to get feedback from others.

In particular, I've recently had very bad experiences with matplotlib's setup 
script pulling in setuptools unconditionally (just because 'import setuptools' 
succeeded), and then borking on install.  Robert Kern had some good 
suggestions on that front, so let's get some feedback on that first.

Basically, let's make sure that: setuptools does ABSOLUTELY NOTHING, EVER, 
unless EXPLICITLY requested by the user at the command line.  ANY kind of 
silent action by setuptools in ipython is off-limits, period.  I've had way 
too many problems with that thing to let it anywhere near the ipython default 
behavior.

If it can't do the right thing via easyinstall, then it's setuptools' problem, 
not ours.

So, I'm all for supporting eggs as best we can, but as long as there is no way 
whatsoever that it can interfere with a plain distutils setup.

Cheers,

f



From robert.kern at gmail.com  Tue Jan 31 14:54:47 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 31 Jan 2006 13:54:47 -0600
Subject: [IPython-dev] easy_install ipython==dev
In-Reply-To: <43DFB8D8.4040301@colorado.edu>
References: <46cb515a0601301215h76fd6a17ud01abd4938d0ffe6@mail.gmail.com>
	<43DEDAAD.8000104@colorado.edu>
	<46cb515a0601302338t1d5599e5w257b1f6443b18d68@mail.gmail.com>
	<46cb515a0601310006w62becbdic451fc496cda436a@mail.gmail.com>
	<43DFB8D8.4040301@colorado.edu>
Message-ID: <drofa8$9oe$1@sea.gmane.org>

Fernando Perez wrote:
> Hi Ville,
> 
> Ville Vainio wrote:
> 
>>Damn, it of course runs setup.py instead of eggsetup.py, which results
>>in broken ipython scripts. Gotta explore it further, I think we need
>>to roll setup and eggsetup into one script to make this work.

Andrew Straw suggested an approach for matplotlib that I like.

import sys
if 'setuptools' in sys.modules:
    kwds = {'entry_points': {...}}
else:
    kwds = {}

setup(name='ipython',
      ...
      **kwds
     )

-- 
Robert Kern
robert.kern at gmail.com

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter