Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds improvements to CSV Importer #33

Merged
merged 9 commits into from
Jul 28, 2017
Merged

Conversation

athityakumar
Copy link
Member

@athityakumar athityakumar commented Jul 7, 2017

Features added :

  • :skiprows option to skip the first skiprows rows
  • Read from .csv.gz format with compression: :gzip option
  • Empty DataFrame is created when CSV file has only headers

Closes issue #15
Closes issue #30
Closes issue #32

Tests are again, yet to be beautified as per PR #27

@athityakumar
Copy link
Member Author

Please review after adding support for .csv.gz files (maybe by tomorrow?). 😄


def process_compression
return ::Zlib::GzipReader.new(open(@path)).read if @compression == :gzip
open(@path)
end
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it fine to compute .gzip readings in the from_csv method itself, or would it be neater to have Importers::CSVGZip inheriting Importers::CSV? I have the same doubt regarding exporter (PR #34) as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm I would say inherit so that there is very explicit division of responsibilities. @zverok WDYT?

.rubocop.yml Outdated
@@ -47,7 +47,7 @@ Metrics/ClassLength:
Max: 200

Metrics/ParameterLists:
Max: 10
Max: 15
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/me looks suspiciously

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zverok - We finally have an Importer with dozens of arguments. 😉

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure it is a good sign, to be honest. Maybe it is time to switch to some options/allowed_options and something.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zverok - Acknowledged. Combined CSV stdlib options like :col_sep, :converters, etc. to **options with default values. It's now back to < 10.

def compression?(algorithm, *formats)
return true if @compression == algorithm
formats.each { |f| return true if @path.end_with?(f) }
false
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe than any? should help here.

.by_col
.map do |col_name, values|
next [col_name, []] if values.nil?
[col_name, values[@skiprows..-1]]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe ?: would be surprisingly more clear here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but I thought that this looked more neater. If not, sure - we can change it to ?:. 👍

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH, I believe that return ... if and next .... if is a last resort (when clear statement of entire algo is impossible, and you need to split it in steps). BUT!!!! If it looks cleaner for you and it is mindful solution -- let it stay. I want to share my experience, not to force my personal styles :)

Copy link
Collaborator

@zverok zverok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, let's merge it. I have some doubts on details, but let's speak about it later.

@athityakumar athityakumar merged commit bd111f7 into master Jul 28, 2017
@athityakumar
Copy link
Member Author

@zverok - Acknowledged, please feel free to open an issue to discuss about the details. (just to make sure it's not forgotten in due course of time 😉 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants