Style suggestions/critiques (rmlibre)

[rmlibre at riseup.net]

You might could consider using numpy, and storing the points in a list
or list-like class. numpy can convert a list into an array, and then you
can do one line binary operations on each element in the list. An
example, let's assume we start with your implementation, and make a list
of your lines:

import numpy as np

l1p1 = l1x1, l1y1 = 0, 0
l1p2 = l1x2, l1y2 = 0, 1
line1 = (l1p1, l1p2)

l2p1 = l2x1, l2y1 = 1, 1
l2p2 = l2x2, l2y2 = 1, 2
line2 = (l2p1, l2p2)

lines = [line1, line2]

# Now convert this into a multi-dimentional array with numpy

array = np.array(lines)
print(array)


>array(
>    [[[0, 0], [0, 1]], [[1, 1], [1, 2]]]
>)


print(array + 2)


>array(
>    [[[2, 2], [2, 3]], [[3, 3], [3, 4]]]
>)


# This works with other binary operators as well. I suggest looking into
# numpy arrays and how you can easily manipulate them. This has the
added
# benefit of having !extremely fast runtime.


# But, I would prefer to create a class with methods like
.make_new_line()
# that takes four points as keyword arguments and a name for the line.
These 
# can be stored in the instance object as a dictionary &/or namedtuple.
That way
# the class automatically names each component of a point, each point,
and each
# line for you. Consider a __getitem__ method as well to return a dict
or
# namedtuple for a certain line. Then you can call them easily with
something like


class Lines:
    """make your custom lines class"""


lines = Lines()
lines.make_new_line("line1", x1=0, y1=1, x2=1, y2=2)
print(lines["line1"])


>array([[0, 1], [1, 2]])


print(lines["line1"]["p1"])


>array([0, 1])


# this would look cleaner with namedtuple syntax. I suggest googling
that.
# Then you can get syntax like


lines["line1"].x1


>0


# I prefer dot syntax to bracketed key look-ups. So I might even do some
# self.__dict__ manipulation in .make_new_line to add the name of the
line 
# directly to the instance dictionary. But this comes with too many
warnings 
# than I will go into. But, then you can automagically get syntax like


print(lines.line1.p2)


>array([1, 2])


# The up-front cost would be greater with creating new classes 
# with custom functionality, but your code will greatly increase 
# in readability, maintainability and expressiveness. And, it 
# will just be better in the long run to have a class to automate 
# all the things you want to be able to do with your lines
# and simplify your experience with managing and creating them.




On 2019-08-21 16:00, python-list-request at python.org wrote:
> Send Python-list mailing list submissions to
> 	python-list at python.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
> 	python-list-request at python.org
> 
> You can reach the person managing the list at
> 	python-list-owner at python.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
> 
> Today's Topics:
> 
>    1. Re: Enumerate - int object not subscriptable (Ian Kelly)
>    2. Re: Xlabel and ylabel are not shown (David Lowry-Duda)
>    3. Re: absolute path to a file (Paul St George)
>    4. Style suggestions/critiques (Michael F. Stemper)
>    5. Re: absolute path to a file (Cameron Simpson)
>    6. Re: Which editor is suited for view a python package's
>       source? (jfong at ms4.hinet.net)
>    7. Re: absolute path to a file (Richard Damon)
>    8. Re: Which editor is suited for view a python package's
>       source? (Kyle Stanley)
>    9. Re: Style suggestions/critiques (Aldwin Pollefeyt)
>   10. Re: absolute path to a file (Grant Edwards)
>   11. Re: Style suggestions/critiques (DL Neil)
>   12. Re: Enumerate - int object not subscriptable (Sayth Renshaw)
>   13. Re: python requests get from API and post to another API and
>       remote u' (Pankaj Jangid)
>   14. Re: absolute path to a file (Paul St George)
>   15. Re: Enumerate - int object not subscriptable (Peter Otten)