Mixing Python2 and Python3 blocks in one file

Mixing Python2 and Python3 blocks in one file

[Karl Voit]

Hi!

Python2 and Python3 are two different languages. Unfortunately,
Org-mode only uses ~#+BEGIN_SRC python~ for both and uses
python-shell-interpreter to choose/switch the compiler.

Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC
python3~ to solve this issue in a clean way?

~#+BEGIN_SRC python~ can still default to python2.


I only found those sources/solutions:

http://thread.gmane.org/gmane.emacs.orgmode/47867
... file-variables to choose interpretor

http://thread.gmane.org/gmane.emacs.orgmode/47867
... workaround with #+srcname (I don't get yet)


-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Mixing Python2 and Python3 blocks in one file

[Karl Voit]

* Karl Voit <devnull@Karl-Voit.at> wrote:
> Hi!
>
> Python2 and Python3 are two different languages. Unfortunately,
> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses
> python-shell-interpreter to choose/switch the compiler.
>
> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC
> python3~ to solve this issue in a clean way?
>
> ~#+BEGIN_SRC python~ can still default to python2.
>
>
> I only found those sources/solutions:

Correct links:

http://article.gmane.org/gmane.emacs.orgmode/47878
> ... file-variables to choose interpretor

http://article.gmane.org/gmane.emacs.orgmode/47955
> ... workaround with #+srcname (I don't get yet)

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Mixing Python2 and Python3 blocks in one file

[William Henney]

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

Hi Karl

On Sun, May 8, 2016 at 3:31 AM, Karl Voit <devnull@karl-voit.at> wrote:

Python2 and Python3 are two different languages. Unfortunately,
> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses
> python-shell-interpreter to choose/switch the compiler.
>
> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC
> python3~ to solve this issue in a clean way?
>
> ~#+BEGIN_SRC python~ can still default to python2.
>
>
>
You can use the :python header argument to the source block, which allows
you to specify the path to the python interpreter:


————————— BEGIN EXAMPLE ————————

* Default python version
#+name: check-python-version
#+BEGIN_SRC python
import sys
return sys.version
#+END_SRC

#+RESULTS: check-python-version
: 3.4.4 |Anaconda 2.5.0 (x86_64)| (default, Jan  9 2016, 17:30:09)
: [GCC 4.2.1 (Apple Inc. build 5577)]

This is the control experiment.

* Custom python version
#+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python
import sys
return sys.version
#+END_SRC

#+RESULTS:
: 2.7.11 |Continuum Analytics, Inc.| (default, Dec  6 2015, 18:57:58)
: [GCC 4.2.1 (Apple Inc. build 5577)]

—————————  END EXAMPLE  ————————

Also see original discussion at

https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html

Will



> I only found those sources/solutions:
>
> http://thread.gmane.org/gmane.emacs.orgmode/47867
> ... file-variables to choose interpretor
>
> http://thread.gmane.org/gmane.emacs.orgmode/47867
> ... workaround with #+srcname (I don't get yet)
>
>
> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>        > get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>


-- 

  Dr William Henney, Instituto de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: Type: text/html, Size: 3723 bytes --]

Re: Mixing Python2 and Python3 blocks in one file

[Karl Voit]

Hi William

* William Henney <whenney@gmail.com> wrote:
>
> On Sun, May 8, 2016 at 3:31 AM, Karl Voit <devnull@karl-voit.at> wrote:
>
> Python2 and Python3 are two different languages. Unfortunately,
>> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses
>> python-shell-interpreter to choose/switch the compiler.
>>
>> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC
>> python3~ to solve this issue in a clean way?
>>
>> ~#+BEGIN_SRC python~ can still default to python2.
>>
> You can use the :python header argument to the source block, which allows
> you to specify the path to the python interpreter:
>
> #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python

Cool, I did not find this parameter yet.

Is this undocumented? http://orgmode.org/org.html does not contain
the string ":python:" and
http://orgmode.org/org.html#Language_002dspecific-header-arguments
also does not mention this parameter.

> Also see original discussion at
> https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html

Most interesting to me, thank you.

With the parameter above as a workaround, I can accomplish the
things I want to do for now. However, I still do think that Python2
and Python3 as different languages demand different block
identifiers.

#+BEGIN_SRC python -> defaults to the default python interpreter
#+BEGIN_SRC python2 -> uses Python2
#+BEGIN_SRC python3 -> uses Python3

Don't you think?

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Mixing Python2 and Python3 blocks in one file

[John Kitchin]

You can hack this to work:

#+BEGIN_SRC emacs-lisp
(defun org-babel-execute:python2 (body params)
  (let ((org-babel-python-command "/Users/jkitchin/Library/Enthought/Canopy_64bit/User/bin/python2"))
    (org-babel-execute:python body params)))

#+END_SRC


#+BEGIN_SRC python2
print 'Hello'
#+END_SRC
#+RESULTS:
: Hello


One issue though is no font-lock in the source block. I think it uses
the language to set the mode.

Karl Voit writes:

> Hi William
>
> * William Henney <whenney@gmail.com> wrote:
>>
>> On Sun, May 8, 2016 at 3:31 AM, Karl Voit <devnull@karl-voit.at> wrote:
>>
>> Python2 and Python3 are two different languages. Unfortunately,
>>> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses
>>> python-shell-interpreter to choose/switch the compiler.
>>>
>>> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC
>>> python3~ to solve this issue in a clean way?
>>>
>>> ~#+BEGIN_SRC python~ can still default to python2.
>>>
>> You can use the :python header argument to the source block, which allows
>> you to specify the path to the python interpreter:
>>
>> #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python
>
> Cool, I did not find this parameter yet.
>
> Is this undocumented? http://orgmode.org/org.html does not contain
> the string ":python:" and
> http://orgmode.org/org.html#Language_002dspecific-header-arguments
> also does not mention this parameter.
>
>> Also see original discussion at
>> https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html
>
> Most interesting to me, thank you.
>
> With the parameter above as a workaround, I can accomplish the
> things I want to do for now. However, I still do think that Python2
> and Python3 as different languages demand different block
> identifiers.
>
> #+BEGIN_SRC python -> defaults to the default python interpreter
> #+BEGIN_SRC python2 -> uses Python2
> #+BEGIN_SRC python3 -> uses Python3
>
> Don't you think?


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Mixing Python2 and Python3 blocks in one file

[William Henney]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

Hi Karl

On Tue, May 17, 2016 at 9:54 AM, Karl Voit <devnull@karl-voit.at> wrote:

> Hi William
>
> * William Henney <whenney@gmail.com> wrote:
> >
> > On Sun, May 8, 2016 at 3:31 AM, Karl Voit <devnull@karl-voit.at> wrote:
> >
> > Python2 and Python3 are two different languages. Unfortunately,
> >> Org-mode only uses ~#+BEGIN_SRC python~ for both and uses
> >> python-shell-interpreter to choose/switch the compiler.
> >>
> >> Shouldn't Org-mode introduce ~#+BEGIN_SRC python2~ and ~#+BEGIN_SRC
> >> python3~ to solve this issue in a clean way?
> >>
> >> ~#+BEGIN_SRC python~ can still default to python2.
> >>
> > You can use the :python header argument to the source block, which allows
> > you to specify the path to the python interpreter:
> >
> > #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python
>
> Cool, I did not find this parameter yet.
>
> Is this undocumented? http://orgmode.org/org.html does not contain
> the string ":python:" and
> http://orgmode.org/org.html#Language_002dspecific-header-arguments
> also does not mention this parameter.
>
>
It is documented at
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html

You are right that it would be better if the language-specific babel
documentation were better integrated in the general org info file.  But I
suppose nobody has been sufficiently motivated to do it yet


> > Also see original discussion at
> > https://lists.gnu.org/archive/html/emacs-orgmode/2014-04/msg01042.html
>
> Most interesting to me, thank you.
>
> With the parameter above as a workaround, I can accomplish the
> things I want to do for now. However, I still do think that Python2
> and Python3 as different languages demand different block
> identifiers.
>
> #+BEGIN_SRC python -> defaults to the default python interpreter
> #+BEGIN_SRC python2 -> uses Python2
> #+BEGIN_SRC python3 -> uses Python3
>
> Don't you think?
>
>
To be honest, I disagree that we need different block identifiers.  Python
is hardly the only language to have gone through multiple major versions,
and I don’t think a proliferation of org-babel languages is the answer.
What about C11 vs C99, etc?  I guess a good rule of thumb would be: do the
two versions use the same major mode in emacs?

Why is the :python parameter insufficient for your needs?  You can also use
it for different virtual environments

Cheers

Will



> --
> mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
>        > get Memacs from https://github.com/novoid/Memacs <
>
> https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
> github
>
>
>


-- 

  Dr William Henney, Instituto de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: Type: text/html, Size: 4844 bytes --]

Re: Mixing Python2 and Python3 blocks in one file

[Thomas S. Dye]

William Henney writes:
>> Cool, I did not find this parameter yet.
>>
>> Is this undocumented? http://orgmode.org/org.html does not contain
>> the string ":python:" and
>> http://orgmode.org/org.html#Language_002dspecific-header-arguments
>> also does not mention this parameter.
>>
>>
> It is documented at
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html

As of a few hours ago, when I added it.  It probably wasn't there when
Karl looked.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Mixing Python2 and Python3 blocks in one file

[Karl Voit]

* Thomas S. Dye <tsd@tsdye.com> wrote:
>
> William Henney writes:
>>
>> It is documented at
>> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html
>
> As of a few hours ago, when I added it.  It probably wasn't there when
> Karl looked.

Thank you very much Thomas!

I can not appreciate documentation improvements too much ;-)

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Division of Org documentation: Org manual and Worg (was: Mixing Python2 and Python3 blocks in one file)

[Karl Voit]

Good morning William,

* William Henney <whenney@gmail.com> wrote:
>
> On Tue, May 17, 2016 at 9:54 AM, Karl Voit <devnull@karl-voit.at> wrote:
>
>> * William Henney <whenney@gmail.com> wrote:
>> >
>> > #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python
>>
>> Is this undocumented? http://orgmode.org/org.html does not contain
>> the string ":python:" and
>> http://orgmode.org/org.html#Language_002dspecific-header-arguments
>> also does not mention this parameter.
>>
> It is documented at
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html
>
> You are right that it would be better if the language-specific babel
> documentation were better integrated in the general org info file.  But I
> suppose nobody has been sufficiently motivated to do it yet

That brings me to an additional question I was asking myself a
couple of times: things like this, IMHO basic features, are
sometimes mentioned in Worg but not in the Org manual. Is there a
«rule» that I can follow so that I know where to look?

So far, I had to do full text search on both domains to find certain
keywords...

Thanks

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Division of Org documentation: Org manual and Worg

[Daniele Pizzolli]

On Wed, May 18 2016, Karl Voit wrote:

> Good morning William,
>
> * William Henney <whenney@gmail.com> wrote:
>>
>> On Tue, May 17, 2016 at 9:54 AM, Karl Voit <devnull@karl-voit.at> wrote:
>>
>>> * William Henney <whenney@gmail.com> wrote:
>>> >
>>> > #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python
>>>
>>> Is this undocumented? http://orgmode.org/org.html does not contain
>>> the string ":python:" and
>>> http://orgmode.org/org.html#Language_002dspecific-header-arguments
>>> also does not mention this parameter.
>>>
>> It is documented at
>> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html
>>
>> You are right that it would be better if the language-specific babel
>> documentation were better integrated in the general org info file.  But I
>> suppose nobody has been sufficiently motivated to do it yet
>
> That brings me to an additional question I was asking myself a
> couple of times: things like this, IMHO basic features, are
> sometimes mentioned in Worg but not in the Org manual. Is there a
> «rule» that I can follow so that I know where to look?
>
> So far, I had to do full text search on both domains to find certain
> keywords...

Hello,

Me too, and this is really a problem when you try do unusual stuff.

I will share some problems and workaround for python in a new thread.

It would be nice to add them to the documentation, but I have not yet
figured out what is the appropriate way to send the patch!

Best,
Daniele

Re: Division of Org documentation: Org manual and Worg

[Rasmus]

Daniele Pizzolli <dan@toel.it> writes:

> It would be nice to add them to the documentation, but I have not yet
> figured out what is the appropriate way to send the patch!

/That/ information happens to be on Worg :)

       http://orgmode.org/worg/org-contribute.html

-- 
It was you, Jezebel, it was you

Re: Division of Org documentation: Org manual and Worg

[Daniele Pizzolli]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Wed, May 18 2016, Rasmus  wrote:

> Daniele Pizzolli writes:
>
>> It would be nice to add them to the documentation, but I have not yet
>> figured out what is the appropriate way to send the patch!
>
> /That/ information happens to be on Worg :)
>
>        http://orgmode.org/worg/org-contribute.html

Thanks Rasmus,

So... here is the patch for worg about python and utf-8!  I skipped
the part related to the tables, since I do not have a clean
workaround.

Best,
Daniele


[-- Attachment #2: 0001-Add-caveats-about-uft-8-strings.patch --]
[-- Type: text/x-diff, Size: 2609 bytes --]

From 91941d90d26e1715447fecc255d7976c0895e75d Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli <dan@toel.it>
Date: Wed, 18 May 2016 11:55:00 +0200
Subject: [PATCH 1/1] Add caveats about uft-8 strings

---
 org-contrib/babel/languages/ob-doc-python.org | 52 ++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/org-contrib/babel/languages/ob-doc-python.org b/org-contrib/babel/languages/ob-doc-python.org
index 968a8bc..e4619ed 100644
--- a/org-contrib/babel/languages/ob-doc-python.org
+++ b/org-contrib/babel/languages/ob-doc-python.org
@@ -25,7 +25,7 @@
   </div>
 #+end_html
 
-* Template Checklist [10/12] 					   :noexport:
+* Template Checklist [11/14] 					   :noexport:
   - [X] Revise #+TITLE:
   - [X] Indicate #+AUTHOR:
   - [X] Add #+EMAIL:
@@ -42,6 +42,8 @@
   - [ ] Describe [[Result%20Types][Result Types]]
   - [ ] Describe [[Other]] differences from supported languages
   - [X] Provide brief [[Examples%20of%20Use][Examples of Use]]
+  - [X] Add caveats about utf-8 in strings
+  - [ ] Add caveats about utf-8 in tables
 * Introduction
 Python is a high-level, readable, interpreted language which can be
 used for many common computing tasks.  It runs on most modern
@@ -242,3 +244,51 @@ return 'images/python-matplot-fig.png' # return filename to org-mode
 
 #+end_example
 [[file:images/python-matplot-fig.png]]
+
+* Caveats
+
+** passing utf-8 strings to python
+
+You need some care in order to pass utf-8 strings to python.
+
+#+begin_example
+#+NAME: unicode_str
+,#+BEGIN_EXAMPLE
+“this string is not ascii!”
+,#+END_EXAMPLE
+#+end_example
+
+#+begin_example
+#+NAME: error-in-passing-var
+#+BEGIN_SRC python :var data=unicode_str
+return data
+#+END_SRC
+#+end_example
+
+#+begin_example
+#+RESULTS: error-in-passing-var
+#+end_example
+
+Will produce no output and prints the following message in the buffer
+=*Org-Babel Error Output*=:
+
+#+BEGIN_EXAMPLE
+  File "<stdin>", line 3
+SyntaxError: Non-ASCII character '\xe2' in file <stdin> on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
+#+END_EXAMPLE
+
+** passing utf-8 strings to python with workaround
+
+A workaround is to use =:preamble= with wthe value =# -*- coding:utf-8 -*-=
+
+#+begin_example
+#+NAME: ok-in-passing-var
+#+BEGIN_SRC python :preamble "# -*- coding: utf-8 -*-" :var data=unicode_str
+return data
+#+END_SRC
+#+end_example
+
+#+begin_example
+#+RESULTS: ok-in-passing-var
+: “this string is not ascii!”
+#+end_example
-- 
2.1.4

Re: Division of Org documentation: Org manual and Worg

[Rasmus]

Hi Daniele,

> So... here is the patch for worg about python and utf-8!  I skipped
> the part related to the tables, since I do not have a clean
> workaround.

Thanks for contributing to Worg!

For Worg you just need to have your ssh key added.  Then you can push
changes yourself.

        http://orgmode.org/worg/worg-about.html

You can email your public ssh key to e.g. Bastien (bzg at gnu dot org).

Rasmus

-- 
You people at the NSA are becoming my new best friends!

Re: Division of Org documentation: Org manual and Worg

[Daniele Pizzolli]

On Wed, May 18 2016, Rasmus  wrote:

> Hi Daniele,
>
>> So... here is the patch for worg about python and utf-8!  I skipped
>> the part related to the tables, since I do not have a clean
>> workaround.
>
> Thanks for contributing to Worg!
>
> For Worg you just need to have your ssh key added.  Then you can push
> changes yourself.
>
>         http://orgmode.org/worg/worg-about.html
>
> You can email your public ssh key to e.g. Bastien (bzg at gnu dot org).

Hello Rasmus,

Done, just pushed the change succesfully!  I will look forward to
integrate more docs about org-mode and python.

Of course feedback are welcome!

Best,
Daniele

Re: Division of Org documentation: Org manual and Worg

[Rasmus]

Daniele Pizzolli <dan@toel.it> writes:

> Done, just pushed the change succesfully!  I will look forward to
> integrate more docs about org-mode and python.

Grazie mille!

Caio

-- 
C is for Cookie

Re: Division of Org documentation: Org manual and Worg

[Daniele Pizzolli]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

On Wed, May 18 2016, Daniele Pizzolli wrote:

> On Wed, May 18 2016, Rasmus  wrote:
>
>> Daniele Pizzolli writes:
>>
>>> It would be nice to add them to the documentation, but I have not yet
>>> figured out what is the appropriate way to send the patch!
>>
>> /That/ information happens to be on Worg :)
>>
>>        http://orgmode.org/worg/org-contribute.html
>
> Thanks Rasmus,
>
> So... here is the patch for worg about python and utf-8!  I skipped
> the part related to the tables, since I do not have a clean
> workaround.

Oops, I correct a couple of typos with this one.
Sorry for the noise.
Daniele


[-- Attachment #2: 0001-Add-caveats-about-uft-8-strings.patch --]
[-- Type: text/x-diff, Size: 2608 bytes --]

From e885c2d7654dcf78cf37e5fd5b1e104545ecbd2f Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli <dan@toel.it>
Date: Wed, 18 May 2016 11:55:00 +0200
Subject: [PATCH 1/1] Add caveats about uft-8 strings

---
 org-contrib/babel/languages/ob-doc-python.org | 52 ++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/org-contrib/babel/languages/ob-doc-python.org b/org-contrib/babel/languages/ob-doc-python.org
index 968a8bc..8acfbff 100644
--- a/org-contrib/babel/languages/ob-doc-python.org
+++ b/org-contrib/babel/languages/ob-doc-python.org
@@ -25,7 +25,7 @@
   </div>
 #+end_html
 
-* Template Checklist [10/12] 					   :noexport:
+* Template Checklist [11/14] 					   :noexport:
   - [X] Revise #+TITLE:
   - [X] Indicate #+AUTHOR:
   - [X] Add #+EMAIL:
@@ -42,6 +42,8 @@
   - [ ] Describe [[Result%20Types][Result Types]]
   - [ ] Describe [[Other]] differences from supported languages
   - [X] Provide brief [[Examples%20of%20Use][Examples of Use]]
+  - [X] Add caveats about utf-8 in strings
+  - [ ] Add caveats about utf-8 in tables
 * Introduction
 Python is a high-level, readable, interpreted language which can be
 used for many common computing tasks.  It runs on most modern
@@ -242,3 +244,51 @@ return 'images/python-matplot-fig.png' # return filename to org-mode
 
 #+end_example
 [[file:images/python-matplot-fig.png]]
+
+* Caveats
+
+You need some care in order to pass utf-8 strings to python.
+
+** passing utf-8 strings to python
+
+#+begin_example
+#+NAME: unicode_str
+,#+BEGIN_EXAMPLE
+“this string is not ascii!”
+,#+END_EXAMPLE
+#+end_example
+
+#+begin_example
+#+NAME: error-in-passing-var
+#+BEGIN_SRC python :var data=unicode_str
+return data
+#+END_SRC
+#+end_example
+
+#+begin_example
+#+RESULTS: error-in-passing-var
+#+end_example
+
+Will produce no output and prints the following message in the buffer
+=*Org-Babel Error Output*=:
+
+#+BEGIN_EXAMPLE
+  File "<stdin>", line 3
+SyntaxError: Non-ASCII character '\xe2' in file <stdin> on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
+#+END_EXAMPLE
+
+** passing utf-8 strings to python with workaround
+
+A workaround is to use =:preamble= with the value =# -*- coding:utf-8 -*-=
+
+#+begin_example
+#+NAME: ok-in-passing-var
+#+BEGIN_SRC python :preamble "# -*- coding: utf-8 -*-" :var data=unicode_str
+return data
+#+END_SRC
+#+end_example
+
+#+begin_example
+#+RESULTS: ok-in-passing-var
+: “this string is not ascii!”
+#+end_example
-- 
2.1.4

Re: Mixing Python2 and Python3 blocks in one file

[Ken Mankoff]

Hi Will,

On 2016-05-17 at 21:19, William Henney <whenney@gmail.com> wrote:
> Why is the :python parameter insufficient for your needs? You can also
> use it for different virtual environments

Can you clarify how to do this? Does it work with conda environments too?

Thanks,

  -k.

Re: Mixing Python2 and Python3 blocks in one file

[William Henney]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

Hi Ken,

On Wed, May 18, 2016 at 8:45 AM, Ken Mankoff <mankoff@gmail.com> wrote:

On 2016-05-17 at 21:19, William Henney <whenney@gmail.com> wrote:
> > Why is the :python parameter insufficient for your needs? You can also
> > use it for different virtual environments
>
> Can you clarify how to do this? Does it work with conda environments too?
>

Yes, you just have to specify ~/anaconda/envs/NAME_OF_ENV/bin/python as the
name of the interpreter

I gave a conda example in my first message to this thread, but here is
another one.  In the shell, I just made a new environment:

$ condo create --name myenv

And now, I can test it in an org file:

#+BEGIN_SRC python :python ~/anaconda/envs/myenv/bin/python :results
verbatim
import sys
return sys.path
#+END_SRC

#+RESULTS:
: ['', '/Users/will/anaconda/envs/myenv/lib/python35.zip',
'/Users/will/anaconda/envs/myenv/lib/python3.5',
'/Users/will/anaconda/envs/myenv/lib/python3.5/plat-darwin',
'/Users/will/anaconda/envs/myenv/lib/python3.5/lib-dynload',
'/Users/will/anaconda/envs/myenv/lib/python3.5/site-packages',
'/Users/will/anaconda/envs/myenv/lib/python3.5/site-packages/setuptools-20.7.0-py3.5.egg']

Note that this is not /exactly/ equivalent to doing “source activate myenv”
in a terminal shell since it does not run any activation/deactivation
scripts that you might have put in the virtual environment.  But personally
I never use that feature

Will


-- 

  Dr William Henney, Instituto de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: Type: text/html, Size: 2397 bytes --]

Re: Mixing Python2 and Python3 blocks in one file

[Ken Mankoff]

Hi Will,

Thanks for the example. This makes conda + Org work better than it has for me in the past. Unfortunately, one major issues is editing and running code outside of Org via (org-edit-special). Perhaps elpy will support conda environments soon.

On 2016-05-18 at 23:37, William Henney <whenney@gmail.com> wrote:
> #+BEGIN_SRC python :python ~/anaconda/envs/myenv/bin/python :results
> verbatim
> import sys
> return sys.path
> #+END_SRC

Anyway, for those of us using IPython, the following also works:

#+BEGIN_SRC python :python ./myenv/bin/ipython --pylab=osx --pdb --nosep --classic --no-banner --no-confirm-exit
print(np.__version__)
#+END_SRC

  -k.

Re: Mixing Python2 and Python3 blocks in one file

[William Henney]

[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]

On Thu, May 19, 2016 at 8:18 AM, Ken Mankoff <mankoff@gmail.com> wrote:

>
> Thanks for the example. This makes conda + Org work better than it has for
> me in the past. Unfortunately, one major issues is editing and running code
> outside of Org via (org-edit-special). Perhaps elpy will support conda
> environments soon.
>
>
I think Elpy works fine with conda environments - you just have to call
pyvenv-activate with the desired path.

You have inspired me to try and automate this for org source blocks (see
org snippets below).  It is a bit clunky, but I got it to work.  Let me
know what you think, and any stylistic corrections are welcome (my lisp
skills are sadly lacking).



* Automating Elpy virtual env configuration in babel source editing buffer
+ This function will automatically activate the virtual environment that
corresponds to the current python executable path
+ It should be a harmless no-op if we are not in a python buffer
  #+BEGIN_SRC emacs-lisp
    (defun wjh/elpy-pyvenv-activate-from-babel-info (info)
      "Activate relevant conda virtual env in Babel source editing buffer.
    The :python source block parameter is inspected to determine the venv."
      (let* ((python-command (or (cdr (assoc :python (nth 2 info)))
                                 org-babel-python-command))
             (venv (replace-regexp-in-string "/bin/python$" ""
python-command)))
        (when (string-match "/envs/" venv)
          (pyvenv-activate (expand-file-name venv)))))
  #+END_SRC
+ Then we need to make sure it is run whenever we edit a babel source block
by doing something like =(wjh/elpy-pyvenv-activate-from-babel-info
org-src--babel-info)=, and also to do =(pyvenv-deactivate)= when we leave
+ Unfortunately, there are no actual hooks that I can find for
=org-edit-src-code= or =org-edit-src-exit=
+ For the activation part we can co-opt the =org-babel-edit-prep:python=
function:
  #+BEGIN_SRC emacs-lisp
    (defun org-babel-edit-prep:python (info)
      (wjh/elpy-pyvenv-activate-from-babel-info info))
  #+END_SRC
  + Although this will break if =ob-python.el= decides to define
=org-babel-edit-prep:python= one day
+ For the deactivation part, I can't see any other way than to use advice
  #+BEGIN_SRC emacs-lisp
    (advice-add 'org-edit-src-exit :after #'pyvenv-deactivate)
  #+END_SRC
+ One thing we have to remember is to install the elpy python package and
dependencies in each virtual environment.  For instance:
  #+BEGIN_SRC sh
  source activate myenv
  pip install elpy rope_py3k importmagic autopep8 yapf jedi
  #+END_SRC



-- 

  Dr William Henney, Instituto de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: Type: text/html, Size: 3714 bytes --]

Re: Mixing Python2 and Python3 blocks in one file

[Ken Mankoff]

On 2016-05-19 at 15:21, William Henney <whenney@gmail.com> wrote:
> I think Elpy works fine with conda environments - you just have to
> call pyvenv-activate with the desired path.

Yes, I have discovered that since I sent my email.

> You have inspired me to try and automate this for org source blocks
> (see org snippets below). It is a bit clunky, but I got it to work.
> Let me know what you think, and any stylistic corrections are welcome
> (my lisp skills are sadly lacking).

Better than my lisp. It looks good, but I like to keep my virtual envs in the folder where the work happens. That is, I create them with =conda env create -y -p ./pyenv=. I think this means your code below will fail because it is looking for an =/envs/= folder. However, my method allows all virtual environments to always have the same name, which could make the code (and testing for the existence of that folder) easier.

> + One thing we have to remember is to install the elpy python package
> and dependencies in each virtual environment. For instance:

This can also be handled by =~./condarc= and the default packages installed whenever a virtual environment is created.

  -k.

Re: Mixing Python2 and Python3 blocks in one file

[William Henney]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On Thu, May 19, 2016 at 2:32 PM, Ken Mankoff <mankoff@gmail.com> wrote:

>
> On 2016-05-19 at 15:21, William Henney <whenney@gmail.com> wrote:
> > I think Elpy works fine with conda environments - you just have to
> > call pyvenv-activate with the desired path.
>
> Yes, I have discovered that since I sent my email.
>
> > You have inspired me to try and automate this for org source blocks
> > (see org snippets below). It is a bit clunky, but I got it to work.
> > Let me know what you think, and any stylistic corrections are welcome
> > (my lisp skills are sadly lacking).
>
> Better than my lisp. It looks good, but I like to keep my virtual envs in
> the folder where the work happens. That is, I create them with =conda env
> create -y -p ./pyenv=. I think this means your code below will fail because
> it is looking for an =/envs/= folder. However, my method allows all virtual
> environments to always have the same name, which could make the code (and
> testing for the existence of that folder) easier.
>
>
Yes, that’s right.  You can just edit the part that says (string-match
"/envs/" venv) and change "/envs/" to a regex that matches the way you name
your environments.  For instance, just the literal string "pyenv" should
work.  Or, even better, "env" would match both your convention and the
standard location.



> > + One thing we have to remember is to install the elpy python package
> > and dependencies in each virtual environment. For instance:
>
> This can also be handled by =~./condarc= and the default packages
> installed whenever a virtual environment is created.
>
>
That's good to know - thanks

Will


>   -k.
>



-- 

  Dr William Henney, Instituto de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

[-- Attachment #2: Type: text/html, Size: 3059 bytes --]