Alex is right, this is how I've seen all python code maintain compatibility between differing versions of packages and the python language itself. Macros have a place, but the dynamic nature of python allows us to avoiding needing them, and as a consequence considers them unpythonic.
Alex Grönholm <[email protected]> wrote: >11.03.2011 09:37, Rüdiger Kessel kirjoitti: >> I have done no porting at all, but I usually end up programming in a >> macro language in all my projects in the past. I usually do not write >> the code in the language it will be compiled at the end. What is the >> can of worms you are talking about? In my experience have 2 code basis >> are a can of worms. >Which is why I'm suggesting a SINGLE code base. >> Again, I do not have enough "Python" experience to judge this things. >> But I am looking for a powerful pre-processor for Python because I am >> starting to see the need for it in "my" projects. >> >> 2011/3/11 Alex Grönholm <[email protected] >> <mailto:[email protected]>> >> >> 11.03.2011 09:20, Rüdiger Kessel kirjoitti: >>> This looks like a perfect pre-processor task to me. Define a >>> macro "EXCEPT(a,b)" that will be converted to "except a,b" or to >>> "except a as b". Defining the macros might be a bit of work, but >>> then you could write one common source where both versions can be >>> derived from. The only disadvantage is that you need to code >>> everything in macros. That is the price of maintaining only one >>> source code base. >> No, it isn't. Nobody uses preprocessors for this, unless you count >> 2to3 as one. The correct way to do it in a way that works for both >> 2.x and 3.x is: >> >> try: >> ... >> except Exception: >> exc = sys.exc_info()[1] >> .... >> >> Preprocessors (other than 2to3) would open a whole new can of >> worms, which is totally unnecessary here. Trust me -- in all >> likelihood, I've done a lot more porting than you have :) >> >>> This is what I mean with "local" changes. If you can achieve the >>> same thing in 2.x and in 3k by changing segments of a few lines >>> each then you can use a pre-processor. But that would not lead to >>> the need of moving things between modules, doesn't it? >>> >>> 2011/3/10 Alex Grönholm <[email protected] >>> <mailto:[email protected]>> >>> >>> 11.03.2011 03:32, Rüdiger Kessel kirjoitti: >>>> I read that one, but I got the impression that changes are >>>> all local. Why would one want to move things between modules >>>> just because it uses py3k syntax? >>>> It looks to me that basically the same structures should >>>> work for both. Maybe I am missing something fundamental here. >>> The syntax changes are fairly radical. For example, how would >>> you catch named exceptions (and assign to a variable) in a >>> way that works for both 3.x and 2.x? There is an ugly but >>> workable way, but I'd just like to check if you've understood >>> the problem. >>> >>>> >>>> 2011/3/10 Alex Grönholm <[email protected] >>>> <mailto:[email protected]>> >>>> >>>> 11.03.2011 03:17, Rüdiger Kessel kirjoitti: >>>>> Sorry for being stupid. I did not see Python py3k yet. >>>>> I saw no need. I use Python because it is available >>>>> everywhere. >>>>> I thought that py3k was just some syntactical different >>>>> dialect. But obviously it is more. Does it have >>>>> completely new data types and does it not support the >>>>> types from 2.x any more? >>>> This should answer most of your questions: >>>> http://docs.python.org/release/3.0.1/whatsnew/3.0.html >>>> >>>>> >>>>> Rüdiger >>>>> >>>>> 2011/3/10 Alex Grönholm <[email protected] >>>>> <mailto:[email protected]>> >>>>> >>>>> 10.03.2011 18:27, Tomer Filiba kirjoitti: >>>>>> no, it's not really possible, because many types >>>>>> were moved between modules, or completely dropped. >>>>>> also, the object model has changed a little, and >>>>>> since netrefs play with the low-level stuff, they >>>>>> have to be adapted. >>>>>> all in all, the syntax part is the least of our >>>>>> concerns. >>>>> I've done quite a bit of py3k porting work myself, >>>>> so could you be a little more specific? Maybe I can >>>>> address those concerns. >>>>> >>>>>> >>>>>> >>>>>> -tomer >>>>>> >>>>>> An NCO and a Gentleman >>>>>> >>>>>> >>>>>> On Thu, Mar 10, 2011 at 00:41, Rüdiger Kessel >>>>>> <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Sorry for asking this stupid question, but is >>>>>> there any good python preprocessor out there >>>>>> that can support the version problem so that >>>>>> the code can look nice, but still comes from a >>>>>> common code base? >>>>>> >>>>>> Ruediger >>>>>> >>>>>> >>>>>> 2011/3/9 Jorge Maroto <[email protected] >>>>>> <mailto:[email protected]>> >>>>>> >>>>>> On Wed, Mar 9, 2011 at 10:59 PM, Tomer >>>>>> Filiba <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> > yeah, i had the feeling someone would >>>>>> sneak in redhat and >>>>>> > their nonexistent releases... >>>>>> > you know, being stuck with software from >>>>>> 2004 in 2011... how come people PAY >>>>>> > money for that "support"? >>>>>> >>>>>> IMHO they just pay to have someone to put >>>>>> the blame on. :). >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >
