Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider moving rfc3339 module under udatetime #19

Closed
iliastsi opened this issue Jul 24, 2017 · 3 comments
Closed

Consider moving rfc3339 module under udatetime #19

iliastsi opened this issue Jul 24, 2017 · 3 comments

Comments

@iliastsi
Copy link
Contributor

Hi!

The udatetime package installs the rfc3339 module at the top-level, effectively shadowing the rfc3339 Python package. Do you think it is possible to move the rfc3339 module under udatetime?

freach added a commit that referenced this issue Aug 7, 2017
@freach freach closed this as completed Aug 7, 2017
@iliastsi
Copy link
Contributor Author

iliastsi commented Aug 7, 2017

Thanks for considering this. To be honest, I had in mind something like this, which moves rfc3339 under udatetime (i.e., import udatetime.rfc3339). I see no reason why the udatetime Python package should install both udatetime and urfc3339 modules, and this also is documented as packaging best practices in PEP 423. In the end, of course, it's up to you (as long as it doesn't conflict with other modules).

Please note that the above patch reverts the fix about out-of-bounds read.

@freach
Copy link
Owner

freach commented Aug 7, 2017

Thanks for clearing that up. You're right managing under udatetime is much cleaner. I reflected your request in 9e929e7 also applied the out-of-bounds read fix in da2b819.

@iliastsi
Copy link
Contributor Author

iliastsi commented Aug 7, 2017

Thanks for taking care of this so quickly :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants