If you want a single code base and nice coding you probably need some macros... One could even define macros that produce the ugly stuff... I do not understand why everybody is not doing it this way, but I do it that way in my projects.
2011/3/11 Alex Grönholm <[email protected]> > 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]> > >> 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]> >> >>> 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]> >>> >>>> 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]> >>>> >>>>> 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]> 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]> >>>>>> >>>>>> On Wed, Mar 9, 2011 at 10:59 PM, Tomer Filiba <[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. :). >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
