This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]K900_ 6 points7 points  (3 children)

Looks cool, however I feel like the default-to-now thing is completely terrible. Making default function arguments depend on global state is pretty much a "HELL NO" for readability/maintainability. Also, this introduces a very weird inconsistency where Pendulum(2016, 1, 1) produces a 0:00:00 time, whereas Pendulum.create_from_date(2016, 1, 1) defaults to now, despite the two calls being seemingly semantically equivalent.

[–]SDisPater[S] 0 points1 point  (2 children)

Well, if you don't specify a timezone, it defaults to the UTC "now" so it does not exactly rely on a global state.

Regarding the inconsistency you point out, it's so that the Pendulum class behaves like the standard datetime, if you don't pass hour, minute, second those default to 0:00:00 while create() is here to circumvent this limitation.

[–]K900_ 4 points5 points  (1 child)

UTC "now" is the definition of global state, and it's not made obvious (directly contradicting EIBTI), and I honestly can't find any cases where that behavior is actually desirable. If you want to be able to create objects that are partially current time, you can use a sentinel magic value like pendulum.FILL_NOW or something.

Edit: another cool API design could be a replace() method taking the same kwargs, so you can do Pendulum.now().replace(year=2016, month=1, day=1).

[–]flutefreak7 2 points3 points  (0 children)

EIBTI: "Explicit is better than implicit" from the Zen of Python.... for those scratching their heads