in reply to Re: converting JSON to CSV
in thread converting JSON to CSV

I am sorry , I didnt see the code.My finished code is below, let me know if its good coding.

#!/usr/bin/perl use warnings; use strict; use Text::CSV; use JSON::MaybeXS; use FileHandle ; use IO::Handle; local( $/, *FH ) ; open( FH, '<', 'aws.json' ); my $text = <FH>; my $data = decode_json($text); my $csv = Text::CSV->new({auto_diag=>2,binary=>1, eol=>"\n", always_qu +ote=>1 }); my @fields = qw/ Timestamp Average Unit /; $csv->print(select, \@fields); for my $datapoint ( @{ $data->{Datapoints} } ) { $csv->print(select, [ map {$datapoint->{$_}} @fields ]); }

Replies are listed 'Best First'.
Re^3: converting JSON to CSV
by AnomalousMonk (Archbishop) on Apr 07, 2017 at 03:25 UTC
    ... let me know if its good coding.

    What follows is in part my own personal preference, but a lot is current idiomatic Perl; I won't rigorously distingush between the two. My comments pertain to your

    local( $/, *FH ) ; open( FH, '<', 'aws.json' ); my $text = <FH>;
    section of code; the rest is from the AnonyMonk's post and looks good to me. Caveat: I haven't actually tested any of the code on which I'm commenting.
    •     local( ..., *FH ) ;
          open( FH, '<', 'aws.json' );
      local-izing package global variables is better than nothing and you're already using the three-argument open, but it's even better to use a lexical filehandle and check the success of the file open:
          my $filename = 'aws.json';
          open my $fh, '<', $filename or die "opening '$filename': $!";
      (You could also turn on autodie globally with a  use autodie; statement, but I prefer the flexibility of individual die clauses.)
    •     local( $/, ... ) ;
          ...
          my $text = <FH>;
      To do this idiomatic file "slurp" read,  $/ must be undefined. Again, globally undefining this variable (and that's effectively what you're doing, even using local) is not preferred: local-ize in the narrowest practicable scope:
          my $text = do { local $/;  <$fh>; };
    • With the previous two changes, the
          local( $/, *FH ) ;
      statement (and its possibly problematic global effects) goes away entirely. (Update: Actually, the  local( ..., *FH ) ; statement effectively has no semantic global effect WRT the  *main::FH glob because it is local-izing the glob at the top level of the script, where all globs come into existence anyway. The only practical "global" effect is on your expectations: you may be lulled into thinking that you have invoked some kind of magical protection for yourself when you have not.)


    Give a man a fish:  <%-{-{-{-<

Re^3: converting JSON to CSV
by shmem (Chancellor) on Apr 07, 2017 at 21:11 UTC

    Just TIMTOWTDI...

    AnomalousMonk already mentioned the issue with local. Localizing is pointless when it happens at top level - in the same way as my variables are global variables if declared at top level in a program that consists in just 1 file without imports.

    So, local needs a place. A bare block is convenient:

    my $text; # but see above ;-) { local( $/, *FH ) ; open( FH, '<', 'aws.json' ); $text = <FH>; } # $/ restored to default here # FH is an empty typeglob in the symbol table

    See also my/local, space/time (was: Re: The difference between my and local)

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

      Just to pick a nit:

      Localizing is pointless when it happens at top level

      Not entirely, e.g. if you've got a file foo.pl that does local $/, and a file bar.pl that does do "foo.pl" (any of eval/do/require/use), then bar.pl is protected from the change to $/.

      I know you also said "a program that consists in just 1 file", but I'd say foo.pl doesn't know if it's being run by perl foo.pl or by being done from another script, or perhaps being run in a persistent process. So localizing would be playing it safe.