I see messages like the following where someone is still asking how to do
something in some version of python 2.X.

I recall the days before the year 2000 with the Y2K scare when people
worried that legacy software might stop working or do horrible things once
the clock turned. It may even have been scary enough for some companies to
rewrite key applications and even switch from languages like COBOL.

What is happening in the python community, and especially in places where
broken software may be a serious problem?

I assume versions of python 2.X will continue to be available for some time
but without any further support and without features being back-ported. 

Conversion of some features seems simple enough but as I have been studying,
I keep running into many areas where the pythons differ and often in subtle
ways that many may not know to change. I won't go into detail, but fixing
the print statement to become the print function is far from enough. Some
things can be made to work in the last versions of 2.7 where the
back-porting allows a smoother transition.

So, is there info out there on what may be problem areas? Are there modules,
for example, that have not been ported and are not available for 3.X and
don't have some similar enough other module that might be used?

This is not just a python problem, of course. PERL is an example where there
seem to be a new and incompatible old version running around.

As a note, I am not complaining that python has evolved in incompatible
ways. Not easy to avoid unless you like stasis. But if enough people keep
avoiding the hints and outright warnings to get more up-to-date, this
Y2-->3K event may be a problem. 


-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon....@python.org> On
Behalf Of Grant Edwards
Sent: Wednesday, January 16, 2019 10:46 AM
To: python-list@python.org
Subject: Re: get the terminal's size

On 2019-01-16, Karen Shaeffer <klsshaef...@gmail.com> wrote:

[fixed quoting and formatting]

>> That will tell you the terminal size at the time Python was started.
>>
>> If the terminal size has changed while Python was running, those 
>> environment variables will be wrong.  You need to use the TIOCGWINSZ 
>> ioctl call:
>>
>>     http://www.delorie.com/djgpp/doc/libc/libc_495.html
>>
>> And to detect the size changes (so you know _when_ you need to do the 
>> above), you need to attach a signal handler for the WINCH signal.
>
> I'm running a python 3 interpreter on linux. I'm actually ssh'd into 
> the terminal on a headless server. [...] [...] With the python 
> interpreter running on the remote terminal, I have resized the 
> terminal window on my local laptop several times. And each time, the 
> remote python interpreter knows about the change, correctly printing 
> the new size.  I have done nothing with environment variables. I have 
> not used a signal handler for the WINCH signal. It just works.

Yes, we know that works on Python3.  The discussion was about what to do on
Python2.

    $ python2
    Python 2.7.15 (default, Sep 12 2018, 15:19:18)
    [GCC 7.3.0] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import shutil
    >>> shutil.get_terminal_size()
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    AttributeError: 'module' object has no attribute 'get_terminal_size'
    >>>

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having a BIG
BANG
                                  at               THEORY!!
                              gmail.com            

--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to