11.03.2011 10:12, Rüdiger Kessel kirjoitti:
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.
Please point me to a single public Python project that uses such macros.
2011/3/11 Alex Grönholm <[email protected]
<mailto:[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]
<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. :).
