* Added rudimentary command line interface.
* Added documentation on the CLI.
* Added example output.
* Removed _optional wrapper in favour of the built-in get() method.
* Added --version option.
* Removed default for 'attendee'.
* Looping over all vevents now.
* Updated changelog.
Per the feedback from @polyzen in PR #246, in YAML, numeric bare strings
are interpreted as floats, not strings. Versions are strings and should
not be coerced to a float. For example, 7.10 isn't the same as 7.1.
For more details, see Travis issue:
https://github.com/travis-ci/docs-travis-ci-com/pull/1537
I would humbly like to suggest icalendar drop support for Python 2.6.
The last release of Python 2.6 was 2013-10-29. It is no longer receiving
security or bug fixes.
https://www.python.org/dev/peps/pep-0361/
The pip project itself has decided to drop support for 2.6. At the
beginning of the year, their numbers estimated that Python 2.6 accounts
for ~2% of their downloads.
https://github.com/pypa/pip/pull/4343
For projects that still use Python 2.6, they can continue to pip install
an older version.
I've tried my best to remove as much 2.6 specific code as I can,
including the 'Programming Language :: Python :: 2.6' trove classifier
from setup.py. I've also removed Travis CI testing, which should result
in slightly faster testing and fewer wasted resources.
Changed:
* Update documented Python support and trove classifiers
* Update Travis test matrix and tox test matrix
* Use set literals (and more literals in general)
* Use dict comprehension
* Remove dependencies on ordereddict and unittest2
* Remove u string prefix, use more modern unicode literals instead
Invalid escape sequences have been deprecated in Python 3.6. See:
https://docs.python.org/3/whatsnew/3.6.html#deprecated-python-behavior
> A backslash-character pair that is not a valid escape sequence now
> generates a DeprecationWarning. Although this will eventually become a
> SyntaxError, that will not be for several Python releases.
When warnings are enabled, this appears as:
DeprecationWarning: invalid escape sequence ...
Sequences discovered through test suite.
Currently we accept Olson timezone identifiers (tzids) as valid, even
when no matching VTIMEZONE component is present. Windows tzids are
different from Olson tzids, but also far spread. Some software produces
.ics files using those Windows tzids with missing VTIMEZONE components.
While in general our stance is to only support standard compliant .ics
files and try to get the issuer of the invalid .ics files to fix their
software, I believe our chances here are very slim. On the other hand,
a lot of those .ics files exist in the wild and not supporting those
Windows tzids is a source of major inconvenience for our users. We
should there accept Windows tzids as we do for Olson tzids. The unicode
consortium has a suggested mapping from Windows tzids to Olson tzids
[0], which we now make use of.
[0] http://www.unicode.org/cldr/charts/29/supplemental/zone_tzid.html
* Update install.rst
change to pip install instead of not referenced setup.py
* Update CHANGES.rst
add a line for changed install instruction in wiki to use pip
Zone needs to be a python 2 str because it's used as the timezone type name.
Zone name is a python 2 str for consistency with pytz. Needs to be made
unique if the conversion is inexact
Maurits van Rees