On Sat, Jan 24, 2015 at 11:58 AM, Miguel Ángel Ajo <majop...@redhat.com>
wrote:
> Hi, I’ve been playing a bit around, being able to locally define the
> default units [1]
> but I’m not satisfied with it, because the implementation is not thread
> safe (big
> sad-face “:-(“ )
>
> Another option would be to use the default unit from the general settings
(g_UserUnit), that way nothing has to be stored in the python module. Just
user unit versions of the conversion functions would do:
def _from_user_units(val):
unit = pcbnew.GetAbbreviatedUnitsLabel()
if unit == 'in':
return pcbnew.FromMM(float(val) * 25.4)
elif unit == 'mm':
return pcbnew.FromMM(float(val))
However I think this may add more problems than being clear about a default
unit and having easy conversion functions. (mostly on the user side with
forgetting to set/check default units, but also on the internal side where
float rounding issues might appear, 1.0/2.54*2.54 = 0.9999999999999999 with
float precision)
(ignore the Point(x,y) Size(x,y) passing, Piers, you really convinced me
> it’s more reasonable to just use (x,y) where we can.
>
> I have forked your lib here: https://github.com/KiCad/kicad-python
> <https://github.com/KiCad/kicad-python/blob/master/kicad/units.py> to
> retain
> your original authorship.
>
> I have also added sphinx so we can build the docs as normally done for
> python
> APIs [2] and a bit of testing [3] which is passed over here, along with
> pep8 / flake8 checks
> [4], for that may be it’s better to use travis-ci as it has better
> integration to
> github.
>
> Thanks, good to have more structure. What's the reason you didn't rename
pcbnew_easy.py to kicad/pcbnew.py? I don't see the need for a subdirectory
there.
> I will be playing a bit more around the default units context, as a second
> option
> we could default to inches or mm (with the ability to explicitly provide
> other unit
> in parameters).
>
Nice to see these experiments with contexts, it's a nifty idea.
However I still think the easiest and most versatile solution would be to
have default units and a recursive inch_to_mm (or shorter: in2mm) function.
For example combining units like in the following action would be hard with
a units='in' parameter:
m.add_pad(position=in2mm((0, 0.1)), drill=1.0)
I do use both units sometimes because some things are standardized in inch,
like pin header spacing, but in that case I still use metric drill sizes,
so I think this example is a realistic action.
> I would guess that mm is more common among users, because of the european
> origin of the software, but may be a poll would be good here.
>
And most American companies finally use metric units too nowadays (at
least in most datasheets I encounter)
>
> Best regards,
> Miguel Ángel.
>
> [1] https://github.com/KiCad/kicad-python/blob/master/kicad/units.py
> [2] http://ci.kicad-pcb.org/job/kicad-python/ws/doc/build/html/index.html
> [3] https://github.com/KiCad/kicad-python/tree/master/kicad/tests/unit
> [4] http://ci.kicad-pcb.org/job/kicad-python/
>
>
>
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
