kicad-developers team mailing list archive

[LordBlick <lordblick@xxxxxxxxx>]

In response to a message written on 11.07.2015, 06:41, from Chris Pavlina:
> > > > > import pcbnew as brd
> > > > > brd.ColorGetName(0)
> > <Swig Object of type 'wxChar *' at 0x7fad80105480>
> > Of course I might deal with ctypes, but I would assume that this is
> > not necessary.
> > > > > import ctypes as ct
> > > > > ct.wstring_at(brd.ColorGetName(0).__long__())
> > u'Black'
>
> Because the pcbnew module is just a SWIG wrapper around the internal
> functions. I'm not personally convinced that's useful - IMO there needs
> to be a further wrapper around that, that converts the interface into
> something more "Pythonic". Get rid of the C++-style getters and setters,
> add proper iterators, etc. But... it is what it is, that's why it does
> that.
Howgh… In my dreams Cython is coming… ;)
> > BTW. Why received string is not compatible with std name space?:
> > > > > ct.wstring_at(brd.ColorGetName(16).__long__())
> > u'Magenta 2'
> > > > > for attr_name in dir(brd):
> > ...   if 'magenta' in attr_name.lower():
> > ...     print("pcbnew.%s:%i" % (attr_name, getattr(brd, attr_name)))
> > ...
> > pcbnew.DARKMAGENTA:10
> > pcbnew.LIGHTMAGENTA:22
> > pcbnew.MAGENTA:16
> > pcbnew.PUREMAGENTA:28
>
> Because you specifically chose to call the function whose purpose is to
> return the UI display names of the colors.
It will be nice if both lists have in some way similar names, for example
PUREMAGENTA - „Pure Magenta” and not „Magenta 4”, as it is with the names of
layers: „B_Cu” - „B.Cu” etc.
That will be easier of namespace management and future improvement. More colors?
The old script will handle it if there will be a function listing their names
and quantity. Layers managment seems almost perfectly(pcbnew.LSET does not
accept python list/tuple with layer static integers, workaround is by hex/bin
parse).
> By the way, I really don't understand your subject line. KiCad's been
> useful for years without a Python interpreter, why would this mean the
> stable release isn't useful?
Logically: If part of something is not fully operational, the whole can also be
rated as not functioning fully. It's just a matter of proportion, but the total
assessment is different. 99.99% != 100%

BTW. You can believe me or not, but the usefulness of the Python function
translates into reduced pressure to introduce and test new functionality or
change the behavior, and results on the minimum size of the core application
code, a time to build, time required for debugging. Today on i7/16GB RAM(all
operations on RAM-disk) full build takes about 20 minutes…
The more plugins and scripts developed and approved separately, the greater the
efficiency and transparency of the whole. Any user can make, what he is
dreaming, and share with other on this, without taking main developers time for
verification, waiting for whether someone has the time and willingness to handle
any amendment.
--
Best Regards,
LordBlick