Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    John Black
    @Fierozen
    Well, after further troubleshooting Saturday morning, it appears this could be solved by validating input to rrule1 = rrule(freq=MONTHLY, dtstart=start_date, interval=repeat_every, wkst=MO,
    byweekday=byweekday, until=until_date)
    byweekday must not be a float
    perhaps perform floor(byweekday) on every input?
    John Black
    @Fierozen

    But now I'm getting a new problem in Python 3.6.5:

    Traceback (most recent call last):
    File "/Users/johnblack/.conda/envs/kashoripy36/lib/python3.6/site-packages/dateutil/parser/_parser.py", line 1022, in <genexpr>
    all(x in string.ascii_uppercase for x in token))
    SystemError: error return without exception set
    Exception ignored in: <generator object parser._could_be_tzname.<locals>.<genexpr> at 0x10e12fba0>

    This error happens hundreds or thousands of time, slowing performance way down, but then seems to generate the same response as 2.7

    John Black
    @Fierozen
    But I only see with a debugger attached.
    John Black
    @Fierozen
    And...its not just dateutil, but mostly functions which use Python 3.6 generators: w(x condition for x in interable)
    Paul Ganssle
    @pganssle
    Definitely doesn't seem right to floor byweekday.
    Generally just use the weekday constants, not integers.
    @Fierozen Feel free to make an issue about validating the inputs of byweekday. Though generally when I make that sort of thing more strict I find that someone was relying on the loose validation for some reason.
    @Fierozen Do you have a minimal example that generates this exception problem?
    John Black
    @Fierozen
    @pganssle Thanks. I'll get together the actual code tonight if I can.
    little snipit should work
    Bernát Gábor
    @gaborbernat
    Cool
    Cheuk Ting Ho
    @Cheukting
    Hi! I will try "Isoparser misinterprets T24:00 #658" today
    Pav A
    @rs2
    Will look at dateutil/dateutil#124
    Cosimo Lupo
    @anthrotype
    I'll grab this low-hanging fruit dateutil/dateutil#736
    Pav A
    @rs2
    Doctests fork: https://github.com/rs2/dateutil
    Pav A
    @rs2
    https://docs.pytest.org/en/latest/example/pythoncollection.html
    Pav A
    @rs2
    @pganssle: Should tzinfo indeed be referencing local file system? 
    Expected:
    datetime.datetime(2012, 1, 19, 17, 21, tzinfo=tzfile('US/Central'))
Got:
    datetime.datetime(2012, 1, 19, 17, 21, tzinfo=tzfile('/usr/share/zoneinfo/America/Chicago'))
    Pav A
    @rs2
    @pganssle Please can you review https://github.com/dateutil/dateutil/pull/749/
    Pav A
    @rs2
    Also the 1995 Kiritimati test results are platform-dependent: https://ci.appveyor.com/project/dateutil/dateutil/build/2.3.1455/job/2d5pece9qpxlbe4w vs https://travis-ci.org/dateutil/dateutil/jobs/389742832. KIR should be west of the International date line from 1995, i.e. 2 Jan in the test.
    Paul Ganssle
    @pganssle
    @rs2 You'll see how I dealt with that here: https://github.com/dateutil/dateutil/blob/master/dateutil/test/test_tz.py#L2596
    Johannes Löthberg
    @kyrias
    Hey, I'm looking into a problem in the python-iCalendar test suite using dateutil 2.7, but I got a bit sidetracked because it seems the dateutil exception thrown is actually wrong.
    The problem is when the test suite is trying to parse https://github.com/collective/icalendar/blob/2003b292f63ef834a153cdd68c912b6686856b1e/src/icalendar/tests/america_new_york.ics#L7. The exception thrown says 'RRULE UNTIL values must be specified in UTC when DTSTART is timezone-aware', but here the UNTIL value is in UTC, while DTSTART is tz-naive.
    And I'm unclear as to whether the exception is just incorrectly worded, or if the test ics file is incorrect.
    Johannes Löthberg
    @kyrias
    Ah, just found the place in the RFC, and it seems like the exception message is indeed incorrectly worded.
    Paul Ganssle
    @pganssle
    I suppose you could take the if to be if and only if in that situation.
    Paul Ganssle
    @pganssle
    Oh I guess it's actually a "when"
    Matt Cooper
    @vtbassmatt
    Hey hey. Normally I would send you a phone number, but I'm in an all-afternoon training right now so chat is better :)
    Our test analytics stuff (currently) requires you to upload JUnit (or NUnit, or TRX, or a bunch of other formats) results in order to track them. Instead of making you call a REST API or something, we have a "PublishTestResults" task.
    Paul Ganssle
    @pganssle
    Ah.
    Is there any way to upload an artifact to somewhere where we can look at it?
    Matt Cooper
    @vtbassmatt
    Since the "docs" leg doesn't create any JUnit results, the PublishTestResults task was throwing a warning about no results found. That's not a problem, it's intended, so I just made that step skip when running the Docs job
    Yes! There's a PublishBuildArtifacts task which will create an "artifact" that then gets attached to the build.
    You can download a ZIP after the build finishes.
    Paul Ganssle
    @pganssle
    Hm... Would be preferable if we could view the contents directly like a website, though a zip file would still be an improvement over "clone the PR branch and build the docs"
    I might just bite the bullet on permissions and go with netlify.
    Matt Cooper
    @vtbassmatt
    Yeah... that's one I've heard a few times. You can string something together with an Azure static content publishing feature, but we haven't made that seamless and easy yet. In fact, I ran out of time to publish the blog post I was trying to write on the topic.
    Paul Ganssle
    @pganssle
    Yeah, no problem. I think Steve Dower was planning on doing something similar for CPython's documentation.
    Matt Cooper
    @vtbassmatt
    I got it working somewhere... let me find that link
    Paul Ganssle
    @pganssle
    On the other question - are the permissions going to be automatically linked to the GH org? Is there any way to achieve that?
    Matt Cooper
    @vtbassmatt
    Yeah, was just about to mention that.
    We don't have that feature yet. It's something we desperately want to do.
    Paul Ganssle
    @pganssle
    It's not a big deal if not, I just know that I've had that problem with Appveyor especially. When I inherited the dateutil config I ended up getting access to some private Google appveyor jobs because it was linked to the former maintainer's appveyor account.
    Matt Cooper
    @vtbassmatt
    In the short term, it won't actually affect you much. You can set up an account with us, but the project is world-readable (well, you have to set it that way), and almost all the interaction happens from GitHub.
    Paul Ganssle
    @pganssle
    Fixed that up but it's something I'd like to avoid. For now I don't think it will be a problem, I'll just create a custom live account for dateutil.
    Matt Cooper
    @vtbassmatt
    Yeah. That's the problem for now.
    Or, you can add several other people as administrators.
    Paul Ganssle
    @pganssle
    Yeah, dateutil is a pretty small project so I'm less worried about that.
    I imagine it'll come soon enough anyway since GH is owned by MS now.