[sage-devel] Re: Integration of Trac and Github

2016-05-25 Thread kcrisman
> The developer's walkthrough > says in its > third paragraph: > > You can alternatively fork and create a pull request at github > which will automatically fetch your > code and open a ticket on

Re: [sage-devel] print to python3

2016-05-25 Thread Fernando Perez
On Tue, May 24, 2016 at 9:09 PM, William Stein wrote: > Thanks for your post! The assumption in this whole thread is that > Sage supports either python2 or python3, and not both. Thanks for > questioning this assumption and pointing out that "all the major > scientific python

[sage-devel] Integration of Trac and Github

2016-05-25 Thread paulmasson
The developer's walkthrough says in its third paragraph: You can alternatively fork and create a pull request at github which will automatically fetch your code and open a ticket on our trac

Re: [sage-devel] Re: print to python3

2016-05-25 Thread Erik Bray
On Wed, May 25, 2016 at 6:54 PM, Harald Schilly wrote: > On Wed, May 25, 2016 at 6:28 PM, Nils Bruin wrote: >> In that case it might be worth considering if we can integrate our preparser >> steps into the lib2to3.refactor framework: > > I'm by far not an

Re: [sage-devel] Re: print to python3

2016-05-25 Thread Harald Schilly
On Wed, May 25, 2016 at 6:28 PM, Nils Bruin wrote: > In that case it might be worth considering if we can integrate our preparser > steps into the lib2to3.refactor framework: I'm by far not an expert on parsers, but I think forking that 2to3 part in the standard library could work

Re: [sage-devel] Re: print to python3

2016-05-25 Thread Nils Bruin
On Wednesday, May 25, 2016 at 8:23:07 AM UTC-7, Harald Schilly wrote: > > I haven't read all the posting here, but just to throw in an idea that > might not have been mentioned before: we could use this 2to3 utility in the > preparsing step. I.e. an extended pipeline like input → preparser →

Re: [sage-devel] Re: print to python3

2016-05-25 Thread Harald Schilly
On Tuesday, May 24, 2016 at 5:48:59 PM UTC+2, John Cremona wrote: > > We seem to be stuck. > I haven't read all the posting here, but just to throw in an idea that might not have been mentioned before: we could use this 2to3 utility in the preparsing step. I.e. an extended pipeline like

Re: [sage-devel] Re: print to python3

2016-05-25 Thread kcrisman
> > Most Sage users do not care a fig about Python versions, but will care > if after 10 years of being able to type "print a" they are suddenly > forced into typing "(print(a)". Iwas thinking about this from a user > perspective not a developer perspective. > > Bingo. > Also, I think the

[sage-devel] Interval Sparse/Dense Matrices

2016-05-25 Thread Nisoli Isaia
I'm thinking in implementing cython classes for mpfr_t and mpfi_t dense/sparse matrices, imitating the dense/sparse matrices for the mpq_t type. Would it be of interest for the community? Is there any previous work on the issue, ongoing discussion on the topic? Best wishes Isaia -- You

[sage-devel] Re: matrix vector product for generic sparse matrices

2016-05-25 Thread Travis Scrimshaw
Hey Nisoli, There is an important detail in what you are doing: you are multiplying a *sparse* matrix times a *dense* vector. It seems possible to me that the operation in and of itself has not been looked at too much in Sage other than the easiest solution of converting the sparse matrix to

[sage-devel] matrix vector product for generic sparse matrices

2016-05-25 Thread Nisoli Isaia
I opened a ticket due to the following issue: It seems like this simple cython code is faster 30% faster than the implemented matrix vector product for generic sparse matrices. I run some (many) tests with matrices with RIF coefficients and all seem to point in this direction. Is it possible

[sage-devel] Re: print to python3

2016-05-25 Thread Johan S . R . Nielsen
> Let me try to summarize. We seem to more or less agree that we should not > repeatedly break the code of all users of sage. To avoid that, it would be > better to switch completely to python3 in just one major change. And then > there will be something like the "last py2 release" and the

[sage-devel] Re: print to python3

2016-05-25 Thread Frédéric Chapoton
Thanks for your reactions. Let me try to summarize. We seem to more or less agree that we should not repeatedly break the code of all users of sage. To avoid that, it would be better to switch completely to python3 in just one major change. And then there will be something like the "last py2

Re: [sage-devel] print to python3

2016-05-25 Thread Jeroen Demeyer
On 2016-05-25 01:52, Nils Bruin wrote: Hasn't this been the holy grail the python community has been looking for? I don't know what you mean with "the Python community" but it's certainly not a priority for upstream CPython. If CPython really wanted to make it easier to port Python 2 code to

Re: [sage-devel] Re: print to python3

2016-05-25 Thread John Cremona
This looks helpful: http://python-future.org/compatible_idioms.html I was looking for a simple-minded person's guide to what they would actually have to change to make the transition. There is a lot of ranting out there and stuff wriiten for people for whom programming seems more and end in

[sage-devel] Re: print to python3

2016-05-25 Thread Simon King
Hi William, On 2016-05-24, William Stein wrote: > The last thing we want is: > > - I upgraded to Sage-7.3 and *all* my 100s of worksheets I use in > teaching broke due to print statements.I spent 10 hours going > through and fixing them all -- ugh. Misery. > > Then... >

[sage-devel] Re: print to python3

2016-05-25 Thread Dima Pasechnik
In fact, I would not be surprised (I'm in fact willing to bet that this will happen) if python2 were around for another 20-30 years, perhaps forked off the main python development. Suppressing a language (or a dialect) with a sizeable following is always a pain, and politically explosive, be it

Re: [sage-devel] Re: Delete old optional packages

2016-05-25 Thread Alejandro Serrano Mena
Dear all, I was the uploader of the `sip` and `PyQt4` packages. This was long ago and right now I cannot take the effort of upgrading them. As far as I know, they haven't been used for any other thing that experimentation... El miércoles, 27 de abril de 2016, 16:05:28 (UTC+2), Dima Pasechnik