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
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
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
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
18 matches
Mail list logo
