lycantropos / gon

Geometries processing
https://gon.rtfd.io
MIT License
17 stars 0 forks source link

Release 2.0.0 #45

Closed lycantropos closed 3 years ago

lycantropos commented 3 years ago
codecov[bot] commented 3 years ago

Codecov Report

Merging #45 (f7e2c31) into master (97ec2ce) will decrease coverage by 1.18%. The diff coverage is 93.54%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #45      +/-   ##
==========================================
- Coverage   95.36%   94.17%   -1.19%     
==========================================
  Files          29       22       -7     
  Lines        1963     1529     -434     
==========================================
- Hits         1872     1440     -432     
+ Misses         91       89       -2     
Impacted Files Coverage Δ
gon/core/mix.py 80.44% <80.44%> (ø)
gon/__init__.py 100.00% <100.00%> (ø)
gon/base.py 100.00% <100.00%> (ø)
gon/core/angular.py 100.00% <100.00%> (ø)
gon/core/compound.py 100.00% <100.00%> (ø)
gon/core/contour.py 100.00% <100.00%> (ø)
gon/core/contracts.py 100.00% <100.00%> (ø)
gon/core/empty.py 96.72% <100.00%> (ø)
gon/core/geometry.py 100.00% <100.00%> (ø)
gon/core/iterable.py 100.00% <100.00%> (ø)
... and 29 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 97ec2ce...f7e2c31. Read the comment docs.

lycantropos commented 2 years ago

@rsquires1988: sorry for this backward-incompatible changes, let me describe why we've removed those methods:

raw methods were used to create simple Python-builtins-based representation of gon geometries so we can provide them as arguments to dependencies in a consistent manner (points became tuples of coordinates, contours -- lists of tuples of points coordinates, etc.), and then construct geometries back from outputs using from_raw methods, but after that ground package was introduced which provides common interfaces for geometries and it was used by dependencies, so there's no need in raw/from_raw methods from API perspective and users are free to define their own routines for this kind of tasks.

So, if you need those -- you can define them (for example by writing a small module which subclasses geometries and adds this methods), implementation is here, we can also introduce a separate package that will do this kind of tasks (and potentially add different formats).