People are asking why this is needed compared to Arrow and a few other libraries. Personally I was never happy using the python time libraries, it always felt like my use cases were slightly different then the library, and I always found myself getting frustrated over little things here and there. I think there are a LOT of use cases for time in python applications and there is plenty of room for small libraries to satisfy these conditions, versus one monolithic time library that attempts to solve all.
Maya – Python Datetimes for Humans
31–40 of 180 posts
Re: Maya – Python Datetimes for Humans
#32Earlier quoted context omitted.
Who wishes that Requests didnt exist? That guy!!! ^^^^^^^
You comment makes no sense...
He wishes the guy was the sort of guy who contributed to other projects rather than doing his own thing. But if he WAS that sort of guy we wouldn't have Requests.
I thought you guys were supposed to be smart.
Re: Maya – Python Datetimes for Humans
#33Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. There are many good options to claw some performance back so it's really head-scratch inducing that someone would recognize that stdlib datetime is a dog and then wrap it instead of scrapping it.
Re: Maya – Python Datetimes for Humans
#34How does it differ from Arrow which was made several years ago? [1] [1] http://crsmithdev.com/arrow/
The unpythonic interface for Arrow stands out sorely in Python codebases.
I'm not sure I would call Maya particularly pythonic and just like all the other libraries it's API seems to be focused more on fixing issues in other libraries than actually thinking through the problem.
Re: Maya – Python Datetimes for Humans
#35Earlier quoted context omitted.
you'd be surprised, the amount of headache-inducing code that timezones can cause, especially when dealing with servers with different locales than your development machine when doing timezone algebra. This API avoids that problem entirely.
It does not: timezone (TZ) definitions are politicial, inaccurate, and stupid and non versioned. The problem with TZ is TZ in its core definition. 1) they always change: if you have not updated your TZ since 3 months they are probably inaccurate 2) your TZ definition maybe accurate but they may not have been applied for real in the concerned zone 3) you can have different local time for the same longitude 4) you can…
The TZ database has versions and you could at least in theory expose that at a higher level in libraries.
Re: Maya – Python Datetimes for Humans
#36How does it differ from Arrow which was made several years ago? [1] [1] http://crsmithdev.com/arrow/
That would be nice to know. Arrow still seems active, and has been consistently so over the last 3 years. I have a bit of doubt about a time library that defaults to UTC but uses human phrases like "tomorrow". Who thinks about UTC tomorrow?
I have a lot of doubt about a time library that defaults to UTC at all.
Having spent a lot of time dealing with timezones, I have a strong feeling that naive should be the default unless explicitly given a timezone, and your code should blow up when it is given them (or possibly gracefully fail).
Admittedly I haven't had a chance to play with maya as I haven't been able to get it to install.
Re: Maya – Python Datetimes for Humans
#37Earlier quoted context omitted.
You comment makes no sense...
He wishes the guy was the sort of guy who contributed to other projects rather than doing his own thing. But if he WAS that sort of guy we wouldn't have Requests. I thought you guys were supposed to be smart.
No, he doesn't:
> For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives.
Re: Maya – Python Datetimes for Humans
#38Earlier quoted context omitted.
That would be nice to know. Arrow still seems active, and has been consistently so over the last 3 years. I have a bit of doubt about a time library that defaults to UTC but uses human phrases like "tomorrow". Who thinks about UTC tomorrow?
that's why there's `maya.when('yesterday', timezone='US/Eastern')` :)
That's great, but why this then:
>>> tomorrow = maya.when('tomorrow')
>>> tomorrow.slang_date()
'tomorrow'
>>> tomorrow.slang_time()
'23 hours from now'
This is actually my biggest gripe with date+time libs. Imho API should always be explicit in what its default TZ is.
EDIT: still, appreciate what you are doing. Requests rule, and there are many other areas (including datetime) that need libs with better APIs. Thumbs up!
Re: Maya – Python Datetimes for Humans
#39I wonder if the naming isn't a bit unfortunate, seeing that Maya is one of the major 3d packages out there and googling for Maya and Python will almost always lead there (also, not sure whether Autodesk might object...)
Yep. Picking cute short brand names for libraries as though they were startups clutters up the namespace of programmer's conversational language causing ambiguity and obfuscation. It would make life easier if we adopted an informal naming convention for small libraries e.g. . Lang is useful when libraries get ported so you get e.g. PyMayaTime, GoMayaTime etc. Still sounds cute but you know what its for when you pick…
Picking names which collide with stuff seems to be the standard these days. Don't get me started on Google(Chrome, Go)
Re: Maya – Python Datetimes for Humans
#40Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. There are many good options to claw some performance back so it's really head-scratch inducing that someone would recognize that stdlib datetime is a dog and then wrap it instead of scrapping it.
> It's puzzling why this doesn't wrap np.datetime64 instead.
Perhaps to avoid the numpy dependency. I've found numpy a bit heavy and wouldn't want to depend on it simply for the sake of some datetime syntax. May be boost.datetime or even numpy's implementantion on datetime, but that sounds like a lot of maintenance.