okay... we'll go with one-codebase-to-rule-them-all... macros are out of the question, obviously, and branches would be too hard to maintain. modules that have significant changes will be duplicated (most likely only brine and vinegar), and all the others will be written cross-compatible.
An NCO and a Gentleman 2011/3/11 Alex Grönholm <[email protected]> > 11.03.2011 10:20, Rüdiger Kessel kirjoitti: > > 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. > > Because then the Python maintainers would have to support old, flawed > designs that were dropped in v3.0. If you want 2.x syntax you'll have to use > a 2.x interpreter. Sometimes it's a good idea for the snake to shed its old > skin :) > > > 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. > > You method is not the most practical one here, that's why it's not being > done. > > > 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. :). >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > >
