New submission from Alexander Boyd:
Itertools would benefit greatly from a function (which I've named intersperse,
after Haskell's equivalent) for yielding the items of an iterator with a given
value placed between each. Sort of a str.join-like function, but for arbitrary
sequences
Alexander Boyd added the comment:
Then perhaps the docstring of relative_to could note this (like relpath does),
or a separate method that's explicitly not symlink safe created.
Or better yet, what about a function that does (or at least tries to) give the
correct answer in the face
New submission from Alexander Boyd:
pathlib.Path.relative_to() blows up when given a path that's not an ancestor of
the path on which relative_to is being called:
pathlib.Path(/usr/bin).relative_to(/etc)
Traceback (most recent call last):
File stdin, line 1, in module
File pathlib.py
Changes by Alexander Boyd a...@opengroove.org:
--
nosy: +javawizard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18144
___
___
Python-bugs-list
Changes by Alexander Boyd a...@opengroove.org:
--
nosy: +javawizard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12955
___
___
Python-bugs-list
Alexander Boyd added the comment:
Yep, that fixes it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19213
___
___
Python-bugs-list mailing list
Alexander Boyd added the comment:
They're providing both /etc/oracle-release and /etc/redhat-release (as Oracle
Linux is based on RHEL).
I've attached /etc/oracle-release for reference.
--
Added file: http://bugs.python.org/file32147/oracle-release
New submission from Alexander Boyd:
Tested on 3.3.2 and 2.6.6.
On Oracle Linux, platform.linux_distribution detects the current distribution
as Red Hat Enterprise Linux:
import platform
platform.linux_distribution()
('Red Hat Enterprise Linux Server', '6.2', 'Santiago')
I would have
Alexander Boyd a...@opengroove.org added the comment:
I've attached a file demonstrating the stack overflow. It assumes
total_ordering has been defined as per new_total_ordering.py.
--
Added file: http://bugs.python.org/file21712/new_total_ordering_overflow.py
Alexander Boyd a...@opengroove.org added the comment:
That's my point. My version, sane_total_ordering.py, fixes this by using
traditional functions and explicit NotImplemented checks.
--
___
Python tracker rep...@bugs.python.org
http
Alexander Boyd a...@opengroove.org added the comment:
Ok. Yeah, I won't argue that it's pretty :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
Alexander Boyd a...@opengroove.org added the comment:
This is not fixed. The accepted fix doesn't take NotImplemented into account,
with the result that comparing two mutually-incomparable objects whose ordering
operations were generated with total_ordering causes a stack overflow instead
Alexander Boyd a...@opengroove.org added the comment:
But it seems pointless to force someone to implement all of the rich comparison
methods when they may want to do something as simple as this:
class Foo:
...
def __lt__(self, other):
if not isinstance(other, Foo
Alexander Boyd a...@opengroove.org added the comment:
Ok. I did write that against Python 2, so I wasn't aware of __eq__ and __ne__.
I'll keep that in mind.
I am curious, however, as to how this could break existing code. It seems like
code that relies on a stack overflow is already broken
14 matches
Mail list logo