Git Product home page Git Product logo

ipython / ipython Goto Github PK

View Code? Open in Web Editor NEW
16.1K 749.0 4.4K 76.66 MB

Official repository for IPython itself. Other repos in the IPython organization contain things like the website, documentation builds, etc.

Home Page: https://ipython.readthedocs.org

License: BSD 3-Clause "New" or "Revised" License

Python 72.09% Makefile 0.13% Shell 0.35% Jupyter Notebook 27.41% Batchfile 0.01%
ipython jupyter data-science notebook python repl closember hacktoberfest spec-0

ipython's Introduction

image

image

image

image

image

image

IPython: Productive Interactive Computing

Overview

Welcome to IPython. Our full documentation is available on ipython.readthedocs.io and contains information on how to install, use, and contribute to the project. IPython (Interactive Python) is a command shell for interactive computing in multiple programming languages, originally developed for the Python programming language, that offers introspection, rich media, shell syntax, tab completion, and history.

IPython versions and Python Support

Starting after IPython 8.16, we will progressively transition to Spec-0000.

Starting with IPython 7.10, IPython follows NEP 29

IPython 7.17+ requires Python version 3.7 and above.

IPython 7.10+ requires Python version 3.6 and above.

IPython 7.0 requires Python version 3.5 and above.

IPython 6.x requires Python version 3.3 and above.

IPython 5.x LTS is the compatible release for Python 2.7. If you require Python 2 support, you must use IPython 5.x LTS. Please update your project configurations and requirements as necessary.

The Notebook, Qt console and a number of other pieces are now parts of Jupyter. See the Jupyter installation docs if you want to use these.

Main features of IPython

Comprehensive object introspection.

Input history, persistent across sessions.

Caching of output results during a session with automatically generated references.

Extensible tab completion, with support by default for completion of python variables and keywords, filenames and function keywords.

Extensible system of ‘magic’ commands for controlling the environment and performing many tasks related to IPython or the operating system.

A rich configuration system with easy switching between different setups (simpler than changing $PYTHONSTARTUP environment variables every time).

Session logging and reloading.

Extensible syntax processing for special purpose situations.

Access to the system shell with user-extensible alias system.

Easily embeddable in other Python programs and GUIs.

Integrated access to the pdb debugger and the Python profiler.

Development and Instant running

You can find the latest version of the development documentation on readthedocs.

You can run IPython from this directory without even installing it system-wide by typing at the terminal:

$ python -m IPython

Or see the development installation docs for the latest revision on read the docs.

Documentation and installation instructions for older version of IPython can be found on the IPython website

IPython requires Python version 3 or above

Starting with version 6.0, IPython does not support Python 2.7, 3.0, 3.1, or 3.2.

For a version compatible with Python 2.7, please install the 5.x LTS Long Term Support version.

If you are encountering this error message you are likely trying to install or use IPython from source. You need to checkout the remote 5.x branch. If you are using git the following should work:

$ git fetch origin
$ git checkout 5.x

If you encounter this error message with a regular install of IPython, then you likely need to update your package manager, for example if you are using pip check the version of pip with:

$ pip --version

You will need to update pip to the version 9.0.1 or greater. If you are not using pip, please inquiry with the maintainers of the package for your package manager.

For more information see one of our blog posts:

https://blog.jupyter.org/release-of-ipython-5-0-8ce60b8d2e8e

As well as the following Pull-Request for discussion:

#9900

This error does also occur if you are invoking setup.py directly – which you should not – or are using easy_install If this is the case, use pip install . instead of setup.py install , and pip install -e . instead of setup.py develop If you are depending on IPython as a dependency you may also want to have a conditional dependency on IPython depending on the Python version:

install_req = ['ipython']
if sys.version_info[0] < 3 and 'bdist_wheel' not in sys.argv:
    install_req.remove('ipython')
    install_req.append('ipython<6')

setup(
    ...
    install_requires=install_req
)

Alternatives to IPython

IPython may not be to your taste; if that's the case there might be similar project that you might want to use:

Ignoring commits with git blame.ignoreRevsFile

As of git 2.23, it is possible to make formatting changes without breaking git blame. See the git documentation for more details.

To use this feature you must:

  • Install git >= 2.23
  • Configure your local git repo by running:
    • POSIX: tools\configure-git-blame-ignore-revs.sh
    • Windows: tools\configure-git-blame-ignore-revs.bat

ipython's People

Contributors

barrywark avatar bfroehle avatar bollwyvl avatar carreau avatar damianavila avatar doerwalter avatar ellisonbg avatar fperez avatar gaelvaroquaux avatar ivanov avatar jasongrout avatar jdfreder avatar jhamrick avatar jstenar avatar juliantaylor avatar kojoley avatar krassowski avatar minrk avatar mrmino avatar rgbkrk avatar rkern avatar sgaist avatar shaperilio avatar srinivasreddy avatar ssanderson avatar sylvaincorlay avatar takluyver avatar tkf avatar vivainio avatar zsailer avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ipython's Issues

CrashHandler doesn't inspect modules properly

Original Launchpad bug 515652: https://bugs.launchpad.net/ipython/+bug/515652
Reported by: ellisonbg (Brian Granger).

If I make Magic an object and look at the crash reporter I see things like:

   global The = undefined
   global Component = <class 'IPython.core.component.Component'>
   global subclass = undefined
   global that = undefined
   instance = undefined
   global will = undefined
   global   = undefined
   global to = undefined
   global be. = undefined

The variables here are not in Python code but are words from a
docstring in that module.
Any idea on what is going on here?

Is it by any chance being loaded at runtime and the file may have
changed since you started ipython? The python inspection libraries
have caching bugs, I try in several places to flush those caches to
avoid this problem, but I may not be doing it right everywhere.

This is old, old, horrible code I hacked very early on in ipython's
life on top of something I hadn't written and that was pretty bad to
begin with. It's in serious need of a test suite so it can be
refactored...

At least as a pointer, the machinery responsible is around here:

http://bazaar.launchpad.net/%7Efdo.perez/ipython/trunk-dev/annotate/head%3A/IPython/core/ultratb.py#L788

So what's happening is that the list of 'unique names' being generated
is for some reason being computed from the wrong line of code, so text
from a docstring is read instead of text from the proper line of
source that originated the exception.

Sorry not to be more helpful, this is something that needs a solid
chunk of deep work at some point, not something we can clear quickly
(the refactoring I mean, this little bug might be fixable with a
one-line change somewhere).

Include improvements from anythingipython.el

Original Launchpad bug 405582: https://bugs.launchpad.net/ipython/+bug/405582
Reported by: fdo.perez (Fernando Perez).

At: http://mercurial.intuxication.org/hg/anythingipython/summary

there is a little Emacs module with fixes for ipython.el and what appear to be other improvements. We should contact its author, listed as

Thierry Volpiatto - thierry.volpiatto AT gmail.com

to inquire whether he'd be interested in contributing this code upstream (i.e. with us). As it currently stands his code is GPL'd but it's a tiny module on top of ipython.el itself (which is BSD), so hopefully the author will be amenable to relicensing it as BSD so its changes can be merged back with ipython proper.

generics.complete_object broken

Original Launchpad bug 527968: https://bugs.launchpad.net/ipython/+bug/527968
Reported by: dsdale24 (Darren Dale).

generics.complete_object appears to be broken in the trunk (0.11alpha). It keeps returning TryNext in situations where it should not. As a result, it is proving to be very difficult to support some custom completers with the forthcoming ipython-0.11:

In [12]: generics.complete_object('foo', dir('foo'))
---------------------------------------------------------------------------
TryNext                                   Traceback (most recent call last)

/Users/darren/Projects/phynx.git/<ipython console> in <module>()

/Users/darren/Projects/ipython/IPython/external/simplegeneric.pyc in dispatch(*args, **kw)
     73                 f = _gbt(t, _sentinel)
     74                 if f is not _sentinel:
---> 75                     return f(*args, **kw)
     76             else:
     77                 return func(*args, **kw)

/Users/darren/Projects/ipython/IPython/utils/generics.pyc in complete_object(obj, prev_completions)
     60     own_attrs + prev_completions.
     61     """
---> 62     raise TryNext
     63
     64

TryNext:

Getting "DeadReferenceError: Calling Stale Broker" after ipcontroller restart

Original Launchpad bug 308253: https://bugs.launchpad.net/ipython/+bug/308253
Reported by: vvatsa (Vishal Vatsa).

Not Sure that is a bug or an expected behavior.

I am starting the ipcontoller such that it reuses the ipcontroller-tc.furl between restarts.
After the restart, if I invoke a DeadReferenceError with the following traceback:
I am using the blocking TaskClient from an ipython shell.

In [8]: tc.spin()

DeadReferenceError Traceback (most recent call last)

/home/vishal/ in ()

/usr/lib/python2.5/site-packages/IPython/kernel/taskclient.pyc in spin(self)
119 scheduler is idle for some reason.
120 """
--> 121 return blockingCallFromThread(self.task_controller.spin)
122
123 def queue_status(self, verbose=False):

/usr/lib/python2.5/site-packages/IPython/kernel/twistedutil.pyc in blockingCallFromThread(f, _a, *_kw)
67 @raise: any error raised during the callback chain.
68 """
---> 69 return twisted.internet.threads.blockingCallFromThread(reactor, f, _a, *_kw)
70
71 else:

/usr/lib/python2.5/site-packages/twisted/internet/threads.pyc in blockingCallFromThread(reactor, f, _a, *_kw)
81 result = queue.get()
82 if isinstance(result, failure.Failure):
---> 83 result.raiseException()
84 return result
85

/usr/lib/python2.5/site-packages/twisted/python/failure.pyc in raiseException(self)
317 information if available.
318 """
--> 319 raise self.type, self.value, self.tb
320
321

DeadReferenceError: Calling Stale Broker

Robust readline support on OS X's builtin Python

Original Launchpad bug 254023: https://bugs.launchpad.net/ipython/+bug/254023
Reported by: seanj-xyke (Sean Jensen-Grey).

Re-edited 9/25/2008,

Short:

The bug contains a description and a solution for getting readline to work reliably on the mac. The solution outlined recommends shipping the egg for readline with ipython and installing it in site-packages. Optionally modifying the ipython.py script to contain a reference to the egg.

See below.


With a default source install of IPython 0.8.4, typing code into the ipython shell is a little frustrating since I cannot use the tab key to indent code.

Even with the -noreadline option used when starting ipython, the tab key will not emit a tab or spaces in the ipython shell.

I understand that readline support on OS X 10.5 is provided by libedit which does not have the same functionality as gnureadline.

And that by installing gnu readline I get the behavior I want.

And that there is an install guide @ http://ipython.scipy.org/moin/InstallationOSXLeopard

It would seem to me that the usability of ipython on the mac under leopard is pretty flawed due to poor readline implementation (out of the box). At least with how IPython interacts with it.

A couple possibilities to remedy this would be:

  1. Rather than say that libedit was detected, say something along the lines of

(only on darwin and if libedit was detected ...)

"""

The libedit replacement for gnu readline was detected on your mac.

IPython needs gnu readline to function optimally. Using the tab key to indent code
will not work without it.

Please install pyreadline for osx. Or modify the ipython script itself.

see, http://pypi.python.org/pypi/readline/2.5.1

"""

  1. Ship the pyreadline.egg with the tar.gz of the source, during setup if they are using darwin, include the egg and modify the ipython start script.

My new start script looks like

import sys
sys.path.insert( 0, '/Users/sean/python/readline-2.5.1-py2.5-macosx-10.5-fat.egg')

import IPython.Shell
IPython.Shell.start().mainloop()

And it works great. I just had to download the egg from pypi and add it to my sys.path, INFRONT of everything else.pur

Adding in pyreadline support on the mac would only take 360k of extra space, it would save an extra configuration step. The setup command purveyed on blogs and on the OSX install page failed with a gcc error on my machine (new leopard 10.5.2 install with latest xcode tools).

I think shipping a binary egg that only ipython used would be best solution.

%store raises exception when storing compiled regex

Original Launchpad bug 396351: https://bugs.launchpad.net/ipython/+bug/396351
Reported by: tmp-ipython (matt_ipython).

> import re
> compiled_re = re.compile(r'^(\d+)')
> %store compiled_re

AttributeError: __class__

The object "compiled_re" does in fact get pickled and is automatically restored when ipython is next launched. But code to print out user feedback is assuming that the object being stored has an attribute "class", which a compiled regular expression does not have.

I'm not sure if there is a reliable way to always get equivalent of the "name" attribute for all objects or not. In the couple cases I tried however (including for the compiled_re object), replacing:

obj.class.name

with

type(obj).name

worked. I would think that doing something like this which is not necessarily 100% reliable should be inside of a try/except block.

I'm new to iPython as of today. I'm running version "0.10.bzr.r1163".

find_job_cmd is too hasty to fail on Windows

Original Launchpad bug 503903: https://bugs.launchpad.net/ipython/+bug/503903
Reported by: ellisonbg (Brian Granger).

The find_job_cmd function at line 565 of launcher.py fails on line 560 when the Windows HPC stuff is not installed.
But find_job_cmd is called at import (always), so it fails.

We should probably just return 'job' if find_cmd('job') fails.

This is only used on Windows.

def find_job_cmd():
if os.name=='nt':
return find_cmd('job')
else:
return 'job'

Better dependency handling for test suite

Original Launchpad bug 508970: https://bugs.launchpad.net/ipython/+bug/508970
Reported by: fdo.perez (Fernando Perez).

This bug is a follow-up of:

https://bugs.launchpad.net/ipython/+bug/362142

which is now closed and split into several more specific reports. See the above for extra background.

The main point of this ticket is best summarized by Brian here:

It is still super easy for a single developer to break the test suite by making their new module depend on something (twisted, wx, etc.). For that dev, they always have the dep. installed, so they never see the failure, so all their new tests will run fine. This is particularly insidious (still) for twisted because iptest does not have a clean way of declaring test dependencies and run methods for individual files.

We are trying to do this by subpackage, but that is quite inflexible - what if only a single file in a subpackage depends on twisted - then the rest of the subpackage can't be tested using nose.

We need a simple, declarative API for "declaring" the testing related information on a per subpackage or per module basis. This includes:

  • Dependencies
  • Method of running the test (nose+iptest/trial)
  • Thing like "test this subpackage this way, but these two modules are different" We run into this with frontend, which uses twisted in a few places, but not everywhere.

Decide when to use Term and when to print

Original Launchpad bug 514613: https://bugs.launchpad.net/ipython/+bug/514613
Reported by: ellisonbg (Brian Granger).

Currently in IPython.core we sometimes use IPython.utils.io.Term to print and sometimes we just do print. The advantage of using Term is that it will properly handle colors on Windows. But we don't use it everywhere. Really, we need to come up with a uniform way of handling printing to stdout/stderr in IPython. This is particularly relevant as we refactor the core to be used without a terminal.

Merge history from multiple sessions

Original Launchpad bug 296113: https://bugs.launchpad.net/ipython/+bug/296113
Reported by: fdo.perez (Fernando Perez).

This is a feature request from SageDays11.

Add an option for the history from multiple sessions to be merged into one, rather than the current behavior (last session to quit overwrites the file).

The idea would be to have each session periodically save its own history to a common file. Caveat: since now the history file would be shared by multiple sessions, parts of ipython that checkpoint and restore to the history file should restore from a private per-session file rather than the checkpointed one.

This should be probably off by default, since it significantly changes the history behavior and many users may not want it.

stderr missing in IPython + Emacs + WinXP

Original Launchpad bug 237204: https://bugs.launchpad.net/ipython/+bug/237204
Reported by: jietang86 (Jie Tang).

WinXP Pro SP2
Emacs 22.1
ipython.el
python-mode.el

stderr doesn't show up when using IPython with ipython.el inside Emacs.

e.g.:

In [2]: from sys import stderr,stdout

In [3]: stdout.write('\nfoo\n')

foo

In [4]: stderr.write('\nbar\n')

In [5]:

It seems like sys.stderr has some buffering issues; if I flush the stream using stderr.flush() after writing to it the text displays.

In [6]: stderr.flush()

bar

In [7]:

As a workaround I added calls to

Term.cout.flush()
Term.cerr.flush()

right before IPython's "In[]" input prompt is displayed (around line 1675 in iplib.py)

dreload produces spurious traceback when numpy is involved

Original Launchpad bug 306805: https://bugs.launchpad.net/ipython/+bug/306805
Reported by: fdo.perez (Fernando Perez).

Original report by Robin on the ipython user list is below.

I see the problem by using dreload(), but I can't reproduce it by manually calling the pieces of the code that break in that traceback. Will need to investigate further; there's a slim chance it's a problem in numpy's machinery that tries to detect that it's being imported from the build directory.

Original report:

From: Robin [email protected]
Date: Fri, Dec 5, 2008 at 10:12 AM
Subject: [IPython-user] dreload numpy - source dir error
To: "[email protected]" [email protected]

Hi,

I thought I had seen this come up but I can't find it - so sorry if it has...

I have an error using dreload with numpy... I get the error about
importing numpy in the source directory whenever I try to dreload
something that uses numpy. For the most part it does seem to work (I'm
not changing numpy - its my own code I'm trying to dreload) but the
long trace back is a bit annoying because it breaks the list of
results when scrolling through the history...

Anyway here is an example:

robin-mbp:amaripool robince$ ipython
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
Type "copyright", "credits" or "license" for more information.

IPython 0.9.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import numpy
In [2]: reload numpy
------> reload(numpy)
Out[2]: 
In [3]: dreload numpy
------> dreload(numpy)
Reloading numpy
Reloading numpy.numpy
Reloading numpy.show
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/Users/robince/phd/amaripool/ in ()

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ipython-0.9.1-py2.5.egg/IPython/deep_reload.pyc
in reload(module, exclude)
   179     __builtin__.__import__ = deep_import_hook
   180     try:
--> 181         ret = deep_reload_hook(module)
   182     finally:
   183         __builtin__.__import__ = original_import

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ipython-0.9.1-py2.5.egg/IPython/deep_reload.pyc
in deep_reload_hook(module)
   157     name = module.__name__
   158     if '.' not in name:
--> 159         return import_module(name, name, None)
   160     i = name.rfind('.')
   161     pname = name[:i]

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ipython-0.9.1-py2.5.egg/IPython/deep_reload.pyc
in import_module(partname, fqname, parent)
   145
   146     try:
--> 147         m = imp.load_module(fqname, fp, pathname, stuff)
   148     finally:
   149         if fp: fp.close()

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/__init__.pyc
in ()
   119         its source directory; please exit the numpy source
tree, and relaunch
   120         your python intepreter from there."""
--> 121         raise ImportError(msg)
   122     from version import version as __version__
   123

ImportError: Error importing numpy: you should not try to import numpy from
       its source directory; please exit the numpy source tree, and relaunch
       your python intepreter from there.

Cheers

Robin

ipcluster does not start all the engines

Original Launchpad bug 509015: https://bugs.launchpad.net/ipython/+bug/509015
Reported by: fdo.perez (Fernando Perez).

As reported on the mailing list...

---------- Forwarded message ----------
From: Toby Burnett tburnett@EMAIL-REMOVED
Date: Sat, Jan 16, 2010 at 8:58 AM
Subject: [IPython-user] ipcluster does not start all the engines
To: "[email protected]" [email protected]

Hi,
I did not find any previous notes on this.
I have a cluster of 4 machines, each with 8 hyperthreaded cores, so I can run 16 engines per machine, or 64 in all. It is amazingly easy and useful, thanks so much for providing this.

However, when using ipcluster on one of these machines in ssh mode, with this clusterfile,
send_furl = False
engines = { 'tev1' : 16,
'tev2' : 16,
'tev3' : 16,
'tev4' : 16
}

I typically get about 50 engines to actually start. Since there seems to be no log file for ipcluster (in spite of code that seems like it should record which engines it tried to start), I can't send that. The ipcontroller log file looks fine, except for recording fewer than the 64 engines that I expected.

I have an alternative, very klugy method that starts a controller, then executes 64 ssh commands to the respective machines to simply run ipengine. I found the same problem, which went away when I introduced a 1 second delay after each ssh call, which of course takes more than a minute to run, and leaves all those ssh processes running.

So I suspect that the same thing would work in the loop in this method of ipcluster.SSHEngineSet

def _ssh_engine(self, hostname, count):
exec_engine = "ssh %s sh %s/%s-sshx.sh %s" % (
hostname, self.temp_dir,
os.environ['USER'], self.engine_command
)
cmds = exec_engine.split()
dlist = []
log.msg("about to start engines...")
for i in range(count):
log.msg('Starting engines: %s' % exec_engine)
d = getProcessOutput(cmds[0], cmds[1:], env=os.environ)
dlist.append(d)
return gatherBoth(dlist, consumeErrors=True)

but that would be inelegant, given that the real problem is probably related to the controller not responding properly to multiple requests.

Thanks for looking at this.

--Toby Burnett

Support in readline bash's operate-and-get-next behavior

Original Launchpad bug 382638: https://bugs.launchpad.net/ipython/+bug/382638
Reported by: fdo.perez (Fernando Perez).

This was reported as a wishlist item from the Sage developers, below is the full conversation.

It is a wishlist item for a type of history behavior that GNU readline doesn't offer by default but that is very appreciated by users of Magma (which behaves in this form). From communications by the readline maintainer, apparently this can be implemented client-side, so in principle ipython could offer it, though at this point I don't know how to (haven't looked into it in any detail).

Python's readline does offer the necessary hook:

In [2]: readline.*hook*?
readline.__subclasshook__
readline.set_completion_display_matches_hook
readline.set_pre_input_hook
readline.set_startup_hook   # this one

Original email from sage-dev follows:

---------- Forwarded message ----------
From: Kwankyu [email protected]
Date: Thu, May 28, 2009 at 5:03 PM
Subject: [sage-devel] A command line feature - operate and get next history line
To: sage-devel [email protected]

Hi,

I got a reply from GNU readline maintainer Chet Ramey to the following

wish letter.

Dear Readline Maintainer,

I am a user of Sage, a computer algebra system relying on GNU readline
library. In Sage FAQ, you can find the following article. (Magma is
another computer algebra system relying on "readline" via IPython)

  1. Why is Sage's command history different than Magma's
  • QUESTION: Using Sage, I am missing a feature of Magma command
    line interface. In Magma, if I enter a line found in history using up
    arrow key, and then press down arrow key, then the next line in
    history is fetched. This feature allows me to fetch as many successive
    lines in history as like. Does Sage(or readline) have a similar
    feature?
  • ANSWER: No, Sage does not have a similar feature. The IPython
    command prompt uses the readline library (via pyreadline), which
    evidently doesn't support this feature. Magma has its own custom
    "readline-like" library, which does support this feature. (Since so
    many people have requested this feature, if anybody can figure out how
    to implement it, then such an implementation would certainly be
    welcome!)

It seems that the only way Sage can have the convenient feature is
that GNU readline library have such a feature in its history facility.
I wish this happens in the new version of the GNU readline library.

Thank you for your attention. Have a nice day.

From Chet Ramey:

The answer is that this is very similar to the operate-and-get-next
feature bash adds to the readline interface. I am not inclined to add this to
readline in its current form because it manipulates state managed by
the calling application (rl_startup_hook) and requires that state to be
kept between calls to readline(). It's a feature that should be provided

by the calling application -- it's implementation is not complicated.

Issues in magic_whos code

Original Launchpad bug 509043: https://bugs.launchpad.net/ipython/+bug/509043
Reported by: gokhansever (Gokhan Sever).

1-) In .../IPython/core/magic.py looking at the magic_whos code:

You still mention of Numeric. Shouldn't these instances be cleared both in code and documentation providing that you drop support for Python 2.4 and below?

2-) Lines 966-967 in magic.py:

        # for these types, show len() instead of data:
        seq_types = [types.DictType,types.ListType,types.TupleType]

with a sample code:

In [18]: ll = range(10)

In [19]: whos
Variable   Type                Data/Info
----------------------------------------
a          InteractiveShell    
b          NoneType            None
ll           list                       [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

From this, either the comment or the output of the whos needs to be updated.

Python version: 0.11.bzr.r1346
Platform info : os.name -> posix, sys.platform -> linux2
: Linux-2.6.31.9-174.fc12.i686.PAE-i686-with-fedora-12-Constantine
Python info : 2.6.2 (r262:71600, Aug 21 2009, 12:22:21) [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)]

Line entry edge case error

Original Launchpad bug 290981: https://bugs.launchpad.net/ipython/+bug/290981
Reported by: speijnik (Stephan Peijnik).

This bug came in via bugs.debian.org and I am forwarding it to you as it seems to be an IPython issue. The Debian bug in question is http://bugs.debian.org/473018.
Could you please have a look at the bug report and comment on it? This problem seems to also affect IPython 0.9.1 which I am currently packaging for Debian.

The original problem description can be found below.

Regards,

Stephan

-- original problem description --
Interactively entering the following, allowing ipython
to automatically provide indentation:

def a(b):
  b()
 return True

causes an indentation error (as expected). I press "up"
to retrieve the history, and go back to add in the
additional space before "return". Pressing enter causes:

NameError: name 'e' is not defined

Weirder still: if True is replaced with 'q' and some value
is assigned to the variable q, ipython returns that value
as the next "out" result. Find transcript below.

The "call" b() appears to not matter (it can be replaced
with other code, for instance "b=b").

redefining stdout in imported module breaks cmdprompt on windows

Original Launchpad bug 383554: https://bugs.launchpad.net/ipython/+bug/383554
Reported by: techtonik (anatoly techtonik).

When import the module that redefines stdout, the colorful IPython prompt breaks (pyreadline is at 1.5), although other colors work in error messages.

Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.9.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from yyy import xxx

☺←[0;32m☻In [☺←[1;32m☻2☺←[0;32m☻]: ☺←[0m☻

☺←[0;32m☻In [☺←[1;32m☻3☺←[0;32m☻]: ☺←[0m☻some strange command
------------------------------------------------------------
   File "<ipython console>", line 1
     some strange command
                ^
SyntaxError: invalid syntax


☺←[0;32m☻In [☺←[1;32m☻4☺←[0;32m☻]: ☺←[0m☻

-- cut xxx.py ---

import sys

class restdout:
    def __init__(self, fp):
        self.fp = fp

    def write(self, s):
        self.fp.write(s)

sys.stdout = restdout(sys.stdout)

IPython.kernel.client cannot be imported inside an engine

Original Launchpad bug 300218: https://bugs.launchpad.net/ipython/+bug/300218
Reported by: dejan-igi (Dejan Pecevski).

Importing IPython.kernel.client in an engine doesn't work.
The twisted reactor is started for the controller and engine
automatically when they start and for the client when
IPython.kernel.client is imported. The problem is that when executing import
IPython.kernel.client script in the engine, the engine already has the reactor running,
and the import tries to start the reactor again. This causes
a the ipengine<->ipcontroller communication to fail on
subsequently executed commands.

A typical use case when one needs to import IPython.kernel.client in the
engines, is when one wants to use one of the engines as a client connected
to another ipcontroller, and it seems impossible to do it,
if one cannot import the client in one of the engines.

wx frontend don't display well commands output

Original Launchpad bug 345610: https://bugs.launchpad.net/ipython/+bug/345610
Reported by: laurent-dufrechou (Laurent Dufrechou).

There must be locale error for commands taht goes throught process under VISTA SP1 french:

!dir ->

Le volume dans le lecteur C n'a pas de nom.
Le num‚ro de s‚rie du volume est 1860-8F8E

R‚pertoire de C:\Users\ldufrechou\Desktop\Ipython-dev\test\ipython-sync-frontend-retweaks\IPython\frontend\wx

19/03/2009 21:57 .
19/03/2009 21:57 ..
19/03/2009 21:55 20ÿ691 console_widget.py
19/03/2009 21:57 15ÿ647 console_widget.pyc
19/03/2009 21:56 5ÿ754 ipythonx.py
19/03/2009 21:55 20ÿ476 wx_frontend.py
19/03/2009 21:57 18ÿ174 wx_frontend.pyc
19/03/2009 21:55 0 init.py
6 fichier(s) 80ÿ742 octets
2 R‚p(s) 1ÿ123ÿ250ÿ176 octets libres

Ctrl-C with -gthread on Windows, causes uncaught IOError

Original Launchpad bug 412353: https://bugs.launchpad.net/ipython/+bug/412353
Reported by: fdo.perez (Fernando Perez).

The proposed fix is, in Shell.py
try:
update_tk(self.tk)
self.IP.runcode()
time.sleep(0.01)
return True
except IOError:
return True

See for details:
http://mail.scipy.org/pipermail/ipython-dev/2009-August/005407.html

Note that with the new inputhook work, this may become completely unnecessary. But still, if we ever put out an 0.10.1 bugfix release on the 0.10 series, this fix should go in.

Create a daily build PPA for ipython

Original Launchpad bug 417969: https://bugs.launchpad.net/ipython/+bug/417969
Reported by: fdo.perez (Fernando Perez).

Once our trunk stabilizes some, we should offer a daily PPA to make it easy for interested users to follow our tree.

Some useful links and references:

https://code.edge.launchpad.net/~fta/+junk/ppa-confs
https://code.edge.launchpad.net/~fta/+junk/ppa-scripts
https://wiki.ubuntu.com/DailyBuilds
http://castrojo.wordpress.com/2009/08/21/making-daily-builds/

unicode bug - encoding input

Original Launchpad bug 339642: https://bugs.launchpad.net/ipython/+bug/339642
Reported by: vsevolod-solovyov (Murkt).

Default Python shell:

u'абвгд'
u'\u0430\u0431\u0432\u0433\u0434'

IPython 0.9.1:

u'абвгд'
u'\xd0\xb0\xd0\xb1\xd0\xb2\xd0\xb3\xd0\xb4'
'абвгд'.decode('utf8')
u'\u0430\u0431\u0432\u0433\u0434'

sys.stdin.encoding is 'UTF-8'.

How to fix: remove the line №2022 from IPython/iplib.py (for 0.9.1 release). Here it is:

--- a/iplib.py
+++ b/iplib.py
@@ -2019,7 +2019,6 @@
# this allows execution of indented pasted code. It is tempting
# to add '\n' at the end of source to run commands like ' a=1'
# directly, but this fails for more complicated scenarios

  •    source=source.encode(self.stdin_encoding)
     if source[:1] in [' ', '\t']:
         source = 'if 1:\n%s' % source
    

I didn't find any intoduced bugs by a quick check.

Additionaly, I checked ipython-wx and ipythonx - latter doesn't have this bug.

Add Robert Kern's run_examples magic

Original Launchpad bug 409633: https://bugs.launchpad.net/ipython/+bug/409633
Reported by: fdo.perez (Fernando Perez).

From a discussion on the scipy-dev list, starting here:

http://mail.scipy.org/pipermail/scipy-dev/2009-August/012486.html

Robert went ahead and implemented it as a magic using the new demo improvements:

http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/kernmagic/file/c18f492e9688/kernmagic/mymagics.py

We should fold these into ipython itself.

Improve robustness and debuggability of test suite

Original Launchpad bug 508971: https://bugs.launchpad.net/ipython/+bug/508971
Reported by: fdo.perez (Fernando Perez).

This bug is a follow-up of:

https://bugs.launchpad.net/ipython/+bug/362142

which is now closed and split into several more specific reports. See the above for extra background.

The main points brought up by Brian:

Our test suite is still quite fragile and difficult to debug when things go wrong (case in point, your recent bug report about the history being dumped to the screen). If we can get the dpendency issues worked out (to isolate twisted and nose) I think most of this fragility is localized to the nose extension that handles the one time IPython shell. I think our test infrastructure has to be completely independent of our main IPython code (the testing infrastucture should never do "from IPython import ...").

At some point, we figured out how we could enable the writing of IPython doctests without the nose extension (do you remember how this can be done?). As I remember we talked about using this idea along with pexpect to isolate the running IPython to another process.

Jorgen noted:

I think using pexpect requires some research if you want to keep the the
tests running on windows.

Brian's reply:
Yes, this is a huge problem - pexpect doesn't work on Windows...

We should check with the Sage folks, I know at one point, they were working on a windows port of pexpect called wexpect.

Twisted does have many of the same capabilities that pexpect has for working with external processes. That might be our best bet.

IPython should follow the XDG Base Directory spec for configuration

Original Launchpad bug 409277: https://bugs.launchpad.net/ipython/+bug/409277
Reported by: bernd-sch (Bernd Schlapsi).

Could IPython please follow the XDG Base Directory Specification for the configuration/data directory on linux.

more infos here:

I am using:
python 2.6.2
ipython 0.9.1
Ubuntu 9.04 with latest updates

%clear should also delete _NN references and Out[NN] ones

Original Launchpad bug 412350: https://bugs.launchpad.net/ipython/+bug/412350
Reported by: fdo.perez (Fernando Perez).

We need a few things regarding variable/namespace clearing:

  • A 'hard reset' that really nukes _NN, Out[NN], _, __, ___ and all other references we create behind the user's back.
  • Visible name reset: what %reset does today.
  • Integration of %reset and %clear in a nice, unified interface for cleaning various parts of the things we cache. Users shouldn't have to know about these two.

I'm making this high (but not critical) importance because it is a problem that keeps coming back on the mailing lists.

Case insensitive Tab completion

Original Launchpad bug 362568: https://bugs.launchpad.net/ipython/+bug/362568
Reported by: andrea-riciputi (Andrea Riciputi).

Nowadays many Python packages have classes and/or methods that can be both lower and upper case. Being able to get autocompletion suggestion in a case insensitive way could be really usefull to many IPython users. I'm talking about something similar to what you get in most modern shells, where you get file completion no matter the file name case. Something that works like this:

Foo.a[TAB][TAB]
Foo.amethod Foo.AnotherMethod

if the user types "m" she gets Foo.amethod, whilst if she types "n" she gets Foo.AnotherMethod

Thomas Heller suggested to hack the attr_matches() and global_matches() methods in completer.py (see the patch below). I think a better solution would be a new configuration option (let say tab_case = True|False) to be set in the ipython_rc.py file. I'm sorry, but I don't know IPython internals enough to be able to be more specific. However I think this feature could be a usefull improvement to many IPython users.

non-blocking pendingResult partial results

Original Launchpad bug 462980: https://bugs.launchpad.net/ipython/+bug/462980
Reported by: unpingco (Jose Unpingco).

When I do a non-blocking pendingResult, how can I check how many are actually done? in other words, doing

In[10]: pr.get_result()

locks up if there is even one result that is not completed yet. Is it possible to do something that would collect the results, if they are available, and not lock up on whichever of the engines that are not done yet?

readline in OS X does not have correct key bindings

Original Launchpad bug 516716: https://bugs.launchpad.net/ipython/+bug/516716
Reported by: ben-j-schiller (thesylex).

I'm using OS X 10.5.8, and have installed Python 2.6.4 (not using the built-in version). I have confirmed the same problem with OS X 10.6.2. I compiled iPython 0.10 against Python 2.6.4, and the following keys do not work: home, end, page up page down (for history searching), ctrl/esc + left/right for word navigation.

Here's a fix (for default ipythonrc)

readline_parse_and_bind "\e[1~": beginning-of-line
readline_parse_and_bind "\e[4~": end-of-line
readline_parse_and_bind "\e[5~": history-search-backward
readline_parse_and_bind "\e[6~": history-search-forward
readline_parse_and_bind "\e[5C": forward-word
readline_parse_and_bind "\e[5D": backward-word
readline_parse_and_bind "\e\e[C": forward-word
readline_parse_and_bind "\e\e[D": backward-word

These are the standard key bindings and should be compatible with all *nix systems (someone please test linux). Note that these are not the standard OS X key bindings in Terminal, but should be compatible with them. In particular, Terminal uses shift+page up/down instead of page up/down for the escape codes I used. I gave the forward/backword-word bindings for OS X and linux. Home/end are simply disabled in Terminal by default and people will have to fix that themselves.

Also, the implementation in ipython of up/down for history searching is non-standard. I recommend using page up/down as I have it here, and changing up/down to use all of history. I can see by the comments that people have already complained about this....

The tests in test_process fail under Windows

Original Launchpad bug 266923: https://bugs.launchpad.net/ipython/+bug/266923
Reported by: ellisonbg (Brian Granger).

All the tests in test_process.py fail in some way or another on Windows.

test_capture_out and test_kill: fail on Vista when iptest is run using the shortcut in the Start Menu. The error is realted to Windows permissions. But, they pass when iptest is run from the command line.

test_io: fails always on Windows. Something related to how the string are quoted.

Misc. problems in our Sphinx based docs

Original Launchpad bug 413776: https://bugs.launchpad.net/ipython/+bug/413776
Reported by: ellisonbg (Brian Granger).

I am observing multple problems with the Sphinx based documentation. I am using the 0.11 trunk and Sphinx 0.6.2. We need to go through our docs and probably do the following:

  • Update all of our extensions to the latest version from matplotlib, etc.
  • Fix all the errors we are having with our api docs.

Here are some of the actual errors:
1.

WARNING: extension 'ipython_console_highlighting' has no setup() function; is it really a Sphinx extension module?

/Users/bgranger/Documents/Computation/IPython/Code/inputhook/docs/sphinxext/docscrape.py:117: UserWarning: Unknown section Options
warn("Unknown section %s" % key)

  1. When reading sources, Sphinx gives MANY (WARNING/2) errors about problems with our module docstrings.
  2. Then we get lots of these:

(WARNING/2) toctree references unknown document u'api/generated/generated/IPython.config.api'

checking consistency... /Users/bgranger/Documents/Computation/IPython/Code/inputhook/docs/source/api/generated/gen.txt:: WARNING: document isn't included in any toctree
done

cPickle works in standard interpreter, but not in IPython

Original Launchpad bug 363115: https://bugs.launchpad.net/ipython/+bug/363115
Reported by: reckoner (reckoner).

For example in IPython:

class Mylist(list):
     def __init__(self,x=[]):
          list.__init__(self,x)

from cPickle import dumps
w=Mylist([1,2,3])
dumps(w)

PicklingError: Can't pickle <class '__main__.Mylist'>: attribute
lookup __main__.Mylist failed

However, using the standard Python interpreter:

 Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from cPickle import dumps
 >>> class Mylist(list):
 ...         def __init__(self,x=[]):
 ...             list.__init__(self,x)
 ...
 >>> w=Mylist([1,2,3])
 >>> dumps(w)
 'ccopy_reg\n_reconstructor\np1\n(c__main__\nMylist\np2\nc__builtin__\nlist\np3\n
 (lp4\nI1\naI2\naI3\natRp5\n.'
 >>>

In-place %editing of methods

Original Launchpad bug 561693: https://bugs.launchpad.net/ipython/+bug/561693
Reported by: fdo.perez (Fernando Perez).

By Robert Kern on the dev-list

It just occurred to me that someone could write a very useful magic for editing
methods and functions in-place. The following is a loose sketch to record my
thoughts in public.

Workflow:

You think you have a problem with a particular method. You use Foo.bar?? to view
its source. You realize that you need a print statement somewhere in there. What
to do?!

Solution:

%inplace Foo.bar

This will inspect the source for just the method and open it in your editor.
When you are finished, it will create a new module object with an ad hoc name
(maybe inplace_.py) with a corresponding fake entry in the linecache
for tracebacks and future %inplaces. The globals dict is populated with the
entries from the method object's globals dict (.im_func.func_globals) in order
to ensure that you have the appropriate global referents (be sure to fix the
file entry to the ad hoc name). If the new function needs extra imports or
other module-level functions, that's fine (untested). No new methods, though.

Execute the code in this module's namespace. Extract the function object by
name. If the original is a method, look up the class and assign the new function
object to it. If the original is a function, look up the module and assign it.
None of this is particularly difficult or problematic. Only when you need to
edit whole classes and adjust living objects to use the new type do you run into
difficulties. There are solutions on PyPI, but they are larger and more
error-prone than we probably care for.

%inplace should keep a record of these modifications. Many of them are going to
be throwaway debugging things, but some will be genuine modifications that
should be propagated into the actual source code. A SQLite database in
~/.ipython/ is a nice, robust location to keep them. Upon exit, IPython should
print out the final versions of the modified functions. Additionally, you can
have a couple of --options for %inplace that let you view/clean up the database
instead of editing something. For bonus points, generate a unified diff against
the actual files.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.