From carl.input at gmail.com Fri Feb 3 16:38:24 2017 From: carl.input at gmail.com (Carl Smith) Date: Fri, 3 Feb 2017 21:38:24 +0000 Subject: [IPython-dev] Problem with I-Search when Using IPython in VSCode's Integrated Terminal Message-ID: Hi, I was just trying out VSCode, Microsoft's open source editor. It's pretty nice and has an integrated terminal emulator. The terminal works fine with a regular bash shell, but whenever I use IPython there, it has this weird issue where it opens I-Search after almost every input. If I enter `ls` say, it prints the directory contents, then the prompt jumps to the bottom of the screen, where an `I-Search:` prompt appears. It doesn't happen with IPython in a regular terminal emulator, only with IPython in VSCode. It makes IPython unusable there. Sorry if this is the wrong place to ask about this. Can anyone help me get rid of it? -- Carl Smith carl.input at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sat Feb 4 06:37:57 2017 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 4 Feb 2017 11:37:57 +0000 Subject: [IPython-dev] Problem with I-Search when Using IPython in VSCode's Integrated Terminal In-Reply-To: References: Message-ID: Hi Carl, No idea what's going wrong there. Feel free to open an issue on IPython to try to work it out. Thomas On 3 February 2017 at 21:38, Carl Smith wrote: > Hi, > > I was just trying out VSCode, Microsoft's open source editor. It's pretty > nice and has an integrated terminal emulator. The terminal works fine with > a regular bash shell, but whenever I use IPython there, it has this weird > issue where it opens I-Search after almost every input. If I enter `ls` > say, it prints the directory contents, then the prompt jumps to the bottom > of the screen, where an `I-Search:` prompt appears. It doesn't happen with > IPython in a regular terminal emulator, only with IPython in VSCode. It > makes IPython unusable there. > > Sorry if this is the wrong place to ask about this. Can anyone help me get > rid of it? > > -- Carl Smith > carl.input at gmail.com > > _______________________________________________ > 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: From carl.input at gmail.com Sat Feb 4 13:31:56 2017 From: carl.input at gmail.com (Carl Smith) Date: Sat, 04 Feb 2017 18:31:56 +0000 Subject: [IPython-dev] Problem with I-Search when Using IPython in VSCode's Integrated Terminal In-Reply-To: References:

Message-ID: Thanks Thomas. I'll see if I can figure it out first. Just thought it was worth asking here, as I was at a loss, and it's one of those things that are hard to search for on Google. Cheers, On Sat, 4 Feb 2017 11:38 Thomas Kluyver, wrote: > Hi Carl, > > No idea what's going wrong there. Feel free to open an issue on IPython to > try to work it out. > > Thomas > > On 3 February 2017 at 21:38, Carl Smith wrote: > > Hi, > > I was just trying out VSCode, Microsoft's open source editor. It's pretty > nice and has an integrated terminal emulator. The terminal works fine with > a regular bash shell, but whenever I use IPython there, it has this weird > issue where it opens I-Search after almost every input. If I enter `ls` > say, it prints the directory contents, then the prompt jumps to the bottom > of the screen, where an `I-Search:` prompt appears. It doesn't happen with > IPython in a regular terminal emulator, only with IPython in VSCode. It > makes IPython unusable there. > > Sorry if this is the wrong place to ask about this. Can anyone help me get > rid of it? > > -- Carl Smith > carl.input at gmail.com > > _______________________________________________ > 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: From cappy2112 at gmail.com Mon Feb 6 00:42:52 2017 From: cappy2112 at gmail.com (Tony Cappellini) Date: Sun, 5 Feb 2017 21:42:52 -0800 Subject: [IPython-dev] Jupiter notebook not showing full cells in Safari on OS X Sierra Message-ID: I've just installed Anaconda 4.3.0 (Python 3.6) on Sierra, and created a few virtual environments. After launching the notebook interface in Safari- and opening a pre-existing notebook file, I've noticed that some of the cells are not fully displayed. I cannot scroll down so that I can see the full contents of the cells. Has anyone else had this problem? I wish I could attach a screenshot to this posting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon Feb 6 04:26:19 2017 From: benjaminrk at gmail.com (MinRK) Date: Mon, 6 Feb 2017 10:26:19 +0100 Subject: [IPython-dev] Jupiter notebook not showing full cells in Safari on OS X Sierra In-Reply-To: References: Message-ID: Do you have an extensions installed? Does it look different on other browsers? Images would indeed be helpful. You can use an image sharing site and put a link in here. -Min On Mon, Feb 6, 2017 at 6:42 AM, Tony Cappellini wrote: > > I've just installed Anaconda 4.3.0 (Python 3.6) on Sierra, and created a > few virtual environments. > > After launching the notebook interface in Safari- and opening a > pre-existing notebook file, > I've noticed that some of the cells are not fully displayed. I cannot > scroll down so that I can see the full contents of the cells. > > Has anyone else had this problem? > > I wish I could attach a screenshot to this posting. > > _______________________________________________ > 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: From jklymak at gmail.com Mon Feb 6 10:01:41 2017 From: jklymak at gmail.com (Klymak Jody) Date: Mon, 6 Feb 2017 07:01:41 -0800 Subject: [IPython-dev] Jupiter notebook not showing full cells in Safari on OS X Sierra In-Reply-To: References: Message-ID: > On Feb 5, 2017, at 21:42 PM, Tony Cappellini wrote: > > > I've just installed Anaconda 4.3.0 (Python 3.6) on Sierra, and created a few virtual environments. > > After launching the notebook interface in Safari- and opening a pre-existing notebook file, > I've noticed that some of the cells are not fully displayed. I cannot > scroll down so that I can see the full contents of the cells. > > Has anyone else had this problem? 1) Make sure you go to File->Trust Notebook 2) cells are collapsible, so you can click in the left gutter. Cheers, Jody > > I wish I could attach a screenshot to this posting. > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > https://mail.scipy.org/mailman/listinfo/ipython-dev From jr at sun.ac.za Tue Feb 14 09:00:48 2017 From: jr at sun.ac.za (Johann Rohwer) Date: Tue, 14 Feb 2017 16:00:48 +0200 Subject: [IPython-dev] Sans-serif fonts in LaTeX labels for Jupyter widgets? Message-ID: <7f158d09-07b2-6bab-fe80-8b793097e4d3@sun.ac.za> The documentation on layout and styling of Jupyter widgets mentions that Label widget can also render LaTeX equations: http://ipywidgets.readthedocs.io/en/latest/examples/Widget%20Styling.html#Latex On my machine, these equations render in a serif font by default. Is it possible to change the default font set to use sans-serif fonts, similar to matplotlib's? matplotlib.rcPararams['mathtext.fontset'] = 'stixsans' Cheers, Johann From carl.input at gmail.com Tue Feb 14 12:26:15 2017 From: carl.input at gmail.com (Carl Smith) Date: Tue, 14 Feb 2017 17:26:15 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. Message-ID: Hey all, I just opened an issue with PTK. There's a conflict between cursor wrapping and some 'named commands'. If you set PTK up to allow the cursor to wrap when it goes off the start or end of a line, it breaks some of PTKs collection of bash command equivalents. Thomas mentioned adding cursor wrapping to IPython by default, so figured you'd appreciate a heads-up. The issue (with a bit more detail) is here: https://github.com/jonathanslenders/python-prompt-toolkit/issues/469 Best, -- Carl Smith carl.input at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Feb 14 12:42:40 2017 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 14 Feb 2017 17:42:40 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. In-Reply-To: References: Message-ID: Thanks for the heads up. I forget exactly what cursor wrapping means in PTK; is that not what the cursor does by default? On 14 February 2017 at 17:26, Carl Smith wrote: > Hey all, > > I just opened an issue with PTK. There's a conflict between cursor > wrapping and some 'named commands'. If you set PTK up to allow the cursor > to wrap when it goes off the start or end of a line, it breaks some of PTKs > collection of bash command equivalents. > > Thomas mentioned adding cursor wrapping to IPython by default, so figured > you'd appreciate a heads-up. The issue (with a bit more detail) is here: > > https://github.com/jonathanslenders/python-prompt-toolkit/issues/469 > > Best, > > -- Carl Smith > carl.input at gmail.com > > _______________________________________________ > 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: From jason at jasongrout.org Tue Feb 14 12:58:50 2017 From: jason at jasongrout.org (Jason Grout) Date: Tue, 14 Feb 2017 17:58:50 +0000 Subject: [IPython-dev] Sans-serif fonts in LaTeX labels for Jupyter widgets? In-Reply-To: <7f158d09-07b2-6bab-fe80-8b793097e4d3@sun.ac.za> References: <7f158d09-07b2-6bab-fe80-8b793097e4d3@sun.ac.za> Message-ID: Good question. In theory, since we use MathJax for the rendering, this would be possible on a local notebook server by modifying the MathJax config in a custom.js file (see http://docs.mathjax.org/en/latest/options/HTML-CSS.html?highlight=stix and http://docs.mathjax.org/en/latest/font-support.html). You could set the preferredFont to null, and use one of the web fonts, for example. It looks like Davide (author of MathJax) has talked about using sans serif fonts before: https://github.com/mathjax/mathjax-docs/wiki/Can-MathJax-use-font-xxxx%3F. He might have an updated answer if you ask on the MathJax mailing list. Thanks, Jason On Tue, Feb 14, 2017 at 9:00 AM Johann Rohwer wrote: The documentation on layout and styling of Jupyter widgets mentions that Label widget can also render LaTeX equations: http://ipywidgets.readthedocs.io/en/latest/examples/Widget%20Styling.html#Latex On my machine, these equations render in a serif font by default. Is it possible to change the default font set to use sans-serif fonts, similar to matplotlib's? matplotlib.rcPararams['mathtext.fontset'] = 'stixsans' Cheers, Johann _______________________________________________ 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: From carl.input at gmail.com Tue Feb 14 13:06:56 2017 From: carl.input at gmail.com (Carl Smith) Date: Tue, 14 Feb 2017 18:06:56 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. In-Reply-To: References: Message-ID: On 14 February 2017 at 17:42, Thomas Kluyver wrote: > Thanks for the heads up. I forget exactly what cursor wrapping means in > PTK; is that not what the cursor does by default? > ?Nah. At least, it didn't last time I updated my installation. When the cursor reaches the start or end of a line, it just stops. If you're not planning to add cursor wrapping at this stage, then it's really only a problem for PTK. It should be fixed soon too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Tue Feb 14 13:11:11 2017 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 14 Feb 2017 18:11:11 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. In-Reply-To: References:

Message-ID: On 14 February 2017 at 18:06, Carl Smith wrote: > Nah. At least, it didn't last time I updated my installation. When the > cursor reaches the start or end of a line, it just stops. That's not what I see: [image: Inline images 1] I'm pretty sure I don't have any custom config affecting that. :-S -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-02-14 18-10-30.png Type: image/png Size: 2550 bytes Desc: not available URL: From carl.input at gmail.com Tue Feb 14 15:22:23 2017 From: carl.input at gmail.com (Carl Smith) Date: Tue, 14 Feb 2017 20:22:23 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. In-Reply-To: References:

Message-ID: I think we're describing two slightly different things. I just disabled the wrap stuff in my config (with 5.1.0), and it stops working. If you have two lines of code and the cursor is in the middle of the top line, and you then start pressing Right repeatedly, when the cursor gets to the last column and you hit Right again, does the cursor jump to the start of the second line or just stop? Similarly for hitting Left to go off the start of the second line, to wrap to the end of the first. I think you're describing the text wrapping over when it gets too long to fit on the line, with the cursor wrapping over with it. -- Carl Smith carl.input at gmail.com On 14 February 2017 at 18:11, Thomas Kluyver wrote: > On 14 February 2017 at 18:06, Carl Smith wrote: > >> Nah. At least, it didn't last time I updated my installation. When the >> cursor reaches the start or end of a line, it just stops. > > > That's not what I see: > > [image: Inline images 1] > > I'm pretty sure I don't have any custom config affecting that. :-S > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-02-14 18-10-30.png Type: image/png Size: 2550 bytes Desc: not available URL: From carl.input at gmail.com Tue Feb 14 17:55:17 2017 From: carl.input at gmail.com (Carl Smith) Date: Tue, 14 Feb 2017 22:55:17 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. In-Reply-To: References:

Message-ID: Thomas, sorry if my last email sounded a bit condescending mate. I was just trying to explain exactly what the issue was. I don't think IPython needs to do anything about this issue now anyway. I thought you had plans to use the cursor wrap thing. Best, -- Carl Smith carl.input at gmail.com On 14 February 2017 at 20:22, Carl Smith wrote: > I think we're describing two slightly different things. I just disabled > the wrap stuff in my config (with 5.1.0), and it stops working. > > If you have two lines of code and the cursor is in the middle of the top > line, and you then start pressing Right repeatedly, when the cursor gets to > the last column and you hit Right again, does the cursor jump to the start > of the second line or just stop? Similarly for hitting Left to go off the > start of the second line, to wrap to the end of the first. > > I think you're describing the text wrapping over when it gets too long to > fit on the line, with the cursor wrapping over with it. > > -- Carl Smith > carl.input at gmail.com > > On 14 February 2017 at 18:11, Thomas Kluyver wrote: > >> On 14 February 2017 at 18:06, Carl Smith wrote: >> >>> Nah. At least, it didn't last time I updated my installation. When the >>> cursor reaches the start or end of a line, it just stops. >> >> >> That's not what I see: >> >> [image: Inline images 1] >> >> I'm pretty sure I don't have any custom config affecting that. :-S >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-02-14 18-10-30.png Type: image/png Size: 2550 bytes Desc: not available URL: From jr at sun.ac.za Wed Feb 15 01:47:30 2017 From: jr at sun.ac.za (Johann Rohwer) Date: Wed, 15 Feb 2017 08:47:30 +0200 Subject: [IPython-dev] Sans-serif fonts in LaTeX labels for Jupyter widgets? In-Reply-To: References: <7f158d09-07b2-6bab-fe80-8b793097e4d3@sun.ac.za> Message-ID: Thanks for your reply. Pardon my ignorance, I am not entirely familiar with Jupyter internals. At which point is the MathJax configuration set, and how to override this without changing system defaults, i.e. user-specific? The wiki by Davide reads: For example, you could tell the HTML-CSS output jax to use the MathJax sans-serif font, when possible, in place of its seriffed font. The following accomplishes that: placed before the script that loads |MathJax.js| would tell the HTML-CSS (and the SVG) output jax to use the appropriate sans-serif fonts as the first choices for the normal, bold, and italic mathvariants, effectively making variables be italic sans-serif and numbers being upright sans-serif. So what is the script that loads MathJax.js for the jupyter notebook? I could only find a reference to that in a template file, python2.7/dist-packages/notebook/templates/noteboook.html I tried pasting the above code into ~/.ipython/profile_default/static/custom/custom.js but it has no effect. So at what point (and where) is MathJax loaded in the jupyter notebook startup, and how to change the defaults? Thanks, Johann On 14/02/17 19:58, Jason Grout wrote: > Good question. In theory, since we use MathJax for the rendering, this > would be possible on a local notebook server by modifying the MathJax > config in a custom.js file (see > http://docs.mathjax.org/en/latest/options/HTML-CSS.html?highlight=stix and > http://docs.mathjax.org/en/latest/font-support.html). You could set the > preferredFont to null, and use one of the web fonts, for example. > > It looks like Davide (author of MathJax) has talked about using sans serif > fonts before: > https://github.com/mathjax/mathjax-docs/wiki/Can-MathJax-use-font-xxxx%3F. > He might have an updated answer if you ask on the MathJax mailing list. > > Thanks, > > Jason > > > On Tue, Feb 14, 2017 at 9:00 AM Johann Rohwer > wrote: > > The documentation on layout and styling of Jupyter widgets mentions that > Label widget can also render LaTeX equations: > http://ipywidgets.readthedocs.io/en/latest/examples/Widget%20Styling.html#Latex > > On my machine, these equations render in a serif font by default. Is it > possible to change the default font set to use sans-serif fonts, > similar to > matplotlib's? > matplotlib.rcPararams['mathtext.fontset'] = 'stixsans' > > Cheers, > Johann > _______________________________________________ > 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 -- Johann M. Rohwer Professor of Systems Biology, and Chairperson: Dept. of Biochemistry Stellenbosch University Private Bag X1, 7602 Matieland SOUTH AFRICA Tel +27-21-8085843 Fax +27-21-8085863 jr at sun.ac.za http://www.jjj.sun.ac.za -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Feb 15 05:35:13 2017 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 15 Feb 2017 10:35:13 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. In-Reply-To: References:

Message-ID: On 14 February 2017 at 20:22, Carl Smith wrote: > If you have two lines of code and the cursor is in the middle of the top > line, and you then start pressing Right repeatedly, when the cursor gets to > the last column and you hit Right again, does the cursor jump to the start > of the second line or just stop? Similarly for hitting Left to go off the > start of the second line, to wrap to the end of the first. > > I think you're describing the text wrapping over when it gets too long to > fit on the line, with the cursor wrapping over with it. > You were quite right about what I was trying, and I understand what you mean now. No, I don't have cursor wrapping enabled. In fact I'd forgotten that we had any plan to enable that by default in IPython. Don't worry, I didn't read your message as condescending - it was a useful clarification on something I hadn't understood. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Wed Feb 15 05:40:51 2017 From: carl.input at gmail.com (Carl Smith) Date: Wed, 15 Feb 2017 10:40:51 +0000 Subject: [IPython-dev] Potential problem with PTK's wrap cursor feature. In-Reply-To: References:

Message-ID: > Don't worry, I didn't read your message as condescending - it was a useful > clarification on something I hadn't understood. :-) > ?Cool. The Web is rubbish at conveying tone.? If you're not planning to use the wrapping thing anytime soon, it's a non-issue here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Thu Feb 16 17:59:45 2017 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Thu, 16 Feb 2017 14:59:45 -0800 Subject: [IPython-dev] Participating in Docathon week of March 6th. Message-ID: Hello Jupyter and IPython crowd, UC Berkeley Institute for Data Science in collaboration with a couple other location is organizing a Docathon the Week of March 6th. The Docathon is like a Hackathon but focused on developing material and tools for documentation. It will be a distributed event where we hope to gather contributors and project to focus for a week on improving the current state of documentation across the board, regardless of whether you code in R, Python, Julia, C, ... A kickoff event should be happening on the March 6th at least at BIDS in Berkeley, and hope you can join in person, if not be online with US. A couple of other locations are making space available for people wanting to get involved , get help an give help. The Docathon is of course also ment to be a remote event, and is just a good opportunity to work on documentation for a week. You can get more informations on the Docathon website[1] If you'd like to participate to give, receive help, or want your project to get contribution during the Docathon, please register by filling-in the relevant forms on the upper left of the website. We might also ask you to create a "Docathon" label on GitHub. All this will allow us to gather metrics and try to get funding to organize a Docathon next year depending on the success. I'll personally be in BIDS space most of the week and will be happy to help you contribute to the Jupyter Documentation (Notebook 5.0 might not be out yet so that will be a good time to contribute). If you have any questions or like to get involved, host some hackers, write crawling scripts, do some webdesign... you can directly open issues on the GitHub organisation[2], there are plenty of available task. Thanks, -- Matthias [1]: https://bids.github.io/docathon/ [2]: https://github.com/BIDS/docathon/ From john.brodie at gmail.com Fri Feb 17 12:23:22 2017 From: john.brodie at gmail.com (John Brodie) Date: Fri, 17 Feb 2017 17:23:22 +0000 Subject: [IPython-dev] IPython-dev Digest, Vol 157, Issue 9 In-Reply-To: References: Message-ID: unsubscribe On Fri, Feb 17, 2017 at 4:00 AM wrote: > Send IPython-dev mailing list submissions to > ipython-dev at scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.scipy.org/mailman/listinfo/ipython-dev > or, via email, send a message with subject or body 'help' to > ipython-dev-request at scipy.org > > You can reach the person managing the list at > ipython-dev-owner at scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPython-dev digest..." > > > Today's Topics: > > 1. Participating in Docathon week of March 6th. (Matthias Bussonnier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Feb 2017 14:59:45 -0800 > From: Matthias Bussonnier > To: Project Jupyter , IPython developers > list > Subject: [IPython-dev] Participating in Docathon week of March 6th. > Message-ID: > Aw at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello Jupyter and IPython crowd, > > UC Berkeley Institute for Data Science in collaboration with a couple other > location is organizing a Docathon the Week of March 6th. > > The Docathon is like a Hackathon but focused on developing material and > tools > for documentation. It will be a distributed event where we hope to gather > contributors and project to focus for a week on improving the current > state of > documentation across the board, regardless of whether you code in R, > Python, > Julia, C, ... > > A kickoff event should be happening on the March 6th at least at BIDS in > Berkeley, and hope you can join in person, if not be online with US. A > couple of > other locations are making space available for people wanting to get > involved , > get help an give help. The Docathon is of course also ment to be a remote > event, > and is just a good opportunity to work on documentation for a week. > > You can get more informations on the Docathon website[1] > > If you'd like to participate to give, receive help, or want your project > to get > contribution during the Docathon, please register by filling-in the > relevant > forms on the upper left of the website. We might also ask you to create a > "Docathon" label on GitHub. All this will allow us to gather metrics and > try to > get funding to organize a Docathon next year depending on the success. > > I'll personally be in BIDS space most of the week and will be happy to > help you > contribute to the Jupyter Documentation (Notebook 5.0 might not be out yet > so > that will be a good time to contribute). > > If you have any questions or like to get involved, host some hackers, write > crawling scripts, do some webdesign... you can directly open issues on the > GitHub organisation[2], there are plenty of available task. > > Thanks, > -- > Matthias > > > > [1]: https://bids.github.io/docathon/ > [2]: https://github.com/BIDS/docathon/ > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > https://mail.scipy.org/mailman/listinfo/ipython-dev > > > ------------------------------ > > End of IPython-dev Digest, Vol 157, Issue 9 > ******************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glenn.caltech at gmail.com Tue Feb 21 10:01:31 2017 From: glenn.caltech at gmail.com (G Jones) Date: Tue, 21 Feb 2017 10:01:31 -0500 Subject: [IPython-dev] traitlets.config: common or global parameters? Message-ID: Hello, I am working on using traitlets.config in my project. The application has this structure: class Writer(Configurable): writer_trait = Int(4).tag(config=True) common_dir = Unicode('').tag(config=True) class Acquire(Configurable): acquire_trait = Int(55).tag(config=True) common_dir = Unicode('').tag(config=True) class Pipeline(Configurable): common_dir = Unicode('').tag(config=True) def initialize(self): self.writer = Writer() self.acquire = Acquire() class PipelineApp(Application): classes = [Pipeline, Acquire, Writer] def initialize(self,argv=None): self.pipeline = Pipeline(config=self.config) self.pipeline.initialize() The idea is that the common_dir traits should be all the same. The code works as written, but results in three possible lines in the settings file. Since the settings file is just python, it's not too bad to do c.Pipeline.common_dir = '/output' c.Acquire.common_dir = c.Pipeline.common_dir c.Writer.common_dir = c.Pipeline.common_dir But it seems like there should be a better way. I see that I could pass in a parent and access it that way: self.writer = Writer(parent=self) and then in writer: self.parent.common_dir But then if I want to use Writer on its own, I need to do a check if self.parent.... or something. Is there a better way? I hope the intent is clear, please let me know if not. Thanks, Glenn -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Tue Feb 21 11:39:22 2017 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Tue, 21 Feb 2017 08:39:22 -0800 Subject: [IPython-dev] traitlets.config: common or global parameters? In-Reply-To: References: Message-ID: Hi Glenn, I think the idea is to make a Common dummy subclass: class MyConfigurable(configurable): # class can be empty, or you can move the # common_dir = Unicode('').tag(config=True) # in it, up to you. pass Then just inherit from it: class Writer(MyConfigurable): writer_trait = Int(4).tag(config=True) common_dir = Unicode('').tag(config=True) class Acquire(MyConfigurable): acquire_trait = Int(55).tag(config=True) common_dir = Unicode('').tag(config=True) class Pipeline(MyConfigurable): common_dir = Unicode('').tag(config=True) def initialize(self): self.writer = Writer() self.acquire = Acquire() class PipelineApp(Application): classes = [Pipeline, Acquire, Writer] def initialize(self,argv=None): self.pipeline = Pipeline(config=self.config) self.pipeline.initialize() > > > The idea is that the common_dir traits should be all the same. The code works as > written, but results in three possible lines in the settings file. Since the > settings file is just python, it's not too bad to do > > c.Pipeline.common_dir = '/output' > c.Acquire.common_dir = c.Pipeline.common_dir > c.Writer.common_dir = c.Pipeline.common_dir Now you just need to configure MyConfigurable for it to affect all classes. c.MyConfigurable.common_dir = '/output' You can target one class in particular with what you do above. If you add parent=self self.pipeline = Pipeline(config=self.config, parent=self) Then you can narrow down configuration by using parent/child selector; c.PipelineApp.MyConfigurable.common_dir = '/output' It will target only MyConfigurable where `parent=self` is passed and parent is an instance of PipelineApp. (This is a rare case use in nbconvert to allow configuration of each exporter independently) Does that answer your questions ? -- Matthias On Tue, Feb 21, 2017 at 7:01 AM, G Jones wrote: > Hello, > > I am working on using traitlets.config in my project. The application has > this structure: > > class Writer(Configurable): > writer_trait = Int(4).tag(config=True) > common_dir = Unicode('').tag(config=True) > > class Acquire(Configurable): > acquire_trait = Int(55).tag(config=True) > common_dir = Unicode('').tag(config=True) > > class Pipeline(Configurable): > common_dir = Unicode('').tag(config=True) > def initialize(self): > self.writer = Writer() > self.acquire = Acquire() > > class PipelineApp(Application): > classes = [Pipeline, Acquire, Writer] > def initialize(self,argv=None): > self.pipeline = Pipeline(config=self.config) > self.pipeline.initialize() > > > The idea is that the common_dir traits should be all the same. The code > works as written, but results in three possible lines in the settings file. > Since the settings file is just python, it's not too bad to do > c.Pipeline.common_dir = '/output' > c.Acquire.common_dir = c.Pipeline.common_dir > c.Writer.common_dir = c.Pipeline.common_dir > > But it seems like there should be a better way. > > I see that I could pass in a parent and access it that way: > self.writer = Writer(parent=self) > > and then in writer: > self.parent.common_dir > > But then if I want to use Writer on its own, I need to do a check if > self.parent.... or something. > > Is there a better way? I hope the intent is clear, please let me know if > not. > > Thanks, > Glenn > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > https://mail.scipy.org/mailman/listinfo/ipython-dev > From glenn.caltech at gmail.com Tue Feb 21 12:51:16 2017 From: glenn.caltech at gmail.com (G Jones) Date: Tue, 21 Feb 2017 12:51:16 -0500 Subject: [IPython-dev] traitlets.config: common or global parameters? In-Reply-To: References: Message-ID: Hi Matthias, Thanks for the reply; I think that makes sense. It might also answer my next question too: Suppose I have another application PipelineMonitor and I want to connect PipelineApp to PipelineMonitor via a common socket. The question is how to share that common socket information (i.e. port number) between the applications using the config file. It sounds like the idea would be to do something like common_configuration.py: class GlobalConfiguration(configurable): common_port_number = Int(55555).tag(config=True) pipeline.py: from common_configuration import GlobalConfiguration class PipelineConfiguration(GlobalConfiguration): common_dir = Unicode('').tag(config=True) pipeline_monitor.py: from common_configuration import GlobalConfiguration class PipelineMonitorConfiguration(GlobalCOnfiguration): some_param = Int(34).tag(config=True) and then inherit PipelineConfiguration and PipelineMonitorConfiguration in the respective application classes. Then I should be able to have a global_config.py configuration file with the common_port_number, and then use load_subconfig(global_config.py) in each of the application specific config files. Does that sound like the right idea? Thank you again, Glenn On Tue, Feb 21, 2017 at 11:39 AM, Matthias Bussonnier < bussonniermatthias at gmail.com> wrote: > Hi Glenn, > > I think the idea is to make a Common dummy subclass: > > class MyConfigurable(configurable): > # class can be empty, or you can move the > # common_dir = Unicode('').tag(config=True) > # in it, up to you. > pass > > > Then just inherit from it: > > class Writer(MyConfigurable): > writer_trait = Int(4).tag(config=True) > common_dir = Unicode('').tag(config=True) > > class Acquire(MyConfigurable): > acquire_trait = Int(55).tag(config=True) > common_dir = Unicode('').tag(config=True) > > class Pipeline(MyConfigurable): > common_dir = Unicode('').tag(config=True) > def initialize(self): > self.writer = Writer() > self.acquire = Acquire() > > class PipelineApp(Application): > classes = [Pipeline, Acquire, Writer] > def initialize(self,argv=None): > self.pipeline = Pipeline(config=self.config) > self.pipeline.initialize() > > > > > > The idea is that the common_dir traits should be all the same. The code > works as > > written, but results in three possible lines in the settings file. Since > the > > settings file is just python, it's not too bad to do > > > > c.Pipeline.common_dir = '/output' > > c.Acquire.common_dir = c.Pipeline.common_dir > > c.Writer.common_dir = c.Pipeline.common_dir > > > Now you just need to configure MyConfigurable for it to affect all classes. > > c.MyConfigurable.common_dir = '/output' > > You can target one class in particular with what you do above. > > If you add parent=self > > self.pipeline = Pipeline(config=self.config, parent=self) > > Then you can narrow down configuration by using parent/child selector; > > c.PipelineApp.MyConfigurable.common_dir = '/output' > > It will target only MyConfigurable where `parent=self` is passed and > parent is an > instance of PipelineApp. (This is a rare case use in nbconvert to allow > configuration of each exporter independently) > > Does that answer your questions ? > > -- > > Matthias > > On Tue, Feb 21, 2017 at 7:01 AM, G Jones wrote: > > Hello, > > > > I am working on using traitlets.config in my project. The application has > > this structure: > > > > class Writer(Configurable): > > writer_trait = Int(4).tag(config=True) > > common_dir = Unicode('').tag(config=True) > > > > class Acquire(Configurable): > > acquire_trait = Int(55).tag(config=True) > > common_dir = Unicode('').tag(config=True) > > > > class Pipeline(Configurable): > > common_dir = Unicode('').tag(config=True) > > def initialize(self): > > self.writer = Writer() > > self.acquire = Acquire() > > > > class PipelineApp(Application): > > classes = [Pipeline, Acquire, Writer] > > def initialize(self,argv=None): > > self.pipeline = Pipeline(config=self.config) > > self.pipeline.initialize() > > > > > > The idea is that the common_dir traits should be all the same. The code > > works as written, but results in three possible lines in the settings > file. > > Since the settings file is just python, it's not too bad to do > > c.Pipeline.common_dir = '/output' > > c.Acquire.common_dir = c.Pipeline.common_dir > > c.Writer.common_dir = c.Pipeline.common_dir > > > > But it seems like there should be a better way. > > > > I see that I could pass in a parent and access it that way: > > self.writer = Writer(parent=self) > > > > and then in writer: > > self.parent.common_dir > > > > But then if I want to use Writer on its own, I need to do a check if > > self.parent.... or something. > > > > Is there a better way? I hope the intent is clear, please let me know if > > not. > > > > Thanks, > > Glenn > > > > _______________________________________________ > > 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: From prabhu at aero.iitb.ac.in Tue Feb 21 15:20:18 2017 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Wed, 22 Feb 2017 01:50:18 +0530 Subject: [IPython-dev] [ANN ] Jupyter tools: tex2ipy and ipyaml Message-ID: <5c7c9601-620c-36f1-7a93-50b5bd9f6045@aero.iitb.ac.in> Hi everyone, I'd like to announce a couple of simple packages related to Jupyter notebooks. tex2ipy: https://github.com/prabhuramachandran/tex2ipy This simple tool makes it relatively easy to convert a LaTeX beamer presentation to a Jupyter/IPython notebook using RISE[1]. The second tool is: ipyaml: https://github.com/prabhuramachandran/ipyaml This allows Jupyter to store notebook files as easy-to-edit YAML files. It supports both code/markdown and outputs so is entirely compatible with .ipynb files (version 4 of the notebook format). Output dumping can be disabled if needed. This package is similar to notedown and ipymd but offers complete compatibility with .ipynb files. Installation ------------ Both packages can be installed using pip. $ pip install tex2ipy # Works only with Python3.x $ pip install ipyaml cheers, Prabhu [1] https://github.com/damianavila/RISE From ellisonbg at gmail.com Tue Feb 21 17:05:46 2017 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 21 Feb 2017 15:05:46 -0700 Subject: [IPython-dev] [ANN ] Jupyter tools: tex2ipy and ipyaml In-Reply-To: <5c7c9601-620c-36f1-7a93-50b5bd9f6045@aero.iitb.ac.in> References: <5c7c9601-620c-36f1-7a93-50b5bd9f6045@aero.iitb.ac.in> Message-ID: Very cool! Thanks for sharing! On Tue, Feb 21, 2017 at 1:20 PM, Prabhu Ramachandran wrote: > Hi everyone, > > I'd like to announce a couple of simple packages related to Jupyter notebooks. > > tex2ipy: https://github.com/prabhuramachandran/tex2ipy > > This simple tool makes it relatively easy to convert a LaTeX beamer presentation > to a Jupyter/IPython notebook using RISE[1]. > > The second tool is: > > ipyaml: https://github.com/prabhuramachandran/ipyaml > > This allows Jupyter to store notebook files as easy-to-edit YAML files. It > supports both code/markdown and outputs so is entirely compatible with .ipynb > files (version 4 of the notebook format). Output dumping can be disabled if > needed. This package is similar to notedown and ipymd but offers complete > compatibility with .ipynb files. > > Installation > ------------ > > Both packages can be installed using pip. > > $ pip install tex2ipy # Works only with Python3.x > > $ pip install ipyaml > > > cheers, > Prabhu > > [1] https://github.com/damianavila/RISE > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > https://mail.scipy.org/mailman/listinfo/ipython-dev -- 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 fperez.net at gmail.com Wed Feb 22 20:17:04 2017 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 22 Feb 2017 17:17:04 -0800 Subject: [IPython-dev] [ANN ] Jupyter tools: tex2ipy and ipyaml In-Reply-To: References: <5c7c9601-620c-36f1-7a93-50b5bd9f6045@aero.iitb.ac.in> Message-ID: On Tue, Feb 21, 2017 at 2:05 PM, Brian Granger wrote: > Very cool! Thanks for sharing! +1! Which reminds me of this: https://github.com/pypa/pypi-legacy/issues/210 It would be really nice to have a "Jupyter" trove classifier for PyPI, so we could quickly find Jupyter-related packages... That would be useful on multiple fronts for us... Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Wed Feb 22 22:41:29 2017 From: carl.input at gmail.com (Carl Smith) Date: Thu, 23 Feb 2017 03:41:29 +0000 Subject: [IPython-dev] IPython Syntax Highlighting for the Nice Editor (and JOE) Message-ID: The Nice Editor (also known as ne) is a user-friendly alternative to Emacs and Vim, hailed by *Linux Voice* as "the third best editor for Linux". It's simple and fast, and feels really modern, like Sublime, not like nano. I love it, and use it with IPython, so recently asked about adding a syntax highlighter for editing IPython blocks and ipy files. The lead developer, Sebastiano Vigna (vigna), was super helpful, and implemented it. With IPython commands, you can highlight the bang or percent character one colour and the actual command a different colour, and it works with =! statements (and is not confused by Python's modulo and not-equals operators). Nice could potentially highlight the commands as shell syntax, but the simplicity of the current solution is *nice*. It looks like this: @line_magic *def **appserver*(args): path, port = server_argparse(args) *%* dev_appserverpy $path --port $port @line_magic *def **sonicboom*(port): *def **kill*(process): id = process.split()[1] *!* kill -9 $id *return* int(id) processes =*!* lsof -i tcp:$port graveyard = [ kill(process) *for* process *in* processes *if* "(LISTEN)" *in* process ] If you are interested in using this at the moment, the file you need is here (as a gist): https://gist.github.com/carlsmith/fb451f9a8f5a6e699e3eaeda40d3918a JOE (Joe's Own Editor) uses the same syntax highlighting definitions, so the file will work with that editor too. There are links to HTML and PDF versions of the Nice Editor docs at http://ne.di.unimi.it . Best, -- Carl Smith carl.input at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Thu Feb 23 00:37:52 2017 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Wed, 22 Feb 2017 21:37:52 -0800 Subject: [IPython-dev] IPython Syntax Highlighting for the Nice Editor (and JOE) In-Reply-To: References: Message-ID: Sweet ! Thanks for sharing !, I'm not even sure IPython has the correct highlighting everywhere ! -- M On Wed, Feb 22, 2017 at 7:41 PM, Carl Smith wrote: > The Nice Editor (also known as ne) is a user-friendly alternative to Emacs > and Vim, hailed by Linux Voice as "the third best editor for Linux". It's > simple and fast, and feels really modern, like Sublime, not like nano. I > love it, and use it with IPython, so recently asked about adding a syntax > highlighter for editing IPython blocks and ipy files. The lead developer, > Sebastiano Vigna (vigna), was super helpful, and implemented it. > > With IPython commands, you can highlight the bang or percent character one > colour and the actual command a different colour, and it works with =! > statements (and is not confused by Python's modulo and not-equals > operators). Nice could potentially highlight the commands as shell syntax, > but the simplicity of the current solution is nice. It looks like this: > > @line_magic > > def appserver(args): > > > path, port = server_argparse(args) > > % dev_appserverpy $path --port $port > > > @line_magic > > def sonicboom(port): > > > def kill(process): > > > id = process.split()[1] > > ! kill -9 $id > > return int(id) > > > processes =! lsof -i tcp:$port > > graveyard = [ kill(process) for process in processes if "(LISTEN)" in > process ] > > > > > If you are interested in using this at the moment, the file you need is here > (as a gist): > > https://gist.github.com/carlsmith/fb451f9a8f5a6e699e3eaeda40d3918a > > JOE (Joe's Own Editor) uses the same syntax highlighting definitions, so the > file will work with that editor too. > > There are links to HTML and PDF versions of the Nice Editor docs at > http://ne.di.unimi.it . > > Best, > -- Carl Smith > carl.input at gmail.com > > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > https://mail.scipy.org/mailman/listinfo/ipython-dev > From carl.input at gmail.com Thu Feb 23 09:48:41 2017 From: carl.input at gmail.com (Carl Smith) Date: Thu, 23 Feb 2017 14:48:41 +0000 Subject: [IPython-dev] IPython Syntax Highlighting for the Nice Editor (and JOE) In-Reply-To: References: Message-ID: > Thanks for sharing !, I'm not even sure IPython has the correct > highlighting everywhere ! > ?:) No problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Mon Feb 27 03:28:00 2017 From: benjaminrk at gmail.com (MinRK) Date: Mon, 27 Feb 2017 09:28:00 +0100 Subject: [IPython-dev] traitlets.config: common or global parameters? In-Reply-To: References: Message-ID: On Tue, Feb 21, 2017 at 6:51 PM, G Jones wrote: Hi Matthias, > Thanks for the reply; I think that makes sense. > It might also answer my next question too: Suppose I have another > application PipelineMonitor and I want to connect PipelineApp to > PipelineMonitor via a common socket. The question is how to share that > common socket information (i.e. port number) between the applications using > the config file. It sounds like the idea would be to do something like > common_configuration.py: > class GlobalConfiguration(configurable): > common_port_number = Int(55555).tag(config=True) > > pipeline.py: > from common_configuration import GlobalConfiguration > class PipelineConfiguration(GlobalConfiguration): > common_dir = Unicode('').tag(config=True) > > pipeline_monitor.py: > from common_configuration import GlobalConfiguration > class PipelineMonitorConfiguration(GlobalCOnfiguration): > some_param = Int(34).tag(config=True) > > and then inherit PipelineConfiguration and PipelineMonitorConfiguration in > the respective application classes. > Yup, this is a patten that has shown up in a few cases, and works pretty well. > Then I should be able to have a global_config.py configuration file with > the common_port_number, and then use load_subconfig(global_config.py) in > each of the application specific config files. > If your different Applications are relatively small and closely related, you can probably get away with using a single configuration file for your whole application. Set config_file_name on all your applications to the same value (e.g. 'myapp_config'. -MinRK > Does that sound like the right idea? > > Thank you again, > Glenn > > > On Tue, Feb 21, 2017 at 11:39 AM, Matthias Bussonnier < > bussonniermatthias at gmail.com> wrote: > >> Hi Glenn, >> >> I think the idea is to make a Common dummy subclass: >> >> class MyConfigurable(configurable): >> # class can be empty, or you can move the >> # common_dir = Unicode('').tag(config=True) >> # in it, up to you. >> pass >> >> >> Then just inherit from it: >> >> class Writer(MyConfigurable): >> writer_trait = Int(4).tag(config=True) >> common_dir = Unicode('').tag(config=True) >> >> class Acquire(MyConfigurable): >> acquire_trait = Int(55).tag(config=True) >> common_dir = Unicode('').tag(config=True) >> >> class Pipeline(MyConfigurable): >> common_dir = Unicode('').tag(config=True) >> def initialize(self): >> self.writer = Writer() >> self.acquire = Acquire() >> >> class PipelineApp(Application): >> classes = [Pipeline, Acquire, Writer] >> def initialize(self,argv=None): >> self.pipeline = Pipeline(config=self.config) >> self.pipeline.initialize() >> > >> > >> > The idea is that the common_dir traits should be all the same. The code >> works as >> > written, but results in three possible lines in the settings file. >> Since the >> > settings file is just python, it's not too bad to do >> > >> > c.Pipeline.common_dir = '/output' >> > c.Acquire.common_dir = c.Pipeline.common_dir >> > c.Writer.common_dir = c.Pipeline.common_dir >> >> >> Now you just need to configure MyConfigurable for it to affect all >> classes. >> >> c.MyConfigurable.common_dir = '/output' >> >> You can target one class in particular with what you do above. >> >> If you add parent=self >> >> self.pipeline = Pipeline(config=self.config, parent=self) >> >> Then you can narrow down configuration by using parent/child selector; >> >> c.PipelineApp.MyConfigurable.common_dir = '/output' >> >> It will target only MyConfigurable where `parent=self` is passed and >> parent is an >> instance of PipelineApp. (This is a rare case use in nbconvert to allow >> configuration of each exporter independently) >> >> Does that answer your questions ? >> >> -- >> >> Matthias >> >> On Tue, Feb 21, 2017 at 7:01 AM, G Jones wrote: >> > Hello, >> > >> > I am working on using traitlets.config in my project. The application >> has >> > this structure: >> > >> > class Writer(Configurable): >> > writer_trait = Int(4).tag(config=True) >> > common_dir = Unicode('').tag(config=True) >> > >> > class Acquire(Configurable): >> > acquire_trait = Int(55).tag(config=True) >> > common_dir = Unicode('').tag(config=True) >> > >> > class Pipeline(Configurable): >> > common_dir = Unicode('').tag(config=True) >> > def initialize(self): >> > self.writer = Writer() >> > self.acquire = Acquire() >> > >> > class PipelineApp(Application): >> > classes = [Pipeline, Acquire, Writer] >> > def initialize(self,argv=None): >> > self.pipeline = Pipeline(config=self.config) >> > self.pipeline.initialize() >> > >> > >> > The idea is that the common_dir traits should be all the same. The code >> > works as written, but results in three possible lines in the settings >> file. >> > Since the settings file is just python, it's not too bad to do >> > c.Pipeline.common_dir = '/output' >> > c.Acquire.common_dir = c.Pipeline.common_dir >> > c.Writer.common_dir = c.Pipeline.common_dir >> > >> > But it seems like there should be a better way. >> > >> > I see that I could pass in a parent and access it that way: >> > self.writer = Writer(parent=self) >> > >> > and then in writer: >> > self.parent.common_dir >> > >> > But then if I want to use Writer on its own, I need to do a check if >> > self.parent.... or something. >> > >> > Is there a better way? I hope the intent is clear, please let me know if >> > not. >> > >> > Thanks, >> > Glenn >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > 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: From bussonniermatthias at gmail.com Tue Feb 28 19:04:09 2017 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Tue, 28 Feb 2017 16:04:09 -0800 Subject: [IPython-dev] Preparing for IPython 6.0 Message-ID: Hi all I think we are closing-in on IPython 6.0 There are about 30 issues/PR open [1], I've opened a meta issue to discuss remaining changes and potentially problematic issues[2], and I've started to write/fomat the what's new [3] There are about 7 issues marked "Need contributors" that should be relatively easy if you are new to the codebase or to Python. Next week I'll be in Berkeley participating to the docathon [4]. I'd love help to go through the docs and make things cleaner/better/valid for most English lexer/parser/compiler/interpreters. If you have any critical issues that are not marked as 6.0, let us know. Even if they are marked as 6.0 they may be bumped to later if there is not much interest, involve too much changes, or are beyond what we are capable of doing. Looking forward for your help to test, review, document. As usual if you have any question they are welcome. Thanks, -- Matthias 1: https://github.com/ipython/ipython/milestone/33 2: https://github.com/ipython/ipython/issues/10329 3: http://ipython.readthedocs.io/en/latest/whatsnew/development.html 4: https://bids.github.io/docathon/