From: Yuri T. <qar...@gm...> - 2008-12-05 04:21:42
|
> Seeing the code won't run as-is (the user still needs to run 2to3) in > 3.0, I do *not* think we should be adding this version check. > Obviously, if we are supporting 3.0 (through 2to3) that should be > documented and a note about this could be made there. I suppose a > comment in the source could help as well. When we make a release, the user should be able to download a py3k version and just install it. We just shouldn't keep the py3k version in our git tree. Our git tree should have 3.0-friendly code that runs as is with python 2.3, 2.4, 2.5 and 2.6. (Again, we can drop 2.3 at some point, if there is a good reason.) "3.0-friendly" means that if you run it through 2to3, it would work with py3k without further changes. People who want to contribute patches should always do so against the 2.x version. When we make a release, however, we can publish two versions simultaneously, from the same code base: git -> zip -> "markdown-2.0.zip" git -> 2to3 -> zip -> "markdown-2.0-py3k.zip" We don't _have_ to do this for 2.0, since at this point people who want to run py3k will know how to run 2to3, but we'll have to get to doing this eventually and we might as well start now. (It doesn't look like we have to do much additional work for this.) > Hmm, it's not failing for me in 2.5. I haven't installed 2.6 yet. My > understanding is that that is where we should be testing before > running 2to3. I'll have to investigate further. It fails for me in 2.5. BTW, it looks like we (actually, probably I) broke 2.4 compatibility at some point. - yuri -- http://sputnik.freewisdom.org/ |