Looks like AzureML Python SDK has two Dataset packages exposed over API:
azureml.contrib.dataset
azureml.data
The documentation doesn't clearly mention the difference or when should we use which one? But, it creates confusion for sure. For example, There are two Tabular Dataset classes exposed over API. And they have different APIs for different functions:
azureml.data.TabularDataset
azureml.contrib.dataset.TabularDataset
Any suggestion about when should I use which package will be helpful.
As per the PyPi, azureml.contrib.dataset has been deprecated and azureml.data should be used instead:
The azureml-contrib-dataset package has been deprecated and might not
receive future updates and removed from the distribution altogether.
Please use azureml-core instead.
Related
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
I will need to import and work on few databases containing parameters in bw2, ecoinvent(s) and another db exported from Simapro. While in the past I had used bw2parameters I have seen now the handling of parameters has been also included in bwdata and I am getting a bit confused. what is the workflow now? should I just rely and work with one of the two, both or what? and with which version of the two packages?
thx
Parameters (named variables and formulas stored as strings) are introduced in Brightway2-data version 3.0, which is currently a release candidate. Although we have effectively 100% test coverage and some documentation, I would like to wait a bit before the final release to improve the documentation and make sure that there aren't any bugs that pop up somewhere. That being said, I would feel completely comfortable using the release candidate (along with Brightway2-IO 0.6.RC3, which provides nice ways to specify parameters).
bw2parameters is a library for evaluating a graph of variables and formulas. bw2data is a library for storing, loading, and exporting variables and formulas, tracking when their values are obsolete. They don't compete but instead work together.
I am trying to parse some GHC Core to extract name information and other bits needed.
I am currently using the GHC API given that I haven't found other useful packages help with it.
I've looked through some packages like ghc-core, ghc-core-html and extcore but they seem slightly outdated and I haven't managed to use extcore with ghc-7.10.3.
I have also tried to look for up to date documentation on Core without luck. The best post I've come across is this one, but the discussion is slightly outdated (e.g. compiling the example from these slides, gives a different core dump using the latest ghc.
The question
Having said all this, do you guys know of any recent package that can help in parsing Core? Is there any new documentation regarding CORE manipulation?
Thanks!
The external core feature was removed because it was buggy and a hassle to maintain and if people were using it they didn't speak up. So there is no longer any textual representation of Core intended for machine consumption. Only the internal (AST) representation is available. Of course, I'm sure you'd be welcome to revive the external representation if you want to maintain it.
There are many Haskell SQLite bindings, which implies to me that there are many different tradeoffs on using building/using a SQLite binding. I've tried to read through the documentation of many of these packages but it became a blur after a while, and I was unable to really identify the primary tradeoffs of choosing one over another.
A search on Hackage finds:
direct-sqlite
HDBC-sqlite3
hdbi-sqlite
hsql-sqlite3
hsSqlite3
persistent-sqlite
simplest-sqlite
sql-simple-sqlite
sqlite
sqlite-simple
sqlite-simple-typed
bindings-sqlite3
Nevermind some "meta" SQLite packages. haskelldb-hdbc-sqlite3, haskelldb-hsql-sqlite3, language-sqlite, opaleye-sqlite
Hoping that someone has been able to do this successfully and can help me understand how to choose.
I looked at the package mentioned. Some of these package are a dependency of another package (like opaleye-sqlite and sqlite-simple) depend on direct-sqlite.
Therefore, let's first look at the package that provide the actual driver. Most of them are outdated. There seem to be 3 that still have recent updates:
https://hackage.haskell.org/package/simplest-sqlite https://github.com/YoshikuniJujo/test_haskell/tree/master/features/ffi/sqlite3/simplest-sqlite i wouldn't use it because the repository says "It's just my private Haskell learning/testing repository."
https://hackage.haskell.org/package/persistent-sqlite this one is based on direct-sqlite (seems like part of the direct-sqlite has been forked)
The last one being the direct-sqlite package. I used this website to find which package depend on direct-sqlite. Now leaving out package that don't have the purpose of working with sqlite (such as bake: Continuous integration system). And also leaving out packages that haven't seen updates in a long time.
That leaves us with the following package that provide extra functionality based on direct-sqlite. This list includes more levels of reverse lookup to see which other package make use of the package listed below.
persistent-sqlite as mentioned before
esqueleto
eventful
groundhog-sqlite
opaleye-sqlite
selda-sqlite
sqlite-simple
beam-sqlite
I've had very good experiences with the ...-simple family of libraries. They are very full-featured and sit at a nice medium level of abstraction where you get a large amount of flexibility over how you intereact with the database.
I'm the author of opaleye-sqlite. It is a somewhat experimental version of Opaleye for SQLite. The Postgres version of Opaleye is very solid and used in production in several places, but I only know of one person who has used opaleye-sqlite in production.
As part of a major refactoring of my Node.js app (going DDD), I'm looking for a library that through inspecting code is able to visualize module dependencies (by means of 'requiring' them) between different node-modules.
Visualizing in Table-format is fine, I don't need fancy graphs.
Any Node libraries out there?
If you may accept also some fancy graphs: http://hughsk.github.com/colony/
I do not know if this exists, but I found the following by quick search:
http://toolbox.no.de/packages/subdeps
http://toolbox.no.de/packages/fast-detective
Maybe subdeps is not exactly what you want right now, but I think you could use these projects to make that project yourself?
See also https://github.com/pahen/madge
Create graphs from your CommonJS, AMD or ES6 module dependencies. Could also be useful for finding circular dependencies in your code. Tested on Node.js and RequireJS projects. Dependencies are calculated using static code analysis.
I just published my node-dependency-visualizer, which is a small module, that creates a digraph from your node dependencies. Paired with graphviz/dot you can create a dependency graph as svg (or other image format) which you can include with your documentation, embed in your Readme.md, ...
However, it does not check, whether the dependencies are actually needed in code - not sure, whether the OP meant that with "requiring". Of course this question is old, but this tool might be helpful for others, too.
Sample image (Angluar cli):