On Wed, Nov 22, 2017 at 9:22 PM, bunslow wrote:
> Something *should* be object oriented with the functions in question all
> operate on the same data type, and in particular, those functions/verbs
> *are only well defined for that type*.
>
But here you are missing something that I think is impor
On 23 November 2017 at 16:34, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Nick Coghlan writes:
>
> > We're not going to start second-guessing the Unicode Consortium on this
> > point - human languages are complicated, and we don't have any special
> > insight on this poi
Nick Coghlan writes:
> We're not going to start second-guessing the Unicode Consortium on this
> point - human languages are complicated, and we don't have any special
> insight on this point that they don't.
Agreed. Python, however, is NOT a (natural) human language, and the
Unicode Consorti
On 23 November 2017 at 15:22, bunslow wrote:
> Something *should* be object oriented with the functions in question all
> operate on the same data type, and in particular, those functions/verbs
> *are only well defined for that type*. heapq.heappush(list-not-heap, item)
> is perfectly valid code
Mikhail V writes:
> A single word written in local language should not. But its a perfect way
> to make whole code look like a mess.
Alex Martelli wrote a couple of interesting posts about his
experiences with multilingual comments back in the discussion of PEP
263. One of them involved a team
Something *should* be object oriented with the functions in question all
operate on the same data type, and in particular, those functions/verbs
*are only well defined for that type*. heapq.heappush(list-not-heap, item)
is perfectly valid code in the current interface, but doesn't make any
sense at
On Wed, Nov 22, 2017 at 10:52 PM, bunslow wrote:
> I'll just note the original proposal I made was specifically designed to
> be the minimum possible improvement, to avoid controversy (and e.g. a PEP).
>
> I agree that there are significant flaws and room for improvement in the
> current heapq mo
Honestly, I don't see the value in a thin object-oriented wrapper around
heapq functions. I'm a big -1 on the idea.
I'm the author of sortedcontainers (
https://pypi.python.org/pypi/sortedcontainers/) so I interact with a lot of
people using sorted collections types. My observations show folk's ne
On 22 November 2017 at 11:00, Chris Angelico wrote:
> So the question is more: why, with Python being the way it is, do the
> heap functions operate on a list? I think heapq.heapify is the answer:
> in linear time, it heapifies a list *in place*.
>
> I don't think there's any reason to have *both
On 21 November 2017 at 21:55, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Personally, I think that Python probably should ban non-ASCII
> non-letter characters in identifiers and whitespace, and maybe add
> them later in response to requests from native speakers of the
> re
On Wed, Nov 22, 2017 at 11:28:20AM +, Alon Snir wrote:
> It would be faster with ‘deque’:
It isn't. According to my testing, your version with deque is
approximately two times slower than the version from toolz.itertoolz
that Wes quotes.
--
Steve
_
It would be faster with ‘deque’:
def roundrobin(*iterables):
iters = deque(map(iter,iterables), len(iterables))
while iters:
try:
yield next(iters[0])
except StopIteration:
iters.popleft()
else:
iters.rotate(-1)
From: Wes Turner
Chris Angelico wrote:
Yeah but if it's wrapping an existing list, it's not really
constructing a new object.
That depends on what you consider the object to be. There
are existing examples of objects that wrap other objects
and mutate them, e.g. TextIOWrapper.
If it would make anyone happier,
I thought the purpose of heapq was to have a ready-made example
for instructors on how an API can be improved by applying object-oriented
techniques. ;-)
I think adding a HeapQueue class would be a great idea. Obviously the
existing functions
would need to continue existing for backward compatibil
On Wed, 22 Nov 2017 00:22:00 -0600
Nick Timkovich
wrote:
>
> Functions are great. I'm a big fan of functions. However,
>
> 1. Once there are several that all have the same thing as an argument:
> thing_operation1(thing, arg), thing_operation2(thing, arg)...it's about
> time to bind them together
On Wed, 22 Nov 2017 17:11:53 +1100
Chris Angelico wrote:
> On Wed, Nov 22, 2017 at 3:55 PM, Greg Ewing
> wrote:
> > Chris Angelico wrote:
> >>
> >> So the question is more: why, with Python being the way it is, do the
> >> heap functions operate on a list? I think heapq.heapify is the answer:
On 22.11.2017 07:22, Nick Timkovich wrote:
Functions are great. I'm a big fan of functions. However,
1. Once there are several that all have the same thing as an argument:
thing_operation1(thing, arg), thing_operation2(thing, arg)...it's
about time to bind them together.
2. And especially for
17 matches
Mail list logo
