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. :).












Reply via email to