3 ms·

You can alternately stick the logic into a function, which maintains the readability. def get_record(row): return { 'name': row[0],

You can alternately stick the logic into a function, which maintains the readability. def get_record(row): return { 'name': row[0], 'shares': int(row[1]), 'price': float(row[2]) } return [ get_record(r) for r in rows ] or return list(map(get_record, rows))

thrdbndndn 3y ago
I do like to use ad hoc functions to make things cleaner (mainly for the handy "early" return behavior), but in this case I don't find it's much better than "just create an empty list first and do a for loop".
- gen220 3y ago
  Personally, I enjoy the pattern of making the return type a dataclass and make this function a static method on the dataclass, something like `def from_data(self, data: Dict) -> PortfolioRow`. In 2023, it's rude to return dictionaries. :)
  - proamdev123 3y ago
    > In 2023, it's rude to return dictionaries. :) Why do you say that? I think you were partially kidding, but also half serious. What’s the issue with returning dictionaries, and why should we be returning dataclasses instead? Asking for my own learning.
    - sanderjd 3y ago
      Data classes are "self-documenting" with respect to the "keys" you can expect to be present. Relatedly, they enable meaningful type hints: def some_method(input: Dict[str, int]): ... You can just as easily call `some_method({"foo": 1})` as `some_method({"bar": 2})`. vs. def some_method(input: MyDataClassWithFoo): ... Now you can't pass a dict where the key is "bar" and presumably get a KeyError when it tries to look up a "foo" key, you can only pass a MyDataClassWithFoo.
    - gen220 3y ago
      Regarding the 2023 part, it's because dataclasses in Python are pretty fully-featured and part of the stdlib, so building rich data structures is quick, ergonomic, and helps remove/centralize boilerplate and parsing (aka validating, see https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...). Regarding rude, yea it was a bit tongue-in-cheek (I would never hold a grudge against somebody for returning a dict). You should generally define an interface for your function that's as precise as its logic allows for. `Dict` is as good as `Any`: it doesn't tell you very much about what the function internally expects. The sibling comment to mine does a good job going through this.

thrdbndndn 3y ago

I do like to use ad hoc functions to make things cleaner (mainly for the handy "early" return behavior), but in this case I don't find it's much better than "just create an empty list first and do a for loop".

gen220 3y ago
Personally, I enjoy the pattern of making the return type a dataclass and make this function a static method on the dataclass, something like `def from_data(self, data: Dict) -> PortfolioRow`. In 2023, it's rude to return dictionaries. :)
- proamdev123 3y ago
  > In 2023, it's rude to return dictionaries. :) Why do you say that? I think you were partially kidding, but also half serious. What’s the issue with returning dictionaries, and why should we be returning dataclasses instead? Asking for my own learning.
  - sanderjd 3y ago
    Data classes are "self-documenting" with respect to the "keys" you can expect to be present. Relatedly, they enable meaningful type hints: def some_method(input: Dict[str, int]): ... You can just as easily call `some_method({"foo": 1})` as `some_method({"bar": 2})`. vs. def some_method(input: MyDataClassWithFoo): ... Now you can't pass a dict where the key is "bar" and presumably get a KeyError when it tries to look up a "foo" key, you can only pass a MyDataClassWithFoo.
  - gen220 3y ago
    Regarding the 2023 part, it's because dataclasses in Python are pretty fully-featured and part of the stdlib, so building rich data structures is quick, ergonomic, and helps remove/centralize boilerplate and parsing (aka validating, see https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...). Regarding rude, yea it was a bit tongue-in-cheek (I would never hold a grudge against somebody for returning a dict). You should generally define an interface for your function that's as precise as its logic allows for. `Dict` is as good as `Any`: it doesn't tell you very much about what the function internally expects. The sibling comment to mine does a good job going through this.