From bussonniermatthias at gmail.com  Tue Feb  2 20:36:58 2016
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Tue, 2 Feb 2016 17:36:58 -0800
Subject: [IPython-dev] IPython 4.1.0 out.
Message-ID: <BD319FE3-672F-42FD-B365-76B70170C68A@gmail.com>

Hello fellow Pythonistas, 

As promised a few days ago, and as we did not get any outstanding bug reports, IPython 4.1.0 is now out !

And, as usual you can upgrade with 

	$ pip install ipython --upgrade

The conda folks should update their recipe shortly in which case you will be able to upgrade using conda, 
the `-y` flag will skip prompting you for confirmation :-P  

	$ conda install ipython -y 

You can see the short list of new features on readthedocs [1]:

	? IPython debugger (IPdb) now supports the number of context lines for the where (and w) commands. The context keyword is also available in various APIs.
	? YouTube video will now show thumbnail when exported to a media that do not support video.
	? Add warning when running ipython <subcommand> when subcommand is deprecated. jupyter should now be used.
	? Code in %pinfo (also known as ??) are now highlighter.
	? %aimport now support module completion
	? ipdb output is now colored ! 
	? Add ability to transpose columns for completion


And the stats[2]:

	We closed 60 issues and merged 148 pull requests,  with 52 authors contributing 468 commits.
	To  compare with the big split (3.x-> 4.0)
	We closed 35 issues and merged 125 pull requests, with 69 authors contributed 1186 commits.

So this is not such a small release. 

We should shortly branch toward a 5.0 that will likely drop some backward compatibility (remove a few shims, deprecated API...etc), 
so stay alert if you are on master. 

Enjoy this release, Thanks
--
Matthias for the IPython team. 

[1] http://ipython.readthedocs.org/en/4.x/whatsnew/version4.html <http://ipython.readthedocs.org/en/4.x/whatsnew/version4.html>
[2] http://ipython.readthedocs.org/en/4.x/whatsnew/github-stats-4.html <http://ipython.readthedocs.org/en/4.x/whatsnew/github-stats-4.html>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160202/a119c8fe/attachment.html>

From fperez.net at gmail.com  Tue Feb  2 22:01:19 2016
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 2 Feb 2016 19:01:19 -0800
Subject: [IPython-dev] IPython 4.1.0 out.
In-Reply-To: <BD319FE3-672F-42FD-B365-76B70170C68A@gmail.com>
References: <BD319FE3-672F-42FD-B365-76B70170C68A@gmail.com>
Message-ID: <CAHAreOrPcAQ9mjEfUxzpeKrPk_j2yPh0k06o7j9Wnz5VH_ZTsQ@mail.gmail.com>

On Tue, Feb 2, 2016 at 5:36 PM, Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> Hello fellow Pythonistas,
>
> As promised a few days ago, and as we did not get any outstanding bug
> reports, IPython 4.1.0 is now out !
>

Thanks so much, Matthias and everyone who contributed. I'm delighted to see
IPython itself continue to grow, even amidst the massive amount of activity
in other areas of the larger Jupyter umbrella :)

Best,

f
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160202/f609005d/attachment.html>

From benjaminrk at gmail.com  Wed Feb  3 14:43:32 2016
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 3 Feb 2016 20:43:32 +0100
Subject: [IPython-dev] [ANN] IPython Parallel 5.0
Message-ID: <CAHNn8BU2H3ggZ7yNLGHn7_8yAQwD4NiNXCoe=MGkOU2=F0xk1g@mail.gmail.com>

We just released IPython Parallel 5.0, check it out:

pip install --upgrade ipyparallel

The highlight of 5.0 is the use of Futures for integration with existing
async tools, and a concurrent.futures-compatible Executor API for IPython
parallel, so it can be dropped in for code using the existing Executor API. See
the demo for details
<https://nbviewer.jupyter.org/github/ipython/ipyparallel/blob/5.0.0/examples/Futures.ipynb>
.

Thanks to Anne Archibald for pushing on the Futures work.

summary of changes
<https://ipyparallel.readthedocs.org/en/5.0.0/changelog.html#id1>

P.S. The main reason for the 5.0 marker is moving some IPython
Parallel-specific code out of the ipykernel repo, so it may not be as
exciting as it sounds. But still, Futures!

-MinRK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160203/b526c121/attachment.html>

From benjaminrk at gmail.com  Wed Feb  3 15:30:43 2016
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 3 Feb 2016 21:30:43 +0100
Subject: [IPython-dev] Moving ipython-dev off of scipy.org
Message-ID: <CAHNn8BXVZ_a0_qtQeBJ2eAPHcHzToHkGwfCZxMcfC0kCS8bKVg@mail.gmail.com>

I just got a bounce notification that my email to ipython-dev was flagged
for coming from a suspected spam server. That server was Gmail. Scipy.org
is also down pretty often, making the list inoperable, sometimes for days.
I think we should end our remaining reliance on it, which I think is only
ipython-dev (and the long-deprecated ipython-user).

Would it be acceptable to move ipython-dev off of scipy.org to Google
Groups? Or consider moving IPython conversation to the existing Jupyter
Google Group; I don't have a strong preference.

The question of preserving the archives has come up, and I don't think
that's a big issue, but we should make sure that we have a link to old
conversations. The archives can remain on scipy.org and/or we can export
them to another host. The archives are also already duplicated to places
like gmane that aren't likely to go away.

-MinRK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160203/b146cc5f/attachment.html>

From markbak at gmail.com  Fri Feb  5 07:06:13 2016
From: markbak at gmail.com (Mark Bakker)
Date: Fri, 5 Feb 2016 13:06:13 +0100
Subject: [IPython-dev] ipywidgets layout broken?
Message-ID: <CAEX=yaZR9nX3-BMmWZwcy+kvcH5GYj7VgKLCOtmkVdHddhFT5w@mail.gmail.com>

Hello list,

Not sure if ipywidgets questions should still be asked here (if not, please
let me know).

I tried to run the Flexbox Layout.ipynb and Widget Layout.ipynb notebooks
from the examples directory and neither of them worked

The Layout class doesn't exist in ipywidgets version 4.1.1.

My version too old or too new?

Thanks,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160205/614b6f6a/attachment.html>

From jon.freder at gmail.com  Fri Feb  5 10:55:41 2016
From: jon.freder at gmail.com (Jonathan Frederic)
Date: Fri, 5 Feb 2016 07:55:41 -0800
Subject: [IPython-dev] ipywidgets layout broken?
In-Reply-To: <CAEX=yaZR9nX3-BMmWZwcy+kvcH5GYj7VgKLCOtmkVdHddhFT5w@mail.gmail.com>
References: <CAEX=yaZR9nX3-BMmWZwcy+kvcH5GYj7VgKLCOtmkVdHddhFT5w@mail.gmail.com>
Message-ID: <CAAoBLw38xB-MCwjCNCC5TPkC6dNPB0ssDvbQTkUCz8LR22i4EQ@mail.gmail.com>

Hi mark!

That version of ipywidgets is too old.  The Layout class only exists in
master (5.0 dev) right now.

You're looking for the 4.1.1 tag on GitHub, you can find that here:
https://github.com/ipython/ipywidgets/tree/4.1.1

Cheers,
Jon

On Fri, Feb 5, 2016 at 4:06 AM, Mark Bakker <markbak at gmail.com> wrote:

> Hello list,
>
> Not sure if ipywidgets questions should still be asked here (if not,
> please let me know).
>
> I tried to run the Flexbox Layout.ipynb and Widget Layout.ipynb notebooks
> from the examples directory and neither of them worked
>
> The Layout class doesn't exist in ipywidgets version 4.1.1.
>
> My version too old or too new?
>
> Thanks,
>
> Mark
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160205/ea94de07/attachment.html>

From akim at lrde.epita.fr  Fri Feb 12 04:14:37 2016
From: akim at lrde.epita.fr (Akim Demaille)
Date: Fri, 12 Feb 2016 10:14:37 +0100
Subject: [IPython-dev] Finding the subcommand names
Message-ID: <43A8A8EF-265B-4C11-8C43-8FF965817E40@lrde.epita.fr>

Hi,

The most recent version of IPython complains when I run `ipython notebook`:

> $ ipython notebook
> [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is deprecated and will be removed in future versions.
> [TerminalIPythonApp] WARNING | You likely want to use `jupyter notebook`... continue in 5 sec. Press Ctrl-C to quit now.

So I obey, but it fails:

> $ jupyter-3.4 notebook
> jupyter: 'notebook' is not a Jupiter command


What?  What are the existing commands?

> $ jupyter-3.4 --help
> usage: jupyter-3.4 [-h] [--version] [--config-dir] [--data-dir]
>                    [--runtime-dir] [--paths] [--json]
>                    [subcommand]
> 
> Jupyter: Interactive Computing
> 
> positional arguments:
>   subcommand     the subcommand to launch
> 
> optional arguments:
>   -h, --help     show this help message and exit
>   --version      show the jupyter command's version and exit
>   --config-dir   show Jupyter config dir
>   --data-dir     show Jupyter data dir
>   --runtime-dir  show Jupyter runtime dir
>   --paths        show all Jupyter paths. Add --json for machine-readable
>                  format.
>   --json         output paths as machine-readable json
> 
> Available subcommands: 3.4 kernelspec-3.4 migrate-3.4 nbconvert-3.4
> nbextension-3.4 notebook-3.4 trust-3.4

Huh, I need that -3.4 extension :(

> $ jupyter-3.4 notebook-3.4
> [I 10:09:00.941 NotebookApp] The port 8888 is already in use, trying another random port.
> [I 10:09:00.942 NotebookApp] The port 8889 is already in use, trying another random port.


But that `ipython notebook` is inside a shell script that I
provide my users with.  So I need something portable.  Hence
the question is: what is the advertised way to know how the
`notebook` command is to be invoked?  Yeah, I can grep and
sed etc. the help message, but that?s really messy.  Besides,
how do I know what conventions are used on other platforms/distros?

That `notebook-3.4` instead of `notebook` is really an additional
complexity I would have liked not to have.

FWIW, IPython/Jupyter were installed via MacPorts.

Cheers!

From steve at holdenweb.com  Fri Feb 12 04:19:15 2016
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 12 Feb 2016 09:19:15 +0000
Subject: [IPython-dev] Finding the subcommand names
In-Reply-To: <43A8A8EF-265B-4C11-8C43-8FF965817E40@lrde.epita.fr>
References: <43A8A8EF-265B-4C11-8C43-8FF965817E40@lrde.epita.fr>
Message-ID: <CAMofdRApVZOSS7dMDmVFSUSsUAzz3jTxF2mvcRfQ-cm3-obZiQ@mail.gmail.com>

I'm not sure quite how you got into the weeds that are currently ensnaring
you, so I will content myself with observing that when I create a new
virtual environment and execute

    pip install jupyter

everything then appears to be ready to make

    jupyter notebook

work perfectly. If you aren't currently using virtual environments then I
would recommend you start immediately.

regards
 Steve

Steve Holden

On Fri, Feb 12, 2016 at 9:14 AM, Akim Demaille <akim at lrde.epita.fr> wrote:

> Hi,
>
> The most recent version of IPython complains when I run `ipython notebook`:
>
> > $ ipython notebook
> > [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is
> deprecated and will be removed in future versions.
> > [TerminalIPythonApp] WARNING | You likely want to use `jupyter
> notebook`... continue in 5 sec. Press Ctrl-C to quit now.
>
> So I obey, but it fails:
>
> > $ jupyter-3.4 notebook
> > jupyter: 'notebook' is not a Jupiter command
>
>
> What?  What are the existing commands?
>
> > $ jupyter-3.4 --help
> > usage: jupyter-3.4 [-h] [--version] [--config-dir] [--data-dir]
> >                    [--runtime-dir] [--paths] [--json]
> >                    [subcommand]
> >
> > Jupyter: Interactive Computing
> >
> > positional arguments:
> >   subcommand     the subcommand to launch
> >
> > optional arguments:
> >   -h, --help     show this help message and exit
> >   --version      show the jupyter command's version and exit
> >   --config-dir   show Jupyter config dir
> >   --data-dir     show Jupyter data dir
> >   --runtime-dir  show Jupyter runtime dir
> >   --paths        show all Jupyter paths. Add --json for machine-readable
> >                  format.
> >   --json         output paths as machine-readable json
> >
> > Available subcommands: 3.4 kernelspec-3.4 migrate-3.4 nbconvert-3.4
> > nbextension-3.4 notebook-3.4 trust-3.4
>
> Huh, I need that -3.4 extension :(
>
> > $ jupyter-3.4 notebook-3.4
> > [I 10:09:00.941 NotebookApp] The port 8888 is already in use, trying
> another random port.
> > [I 10:09:00.942 NotebookApp] The port 8889 is already in use, trying
> another random port.
>
>
> But that `ipython notebook` is inside a shell script that I
> provide my users with.  So I need something portable.  Hence
> the question is: what is the advertised way to know how the
> `notebook` command is to be invoked?  Yeah, I can grep and
> sed etc. the help message, but that?s really messy.  Besides,
> how do I know what conventions are used on other platforms/distros?
>
> That `notebook-3.4` instead of `notebook` is really an additional
> complexity I would have liked not to have.
>
> FWIW, IPython/Jupyter were installed via MacPorts.
>
> Cheers!
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160212/f5a12d74/attachment.html>

From benjaminrk at gmail.com  Fri Feb 12 05:48:54 2016
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 12 Feb 2016 11:48:54 +0100
Subject: [IPython-dev] Finding the subcommand names
In-Reply-To: <43A8A8EF-265B-4C11-8C43-8FF965817E40@lrde.epita.fr>
References: <43A8A8EF-265B-4C11-8C43-8FF965817E40@lrde.epita.fr>
Message-ID: <CAHNn8BVLAozCseu27UR-mKgPGOM1RzVfW8=fuTH6_mA7WUL6KA@mail.gmail.com>

> FWIW, IPython/Jupyter were installed via MacPorts.

This seems the most important bit. Jupyter doesn't add `-X.Y` to its
scripts, so it's probably macports doing this (I don't know how/where they
do this). When you type `jupyter notebook`, that's really just a synonym
for `jupyter-notebook`. MacPorts should really be providing this
executable. If they aren't they may need to ship a patch to Jupyter's
command dispatch to add the version suffix.

If there is a patch to be made, it would be in jupyter_core.command, which
implements the subcommand dispatch. We could conceivably detect a suffix on
the executable and add it to how subcommands are found.

-MinRK


On Fri, Feb 12, 2016 at 10:14 AM, Akim Demaille <akim at lrde.epita.fr> wrote:

> Hi,
>
> The most recent version of IPython complains when I run `ipython notebook`:
>
> > $ ipython notebook
> > [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is
> deprecated and will be removed in future versions.
> > [TerminalIPythonApp] WARNING | You likely want to use `jupyter
> notebook`... continue in 5 sec. Press Ctrl-C to quit now.
>
> So I obey, but it fails:
>
> > $ jupyter-3.4 notebook
> > jupyter: 'notebook' is not a Jupiter command
>
>
> What?  What are the existing commands?
>
> > $ jupyter-3.4 --help
> > usage: jupyter-3.4 [-h] [--version] [--config-dir] [--data-dir]
> >                    [--runtime-dir] [--paths] [--json]
> >                    [subcommand]
> >
> > Jupyter: Interactive Computing
> >
> > positional arguments:
> >   subcommand     the subcommand to launch
> >
> > optional arguments:
> >   -h, --help     show this help message and exit
> >   --version      show the jupyter command's version and exit
> >   --config-dir   show Jupyter config dir
> >   --data-dir     show Jupyter data dir
> >   --runtime-dir  show Jupyter runtime dir
> >   --paths        show all Jupyter paths. Add --json for machine-readable
> >                  format.
> >   --json         output paths as machine-readable json
> >
> > Available subcommands: 3.4 kernelspec-3.4 migrate-3.4 nbconvert-3.4
> > nbextension-3.4 notebook-3.4 trust-3.4
>
> Huh, I need that -3.4 extension :(
>
> > $ jupyter-3.4 notebook-3.4
> > [I 10:09:00.941 NotebookApp] The port 8888 is already in use, trying
> another random port.
> > [I 10:09:00.942 NotebookApp] The port 8889 is already in use, trying
> another random port.
>
>
> But that `ipython notebook` is inside a shell script that I
> provide my users with.  So I need something portable.  Hence
> the question is: what is the advertised way to know how the
> `notebook` command is to be invoked?  Yeah, I can grep and
> sed etc. the help message, but that?s really messy.  Besides,
> how do I know what conventions are used on other platforms/distros?
>
> That `notebook-3.4` instead of `notebook` is really an additional
> complexity I would have liked not to have.
>
> FWIW, IPython/Jupyter were installed via MacPorts.
>
> Cheers!
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160212/b01d4686/attachment.html>

From steve at holdenweb.com  Fri Feb 12 07:08:12 2016
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 12 Feb 2016 12:08:12 +0000
Subject: [IPython-dev] Finding the subcommand names
In-Reply-To: <CAHNn8BVLAozCseu27UR-mKgPGOM1RzVfW8=fuTH6_mA7WUL6KA@mail.gmail.com>
References: <43A8A8EF-265B-4C11-8C43-8FF965817E40@lrde.epita.fr>
 <CAHNn8BVLAozCseu27UR-mKgPGOM1RzVfW8=fuTH6_mA7WUL6KA@mail.gmail.com>
Message-ID: <CAMofdRByTMpsgMcQku3OghHMN3z0K9DBopa4pdHaqHgDF65V9g@mail.gmail.com>

It would seem foolhardy to attempt MacPorts installation of something
that's currently evolving as fast as Jupyter.  S

Steve Holden

On Fri, Feb 12, 2016 at 10:48 AM, MinRK <benjaminrk at gmail.com> wrote:

> > FWIW, IPython/Jupyter were installed via MacPorts.
>
> This seems the most important bit. Jupyter doesn't add `-X.Y` to its
> scripts, so it's probably macports doing this (I don't know how/where they
> do this). When you type `jupyter notebook`, that's really just a synonym
> for `jupyter-notebook`. MacPorts should really be providing this
> executable. If they aren't they may need to ship a patch to Jupyter's
> command dispatch to add the version suffix.
>
> If there is a patch to be made, it would be in jupyter_core.command, which
> implements the subcommand dispatch. We could conceivably detect a suffix on
> the executable and add it to how subcommands are found.
>
> -MinRK
>
>
> On Fri, Feb 12, 2016 at 10:14 AM, Akim Demaille <akim at lrde.epita.fr>
> wrote:
>
>> Hi,
>>
>> The most recent version of IPython complains when I run `ipython
>> notebook`:
>>
>> > $ ipython notebook
>> > [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is
>> deprecated and will be removed in future versions.
>> > [TerminalIPythonApp] WARNING | You likely want to use `jupyter
>> notebook`... continue in 5 sec. Press Ctrl-C to quit now.
>>
>> So I obey, but it fails:
>>
>> > $ jupyter-3.4 notebook
>> > jupyter: 'notebook' is not a Jupiter command
>>
>>
>> What?  What are the existing commands?
>>
>> > $ jupyter-3.4 --help
>> > usage: jupyter-3.4 [-h] [--version] [--config-dir] [--data-dir]
>> >                    [--runtime-dir] [--paths] [--json]
>> >                    [subcommand]
>> >
>> > Jupyter: Interactive Computing
>> >
>> > positional arguments:
>> >   subcommand     the subcommand to launch
>> >
>> > optional arguments:
>> >   -h, --help     show this help message and exit
>> >   --version      show the jupyter command's version and exit
>> >   --config-dir   show Jupyter config dir
>> >   --data-dir     show Jupyter data dir
>> >   --runtime-dir  show Jupyter runtime dir
>> >   --paths        show all Jupyter paths. Add --json for machine-readable
>> >                  format.
>> >   --json         output paths as machine-readable json
>> >
>> > Available subcommands: 3.4 kernelspec-3.4 migrate-3.4 nbconvert-3.4
>> > nbextension-3.4 notebook-3.4 trust-3.4
>>
>> Huh, I need that -3.4 extension :(
>>
>> > $ jupyter-3.4 notebook-3.4
>> > [I 10:09:00.941 NotebookApp] The port 8888 is already in use, trying
>> another random port.
>> > [I 10:09:00.942 NotebookApp] The port 8889 is already in use, trying
>> another random port.
>>
>>
>> But that `ipython notebook` is inside a shell script that I
>> provide my users with.  So I need something portable.  Hence
>> the question is: what is the advertised way to know how the
>> `notebook` command is to be invoked?  Yeah, I can grep and
>> sed etc. the help message, but that?s really messy.  Besides,
>> how do I know what conventions are used on other platforms/distros?
>>
>> That `notebook-3.4` instead of `notebook` is really an additional
>> complexity I would have liked not to have.
>>
>> FWIW, IPython/Jupyter were installed via MacPorts.
>>
>> Cheers!
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160212/d905c90f/attachment.html>

From lkb.teichmann at gmail.com  Mon Feb 15 03:25:28 2016
From: lkb.teichmann at gmail.com (Martin Teichmann)
Date: Mon, 15 Feb 2016 09:25:28 +0100
Subject: [IPython-dev] Metaclasses in traitlets and PEP 487
Message-ID: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>

Hi List,

over a python-ideas, we are currently discussing PEP 487:
https://www.python.org/dev/peps/pep-0487/
This proposal intends to ease the customization of class
creation. Instead of using custom metaclasses the idea is
to have only one metaclass in the standard library or even
in Python itself.

The IPython traitlets are a typical application for this
proposal, and could benefit from that. This is why I
converted traitlets to use a PEP 487 style metaclass and
uploaded it to https://github.com/tecki/traitlets/tree/pep487
It works, all tests pass unmodified in both Python 2 and 3.

Given that PEP 487 was written with projects like
IPython traitlets in mind, I thought I ask on this list whether
there are comments about it.

As a note to the reader, following discussions on
python-ideas, the naming of methods has changed a little
since I last posted PEP 487, so the comments in
https://github.com/tecki/traitlets/blob/pep487/traitlets/utils/metaclass.py
are more accurate. I did not yet start a formal pull request,
as PEP 487 is still discussed and things may still change.

Greetings

Martin


From takowl at gmail.com  Mon Feb 15 07:16:52 2016
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 15 Feb 2016 12:16:52 +0000
Subject: [IPython-dev] Metaclasses in traitlets and PEP 487
In-Reply-To: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>
References: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>
Message-ID: <CAOvn4qg1ykHPq4_S+QLeFt65zH_DKQ4SWnzj4Ze=kNsEZ74sog@mail.gmail.com>

Hi Martin,

Thanks for looking into this - it would be great to avoid maintaining our
own metaclasses in traitlets, and I know that we have somewhere knocking
around a QMetaObjectHasTraits class because of precisely the multiple
inheritance problem that you describe.

Just to check that I understand, if the PEP is accepted, we wouldn't add a
utils.metaclass module to traitlets, but instead use the new SubclassInit
class in the standard library, and an equivalent backport on PyPI for
already released Python versions, right?

Thanks,
Thomas

On 15 February 2016 at 08:25, Martin Teichmann <lkb.teichmann at gmail.com>
wrote:

> Hi List,
>
> over a python-ideas, we are currently discussing PEP 487:
> https://www.python.org/dev/peps/pep-0487/
> This proposal intends to ease the customization of class
> creation. Instead of using custom metaclasses the idea is
> to have only one metaclass in the standard library or even
> in Python itself.
>
> The IPython traitlets are a typical application for this
> proposal, and could benefit from that. This is why I
> converted traitlets to use a PEP 487 style metaclass and
> uploaded it to https://github.com/tecki/traitlets/tree/pep487
> It works, all tests pass unmodified in both Python 2 and 3.
>
> Given that PEP 487 was written with projects like
> IPython traitlets in mind, I thought I ask on this list whether
> there are comments about it.
>
> As a note to the reader, following discussions on
> python-ideas, the naming of methods has changed a little
> since I last posted PEP 487, so the comments in
> https://github.com/tecki/traitlets/blob/pep487/traitlets/utils/metaclass.py
> are more accurate. I did not yet start a formal pull request,
> as PEP 487 is still discussed and things may still change.
>
> Greetings
>
> Martin
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160215/bb7a7d79/attachment.html>

From lkb.teichmann at gmail.com  Mon Feb 15 09:29:44 2016
From: lkb.teichmann at gmail.com (Martin Teichmann)
Date: Mon, 15 Feb 2016 15:29:44 +0100
Subject: [IPython-dev] Metaclasses in traitlets and PEP 487
In-Reply-To: <CAOvn4qg1ykHPq4_S+QLeFt65zH_DKQ4SWnzj4Ze=kNsEZ74sog@mail.gmail.com>
References: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>
 <CAOvn4qg1ykHPq4_S+QLeFt65zH_DKQ4SWnzj4Ze=kNsEZ74sog@mail.gmail.com>
Message-ID: <CAK9R32TXDOuukm5aTb_rs2E7y+2WXuVbd3JLm6kU+MP1+VC=aw@mail.gmail.com>

Hi Thomas,

> Just to check that I understand, if the PEP is accepted, we wouldn't add a
> utils.metaclass module to traitlets, but instead use the new SubclassInit
> class in the standard library, and an equivalent backport on PyPI for
> already released Python versions, right?

This is currently the point of discussion. My current assumption is that
larger projects (like IPython) will certainly want to maintain backwards
compatibility, and are typically hesitant to add new dependencies.

The backport on PyPI will just be one short file which tries to import the
new classes in the standard library, and will fall back to an own
implementation.
One way would then be to add this PyPI package as a dependency to
IPython. Another way would be to simply add that simple file to IPython,
then we have either the backwards compatibility or the compatibility
with other projects (if we did find the standard library classes), but not
both.

The best compromise is probably to put it into a library like six, so that
we have compatibility at least between projects using the same
compatibility library. IPython is not using six, so I just opted for putting
said one file into IPython.

You also mentioned situations in which you want to have compatibility
with C++ extension metaclasses. Those will only be compatible once
our new metaclass makes it into the interpreter proper. That will still
take some time, though.

Greetings

Martin


From takowl at gmail.com  Mon Feb 15 09:47:33 2016
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 15 Feb 2016 14:47:33 +0000
Subject: [IPython-dev] Metaclasses in traitlets and PEP 487
In-Reply-To: <CAK9R32TXDOuukm5aTb_rs2E7y+2WXuVbd3JLm6kU+MP1+VC=aw@mail.gmail.com>
References: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>
 <CAOvn4qg1ykHPq4_S+QLeFt65zH_DKQ4SWnzj4Ze=kNsEZ74sog@mail.gmail.com>
 <CAK9R32TXDOuukm5aTb_rs2E7y+2WXuVbd3JLm6kU+MP1+VC=aw@mail.gmail.com>
Message-ID: <CAOvn4qgZdRaHLnoDQMt9q4D31o_wkDUznM=XMn6X40J119H72g@mail.gmail.com>

On 15 February 2016 at 14:29, Martin Teichmann <lkb.teichmann at gmail.com>
wrote:

> This is currently the point of discussion. My current assumption is that
> larger projects (like IPython) will certainly want to maintain backwards
> compatibility, and are typically hesitant to add new dependencies.
>
> The backport on PyPI will just be one short file which tries to import the
> new classes in the standard library, and will fall back to an own
> implementation.
> One way would then be to add this PyPI package as a dependency to
> IPython. Another way would be to simply add that simple file to IPython,
> then we have either the backwards compatibility or the compatibility
> with other projects (if we did find the standard library classes), but not
> both.
>

I think we'd be OK with adding a small, pure-Python dependency like that.
It seems a bit silly to make a standardised metaclass to facilitate
multiple inheritance, and then make independent incompatible copies of it!

> You also mentioned situations in which you want to have compatibility
with C++ extension metaclasses. Those will only be compatible once our new
metaclass makes it into the interpreter proper. That will still take some
time, though.
Gotcha. I can still see the advantage of reducing the likelihood that
someone else will need that kind of craziness, though.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160215/190ef97a/attachment.html>

From sylvain.corlay at gmail.com  Tue Feb 16 12:06:37 2016
From: sylvain.corlay at gmail.com (Sylvain Corlay)
Date: Tue, 16 Feb 2016 12:06:37 -0500
Subject: [IPython-dev] Metaclasses in traitlets and PEP 487
In-Reply-To: <CAOvn4qgZdRaHLnoDQMt9q4D31o_wkDUznM=XMn6X40J119H72g@mail.gmail.com>
References: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>
 <CAOvn4qg1ykHPq4_S+QLeFt65zH_DKQ4SWnzj4Ze=kNsEZ74sog@mail.gmail.com>
 <CAK9R32TXDOuukm5aTb_rs2E7y+2WXuVbd3JLm6kU+MP1+VC=aw@mail.gmail.com>
 <CAOvn4qgZdRaHLnoDQMt9q4D31o_wkDUznM=XMn6X40J119H72g@mail.gmail.com>
Message-ID: <CAK=Phk7mt2yGhs+uOH8MYGMy75pEiHEg7h-TshFKXKrymvRwDg@mail.gmail.com>

Hi Martin,

Thank you for posting on the list about this. The separation of
`MetaHasDescriptors `in the earlier release was actually meant to
standardize on metaclass implementation that could be used for other
descriptors than trait types, very much in the spirit of you PEP.

My understanding is that the new `__set_owner__` method on the descriptor
exactly corresponds to the `class_init` in our base Descriptor class, that
is the part of the descriptor initialization that depends on the class
(while `instance_init` is the part of the initialization that depends on
the instance). However, it sometimes does a bit more than setting the name
of the owner, like in the case of the default initializers. Hence I was
wondering if the name was accurate. What do you think about simply reusing
`__class_init__`?

Thanks,

Sylvain

On Mon, Feb 15, 2016 at 9:47 AM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 15 February 2016 at 14:29, Martin Teichmann <lkb.teichmann at gmail.com>
> wrote:
>
>> This is currently the point of discussion. My current assumption is that
>> larger projects (like IPython) will certainly want to maintain backwards
>> compatibility, and are typically hesitant to add new dependencies.
>>
>> The backport on PyPI will just be one short file which tries to import the
>> new classes in the standard library, and will fall back to an own
>> implementation.
>> One way would then be to add this PyPI package as a dependency to
>> IPython. Another way would be to simply add that simple file to IPython,
>> then we have either the backwards compatibility or the compatibility
>> with other projects (if we did find the standard library classes), but not
>> both.
>>
>
> I think we'd be OK with adding a small, pure-Python dependency like that.
> It seems a bit silly to make a standardised metaclass to facilitate
> multiple inheritance, and then make independent incompatible copies of it!
>
> > You also mentioned situations in which you want to have compatibility
> with C++ extension metaclasses. Those will only be compatible once our new
> metaclass makes it into the interpreter proper. That will still take some
> time, though.
> Gotcha. I can still see the advantage of reducing the likelihood that
> someone else will need that kind of craziness, though.
>
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160216/1119800a/attachment.html>

From lkb.teichmann at gmail.com  Wed Feb 17 07:56:35 2016
From: lkb.teichmann at gmail.com (Martin Teichmann)
Date: Wed, 17 Feb 2016 13:56:35 +0100
Subject: [IPython-dev] Metaclasses in traitlets and PEP 487
In-Reply-To: <CAK=Phk7mt2yGhs+uOH8MYGMy75pEiHEg7h-TshFKXKrymvRwDg@mail.gmail.com>
References: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>
 <CAOvn4qg1ykHPq4_S+QLeFt65zH_DKQ4SWnzj4Ze=kNsEZ74sog@mail.gmail.com>
 <CAK9R32TXDOuukm5aTb_rs2E7y+2WXuVbd3JLm6kU+MP1+VC=aw@mail.gmail.com>
 <CAOvn4qgZdRaHLnoDQMt9q4D31o_wkDUznM=XMn6X40J119H72g@mail.gmail.com>
 <CAK=Phk7mt2yGhs+uOH8MYGMy75pEiHEg7h-TshFKXKrymvRwDg@mail.gmail.com>
Message-ID: <CAO9LD_Dp5Xz7x9zXx3ww_C7qXZ+Gtcd0i3tSgLhqZuLmDfr6TA@mail.gmail.com>

Hi Sylvain,

> My understanding is that the new `__set_owner__` method on the descriptor exactly corresponds to the `class_init` in our base Descriptor class, that is the part of the descriptor initialization that depends on the class (while `instance_init` is the part of the initialization that depends on the instance). However, it sometimes does a bit more than setting the name of the owner, like in the case of the default initializers. Hence I was wondering if the name was accurate. What do you think about simply reusing `__class_init__`?

There was some discussion on python-ideas about that name.
It is an extension to the descriptor protocol, which already has three
methods: __set__, __get__ and
__delete__. How should we name the new method?

I personally don't like __class_init__, I think it is actually
misleading, as it is called on an object, not a class.
Originally, I had it called __init_descriptor__. Others considered
that misleading, because in the
new metaclass there is also an __init_subclass__, and one might think
that __init_descriptor__ is also
called on the initialized class, but it is called on the descriptor.
This is where the name __set_owner__ came
from, as in __get__ the parameter is called owner. But given that not
only the owner is set, but also the
name of the descriptor, __set_owner__ also might not be the best choice.

Greetings

Martin


From takowl at gmail.com  Wed Feb 17 08:51:14 2016
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 17 Feb 2016 13:51:14 +0000
Subject: [IPython-dev] Metaclasses in traitlets and PEP 487
In-Reply-To: <CAO9LD_Dp5Xz7x9zXx3ww_C7qXZ+Gtcd0i3tSgLhqZuLmDfr6TA@mail.gmail.com>
References: <CAO9LD_B=AL9DjhDUtNUQUZ4QTb5FoHVs=P9G=YF16hcoAEBiKw@mail.gmail.com>
 <CAOvn4qg1ykHPq4_S+QLeFt65zH_DKQ4SWnzj4Ze=kNsEZ74sog@mail.gmail.com>
 <CAK9R32TXDOuukm5aTb_rs2E7y+2WXuVbd3JLm6kU+MP1+VC=aw@mail.gmail.com>
 <CAOvn4qgZdRaHLnoDQMt9q4D31o_wkDUznM=XMn6X40J119H72g@mail.gmail.com>
 <CAK=Phk7mt2yGhs+uOH8MYGMy75pEiHEg7h-TshFKXKrymvRwDg@mail.gmail.com>
 <CAO9LD_Dp5Xz7x9zXx3ww_C7qXZ+Gtcd0i3tSgLhqZuLmDfr6TA@mail.gmail.com>
Message-ID: <CAOvn4qgOkHJqW4Hsht8oO0Pgf3MrLKH1_TdXZ5kfGNQXJCYUzg@mail.gmail.com>

Of the various names mentioned, I like __set_owner__ the best - it may not
be 100% accurate, but it gives me a better idea of what it is than any of
the 'init_blah' names.

Maybe __set_ownership__? 'Ownership' could certainly include 'what does my
owner call me'.

On 17 February 2016 at 12:56, Martin Teichmann <lkb.teichmann at gmail.com>
wrote:

> Hi Sylvain,
>
> > My understanding is that the new `__set_owner__` method on the
> descriptor exactly corresponds to the `class_init` in our base Descriptor
> class, that is the part of the descriptor initialization that depends on
> the class (while `instance_init` is the part of the initialization that
> depends on the instance). However, it sometimes does a bit more than
> setting the name of the owner, like in the case of the default
> initializers. Hence I was wondering if the name was accurate. What do you
> think about simply reusing `__class_init__`?
>
> There was some discussion on python-ideas about that name.
> It is an extension to the descriptor protocol, which already has three
> methods: __set__, __get__ and
> __delete__. How should we name the new method?
>
> I personally don't like __class_init__, I think it is actually
> misleading, as it is called on an object, not a class.
> Originally, I had it called __init_descriptor__. Others considered
> that misleading, because in the
> new metaclass there is also an __init_subclass__, and one might think
> that __init_descriptor__ is also
> called on the initialized class, but it is called on the descriptor.
> This is where the name __set_owner__ came
> from, as in __get__ the parameter is called owner. But given that not
> only the owner is set, but also the
> name of the descriptor, __set_owner__ also might not be the best choice.
>
> Greetings
>
> Martin
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160217/887dfef4/attachment.html>

From vasco+python at tenner.nl  Thu Feb 25 08:58:21 2016
From: vasco+python at tenner.nl (Vasco)
Date: Thu, 25 Feb 2016 14:58:21 +0100
Subject: [IPython-dev] Create new file context menu windows
Message-ID: <56CF087D.7020806@tenner.nl>

Dear all,
I created a small script in order to be able to create a new ipython 
notebook, from windows explorer via the File->New context menu.

https://github.com/vascotenner/ipython-notebook-new-file-windows

Kind regards,
Vasco


From benjaminrk at gmail.com  Thu Feb 25 11:00:49 2016
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 25 Feb 2016 17:00:49 +0100
Subject: [IPython-dev] [ANN] IPython kernel 4.3
Message-ID: <CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA@mail.gmail.com>

We?ve just released 4.3 of the IPython kernel. It has a few compatibility
fixes, but the main change is that all output is published from a
background thread. This fixes a couple of annoying problems:

   1. no more need for those pesky sys.stdout.flush() calls to ensure that
   your print statements show up promptly in long-running cells.
   2. output from subprocesses and threads should get published in a more
   natural order when concurrent with main process output

-MinRK
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160225/cb69061c/attachment.html>

From ellisonbg at gmail.com  Thu Feb 25 13:33:01 2016
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 25 Feb 2016 10:33:01 -0800
Subject: [IPython-dev] [jupyter] [ANN] IPython kernel 4.3
In-Reply-To: <CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA@mail.gmail.com>
References: <CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA@mail.gmail.com>
Message-ID: <CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA@mail.gmail.com>

Awesome work!

On Thu, Feb 25, 2016 at 8:00 AM, MinRK <benjaminrk at gmail.com> wrote:
> We?ve just released 4.3 of the IPython kernel. It has a few compatibility
> fixes, but the main change is that all output is published from a background
> thread. This fixes a couple of annoying problems:
>
> no more need for those pesky sys.stdout.flush() calls to ensure that your
> print statements show up promptly in long-running cells.
> output from subprocesses and threads should get published in a more natural
> order when concurrent with main process output
>
> -MinRK
>
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+unsubscribe at googlegroups.com.
> To post to this group, send email to jupyter at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com


From jon.freder at gmail.com  Thu Feb 25 16:38:38 2016
From: jon.freder at gmail.com (Jonathan Frederic)
Date: Thu, 25 Feb 2016 13:38:38 -0800
Subject: [IPython-dev] Create new file context menu windows
In-Reply-To: <56CF087D.7020806@tenner.nl>
References: <56CF087D.7020806@tenner.nl>
Message-ID: <CAAoBLw1EbEp40+QJBCgMLtdP59p+21Ezva7r5aSEZP4sXM6NyA@mail.gmail.com>

Cool!  Thanks Vasco

On Thu, Feb 25, 2016 at 5:58 AM, Vasco <vasco+python at tenner.nl> wrote:

> Dear all,
> I created a small script in order to be able to create a new ipython
> notebook, from windows explorer via the File->New context menu.
>
> https://github.com/vascotenner/ipython-notebook-new-file-windows
>
> Kind regards,
> Vasco
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160225/649bdba1/attachment.html>

From kikocorreoso at gmail.com  Fri Feb 26 04:59:38 2016
From: kikocorreoso at gmail.com (Kiko)
Date: Fri, 26 Feb 2016 10:59:38 +0100
Subject: [IPython-dev] How to know if code is executing in a rich display
	(qtconsole or notebook)
Message-ID: <CAB-sx60PhOzs_v5KJFmR_B6qLp6dVmozqy4msAknCM-4Yb4zWQ@mail.gmail.com>

Hi all,

Is there a sane way to know if some code is executing in a rich display
environment like the qtconsole or the notebook?

I think the following could work:

try:
    from ipykernel.zmqshell import ZMQInteractiveShell
    ip = get_ipython()
    rich_display = isinstance(ip, ZMQInteractiveShell)
except:
    rich_display = False

Thanks!!

Best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160226/523434cf/attachment.html>

From benjaminrk at gmail.com  Fri Feb 26 05:33:56 2016
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 26 Feb 2016 11:33:56 +0100
Subject: [IPython-dev] How to know if code is executing in a rich
 display (qtconsole or notebook)
In-Reply-To: <CAB-sx60PhOzs_v5KJFmR_B6qLp6dVmozqy4msAknCM-4Yb4zWQ@mail.gmail.com>
References: <CAB-sx60PhOzs_v5KJFmR_B6qLp6dVmozqy4msAknCM-4Yb4zWQ@mail.gmail.com>
Message-ID: <CAHNn8BUFnm2f1N4KX5M7AexvPJHfnWTGbsO_cgtzY+an2wfYhQ@mail.gmail.com>

You can check if it?s running in a kernel with:

try:
    get_ipython().kernelexcept AttributeError:
    # not a kernelelse:
    # a kernel

-MinRK
?

On Fri, Feb 26, 2016 at 10:59 AM, Kiko <kikocorreoso at gmail.com> wrote:

> Hi all,
>
> Is there a sane way to know if some code is executing in a rich display
> environment like the qtconsole or the notebook?
>
> I think the following could work:
>
> try:
>     from ipykernel.zmqshell import ZMQInteractiveShell
>     ip = get_ipython()
>     rich_display = isinstance(ip, ZMQInteractiveShell)
> except:
>     rich_display = False
>
> Thanks!!
>
> Best.
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160226/26593d1b/attachment.html>

From kikocorreoso at gmail.com  Fri Feb 26 05:38:14 2016
From: kikocorreoso at gmail.com (Kiko)
Date: Fri, 26 Feb 2016 11:38:14 +0100
Subject: [IPython-dev] How to know if code is executing in a rich
 display (qtconsole or notebook)
In-Reply-To: <CAHNn8BUFnm2f1N4KX5M7AexvPJHfnWTGbsO_cgtzY+an2wfYhQ@mail.gmail.com>
References: <CAB-sx60PhOzs_v5KJFmR_B6qLp6dVmozqy4msAknCM-4Yb4zWQ@mail.gmail.com>
 <CAHNn8BUFnm2f1N4KX5M7AexvPJHfnWTGbsO_cgtzY+an2wfYhQ@mail.gmail.com>
Message-ID: <CAB-sx627grgnw9N+u0q=hJYnyaQVYmLaQz1svScLTPcWnDLTnQ@mail.gmail.com>

Thanks!!

2016-02-26 11:33 GMT+01:00 MinRK <benjaminrk at gmail.com>:

> You can check if it?s running in a kernel with:
>
> try:
>     get_ipython().kernelexcept AttributeError:
>     # not a kernelelse:
>     # a kernel
>
> -MinRK
> ?
>
> On Fri, Feb 26, 2016 at 10:59 AM, Kiko <kikocorreoso at gmail.com> wrote:
>
>> Hi all,
>>
>> Is there a sane way to know if some code is executing in a rich display
>> environment like the qtconsole or the notebook?
>>
>> I think the following could work:
>>
>> try:
>>     from ipykernel.zmqshell import ZMQInteractiveShell
>>     ip = get_ipython()
>>     rich_display = isinstance(ip, ZMQInteractiveShell)
>> except:
>>     rich_display = False
>>
>> Thanks!!
>>
>> Best.
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160226/85c43450/attachment.html>

From fperez.net at gmail.com  Fri Feb 26 11:49:06 2016
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 26 Feb 2016 16:49:06 +0000
Subject: [IPython-dev] [jupyter] [ANN] IPython kernel 4.3
In-Reply-To: <CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA@mail.gmail.com>
References: <CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA@mail.gmail.com>
 <CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA@mail.gmail.com>
Message-ID: <CAHAreOopfFx2m+WJcoKoygNSKHEMDJzT7Smcbu21gtu+pWp2gg@mail.gmail.com>

Indeed, many thanks!

On Thu, Feb 25, 2016, 12:33 Brian Granger <ellisonbg at gmail.com> wrote:

> Awesome work!
>
> On Thu, Feb 25, 2016 at 8:00 AM, MinRK <benjaminrk at gmail.com> wrote:
> > We?ve just released 4.3 of the IPython kernel. It has a few compatibility
> > fixes, but the main change is that all output is published from a
> background
> > thread. This fixes a couple of annoying problems:
> >
> > no more need for those pesky sys.stdout.flush() calls to ensure that your
> > print statements show up promptly in long-running cells.
> > output from subprocesses and threads should get published in a more
> natural
> > order when concurrent with main process output
> >
> > -MinRK
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Project Jupyter" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to jupyter+unsubscribe at googlegroups.com.
> > To post to this group, send email to jupyter at googlegroups.com.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/jupyter/CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA%40mail.gmail.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Brian E. Granger
> Associate Professor of Physics and Data Science
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgranger at calpoly.edu and ellisonbg at gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+unsubscribe at googlegroups.com.
> To post to this group, send email to jupyter at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160226/d53bae46/attachment.html>

From bussonniermatthias at gmail.com  Fri Feb 26 13:28:54 2016
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Fri, 26 Feb 2016 10:28:54 -0800
Subject: [IPython-dev] [jupyter] [ANN] IPython kernel 4.3
In-Reply-To: <CAHAreOopfFx2m+WJcoKoygNSKHEMDJzT7Smcbu21gtu+pWp2gg@mail.gmail.com>
References: <CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA@mail.gmail.com>
 <CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA@mail.gmail.com>
 <CAHAreOopfFx2m+WJcoKoygNSKHEMDJzT7Smcbu21gtu+pWp2gg@mail.gmail.com>
Message-ID: <9B14741F-7E88-42C5-A42B-88108B46A53C@gmail.com>

Hi all, 

Min pushed 4.3.1 a few hours a go that fix a critical bug on windows[1]. 


-- 
M

[1]: https://github.com/ipython/ipykernel/issues/107
> On Feb 26, 2016, at 08:49, Fernando Perez <fperez.net at gmail.com> wrote:
> 
> Indeed, many thanks!
> 
> 
> On Thu, Feb 25, 2016, 12:33 Brian Granger <ellisonbg at gmail.com <mailto:ellisonbg at gmail.com>> wrote:
> Awesome work!
> 
> On Thu, Feb 25, 2016 at 8:00 AM, MinRK <benjaminrk at gmail.com <mailto:benjaminrk at gmail.com>> wrote:
> > We?ve just released 4.3 of the IPython kernel. It has a few compatibility
> > fixes, but the main change is that all output is published from a background
> > thread. This fixes a couple of annoying problems:
> >
> > no more need for those pesky sys.stdout.flush() calls to ensure that your
> > print statements show up promptly in long-running cells.
> > output from subprocesses and threads should get published in a more natural
> > order when concurrent with main process output
> >
> > -MinRK
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Project Jupyter" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to jupyter+unsubscribe at googlegroups.com <mailto:jupyter%2Bunsubscribe at googlegroups.com>.
> > To post to this group, send email to jupyter at googlegroups.com <mailto:jupyter at googlegroups.com>.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/jupyter/CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA%40mail.gmail.com <https://groups.google.com/d/msgid/jupyter/CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA%40mail.gmail.com>.
> > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> 
> 
> 
> --
> Brian E. Granger
> Associate Professor of Physics and Data Science
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgranger at calpoly.edu <mailto:bgranger at calpoly.edu> and ellisonbg at gmail.com <mailto:ellisonbg at gmail.com>
> 
> --
> You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscribe at googlegroups.com <mailto:jupyter%2Bunsubscribe at googlegroups.com>.
> To post to this group, send email to jupyter at googlegroups.com <mailto:jupyter at googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA%40mail.gmail.com <https://groups.google.com/d/msgid/jupyter/CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA%40mail.gmail.com>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscribe at googlegroups.com <mailto:jupyter+unsubscribe at googlegroups.com>.
> To post to this group, send email to jupyter at googlegroups.com <mailto:jupyter at googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAHAreOopfFx2m%2BWJcoKoygNSKHEMDJzT7Smcbu21gtu%2BpWp2gg%40mail.gmail.com <https://groups.google.com/d/msgid/jupyter/CAHAreOopfFx2m%2BWJcoKoygNSKHEMDJzT7Smcbu21gtu%2BpWp2gg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160226/38b8acd2/attachment.html>

From rgbkrk at gmail.com  Fri Feb 26 14:40:48 2016
From: rgbkrk at gmail.com (Kyle Kelley)
Date: Fri, 26 Feb 2016 13:40:48 -0600
Subject: [IPython-dev] [jupyter] [ANN] IPython kernel 4.3
In-Reply-To: <9B14741F-7E88-42C5-A42B-88108B46A53C@gmail.com>
References: <CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA@mail.gmail.com>
 <CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA@mail.gmail.com>
 <CAHAreOopfFx2m+WJcoKoygNSKHEMDJzT7Smcbu21gtu+pWp2gg@mail.gmail.com>
 <9B14741F-7E88-42C5-A42B-88108B46A53C@gmail.com>
Message-ID: <CA+tbMaV0=WzCJ=rbGc66=dzdaUY_zNUUd++T8ygKRkA52_C7ng@mail.gmail.com>

This is so good. No longer having to flush output is really helpful in a
few notebooks I'm working in.

On Fri, Feb 26, 2016 at 12:28 PM, Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> Hi all,
>
> Min pushed 4.3.1 a few hours a go that fix a critical bug on windows[1].
>
>
> --
> M
>
> [1]: https://github.com/ipython/ipykernel/issues/107
>
> On Feb 26, 2016, at 08:49, Fernando Perez <fperez.net at gmail.com> wrote:
>
> Indeed, many thanks!
>
> On Thu, Feb 25, 2016, 12:33 Brian Granger <ellisonbg at gmail.com> wrote:
>
>> Awesome work!
>>
>> On Thu, Feb 25, 2016 at 8:00 AM, MinRK <benjaminrk at gmail.com> wrote:
>> > We?ve just released 4.3 of the IPython kernel. It has a few
>> compatibility
>> > fixes, but the main change is that all output is published from a
>> background
>> > thread. This fixes a couple of annoying problems:
>> >
>> > no more need for those pesky sys.stdout.flush() calls to ensure that
>> your
>> > print statements show up promptly in long-running cells.
>> > output from subprocesses and threads should get published in a more
>> natural
>> > order when concurrent with main process output
>> >
>> > -MinRK
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Project Jupyter" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to jupyter+unsubscribe at googlegroups.com.
>> > To post to this group, send email to jupyter at googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/jupyter/CAHNn8BVSa_eMsH0HgsXmL5VKfJSUjhE6bE4Uh_mzc-eEjOYviA%40mail.gmail.com
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Brian E. Granger
>> Associate Professor of Physics and Data Science
>> Cal Poly State University, San Luis Obispo
>> @ellisonbg on Twitter and GitHub
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Project Jupyter" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jupyter+unsubscribe at googlegroups.com.
>> To post to this group, send email to jupyter at googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jupyter/CAH4pYpQVc4G_ZHr8FuxiZrh3k25C-SdAiozWKoWL-u9L4W9WPA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+unsubscribe at googlegroups.com.
> To post to this group, send email to jupyter at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/CAHAreOopfFx2m%2BWJcoKoygNSKHEMDJzT7Smcbu21gtu%2BpWp2gg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jupyter/CAHAreOopfFx2m%2BWJcoKoygNSKHEMDJzT7Smcbu21gtu%2BpWp2gg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+unsubscribe at googlegroups.com.
> To post to this group, send email to jupyter at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/9B14741F-7E88-42C5-A42B-88108B46A53C%40gmail.com
> <https://groups.google.com/d/msgid/jupyter/9B14741F-7E88-42C5-A42B-88108B46A53C%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kyle Kelley (@rgbkrk <https://twitter.com/rgbkrk>; lambdaops.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20160226/573a355e/attachment.html>