In the latest release of torchtext they moved a lot of features to torchtext.legacy, I want to do the same things like torchtext.legacy.data.Field and other features without using legacy, is that can be done? and how?
EDIT:
here is a release note about 0.9.0 version
here is the migration guide
Also, in the first link, there are counterparts for legacy Datasets.
Old answer (might be useful)
You could go for an alias, namely:
import torchtext.legacy as torchtext
But this is a bad idea for multiple reasons:
It became legacy for a reason (you can always change your existing code to torchtext.legacy.data.Field)
Very confusing - torchtext should torchtext, not torchtext.legacy
Unable to import torchtext as... torchtext - because this alias is already taken.
You could also do some workarounds like assigning torch.legacy.data.Field to torch.data.Field and what not, but it is a horrible idea.
If you want to work with this legacy stuff, you can always stay with smaller version of torchtext like 0.8.0 and this would make sense
Related
I am trying to clone and run this repository:
https://github.com/switchablenorms/CelebAMask-HQ
The demo runs with PyTorch 0.4.1, and I am trying to find the corresponding version, how can I find it?
The corresponding torchvision version for 0.4.1 is 0.2.1.
The easiest way is to look it up in the previous versions section. Only if you couldn't find it, you can have a look at the torchvision release data and pytorch's version. There you can find which version, got release with which version!
One way to find the torch-to-torchvision correspondence is by looking at
the tables on https://pypi.org/project/torchvision/
or (even better) https://github.com/pytorch/pytorch/wiki/PyTorch-Versions
Based on that, the current version at the time of this writing is 0.2.2.
I have a Python3 project which uses Biopython package. One of its modules got removed in the latest version so I have to change a small piece of code to support this change. On the other hand this change would break my code for all "old" version of Biopython (which are heavily used on productive systems).
My questions:
What is the proper way to deal with this?
If this makes sense: How do I support old and new package versions at the same time? Do I perform a run time check to see which version I have an then run different code? Or is this a bad idea? If you think this is the way to go: Is there a standard way to do this?
The simplest way to ensure a specific version is present is to pin that version in your requirements.txt file (or other dependency specifications). There are plenty of systems which rely on legacy versions of packages, and especially for a package without any security implications this is totally reasonable.
If supporting multiple versions is your goal, you could perform some basic checks during your package import process, in an __init__.py file or elsewhere. This pattern is somewhat common, especially useful for version compatibility between Python 2 & 3:
def foo_function():
return
try:
import biopython.foo as foo
except (ImportError, AttributeError):
foo = foo_function
foo()
I have seen this countless times in the wild on GitHub--of course now that I try to find an example I cannot--but I will update this answer with an example when I do.
EDIT: If it's good enough for Numpy, it's probably good enough for the rest of us. numpy_base.pyi L7-13
New to Python and come from a statically typed language background. I want type hints for https://lxml.de just for ease of development (mypy flagging issues and suggesting methods would be nice!)
To my knowledge, this is a python 2.0 module and doesn’t have types. Currently I’ve used https://mypy.readthedocs.io/en/stable/stubgen.html to create stub type definitions and filling in “any”-types I’m using with more information, but it’s really hacky. Are there any safer ways to get type hints?
There is an official stubs package for lxml now called lxml-stubs:
$ pip install lxml-stubs
Note, however, that the stubs are still in development and are not 100% complete yet (although very much usable from my experience). These stubs were once part of typeshed, then curated by Jelle Zijlstra after removal and now are developed as part of the lxml project.
If you want the development version of the stubs, install via
$ pip install git+https://github.com/lxml/lxml-stubs.git
(the project's readme installation command is missing the git+ prefix in URL's scheme and won't work).
Recently I have done much more gap filling based on lxml-stubs with some good progress.
Welcome to check out types-lxml if any late comer are still interested. For most people I think lxml.objectify is the only missing piece lacking from the stubs, which is planned immediately after current release.
I’ve used stubgen to create stub type definitions and filling in “any”-types
This is actually the correct approach if it's not lxml; creating template from mypy stubgen is the starting point for many stub files. But lxml is mostly written in Cython, for which stubgen do not have perfect support yet. Besides as OP noted, this is a python 2.0 era module, and author uses function arguments in a quite polymorphous way. There are lots of unique challenges annotating lxml, as lxml is essentially a python interface for libxml and libxslt in its core.
As an example, the support of both unicode and bytes input complicates matter too; this is the same difficulty found when annotating xml.etree bundled with python, but in a much greater magnitude.
I would not call this "hacky", rather it is gradual typing.
You can take a closer look at lxml-stubs repository. From about:
This repository contains external type annotations (see PEP 484) for the lxml package. Such type annotations are normally included in typeshed, but lxml's annotations were frequently problematic and have therefore been deleted from typeshed. In particular, the stubs are incomplete and it has been difficult to provide complete stubs.
Perhaps it will be useful to you
I have trained the model on a super computer(ubuntu). After the training I used the model with Windows 10 and got this error:
SourceChangeWarning: source code of class 'torch.nn.modules.linear.Linear' has changed. you can retrieve the original source code by accessing the object's source attribute or set `torch.nn.Module.dump_patches = True` and use the patch tool to revert the changes.
warnings.warn(msg, SourceChangeWarning)
I can't load the model I trained.
pytorch version in ubuntu: 1.1.0a0+9a7bcac
pytorch version in windows: 0.4.1
What is going wrong and how can I fix it?
EDIT after comment discussion:
It seems like yor Windows version is outdated and there is thus a version conflict occurring. I would strongly suggest to update the version on Windows to post 1.0 release, which should fix the problem.
According to this link, you can likely ignore the warning (not an error), as long as your model seems to still work as intended. The usual culprit for such changes is that you have inconsistent versions of PyTorch on your two systems, and therefore might encounter this warning.
Generally, the versions are supposed to be fully backward compatible, but of course there is no guarantee for this. It has nothing to do with the fact that you are on Linux and/or Windows, unless the source code detects changes in the line break character (which is the main difference from what I remember), although I think this is very unlikely to be the case.
Thank dennlinger very much!
Is the problem of version.
After I update the pytorch version, it work!
Currently I need to resort in a sparse solver for a project. However I use an old version of Eigen3 on Ubuntu 12.04 (during the thesis I avoid unnecessary updates/upgrades), which means that all the information that I find online cannot be used at the moment because of my outdated version, while the few unsupported tools of my version are very hard to use (weird compilation errors - e.g. with unsupported/Eigen/SparseExtra)
I think that I should upgrade to the last stable version, however it is very critical that I will be able to replicate the numbers of all the experiments that I got with the current outdated version. Is Eigen safe when it comes to backwards compatibility?
Eigen is also a dependency for PCL that I'm using, so I'm not sure if this complicates things. Everything is installed with apt-get. Linking to a new version of Eigen locally for experimentation is not possible, because PCL complains and expects to find Eigen installed globally (i.e. in /usr/local/include).
Eigen is source (API) and binary (ABI) backward compatible (of course, except for unsupported/*). However, the numerical results might be slightly different due to different rounding errors, but that's already the case when, e.g., enabling/disabling SSE or OpenMP.
Since Eigen is header only, it is very easy to try the newest version.