Re: [Python-Dev] python 3.3 b2

[Nick Coghlan]

On Tue, Jul 31, 2012 at 2:46 PM, Georg Brandl  wrote:
> Am 30.07.2012 22:59, schrieb Barry Warsaw:
>> On Jul 30, 2012, at 10:22 PM, Georg Brandl wrote:
>>
>>>As I've explained on python-committers, it's currently on hold pending
>>>the resolution of some importlib issues as well as a bug with the
>>>cross-compiling code.  I won't issue a concrete date, but I expect the
>>>release to be made some time before next Sunday.
>>
>> I expect to land the new import documentation (issue 15295) within the next
>> day or so, after I slog through the remaining comments.  I have unpushed 
>> local
>> changes that still need a little polishing, but I don't want it to linger too
>> long.
>
> That's good news; thank you Barry!
>
> And of course big kudos go to Nick, who's sorting out a lot of the latest
> blockers more or less single-handedly :)

With Brett doing so much of the heavy lifting to get importlib
bootstrapped in the first place, helping to file off the last few
rough edges seems like the least I can do :)

Something that has definitely suffered for it is the ipaddress docs,
though - they're still missing the method and attribute details for
the various types (see http://bugs.python.org/issue14814).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python 3.3 b2

[Georg Brandl]

Am 30.07.2012 22:59, schrieb Barry Warsaw:
> On Jul 30, 2012, at 10:22 PM, Georg Brandl wrote:
> 
>>As I've explained on python-committers, it's currently on hold pending
>>the resolution of some importlib issues as well as a bug with the
>>cross-compiling code.  I won't issue a concrete date, but I expect the
>>release to be made some time before next Sunday.
> 
> I expect to land the new import documentation (issue 15295) within the next
> day or so, after I slog through the remaining comments.  I have unpushed local
> changes that still need a little polishing, but I don't want it to linger too
> long.

That's good news; thank you Barry!

And of course big kudos go to Nick, who's sorting out a lot of the latest
blockers more or less single-handedly :)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

[Guido van Rossum]

On Tue, Jul 31, 2012 at 5:25 AM, PJ Eby  wrote:
> On Mon, Jul 30, 2012 at 12:51 PM, Guido van Rossum  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

[PJ Eby]

On Mon, Jul 30, 2012 at 12:51 PM, Guido van Rossum  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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python 3.3 b2

[Barry Warsaw]

On Jul 30, 2012, at 10:22 PM, Georg Brandl wrote:

>As I've explained on python-committers, it's currently on hold pending
>the resolution of some importlib issues as well as a bug with the
>cross-compiling code.  I won't issue a concrete date, but I expect the
>release to be made some time before next Sunday.

I expect to land the new import documentation (issue 15295) within the next
day or so, after I slog through the remaining comments.  I have unpushed local
changes that still need a little polishing, but I don't want it to linger too
long.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python 3.3 b2

[Georg Brandl]

Am 30.07.2012 21:42, schrieb Yury Selivanov:
> Hi all,
> 
> What's the status of Python 3.3 beta 2?

As I've explained on python-committers, it's currently on hold pending
the resolution of some importlib issues as well as a bug with the
cross-compiling code.  I won't issue a concrete date, but I expect the
release to be made some time before next Sunday.

cheers,
Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python 3.3 b2

[Stefan Krah]

Yury Selivanov  wrote:
> What's the status of Python 3.3 beta 2?

It's postponed until next weekend.


Stefan Krah


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python 3.3 b2

[Yury Selivanov]

Hi all,

What's the status of Python 3.3 beta 2?

Thanks,
Yury
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Update PEP-0424 with respect to feedback received.

[Andrew Svetlov]

Sure, GvR covered my question in much more clean way in
http://code.activestate.com/lists/python-dev/117152/

On Mon, Jul 30, 2012 at 9:49 PM, Ifthikhan Nazeem  wrote:
> The question is not very clear. Are you asking whether function arguments
> can have default parameters?
>
> --
> Thanks
> Iftikhan Nazeem
> LinkedIn : http://ae.linkedin.com/in/ifthikhan
>
>
> On Mon, Jul 30, 2012 at 11:23 AM, Andrew Svetlov 
> wrote:
>>
>> On Mon, Jul 30, 2012 at 4:10 AM, alex.gaynor 
>> wrote:
>>
>> > +In addition, a new function ``operator.length`` hint is added
>>
>> ``operator.length`` or ``operator.length_hint``?
>>
>> > +def length_hint(obj, default):
>> Is there default value for `default` parameter?
>> For example:
>>
>> def length_hint(obj, default=0):
>> pass
>>
>> or something like that?
>>
>> --
>> Thanks,
>> Andrew Svetlov
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/iftecan2000%40gmail.com
>
>



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Update PEP-0424 with respect to feedback received.

[Ifthikhan Nazeem]

The question is not very clear. Are you asking whether function arguments
can have default parameters?

--
Thanks
Iftikhan Nazeem
*LinkedIn* : 
http://ae.linkedin.com/in/ifthikhan


On Mon, Jul 30, 2012 at 11:23 AM, Andrew Svetlov
wrote:

> On Mon, Jul 30, 2012 at 4:10 AM, alex.gaynor 
> wrote:
>
> > +In addition, a new function ``operator.length`` hint is added
>
> ``operator.length`` or ``operator.length_hint``?
>
> > +def length_hint(obj, default):
> Is there default value for `default` parameter?
> For example:
>
> def length_hint(obj, default=0):
> pass
>
> or something like that?
>
> --
> Thanks,
> Andrew Svetlov
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/iftecan2000%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

[Guido van Rossum]

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  wrote:
>
>
> On Mon, Jul 30, 2012 at 9:51 AM, Guido van Rossum  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. 10?
>>
>
> 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pushing issue #12288

[Andrew Svetlov]

Pushed. Thank you.

On Mon, Jul 30, 2012 at 7:19 PM, Georg Brandl  wrote:
> Am 30.07.2012 12:21, schrieb Andrew Svetlov:
>> Is there ok to push http://bugs.python.org/issue12288 in 3.3?
>> It looks very easy and straightforward.
>> If now is too alte — I'm ok.
>>
>> Georg Brandl, what's your decision?
>
> Sure, go ahead.  Nobody (I hope) said that every tiny bugfix needs
> my approval.
>
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

[Alex Gaynor]

On Mon, Jul 30, 2012 at 9:51 AM, Guido van Rossum  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. 10?
>
>
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Requesting pronouncement on PEP 0424

[Guido van Rossum]

On Sun, Jul 29, 2012 at 6:11 PM, Alex Gaynor  wrote:
> Guido van Rossum  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. 10?

- 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pushing issue #12288

[Georg Brandl]

Am 30.07.2012 12:21, schrieb Andrew Svetlov:
> Is there ok to push http://bugs.python.org/issue12288 in 3.3?
> It looks very easy and straightforward.
> If now is too alte — I'm ok.
> 
> Georg Brandl, what's your decision?

Sure, go ahead.  Nobody (I hope) said that every tiny bugfix needs
my approval.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] AUTO: Jon K Peck is out of the office

[Jon K Peck]

I am out of the office until 08/02/2012.

I will be out of the office from July 29 through Aug 2.  I expect to have
some access to email but will be delayed in responding.


Note: This is an automated response to your message  "Python-Dev Digest,
Vol 108, Issue 46" sent on 07/30/2012 4:00:03.

This is the only notification you will receive while this person is away.___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Pushing issue #12288

[Andrew Svetlov]

Is there ok to push http://bugs.python.org/issue12288 in 3.3?
It looks very easy and straightforward.
If now is too alte — I'm ok.

Georg Brandl, what's your decision?

-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Update PEP-0424 with respect to feedback received.

[Andrew Svetlov]

On Mon, Jul 30, 2012 at 4:10 AM, alex.gaynor  wrote:

> +In addition, a new function ``operator.length`` hint is added

``operator.length`` or ``operator.length_hint``?

> +def length_hint(obj, default):
Is there default value for `default` parameter?
For example:

def length_hint(obj, default=0):
pass

or something like that?

-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com