Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread peter green

but this leads later to

Traceback (most recent call last):
   File "cycle.py", line 83, in OnCloseWindow
 Save_Cycle(cycle.name, cycle.passwd, cycle.file)
   File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 
46, in Save_Cycle
 tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) )
TypeError: can only concatenate str (not "bytes") to str

String handling changed significantly between python2 and python3. Python 2 is "byte strings by 
default", type "str" was used for byte strings and type "unicode" was used for 
unicode strings. Implicit conversions between the two were allowed.

Python 3 is "unicode by default", type "bytes" is used for byte strings and type 
"str" is used for unicode strings. There is no implict conversion between unicode strings and byte 
strings.

"pickle.dumps" returned a bytes object, and you tried to concatenate it to a 
str object. You need to change 'Cycle' to b'Cycle'.

Also python 3 bytes objects behave a bit differently from python 2 str objects. 
To accommodate this I believe you need the following changes in p_rotor.py

"|for c in map(ord, buf):|" -> "|for c in buf:|"
"|return ''.join(map(chr, outbuf))|" -> "|return bytes(outbuf)|"
"|for c in map(ord, key):|" -> "for c in key:"



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread Michael Kesper
Hi,

On 12.09.19 16:09, Andreas Tille wrote:
> May be some final helping hint could be how to fix leaving the 
> program that leads to:
> 
> 
> Traceback (most recent call last): File "/usr/bin/cycle", line 83,
> in OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file)
> File "/usr/share/cycle/save_load.py", line 27, in Save_Cycle 
> m.update(passwd) TypeError: Unicode-objects must be encoded before 
> hashing
> 
> 
> I tried
> 
> m.update(passwd.encode())
> 
> but this leads later to
> 
> Traceback (most recent call last): File "cycle.py", line 83, in 
> OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file) File 
> "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", 
> line 46, in Save_Cycle tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) 
> ) TypeError: can only concatenate str (not "bytes") to str
> 
> 
> Since I do not have much experience with hashlib I'd be happy if 
> someone might be able to proof-read `def Save_Cycle` in 
> save_load.py.

This does not have anything to do with hashlib per se.
It's just the usual mess of mixing bytestrings with strings.
You often don't notice in Python2, it just introduces subtle bugs.
Python3 is more strict here and doesn't allow it.

Try this:

tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

As an explanation:

Python 3.7.3 (default, Apr  3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> s = 'abc123üöß'
>>> objSave = pickle.dumps(s)
>>> objSave
b'\x80\x03X\x0c\x00\x00\x00abc123\xc3\xbc\xc3\xb6\xc3\x9fq\x00.'
>>> type(objSave)

>>> print('Cycle'+pickle.dumps(objSave))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can only concatenate str (not "bytes") to str
>>> print('Cycle{}'.format(pickle.dumps(objSave)))
Cycleb'\x80\x03C\x16\x80\x03X\x0c\x00\x00\x00abc123\xc3\xbc\xc3\xb6\xc3\x9fq\x00.q\x00.'

Best wishes
Michael

P.S.: The code is in a bad state regarding whitespace / indentation.
This is critical to get right in Python (e.g. after a for there _has to_
be an indentation added, Python normally uses four spaces, no tabs).




signature.asc
Description: OpenPGP digital signature


Re: should Debian add itself to https://python3statement.org ?

2019-09-12 Thread Mo Zhou
Hi Drew,

https://release.debian.org/transitions/html/python2-rm.html

Given the current progress it looks not easy to make a promise.
If some upstream happen to lag behind the schedule of python3
migration, we'll just stuck there for a while.

On 2019-09-12 14:46, Drew Parsons wrote:
> https://python3statement.org/ is a site documenting the projects which
> are supporting the policy of dropping Python2 to keep Python3 only.
> 
> The site is designed for python packages specifically, to have only
> Python3 supported by end of 2020.
> 
> But it seems to me it would be in the spirit of the site to add
> Debian's pledge to remove Python2 (we are currently in the middle of
> doing just that).
> 
> Is this a thing that we want to do as a project, to add Debian to
> https://python3statement.org/ ?
> 
> Drew



Re: should Debian add itself to https://python3statement.org ?

2019-09-12 Thread Paul Gevers
Hi,

On 12-09-2019 17:01, Ian Jackson wrote:
> But we need to be clear what's going on and communicate early.

Yes, not on the front page, but there is (first bullet):

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components

Paul



signature.asc
Description: OpenPGP digital signature


Re: should Debian add itself to https://python3statement.org ?

2019-09-12 Thread Matthias Klose

On 12.09.19 17:01, Ian Jackson wrote:

Drew Parsons writes ("should Debian add itself to https://python3statement.org  
?"):

https://python3statement.org/ is a site documenting the projects which
are supporting the policy of dropping Python2 to keep Python3 only.


That statement is a *pledge* to drop support for python2 by the end of
2020.  Have we in fact made such a pledge ?  I think I may have missed
the memo that python2 would be removed from bullseye.

I did some searching and found this
   https://lists.debian.org/debian-python/2019/07/msg00080.html
which is a sane-looking transition plan but doesn't seem to have a
timeframe and doesn't seem to contemplate removal of the actual
python2 interpreter.

FTAOD I don't have an opinion about whether bullseye *should* ship
without python2.  Obviously dropping it would not be desirable from
users' pov, but maintaining an ancient thing by ourselves would not be
desirable either.  I think I trust the Debian Python team to make that
tradeoff.

But we need to be clear what's going on and communicate early.  If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...


it's communicated here:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-python@lists.debian.org

derived from
https://release.debian.org/transitions/html/python2-rm.html (not perfect, we are 
still missing bug reports).



it's way too early to mark all of these as RC.

No, it's not yet decided if Python2 will be part of bullseye.  But the python 
command and the unversioned python packages won't be part of bullseye.






thanks,
Ian.





Re: should Debian add itself to https://python3statement.org ?

2019-09-12 Thread Ian Jackson
Drew Parsons writes ("should Debian add itself to https://python3statement.org  
?"):
> https://python3statement.org/ is a site documenting the projects which 
> are supporting the policy of dropping Python2 to keep Python3 only.

That statement is a *pledge* to drop support for python2 by the end of
2020.  Have we in fact made such a pledge ?  I think I may have missed
the memo that python2 would be removed from bullseye.

I did some searching and found this
  https://lists.debian.org/debian-python/2019/07/msg00080.html
which is a sane-looking transition plan but doesn't seem to have a
timeframe and doesn't seem to contemplate removal of the actual
python2 interpreter.

FTAOD I don't have an opinion about whether bullseye *should* ship
without python2.  Obviously dropping it would not be desirable from
users' pov, but maintaining an ancient thing by ourselves would not be
desirable either.  I think I trust the Debian Python team to make that
tradeoff.

But we need to be clear what's going on and communicate early.  If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...

thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Getting rid of debian-python.readthedocs.io ?

2019-09-12 Thread Louis-Philippe Véronneau
Hi!

Often I stumble on this readthedocs.io [1] website and it's badly outdated.

Since we already have the Debian Wiki, I'm not sure it's worth keeping
up to date, or at least no one has cared to do so in the last 4 years.
If we really want a sphinx website, we should just build one on Salsa [2].

Is there anyone here with access to that page? I think we should remove
it, but if people want to keep it, at least we should update it :)

[1]: https://debian-python.readthedocs.io/en/latest/debian-policy.html
[2]: https://wiki.debian.org/Salsa/Doc#Web_page_hosting

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Streamlining the use of Salsa CI on team packages

2019-09-12 Thread Louis-Philippe Véronneau
On 19-09-10 14 h 09, Hans-Christoph Steiner wrote:
> 
> 
> Gregor Riepl:
>>
>>> I am not a fan of pointing to a moving target with the "include" statement:
>>>
>>> include:
>>>   - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
>>>   -
>>> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
>>>
>>> "master" will change, and that can break CI jobs where nothing in the
>>> local repo has changed.
>>
>> It does have pros and cons.
>>
>> The good: Additional build/verification steps or even automatic deployment 
>> can
>> be added by the Salsa team at some point without requiring changes to each
>> repository.
>>
>> The bad: As you mentioned, a moving target can be bad and cause inadvertent
>> build failures and other issues that are out of the hands of maintainers.
>>
>> The ugly: Pulling in external scripts always bears a certain risk. They may 
>> go
>> away at some point or cause potentially dangerous side effects.
>>
>> However, I do think that a standardised CI pipeline is very useful. Consider
>> that the buildd infrastructure also uses a standardised build process that
>> packages cannot simply get away from. If this process is replicated on Salsa,
>> with an external script or not, people will quickly get a "glimpse" of what
>> would happen on buildd. The need to manually adapt the CI script every time
>> something changes in the buildd process is a heavy burden to bear and will
>> easily lead to people "forgetting" to update their scripts. That kind of
>> defeats the purpose.
>>
>> Also, consider that the Salsa CI pipeline is not an absolute source of truth,
>> but a tool for developers and maintainers to quickly spot issues with their
>> packages. If an autobuild fails, it's not the end of the world. It just means
>> you have to go check what's going on.
>>
> 
> I totally agree about having a standardized build process and CI
> pipeline.  And I agree that the CI builds are a tool, not the final
> release build process.

I think we all agree on that :)

I'd like to start working on a draft modification to the DPMT and PAPT
to add a part about using Gitlab CI, but I'm not sure what the process
to change those files is...

How were previous modifications dealt with?

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


should Debian add itself to https://python3statement.org ?

2019-09-12 Thread Drew Parsons
https://python3statement.org/ is a site documenting the projects which 
are supporting the policy of dropping Python2 to keep Python3 only.


The site is designed for python packages specifically, to have only 
Python3 supported by end of 2020.


But it seems to me it would be in the spirit of the site to add Debian's 
pledge to remove Python2 (we are currently in the middle of doing just 
that).


Is this a thing that we want to do as a project, to add Debian to 
https://python3statement.org/ ?


Drew



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread Andreas Tille
On Thu, Sep 12, 2019 at 01:57:32PM +0500, Andrey Rahmatullin wrote:
> > > There are circular imports in the code so you most likely broke that by
> > > reordering imports in various files.
> > 
> > s/you most likely broke/2to3 most likely broke/
> 2to3 doesn't do that. You mentioned autopep8, it could do that.

Ahhh, well, that might be another way to mess up the sequence.  Put a
mental note to warn me about autodep8.
 
> > So may be I misinterpreted your hint but even reverting the reordering
> > of 2to3 in my latest commit does not help.
> I also said that other changes may be problematic too. I didn't check
> them.

OK, I redid the patching in git[1] now.  Some more wxPython 4 porting
was needed as well but I somehow got the user interface working.  May be
some final helping hint could be how to fix leaving the program that
leads to:


Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 27, in Save_Cycle
m.update(passwd)
TypeError: Unicode-objects must be encoded before hashing


I tried

  m.update(passwd.encode())

but this leads later to

Traceback (most recent call last):
  File "cycle.py", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 
46, in Save_Cycle
tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) )
TypeError: can only concatenate str (not "bytes") to str


Since I do not have much experience with hashlib I'd be happy if someone
might be able to proof-read `def Save_Cycle` in save_load.py.

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/cycle

-- 
http://fam-tille.de



Bug#940102: RFS: flask-jwt-simple/0.0.3-1 [ITP] -- Protecting flask endpoints with JSON Web Tokens (Python 3)

2019-09-12 Thread Emmanuel Arias
Package: sponsorship-requests
Severity: wishlist
Owner: Emmanuel Arias 
X-Debbugs-CC:  debian-python@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "flask-jwt-simple"

 * Package name: flask-jwt-simple
   Version : 0.0.3-1
   Upstream Author : Landon Gilbert-Bland
 * URL : https://github.com/vimalloc/flask-jwt-simple
 * License : MIT
 * Vcs :
https://salsa.debian.org/python-team/modules/python-flask-jwt-simple
   Section : python

It builds those binary packages:

  python3-flask-jwt-simple - Protecting flask endpoints with JSON Web
Tokens (Python 3)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/flask-jwt-simple

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/f/flask-jwt-simple/flask-jwt-simple_0.0.3-1.dsc

Changes since the last upload:

   * Initial release (Closes: #934101)

Regards,

--
  Emmanuel Arias


Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-12 Thread Andrey Rahmatullin
On Thu, Sep 12, 2019 at 08:30:20AM +0200, Thomas Goirand wrote:
> I wont comment on the relative import ambiguity problem, as Ghislain
> replied correctly. However, I do want to comment on 2to3.
> 
> I generally recommend against using it, in the favor of other tools. For
> example, you can use sixer, which I maintain in Debian, and often used
> (and abused) to do Python 3 conversions. There's also 2to6, which I
> don't know much about, but I've read it works about the same way as
> sixer (which was specifically written for OpenStack).
> 
> The advantage is that you'll get a source code that will work on both
> Python 2 and 3. It's generally a way more easy to submit upstream, which
> may not want to loose Python 2 compatibility.
I can add to this that it's non-trivial to convert from six to normal Py3
code, unless there are some tools that I didn't find. And it's really time
to do that, not to convert TO six.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread Andrey Rahmatullin
On Thu, Sep 12, 2019 at 09:17:08AM +0200, Andreas Tille wrote:
> > > $ cycle
> > > Traceback (most recent call last):
> > >   File "/usr/bin/cycle", line 12, in 
> > > from dialogs import *
> > >   File "/usr/share/cycle/dialogs.py", line 8, in 
> > > from cal_year import cycle, Val
> > >   File "/usr/share/cycle/cal_year.py", line 9, in 
> > > from dialogs import Note_Dlg
> > > ImportError: cannot import name 'Note_Dlg' from 'dialogs' 
> > > (/usr/share/cycle/dialogs.py)
> > There are circular imports in the code so you most likely broke that by
> > reordering imports in various files.
> 
> s/you most likely broke/2to3 most likely broke/
2to3 doesn't do that. You mentioned autopep8, it could do that.

> > "from cal_year import *; from dialogs import *" works, the reverse
> > doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
> > about other changes.
> 
> I can not confirm that
> 
>from cal_year import *
> 
> works at all.  It works in the unpatched Python2 version.
I was just saying that (in the unpatched Python2 version) "from cal_year
import *; from dialogs import *" works, the reverse doesn't, and the
patched version contains the reverse.

>git clone https://salsa.debian.org/med-team/cycle
>cd cycle
>echo "from cal_year import *" | python
>quilt push -a
>echo "from cal_year import *" | python3
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line 
> 9, in 
> from dialogs import Note_Dlg
>   File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line 
> 12, in 
> from cal_year import cycle, Val
> ImportError: cannot import name 'cycle' from 'cal_year' 
> (/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py)
> 
> 
> So may be I misinterpreted your hint but even reverting the reordering
> of 2to3 in my latest commit does not help.
I also said that other changes may be problematic too. I didn't check
them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: pybuild mysteriously does not copy all testfiles

2019-09-12 Thread Debian/GNU
On 10.09.19 16:14, Ole Streicher wrote:
> Hi IOhannes,
> 
> I have basically the same problem, funnily with almost the same subject:

which was entirely intentional :-)

i decided to start a new thread because i'm not sure whether the problem
is really the same.

but i guess, i'll just file a bug against dh-python...

dfasdr
IOhannes



Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-12 Thread Andreas Tille
Hi Michael,

On Thu, Sep 12, 2019 at 09:22:06AM +0200, Michael Kesper wrote:
> On 12.09.19 08:30, Thomas Goirand wrote:
> > I wont comment on the relative import ambiguity problem, as Ghislain
> > replied correctly. However, I do want to comment on 2to3.
> > 
> > I generally recommend against using it, in the favor of other tools. 
> ...
> > 
> > The advantage is that you'll get a source code that will work on both
> > Python 2 and 3. It's generally a way more easy to submit upstream, which
> > may not want to loose Python 2 compatibility.
> 
> We should stop caring about that.
> Python2 will be EOL'ed at January 1, 2020 [0].
> Python2 will vanish from next Debian release.
> Please convert into idiomatic Python3 code, that's the sane way going forward.

I agree here.  @Thomas:  We talked about sixer at DebConf (thanks for
the hint in any case).  But I consider the additional dependency it
introduces something I'd like to avoid if possible.  So I first try my
luck with 2to3 (and I admit I observed some surprises which did not made
me that lucky at all) before I'd use sixer as fallback.

Kind regards

   Andreas.

-- 
http://fam-tille.de



Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-12 Thread Michael Kesper
Hi all,

On 12.09.19 08:30, Thomas Goirand wrote:
> I wont comment on the relative import ambiguity problem, as Ghislain
> replied correctly. However, I do want to comment on 2to3.
> 
> I generally recommend against using it, in the favor of other tools. 
...
> 
> The advantage is that you'll get a source code that will work on both
> Python 2 and 3. It's generally a way more easy to submit upstream, which
> may not want to loose Python 2 compatibility.

We should stop caring about that.
Python2 will be EOL'ed at January 1, 2020 [0].
Python2 will vanish from next Debian release.
Please convert into idiomatic Python3 code, that's the sane way going forward.

Best regards
Michael

[0] https://github.com/python/devguide/pull/344
https://pythonclock.org/



signature.asc
Description: OpenPGP digital signature


Re: Request to join PAPT

2019-09-12 Thread Christopher Hoskin
Hello,

Is someone able to make me a member of PAPT on Salsa, please?

Thanks.

Christopher

On Wed, 4 Sep 2019 at 20:51, Christopher Hoskin  wrote:
>
> Hello,
>
> Please could I join PAPT in order to maintain a pympress package [1].
> I am a Debian Developer and already a member of DPMT. I have read and
> agreed to [2].
>
> Thanks,
>
> Christopher
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935151
> [2] 
> https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread Andreas Tille
Hi Andrey,

On Wed, Sep 11, 2019 at 07:32:33PM +0500, Andrey Rahmatullin wrote:
> > $ cycle
> > Traceback (most recent call last):
> >   File "/usr/bin/cycle", line 12, in 
> > from dialogs import *
> >   File "/usr/share/cycle/dialogs.py", line 8, in 
> > from cal_year import cycle, Val
> >   File "/usr/share/cycle/cal_year.py", line 9, in 
> > from dialogs import Note_Dlg
> > ImportError: cannot import name 'Note_Dlg' from 'dialogs' 
> > (/usr/share/cycle/dialogs.py)
> There are circular imports in the code so you most likely broke that by
> reordering imports in various files.

s/you most likely broke/2to3 most likely broke/

I admit I did not really checked what 2to3 created but I can assure you
I did not simply fired up an editor and had fun reverting some import
sequences.

> "from cal_year import *; from dialogs import *" works, the reverse
> doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
> about other changes.

I can not confirm that

   from cal_year import *

works at all.  It works in the unpatched Python2 version.

   git clone https://salsa.debian.org/med-team/cycle
   cd cycle
   echo "from cal_year import *" | python
   quilt push -a
   echo "from cal_year import *" | python3
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line 
9, in 
from dialogs import Note_Dlg
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line 
12, in 
from cal_year import cycle, Val
ImportError: cannot import name 'cycle' from 'cal_year' 
(/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py)


So may be I misinterpreted your hint but even reverting the reordering
of 2to3 in my latest commit does not help.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-12 Thread Thomas Goirand
On 9/10/19 7:50 AM, Andreas Tille wrote:
> Hi,
> 
> in the process of the Python3 migration the package lefse was converted
> using 2to3.

Hi Andreas,

I wont comment on the relative import ambiguity problem, as Ghislain
replied correctly. However, I do want to comment on 2to3.

I generally recommend against using it, in the favor of other tools. For
example, you can use sixer, which I maintain in Debian, and often used
(and abused) to do Python 3 conversions. There's also 2to6, which I
don't know much about, but I've read it works about the same way as
sixer (which was specifically written for OpenStack).

The advantage is that you'll get a source code that will work on both
Python 2 and 3. It's generally a way more easy to submit upstream, which
may not want to loose Python 2 compatibility.

Cheers,

Thomas Goirand (zigo)



Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-12 Thread Thomas Goirand
On 9/10/19 7:50 AM, Andreas Tille wrote:
> Hi,
> 
> in the process of the Python3 migration the package lefse was converted
> using 2to3.

Hi Andreas,

I wont comment on the relative import ambiguity problem, as Ghislain
replied correctly. However, I do want to comment on 2to3.

I generally recommend against using it, in the favor of other tools. For
example, you can use sixer, which I maintain in Debian, and often used
(and abused) to do Python 3 conversions. There's also 2to6, which I
don't know much about, but I've read it works about the same way as
sixer (which was specifically written for OpenStack).

The advantage is that you'll get a source code that will work on both
Python 2 and 3. It's generally a way more easy to submit upstream, which
may not want to loose Python 2 compatibility.

Cheers,

Thomas Goirand (zigo)