I actually have no clue if it is always safe to modify a **kwargs. Does it never modify a passed in dictionary?

It would be pretty weird if it could modify a passed in dictionary, since it's an expansion of the keywords. I assume that the only way there would even be a dictionary to pass in would be if you passed it like f(**kwargs). Testing it out on Python 3 seems to indicate that does not modify the dictionary. I can try and read up on it later, though.

def test_func(*args, **kwargs):
    kwargs['demo'] = 9

if __name__ == "__main__":
    kwargs = {}
    test_func(**kwargs)
    print(kwargs)    # {}

    kwargs2 = {'demo': 6}
    test_func(**kwargs)
    print(kwargs)    # {}

I have looked into this a bit and I don't see anyone actually saying this is safe, but it also doesn't seem like the question has come up before - I would guess that it would be surprising if it were unsafe and someone would have commented on it by now. My understanding of how these things are supposed to work makes me fairly certain that this will not be a problem, but I've opened a question on SO just in case.

Either way, if we find that there's some weird situation where it could be a problem, we can just have a second PR that adds kwargs = kwargs.copy() at the top of the function, so I don't see any reason why uncertainty in this regard should be blocking.

Edit: I should have waited a few more minutes, the first answer on the SO says that it's always safe based on the spec.

could do dtstart = kwargs.get('dtstart', None), and therefore be able to reduce all of this by an indent.

Yeah, this is fine. I think the main reason I did it this way is that it avoids the unnecessary replace(tzinfo=None) call at the end, but I'm fine with it either way (I really doubt anyone will be bogged down by any potential performance hit in that case).

@WeatherGod Actually, looking at this, I don't think you can reduce all this by an indent, because if dtstart is None, the dtstart.tzinfo is None and dtstart.replace() calls will fail.

actually, it'll fail for a different reason. dtstart would be None and it wouldn't have the tzinfo attribute. Don't know why I didn't see that originally.

Same here: until = kwargs.get('until', None)

Does it make sense to hard-code is_dst?

@WeatherGod The default for pytz.localize is essentially the same as hard-coding is_dst=False, which is inconsistent with PEP-495, since rrule will never set the fold attribute.

In the end I think very few people will need the feature of choosing which side of a DST fold their ticks are on, but it would not be difficult to add in a later version.