I am in favour of any of the suggested approaches which would
let users transition at their own pace.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+un
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 libraries are py2/
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
On 2016-05-24 20:27, Johan S. R. Nielsen wrote:
2) After that, for X years, issue a deprecation warning *every time*
"print a" is used.
As I said before, I don't like this part.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fro
On 2016-05-24 20:20, Nils Bruin wrote:
figuring out where the parentheses go for other uses of print is going
to be tricky. I'm not sure something that is just regex based will do
the job.
It doesn't have to be perfect. It's already easily possible to fool the
preparser with strange constructi
On Tue, 24 May 2016, Nils Bruin wrote:
For people who use notebook servers, one could easily run a jupyter notebook
server that supports both a sage-7.* and a sage-8.0 kernel, providing a
platform to migrate from one to the other with relative ease (this will
probably be a little harder with sag
Fernando,
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 libraries are py2/3 compatible".This reminds me
again of this post
On Tue, May 24, 2016 at 1:56 PM, William Stein wrote:
> We need a real strategy for migrating users to Python3, and definitely
> not some half-way thing that deals only with the print statement.
>
Just lurking here, but that was precisely the thought that came to my mind.
For reference, what we
On Tuesday, May 24, 2016 at 1:56:56 PM UTC-7, William wrote:
>
> Hi,
>
> I've been thinking more, and I'm really disturbed by this piecemeal
> approach to getting Python 3, as least as far as it impacts *users*
> (for developers it is great).
> [...]
> For example, I'm finally using print as a
Hi,
I've been thinking more, and I'm really disturbed by this piecemeal
approach to getting Python 3, as least as far as it impacts *users*
(for developers it is great).
As mentioned before, I've been writing tons of code using Python 3 for
the last two weeks. There are *many* subtle ways in wh
On Tue, 24 May 2016, Frédéric Chapoton wrote:
I agree with Johann's proposal, with X=1 year as William proposed.
The doc will very soon already have print() everywhere.
In beta, yes. But 7.2 was just released, so it will take time for 7.3 to
be out.
I have contacted at least one author of
I agree with Johann's proposal, with X=1 year as William proposed.
The doc will very soon already have print() everywhere.
I have contacted at least one author of the French book. They want to make
a revised edition and an English traduction, and they will use print().
Who is volunteering to w
On Tue, 24 May 2016, Johan S. R. Nielsen wrote:
1) For year, issue only a deprecation *the first time* "print a" is used
in a session.
2) After that, for X years, issue a deprecation warning *every time*
"print a" is used.
3) After that, remove support for "print a" completely.
0) For a year(?
On Tue, May 24, 2016 at 11:27 AM, Johan S. R. Nielsen
wrote:
>> Breaking "print a" will cause a truly epic level of pain to our users for
>> no real gain... So much so that probably no matter what is decided here I
>> would fork sage to add handling this to the pre-processor for sage on SMC.
>> I
On Tue, May 24, 2016 at 11:20 AM, Nils Bruin wrote:
> On Tuesday, May 24, 2016 at 10:21:34 AM UTC-7, William wrote:
>>
>> Breaking "print a" will cause a truly epic level of pain to our users for
>> no real gain... So much so that probably no matter what is decided here I
>> would fork sage to ad
On Tuesday, May 24, 2016 at 10:21:34 AM UTC-7, William wrote:
>
> Breaking "print a" will cause a truly epic level of pain to our users for
> no real gain... So much so that probably no matter what is decided here I
> would fork sage to add handling this to the pre-processor for sage on SMC.
P
Breaking "print a" will cause a truly epic level of pain to our users for
no real gain... So much so that probably no matter what is decided here I
would fork sage to add handling this to the pre-processor for sage on SMC.
I'm here from endless users (eg each year at the sage booth) about minor
de
17 matches
Mail list logo
