after micropython upgrade cannot check if object is of type TextIOWrapper

[JohnMTu]

Hello,

on ESP8266 i'm trying to update from v1.9.4-272-g46091b8a on 2018-07-18; to 1.19.1 as i realized, there is like 6k more heap available and i'm really fighting to fit into ram.

>>> f = open('boot.py', "r")
>>> type(f)
<class 'TextIOWrapper'>
>>> type(f) is io.TextIOWrapper
False
>>> isinstance(f, io.TextIOWrapper)
False

Why are they returning false?
in 1.9.4-272 i used

type(f) is io.TextIOWrapper

and it worked .. in 1.19.1 it doesn't work anymore

Thanks

[JohnMTu]

using

'TextIOWrapper' in str(type(f))

as dirty workaround for now...

[peterhinch]

It seems telling that

>>> type(f)
<class 'TextIOWrapper'>

does not return

<class 'io.TextIOWrapper'>

Interestingly CPython returns _io.TextIOWrapper, but the tests you cite (against io) pass. What did the old version return?

[JohnMTu]

i think i had to type type(f) is io.TextIOWrapper in this demo only because i don't have io.TextIOWrapper imported (which i have in normal code).
will check next days, have to downgrade some board.

[dpgeorge]

The io.TextIOWrapper was removed in commit e65d1e6

If your board supported more than one filesystem (and most of them do) then testing that something is of io.TextIOWrapper would not work correctly. So better to not have something at all than have something that silently gives the wrong result, hence why it's been removed.

[JohnMTu]

i tested with 1.19.1 before that commit.
But as it will be removed, probably doesn't have sense to waste time with it.

I moved project to PICO W. There i have FW 1.19.1 from 2022-09-30 atm.
open('boot.py', "rt")
however still returns io.TextIOWrapper.

And
open('boot.py', "rb")
returns io.FileIO

But classes are not present in "io" module.
So how do i check now, what type of object i have?

btw. i'm very confused.... as type(f) returns <class 'FileIO'> how can it be i cannot compare it against it?

[robert-hh]

See https://docs.micropython.org/en/latest/library/io.html?highlight=textiowrapper#io.TextIOWrapper

[jimmo]

@JohnMTu What's really going on here is that there are multiple types (classes) all called "TextIOWrapper" -- one for each filesystem type.

So this is what Damien is referring to above, we explicitly don't provide a io.TextIOWrapper any more because it could be mulitple different things. i.e. your check type(f) is io.TextIOWrapper would not have worked if the file was on an LFS filesystem because io.TextIOWrapper is (arbritrarily) the FAT TextIOWrapper.

Just because it's not available on io doesn't mean the type(s) don't exist though, which is why you still see that the type is... TextIOWrapper. (But a type's name is independent from its actual definition -- multiple types can share the same name). (@peterhinch this explains your question -- the type in MicroPython doesn't know what module it comes from, it's just a type that we happen to export on the io module. Similar to how machine.Pin and pyb.Pin are actually the same type).

To answer your actual question though, your suggested workaround of using 'TextIOWrapper' in str(type(f)) is probably the best thing I can think of. (Unless you can redesign your way out of this problem... why do you need to check this in the first place?)

[JohnMTu]

Thanks all, i got it now.
Didn't know, that string representation like <class 'TextIOWrapper'> could point to classes from differnet modules under same name.
I come from java world, where we have fully qualified names...