| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
* Add python 3.11 support
* ci: use `windows-2019` runners
`windows-2016` runners have been removed
* ci: use CPython 3.11.0-rc.2 for Windows builds
Co-authored-by: Matt Davis <mrd@redhat.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* Adds support for private GHA runner to build for MacOS/arm64
* Split CI/artifact build workflows (hopefully temporarily) since GHA can't do dynamic/conditional matrix
* Moves Windows builds to GHA
|
|
|
|
|
|
|
| |
* enable use of setuptools-embedded distutils
* list 3.10 support
* remove setup.cfg (and deprecated metadata in it)
* run tests on ephemeral copy of intermediate build bits
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
A single dot matches the official YAML 1.1 int regex.
This was probably unintended. The regex now requires at least
a digit before or after the dot.
|
| |
|
|
|
|
| |
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
|
|
|
|
|
|
|
|
|
|
| |
It's time to stop pretending this is anymore compatible to version 2
by using macros to hide the fact that on 3 objects are bytes and not
string.
Removing the support for version 2 makes things clearer.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
|
|
|
|
|
|
| |
Puzzling, but this is the expected behaviour
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
|
|
|
|
|
|
|
|
| |
Make the build work without any warnings.
The cython and C yaml types were differing in definition and that's
no good.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
|
| |
|
| |
|
| |
|
|
|
| |
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was taken from
https://github.com/yaml/pyyaml/issues/369#issuecomment-571596545,
authored by Pekka Klärck <peke@iki.fi>.
In short, Jython doesn't support lone surrogates, so importing yaml (and
in particular, loading `reader.py`) caused a UnicodeDecodeError. This
patch works around this through a clever use of `eval` to defer
evaluation of the string containing the lone surrogates, only doing it
on non-Jython platforms.
This is only done in `lib/yaml/reader.py` and not `lib3/yaml/reader.py`
because Jython does not support Python 3.
With this patch, Jython's behavior with respect to Unicode code points
over 0xFFFF becomes as it was before
0716ae21a1e7ab6b4ef73428c0c8fff49685d057. It still does not pass all the
unit tests on Jython (passes 1275, fails 3, errors on 1); all the
failing tests are related to unicode. Still, this is better than simply
crashing upon `import yaml`.
With this patch, all tests continue to pass on Python 2 / Python 3.
|
| |
|
|
|
|
| |
close #387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Repeated calls to `resolve` can experience performance degredation, if
`add_implicit_resolver` has been called with `first=None` (to add an
implicit resolver with an unspecified first character).
For example, every time `foo` is encountered, the "wildcard implicit
resolvers" (with `first=None`) will be appended to the list of implicit
resolvers for strings starting with `f`, which will normally be the
resolver for booleans. The list `yaml_implicit_resolvers['f']` will keep
getting longer. The same behavior applies for any first-letter matches
with existing implicit resolvers.
This change avoids unintentionally mutating the lists in the class-level
dict `yaml_implicit_resolvers` by looping through a temporary copy.
Fixes: #439
|
|
|
|
|
| |
Per suggestion https://github.com/yaml/pyyaml/issues/420#issuecomment-663888344
move a few constructors from full_load to unsafe_load.
|
|
|
|
|
| |
Are we done with appveyor now?
Can we just remove this file?
|
|
|
|
|
|
|
| |
Is this TOML file actually needed?
I'd prefer to remove it since it does so little, and stands out so
prominiently.
|
|
|
|
| |
End sentences with periods.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Spaces in the syntax make it harder to reason if there will be spaces in
the rendering or not.
|
| |
|
| |
|
| |
|