Re: Saying bye bye to Python 2
tommy yama : > As many know, python 2 was retired. 🐍 > This means imminent migration to 3 will be a must ? Python 2 will have a lively retirement. It won't be dead before RHEL 7 is dead. According to https://access.redhat.com/support/policy/updates/errata the support dates for RHEL 7 are: End of Full Support: Aug 6, 2019 End of Maintenance Support 1: Aug 6, 2020. End of Maintenance Support 2: June 30, 2024. End of Extended Life-cycle Support: TBD End of Extended Life Phase: ongoing Last Minor Release: TBD Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Why isn't "-std=c99" (and others) not part of python3-config's output?
On Mon, Nov 25, 2019, at 15:13, Musbur wrote: > 2) How does one activate the necessary CFLAGs for extension building? the standard level required for building some extension is a property of the extension's source code, isn't it? I don't know if including the python headers requires -std=c99 or not, but almost certainly they'll work with -std=c11 and an extension may well require it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Saying bye bye to Python 2
On 11/01/2020 00:16, tommy yama wrote: As many know, python 2 was retired. 🐍 This means imminent migration to 3 will be a must ? Upgrading to Python 3 has been a "bloody well should" for many, many years now. Though in a shock announcement a few weeks ago the end of Python 2 was delayed AGAIN (this time only by a few months, but still) https://pyfound.blogspot.com/2019/12/python-2-sunset.html I thought that upgrading is not that simple. thanks ! -- https://mail.python.org/mailman/listinfo/python-list
How to get dynamic data in html (javascript?)
Hi all,
I'm pretty good at hacking html text. But I have no clue how to get
dynamic data like this : "At close: {date} {time}". I would appreciate a
starting push to narrow my focus, currently awfully unfocused. Thanks.
Frederic
--
https://mail.python.org/mailman/listinfo/python-list
Re: Saying bye bye to Python 2
> I thought that upgrading is not that simple. It depends. If you have Python 2 code that deals with a lot of text in byte form, and it's kind of vague where you convert from bytes to strings, you may have a bad time. Otherwise, it may not be that bad. I ported around 500k lines of Python 2 to 3 this year, and it went smoothly. The most valuable resource I found was eevee's post on the subject: https://eev.ee/blog/2016/07/31/python-faq-how-do-i-port-to-python-3/ It talks about the most common tools and pitfalls. In particular, I found the future project to be very valuable. Best, G On Sat, Jan 11, 2020, at 00:16, tommy yama wrote: > As many know, python 2 was retired. 🐍 > This means imminent migration to 3 will be a must ? > > I thought that upgrading is not that simple. > > > thanks ! > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Saying bye bye to Python 2
On Sun, Jan 12, 2020 at 4:50 AM Gunnar Þór Magnússon wrote: > > > I thought that upgrading is not that simple. > > It depends. > > If you have Python 2 code that deals with a lot of text in byte form, and > it's kind of vague where you convert from bytes to strings, you may have a > bad time. > It's always hard to port buggy code or underspecified code. If you have code written in some hypothetical language that doesn't distinguish properly between 16-bit ints and 64-bit floats, and has sloppy conversions between them and different semantics, then it would be a pain to port that to any other language. Ultimately, the cure is to figure out the programmer's original intention and implement that. > Otherwise, it may not be that bad. I ported around 500k lines of Python 2 to > 3 this year, and it went smoothly. The most valuable resource I found was > eevee's post on the subject: > Python Indeed. Especially if you're porting to a fairly recent Py3, chances are that most of the code will work just fine. There'll be just a few places where you have to manually figure things out, and for the rest, automated conversions like 2to3 will cover it. (And a lot of it doesn't even need automated conversion. There aren't actually THAT many things to change.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Relative import cannot find .so submodule?
I have a module named rtmidi, and its C submodule named rtmidi/_rtmidi. The distills script builds successfully and successfully creates a build/lib dir with a rtmidi dir in it and the submodule file rtmidi/_rtmidi.cpython-36dm-darwin.so. I have set PYTHONPATH to this lib dir, but rtmidi/__init__.py gives the following error: Traceback (most recent call last): File "main.py", line 6, in from pkmidicron import MainWindow, util, ports File "/Users/patrick/dev/pkmidicron/pkmidicron/__init__.py", line 1, in from .mainwindow import * File "/Users/patrick/dev/pkmidicron/pkmidicron/mainwindow.py", line 2, in import rtmidi File "/Users/patrick/dev/pkmidicron/pyrtmidi/build/lib/rtmidi/__init__.py", line 1, in from ._rtmidi import * ModuleNotFoundError: No module named 'rtmidi._rtmidi’ How does the module finder work in the import system? I assume ti automatically resolves the name _rtmidi.cpython-36dm-darwin.so to _rtmidi? I didn’t have any luck reading the docs on the import system. Thanks! -Patrick -- https://mail.python.org/mailman/listinfo/python-list
