Consider adding Python 3.5 support

[tonybaloney]

This project uses black, but that's not a requirement to execute it. It also uses f-strings, but those could be replaced with str.format easily

Please 👍 if you want to see this back-ported to 3.5

[tonybaloney]

Would also require dropping use of dataclasses for something else, eg. namedtuples or attrs

[tonybaloney]

Raised WIP in #15

[Kilo59]

If you are already on 3.5 what's holding you back from moving up to 3.6?

EDIT:
I thought I was talking to a potential user, not the author. 🙃

[tonybaloney]

@Kilo59 other way around. It supports 3.6 and 3.7 already. I'm considering back-porting to 3.5

[Kilo59]

@tonybaloney I understand what you are asking. I was actually asking you what's stopping your one's project (in which you someone wants to use wily) from moving from 3.5 to 3.6 (or 3.7).

I could be wrong of course, but I don't see a lot of developers being stuck on 3.5 and unable to move up to 3.6+ actually being very common.
IMO having to support an older version of python and maintain it may start out relatively easy at first but can really start to slow down development as features get added and the project grows in complexity.

EDIT:

🙃 When I originally responded I didn't realize I was talking to the project author, whoops.
Anyways was trying to save you some work, not intentionally trying to be difficult. 😄

[Kilo59]

In addition, adding more dependencies to support 3.5 is going to introduce more chances for dependency problems. I've already had issues with wily, flake8, pyflakes and prospector (fixed it by pinning flake8 to an earlier release 3.5.0) .

I imagine people who are likely to install wily are also likely to be running other static analysis tools too, increasing the likelihood of problems.