From bram.degreve at gmail.com  Sat Oct 15 15:18:37 2011
From: bram.degreve at gmail.com (Bram de Greve)
Date: Sat, 15 Oct 2011 15:18:37 +0200
Subject: pyshapelib for Python 3.x
Message-ID: <4E99882D.30502@gmail.com>

Hi guys,

An former colleague asked me if pyshapelib could be compiled for Python 3.2.
Not surprisingly, it turned out not to be the case.

I want to take the task on me to port the C code, keeping it compatible 
over a whole range of Pythons (2.6, 2.7, 3.0, 3.1, 3.2), 32-bit and 64-bit.
Of course, that'll require some more macros and #ifdefs.  Does that 
sound OK?

I'm wondering about versioning though.
Would this become pyshapelib 1.1 or 1.0.1.

Regards,
Bram





From bernhard at intevation.de  Tue Oct 18 13:36:39 2011
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 18 Oct 2011 13:36:39 +0200
Subject: pyshapelib for Python 3.x
In-Reply-To: <4E99882D.30502@gmail.com>
References: <4E99882D.30502@gmail.com>
Message-ID: <201110181336.40472.bernhard@intevation.de>

Hi Bram,

Am Saturday, 15. October 2011 15:18:37 schrieb Bram de Greve:
> An former colleague asked me if pyshapelib could be compiled for Python
> 3.2. Not surprisingly, it turned out not to be the case.
>
> I want to take the task on me to port the C code, keeping it compatible
> over a whole range of Pythons (2.6, 2.7, 3.0, 3.1, 3.2), 32-bit and 64-bit.
> Of course, that'll require some more macros and #ifdefs.  Does that
> sound OK?

sounds good! 
Given the low level of maintence right now, I think it is completely
sane to keep one version together. 

> I'm wondering about versioning though.
> Would this become pyshapelib 1.1 or 1.0.1.

I'd say 1.1 or 2 because it is a major step forward.

Best,
Bernhard


-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20111018/e3a187e0/attachment.bin

From bram.degreve at gmail.com  Tue Oct 18 17:02:48 2011
From: bram.degreve at gmail.com (Bram de Greve)
Date: Tue, 18 Oct 2011 17:02:48 +0200
Subject: pyshapelib for Python 3.x
In-Reply-To: <201110181336.40472.bernhard@intevation.de>
References: <4E99882D.30502@gmail.com>
	<201110181336.40472.bernhard@intevation.de>
Message-ID: <CAJjS_7ux+siiVr2spQ9tDMOcB4_KLUs2gRS2SsXs9G9ow8LkWA@mail.gmail.com>

Hi Bernhard,

On 18 October 2011 13:36, Bernhard Reiter <bernhard at intevation.de> wrote:

> > I'm wondering about versioning though.
> > Would this become pyshapelib 1.1 or 1.0.1.
>
> I'd say 1.1 or 2 because it is a major step forward.
>
>
Then I'll go for 1.1, as this isn't a major API upgrade.

There is one little thingy though: Unicode.

So far, dbflib uses a flag called return_unicode that can be used to have
strings returned in Unicode instead of its encoded string.  That flag was
false by default.
However, the 3.x python series now uses unicode strings by default.  So I'm
thinking of reversing the default:

return types for strings, according to return_unicode flag:
2.x:
False (default) -> str
True -> unicode
3.x:
False -> bytes
True (default) -> str

What do you think?

Bram



-- 
hi, i'm a signature viruz, plz set me as your signature and help me spread
:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20111018/8343a01e/attachment.html

From bram.degreve at gmail.com  Tue Oct 18 17:04:34 2011
From: bram.degreve at gmail.com (Bram de Greve)
Date: Tue, 18 Oct 2011 17:04:34 +0200
Subject: pyshapelib: uploading windows installers?
Message-ID: <CAJjS_7tOc-0cYbdOB54cSXNdAHQ9D-6knYqtD0P73PYYyVm-eA@mail.gmail.com>

Hi,

Meanwhile, I've also created some binary installers for windows (Python 2.7,
32 & 64 bit).
Shall I upload them to the wald project page?

Bram

-- 
hi, i'm a signature viruz, plz set me as your signature and help me spread
:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.intevation.de/pipermail/thuban-devel/attachments/20111018/d7a409cf/attachment.html

From bernhard at intevation.de  Wed Oct 19 10:43:10 2011
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 19 Oct 2011 10:43:10 +0200
Subject: pyshapelib for Python 3.x
In-Reply-To: <CAJjS_7ux+siiVr2spQ9tDMOcB4_KLUs2gRS2SsXs9G9ow8LkWA@mail.gmail.com>
References: <4E99882D.30502@gmail.com>
	<201110181336.40472.bernhard@intevation.de>
	<CAJjS_7ux+siiVr2spQ9tDMOcB4_KLUs2gRS2SsXs9G9ow8LkWA@mail.gmail.com>
Message-ID: <201110191043.17422.bernhard@intevation.de>

Am Tuesday, 18. October 2011 17:02:48 schrieb Bram de Greve:
> Hi Bernhard,
>
> On 18 October 2011 13:36, Bernhard Reiter <bernhard at intevation.de> wrote:
> > > I'm wondering about versioning though.
> > > Would this become pyshapelib 1.1 or 1.0.1.
> >
> > I'd say 1.1 or 2 because it is a major step forward.
>
> Then I'll go for 1.1, as this isn't a major API upgrade.

I'd say it is a major upgrade as Python 3K is a major step.
No hard preprence, though. ;)

> There is one little thingy though: Unicode.
>
> So far, dbflib uses a flag called return_unicode that can be used to have
> strings returned in Unicode instead of its encoded string.  That flag was
> false by default.
> However, the 3.x python series now uses unicode strings by default.  So I'm
> thinking of reversing the default:
>
> return types for strings, according to return_unicode flag:
> 2.x:
> False (default) -> str
> True -> unicode
> 3.x:
> False -> bytes
> True (default) -> str

I'm sure that unicode should be default for Python 3.
As for changing the default for Python 2, I'm unsure. 
You could say that less changes if you keep the old default,
but hey, old applications could change the default back anyway
and it might be good to use the same default.
So up to you to decide in the details, I'd say.

Best,
Bernhard

-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20111019/bb7a29ce/attachment.bin

From bernhard at intevation.de  Wed Oct 19 10:43:41 2011
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 19 Oct 2011 10:43:41 +0200
Subject: pyshapelib: uploading windows installers?
In-Reply-To: <CAJjS_7tOc-0cYbdOB54cSXNdAHQ9D-6knYqtD0P73PYYyVm-eA@mail.gmail.com>
References: <CAJjS_7tOc-0cYbdOB54cSXNdAHQ9D-6knYqtD0P73PYYyVm-eA@mail.gmail.com>
Message-ID: <201110191043.42152.bernhard@intevation.de>

Am Tuesday, 18. October 2011 17:04:34 schrieb Bram de Greve:
> Meanwhile, I've also created some binary installers for windows (Python
> 2.7, 32 & 64 bit).
> Shall I upload them to the wald project page?

Sure, anything that is useful for our community or product should go there.

-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20111019/5fd3f6f0/attachment.bin

From bernhard.herzog at intevation.de  Wed Oct 26 15:40:57 2011
From: bernhard.herzog at intevation.de (Bernhard Herzog)
Date: Wed, 26 Oct 2011 15:40:57 +0200
Subject: pyshapelib for Python 3.x
In-Reply-To: <CAJjS_7ux+siiVr2spQ9tDMOcB4_KLUs2gRS2SsXs9G9ow8LkWA@mail.gmail.com>
References: <4E99882D.30502@gmail.com>
	<201110181336.40472.bernhard@intevation.de>
	<CAJjS_7ux+siiVr2spQ9tDMOcB4_KLUs2gRS2SsXs9G9ow8LkWA@mail.gmail.com>
Message-ID: <201110261540.58064.bernhard.herzog@intevation.de>

Hi Bram,

On 18.10.2011, Bram de Greve wrote:
> On 18 October 2011 13:36, Bernhard Reiter <bernhard at intevation.de> wrote:
> > > I'm wondering about versioning though.
> > > Would this become pyshapelib 1.1 or 1.0.1.
> >
> > I'd say 1.1 or 2 because it is a major step forward.
>
> Then I'll go for 1.1, as this isn't a major API upgrade.

2.0 may be better, but that depends on the unicode/bytes default. See below.

> There is one little thingy though: Unicode.
[...]
> return types for strings, according to return_unicode flag:
> 2.x:
> False (default) -> str
> True -> unicode
> 3.x:
> False -> bytes
> True (default) -> str
>
> What do you think?

We should approach this question from the point of view of an application that 
uses pyshapelib and that's being ported to Python 3. Porting to Python 3 
already introduces some uncertainties because of incompatible changes and the 
real or imagined danger that the libraries the application uses have 
potentially more bugs when used with Python 3 because they've not been 
adapted correctly yet. pyshapelib should increase those difficulties as 
little as possible.

AFAIK the recommended way to port code to Python 3 is to port to Python 2.7 
first, then if necessary change the code so that no python 3 warnings are 
printed (python -3) and then use teh 2to3 tool to convert the source to 
Python 3 code. The 2to3 can be used to maintain a python 2.7 and Python 3.x 
version at the same time, by maintaining the 2.7 version manually and 
automatically deriving the Python 3 version from that.

For that process to work for code that uses pyshapelib, it must be possible to 
have one codebase that works correctly before and after the 2to3 
transformation.

For the specific case of the default value for the unicode transformation this 
means either making the default the same for python 2.x and 3.x or 
recommending that users set the default explicitly, one way or the other.

Using unicode by default for both Python 2.x and 3.x is the best solution, I 
think. Using unicode for text is the best way to handle text in python 2.x, 
too, so libraries should encourage that. Also it leads to the following 
recommendation for users trying to port their code to Python 3:

 1. upgrade to the new pyshapelib.

    Users that currently relying on the bytes default will have to adapt their
    code at this point by changing their code to work with unicode. This is
    best for for the eventual upgrade to Python 3 anyway.

 2. upgrade to python 3.

    This will not require any pyshapelib related changes.


If the default is changed for Python 2.x, though, pyshapelib's API changes in 
an incompatible way, so using 1.0.1 as the version is definitely not a good 
idea. I'm not sure it warrants going to 2.0, but that depends on how much 
compatibility you want to guarantee for an upgrade from x.y to x.y+1. The 
conservative approach would probably be using 2.0 because some users will 
have to adapt their code.

  Bernhard


-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner