New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please don't use f-strings yet #44

Closed
skorokithakis opened this Issue Jan 20, 2018 · 18 comments

Comments

Projects
None yet
3 participants
@skorokithakis

skorokithakis commented Jan 20, 2018

f-strings are a very new feature, and this makes the library unusable on any system that's more than a few months old. It doesn't even install for me, as the interpreter for Python 3.4 (running on my raspi) doesn't know what an f-string is.

@skorokithakis

This comment has been minimized.

skorokithakis commented Jan 20, 2018

Looks like this library has more needless reliance on Python 3.6. As such, it doesn't really run anywhere usable. I did some work to remove f-strings but then hit some of the other features and I don't have any more time to fix things. I'll have to use something else, thanks.

@n8henrie

This comment has been minimized.

Owner

n8henrie commented Jan 20, 2018

As requested in the issue template, please search old issues before opening new ones. I have no interested in restoring support for 3.5, much less 3.4.

As such, it doesn't really run anywhere usable.

If you haven't heard of it, you should look into pyenv -- I've not had any trouble installing or running 3.6 on any of my Linux or MacOS devices.

@n8henrie n8henrie closed this Jan 20, 2018

@skorokithakis

This comment has been minimized.

skorokithakis commented Jan 20, 2018

Alright, so I guess this library will never be usable anywhere practical, as you're always going to be on cutting edge and all systems are at least a year behind. I'm not interested in installing a whole different version of Python just to use your library.

@n8henrie

This comment has been minimized.

Owner

n8henrie commented Jan 20, 2018

I guess this library will never be usable anywhere practical

As I said, I've not had any trouble installing or running 3.6 on any of my Linux or MacOS devices. AWS runs 3.6. Heroku runs 3.6. Arch comes with 3.6. Even debian stable has 3.5. I wish you would be a little more specific, I'd be happy to try to show you how to install a more modern Python version on whatever device is giving you such trouble.

If you'd read the README, you'd know from the start that I'm explicitly not interested in backporting to earlier Python versions (whose support was intentionally deprecated). I've included instructions in the README on how to install an older version of Fauxmo that runs on 3.4.

I'm not interested in installing a whole different version of Python just to use your library.

Great -- please don't use it.

@skorokithakis

This comment has been minimized.

skorokithakis commented Jan 20, 2018

Libraries should follow the official Python lifecycle. Only 3.3 has been end-of-lifed. Not supporting versions that are still officially active is your choice, but you're losing users.

@n8henrie

This comment has been minimized.

Owner

n8henrie commented Jan 20, 2018

Libraries should follow the official Python lifecycle.

Interesting, I've never heard anyone make that contention, and as mentioned in the other thread Home-Assistant is also leaving 3.4 behind.

Not supporting versions that are still officially active is your choice, but you're losing users.

That's okay, this is a hobby and not a job. Users that feel differently should feel free to fork -- my code is open source and MIT licensed, and I've included a fair amount of documentation regarding the process I used to write it.

Again, if you change your mind and want to learn how to install 3.6, pyenv makes it painless and allows for much easier testing across Python versions for any libraries you develop or to which you contribute.

@skorokithakis

This comment has been minimized.

skorokithakis commented Jan 20, 2018

I do know how to install pyenv, I use it for compatibility in the libraries I develop. I just don't want to add such a large dependency to my Raspberry Pi which is already strapped for space. Anyway, what you support is up to you, thank you for your time.

@n8henrie

This comment has been minimized.

Owner

n8henrie commented Jan 20, 2018

Thanks for the reasonable discussion. FWIW, the RPi is my primary target for Fauxmo, and I have 6 or so Pis including model Bs, V2s, V3s, and a zero, and I have had no issues with pyenv or Fauxmo.

Pyenv itself takes minimal space.

$ git clone --branch=v1.2.1 --depth=1 https://github.com/pyenv/pyenv.git &> /dev/null && du -sh pyenv
4.2M    pyenv

Of course that doesn't include the dependencies for building Python: make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev

I'm out of town for the moment, but when I get back I'll try to remember to see if I can determine the total size required on the Pi for pyenv + dependencies + python36 and update the README with info, as well as see if I can do a little apples-to-apples benchmark of the Raspbian Stretch 3.5 vs a pyenv-installed 35 vs pyenv-installed 35 with --enable-optimizations.

@skorokithakis

This comment has been minimized.

skorokithakis commented Jan 21, 2018

When I write a piece of software, I try to balance the user's needs with my needs. In the case of Python 3.5/3.6, I don't generally consider that the new features save me, personally, enough time to have all my users spend time installing a whole other version of Python on their systems. If it were something like async/await, then yes, obviously it would be much harder to write an application without it, so the use would be justified.

Deprecating previous versions for something like f-strings isn't a good tradeoff to me, but I'm a bit of an extreme case, as I just deprecated Python 2.4 in one of my libraries last year. Basically, I tend to err on the side of the user when my dilemma is "should I keep Python 3.4 support or use the star operator in one function?". I only use the latest-and-greatest with abandon in things that will only ever run on my machines, and consider whether it's worth inconveniencing hundreds of people to save me two seconds.

@n8henrie

This comment has been minimized.

Owner

n8henrie commented Jan 21, 2018

That's fair.

I forked https://github.com/makermusings/fauxmo specifically because I wanted to use a more modern version of python. That is the goal of this fork -- for me to learn more about Python3 (my first programming language, having avoided Python2 entirely), and for me to learn the basics of asyncio. The library was working just fine with its original codebase, but I wanted to port it to Python3 and had no interest in maintaining backwards compatibility with Python2.

The limitations of Raspbian Jessie's default 3.4.2 installation (as compared to a few asyncio features available in 3.4.4) prompted me to investigate using pyenv to get a more recent version on the Pi than was available in the Raspbian repos (again, this was 3.4.4 vs 3.4.2 at the time). Once I was using pyenv anyways, it made no sense not to move to async def / await of 3.5 and eventually f-strings, both of which I like a lot (as well as the new 3.6-only type hint declaration syntax).

Fauxmo is still a very small-scale project, mostly for personal use, and it will likely irreparably break in the next year or two as the Echo and WeMo devices change how they work. I think you're overstating the amount of inconvenience that it places on users to require 3.6 in this case; pyenv is widely available, has a small footprint, it's easy to use and install, and frankly it's much better supported than this relatively young, very small project. Installing a more modern version of Python is simply not that big of a deal, even on a Pi, and I've had instructions on how to go about it font-and-center of the Fauxmo README for quite some time.

Conversations like this certainly makes me covet Go's static binaries even more!

@skorokithakis

This comment has been minimized.

skorokithakis commented Jan 22, 2018

Ah, I see; that's fair. I'll try installing pyenv and seeing how it goes. Yep, static binaries are a great solution to this :/

@n8henrie

This comment has been minimized.

@skorokithakis

This comment has been minimized.

skorokithakis commented Feb 13, 2018

Good writeup, thank you! 16 minutes is maybe acceptable for me, although I wouldn't want to wait for hours to install a version of Python used by just one script. It's great that you made the scripts and benchmarks available, as I always like having references I can point to if someone has the same question about Python buildtimes on a Pi in the future, thanks again!

@TimothyBramlett

This comment has been minimized.

TimothyBramlett commented Apr 14, 2018

I would say f strings should be removed simply bc Python 3.6 is not even available in the Raspbian repos yet. I could compile from source but I don't like compiling on such a small machine.

@n8henrie

This comment has been minimized.

Owner

n8henrie commented Apr 14, 2018

I would say f strings should be removed simply bc Python 3.6 is not even available in the Raspbian repos yet.

Thanks for your input, but I don't find this a compelling reason. Fauxmo isn't available in the Raspbian repos, either. In short, I don't plan to restore Python 3.5 compatibility. If a user made a PR that restored 3.5 compatibility, I may or may not merge, but I will likely continue to use 3.6-only features going forward that would break it in short order.

I could compile from source but I don't like compiling on such a small machine.

Please read my blog post a few posts above. Being such a small machine is a great reason to take advantage of the speed enhancements new to 3.6 as well as the opportunity to compile with optimizations. Compiling an optimized 3.6 from source carries a reasonable one-time cost and seems to achieve somewhere around 15-20% better Python performance, which means a lot on such a small machine.

I'm not terribly interested in rehashing this topic, and I don't find any of the above reasons persuasive, so I'm going to request that people don't reply unless they have a new and compelling reason that I should remove the 3.6-only features from Fauxmo (including f-strings and API changes to some of the asyncio components). In that case, this thread is the right place for further discussion.

@skorokithakis

This comment has been minimized.

skorokithakis commented Apr 14, 2018

@TimothyBramlett In case this is useful to you, I ended up going with a slightly edited version of this alternative.

@TimothyBramlett

This comment has been minimized.

TimothyBramlett commented Apr 14, 2018

@skorokithakis Thanks! I am going to look at ouimeaux! I ended up just modifying the original library this one was made from and that worked well, so I may just continue going with that.

Kind of blows my mind that someone would force Python 3.6+ compatibility because of f-strings.

@n8henrie

This comment has been minimized.

Owner

n8henrie commented Apr 14, 2018

As was mentioned in the second post in this thread, there are also 3.6-only asyncio features that recent versions of Fauxmo leverage, and the new type hint syntax. Not as simple as just f-strings unfortunately (though I do love f-strings). Also, I’m really surprised that a one-time 5 hour build (for a reasonably modern Pi) doesn’t seem worth having a significant faster Python (with the new features to boot). But I guess we’ll just have to agree to disagree here.

Anyway, glad you guys found something that worked well for you. While you’re checking out other projects, I’d recommend also considering the ones that are based on Hue, as I think they also support commands like brightness levels (I don’t think Wemo does), which may open up a lot of possibilities. I’m pretty sure HomeAssistant’s emulated_hue is one example.

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