List view
Minor release to push out: * `grouped` bug fix * Jupyter notebook enhancements * Dataframe interoperability enhancements
Due by July 31, 2016•7/7 issues closed`1.0.0` stable release goals undecided yet but could include * SQL support * Revamp readme and documentation * Refine the stated goals/first impression/etc of project
No due date•9/9 issues closed# New Features ## Completed * Parallel Execution Engine ## In Progress * File compression support # Bug Fixes * `jsonl` encoding bug # Additional Notes * `on_error` considered for implementation, but does not fit well with architecture and better handled user-side. * `0.7.0` is slated to be the last `0.X.X` release. Barring any issues, the release following this will be `1.0.0`.
Due by June 5, 2016•12/12 issues closedMilestone for the `0.6.0` release. Focus of this release will be improving SQL interoperability and support compressed file formats. Included Features: * Reading `sqlite3` databases * Writing to `sqlite3` databases * Read/Write from `bz2`, `gzip`, and `xz` file formats Potential Features: * Read/Write from any database using `SQLAlchemy` * Convert sequence to `pandas` DataFrame * Write SQL parser and compiler from SQL to `ScalaFunctional` transformations
Due by February 26, 2016•3/3 issues closedMilestone for the `0.5.0` release. Focus of this release is not decided for certain yet. The first possibility is to abstract the execution engine away so that `ScalaFunctional` can use either a sequential or parallel execution engine. This would need to be done through a combination of `multiprocessing` and determining where it could be used without creating massive code duplication. Additionally, this would require writing completely new tests and infrastructure since order is not guaranteed, but expected in the current sequential tests. Another possible focus is on LINQ. This could take the form of implementing a limited SQL parser and optimizer using `pyparsing`. This might also be giving `select`, `where`, and related methods more definition. For example, if the LINQ functions are used using calls like `select("atr").filter("atr == 1")` be smarter about how they are executed. This is a wide open door, looking for thoughts and suggestions on what is of value. The basic concept is to start working on smarter ways of reading data, although this might tread into the territory of much more mature libraries like `pandas` its dataframes. Another idea is to implement the `_` operator from `fn.py`. It is quite useful, but its overkill to require the library as a dependency and gimmicky to check if it exists just to import. This might open doors to integrate it more deeply as well. What would you like to see?
No due date•3/3 issues closedMilestone for version `0.4.0`. Primary focus of this release will be interoperability of `functional` with data sources. The primary goal is implementing features to read/write from text, csv, json, and jsonl files. A second focus is expanding the API to support the common named functions of LINQ and updating the docs to improve discoverability from this use case.
Due by November 2, 2015•20/20 issues closedMilestone for version `0.3.0`. Primary focus of this release will be improving performance. This will be primarily achieved by changing functions to use generators instead of explicitly returning lists and expanding generators. Other ideas for performance improvements is welcome.
No due date•6/6 issues closed- No due date•3/3 issues closed