I recently ported a package to Python 3. The overall structure is
pretty straightforward:
top/
client/
module.py
server/
server.py
There's more to it, but that's enough for demonstration. I am
retaining Python 2.7 compatibility on the client side, but have
dispensed with t
On 2018 Apr 25, at 16:02, Skip Montanaro wrote:
> I recently ported a package to Python 3. The overall structure is
> pretty straightforward:
>
> top/
>client/
>module.py
>server/
>server.py
>
> There's more to it, but that's enough for demonstration. I am
> retaining Pyt
>
> If by "top/server tree" you mean that there are more subpackages under
> top.server (not just a server.py file as your diagram shows), then you need
> to filter out all of those subpackages as well, e.g.:
>
> packages = setuptools.find_packages()
> if sys.version_info.major < 3:
>
frankly, I'd give up n find_packages -- it's not that magic, it's just a
convenience function so you don't need to hand-specify them.
But in this case, you're doing something weird, so I"d just be explicit.
Though what I'd probably really do is make the client and server completely
separate packa
Yeah, splitting client and server packages is on my to-do list. Was
just hoping to keep Python2 users from shooting themselves in the foot
with a server subpackage which wouldn't work.
S
On Thu, Apr 26, 2018 at 10:59 AM, Chris Barker wrote:
> frankly, I'd give up n find_packages -- it's not that
If you're lazy, you could distribute the server package to everyone
and just make sure that if someone tries to import it on python 2 then
they get a useful error.
On Thu, Apr 26, 2018 at 9:17 AM, Skip Montanaro
wrote:
> Yeah, splitting client and server packages is on my to-do list. Was
> just h
> If you're lazy, you could distribute the server package to everyone
> and just make sure that if someone tries to import it on python 2 then
> they get a useful error.
>
Thanks, yes, that's a good suggestion. I suspect they'd get a SyntaxError
today, but as another currently active thread sugges
