As will become evident, I disagree with Steven at almost every point.
However, I think his point about users not reading documentation is
well-taken. Due to hyperlinking, users are very likely to skip past
module docstrings. I suggest two (perhaps informal) additions to the
documentation policy i
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman wrote:
>
> > I mean - given no function to retrieve the canonical key,
> > one would have to resort to:
> >
> > my_key = data.__transform__(given_key)
> > for key, value in data.items():
> > if data.__transform__(key) == my_key:
> > ..
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings wrote:
> On 09/14/2013 03:40 AM, Antoine Pitrou wrote:
> > Hello,
> >
> > Following the python-dev discussion, I've written a PEP to recap the
> > proposal and the various arguments. It's inlined below, and it will
> > probably appear soon at http:
On 14 September 2013 12:44, Steven D'Aprano wrote:
> On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote:
>
>> Personally, if there's a bunch of push-back against just adding
>> TransformDict directly, why don't we make it provisional? I thought that
>> was what provisional was for (mean
On 14 September 2013 12:44, Steven D'Aprano wrote:
> On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote:
>
>> Personally, if there's a bunch of push-back against just adding
>> TransformDict directly, why don't we make it provisional? I thought that
>> was what provisional was for (mean
On 14/09/2013 05:47, Ethan Furman wrote:
On 09/13/2013 08:18 PM, Steven D'Aprano wrote:
You're missing that I'm not iterating over the entire dict, just some
subset ("data") that I got from elsewhere.
Ah, okay. Between you and Antoine I am convinced that .getitem() is a good
thing. So have
On 09/14/2013 03:27 AM, Antoine Pitrou wrote:
On Fri, 13 Sep 2013 21:59:11 -0700
Ethan Furman wrote:
I mean - given no function to retrieve the canonical key,
one would have to resort to:
my_key = data.__transform__(given_key)
for key, value in data.items():
if data.__transform__(key)
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman wrote:
> On 09/14/2013 03:27 AM, Antoine Pitrou wrote:
> > On Fri, 13 Sep 2013 21:59:11 -0700
> > Ethan Furman wrote:
> >>
> >>> I mean - given no function to retrieve the canonical key,
> >>> one would have to resort to:
> >>>
> >>> my_key = data._
On 09/14/2013 10:41 AM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 09:43:13 -0700 Ethan Furman wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
No good reason. What's the name? transform_func?
I had originally thought transform_key, but trans
14.09.13 20:41, Antoine Pitrou написав(ла):
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
No good reason. What's the name? transform_func?
There is one reason -- serialization. For example p
On Sat, 14 Sep 2013 22:07:50 +0300
Serhiy Storchaka wrote:
> 14.09.13 20:41, Antoine Pitrou написав(ла):
> > On Sat, 14 Sep 2013 09:43:13 -0700
> > Ethan Furman wrote:
> >> Still, I think it would be useful to expose the transform function.
> >> Any good reason not to?
> >
> > No good reason. Wha
On 9/14/2013 1:45 PM, antoine.pitrou wrote:
http://hg.python.org/cpython/rev/4f5815747f58
changeset: 85701:4f5815747f58
user:Antoine Pitrou
date:Sat Sep 14 19:45:47 2013 +0200
summary:
Issue #18937: Add an assertLogs() context manager to unittest.TestCase to
ensure that a b
On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou wrote:
> Following the python-dev discussion, I've written a PEP to recap the
> proposal and the various arguments. It's inlined below, and it will
> probably appear soon at http://www.python.org/dev/peps/pep-0455/, too.
>
Thanks, Antoine!
Raymond
I was exercising the alpha two release of 3.4 and noticed that
it is still being built under GCC 4.2.1.
Is there any reason we have to use an old compiler?
I would like to see it built under the latest version of Clang
(like the other tools on the Mac) or under GCC 4.8.1.
I've better using the
In article <70c99f87-e9a5-4838-a1e9-4739fbf2e...@gmail.com>,
Raymond Hettinger wrote:
> I was exercising the alpha two release of 3.4 and noticed that
> it is still being built under GCC 4.2.1.
>
> Is there any reason we have to use an old compiler?
Yes, kinda. It's because the 64-bit/32-bit
On Sat, 14 Sep 2013 12:31:36 -0700
Guido van Rossum wrote:
> On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou wrote:
>
> > Following the python-dev discussion, I've written a PEP to recap the
> > proposal and the various arguments. It's inlined below, and it will
> > probably appear soon at http
On Sep 14, 2013, at 1:32 PM, Ned Deily wrote:
> The
> most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have
> a mature clang but do not provide a 10.6 SDK. Even with using an SDK,
> it's still possible to end up inadvertently linking with the wrong
> versions of system li
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka wrote:
> 14.09.13 20:41, Antoine Pitrou написав(ла):
> > No good reason. What's the name? transform_func?
>
> transform_func looks... truncated. Why not transform_function or trans_func?
The stdlib commonly uses "func" rather than "function". F
On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka wrote:
> 14.09.13 20:41, Antoine Pitrou написав(ла):
>
>> No good reason. What's the name? transform_func?
>>
>
> transform_func looks... truncated. Why not transform_function or
> trans_func?
transform_λ
_
On 14/09/13 23:31, Eli Bendersky wrote:
On Sat, Sep 14, 2013 at 2:55 PM, Serhiy Storchaka mailto:storch...@gmail.com>> wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_fu
+1. A 10.6-only build makes sense.
If you aren't having problems with GCC 4.8, then Clang shouldn't give any
trouble. Honestly, I still think Clang should be a compiler option in Windows
distutils...
Raymond Hettinger wrote:
>
>On Sep 14, 2013, at 1:32 PM, Ned Deily wrote:
>> The
>> most r
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
The stdlib common
On 09/14/2013 05:32 PM, Serhiy Storchaka wrote:
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not tran
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings wrote:
Whenever I read a discussion about the dict, I always wonder whether the
same thing applies to a set. Have you considered the utility of a
TransformSet? Or is it YAGNI?
Well, a TransformSet
25 matches
Mail list logo
