Isaac Morland added the comment:
Not if one of the attributes is something that cannot be part of a typename:
>>> fields = ['def', '-']
>>> namedtuple ('test', fields, rename=True).__doc__
'test(_0, _1)'
>>> namedtuple ('
Isaac Morland added the comment:
OK, so it's pretty clear this is heading towards a rejection, but I can't
help but respond to your points:
On 2 August 2017 at 01:12, Raymond Hettinger wrote:
* This would be a potentially confusing addition to the API.
>
I'm giving a
Isaac Morland added the comment:
On 1 August 2017 at 14:32, R. David Murray wrote:
>
> R. David Murray added the comment:
>
> I wrote a "parameterized tests" extension for unittest, and it has the
> option of autogenerating the test name from the parameter names and
&
Isaac Morland added the comment:
First, another note I would like to point out: this is much nicer to write
within namedtuple than as a wrapper function because it is trivial to use
the existing rename logic when needed, as seen in the diff I provided. I
suppose I could write a wrapper which
Isaac Morland added the comment:
Maybe the issue is that I work with SQL constantly. In SQL, if I say "SELECT
a, b, c FROM t" and table t has columns a, b, c, d, e, f, I can still select a,
b, and c from the result. So to me it is natural that getting a bunch of
attributes returns
Isaac Morland added the comment:
I want a meaningful name to appear in debugging output generated by repr() or
str(), not just _ all over the place. I just don't want to specifically come
up with the meaningful name myself.
Right now I pass in the same generated name ('__'.jo
Isaac Morland added the comment:
Here is the diff. Note that I assume implementation of #31085, which allows me
to push determination of a name for the namedtuple down into namedtuple itself:
diff --git a/Lib/collections/__init__.py b/Lib/collections/__init__.py
index 62cf708..d507d23 100644
New submission from Isaac Morland:
This is meant to replace my proposal in #30020 to change attrgetter to use
namedtuple. By creating a new function implemented in Python, I avoid making
changes to the existing attrgetter, which means that both the need of
implementing a C version and the
Isaac Morland added the comment:
I'm hoping to make a pull request but while I figure that out here is the diff:
diff --git a/Lib/collections/__init__.py b/Lib/collections/__init__.py
index 8408255..62cf708 100644
--- a/Lib/collections/__init__.py
+++ b/Lib/collections/__init__.py
@@ -
New submission from Isaac Morland:
I would like to have the possibility of creating a namedtuple type without
explicitly giving it a name. I see two major use cases for this:
1) Automatic creation of namedtuples for things like CSV files with headers
(see #1818) or SQL results (see #13299
Isaac Morland added the comment:
What are the "other issues"?
As to the issue you raise here, that's why I use rename=True.
First create a type with an underscore attribute:
>>> t = namedtuple ('t', ['a', '1234'], rename=True)
(just a
Isaac Morland added the comment:
I've attached a file which illustrates what I'm proposing to happen with the
examples from the help. Note that attrgetter (attr) is not affected, only
attrgetter (*attrs) for more than one attribute. The idea is that tuples
resulting from
New submission from Isaac Morland:
I would find it useful if the tuples returned by attrgetter functions were
namedtuples. An initial look at the code for attrgetter suggests that this
would be an easy change and should make little difference to performance.
Giving a namedtuple where
Isaac Morland added the comment:
How different is this issue from Issue 1608579, Issue 1239890, Issue 1223238,
and Issue 1314067?
--
___
Python tracker
<http://bugs.python.org/issue9
Isaac Morland added the comment:
This is again being discussed in Issue 9299.
--
___
Python tracker
<http://bugs.python.org/issue1675>
___
___
Python-bugs-list m
Isaac Morland added the comment:
This exact issue has already been discussed in Issue 1675.
--
nosy: +ijmorlan
___
Python tracker
<http://bugs.python.org/issue9
Isaac Morland <[EMAIL PROTECTED]> added the comment:
Ok, good point. Perhaps the documentation should be updated to clarify
that Mac OS is treated as Unix even though a default Mac OS X
installation will have a case-insensitive file system. Wouldn't it be
possible for a Windows mach
New submission from Isaac Morland <[EMAIL PROTECTED]>:
$ python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>&g
Isaac Morland <[EMAIL PROTECTED]> added the comment:
I should add that the full version information is:
Python 2.5 (r25:51908, Aug 15 2007, 11:38:03)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Also, in my actual code (a much larger file, in a project using ll.xist
and
New submission from Isaac Morland <[EMAIL PROTECTED]>:
$ cat bug_fine.py
if True:
max (a='a', 'b')
#elif True:
# pass
else:
pass
$ python bug_fine.py
File "bug_fine.py", line 2
max (a='a', 'b')
SyntaxError:
Isaac Morland added the comment:
RFC 1808 has been obsoleted by RFC 3986:
http://tools.ietf.org/html/rfc3986
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Isaac Morland added the comment:
Issue 1637, Issue 1779700, and Issue 1462525 also relate to this problem.
--
nosy: +ijmorlan
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Isaac Morland added the comment:
I should add that the new parameter is called "excl" by analogy with the
O_EXCL option to os.open().
Also, I'm not absolutely certain about the test for which exceptions
should be ignored when excl == False:
e.errno == errno.EEXIST and path.isd
Isaac Morland added the comment:
Attached is an svn diff against the trunk. I was looking at os.py from
Python 2.5 not the trunk, and it appears that an attempt at fixing the
race condition has already been put into os.py, but I don't believe it's
correct.
The attached patch r
Isaac Morland added the comment:
Yes, I'm really combining two things here - the race condition, which I
argue is a (minor) bug, and a feature request to be able to "ensure
exists" a directory.
I have not produced a proper Python patch before and I have other things
to do so
Changes by Isaac Morland:
Added file: http://bugs.python.org/file9016/makedirs.py
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1675>
__
___
Python-bugs-list
Isaac Morland added the comment:
I would suggest that the need to create directories that may already
exist (really "ensure existence of" directories) is not exclusive to
trace.py. I am suggesting this be added as an option to os.mkdir and
os.makedirs. See Issue 1675.
-
Isaac Morland added the comment:
The only thing I found in the bug database concerning os.makedirs was
Issue 766910 (http://bugs.python.org/issue766910). I realized
os.makedirs had a race condition because in my application I want to
create directories but it's perfectly fine if they al
New submission from Isaac Morland:
There appears to be a race condition in os.makedirs. Suppose two
processes simultaneously try to create two different directories with a
common non-existent ancestor. For example process 1 tries to create
"a/b" and process 2 tries to create "a
Isaac Morland added the comment:
This is probably overkill, but I've created a Python script (attached)
that runs all the tests given in Section 5.4 of RFC 3986. It reports
the following:
baseurl=http://a/b/c/d;p?q
failed for ?y: got http://a/b/c/?y, expected http://a/b/c/d;p?y
faile
30 matches
Mail list logo
