Python 3 support #16

Closed
goertzenator opened this Issue Feb 20, 2011 · 122 comments

Projects

None yet
@goertzenator

I have Paramiko running on Python 3 at https://github.com/goertzenator/paramiko

All unit tests, except for sftp, pass. Needs documentation updates for the many str -> bytes changes.

Looking for advice on what to do with this. Adding a python 3 branch to paramiko would have a lot of complications...

robey commented May 22, 2011

there's no way to get code that will run on both python 2 and 3, is there? :(

Paramiko is much too large and io heavy to make that realistic. You could get the two codebases (paramiko py2 and py3) very similar if you started with a py3 version and downported to 2.6 or 2.7. But the current paramiko works well on 2.6 and older, so I don't see a lot of value in that.

Hello,

You can have a single codebase for python 2 and python 3. In the setup.py add the conversion 2to3. This is the recommended way. Add the following code to the setup.py

try:
from distutils.command.build_py import build_py_2to3 as build_py
except ImportError:
# 2.x
from distutils.command.build_py import build_py
...
setup(...
cmdclass = {'build_py':build_py}
)

This is the recommended way: http://wiki.python.org/moin/PortingPythonToPy3k

Using 2to3 was the first step I took for the port and it did convert a lot of things, but it didn't do anything for the massive str/bytes separation that had to take place.

Now I don't know a lot about it, but 3to2 might have more potential for paramiko.

I am working with it now. Since paramiko development seems to be stopped (no reply from the author for months), I am using the ssh fork https://github.com/bitprophet/ssh

Cool, let me know how you make out or if you have any questions.

sciunto commented Aug 19, 2012

Hi,

Is there any progress on that? Is https://github.com/bitprophet/ssh the best implementation in python3?

Thank you!

Owner

@sciunto That 'ssh' fork will merge back into this one shortly, for what it's worth. It's also not Python3 compat yet, though there are patches.

Speaking personally, Python 3 support is a medium priority -- my hope is for Fabric 2.x to be Python 2.6=>3.x compatible, and that will require doing the same for some Paramiko version.

For Fabric and my other projects, I'm hoping to go the "one codebase that works on both Python versions" approach. As mentioned above, I'm not sure if that is feasible for Paramiko due to it being bigger, more complex and more IO oriented. I also haven't experienced the joy/sadness of 2to3/3to2 yet -- if they work and don't make maintenance a huge pain, awesome. If not, hard to say what will happen.

sciunto commented Aug 21, 2012

Alright. I'm going to limit my codes to some popen calls until things evolve.

Thanks a lot for your reply and your work

Owner

For the record, the python 'ssh' lib has now merged back into Paramiko (as of tonight).

Nothing else has changed yet re: investigating the least painful Py3k route for Paramiko itself -- but as I start to work on Fabric 2.x, this will become increasingly important to me, so look for updates in the nearish future.

@takluyver takluyver referenced this issue Dec 21, 2012
Closed

python 3 #123

Any updates or an ETA on a py3k version?

any news about py3k version?

Owner

No py3k news yet, it is still definitely planned (see my above comment), but other priorities have to come first :(

jlegewie commented Feb 4, 2013

I will just add my encouragement here. paramiko is great and I would really like to see it for Python 3.

aspineux commented Mar 4, 2013

I wrote a python library pyzmail that work for both python 2 and 3.
I wrote it for 2.x then ran py2to3 on it. I made some changes to make it work for 2.x and be convertible by py2to3.
Then I have updated my setup.py to make it compatible with py2to3 ( py2to3 is run automatically when installing on 3.X, then no need to have two source tree )

The most difficult part is about unicode string and unicode literal. pyzmail use a lot of both. At 2 or 3 place I had no other choice than test check the python version and write specific code for both version.
The second one was to write doctest that work for both, because py2to3 don't convert comments.

paramiko don't make an heavy use of unicode string then it should be possible to use the same way.

Contributor

Not quite: Particularly in the agent stuff, it should be using
bytestrings.

Cheers,

Michael

On Mon, Mar 4, 2013 at 1:26 PM, Alain Spineux notifications@github.comwrote:

I wrote a python library pyzmail that work for both python 2 and 3.
I wrote it for 2.x then ran py2to3 on it. I made some changes to make it
work for 2.x and be convertible by py2to3.
Then I have updated my setup.py to make it compatible with py2to3 ( py2to3
is run automatically when installing on 3.X, then no need to have two
source tree )

The most difficult part is about unicode string and unicode literal.
pyzmail use a lot of both. At 2 or 3 place I had no other choice than test
check the python version and write specific code for both version.
The second one was to write doctest that work for both, because py2to3
don't convert comments.

paramiko don't make an heavy use of unicode string then it should be
possible to use the same way.


Reply to this email directly or view it on GitHubhttps://github.com/paramiko/paramiko/issues/16#issuecomment-14361382
.

aspineux commented Mar 4, 2013

By "using unicode", I mean having bytestring to convert to 'human' readable strings and vice versa.
98% of the string in paramiko are bytestrings; hostname, login and password are from the user and en then must be converted appropriately. SSH Keys must be loaded and saved the right way.
Thats all. This is not a complete rewrite.

geertj commented Mar 6, 2013

I'd like to voice my support for this issue as well.

@bitprophet You should definitely go for the single code base approach. If you only need to support 2.6, 2.7 and 3.3+ this is very feasible.

e0ne commented Mar 9, 2013

It looks like need to support two different code bases: for python 2.x and 3.7. I'm trying to port paramiko to 3.3 but it really hard to suport 2.x and 3.x in one codebase.

aspineux commented Mar 9, 2013

What is your main problem ? Do you have some recurring piece of code that require some changes ? Does this make the code difficult to read ? Are you using 2to3 in POST-process (after you have made the original code for 2.x , 3.x ready )?

e0ne commented Mar 9, 2013

Yes, I'm using 2to3. Main problem is new types: no long and unicode more. I'm pretty sure that that it will broke 2.x code or code will be difficult to read with a lot of try-except blocks

Owner

I've been actively porting my (much smaller & newer) projects Spec and Invoke to a shared 2.6+3.3 style codebase using six, an approach that not only everybody who's already done this has recommended, but which does seem to work quite well in practice. The transition's been thorny but only because I hadn't done any work with Python 3.x prior so I'm both porting + learning.

I expect any final Paramiko Python 3.x support will end up using six and similar approaches, even if an initial 2to3 pass is used to help highlight trouble spots.

@e0ne it's not that hard. instead of making crazy amounts of try/except blocks, make a function that has that in it. i maintain a daily use set of software that is approaching 10K lines and has to work on everything from 2.4 to 3.3

also, i find it much easier to write for py3 and then handle legacy breakage as exceptions to the norm. it makes dealing with issues a lot easier.

e0ne commented Mar 15, 2013

@FirefighterBlu3 thanks for advise. I'll try it. I'm newbie in porting to python 3.x. I'm working on Lettuce and wont to get fabric/paramiko on python 3.3 in my project.
I don't like six because it makes python not so clear. Have a two branches for 2.x and 3.x is harder but code is better for me.

no problem. i'd love to see a py3 capable paramiko. i'd port it but i'm really really pressed for time. i prefer a single branch

@trentm trentm referenced this issue in joyent/python-manta Jun 25, 2013
Open

python 3 support #8

hukka commented Jun 25, 2013

@e0ne I checked your fork, but didn't see more than one py3k specific commits. Is the port somewhere outside github, or has development stalled?

If there's another more complete port, could someone point me to it?

I now also need ssh with python 3, so I'm willing to help to make the port. The most sensible way I can see is to support 2.6+ and 3.3+ only, with six or without. That approach has worked well with pretty large code base (dateutil). I don't want to maintain my own port, so possibility to merge back is a must, so I'd need some kind of decision to drop 2.5 support and not try to get 3.1 and 3.2 working.

nri-pl commented Jun 25, 2013

I am for giving up 2.5 ...
For a long time waiting for Python 3.2 + support.
I have not found a working fork.

e0ne commented Jun 25, 2013

@tpievila I'll update my github repo with my port to Python 3.3 using six today. I hope, most of features will be work for you

warsaw commented Jun 25, 2013

On Jun 24, 2013, at 11:26 PM, Tomi Pieviläinen wrote:

I now also need ssh with python 3, so I'm willing to help to make the
port. The most sensible way I can see is to support 2.6+ and 3.3+ only, with
six or without. That approach has worked well with pretty large code base
(dateutil). I don't want to maintain my own port, so possibility to merge
back is a must, so I'd need some kind of decision to drop 2.5 support and not
try to get 3.1 and 3.2 working.

While I'm a big fan of 3.3, and support dropping anything older than 2.6, I'll
just note that if you're going to support 3.3, it's usually not that much more
difficult to also support 3.2. Were there specific 3.3 features you planned
on using?

hukka commented Jun 26, 2013

@warsaw http://docs.python.org/3/whatsnew/3.3.html#pep-414-explicit-unicode-literals would probably be the only one. Granted, it's not a critical feature, but it will make the codebase cleaner to read now, and to port to Python 3 only later. In some cases I suppose there might be speedups, but I doubt that will matter.

hukka commented Jun 29, 2013

@e0ne Any news?

hukka commented Jul 1, 2013

While waiting, I started my own port. There's a problem with message.py that will be causing problems: a lot of the code uses str(message) to get a byte presentation of the message, via __ str__(). While this can be fixed within paramiko codebase, I can see only two unpleasant options for external code:

  1. The __ str__ is changed to bytes or perhaps just bytes(), and all current code depending on str() will break.
  2. The __ str__ is left as is, and all future Python 3 code will get a surprise when str() throws "TypeError: __ str__ returned non-string (type bytes)"

Which way would we prefer?

e0ne commented Jul 1, 2013

Here is my branch: https://github.com/e0ne/paramiko/tree/python3.3. It's still in progress. Compatibility with Python 2.6 and 2.7 is ok.

  1. At lease it can be caught and handled

On 1 Jul 2013, at 10:42, Tomi Pieviläinen notifications@github.com wrote:

While waiting, I started my own port. There's a problem with message.py that will be causing problems: a lot of the code uses str(message) to get a byte presentation of the message, via str(). While this can be fixed within paramiko codebase, I can see only two unpleasant options for external code:

  1. The str is changed to bytes or perhaps just bytes(), and all current code depending on str() will break.
  2. The str is left as is, and all future Python 3 code will get a surprise when str() throws "TypeError: str returned non-string (type bytes)"

Which way would we prefer?


Reply to this email directly or view it on GitHub.

hukka commented Jul 1, 2013

Hm, how about third choice: make __ str__() work differently based on running Python version? On Python 2 it would return byte strings and on Python 3 unicode.

On Python 2 str(message) would still work, but Python 3 code needs to use bytes(message). To make portable code, you would write message.bytes() since bytes() doesn't use __ bytes__() (it calls __ str__() instead) on Python 2.

hukka commented Jul 5, 2013

I'm stuck with the same error (verifying the host key fails) whenever I try to connect a transport. Checkout https://github.com/tpievila/paramiko if you have time to figure out what might be wrong.

e0ne commented Jul 5, 2013

It looks like we need to re-write BER decoder

hukka commented Jul 5, 2013

Hm, how did you figure that out?

Contributor
jaraco commented Jul 10, 2013

I've started looking into the state of the Python 3 port as found in tpievila/paramiko. I've managed to get the Travis CI tests running, showing the tests passing on Python 2, but failing (such as this run) on Python 3. It looks like there are quite a few places where the codebase still depends on the ambiguity of bytes versus strings.

hukka commented Jul 11, 2013

Thanks for the help! Have you found a clue about that signature verification error? I think that if nobody can solve it soonish, I'll just have to rehaul the test system. It's very difficult to find divergence points between the Python 2 and 3 when the test cases use random numbers. So if nothing else helps, I was planning to replace it with a pseudo number generator that uses a static seed and then compare the results.

Of course Paramiko is also multithreading, so even that might not help... But it's worth trying. The test cases might be small enough that everything happens in the same order.

nischu7 commented Jul 12, 2013

Check out my recent port to Python 3.x - All unit tests but one (just a clean up thing) succeed: https://github.com/nischu7/paramiko/

Note that I completely dropped python 2 support for now.

hukka commented Jul 12, 2013

I got three errors in the agent.py about concatenation of bytes and strings. Trying to fix those ended up with an odd SSHException: No existing session. Would be nice to get a reference point even if it works only on Python3. I could then compare diffs and see what might have gone wrong in my port.

Or alternatively I wouldn't mind at all if your port was made to work on Python 2 too ;).

nischu7 commented Jul 15, 2013

Hey, see my latest commit fixing the demos and agent: nischu7@7b4ee27

Yes, Python 2.x support should be preserved ;)

gewthen commented Aug 29, 2013

Where can I can find a roadmap for python 3 support? If I wanted to help where can I find plans describing what needs to be done to get paramiko to support python 3?

Lazik commented Oct 1, 2013

Those are three forks that claim to support python 3
https://github.com/nischu7/paramiko
https://github.com/goertzenator/paramiko
https://github.com/varialus/paramiko3k

I tried all three, the goertz & varialus fork installs but fails to import.

The nischu7 passes most tests but not all. Fails the sftp symlink test.

paramiko-goertz
paramiko-nischu7

Lazik commented Oct 1, 2013

But actually, nischu7 fork is able to do sftp.
This worked for me
http://stackoverflow.com/questions/3635131/paramikos-sshclient-with-sftp

tshepang commented Oct 1, 2013

@Lazik can you do paste text instead of screenshots; it loads a lot faster (and looks a lot better)

nischu7 commented Oct 1, 2013

Just create an issue over there https://github.com/nischu7/paramiko/issues and I'm going to fix this soon ;)

Currently working on porting the library to Python 3, with the plan to support 2.6, 2.7 and 3.3 Would love to hear feedback on my progress.

Owner

Just told @dorianpula in email - I'd love somebody to check over the existing branches & jot down an overview of the problems being solved and which approach works best for them. I has a sad that there's probably duplicate work going on :(

I personally will dig into that relatively soon if nobody else does - once I have a prototype of Fabric 2 working, this issue will be blocking my release (it'll be a Python 2/3 release).

Lazik commented Oct 28, 2013

Look at my post above I did just that.

Use https://github.com/nischu7/paramiko
It works for all the things I use it for. If you find a bug, just report it and it will get fixed quickly.

Contributor
jaraco commented Oct 29, 2013

I also have confirmed and tested nischu7/paramiko with good success. I have only tested minimally, though, as my primary use case is fabric. Let me know when there's a Fabric 2 release suitable for testing, and I'll start running it through real-world trials.

Thanks @bitprophet! Yes, so my branch is based off the 1.11 version release, which was the stable release at the time I started my port. I've taken the road of using a unified Python 2/3 codebase, with six helping to manage the various differences between 2 and 3. The idea is not duplicate the codebase, and keep Python 2 support since that'll be crucial for anyone wanting to smoothly transition to 3. (That would be the route the firm I work for would take if we were doing transition of our codebase to Python 3...)

Currently I managed to resolve most of the issues, aside from dealing with byte and unicode strings. The tests pass under 2.7.x but not 3.3.x yet.

I'll take a look at the nischu7 branch, because it sounds like you guys got pretty far with it. :)

Great work @nischu7! I can confirm that almost all of the tests pass in Python 3.3. I am running into problems when running under Python 2.7 though which I will have to look into.

Contributor

Urg, wished I'd noticed this. I have also just about finished the port. Working on 2.6, 2.7, 3.2 and 3.3. Should work on 2.5 as well, which was a real pain to preserve.

https://github.com/scottkmaxwell/paramiko/tree/py3-support

Contributor

My branch is synced up to master. Maybe we can compare. The only thing remaining is sftp.

Contributor

Just made a few more changes. All tests now pass on 2.5, 2.6 and 2.7. All tests except sftp and big file pass on 3.2 and 3.3.

Contributor

For now, you can test on Py3.2 and Py3.3 like this:
python test.py --no-sftp --no-big-file

Well, the nischu7 branch only works under Python 3.2 and higher. It would be very nice to have a unified codebase since someone us can't leave the Python 2 world completely just yet. :P @scottkmaxwell I'll try out your branch next, and I'm happy to contribute to any branch that moves things forward. :)

Contributor

I just went through the nischu7 branch and incorporated some of the changes. Everything is in #233 and all tests still work on Py2.5 - Py2.7. SFTP tests improved. Still 20 tests failing in the SFTP stuff on Py3. Could use some help there if anyone has the time.

hukka commented Nov 2, 2013

@dorianpula I suppose you haven't checked my branch? Since things didn't move forward smoothly, we decided not to depend on paramiko at work. I still can help out a bit, but I got too stuck with the errors I mentioned that it didn't seem worthwhile to continue alone.

Contributor

@tpievila Have a look at my branch if you are still interested in Paramiko on Py3. I plan to spend a bit more time this morning working on the SFTP stuff, but everything else seems to be working.

Contributor

I think I have everything fully working now on Py2.5, 2.6, 2.7, 3.2 and 3.3.

Nice work! Hopefully it's compatible with what @bitprophet has been up to with v2.0.
On Nov 2, 2013 10:24 PM, "Scott Maxwell" notifications@github.com wrote:

I think I have everything fully working now on Py2.5, 2.6, 2.7, 3.2 and
3.3.


Reply to this email directly or view it on GitHubhttps://github.com/paramiko/paramiko/issues/16#issuecomment-27638060
.

@scottkmaxwell Did you install Paramiko and pass the test with python3 ? Could you tell me which packages you have installed ? I am looking for a package like Paramiko to executing some commands on the remote server, but the installation of Paramiko failed with python3.3.2.

Contributor

@xtay573269555 Yes, all tests passed for me with Python 3.3.2. Here is a list of all of my packages:

ecdsa - 0.10 - active
paramiko - 1.13.0 - active development (/Users/scottmax/Source/paramiko)
pip - 1.4.1 - active
py - 1.4.17 - active
pycrypto - 2.6.1 - active
setuptools - 1.1.7 - active
tox - 1.6.1 - active
virtualenv - 1.10.1 - active

Contributor

@xtay573269555 You installed my branch of Paramiko, right?

Contributor

Travis shows all tests passing as well: https://travis-ci.org/paramiko/paramiko/builds/13424000

@scottkmaxwell Thanks a lot. I have installed the latest Paramiko with Python 3.3.2 by following the steps at https://travis-ci.org/paramiko/paramiko/jobs/13424005 .It really does work.

@scottkmaxwell Nice work, thank you! This might make it easier to move fabric forward.

dbrgn commented Nov 14, 2013

Looking forward to a Python 3 port, especially to make a Py3K compatible Fabric possible.

@emre emre referenced this issue in emre/storm Nov 14, 2013
Closed

Python 3 support #43

Owner

@scottkmaxwell - thanks for the efforts! Will try to check it out soon. (The credit line for this "change" in the log is going to be something like a dozen people at this point!)

Just how much pain was Python 2.5? For the long term I don't intend to support 2.5 since its userbase has shrunk considerably vs 2.6/2.7, so if it lets us nuke extra code, we can do so.

I haven't seen the code, but I imagine it's quite painful. Python 2.5 doesn't have __future__.print_function, so you have to use sys.stdout.write to print without a newline, and print('\n') to print an empty line. And there is not two-way compatible syntax to catch an exception and bind it to a name. You have to use sys.exc_info()[1].

That is unless you use 2to3, but I recommend against it if possible (I wasn't clear what style was being used here).

Contributor

@bitprophet Supporting 2.5 wasn't that bad, but I can easily drop it. There are 2 big gotchas with 2.5:

  1. No except Exception as e so you have to do except Exception: and then do e = sys.exc_info[1]. Just ugly.
  2. No b'byte string' support

Supporting 3.2 added a bit of ugliness in the unit tests because 3.2 does not support the u'unicode string' syntax. I had to add some evals to handle the missing b and u string markers in 2.5 and 3.2 respectively. So if you want to trim back to only 2.6+ and 3.3+, we could eliminate most of the unpleasantness.

Contributor

@asmeurer For the most part, you can get away with just putting parenthesis around print. I only use sys.stdout.write when I need to print without a newline in 2.x and 3.x compatible code.

Sure, that's what I was saying. But also print(a, b) won't work. Really it's all just a bunch of little stuff, but it adds up, and you have to remember them all.

Contributor

Yep. It was a PITA. But seems to be working well now.

If we drop 2.5 support, I like the idea of doing from __future__ import print_function.

Contributor

@bitprophet Should I go ahead and strip out 2.5 support?

I am also going to flip around the conditional in the few places I have it to be if PY2 instead of if PY3. Better for when Py4 comes along.

I would absolutely support the notion of dropping py2.5. We've done it in Jedi an nobody's looked back since. The few hacks that @asmeurer talked about are just not worth it - and there's more - like using future imports for with statements etc.

Contributor
jaraco commented Nov 19, 2013

I concur with dropping Python 2.5 support. In my experience, the biggest holdout of Python 2.5 users is Jython and I don't think that's relevant here.

Contributor

Py2.5 support removed and code appropriately beautified in #236

Might as well drop 2.6 as well, given it's also reached EOL.

Contributor

Not much to be gained from dropping 2.6. It would allow set literals and dict comprehensions, but I think that is about it. I like the idea of supporting 2.6. Still a lot of 2.6 installs out there, I think.

Contributor

I'd say that is pretty good evidence that the consensus is stabilizing on the idea that trying to maintain 2.5 support just is not worth the pain. That's great. As I removed the Py2.5 support I remembered how much work it actually was.

For me the biggest thing was actually the lack of the b marker for byte strings. That was the one issue that meant writing code that had to be evaluated at runtime instead of compile time. The other issues were just syntactic ugliness.

For me the biggest thing was actually the lack of the b marker for byte strings.

That's exactly why we eventually dropped Python 2.5 support in Jedi.

koniiiik commented Dec 2, 2013

I'll just chime in with an observation that dropping support for 3.2 (as has been suggested a few times here) might not be the best idea since it's the version of Python in the recently released Debian Wheezy which is going to stick around for a couple of years…

Issues with the u string literal prefix can be worked around by using __future__.unicode_literals throughout the code base and omitting the prefix altogether. I realize this may require rewriting most unicode literals, but it is doable. Of course, this will only be possible without 2.5 support which doesn't have unicode_literals yet.

Contributor

I only had to deal with the u literal in one test file so supporting 3.2 was no big deal. I'm in favor of keeping 3.2 support.

@nhoening nhoening referenced this issue in nhoening/fjd Dec 11, 2013
Closed

Python3 compatilibility #10

mnothic commented Dec 23, 2013

if we continue to maintain retro-compatibility to the branch 2.x, the people never use branch 3.x, it's time to fork and maintain the code in py3k

@mnothic #236 isn't about a new branch, it's about py2/3 compatibility in one branch. That's actually the only thing that makes really sense IMHO.

mnach commented Dec 24, 2013

@mnothic are you sure about it? I use paramiko with python3. And I don't understand why not add py3-compatibility to current branch.

mnothic commented Dec 27, 2013

@mnach what release are you using with py3?

mnach commented Dec 30, 2013

@mnothic i use dev version with pull request #236

Contributor
lndbrg commented Jan 16, 2014

Given the age of python2.5 i'd vote for a drop in support. This will also give us some other (way smaller) benefits syntax wise. I guess that @bitprophet wants to regression test heavily with fabric too.

Contributor

Yep, removed in #236 as suggested by @bitprophet.

Contributor

For those who care, I just merged in the latest changes from master to #236. Latest also includes a bug fix that caused the Fabric unit tests to fail.

Owner

This is still near/at the top of my list, just FYI! need to wrap up a few other bugs & get a set of releases out first.

tshepang commented Feb 3, 2014

thanks for sayin' something @bitprophet

@fenhl fenhl referenced this issue in wurstmineberg/wurstminebot Feb 25, 2014
Open

Add command to set up @wurstmineberg.de mail redirections #7

Please update the Fabric documentation; it now reads "Fabric is a Python (2.5 or higher) library", which implies 3.x support. Only after installing with pip and seeing syntax errors fly by, did I get suspicious about the 3.x support...

Owner

@sybrenstuvel Most folks realize Python 3 is a big break from Python 2...but clearly not everybody. Fixed: fabric/fabric@a722a7c - thanks!

I just completed #256 so it is now officially PYTHON 3 TIME and I will dive into the above PRs next time I have OSS time.

asmeurer commented Mar 5, 2014

When you start actually using Python 3 you realize that it's not actually that big of a break.

Owner

Looks like #236 is the most recent attack on this so I will start by updating a copy of it, w/ latest master (main pain point is likely to be the docs changes from #256).

Owner

@asmeurer Sure, it's no Perl 6 ;) but it's enough of a barrier that I would never expect a project to default to supporting 3 if it just says "Python 2.5+". (Especially if it says 2.5+, given supporting 2.5 and 3 at the same time is even harder ;))

Owner

Mostly done applying #236's changes on top of latest master, taking notes as well. Plan is to present a new, clean PR with that changeset; discuss my notes on it (probably in that PR, just because it makes line comments easier); then iterate until we're satisfied.

Owner

#276 is that PR. Please put any interested eyes on that copy of the code, and I will be posting progress there as I hack on things.

Owner

We're basically done with #276, got test suite parity + did some cleanup + a little remaining that is being handled now.

What's left, IMO:

  • Changelog entry
  • Modify README/website/etc as required to note that Py3 support is now implemented
  • Possibly wait for a few more invested parties (that would be: you) to report that yes, the post-merge master branch works well for them.
  • Release Paramiko 1.13 (now that's an auspicious version number)
  • Handle any bugs-in-the-wild as they come up, in their own tickets.
Owner

Was randomly poking https://caniusepython3.com/ and realized it's asserting ecdsa is not Py3 compatible. Should check that out; will be a hard blocker if it cannot be installed and/or imported (if it's only broken when actually used, then we can just deal for now as ECDSA isn't always required.)

yegle commented Mar 10, 2014

https://github.com/warner/python-ecdsa
It says it support 3.2 and 3.3.

The latest released version (0.10) has no trove classifiers indicating which Python versions are supported, but there is a commit claiming support for both 2.x and 3.x.

Owner

Well that's good to hear then, thanks @yegle @tshepang!

Back on OSS today (it's...been a long week), hopefully will have this out on PyPI by EOD if I'm lucky.

@bitprophet bitprophet added a commit that referenced this issue Mar 13, 2014
@bitprophet bitprophet Add changelog re #16 8463053
Owner

Merged into master!

Can't see a great reason to hold off on a 1.13 release; if it breaks, it breaks, and we bugfix.

@bitprophet bitprophet closed this Mar 14, 2014

Nice work guys!

The reason I posted a comment about the "2.5+" thing, is that I'm trying to get "X and newer" to actually mean "X and newer", and not "X and newer except fo other new stuff" ;-)

Contributor
jaraco commented Mar 14, 2014

Smart move to release and move forward. Too many projects get stymied by fear of issues.

Congrats. And thank you all.

@eirnym eirnym referenced this issue in fabric/fabric Apr 9, 2014
Closed

Python 3.3 support #1050

jptomo commented Aug 1, 2014

👍 💯

Hope py3 supporting will come soon!

tshepang commented Dec 3, 2014

@leafonsword there is, since 1.13.0.

@tshepang
haha,Thx~

@huxley huxley referenced this issue in joyent/python-manta Mar 24, 2015
Open

Paramiko added Python 3.2+ support in v 1.5.0 #28

@ghost
ghost commented Jun 5, 2015

Error from python 3.4.3:
from Crypto.Util import _counter
ImportError: Cannot load specified object

@TeeBSD could you
a) provide more context. e.g. Why is an error from Crypto to do with paramiko? Which OS and version of paramiko? How was it installed?
b) open a new ticket for this issue if there isn't one already (I couldn't find one)

Lazik commented Jun 6, 2015

Paramiko uses pyCrypto.
It's more about how/which version of pyCrypto you installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment