-
-
Notifications
You must be signed in to change notification settings - Fork 678
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
v0.15.0 Changes❗ #612
Comments
I still get warnings when I pass a parser string to .get()
|
Hey @sako0938, we made the conscious decision to include the warning on the @systemcatch we could maybe better target the format string warnings to the timestamp token |
@jadchaar @sako0938 that's going to be difficult since many of the changes apply with or without a format string, I think it's easier to just give a general warning despite it being more annoying. For example in current arrow; >>> arrow.get("garbage2017everywhere", "YYYY")
<Arrow [2017-01-01T00:00:00+00:00]> >>> arrow.get("garbage2017everywhere")
<Arrow [2017-01-01T00:00:00+00:00]> arrow 0.15.0 will raise errors for both these cases. |
Sounds great. I mostly wanted to show how to remove the warnings for others since the issue didn't provide all the context needed at the time. |
Hi, I'm a first-time user of arrow with latest version installed (0.14.4). Still can't understand from previous answers that why the example below still has warning. Is something still missing? arrow.get(astring,"YYYY-MM-DD[T]HH:mm:ss.S[Z]")
/Users/whuang/Envs/p2/lib/python2.7/site-packages/arrow/factory.py:249: ArrowParseWarning: The .get() parsing method with a format string will parse more strictly in version 0.15.0.See https://github.com/crsmithdev/arrow/issues/612 for more details. |
Hey @davix, on version 0.14.3+ there will always be a warning generated when arrow.get() does str parsing (with and without a format passed). To disable the warning please use @sako0938 or our solutions. |
From my understanding, a warning means that a user is doing it incorrectly or at least imperfectly. Why is there warning even if a format is provided, I'm curious? or is there a more proper command other that .get()? |
Warnings can be also be used to notify users of upcoming changes to the package. The changes we've made to the .get() method can apply both with and without a format provided. In 0.15.0 these improvements will take effect and the warnings will disappear. |
The flexible |
@joinemm that functionality will still be there, indeed in version 0.15.0 more formats will parse in .get() without any other logic being needed than do currently. |
I started seeing the message today; I'm with @joinemm - .get is one of the main reasons for me to use arrow. I'm very surprised by this move. EDIT |
@systemcatch really? But what about
I feel like these two were very important |
That is the main function why I'm using arrow; parsing rfc3339 and ISO-8601 without needing to deal with TZ mockery in Python. I'd settle with a .get_iso8601 method that doesn't need any formatting input, but deals with any variations of ISO-8601. |
Apologies, this statement needs to be tweaked. We are dropping support for usage like: You can still use Let us know if you all still have concerns and feedback about this. I have tweaked the original message to reflect my comments above. |
@jadchaar Oh ok, looks like it was just badly worded then. So something like |
@joinemm indeed :). We are not trying to break existing workflows, we are just trying to address core parsing issues that have given
As for this, the functionality will still remain intact if you provide a format string like this: This will no longer work though: |
@petermolnar the warning is there so people can see the full list of changes in this issue, thanks to that warning you and @joinemm showed us that the change log was poorly worded which should hopefully mean less confusion for others in the future. The warning will be gone in 0.15.0 which should be released around the end of August. |
The current version of the manual on readthedocs.io says:
However, that code now generates a warning. That forces an ugly choice. Do I put in the warning suppression code, which just adds clutter to my code and adds risk that some new future warning will be unintentionally suppressed, or do I specify the format string for iso8601, which clutters up my code, seems error prone, and also seems like domain specific knowledge that should be built in to Arrow. I have instead decided to just forbid the use of versions 0.14.* by adding the following to my setup.py file: Hopefully things are better in 0.15.*. |
This issue has come up a number of times in different date/time libraries; I last ran into it in MomentJS. The progression is surprisingly consistent:
The proposed solutions are usually:
Discussion of the solutions devolves into camps wanting default strict versus default liberals. As maintainers are in the default strict camp, neither solution is implemented, the library is too hard to use, and starts a declining adoption rate until maintainers are no longer supported by their companies to maintain the package. Is there any way to derail this path? |
Hello @KenKundert that string does not need a format to be passed now or in the future, the warning will occur with or without a format string. This is so users are aware of the changes coming in 0.15.0 which affect both cases. ArrowParseWarning is specific and won't be used after 0.15.0. |
Indeed, take a look at the examples below. They're clearly wrong and introduce errors that are hard to find and debug. I assume you agree these should be fixed?
This change does not make strict parsing the default, it simply corrects obvious errors. Warnings are clearly needed to inform users about these changes, unfortunately due to the parser design it is difficult to provide specific warnings, hence the need for a more general one. |
See this issue thread for more details: #612
Hey all, v0.15.0 has been released! We have made a huge effort to keep things as compatible as possible with previous versions, but this release may potentially break existing code. Here is the final change log: 0.15.0
# will NOT work in v0.15.0
arrow.get("1565358758")
arrow.get("1565358758.123413")
# will work in v0.15.0
arrow.get("1565358758", "X")
arrow.get("1565358758.123413", "X")
arrow.get(1565358758)
arrow.get(1565358758.123413)
This release has been months in the making and @systemcatch and I have put in a ton of work into it. Please do not hesitate to reach out with any feedback or concerns. Thanks! |
Hi, First off, thank you for maintaining arrow, and thank you for addressing some long standing bugs. Second, fallout from several recent arrow fixes have broken us downstream. This is understandable. However, I'm wondering if you would consider switching to semver. Namely:
We've found that major version bumps are a great way of informing downstream users that something has changed that may merit more investigation before deploying. This would allow us to, in this example, pin to Thanks again! |
Hi @escapewindow, @systemcatch and I actually discussed this recently. We decided that we would like to release 1.0.0 once we find that |
Great release, thanks! |
Closing this issue because the v0.15.0 release seems to have gone well. Feel free to open a new issue if new problems arise. Thanks again everyone for contributing to the conversation and helping to make Arrow even better! |
@jadchaar thousands of people/projects are already using the library. By not following standard versioning practices, you're causing headaches for other humans. Please do a major version bump for breaking changes. |
@jmidyet Agreed and we're working on it. |
While I agree with you, I must admit semver says something like « every version in 0.x can break or not, up to the lib ». Lot of packages are 0.x because their maintainer just does not want to deal with backward-forward compatibility. Yes human error happens, breaking change can sneak between two minor change, but semver has a purpose to minimize this. It is a pity some maintainers do not follow it, it makes updating very risky so we end up freezing lib to an old version, decreasing security. Semver is not that hard. Use PBR to automatize version bump or any other similar lib. And a bit of self discipline. By the way, pendulum is a very sexy lib, I am not saying it is better but it looks like it follows semver. |
@gsemet @jmidyet we appreciate your input and apologize if the lack of semver has caused issues. I am a huge fan of semver myself, but Arrow has been in flux the past few years as maintainers have come and gone (I just join the project back in May), but we are heavily discussing a move to semver. @systemcatch and I discussed the potential move recently, but we wanted to keep a 1.0.0 release until after we have complete DST support implemented. That is one of the big lacking features of Arrow that we want to tackle before officially saying this is a non-beta product. 0.15.0 was focused on refactoring and fixing the parsing behavior, and now we are moving focus to DST. If anyone would like to help us implement DST and get the ball rolling on a 1.0.0 release, we'd be happy to help and look over PRs! Also, 1.0.0 should probably be Python 3+. |
@jadchaar probably worth keeping support for 2.7 for 1.0.0 |
Most of major lib has dropped support for 2.7, especially pip. It's time to move one and forget about it. Lot of libs also only works on 3.5+, which makes totally sense. |
is there a way to be strict about the string being parsed? for instance:
returns a valid arrow date, whereas I want it to fail since the string contains more than just the datetime string. edit:
|
…orted in the arrow.get() arrow-py/arrow#612
In the upcoming version 0.15.0 of
arrow
, we will be making a lot of changes to the behavior ofarrow.get()
to address a number of reported parsing bugs. We have outlined the changes below:Fixes
arrow.get()
returning an incorrect arrow object from a partial parsing match have been eliminated.For example,
These will raise a ParserError in 0.15.0.
arrow.get()
method without a format string:arrow.get("1565358758")
. This change was made to support the ISO 8601 basic format and to address bugs such as Odd parsing from list of formats #447.The following will still work as expected:
X
) will now matches float timestamps:arrow.get("1565358758.123415", "X")
.X
) will now only match on strings that strictly contain integers and floats, preventing incorrect matches.New Features
YYYYMMDDThhmmssZ
)"1998-045"
)Issues addressed
Development progress
You can view the progress of these changes here: https://github.com/crsmithdev/arrow/tree/Version-0.15.0.
Disable Warnings
To get rid of the ArrowParseWarning messages in 0.14.3 onwards, do the following:
The text was updated successfully, but these errors were encountered: