81–90 of 166 posts
Clicking around, those that don't seem to be: 1. Obsolete. Either explicitly so (e.g. Google API) or abandoned, without even a minor/patch release (initools, 2010) or in some cases a code commit (e.g. pathtools, 2012) for five years or more. I suspect that they will never be Py3, the community will just move on to alternatives. 2. Working hard to bring support (e.g. ansible). 3. Part of the graphite ecosystem. If the…
I would like to know if fellow HNers who regularly code in Python are using f-strings and type hints in your production code or otherwise. I often find myself inclined to use type hinting.
Earlier quoted context omitted.
Sets, if you mean a collection that contains no more than 1 of something, are easy. Use a map with struct{}{} values. If ordering is important, it's ~30 lines of simple code to encase a slice and a map in a struct and define your desired interface. Testing for a key's existence is easy as well. Accessing a map returns two variables--the 1st is the value itself. The 2nd variable is that "exists" variable you're asking…
Testing membership is the easy part of sets. What about subset, superset, union, intersection, difference? So many problems are trivial thanks to sets. I'd sooner give up regex support in python than the set type, that is how useful they are.
Even if you use the most obvious, naive code to implement fundamental set operation in Go, the resulting program is probably still faster than whatever you're going to write in Python.
In the absolute worst case, you need to generate an extra copy to use with some other type. Mildly annoying for sure, but easily dealt with.
Earlier quoted context omitted.
Testing membership is the easy part of sets. What about subset, superset, union, intersection, difference? So many problems are trivial thanks to sets. I'd sooner give up regex support in python than the set type, that is how useful they are.
Yes, the boolean group operations make many otherwise non-trivial problems remarkably easy. That's why I consider sets such a crucial feature.
Earlier quoted context omitted.
> at this point there is no reason to not use Python 3 for new projects Sure there is: Python 2 isn't going to change on me again. Python 3 might.
Why on earth do people downvote that? I want a language that isn't going to change. Every single other language community seems to understand that, but something about it pisses off Python people.
Python has changed incompatibly once in 26 years, and never plans to do it again, yet you're making it sound like an ongoing pattern. What language are you going to run to that has that kind of track record?
I would like to know if fellow HNers who regularly code in Python are using f-strings and type hints in your production code or otherwise. I often find myself inclined to use type hinting.
I haven't used type hints yet.
Earlier quoted context omitted.
Testing membership is the easy part of sets. What about subset, superset, union, intersection, difference? So many problems are trivial thanks to sets. I'd sooner give up regex support in python than the set type, that is how useful they are.
This repository was named to emphasise the comedy of its existence :) https://github.com/frou/poor-mans-generics/
type Strings map[string]stdext.Unit
[…]
func (a Strings) Intersection(b Strings) Strings {
result := NewStrings()
for as, _ := range a {
for bs, _ := range b {
if as == bs {
result.Add(as)
break
}
}
}
return result
}Earlier quoted context omitted.
Testing membership is the easy part of sets. What about subset, superset, union, intersection, difference? So many problems are trivial thanks to sets. I'd sooner give up regex support in python than the set type, that is how useful they are.
If sets are a good match for your problem (and I agree, they tend to be for many common ones), you definitely should use them in Go. Just write the fucking code. Even if you use the most obvious, naive code to implement fundamental set operation in Go, the resulting program is probably still faster than whatever you're going to write in Python. In the absolute worst case, you need to generate an extra copy to use wit…
If the answer is to generate the Go, then we should be having human beings focus on the more powerful language controlling that generator.
Clicking around, those that don't seem to be: 1. Obsolete. Either explicitly so (e.g. Google API) or abandoned, without even a minor/patch release (initools, 2010) or in some cases a code commit (e.g. pathtools, 2012) for five years or more. I suspect that they will never be Py3, the community will just move on to alternatives. 2. Working hard to bring support (e.g. ansible). 3. Part of the graphite ecosystem. If the…
Lack of commit activity doesn't necessarily mean a package is obsolete. A small set of well defined functionality can be "done" at some point and need no further changes.
Earlier quoted context omitted.
This repository was named to emphasise the comedy of its existence :) https://github.com/frou/poor-mans-generics/
Ouch! type Strings map[string]stdext.Unit […] func (a Strings) Intersection(b Strings) Strings { result := NewStrings() for as, _ := range a { for bs, _ := range b { if as == bs { result.Add(as) break } } } return result }