Mailing List Archive: Python: Dev

Requesting pronouncement on PEP 0424

Index | Next | Previous | View Threaded

alex.gaynor at gmail

Jul 28, 2012, 10:05 AM

Post #1 of 13 (456 views)
Permalink

Requesting pronouncement on PEP 0424

Hi all,

The discussion on PEP 0424 seems to have subsided (and I haven't gotten angry
emails in a week!). So I would like to request a BDFL or BDFP pronouncement
on PEP 0424, text available here: http://hg.python.org/peps/file/tip/pep-0424.txt

Alex

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Jul 28, 2012, 10:37 AM

Post #2 of 13 (452 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

I'll pronounce. Give me a few days.

On Sat, Jul 28, 2012 at 10:05 AM, Alex Gaynor <alex.gaynor [at] gmail> wrote:
> Hi all,
>
> The discussion on PEP 0424 seems to have subsided (and I haven't gotten angry
> emails in a week!). So I would like to request a BDFL or BDFP pronouncement
> on PEP 0424, text available here: http://hg.python.org/peps/file/tip/pep-0424.txt

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Jul 28, 2012, 11:35 AM

Post #3 of 13 (452 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

Looks good to me, so accepted.

But why isn't it visible on python.org/dev/peps/ yet?

On Sat, Jul 28, 2012 at 7:37 PM, Guido van Rossum <guido [at] python> wrote:

> I'll pronounce. Give me a few days.
>
> On Sat, Jul 28, 2012 at 10:05 AM, Alex Gaynor <alex.gaynor [at] gmail>
> wrote:
> > Hi all,
> >
> > The discussion on PEP 0424 seems to have subsided (and I haven't gotten
> angry
> > emails in a week!). So I would like to request a BDFL or BDFP
> pronouncement
> > on PEP 0424, text available here:
> http://hg.python.org/peps/file/tip/pep-0424.txt
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
>

--
--Guido van Rossum (python.org/~guido)

benjamin at python

Jul 28, 2012, 11:38 AM

Post #4 of 13 (449 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

2012/7/28 Guido van Rossum <guido [at] python>:
> Looks good to me, so accepted.
>
> But why isn't it visible on python.org/dev/peps/ yet?

The rebuilding hook is broken.

--
Regards,
Benjamin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Jul 28, 2012, 11:51 AM

Post #5 of 13 (451 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

On Sat, 28 Jul 2012 17:05:01 +0000 (UTC)
Alex Gaynor <alex.gaynor [at] gmail> wrote:

> Hi all,
>
> The discussion on PEP 0424 seems to have subsided (and I haven't gotten angry
> emails in a week!). So I would like to request a BDFL or BDFP pronouncement
> on PEP 0424, text available here: http://hg.python.org/peps/file/tip/pep-0424.txt

"It may raise a ``TypeError`` if a 32 specific instance cannot have its
length estimated."

-> what is the consumer supposed to do in this case? Propagate the
error, or use a default value?

Regards

Antoine.

--
Software development and contracting: http://pro.pitrou.net

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Jul 28, 2012, 1:14 PM

Post #6 of 13 (449 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

> But why isn't it visible on python.org/dev/peps/ yet?

Because the build process of the PEPs broke when hg.python.org became
its own system.

I'll try to look into that tomorrow, since unfortunately nobody else
volunteered
to fix it.

Regards,
Martin

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

francismb at email

Jul 29, 2012, 3:13 AM

Post #7 of 13 (450 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

Hi Alex,
just a small info (view pep-0424.txt @ 4491:7838a83c3ad1):

- Section Proposal:

[...] than the actual size >>> ofthe <<< container. [...]

- Section Rationale:
The first line is really long (seems to need a newline before
``__length_hint__``)

Regards

francis

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

alex.gaynor at gmail

Jul 29, 2012, 6:11 PM

Post #8 of 13 (445 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

Guido van Rossum <guido <at> python.org> writes:

>
>
> Looks good to me, so accepted.But why isn't it visible on python.org/dev/peps/
yet?

I just realized the text in the python.org repo did not match what I had locally.
I've pushed what I intended to be the latest text, if everyone could take a new
look at that I would be very grateful. Sorry for the mixup.

Alex

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Jul 30, 2012, 9:51 AM

Post #9 of 13 (443 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

On Sun, Jul 29, 2012 at 6:11 PM, Alex Gaynor <alex.gaynor [at] gmail> wrote:
> Guido van Rossum <guido <at> python.org> writes:
>
>>
>>
>> Looks good to me, so accepted.But why isn't it visible on python.org/dev/peps/
> yet?
>
> I just realized the text in the python.org repo did not match what I had locally.
> I've pushed what I intended to be the latest text, if everyone could take a new
> look at that I would be very grateful. Sorry for the mixup.

NP.

I look a careful look at what's in Hg (still totally different from
what python.org displays) and am proposing a few editorial changes;
please see the review at http://codereview.appspot.com/6447061

Also, I have a few content quibbles:

- Is it really worth flagging a negative return value with ValueError?
I'd just as well clip this to zero. What's the worry? That the
computed value is wrong? But it's only meant to be a hint, and why
would -1 be any more wrong than e.g. 1000000000?

- Did you mean to define operator.length_hint()?

- The default can be zero with no semantic impact, so I think there's
no need to require the caller to specify a default.

- Most importantly: calling len(obj) and catching TypeError can only
be a substitute for the real implementation, which IMO ought to check
for the presence of a tp_len slot. Alas, checking hasattr(obj,
'__len__') doesn't quite cut it either, since this returns true for a
class object that defines a __len__ method for its instances (the
class itself doesn't have a length). Still, I worry that calling
len(obj) and catching all TypeErrors overspecifies the desired
behavior; what I *want* to happen is to check if there is a __len__
method, and if so, call it and let any exceptions bubble through. It
may be best to add a comment explaining that am implementation doesn't
have to follow the letter of the Python code in the PEP, in
particular, if obj *has* a __len__() method but calling it raises an
exception, then length_hint(obj) may (ought to?) pass this exception
on instead of calling obj.__length_hint__().

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

alex.gaynor at gmail

Jul 30, 2012, 9:58 AM

Post #10 of 13 (446 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

On Mon, Jul 30, 2012 at 9:51 AM, Guido van Rossum <guido [at] python> wrote:
>
> Also, I have a few content quibbles:
>
> - Is it really worth flagging a negative return value with ValueError?
> I'd just as well clip this to zero. What's the worry? That the
> computed value is wrong? But it's only meant to be a hint, and why
> would -1 be any more wrong than e.g. 1000000000?
>
>
This was done for consistency with len(), I'm not particularly attached to
any behavior.

> - Did you mean to define operator.length_hint()?
>
>
Of course :)

> - The default can be zero with no semantic impact, so I think there's
> no need to require the caller to specify a default.
>
>
I suppose that's fair.

> - Most importantly: calling len(obj) and catching TypeError can only
> be a substitute for the real implementation, which IMO ought to check
> for the presence of a tp_len slot. Alas, checking hasattr(obj,
> '__len__') doesn't quite cut it either, since this returns true for a
> class object that defines a __len__ method for its instances (the
> class itself doesn't have a length). Still, I worry that calling
> len(obj) and catching all TypeErrors overspecifies the desired
> behavior; what I *want* to happen is to check if there is a __len__
> method, and if so, call it and let any exceptions bubble through. It
> may be best to add a comment explaining that am implementation doesn't
> have to follow the letter of the Python code in the PEP, in
> particular, if obj *has* a __len__() method but calling it raises an
> exception, then length_hint(obj) may (ought to?) pass this exception
> on instead of calling obj.__length_hint__().
>
>
Seems reasonable, rather than try to spec that out precisely in the
pseudocode (aka Python ;)) a note like you suggest sounds good.

> --
> --Guido van Rossum (python.org/~guido)
>

Alex

--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

guido at python

Jul 30, 2012, 10:09 AM

Post #11 of 13 (444 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

If you give my second patch an LGTM I'll submit it and you're done.

On Mon, Jul 30, 2012 at 9:58 AM, Alex Gaynor <alex.gaynor [at] gmail> wrote:
>
>
> On Mon, Jul 30, 2012 at 9:51 AM, Guido van Rossum <guido [at] python> wrote:
>>
>> Also, I have a few content quibbles:
>>
>> - Is it really worth flagging a negative return value with ValueError?
>> I'd just as well clip this to zero. What's the worry? That the
>> computed value is wrong? But it's only meant to be a hint, and why
>> would -1 be any more wrong than e.g. 1000000000?
>>
>
> This was done for consistency with len(), I'm not particularly attached to
> any behavior.
>
>>
>> - Did you mean to define operator.length_hint()?
>>
>
> Of course :)
>
>>
>> - The default can be zero with no semantic impact, so I think there's
>> no need to require the caller to specify a default.
>>
>
> I suppose that's fair.
>
>>
>> - Most importantly: calling len(obj) and catching TypeError can only
>> be a substitute for the real implementation, which IMO ought to check
>> for the presence of a tp_len slot. Alas, checking hasattr(obj,
>> '__len__') doesn't quite cut it either, since this returns true for a
>> class object that defines a __len__ method for its instances (the
>> class itself doesn't have a length). Still, I worry that calling
>> len(obj) and catching all TypeErrors overspecifies the desired
>> behavior; what I *want* to happen is to check if there is a __len__
>> method, and if so, call it and let any exceptions bubble through. It
>> may be best to add a comment explaining that am implementation doesn't
>> have to follow the letter of the Python code in the PEP, in
>> particular, if obj *has* a __len__() method but calling it raises an
>> exception, then length_hint(obj) may (ought to?) pass this exception
>> on instead of calling obj.__length_hint__().
>>
>
> Seems reasonable, rather than try to spec that out precisely in the
> pseudocode (aka Python ;)) a note like you suggest sounds good.
>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>
>
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

pje at telecommunity

Jul 30, 2012, 8:25 PM

Post #12 of 13 (435 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

On Mon, Jul 30, 2012 at 12:51 PM, Guido van Rossum <guido [at] python> wrote:
> - Most importantly: calling len(obj) and catching TypeError can only
> be a substitute for the real implementation, which IMO ought to check
> for the presence of a tp_len slot. Alas, checking hasattr(obj,
> '__len__') doesn't quite cut it either, since this returns true for a
> class object that defines a __len__ method for its instances (the
> class itself doesn't have a length).

This isn't the only place this pattern comes up; maybe a hasmethod()
function somewhere (builtin, operator, inspect?) for this would be a
good idea. (i.e., something that returns true only if the method is
for the instance.)

(But perhaps that's a python-ideas topic, since it raises the question
of whether it should really be something more like instancehasattr(),
or whether it should be limited to special slots or something else.)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Jul 30, 2012, 9:17 PM

Post #13 of 13 (432 views)
Permalink

Re: Requesting pronouncement on PEP 0424 [In reply to]

On Tue, Jul 31, 2012 at 5:25 AM, PJ Eby <pje [at] telecommunity> wrote:
> On Mon, Jul 30, 2012 at 12:51 PM, Guido van Rossum <guido [at] python> wrote:
>> - Most importantly: calling len(obj) and catching TypeError can only
>> be a substitute for the real implementation, which IMO ought to check
>> for the presence of a tp_len slot. Alas, checking hasattr(obj,
>> '__len__') doesn't quite cut it either, since this returns true for a
>> class object that defines a __len__ method for its instances (the
>> class itself doesn't have a length).
>
> This isn't the only place this pattern comes up; maybe a hasmethod()
> function somewhere (builtin, operator, inspect?) for this would be a
> good idea. (i.e., something that returns true only if the method is
> for the instance.)
>
> (But perhaps that's a python-ideas topic, since it raises the question
> of whether it should really be something more like instancehasattr(),
> or whether it should be limited to special slots or something else.)

Yes, please redirect / repost; I read p-ideas too. It's an interesting
topic, if very specialized.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads