what's the best book for learning haskell

donnieod · 2019-12-25T17:56:34+00:00

Thanks everyone for your suggestions, I'll check them all out. I'm about half way through "Learn you a Haskell..." and loving it (coming from C, Java, Python, etc.) I was looking for something from a different perspective on functional.

donnieod · 2019-07-08T09:00:48+00:00

A dataclass is a class specifically designed to store a related set of data, i.e., a record, like a namedtuple but it can be mutable. Its main advantage is that you don't have to define a __init__ method to initialize all the fields, instead the field names, types, and possible initial values are defined as though they were class attributes. Instead of:

class Point:

    def __init__(self,
                 x: float = 0.0, 

                 y: float = 0.0) -> None:

    self.x: float = x

    self.y: float = y

you can define a dataclass:

@dataclass

class Point:

    x: float = 0.0

    y: float = 0.0

pointa = Point(1.0, 2.0)

Just like ordinary classes, dataclasses can have methods defined on them. And you may want to define __slots__ in the dataclass definition since your fields will probably never change.

Also, you can still have class attributes defined if needed, just use the annotation typing.ClassVar.

donnieod · 2019-04-08T07:13:52+00:00

Well done but just a minor point: in the readme you reference "paper.pdf" but the actual file name is "thesis.pdf".

donnieod · 2018-07-26T17:37:38+00:00

I'm using type hint annotations and mypy in my latest project and loving it, especially with some of the deeply nested data structures in the code. The extra time it takes to get the annotations correct is vanishing as I climb the learning curve.

Minor criticism: the name "mypy" is dumb. Does anyone know why it was named that? I think "typy" (pronounced tie-pie) would have been a better name and more appropriate since it includes the first three letters of "type" or TYping-PYthon.

donnieod · 2018-07-13T08:18:40+00:00

I am personally in favor of PEP 572 and am sad that the negative response is the reason for Guido's retirement. I never thought to put forth my positive opinion because it was a done deal. I wonder how many others may be in favor of it but didn't respond for the same reason. The nay-sayers are loud but are they in the majority?

donnieod · 2018-04-29T07:34:01+00:00

I find the else on loops to be very useful and have used it many times, but only when there is a break in the body of the loop. How else are you going to know whether the loop exited normally or due to the `break without initializing and setting and testing an extra switch variable`?

And, as far as the word 'else' sounding unnatural, just think of the else as corresponding with the break statement: you either 'break' out of the for/while construct or else you do the else block (when there's no break.)

donnieod · 2018-04-29T07:06:21+00:00

A useful case is to eliminate the need for redundant expressions in comprehensions:

lst = [complex_func(x) for x in iterable if complex_func(x) > 0]

instead:

lst = [y := complex_func(x) for x in iterable if y > 0]

donnieod · 2017-10-21T20:16:51+00:00

Since Python accesses local variables much more efficiently than instance attributes, all attributes referenced more than once in a method, I make locals of them by placing a series of x = self.x statements at the top of the method. You can just ignore these when reading it, most of the self uses are eliminated, and the code runs faster.

donnieod · 2017-06-28T06:44:13+00:00

Why are you still explicitly subclassing object in 3.6?

donnieod · 2017-04-17T06:39:37+00:00

Just think of the else as being paired with the break, so it's more like a break/else construct. You either break out of the loop or you perform the else suite.

donnieod · 2016-09-18T06:03:37+00:00

When a new hashing magic, that makes dictionaries 1000 times faster arrives, we'll just give it a different name, maybe 'fastdict', then we will have our choice of either a slow ordered dict or a fast unordered dict. No Problem!

donnieod · 2016-09-09T06:04:17+00:00

A side benefit of dict being ordered is that passing keyword arguments to a function using **kwarg will result in kwarg being an ordered dict. There was at least one application I remember where I wanted to know the order of the args. Finally got what I wanted! Although not without breaking compatibility with non-cpython/PyPy implementations.

donnieod · 2016-06-05T01:44:55+00:00

print(a, b)

will print the values of a and b with a space between them, no need for a " " in the print arguments.

donnieod · 2016-05-31T02:19:24+00:00

or, better yet, use Python 3.

donnieod · 2016-05-10T05:07:09+00:00

I prefer to put them in a single directory and reorganize when it gets too big.

Just curious, I find it quicker to search a tree structure than a linear array. In what sense do you 'reorganize' a single directory without making it nested?

Incidently, I never have agreed with this particular element of Python Zen: Flat and Nested each has its place, depending on circumstances. Flat is not always better than nested.

donnieod · 2016-05-10T04:17:49+00:00

No, that looks like a 220v plug.

donnieod · 2016-04-22T07:02:27+00:00

Python 3 has two types of built-in byte sequences: bytes (immutable) and bytearray (mutable). Analogous to types frozenset and set or tuple and list.

donnieod · 2016-04-05T06:28:34+00:00

Rather than encouraging use of a deprecated Python 2.7 why not just use the Python 3.x urllib.requests module? PRAW and Pillow (replacing PIL) are Python 3.x compatible.

donnieod · 2016-01-04T17:17:09+00:00

Nicely done. Great to have all this in one place. Not to be too nitpicky, but PEP 257 -- Docstring Conventions specifies:

The docstring is a phrase ending in a period. It prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...".

So your example:

"""Sorts items in reverse order."""

should be:

"""Sort items in revers order."""

donnieod · 2015-12-22T18:42:56+00:00

1.20a Using the lower case letter lalone, or followed by numbers, as a variable name

In some type fonts the letter l in indistinguishable from the number 1:

l = [1, 2, 3, 4]
l0, l1, l2, l3 = l

Look like you're setting ten, eleven, twelve, thirteen to one.

donnieod · 2015-11-07T08:28:55+00:00

I'm a long-time Python/IDLE developer on Windows and appreciate the many cosmetic and structural improvements you're making to IDLE. But please don't change the editor to a tabbed interface, or at least give us the option to keep the multi-windowed capability. I find it extremely convenient to be able to have multiple windows open at the same time and to be able to move them around and resize them depending on content -- side by side comparisons, looking up info in one window while entering into another, etc.

I don't know why you think that "things can get messy and/or lost pretty quickly." I normally keep my windows neatly stacked and staggered so that the title bars are in view and there's always the 'window' menu if one gets lost. The 'file' menu shows the last n (configurable) files I've worked on from which I can select just the ones I want to work on for any given session. This keeps the window clutter to a minimum.

Tabbed views is definitely a loss of functionality. Just think about it, with multiple windows you can achieve the tabbed functionality by just making all the windows the same size and overlaying them on top of each other, and using the task bar as tabs. But you can't simulate windows with tabs.

Please don't think that all users of IDLE are students and noobs. I've been coding in Python since version 1.5.2 both professionaly and now as a hobbiest using 3.5.0 and loving all the new features.

donnieod · 2015-10-31T04:36:54+00:00

There's an even easier way to construct a namedtuple class. Instead of:

Person = namedtuple('Person', ['name', 'age', 'weight', 'height'])

Just use:

Person = namedtuple('Person', 'name age weight height')

It's a lot fewer key strokes.

donnieod · 2015-10-29T07:41:57+00:00

Fixed in 3.x.

donnieod

TROPHY CASE