From jorgen.stenarson at bostream.nu  Wed Nov  2 15:04:05 2005
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 02 Nov 2005 21:04:05 +0100
Subject: [IPython-dev] Windows share patch
Message-ID: <43691BB5.5040500@bostream.nu>

Hi,

The patch still works as expected for me. I have not run into any 
problems yet.

Fernandez I think I have an idea that will make it possible for you to 
test the patch even if you are not on a windows network with your 
windows machine. By enabling sharing on some folder on your computer (do 
this by right clicking on the folder and choosing share (I'm not sure 
about the exact wording since I'm on a swedish computer)). Check the 
share permissions to see that there are reasonable defaults that apply 
to your account. Then you should be able to access that folder via an 
explorer window as \\COMPUTER\FOLDER. If this works then you could try 
it from the command prompt:

cd \\COMPUTER\FOLDER  will fail because UNC paths are not allowed
pushd \\COMPUTER\FOLDER should work by automatically mounting a drive 
(e.g. Z:/Folder)
popd takes you back

If this works your ready to try it from IPython.

This approach works for me when I'm connected to my home network (with 
only one apple computer on it).

Of course you should be careful about leaving shared folders open for 
anyone to connect to.


/J?rgen



From Fernando.Perez at colorado.edu  Wed Nov  2 15:42:58 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 02 Nov 2005 13:42:58 -0700
Subject: [IPython-dev] Windows share patch
In-Reply-To: <43691BB5.5040500@bostream.nu>
References: <43691BB5.5040500@bostream.nu>
Message-ID: <436924D2.2090206@colorado.edu>

J?rgen Stenarson wrote:
> Hi,
> 
> The patch still works as expected for me. I have not run into any 
> problems yet.
> 
> Fernandez I think I have an idea that will make it possible for you to 

It's Fernando.  Fernandez is a patronimic last name, like Stenarson :)

> test the patch even if you are not on a windows network with your 
> windows machine. By enabling sharing on some folder on your computer (do 
> this by right clicking on the folder and choosing share (I'm not sure 
> about the exact wording since I'm on a swedish computer)). Check the 
> share permissions to see that there are reasonable defaults that apply 
> to your account. Then you should be able to access that folder via an 
> explorer window as \\COMPUTER\FOLDER. If this works then you could try 
> it from the command prompt:
> 
> cd \\COMPUTER\FOLDER  will fail because UNC paths are not allowed
> pushd \\COMPUTER\FOLDER should work by automatically mounting a drive 
> (e.g. Z:/Folder)
> popd takes you back

OK, thanks for the tip.  I'll test this and commit if it all works OK.

Regards,

f

ps - you'd asked about emacs and tabs.  This is what I have in my .emacs file:

;; Use spaces instead of tabs for indentation
(defun indent-spaces-common-hook ()
   (setq indent-tabs-mode 'nil))

and then make sure you run this hook for python files.



From stefan at sun.ac.za  Thu Nov  3 09:02:22 2005
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 3 Nov 2005 16:02:22 +0200
Subject: [IPython-dev] magic docstrings
Message-ID: <20051103140222.GA4659@sun.ac.za>

I compiled the iPython docs earlier today, and found some problems in
the generated magic.tex.

One problem is that LaTeX # character is not escaped, which can be
easily fixed:

Index: Magic.py
===================================================================
--- Magic.py    (revision 920)
+++ Magic.py    (working copy)
@@ -264,7 +264,7 @@
         """Format a string for latex inclusion."""

         # Characters that need to be escaped for latex:
-        escape_re = re.compile(r'(%|_|\$)',re.MULTILINE)
+        escape_re = re.compile(r'(%|_|\$|#)',re.MULTILINE)
         # Magic command names as headers:
         cmd_name_re = re.compile(r'^(%s.*?):' % self.shell.ESC_MAGIC,
                                  re.MULTILINE)


The more tricky problem, however, is the use of "\\" in the
docstrings.  In Python, you do not want "\\" in your docstrings, since
they display as "\", but without the "\\" LaTeX won't print a
line-feed.

Then, there are a few "\n" symbols that need to be printed as is.  In
Python, they are correctly escaped as "\\n", but under LaTeX they need
to be "\textbackslash{}n".  I fixed this using

@@ -274,10 +274,14 @@
         # Paragraph continue
         par_re = re.compile(r'\\$',re.MULTILINE)

+        # The "\n" symbol
+        newline_re = re.compile('\\\\n')
+
         str = cmd_name_re.sub(r'\n\\texttt{\\textsl{\\large \1}}:',str)
         str = cmd_re.sub(r'\\texttt{\g<cmd>}',str)
         str = par_re.sub(r'\\\\',str)
         str = escape_re.sub(r'\\\1',str)
+        str = newline_re.sub(r'\\textbackslash{}n',str)
         return str

but you might want to use a more generic solution to, for example,
replace all escaped characters like \n, \t, \b.

Regards
St??fan



From stefan at sun.ac.za  Wed Nov  9 17:07:21 2005
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 10 Nov 2005 00:07:21 +0200
Subject: [IPython-dev] magic docstrings
In-Reply-To: <20051103140222.GA4659@sun.ac.za>
References: <20051103140222.GA4659@sun.ac.za>
Message-ID: <20051109220721.GA20359@rajah>

The problem I mention below is difficult to solve without making use
of some markup.  Markup tends to look ugly, but I think the ReST guys
have a pretty good solution:

http://docutils.sourceforge.net/rst.html

This solves the problem below, since all example blocks will be
clearly identifyable, and can then be processed with a LaTeX filter.

St?fan

On Thu, Nov 03, 2005 at 04:02:22PM +0200, Stefan van der Walt wrote:
> The more tricky problem, however, is the use of "\\" in the
> docstrings.  In Python, you do not want "\\" in your docstrings, since
> they display as "\", but without the "\\" LaTeX won't print a
> line-feed.



From jorgen.stenarson at bostream.nu  Sat Nov 12 06:38:07 2005
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sat, 12 Nov 2005 12:38:07 +0100
Subject: [IPython-dev] wildcard patch
Message-ID: <4375D41F.9070705@bostream.nu>

Hi,

I have discovered a problem with the wildcard functionality.

As it is written now it will only match attributes in an object that are
present in its __dict__, and only if there is no __dict__ for the object 
it builds one by calling dir(object). This means inherited attributes 
will not be visible for objects with a __dict__. Which means there will 
be a mismatch between the results you get using dir(object) compared to 
?object.*

An example of this problem can be found by subclassing dict

In [1]:class test(dict):
    ...:    pass
    ...:

In [2]:x=test(a=1)

In [3]:x
Out[3]:{'a': 1}

Without patch
In [4]:?x.*

With patch
In [4]:?x.*
x.__class__
x.__cmp__
x.__contains__
x.__delattr__
+many more

The attached patch builds the namespace by calling dir on all objects,
this should make the wildcard search more consistent with dir. But the
operation of dir is not well specified and may change between releases 
of python. So if someone feels the operation of ?* should be more well 
defined I'm open to suggestions on how to go about that.

/J?rgen





-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wildcard-patch-20051112
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20051112/61f11125/attachment.ksh>

From Fernando.Perez at colorado.edu  Sun Nov 13 04:32:50 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 13 Nov 2005 02:32:50 -0700
Subject: [IPython-dev] wildcard patch
In-Reply-To: <4375D41F.9070705@bostream.nu>
References: <4375D41F.9070705@bostream.nu>
Message-ID: <43770842.2090801@colorado.edu>

J?rgen Stenarson wrote:
> Hi,
> 
> I have discovered a problem with the wildcard functionality.
> 
> As it is written now it will only match attributes in an object that are
> present in its __dict__, and only if there is no __dict__ for the object 
> it builds one by calling dir(object). This means inherited attributes 
> will not be visible for objects with a __dict__. Which means there will 
> be a mismatch between the results you get using dir(object) compared to 
> ?object.*

Thanks for the patch.  I'll apply a slightly modified version, because dir() 
can actually return non-strings on rare occasions (nasty as it is).  The 
tab-completion code in ipython in fact guards against this situation, which 
we've seen in the wild with wrapped C++ code.

In addition, I'll make the behavior of * honor the flags regarding the display 
of _ and __ names in tab completion.  I think that ipython's mechanisms should 
all be consistent in this regard.

Cheers,

f



From Fernando.Perez at colorado.edu  Sun Nov 13 05:25:06 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 13 Nov 2005 03:25:06 -0700
Subject: [IPython-dev] wildcard patch
In-Reply-To: <43770842.2090801@colorado.edu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
Message-ID: <43771482.2070701@colorado.edu>

Fernando Perez wrote:

> Thanks for the patch.  I'll apply a slightly modified version, because dir() 
> can actually return non-strings on rare occasions (nasty as it is).  The 
> tab-completion code in ipython in fact guards against this situation, which 
> we've seen in the wild with wrapped C++ code.

OK, I committed the patch with these extra safeties in place and some other 
changes.

> In addition, I'll make the behavior of * honor the flags regarding the display 
> of _ and __ names in tab completion.  I think that ipython's mechanisms should 
> all be consistent in this regard.

Scratch this.  I'd forgotten that the * system already has a flag to deal with 
underscores, so I left that alone.

One comment: as I use this system more and more, I'm wondering if we shouldn't 
make the default search be case sensitive.  Python is a case sensitive 
language, so I think that the search should by default match the language.  I 
think it's a good idea to offer the case insensitive alternative, for when you 
really don't know what something may be even vaguely called, but I'm leaning 
towards having this facility more closely follow language defaults.

I haven't committed any changes in thir regard though, so I'll be happy to 
hear opinions.

Cheers,

f



From jorgen.stenarson at bostream.nu  Sun Nov 13 12:12:25 2005
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Sun, 13 Nov 2005 18:12:25 +0100
Subject: [IPython-dev] wildcard patch
In-Reply-To: <43771482.2070701@colorado.edu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu>
Message-ID: <437773F9.6040303@bostream.nu>

Fernando Perez wrote:
...
> One comment: as I use this system more and more, I'm wondering if we 
> shouldn't make the default search be case sensitive.  Python is a case 
> sensitive language, so I think that the search should by default match 
> the language.  I think it's a good idea to offer the case insensitive 
> alternative, for when you really don't know what something may be even 
> vaguely called, but I'm leaning towards having this facility more 
> closely follow language defaults.
> 
> I haven't committed any changes in thir regard though, so I'll be happy 
> to hear opinions.
> 
> Cheers,
> 
> f
> 

I can see your point in having a case sensitive search but I mainly use 
this to look for things I'm not sure about... So at this time I think I 
prefer case insensitive. But perhaps this should be put in ipythonrc as 
an option since this is certainly a matter of taste. But perhaps that 
work should be left for the branch.

/J?rgen



From Fernando.Perez at colorado.edu  Sun Nov 13 15:31:35 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 13 Nov 2005 13:31:35 -0700
Subject: [IPython-dev] wildcard patch
In-Reply-To: <437773F9.6040303@bostream.nu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu>
Message-ID: <4377A2A7.3010603@colorado.edu>

J?rgen Stenarson wrote:
> Fernando Perez wrote:
> ...
> 
>>One comment: as I use this system more and more, I'm wondering if we 
>>shouldn't make the default search be case sensitive.  Python is a case 
>>sensitive language, so I think that the search should by default match 
>>the language.  I think it's a good idea to offer the case insensitive 
>>alternative, for when you really don't know what something may be even 
>>vaguely called, but I'm leaning towards having this facility more 
>>closely follow language defaults.

> 
> I can see your point in having a case sensitive search but I mainly use 
> this to look for things I'm not sure about... So at this time I think I 
> prefer case insensitive. But perhaps this should be put in ipythonrc as 
> an option since this is certainly a matter of taste. But perhaps that 
> work should be left for the branch.

OK, I propose a compromise: I'll change the default behavior to be case 
sensitive, but I'll also make it an ipythonrc option.  That way you can set it 
to your liking from day one, and nothing will change for you, while we get 
what I think is a more 'pythonic' design (it's not just 'foolish consistency' 
either, I actually find it useful to query only for names with specific case 
more often than the insensitive version).

I promise not to commit anything until I actually provide you with the rc 
option, so the system will never default to case-sensitive without giving you 
the option to get the behavior you like.  Since you wrote this to begin with, 
I think it's the least I can do :)

How does that sound?

f



From mantegazza at ill.fr  Mon Nov 14 02:43:54 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Mon, 14 Nov 2005 08:43:54 +0100
Subject: [IPython-dev] wildcard patch
In-Reply-To: <4377A2A7.3010603@colorado.edu>
References: <4375D41F.9070705@bostream.nu> <437773F9.6040303@bostream.nu>
	<4377A2A7.3010603@colorado.edu>
Message-ID: <200511140843.55122.mantegazza@ill.fr>

Le Dimanche 13 Novembre 2005 21:31, Fernando Perez a ?crit :

> OK, I propose a compromise: I'll change the default behavior to be case
> sensitive, but I'll also make it an ipythonrc option.  That way you can
> set it to your liking from day one, and nothing will change for you,
> while we get what I think is a more 'pythonic' design (it's not just
> 'foolish consistency' either, I actually find it useful to query only for
> names with specific case more often than the insensitive version).

It is ok for me (I prefer case sensitive behavior).

Thank's

-- 
   Fr?d?ric



From jorgen.stenarson at bostream.nu  Mon Nov 14 12:28:48 2005
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 14 Nov 2005 18:28:48 +0100
Subject: [IPython-dev] wildcard patch
In-Reply-To: <4377A2A7.3010603@colorado.edu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu>
	<4377A2A7.3010603@colorado.edu>
Message-ID: <4378C950.4060401@bostream.nu>

Fernando Perez wrote:
> I promise not to commit anything until I actually provide you with the 
> rc option, so the system will never default to case-sensitive without 
> giving you the option to get the behavior you like.  Since you wrote 
> this to begin with, I think it's the least I can do :)
> 
> How does that sound?
> 
Sounds good to me

/J?rgen



From Fernando.Perez at colorado.edu  Mon Nov 14 15:02:07 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 14 Nov 2005 13:02:07 -0700
Subject: [IPython-dev] wildcard patch
In-Reply-To: <4378C950.4060401@bostream.nu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu>
	<4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu>
Message-ID: <4378ED3F.8010400@colorado.edu>

J?rgen Stenarson wrote:
> Fernando Perez wrote:
> 
>>I promise not to commit anything until I actually provide you with the 
>>rc option, so the system will never default to case-sensitive without 
>>giving you the option to get the behavior you like.  Since you wrote 
>>this to begin with, I think it's the least I can do :)
>>
>>How does that sound?
>>
> 
> Sounds good to me

OK, glad you like that one.  What comes next is worse :)

I've been working on the wildcard code some, and I started to dislike the 
existing API a little, for consistency/maintainability reasons.  The magic 
functions have an option parsing system based on the stdlib's getopt(), and 
provide uniform unix-like syntax:

%cmd -opt1 -opt2 -opt_with_value=foo  arg1 arg2 ...

Currently, the wildcard system makes up its own unique syntax, using - both 
for options (c/a) and to delete namespaces from the search list.  I really 
don't like special cases such as this, and I apologize for not having thought 
more carefully about this earlier.  I like the functionality a lot, and I 
didn't want  to discourage you from contributing, so I think I didn't pass a 
picky enough comb over the original implementation.

I think we should clean this up a little, even at the cost of introducing 
slightly more verbose syntax.  As the Zen of pyhton says:

Special cases aren't special enough to break the rules.

Here's a patch that begins to implement that.  The docstrings aren't fixed 
yet, the ipythonrc option isn't implemented yet, and I'll work more on your 
code.  But you can test it a little and let me know what you think.  Now 
things are

%psearch [-e exclude1 -s search_add1 -i -a]  PATTERN [TYPESPEC]

So intstead of -/+ you use -e/-s to exclude/search namespaces.

Let me know what you think of this as I rework it...

Cheers,

f
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wildcard_fp.patch
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20051114/25614915/attachment.ksh>

From Fernando.Perez at colorado.edu  Tue Nov 15 03:55:10 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 15 Nov 2005 01:55:10 -0700
Subject: [IPython-dev] wildcard patch
In-Reply-To: <43790148.3030200@bostream.nu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu>
	<4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu>
	<4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu>
Message-ID: <4379A26E.6090300@colorado.edu>

J?rgen Stenarson wrote:

> I'm all for making the psearch follow the ipython convention. I'll test 
> your patch tomorrow.

Don't bother with the patch, please  update SVN.  I had committed some changes 
earlier which inadvertedly broke badly globals handling.  At this point it was 
easier to just finish up and commit than to try to disentangle that earlier 
bad patch (it wasn't all bad, as I needed part of it, but it required refining).

Anwyay, the point is that rather than fight patch problems, I just went ahead 
and finished the wildcard rework.  The only thing missing is probably a 
mention in the Lyx manual; the actual docstrings and code are now in place, as 
well as the ipythonrc support.  Just add this section to your ipythonrc file:

# Wildcard searches - IPython has a system for searching names using
# shell-like wildcards; type %psearch? for details.  This variables sets
# whether by default such searches should be case sensitive or not.  You can
# always override the default at the system command line or the IPython
# prompt.

wildcards_case_sensitive 1


And set the value to 0/1 according to your liking.

Let me know of any problems you encounter.

Cheers,

f



From jorgen.stenarson at bostream.nu  Tue Nov 15 12:53:06 2005
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 15 Nov 2005 18:53:06 +0100
Subject: [IPython-dev] wildcard patch
In-Reply-To: <4379A26E.6090300@colorado.edu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu>
	<4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu>
	<4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu>
	<4379A26E.6090300@colorado.edu>
Message-ID: <437A2082.5010009@bostream.nu>


Fernando Perez wrote:
> 
> Let me know of any problems you encounter.
> 

the new wildcard functionality seems to work ok. However I have found a 
bug that seems to have been introduced with rev 923. If there is an 
alias command that do not define a new alias but only lists them in the 
ipythonrc file then ipython crashes. Like if you just uncomment alias at 
the end of the ipythonrc file, I believe this used to be the default 
some revisions ago. I get the crash on both PC and mac.


/J?rgen



From Fernando.Perez at colorado.edu  Tue Nov 15 13:03:41 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 15 Nov 2005 11:03:41 -0700
Subject: [IPython-dev] wildcard patch
In-Reply-To: <437A2082.5010009@bostream.nu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu>
	<4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu>
	<4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu>
	<4379A26E.6090300@colorado.edu> <437A2082.5010009@bostream.nu>
Message-ID: <437A22FD.4020405@colorado.edu>

J?rgen Stenarson wrote:
> Fernando Perez wrote:
> 
>>Let me know of any problems you encounter.
>>
> 
> 
> the new wildcard functionality seems to work ok. However I have found a 
> bug that seems to have been introduced with rev 923. If there is an 
> alias command that do not define a new alias but only lists them in the 
> ipythonrc file then ipython crashes. Like if you just uncomment alias at 
> the end of the ipythonrc file, I believe this used to be the default 
> some revisions ago. I get the crash on both PC and mac.

OK, thanks for the report.  I'll look into what's going on here tonight.

Cheers,

f



From Fernando.Perez at colorado.edu  Tue Nov 15 15:25:11 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 15 Nov 2005 13:25:11 -0700
Subject: [IPython-dev] wildcard patch
In-Reply-To: <437A22FD.4020405@colorado.edu>
References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu>
	<43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu>
	<4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu>
	<4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu>
	<4379A26E.6090300@colorado.edu> <437A2082.5010009@bostream.nu>
	<437A22FD.4020405@colorado.edu>
Message-ID: <437A4427.8060600@colorado.edu>

Fernando Perez wrote:
> J?rgen Stenarson wrote:

>>the new wildcard functionality seems to work ok. However I have found a 
>>bug that seems to have been introduced with rev 923. If there is an 
>>alias command that do not define a new alias but only lists them in the 
>>ipythonrc file then ipython crashes. Like if you just uncomment alias at 
>>the end of the ipythonrc file, I believe this used to be the default 
>>some revisions ago. I get the crash on both PC and mac.
> 
> 
> OK, thanks for the report.  I'll look into what's going on here tonight.

Fixed in SVN r924.

Cheers,

f



From pythondevdang at lazytwinacres.net  Fri Nov 18 08:06:25 2005
From: pythondevdang at lazytwinacres.net (Daniel 'Dang' Griffith)
Date: Fri, 18 Nov 2005 08:06:25 -0500
Subject: [IPython-dev] Interesting announcement
Message-ID: <6.2.1.2.2.20051118080003.03365010@mail.jencospeed.net>

I've only been following the posts for ipython very passively, but I found 
this announcement interesting, as the subject of chaining several commands 
together has come up on occasion over the years.  It's an interesting 
approach.  It's licensed with GPL; I don't know if this is incompatible 
with the BSD license that IPython uses.  Still, you might consider talking 
with them to see if it could be dual-licensed; I've seen a few things 
lately being released that way.

Announcement:
http://comments.gmane.org/gmane.comp.python.announce/5728
Home page:
http://geophile.com/osh/

     --dang



From Fernando.Perez at colorado.edu  Fri Nov 18 12:23:43 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 18 Nov 2005 10:23:43 -0700
Subject: [IPython-dev] Interesting announcement
In-Reply-To: <6.2.1.2.2.20051118080003.03365010@mail.jencospeed.net>
References: <6.2.1.2.2.20051118080003.03365010@mail.jencospeed.net>
Message-ID: <437E0E1F.2070600@colorado.edu>

Daniel 'Dang' Griffith wrote:
> I've only been following the posts for ipython very passively, but I found 
> this announcement interesting, as the subject of chaining several commands 
> together has come up on occasion over the years.  It's an interesting 
> approach.  It's licensed with GPL; I don't know if this is incompatible 
> with the BSD license that IPython uses.  Still, you might consider talking 
> with them to see if it could be dual-licensed; I've seen a few things 
> lately being released that way.
> 
> Announcement:
> http://comments.gmane.org/gmane.comp.python.announce/5728
> Home page:
> http://geophile.com/osh/

Yes, I had seen this and had a look at it a while ago.  While it looks 
interesting, it's a bit orthogonal to ipython in that in introduces a whole 
new syntax which is not python:

@foo [ shell command ] ^ out ...

@foo is a cluster, not a decorator, [] is used to pass commands, not to 
retrieve sequence/mapping elemnts, etc.  So while I have no doubt that this 
can be very handy for spreading commands over a cluster, it's not really 
python anymore.  Additionally, it is not interactive, but rather a one-shot 
executable (it's a bit strange that the homepage is titled 'Osh - Object 
oriented shell', but the second paragraph starts with 'osh is not a shell').

The chainsaw branch of ipython implements cluster/parallel support, but within 
the ipython framework.  I personally prefer the idea of keeping the full 
python language as is, and providing suitable localized extensions to help 
system interaction, rather than trying to reinvent yet another whole new 
language.  Going that route is ill-advised, IMO, because it requires users to 
learn yet another set of syntax and rules which are orthogonal to those of 
python, and also because it's highly unlikely that you'll do a better job at 
language design than Guido and the whole python community.

Specialized mini-languages do have a place, but they carry a price (time and 
cognitive load, to begin with).  I don't think this is a context where the 
price is worth paying.  In addition, his restriction to non-interactive, 
command-line usage makes the system somewhat limited in my view.  For any 
system where the price of learning is worth paying, you want to be able do do 
complex things.  That inevitably means looping, logic, branching, etc; all 
things that require more than single-line input.

So while I like the core idea of 'piping python objects', I'm not sure that I 
personally would have made the specific implementation decisions of Osh.  For 
that same task (quickly spreading commands to a cluster) I long ago wrote my 
own little (very limited) python script which satisfies my needs.

I am sure that Osh can be very useful, and I really don't want this post to 
sound like I'm bashing it in any way.  I had it bookmarked already, and I'll 
keep an interested eye on its evolution.  I just wanted to provide some clear 
reasons why at this point, I don't see too many points of contact with ipython.

Cheers,

f



From vivian at vdesmedt.com  Sun Nov 27 07:15:51 2005
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sun, 27 Nov 2005 13:15:51 +0100
Subject: [IPython-dev] Debugger patch
Message-ID: <4389A377.1010608@vdesmedt.com>

Fernando,

Few times ago I send to the IPython mailing list a patch proposition 
that in my opinion improve the python debugger usability in the spirit 
of IPython.

 - it make the completion working when IPython run in debugger mode,
 - it colorize Python stack the same way IPython do for Exception stacks,
 - it hide some of the stack level that that do not belong to the script 
being debugged (actually IPython levels not relevant for the developper)

I was wondering if you still think it is worth valuable addition and if 
you plan to merge it into the IPython code?

Since it impact more that one files you could consider the integration 
as a long task.
If it these kind of considerations that slow down the integration of the 
patch I'll be glad to split my patch by feature to make the integration 
process more transparent and less stressful :-)

Tell me if I can help.
Kindest regards,
Vivian.



From mantegazza at ill.fr  Mon Nov 28 05:35:22 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Mon, 28 Nov 2005 11:35:22 +0100
Subject: [IPython-dev] Getting executed code
Message-ID: <200511281135.22399.mantegazza@ill.fr>

Hello,

Is there a way to retreive the currently executed code ? The ipshell.buffer 
contains the code, but in the case of a multiline code, how can I know what 
is the current line executed, in my custom exception handler ?

-- 
   Fr?d?ric



From mantegazza at ill.fr  Tue Nov 29 07:21:57 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Tue, 29 Nov 2005 13:21:57 +0100
Subject: [IPython-dev] IPython prompt delay
Message-ID: <200511291321.57840.mantegazza@ill.fr>

Hello Ferndando,

Is possible to add a short fixed delay before the prompt is printed again, 
after some code has been executed ? Where can I add it in the 0.6.15 
version code ?

Thank's,

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Tue Nov 29 15:08:51 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 29 Nov 2005 13:08:51 -0700
Subject: [IPython-dev] IPython prompt delay
In-Reply-To: <200511291321.57840.mantegazza@ill.fr>
References: <200511291321.57840.mantegazza@ill.fr>
Message-ID: <438CB553.9060405@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Hello Ferndando,
> 
> Is possible to add a short fixed delay before the prompt is printed again, 
> after some code has been executed ? Where can I add it in the 0.6.15 
> version code ?

The prompt system is fully dynamic, so the easiest way is to insert a 
time.sleep() call into your prompt :)

Alternatively, you can override the prompt's display() method, but that's a 
little bit more work.

Cheers,

f



From Fernando.Perez at colorado.edu  Tue Nov 29 15:20:02 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 29 Nov 2005 13:20:02 -0700
Subject: [IPython-dev] Debugger patch
In-Reply-To: <4389A377.1010608@vdesmedt.com>
References: <4389A377.1010608@vdesmedt.com>
Message-ID: <438CB7F2.3080202@colorado.edu>

Hi Vivian,

Vivian De Smedt wrote:
> Fernando,
> 
> Few times ago I send to the IPython mailing list a patch proposition 
> that in my opinion improve the python debugger usability in the spirit 
> of IPython.
> 
>  - it make the completion working when IPython run in debugger mode,
>  - it colorize Python stack the same way IPython do for Exception stacks,
>  - it hide some of the stack level that that do not belong to the script 
> being debugged (actually IPython levels not relevant for the developper)
> 
> I was wondering if you still think it is worth valuable addition and if 
> you plan to merge it into the IPython code?
> 
> Since it impact more that one files you could consider the integration 
> as a long task.
> If it these kind of considerations that slow down the integration of the 
> patch I'll be glad to split my patch by feature to make the integration 
> process more transparent and less stressful :-)

I'll certainly be happy to integrate this into ipython, and splitting it into 
reasonable chunks will help me a lot.  As I mentioned to you, hacking pdb is 
quite unpleasant, so this may take some effort.

The current status with ipython is that we have a fair amount of new things 
sitting in SVN, so at some point I should make a new release.  All new work is 
going to take place on the chainsaw branch, but I plan on picking pieces from 
trunk to put in there rather than refactoring wholesale: this will lead to a 
cleaner design, I hope.  It also means that I'm less worried about keeping the 
current codebase alive for a while, since I won't try to make full merges: the 
new code is being structured very differently, and I'm only pulling the good 
pieces out of the existing one.

For a new release, Ville's patch is still in the queue, along with anything 
you may submit.  I have all of Jorgen's wildcard work already committed, and a 
few more things sitting on my Inbox that need to be looked at and committed as 
well.

So in summary: send it in, but broken into small pieces.  Please keep the 
guidelines from:

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

in mind when you make the patches.  They are simple, and meant to keep all of 
us working on code rather than dealing with patch mixups.

Cheers, and many thanks for the interest in tackling a beast as nasty as  pdb!

f



From Fernando.Perez at colorado.edu  Tue Nov 29 15:22:11 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 29 Nov 2005 13:22:11 -0700
Subject: [IPython-dev] Getting executed code
In-Reply-To: <200511281135.22399.mantegazza@ill.fr>
References: <200511281135.22399.mantegazza@ill.fr>
Message-ID: <438CB873.50409@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Hello,
> 
> Is there a way to retreive the currently executed code ? The ipshell.buffer 
> contains the code, but in the case of a multiline code, how can I know what 
> is the current line executed, in my custom exception handler ?

At that point, you need to use python's exception inspection machinery. 
IPython feeds entire blocks for execution to the interpreter, so it can't know 
at what line the error occurred.  But that information is stored in the 
traceback objects, so you can retrieve it.  Look at ultraTB.py for details of 
how ipython builds that information for display.

Cheers,

f



From mantegazza at ill.fr  Wed Nov 30 03:46:59 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Wed, 30 Nov 2005 09:46:59 +0100
Subject: [IPython-dev] Getting executed code
In-Reply-To: <438CB873.50409@colorado.edu>
References: <200511281135.22399.mantegazza@ill.fr>
	<438CB873.50409@colorado.edu>
Message-ID: <200511300947.00276.mantegazza@ill.fr>

Le Mardi 29 Novembre 2005 21:22, Fernando Perez a ?crit :

> > Is there a way to retreive the currently executed code ? The
> > ipshell.buffer contains the code, but in the case of a multiline code,
> > how can I know what is the current line executed, in my custom
> > exception handler ?
>
> At that point, you need to use python's exception inspection machinery.
> IPython feeds entire blocks for execution to the interpreter, so it can't
> know at what line the error occurred.  But that information is stored in
> the traceback objects, so you can retrieve it.  Look at ultraTB.py for
> details of how ipython builds that information for display.

Ok, thanks.

-- 
   Fr?d?ric



From mantegazza at ill.fr  Wed Nov 30 06:57:32 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Wed, 30 Nov 2005 12:57:32 +0100
Subject: [IPython-dev] IPython prompt delay
In-Reply-To: <438CB553.9060405@colorado.edu>
References: <200511291321.57840.mantegazza@ill.fr>
	<438CB553.9060405@colorado.edu>
Message-ID: <200511301257.33338.mantegazza@ill.fr>

Le Mardi 29 Novembre 2005 21:08, Fernando Perez a ?crit :

> The prompt system is fully dynamic, so the easiest way is to insert a
> time.sleep() call into your prompt :)

You mean like this :

argv = ["-pi1", "${time.sleep(0.2)}PyMAD>>> ",
        "-po", " ",
        "-profile", "pymad"]
ipshell = IPShellEmbed(argv)

It works, but it displays 'None' before PyMAD. It is because time.sleep() 
returns None, I presume. How can I make it return an empty string, 
instead ?

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Wed Nov 30 13:05:58 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 30 Nov 2005 11:05:58 -0700
Subject: [IPython-dev] IPython prompt delay
In-Reply-To: <200511301257.33338.mantegazza@ill.fr>
References: <200511291321.57840.mantegazza@ill.fr>
	<438CB553.9060405@colorado.edu> <200511301257.33338.mantegazza@ill.fr>
Message-ID: <438DEA06.3010106@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Le Mardi 29 Novembre 2005 21:08, Fernando Perez a ?crit :
> 
> 
>>The prompt system is fully dynamic, so the easiest way is to insert a
>>time.sleep() call into your prompt :)
> 
> 
> You mean like this :
> 
> argv = ["-pi1", "${time.sleep(0.2)}PyMAD>>> ",
>         "-po", " ",
>         "-profile", "pymad"]
> ipshell = IPShellEmbed(argv)
> 
> It works, but it displays 'None' before PyMAD. It is because time.sleep() 
> returns None, I presume. How can I make it return an empty string, 
> instead ?

Wrap it:

def mysleep(t):
   time.sleep(t)
   return ''

Cheers,

f