I do not understand why the Python compiler does not support all syntax and you tell him at the beginning what syntax you want to use.
I do not know much of Python as I said before, but I was never interested how other people limit their doing or thinking. I try to do what is practical. Programming is not a religion for me. At the end nobody is doing it because nobody is doing it. Anyhow, I was just asking stupid questions and since you all have uch more experience than me I was interested in your answers. Thank you. I will be not much help in the porting. 2011/3/11 Rüdiger Kessel <[email protected]> > 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. :). >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >
