by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Bernát Gábor
    @gaborbernat
    tox on Windows :+1: https://tox.readthedocs.io/en/latest/developers.html#id1 for the adventurous
    László Kiss Kollár
    @lkollar
    dateutil/dateutil#548 for #544
    John Black
    @Fierozen
    On the site "Python 3 Readiness", http://py3readiness.org/ python-dateutil is listed as Python3 ready. But I am getting an error that was commonly found when people moved from Python2 to Python3, "TypeError: list indices must be integers or slices, not float" in line 1230 of dateutil/rrule.py in version 2.7.2. Is anyone familiar with this issue?
    Bernát Gábor
    @gaborbernat
    @pganssle would know :-)
    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
    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
    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.