Re: [Python-Dev] Changing the Division Operator -- PEP 238, rev 1.12

Guido van Rossum <guido@python.org> writes:
Cool, thanks.
I like this a lot -- I hope we can add this to 2.2a2 (which was due today but is postponed for at least a week).
Well, I'm off sunseeking in a week; I'd hope it can get it done by then.
I think the integral flags to compile() are fine,
Noted.
and 'or' is indeed the right thing.
Hmm. While I agree that 'or'ing is the best thing to do by default, it would be nice if there was some way of requesting a blank starting point (this is the other unresolved issue in PEP 236, after all). Maybe it's not worth it.
After reading the PEP, I understand the refactoring that I complained about in a comment on the patch.
OK.
Good job!
It's not done yet (and I thought this was a dead simple change!). I've uploaded a new patch, which takes Tim's suggestion of using the _Feature objects and runs with it. I'd appreciate it if you and Tim could cast an eye over it - if you think the apprach is sound then I'll update my PEP and draft some changes to 236. Cheers, M. -- Presumably pronging in the wrong place zogs it. -- Aldabra Stoddart, ucam.chat

I hope Tim can do this -- I need to take a break from chores. --Guido van Rossum (home page: http://www.python.org/~guido/)

[Michael Hudson]
Well, there's no reason at all to believe that whatever future statements IDLE and doctest (for examples) happen to use in their own implementations are also appropriate for the user-code they're simulating. So the problem isn't solved in full unless that connection can be broken (is that hard? offhand it *sounds* like it just needs another yes/no argument). OTOH, IDLE and doctest (for examples) can easily enough be written to use no future-stmts at all of their own, so that code compiled from them gets a blank starting point. Whether that remains easy down the road depends on how silly we get in introducing stupid future stmts <0.9 wink>.

I hope Tim can do this -- I need to take a break from chores. --Guido van Rossum (home page: http://www.python.org/~guido/)

[Michael Hudson]
Well, there's no reason at all to believe that whatever future statements IDLE and doctest (for examples) happen to use in their own implementations are also appropriate for the user-code they're simulating. So the problem isn't solved in full unless that connection can be broken (is that hard? offhand it *sounds* like it just needs another yes/no argument). OTOH, IDLE and doctest (for examples) can easily enough be written to use no future-stmts at all of their own, so that code compiled from them gets a blank starting point. Whether that remains easy down the road depends on how silly we get in introducing stupid future stmts <0.9 wink>.
participants (3)
-
Guido van Rossum
-
Michael Hudson
-
Tim Peters