I am wondering why no one mentions the "six" package to maintain a
temporary py2/py3-compatible codebase. I have an experience of moving my
own small project from python 2 to python 3 with the "six" package quite
successfully. The strategy was to add "import six" at every file and make
the file
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 expert on parsers, but I think forking th
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 (i.e. a lot of
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 → 2to3
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 inpu
>
> 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 l
> 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 "firs
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 r
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 itsel
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...
>
> - I upgraded to
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
We seem to be stuck. The possibilities are
(1) make "print a" just stop working at some point (maybe not yet)
(2) as (1) but with a deprecation warning
(3) continue to support "print a" for ever.
All three have had some negative votes!
Jeroen, I also do not like "endless" deprecation warnings,
On 2016-05-24 15:27, Travis Scrimshaw wrote:
every time, not just the first
-1. We should not annoy our users with endless deprecation warnings.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving e
On Tuesday, May 24, 2016 at 7:55:49 AM UTC-5, vdelecroix wrote:
>
> On 24/05/16 07:48, John Cremona wrote:
> > On 24 May 2016 at 13:17, Jeroen Demeyer > wrote:
> >> On 2016-05-24 14:06, John Cremona wrote:
> >>>
> >>> Would it be possible for
> >>>
> >>> sage: a=3
> >>> sage: print a
> >
On 24/05/16 07:48, John Cremona wrote:
On 24 May 2016 at 13:17, Jeroen Demeyer wrote:
On 2016-05-24 14:06, John Cremona wrote:
Would it be possible for
sage: a=3
sage: print a
to work on the command line, using the preparser?
That already works today.
But would it still work after a to
On Tue, 24 May 2016, John Cremona wrote:
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.
You
On 24 May 2016 at 13:17, Jeroen Demeyer wrote:
> On 2016-05-24 14:06, John Cremona wrote:
>>
>> Would it be possible for
>>
>> sage: a=3
>> sage: print a
>>
>> to work on the command line, using the preparser?
>
>
> That already works today.
But would it still work after a total conversion of Sag
On 2016-05-24 14:06, John Cremona wrote:
in code (*.py) files.
For .py code files, there is not really an issue since those can just do
from __future__ import ...
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group an
On 2016-05-24 14:06, John Cremona wrote:
Would it be possible for
sage: a=3
sage: print a
to work on the command line, using the preparser?
That already works today.
If you want that to continue working, it's better to not switch to
Python 3 style printing. It's kind of silly to change Sage
On 24 May 2016 at 12:33, Frédéric Chapoton wrote:
> Hello everybody,
>
> we are now almost ready to try to use the Python 3 print() function
> everywhere in Sage: doctests, command-line, notebook.
> This big switch is the aim of ticket http://trac.sagemath.org/ticket/20668.
> It still has to wait
Hello everybody,
we are now almost ready to try to use the Python 3 print() function
everywhere in Sage: doctests, command-line, notebook.
This big switch is the aim of ticket http://trac.sagemath.org/ticket/20668.
It still has to wait for an update of sagenb and for the next beta.
This is an *
Hello,
concerning changing the behaviour of print to python3 style,
There are still a few tickets needing review:
http://trac.sagemath.org/query?status=!closed&component=python3
Frederic
Le mardi 3 mai 2016 20:50:21 UTC+2, Frédéric Chapoton a écrit :
>
> Hello,
>
> I am trying to move toward
Because if you do that now, it triggers doctests failure all over the place.
Le lundi 16 mai 2016 11:49:45 UTC+2, Jeroen Demeyer a écrit :
>
> On 2016-05-16 11:34, Frédéric Chapoton wrote:
> > Once this is done, the plan is
> > to add "from __future__ import print_function" to src/sage/all.py.
On 2016-05-16 11:34, Frédéric Chapoton wrote:
Once this is done, the plan is
to add "from __future__ import print_function" to src/sage/all.py.
Why only "once this is done". What makes that file so special?
--
You received this message because you are subscribed to the Google Groups
"sage-dev
Hello,
I think we have made a good step towards using the python 3 print style.
There are many tickets with positive review already done on the way. Let us
hope that they will enter sage soon. Once this is done, the plan is to add
"from __future__ import print_function" to src/sage/all.py.
htt
Is it strictly needed, no. However, it allows us to be compatible with
Python3 and it helps prevent anyone in the future from adding code that is
only works in Python2 wrt print statements. Furthermore, most of the
docstrings can be made 2/3 compliant and don't need "fancy" print_function
st
I already commented on one of these tickets that I do not understand why
`from __future__ import print_function`
is needed everywhere.
Indeed, most modules do not do nontrivial printing anywhere, except perhaps
docstrings
(and the latter are not affected by that import anyway).
Dima
On Tuesday,
27 matches
Mail list logo
