python3 : help needed

[Frédéric Chapoton]

Dear all,

We have almost reached the state of vanilla sage building with SAGE_PYTHON3=yes (this does not mean working !). But something seems to go wrong, and I would like help to find and fix the current problem.

So, for people that want to do something else than answering polls, you can try the following:

In a separate install of sage, on top of 8.0.beta7, apply

https://trac.sagemath.org/ticket/23030 (git pull trac u/chapoton/23030)

and

https://trac.sagemath.org/ticket/22305 (git pull trac public/22305)

then export SAGE_PYTHON3=yes

and make build.

This should finish succesfully, with the usual message. Then try ./sage

For me, this fails with some traceback about not finding sage.repl.interpreter. Can someone help to fix that please ?

Frédéric

[John H Palmieri]

On Friday, May 19, 2017 at 9:51:46 AM UTC-7, Frédéric Chapoton wrote:

Dear all,

We have almost reached the state of vanilla sage building with SAGE_PYTHON3=yes (this does not mean working !). But something seems to go wrong, and I would like help to find and fix the current problem.

So, for people that want to do something else than answering polls, you can try the following:

In a separate install of sage, on top of 8.0.beta7, apply

https://trac.sagemath.org/ticket/23030 (git pull trac u/chapoton/23030)

and

https://trac.sagemath.org/ticket/22305 (git pull trac public/22305)

then export SAGE_PYTHON3=yes

and make build.

This should finish succesfully, with the usual message.

It took me a bit more work. First I had a problem with the Sage library, which I could fix by applying #23029. Second, conway-polynomials wouldn't build because it couldn't find six.moves, so I had to change the spkg-install script to use #!/usr/bin/env sage-python23 instead of #!/usr/bin/env python. I should also point out that even when the problem is only in conway-polynomials, the build process keeps rebuilding all of sagelib, rebuilding all of the extensions. So something is not correctly detecting that the Sage library files are already built and installed.

The docs now don't build, although now I see that you were not recommending even trying. Anyway, the error is:

/Users/palmieri/Desktop/Sage_stuff/sage_builds/TESTING/sage-8.0.beta7/local/bin/python: No module named sage_setup

I suppose it should be calling python3 or sage-python23 instead. If we're not worrying about the docs for now, that's fine with me.


Anyway, I finally got 'make build' to work and I ran into the same problem you did. One issue is that sage-ipython is being called, and its first line is #!/usr/bin/env python, which calls python2. You can change that to sage-python23 (which calls a version of Python depending on the setting of SAGE_PYTHON3). When I do that, Sage creates a crash report, saying

ModuleNotFoundError: No module named 'sage.structure.sage_object'. Indeed, when I look at local/lib/python3.6/site-packages/sage/structure, there are no .so files there. This must be related to the issues that caused constant rebuilding of the Sage library. Here are some lines from the log file:

copying build/lib.macosx-10.9-x86_64-3.6/sage/structure/sage_object.cpython-36m-darwin.so -> /Users/palmieri/Desktop/Sage_stuff/sage_builds/TESTING/sage-8.0.beta7/local/lib/python3.6/site-packages/sage/structure

and then later

Cleaning up stale file: /Users/palmieri/Desktop/Sage_stuff/sage_builds/TESTING/sage-8.0.beta7/local/lib/python3.6/site-packages/sage/structure/sage_object.cpython-36m-darwin.so

(Why isn't it just called "sage_object.so"?)

--
John



 

[John H Palmieri]

The stale file issue has been discussed before: https://groups.google.com/d/msg/sage-devel/W7FotQglFBs/RsnII556AwAJ.
 

[John H Palmieri]

If I comment out the "self.clean_stale_files()" line from src/setup.py, then I still get an error, but one you might expect from Python3: "NameError: name 'unicode' is not defined". This comes from src/sage/misc/sageinspect.py:

    if not isinstance(r, string_types):
        return ''
    elif isinstance(r, unicode):
        return r.encode('utf-8', 'ignore')
    else:
        return r

 

[Frédéric Chapoton]

Thanks, John, for the helping hand.

Yes, this unicode error will be the next one we need to handle. But first we need to understand what is going wrong before. Commenting the line in src/setup.py is certainly not the right solution..

[Frédéric Chapoton]

There are many files in src/bin with the first line being "#!/usr/bin/env python"

Should we convert all of them to cal sage-python23 or only a few critical ones ?

[John H Palmieri]

We do not have a plan for how to *run* Sage using Python3, only for how to build it: set SAGE_PYTHON3=yes. Should there be a separate command, `sage3`, which uses Python3? Or once you build with SAGE_PYTHON3=yes, should everything use Python3 aftewards? (I essentially proposed that at #22582 and did not receive any support for it.) Other options for how to run Sage using Python3? We should decide how we want to do this.

So anyway, with the current situation, we should only change files to use sage-python23 if they are used in the build process, e.g., files in build/bin or in build/pkgs/PKG_NAME/, not files in src/bin.

--
John

[John H Palmieri]

With Python 2, the .so files are just called "sage_object.so", while with Python 3, the .so files are called "sage_object.cpython-36m-darwin.so" (on OS X). Is that file name difference causing Sage to treat them as stale (= not connected to existing Sage library files) and thus removing them? I don't know what else the problem could be.

[John H Palmieri]

In the file src/sage_setup/clean.py, the variable CEXTMOD_EXTS could perhaps be modified from (on OS X) ".so" to ".cpython-36m-darwin.so". That fixes the problem for me, but I'm not what Python code to use to come with "cpython-36m-darwin". Something in distutils?

Along similar lines, building the Sage library byte-compiles the python files, and with python 3 it puts them into a subdirectory __pycache__. This subdirectory is not an expected part of the path name for Sage, so Sage then views them as stale and deletes them.

  John

[John H Palmieri]

On Saturday, May 20, 2017 at 1:12:48 PM UTC-7, John H Palmieri wrote:

In the file src/sage_setup/clean.py, the variable CEXTMOD_EXTS could perhaps be modified from (on OS X) ".so" to ".cpython-36m-darwin.so". That fixes the problem for me, but I'm not what Python code to use to come with "cpython-36m-darwin". Something in distutils?

I also have to make this change, to make sure that files named BLAH.cpython36m-darwin.so are associated with the module BLAH:

diff --git a/src/sage_setup/find.py b/src/sage_setup/find.py
index cba29bfd94..eeab051c2e 100644
--- a/src/sage_setup/find.py
+++ b/src/sage_setup/find.py
@@ -180,6 +180,7 @@ def installed_files_by_module(site_packages, modules=('sage',)):
                 module_dir = '.'.join(dirpath.split(os.path.sep))
                 for filename in filenames:
                     base, ext = os.path.splitext(filename)
+                    base = base.split('.')[0]
                     filename = os.path.join(dirpath, filename)
                     if base == '__init__':
                         add(module_dir, filename)

 

[John H Palmieri]

On Saturday, May 20, 2017 at 8:33:20 AM UTC-7, John H Palmieri wrote:

We do not have a plan for how to *run* Sage using Python3, only for how to build it: set SAGE_PYTHON3=yes. Should there be a separate command, `sage3`, which uses Python3? Or once you build with SAGE_PYTHON3=yes, should everything use Python3 aftewards? (I essentially proposed that at #22582 and did not receive any support for it.) Other options for how to run Sage using Python3? We should decide how we want to do this.

So anyway, with the current situation, we should only change files to use sage-python23 if they are used in the build process, e.g., files in build/bin or in build/pkgs/PKG_NAME/, not files in src/bin.

Along these lines, though, see https://trac.sagemath.org/ticket/23039: Sage's build breaks the ipython3 script (which is only built with `SAGE_PYTHON3=yes`).
 

[John H Palmieri]

On Saturday, May 20, 2017 at 1:12:48 PM UTC-7, John H Palmieri wrote:

In the file src/sage_setup/clean.py, the variable CEXTMOD_EXTS could perhaps be modified from (on OS X) ".so" to ".cpython-36m-darwin.so". That fixes the problem for me, but I'm not what Python code to use to come with "cpython-36m-darwin". Something in distutils?

Found it: sysconfig.get_config_var('EXT_SUFFIX')

 

[Frédéric Chapoton]

ok, now with 8.0.b8, you can just do

"export SAGE_PYTHON3=yes"

and then "make build". This should succeed, with no error message.

Then try "./sage"

This fails with some traceback about not finding sage.repl.interpreter. 

Once again, can please someone help to fix that ?

Frederic

[Kwankyu Lee]

On Thursday, May 25, 2017 at 10:49:34 AM UTC+2, Frédéric Chapoton wrote:

ok, now with 8.0.b8, you can just do

"export SAGE_PYTHON3=yes"

and then "make build". This should succeed, with no error message.

Then try "./sage"

Following your instructions, I built sage on mac. Then sage starts with no problem, strangely. So I checked the version of running python. It is 2.7.13. What should I do to run sage with python3?

Being unsure if sage was built to run with python3, I followed the instructions once more to build again. Then sage is now compiling 457 files all over again. This is not normal.

Anyway, I could not reach to the point where "./sage" crashes... Any idea what I missed?

[Frédéric Chapoton]

Very surprising that sage starts.. Did you really launch the sage that you just compiled ?

I am using Linux, and do not know anything about macs, sorry. Did you check that "echo $SAGE_PYTHON3" answered yes ?

Yes, another aspect of the same problem is this complete recompilation every time. It seems that all compiled files are just washed out for "cleanup" of sage.

I think we need some input from people that understand the build process. John already helped, but others are very welcome to give a hand. I will not be able to solve that, and this is the next step towards python3.

Frederic

[Kwankyu Lee]

On Thursday, May 25, 2017 at 4:36:04 PM UTC+2, Frédéric Chapoton wrote:

Very surprising that sage starts.. Did you really launch the sage that you just compiled ?

I suspect this as well... I will respond later when I am sure about everything. I am a bit busy for other things right now.

[John H Palmieri]

If you built Sage once normally and then rebuilt using `SAGE_PYTHON3=yes` without cleaning anything out, then all of the previously built parts might still be there, so maybe it's not too surprising that it starts up.

--
John

[Frédéric Chapoton]

ah, indeed, that's a possibility. I hope that I said loud enough not to play with SAGE_PYTHON in the usual sage install...

[John H Palmieri]

On Thursday, May 25, 2017 at 1:49:34 AM UTC-7, Frédéric Chapoton wrote:

ok, now with 8.0.b8, you can just do

"export SAGE_PYTHON3=yes"

and then "make build". This should succeed, with no error message.

Then try "./sage"

This fails with some traceback about not finding sage.repl.interpreter. 

Once again, can please someone help to fix that ?

I suggested a problem before: the script sage-ipython, which is used to start Sage, has as its first line #!/usr/bin/env python, and therefore runs Python 2, not Python 3. The next interesting line in that script is

    from sage.repl.interpreter import SageTerminalApp

Since you have built Sage with Python 3, then the Sage library is installed in local/lib/python3.6/site-libraries/sage, so Python 2 doesn't find it. Is that not the problem?

A temporary fix: change to #!/usr/bin/env sage-python23. A longer term fix: we have to decide how to run Sage with Python 3. Maybe create a script sage-ipython3 which uses #!/usr/bin/env python3 and a command-line option for sage which tells it to use Python 3? We need a design discussion about this.

--
John

 

[Frédéric Chapoton]

Hello,

I would like the design discussion to take place now, for sure. I would like that we have a clean way to build and run sage with python3, so that we can concentrate on fixing the many remaining issues inside sage code itself, with a python3 build correctly in place. The road towards a full python3 sage is still quite long, and my motivation gets weaker, as it seems that not so many people care about that.

The temporary fix you suggest does not solve the issue, maybe because I did not comment the "remove_stale_file" line before compiliing. My problem is not to find ad-hoc fixes, but to fix the build in a proper way. I do not have the technical ability to do that myself. To those who know, please open trac tickets and propose branches.

Frederic

[Kwankyu Lee]

The successful launch with my built of sage with python3 seems well explained by John.

On Thursday, May 25, 2017 at 5:37:10 PM UTC+2, Frédéric Chapoton wrote

The road towards a full python3 sage is still quite long, and my motivation gets weaker, as it seems that not so many people care about that.

This is painful.

 

A novice question about design: do we aim to make sage (1) "buildable either with python2 or with python3"  or (2) "runnable either with python2 or with python3". Am I clear enough? If (2), then you build once and then sage can be run with either python2 or with python3. I prefer (2), but I don't know which is easier to achieve. 

[John H Palmieri]

The current approach has been (1).

With (2), if we don't mind using more disk space and having a longer build time, I think the Python libraries can be dealt with: just build each twice, for local/lib/pythonX.X/site-libraries with X.X=2.7, 3.6. We do this for setuptools and pip already. Are there other components of Sage that end up in local/lib (not tagged by the Python version) that depend on the version of Python?

  John

[Frédéric Chapoton]

I have made a git branch (public/ugly_python3) with the ad-hoc changes..With this, one meets as wanted (this is my aim) a first real problem in sage-code (namely unicode in sageinspect for the moment).

Frederic

[Nils Bruin]

Thank you! I can confirm that, after a distclean, building your branch with `SAGE_PYTHON3=yes` gets me to the same point as you describe. The first few issues are fairly simple. I've pushed some coarse fixes for them to

trac u/nbruin/py3_compat

(based on your ugly_python3). I consider these more markers for where the problems are than proper fixes, because they probably break py2.

The next issue is a

TypeError: __str__ returned non-string (type bytes)

which happens in  the Parent stuff for "rings/infinity.py" somewhere. The problem is clear: we end up with some byte string from what should be a "str". I don't know where, though. Do "cdef str" objects coerce into "object" as a "str" or as a "bytes"? Probably the latter ... this could be painful.

[Nils Bruin]

incidentally, it would be nice if we could equiv local/bin/ipython with the proper sage-python23 as well. Having a functional shell with an interactive debugger is a much nicer way to debug "import sage.all".

[John H Palmieri]

On Thursday, May 25, 2017 at 4:40:01 PM UTC-7, Nils Bruin wrote:

incidentally, it would be nice if we could equiv local/bin/ipython with the proper sage-python23 as well. Having a functional shell with an interactive debugger is a much nicer way to debug "import sage.all".

This is a design question for which we do not have an answer, or even any real suggestions. Right now, SAGE_PYTHON3=yes is purely for building Sage, not for running it, and maybe long-term it should get replaced with a configure option anyway. Python conventions say that "python" should always mean "Python 2", so if we want to follow those conventions, then local/bin/python should not be sage-python23.

- Should we try to determine somehow whether Sage was built for Python 2 or Python 3, and have the script "sage" behave accordingly? (What if you've built without setting SAGE_PYTHON3 and then you rebuild with SAGE_PYTHON3=yes, without doing "make distclean" in between? With the current state of affairs, all sorts of things will break: this is a bad idea. But should you be able to do this?)

- Should we instead have a separate script "sage3" which we run using "sage --some-command-line-option"?

- Should we build everything for both versions of Python, and then let the user choose at run time?

I'm sure there are plenty of other similar questions. Does anyone have opinions on any of them, either from the point of view of user preference or the point of view of implementation?

--
John

[Nils Bruin]

On Thursday, May 25, 2017 at 4:36:49 PM UTC-7, Nils Bruin wrote:

TypeError: __str__ returned non-string (type bytes)

which happens in  the Parent stuff for "rings/infinity.py" somewhere. The problem is clear: we end up with some byte string from what should be a "str". I don't know where, though. Do "cdef str" objects coerce into "object" as a "str" or as a "bytes"? Probably the latter ... this could be painful.

Found the problem: it's in SageObject.__repr__ (triggered by the formation of an error message in sage.rings.ring.is_field). I've pushed a solution to my nbruin/py3_compat, but I don't see how to solve this in a way that works on both py2 and py3.

We're going to have a lot of unicode problems ...

Another weird one occurs in

cdef class RealNumber(sage.structure.element.RingElement):
    ....
    def __hex__(self):
        ....
    hex = __hex__

On python3, this gives a runtime error:
NameError: name '__hex__' is not defined

so it looks like the order in which class initialization code is executed is different between py2 and py3. It would be good to know how to solve alias initialization in a py3 cdef class.

[Nils Bruin]

On Thursday, May 25, 2017 at 5:07:22 PM UTC-7, John H Palmieri wrote:

On Thursday, May 25, 2017 at 4:40:01 PM UTC-7, Nils Bruin wrote:

incidentally, it would be nice if we could equiv local/bin/ipython with the proper sage-python23 as well. Having a functional shell with an interactive debugger is a much nicer way to debug "import sage.all".

This is a design question for which we do not have an answer, or even any real suggestions. Right now, SAGE_PYTHON3=yes is purely for building Sage, not for running it, and maybe long-term it should get replaced with a configure option anyway. Python conventions say that "python" should always mean "Python 2", so if we want to follow those  conventions, then local/bin/python should not be sage-python23.

I don't really care at this point. In the ugly_py3 style, it's just a good idea to equip local/bin/ipython with something that allows it to run python3 (so that sage -ipython works on a py3 build). Otherwise, there should be a local/bin/ipython3, and possibly sage -ipython can then select which exec to use. This is not about final design, it's about having the right tools to make an inventory of how badly broken sage/py3 is (and what fixes we might make).

I changed local/bin/ipython on my install, but it didn't show up in my git diff. Perhaps local/bin/ipython isn't tracked? does one make the change somewhere else? I was just looking for a way to include the change in Frederic's branch. With that branch, we're finally getting to a state where people can easily see what's wrong with Sage/Py3.

[Francois Bissey]

I am a bit surprised you can do that. I have just sent a PR to pynac
a couple of days ago to have it build with python3.
https://github.com/pynac/pynac/pull/248
I have a feeling you still a python2 pynac.

François

[Nils Bruin]

On Thursday, May 25, 2017 at 6:40:18 PM UTC-7, François wrote:

I am a bit surprised you can do that. I have just sent a PR to pynac
a couple of days ago to have it build with python3.
https://github.com/pynac/pynac/pull/248
I have a feeling you still a python2 pynac.

François

That seems about right. Possibly there are enough fixes in place to let pynac compile, but not necessarily load. With the fixes in place on
https://git.sagemath.org/sage.git/log/?h=u/nbruin/py3_compat
I now get a segfault in libpynac.so


 

[Dima Pasechnik]

On Friday, May 26, 2017 at 2:11:02 AM UTC+1, Nils Bruin wrote:

On Thursday, May 25, 2017 at 5:07:22 PM UTC-7, John H Palmieri wrote:

On Thursday, May 25, 2017 at 4:40:01 PM UTC-7, Nils Bruin wrote:

incidentally, it would be nice if we could equiv local/bin/ipython with the proper sage-python23 as well. Having a functional shell with an interactive debugger is a much nicer way to debug "import sage.all".

This is a design question for which we do not have an answer, or even any real suggestions. Right now, SAGE_PYTHON3=yes is purely for building Sage, not for running it, and maybe long-term it should get replaced with a configure option anyway. Python conventions say that "python" should always mean "Python 2", so if we want to follow those  conventions, then local/bin/python should not be sage-python23.

I don't really care at this point. In the ugly_py3 style, it's just a good idea to equip local/bin/ipython with something that allows it to run python3 (so that sage -ipython works on a py3 build). Otherwise, there should be a local/bin/ipython3, and possibly sage -ipython can then select which exec to use. This is not about final design, it's about having the right tools to make an inventory of how badly broken sage/py3 is (and what fixes we might make).

I changed local/bin/ipython on my install, but it didn't show up in my git diff. Perhaps local/bin/ipython isn't tracked?

nothing in local/ is tracked. You may see if ipython is tracked:

git ls-tree -r develop --name-only | grep ipython

The output suggests that local/bin/ipython comes from ipython spkg. 

I believe that to install ipython for python3 one must run pip3 rather than pip2

(alternatively, if ipython was installed using setup.py, one would have ran 

python3 setup.py install)

I don't understand the magic behind pip2 vs pip3 (pip acts as one of these depending upon something)

IMHO the 1st thing would be to upgrade to the current pip, before proceeding further with python3, as it seems

to be a crucial piece of infrastructure, and messing around with an old version is a waste of time.

Dima

[Francois Bissey]

> On 26/05/2017, at 15:28, Nils Bruin <nbr...@sfu.ca> wrote:
>
> On Thursday, May 25, 2017 at 6:40:18 PM UTC-7, François wrote:
> I am a bit surprised you can do that. I have just sent a PR to pynac
> a couple of days ago to have it build with python3.
> https://github.com/pynac/pynac/pull/248
> I have a feeling you still a python2 pynac.
>
> François
>
> That seems about right. Possibly there are enough fixes in place to let pynac compile, but not necessarily load. With the fixes in place on
> https://git.sagemath.org/sage.git/log/?h=u/nbruin/py3_compat
> I now get a segfault in libpynac.so

Without the above PR the build of pynac with python3 should
break. Unless you have a fix for pynac I cannot see in your
commits.

[Frédéric Chapoton]

Maybe you could make some of your changes into tickets and branches, Nils ?

I am thinking in particular about the changes relates to div, idiv, that could go into  

https://trac.sagemath.org/ticket/22875

Unicode is certainly going to be subtle to handle. Some step is being made in https://trac.sagemath.org/ticket/23044

[Frédéric Chapoton]

pip upgrade is waiting at https://trac.sagemath.org/ticket/21835 (but may not be ready)

I am working on a ticket for changes concerning ETuple and map.

[John H Palmieri]

On Thursday, May 25, 2017 at 6:11:02 PM UTC-7, Nils Bruin wrote:

On Thursday, May 25, 2017 at 5:07:22 PM UTC-7, John H Palmieri wrote:

On Thursday, May 25, 2017 at 4:40:01 PM UTC-7, Nils Bruin wrote:

incidentally, it would be nice if we could equiv local/bin/ipython with the proper sage-python23 as well. Having a functional shell with an interactive debugger is a much nicer way to debug "import sage.all".

This is a design question for which we do not have an answer, or even any real suggestions. Right now, SAGE_PYTHON3=yes is purely for building Sage, not for running it, and maybe long-term it should get replaced with a configure option anyway. Python conventions say that "python" should always mean "Python 2", so if we want to follow those  conventions, then local/bin/python should not be sage-python23.

I don't really care at this point.

Then I would say, if SAGE_PYTHON3=yes, make a symlink python -> python3 (in the ugly_py3 style).
 

In the ugly_py3 style, it's just a good idea to equip local/bin/ipython with something that allows it to run python3 (so that sage -ipython works on a py3 build). Otherwise, there should be a local/bin/ipython3, and possibly sage -ipython can then select which exec to use. This is not about final design, it's about having the right tools to make an inventory of how badly broken sage/py3 is (and what fixes we might make).

If you build Sage's IPython package with SAGE_PYTHON3=yes, then it will install a script local/bin/ipython3. (Note then that if the sage-location script runs, its function make_scripts_relative will break local/bin/ipython3 because it will replace the #! line, which initially uses Sage's Python3, to a generic /usr/bin/env python. Another broken part to fix.)

  John

 

[Nils Bruin]

On Friday, May 26, 2017 at 7:52:57 AM UTC-7, John H Palmieri wrote:

If you build Sage's IPython package with SAGE_PYTHON3=yes, then it will install a script local/bin/ipython3. (Note then that if the sage-location script runs, its function make_scripts_relative will break local/bin/ipython3 because it will replace the #! line, which initially uses Sage's Python3, to a generic /usr/bin/env python. Another broken part to fix.)

Ah, that would explain it. Data point on naming: on my fedora25, there are /usr/bin/ipython, /usr/bin/ipython2, /usr/bin/python3 (each separate files). ipython and ipython3 are identical. The ipython2 might be a historical remnant, though.

For Python, there are /usr/bin/python2.7, /usr/bin/python3.5 with /usr/bin/python a symlink pointing to /usr/bin/python2.7 (via some other symlinks).

So there seems to be precedent that the naming convention for "python" does not translate to naming convention for "ipython".

In any case, I think it would be good to ensure we at least have functioning *python2* and *python3* links. What the unnumbered names refer to is then slightly less vital.

[François Bissey]

Originally only sent to Frederic instead of the group


-------- Forwarded Message --------
Subject: Re: [sage-devel] Re: python3 : help needed
Date: Mon, 29 May 2017 10:00:25 +1200
From: François Bissey <francoi...@canterbury.ac.nz>
To: Frédéric Chapoton <fchap...@gmail.com>

On 25/05/17 20:49, Frédéric Chapoton wrote:
> ok, now with 8.0.b8, you can just do
>
> "export SAGE_PYTHON3=yes"
>
> and then "make build". This should succeed, with no error message.
>

> Then try "./sage"
>
> This fails with some traceback about not finding sage.repl.interpreter.
>

> Once again, can *please* someone help to fix that ?
>

OK, in the last few days I finally executed a plan for sage-on-gentoo
to be able to build and sage for python2.7 and python3.6 at the same time.
The main obstacle to do that are pynac and brial. pynac being the
hardest problem. I have been creative in a way that they cannot
currently be ported back to sage proper. And of course it needs a PR
I already mentioned here to build at all with python3.

In any case I have a build, with documentation courtesy of the python2.7
part.

My build is dangerously based on volker's develop branch where he
merges tickets and tests them before releasing. So I have a number
of py3 tickets included beyond 8.0.beta8 but I don't include any other
tickets.

I hear how unicode will be a problem. Well when I try sage with python3
I crash like everyone else and my trace back ends up with
/usr/lib64/python3.6/site-packages/sage/misc/sageinspect.py in
_sage_getdoc_unformatted(obj=<function CachedRepresentation.__classcall__>)
1623
1624 - William Stein
1625 - extensions by Nick Alexander
1626 """
1627 if obj is None:
1628 return ''
1629 try:
1630 r = obj.__doc__
1631 except Exception:
1632 return ''
1633
1634 # Check if the __doc__ attribute was actually a string, and
1635 # not a 'getset_descriptor' or similar.
1636 if not isinstance(r, string_types):
1637 return ''
-> 1638 elif isinstance(r, unicode):
global isinstance = undefined
r = '\n Construct a new object of this class or reuse an
existing one.\n\n See also :class:`CachedRepresentation` and\n
:class:`UniqueRepresent$
global unicode = undefined
1639 return r.encode('utf-8', 'ignore')
1640 else:
1641 return r
1642
1643
1644 def sage_getdoc_original(obj):
1645 r"""
1646 Return the unformatted docstring associated to ``obj`` as a
1647 string.
1648
1649 If ``obj`` is a Cython object with an embedded position or
signature in
1650 its docstring, the embedded information is stripped. If the
stripped
1651 docstring is empty, then the stripped docstring of
``obj.__init__`` is
1652 returned instead.
1653

NameError: name 'unicode' is not defined

Francois

[John H Palmieri]

On Friday, May 26, 2017 at 8:40:22 AM UTC-7, Nils Bruin wrote:

On Friday, May 26, 2017 at 7:52:57 AM UTC-7, John H Palmieri wrote:

If you build Sage's IPython package with SAGE_PYTHON3=yes, then it will install a script local/bin/ipython3. (Note then that if the sage-location script runs, its function make_scripts_relative will break local/bin/ipython3 because it will replace the #! line, which initially uses Sage's Python3, to a generic /usr/bin/env python. Another broken part to fix.)

Ah, that would explain it.

This issues is tracked at https://trac.sagemath.org/ticket/23039 (not that I know how to fix it properly).

  John

 

[Vincent Delecroix]

Note that __hex__ is not used anymore in py3 (calling `hex(obj)` goes
through `obj.__index__()`). What I proposed in cypari2 [1] is to use
Cython macros for py2/py3 changes. That solved all py2/py3 issues we had.

cdef class MyClass(...):
IF PY_MAJOR_VERSION == 2:
def __hex__(self):
...

IF PY_MAJOR_VERSION == 2:
def __oct__(self):
...

IF PY_MAJOR_VERSION == 2:
def __int__(self):
...

IF PY_MAJOR_VERSION == 2:
def __cmp__(self, Gen other):
...

[1] https://github.com/defeo/cypari2/pull/13

[Nils Bruin]

On Monday, May 29, 2017 at 2:08:37 AM UTC-6, vdelecroix wrote:

Note that __hex__ is not used anymore in py3 (calling `hex(obj)` goes
through `obj.__index__()`). What I proposed in cypari2 [1] is to use
Cython macros for py2/py3 changes. That solved all py2/py3 issues we had.

Ah. So apparently, cython still processes __hex__ as a special method and then discovers later there's no slot for it in Py3.
 

cdef class MyClass(...):
     IF PY_MAJOR_VERSION == 2:
         def __hex__(self):
             ...

     IF PY_MAJOR_VERSION == 2:
         def __oct__(self):
             ...

     IF PY_MAJOR_VERSION == 2:
         def __int__(self):
             ...

     IF PY_MAJOR_VERSION == 2:
         def __cmp__(self, Gen other):
             ...

That looks like a very good idea.

Note that cythonize allows for a "compile_time_env" argument, which is probably a better way to inject the binding for PY_MAJOR_VERSION than by writing and importing a "pxi" file. See for instance https://git.sagemath.org/sage.git/diff/src/setup.py?id=d34101e8c4a28181a075db0bd8aea34c94154b54 for a recent use in sage.
 

  [1] https://github.com/defeo/cypari2/pull/13