3 ms·

Seems like it's written by someone who prefers Ruby or JavaScript -- where there exists already a culture using names which are cute first, even if they are opa

Seems like it's written by someone who prefers Ruby or JavaScript -- where there exists already a culture using names which are cute first, even if they are opaque -- over Python. These method naming choices are baffling Arrow.to() converts to a new timezone? And .replace() applies a relative offset!? Replace the hour field of this object with -1 should not return an object having hour=11. Arrow.get() is doing some kind of quadruple duty, neither of which would I describe as "getting." And what about that class name? Arrow as the name of a package is fine, but what do you expect someone to make of <Arrow [...]> -- what's wrong with arrow.DateTime? Great work on making and releasing something, but this API is surprising -- as in, one would be unable to predict how it works. I will continue using python-dateutil

tripzilch 12y ago
Thank you for putting into words my same initial concerns about this library. Naming should be much clearer than this, with the intention to make code sort-of read like English text as much as possible. Arrow is a fine name[0], but the actual class/object names should be descriptive. Also, not only the fact that .replace() can apply relative time-offsets, the quirky way it signifies it, using singular and plural keyword-parameters, it's a "clever" solution but it's not at all intuitive. When I figured it out, it was more of a relief that at least .replace() does not always apply relative time-offsets (which would have been terrible naming). I wish it was more pythonic, on the whole, agreeing with the way people expect things to behave in Python modules. It says it's inspired by Requests, which gets that very much right, so I was getting my hopes up a little. Arrow.get() is totally named the wrong thing. It does more like a .create(), maybe I would've put that functionality into the constructor. A method called .get() should implement something very similar to what most .get* methods do on standard types and in the standard library. Which is, extract part of an object that is a container-type (optionally with defaults, etc). Of course that operation does not make sense on an Arrow object (and please don't try), so it probably just shouldn't have a .get() method. [0] actually it's not. I've found myself accidentally muscle-memory-typing "Array" a couple of times already. I'd probably have renamed this module early on in the process for that reason alone.

tripzilch 12y ago

Thank you for putting into words my same initial concerns about this library. Naming should be much clearer than this, with the intention to make code sort-of read like English text as much as possible. Arrow is a fine name[0], but the actual class/object names should be descriptive. Also, not only the fact that .replace() can apply relative time-offsets, the quirky way it signifies it, using singular and plural keyword-parameters, it's a "clever" solution but it's not at all intuitive. When I figured it out, it was more of a relief that at least .replace() does not always apply relative time-offsets (which would have been terrible naming). I wish it was more pythonic, on the whole, agreeing with the way people expect things to behave in Python modules. It says it's inspired by Requests, which gets that very much right, so I was getting my hopes up a little. Arrow.get() is totally named the wrong thing. It does more like a .create(), maybe I would've put that functionality into the constructor. A method called .get() should implement something very similar to what most .get* methods do on standard types and in the standard library. Which is, extract part of an object that is a container-type (optionally with defaults, etc). Of course that operation does not make sense on an Arrow object (and please don't try), so it probably just shouldn't have a .get() method. [0] actually it's not. I've found myself accidentally muscle-memory-typing "Array" a couple of times already. I'd probably have renamed this module early on in the process for that reason alone.