On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Jeffrey Yasskin] > > The other 3 methods > > specified by PEP 3141 aren't strictly necessary for 2.6, but they will > > be needed for 3.0. I'd rather not make the two versions of Decimal > > gratuitously different, so this patch puts them in the 2.6 version > > too. > > If I understand you correctly, then the patch backports magic methods that do > not have corresponding invocation methods in Py2.6. > So, they are basically useless. If that's true, then the patch is clutter -- > it makes 2.6 less desirable. It is not obvious to me > how this will help someone transition to Py3.0. I'm curious to hear how > Guido makes the call on this. > > Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds > with previous discussions where I believe we said that > that is *not* the goal and will likely not even be possible in many cases. > Besides, if the invocation of the magic methods is > different in 3.0, how are you going to keep the test suite code the same > across versions?
I tend to agree. 2.6 and 3.0 decimal already differ plenty. > There should probably be a PEP sets clearer guidelines about what should be > backported from Py3.0. Can you volunteer a draft? It could be PEP 3003. I'm probably too close to 3.0 to be able to objectively write this, which really represents end users' desire for stability in 2.6. > Perhaps something like this: > * If there is a new feature that can be implemented in both and will make > both more attractive, then it should be in both. > * If something is going away or changing in 3.0, then the 2.6 conversion tool > mode should warn about it if possible. > * If neither of the above apply, then leave 2.6 alone. > > > I'm not > > sure exactly what you're objecting to. Could you be more precise? > > You note said: "I'll implement Context.round() in a separate patch. Comment > away." > > Unless I misread what you're trying to do, that is a gratuitous API build-out > (whether talking about Py2.6 or Py3.0) which adds a > second-way-to-do-it to a module that already has a huge number of methods. > Our goal is to keep that module as a minimal > implementation of the spec. Fattening the API will make the module harder to > use, not simpler. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
