On 23 Jul, 2009, at 16:29, Tarek Ziadé wrote:
On Thu, Jul 23, 2009 at 4:17 PM, Lennart Regebrorege...@gmail.com
wrote:
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
- Let's then backport the 0.8 version into a 0.7 version, compatbile
with Python 2.x and with the required bootstraping
so it
On Thu, Jul 23, 2009 at 11:59 PM, Lennart Regebrorege...@gmail.com wrote:
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
So how this will look at the end ? a conversion function that can be
called when releasing
for instance ?
Something like that. There is a port.sh script that will make a
2009/7/24 Tarek Ziadé ziade.ta...@gmail.com:
I can postpone the 0.6 release for a week or so, until this is ready, so we
can
have 0.6 for Python 3.
I think we should make a 2.x only release first. The changes to
support Python 3 are small but numerous and since the test-coverage
isn't that
On Fri, Jul 24, 2009 at 3:29 PM, Lennart Regebrorege...@gmail.com wrote:
2009/7/24 Tarek Ziadé ziade.ta...@gmail.com:
I can postpone the 0.6 release for a week or so, until this is ready, so we
can
have 0.6 for Python 3.
I think we should make a 2.x only release first. The changes to
On Jul 24, 2009, at 10:29 AM, Lennart Regebro wrote:
2009/7/24 Tarek Ziadé ziade.ta...@gmail.com:
I can postpone the 0.6 release for a week or so, until this is
ready, so we can
have 0.6 for Python 3.
I think we should make a 2.x only release first. The changes to
support Python 3 are
On Friday, 24 July, 2009, at 03:59PM, Leonardo Santagada
santag...@gmail.com wrote:
On Jul 24, 2009, at 10:29 AM, Lennart Regebro wrote:
2009/7/24 Tarek Ziadé ziade.ta...@gmail.com:
I can postpone the 0.6 release for a week or so, until this is
ready, so we can
have 0.6 for Python 3.
On Fri, Jul 24, 2009 at 4:06 PM, Ronald Oussorenronaldousso...@mac.com wrote:
I agree with Lennart that a 2.x only release would be better, especially
because it would be possible to do a 0.7 alpha/beta release short after the
stable 0.6 release.
Notice that 0.7 will rename the setuptools
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
I think you don't see my point : making a pure Python 3 version, without
any backward compatibility issues / bootstraping , fight against setuptools
distribution. Then backporting it in 0.7
But 0.8 would not be 2.x compatible.
That would mean we
On Thu, Jul 23, 2009 at 4:37 PM, Lennart Regebrorege...@gmail.com wrote:
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
I think you don't see my point : making a pure Python 3 version, without
any backward compatibility issues / bootstraping , fight against setuptools
distribution. Then
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
That's exactly how Python 2.X / 3.x are developed.
Python 2.x and 3.x are two different, incompatible versions of one
software. Of course you have different branches. We are to create one
compatible version for both Python 2 and Python 3. There is no
On Thu, Jul 23, 2009 at 5:06 PM, Lennart Regebrorege...@gmail.com wrote:
We are to create one
compatible version for both Python 2 and Python 3.
[..]
This has no significant benefits, creates more work and more
confusion. There is simply no reason to do this.
Sorry, we are not making any
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
I am not sure what to look at in there, do you have a place in there
that is based on setuptools trunk ?
Does it work with 2.x and 3.x at the same time ?
Yes, via 2to3 which for good reasons are the official way of
supporting both Python 2.x and 3.x
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
Or are you thinking about generated the 3k code at release time for
the 3.x version ?
Either release time or install time (although install time is tricky,
as setuptools currently depends on itself, so release time is the way
to go at least before a
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
So what is the work left to be done so it works fully for our code base ?
Making a diff of the work done of the google code repo, and getting it
into the hg repository.
It's not that much work, but as noted I failed (in several ways) last time. :-/
2009/7/23 Tarek Ziadé ziade.ta...@gmail.com:
So how this will look at the end ? a conversion function that can be
called when releasing
for instance ?
Something like that. There is a port.sh script that will make a port
(from a copy in /tmp/) and I used that to do the Python 3 tgz's before
if
15 matches
Mail list logo