Error when loading model trained with python3.7 pytorch 0.4.1 using python2.7 pytorch 0.4.1

1

Model is saved with torch.save(model.state_dict()).
When I switch to python 2.7 and use

checkpoint = torch.load(Path(model_dir))
model.load_state_dict(checkpoint)

It gives the following error

AttributeError: 'PosixPath' object has no attribute 'seek'. You can only torch.load from a file that is seekable. Please pre-load the data into a buffer like io.BytesIO and try to load from it instead.

Is there a way to avoid this?

Thanks

1 Like
2

What is the Path object that you create? You can give torch.load() the string containing the path. Otherwise, as said in the error message, you should read the file in a buffer and give that buffer to torch.load().

2 Likes
3

Thanks for the reply. I change the Path object to string object and it works.

4

If you prefer working with pathlib, you can also use the Path.as_posix method to get a string referencing the same file. In that way you can handle paths with Path objects and get the string only when loading/saving the model.

5

I’m having this issue too but I have not change my code nor did I change the version of pytorch (from today to yesterday). May I request a specification of when this error occurs exactly please?

It’s work for months without having to convert to strings.

Thanks in advance.

6

It may be some other library that changed (like the Path one that used to support this in different versions?).
But converting to string should just work.

7

Just to be precise, this is the error I am getting:

AttributeError: 'PosixPath' object has no attribute 'tell'

I don’t understand your guess. What is causing this issue, how do I avoid it? I use Path objs everywhere, how do I know no other weird unexpected bugs will occur?

do you know what is causing this?

1 Like
8

Hi,

The is caused by the fact that the pytorch API expects either a string or a file-like object. And your Path object is neither of them.
Hence my recommendation to change it to a string to call into pytorch’s save/load APIs.

9

my confusion is that I’ve always used Path objects and never had this issue (until I pull a checkpoint from my sever). Why did it decide to throw an error this time but not before?

So to clarify, when can I use Path objects with pytorch? is it just not with torch.save and torch.load?

10

I don’t know.
Since you said that you did not change your pytorch version, my best guess is that you changed the version of the libary providing the Path object?

So to clarify, when can I use Path objects with pytorch? is it just not with torch.save and torch.load?

To be safe i would say you should never give a Path object directly to the pytorch API as it is not supported (even though it might work by change for some versions of pytorch/Path object).

11

sorry for being a complainer but I want to help. Why not instead of passing the responsibility to the user to do this which is sort of unusual you guys have a check or something where it converts to string (or what guarantees it will work most likely). It feels Path objects are standard to work so why not just convert to string or handle a few comment errors?

That would be so wonderful to a such already fantastic library that pytorch is :slight_smile:

12

Hi,

The most likely reason is that we don’t want to add whatever lib provides Path as a dependency. More dependency means slowing build and install time so we try to keep them as low as possible.
That being said, if there is a standard API to extract the string from these objects that won’t require adding new dependencies, I am sure you can add a feature request on github and it will most likely be accepted :slight_smile: