[Python-Dev] Fwd: [Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace packages)?

2012-03-12 Thread PJ Eby 
Ugh; this was supposed to be sent to the list, not just Guido.  (I wish
Gmail defaulted to reply-all in the edit box.)

-- Forwarded message --
From: PJ Eby 
Date: Mon, Mar 12, 2012 at 12:16 AM
Subject: Re: [Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace
packages)?
To: Guido van Rossum 


On Sun, Mar 11, 2012 at 10:39 PM, Guido van Rossum  wrote:

> I'm leaning towards PEP 402 or some variant. Let's have a pow-wow at
> the sprint tomorrow (I'll arrive in Santa Clara between 10 and 10:30).
> I do want to understand Nick's argument better; I haven't studied PEP
> 395 yet.
>

Note that PEP 395 can stay compatible with PEP 402 by a fairly
straightforward change: instead of implicitly and automagically guessing
the needed sys.path[0] change, it could be made explicit by adding
something like this to the top of script/modules that are inside a package:

import pkgutil
pkgutil.script_module(__name__, 'mypackage.thismodule')

Assuming __name__=='__main__', the API would set __main__.__qualname__, set
sys.modules[qualname] = __main__, and fix up sys.path[0] if and only if it
still is the parent directory of __main__.__file__.  (If
__name__!=='__main__' and it's not equal to the second argument either,
it'd be an error.)

Then, in the event of broken relative imports or module aliasing, the error
message can suggest adding a script_module() declaration to explicitly make
the file a "dual citizen" -- i.e., script/module.  (It's already possible
for PEP 395 to be confused by stray __init__.py files or __path__
manipulation; using error messages and explicit declaration instead of
guessing seems like a better route for 395 to take.)

Of course, it's also possible to fix the 395/402 incompatibility by
reintroducing some sort of marker, such as .pyp directory extensions or by
including *.pyp marker files within package directories.  The problem is
that these markers work against the intuitive nature of PEP 402 if they are
required, and they do not help 395 if nobody uses them due to their
optionality.  ;-)

(Last, but not least, the compromise approach: allow explicit script/module
declaration as a workaround for virtual packages, AND support automagic
__qualname__ recognition for self-contained packages...  but still give
error messages for broken relative imports and aliasing that suggest the
explicit declaration.)

Anyway, the other open issues for 402 are:

* Dealing with updates to sys.path
* Iterating available virtual packages

There was a Python-Dev discussion about the first, in which I realized that
sys.path updates can actually be handled transparently by making virtual
__path__ objects be special iterables rather than lists; but the PEP hasn't
been updated to reflect that.  (I was actually waiting for some sign of
BDFL interest before adding a potential complication like that to the PEP.)
 The relevant proposal was:

> This seems to lean in favor of making a simple reiterable wrapper
> type for the __path__, that only allows you to take the length and
> iterate over it.  With an appropriate design, it could actually
> update itself automatically, given a subname and a parent
> __path__/sys.path.  That is, it could keep a tuple copy of the
> last-seen parent path, and before iteration, compare
> tuple(self.parent_path) to self.last_seen_path.  If they're
> different, it rebuilds the value to be iterated over.

> Voila: transparent updating of all virtual __path__ values from
> sys.path changes (or modifications to self-contained __path__
> parents, btw), and trying to change it (or read an item from it
> positionally) will not create any silent failures.

> Alright...  *if* we support automatic updates to virtual __paths__,
> this is probably how we should do it.  (It will require, though, that
> imp.find_module be changed to use a different iteration method than
> PyList_GetItem, as it's quite possible a virtual __path__ will get
> passed into it.)

I actually drafted an implementation of this to work with importlib, so it
seems pretty feasible to support automatically-updated virtual paths that
change on the next import attempt if sys.path (or any parent __path__) has
changed since the last time.

Iterating virtual packages is a somewhat harder problem, since it's not
really practical to do an unbounded subdirectory search for importable
files. Probably, the pkgutil module-walking APIs just need to grow some
extra flags for virtual package searching, with some reasonable defaults.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP czar for PEP 3144?

2012-03-12 Thread Peter Moody 
On Wed, Feb 29, 2012 at 9:13 PM, Peter Moody  wrote:
> Just checking in:
>
> On Mon, Feb 20, 2012 at 5:48 PM, Nick Coghlan  wrote:
>> At the very least:
>> - the IP Interface API needs to move to a point where it more clearly
>> *is* an IP Address and *has* an associated IP Network (rather than
>> being the other way around)
>
> This is done [1]. There's cleanup that needs to happen here, but the
> interface classes are now subclasses of the respective address
> classes.
>
> Now I need to apply some consistency and then move on to the remaining
> issues points:
>
>> - IP Network needs to behave more like an ordered set of sequential IP
>> Addresses (without sometimes behaving like an Address in its own
>> right)

This is done [2]. Consistent iterable apis and polish left to do.

Cheers,
peter

[2] 
http://code.google.com/p/ipaddress-py/source/detail?r=578ef1777018211f536cacd29b6750086430fd141

>> - iterable APIs should consistently produce iterators (leaving users
>> free to wrap list() around the calls if they want the concrete
>> realisation)
>
> Cheers,
> peter
>
> [1] 
> http://code.google.com/p/ipaddress-py/source/detail?r=10dd6a68139fb99116219865afcd1c183777e8cc
> (the date is munged b/c I rebased to my original commit before submitting).
>
> --
> Peter Moody      Google    1.650.253.7306
> Security Engineer  pgp:0xC3410038



-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: [Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace packages)?

2012-03-12 Thread Fred Drake 
On Mon, Mar 12, 2012 at 11:43 AM, PJ Eby  wrote:
> I wish Gmail defaulted to reply-all in the edit box.

There's a lab for that.  :-)


  -Fred

-- 
Fred L. Drake, Jr.    
"A person who won't read has no advantage over one who can't read."
   --Samuel Langhorne Clemens
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 417: Adding mock to the Python Standard Library

2012-03-12 Thread Michael Foord 
Hello all,

At the Python Language Summit adding the "mock" library to the Python Standard 
Library was discussed and agreed. Here is a very brief PEP covering the 
decision and rationale.

All the best,

Michael Foord

PEP: 417
Title: Including mock in the Standard Library
Version: $Revision$
Last-Modified: $Date$
Author: Michael Foord 
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 12-Mar-2012
Python-Version: 3.3
Post-History: 12-Mar-2012


Abstract

This PEP proposes adding the mock [1]_  testing library
to the Python standard library as ``unittest.mock``.


Rationale

Creating mock objects for testing is a common need in Python.
Many developers create ad-hoc mocks, as needed, in their test
suites. This is currently what we do in the Python test suite,
where a standardised mock object library would be helpful.

There are many mock object libraries available for Python [2]_.
Of these, mock is overwhelmingly the most popular, with as many
downloads on PyPI as the other mocking libraries combined.

An advantage of mock is that it is a mocking library and not a
framework. It provides a configurable and flexible mock object,
without being opinionated about how you write your tests. The
mock api is now well battle-tested and stable.

mock also handles safely monkeypatching and unmonkeypatching
objects during the scope of a test. This is hard to do safely
and many developers / projects mimic this functionality
(often incorrectly). A standardised way to do this, handling
the complexity of patching in the presence of the descriptor
protocol (etc) is useful. People are asking for a "patch" [3]_
feature to unittest. Doing this via mock.patch is preferable
to re-implementing part of this functionality in unittest.


Background
Addition of mock to the Python standard library was discussed
and agreed to at the Python Language Summit 2012.


References

[1] `mock library on PyPI`_
[2] http://pypi.python.org/pypi?%3Aaction=search&term=mock&submit=search
[3] http://bugs.python.org/issue11664



Copyright

This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





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

[Python-Dev] Job! Python Engineer position

2012-03-12 Thread Watts, Wendy 
Hello, my name is Wendy; I am a IT recruiter for vtrIT which is a
division of Volt Workforce Technical Solutions located in San Francisco.
I have an urgent Senior and Junior Python Engineer positions open for a
client located in CA. I am reaching out to you in finding out your
status of new opportunity, and if we can speak verbal? 

We will pay travel expenses.  

Please job description for your review? 

Specific's of the positions are as follows:

* Job Title - one Sr. Python Engineer and 2 (mid-level) Python
Engineers

* Location:  It must be 100% onsite at client location in
Mountain View, California.

* Duration: six-month  contract

 

If interested please forward me your resume a word attachment and I will
call you ASAP. Email: [email protected]

 

 

 

 

Wendy Watts 

IT Recruiter 

 

VTRIT

100 First Street, Suite 200 I San Francisco, CA 55120 

t: 415.536.5844  I f: 415.536.2845

wwatts@vtrit  .com | vtrit.com

 

 

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

Re: [Python-Dev] Job! Python Engineer position

2012-03-12 Thread Brian Curtin 
On Mon, Mar 12, 2012 at 15:40, Watts, Wendy  wrote:
> Hello, my name is Wendy; I am a IT recruiter for vtrIT which is a division
> of Volt Workforce Technical Solutions located in San Francisco. I have an
> urgent Senior and Junior Python Engineer positions open for a client located
> in CA. I am reaching out to you in finding out your status of new
> opportunity, and if we can speak verbal?

Please do not post jobs to this list. [email protected] is a better
location: http://www.python.org/community/jobs/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 417: Adding mock to the Python Standard Library

2012-03-12 Thread Gregory P. Smith 
+10 for the record.  (given we all already agreed upon this in the summit :)

make it so.

On Mon, Mar 12, 2012 at 3:05 PM, Michael Foord wrote:

> Hello all,
>
> At the Python Language Summit adding the "mock" library to the Python
> Standard Library was discussed and agreed. Here is a very brief PEP
> covering the decision and rationale.
>
> All the best,
>
> Michael Foord
>
>
>
>
> --
> http://www.voidspace.org.uk/
>
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing
> http://www.sqlite.org/different.html
>
>
>
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Job! Python Engineer position

2012-03-12 Thread Watts, Wendy 
Great. Thank you. 



Wendy Watts 
IT Recruiter 

VTRIT
100 First Street, Suite 200 I San Francisco, CA 55120 
t: 415.536.5844  I f: 415.536.2845
[email protected] | vtrit.com



-Original Message-
From: Brian Curtin [mailto:[email protected]] 
Sent: Monday, March 12, 2012 4:01 PM
To: Watts, Wendy
Cc: [email protected]
Subject: Re: [Python-Dev] Job! Python Engineer position

On Mon, Mar 12, 2012 at 15:40, Watts, Wendy  wrote:
> Hello, my name is Wendy; I am a IT recruiter for vtrIT which is a division
> of Volt Workforce Technical Solutions located in San Francisco. I have an
> urgent Senior and Junior Python Engineer positions open for a client located
> in CA. I am reaching out to you in finding out your status of new
> opportunity, and if we can speak verbal?

Please do not post jobs to this list. [email protected] is a better
location: http://www.python.org/community/jobs/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 417: Adding mock to the Python Standard Library

2012-03-12 Thread Guido van Rossum 
More to the point, I am approving the PEP.

We chatted briefly at the sprint and I just want to emphasize that the
external version should not grow new features before the stdlib
version has those same features (we don't want users complaining that
the stdlib version is no good). Also, if you have some new features
you're planning to add, add them now, before inclusion into the
stdlib; and likewise, if you have some things you would like to
remove, remove them now.

Good luck!

--Guido

On Mon, Mar 12, 2012 at 4:01 PM, Gregory P. Smith  wrote:
> +10 for the record.  (given we all already agreed upon this in the summit :)
>
> make it so.
>
> On Mon, Mar 12, 2012 at 3:05 PM, Michael Foord 
> wrote:
>>
>> Hello all,
>>
>> At the Python Language Summit adding the "mock" library to the Python
>> Standard Library was discussed and agreed. Here is a very brief PEP covering
>> the decision and rationale.
>>
>> All the best,
>>
>> Michael Foord
>>
>>
>>
>>
>> --
>> http://www.voidspace.org.uk/
>>
>>
>> May you do good and not evil
>> May you find forgiveness for yourself and forgive others
>> May you share freely, never taking more than you give.
>> -- the sqlite blessing
>> http://www.sqlite.org/different.html
>>
>>
>>
>>
>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: give the AST class a __dict__

2012-03-12 Thread Antoine Pitrou 

On Mon, 12 Mar 2012 17:56:10 +0100
benjamin.peterson  wrote:
> http://hg.python.org/cpython/rev/3877bf2e3235
> changeset:   75542:3877bf2e3235
> user:Benjamin Peterson 
> date:Mon Mar 12 09:46:44 2012 -0700
> summary:
>   give the AST class a __dict__

This seems to have broken the Windows buildbots.

cheers

Antoine.


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

[Python-Dev] New PEP numbering scheme

2012-03-12 Thread Brett Cannon 
It came up at the sprints about how to choose new PEP numbers. It was
agreed that the newest, *lowest* number should be used (e.g. 418) and not
the next highest number (e.g. 3156). I have already updated PEP 1 to
reflect this.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 335 officially rejected

2012-03-12 Thread Guido van Rossum 
We've had many discussions in the past about PEP 335 and they always
ended in non-action. I'm cutting any future discussions short and
officially rejecting the PEP. Amongst other reasons, I really dislike
that the PEP adds to the bytecode for all uses of these operators even
though almost no call sites will ever need the feature.

PS. The NumPy folks brought up a somewhat separate issue: for them,
the most common use case is chained comparisons (e.g. A < B < C). If
someone wants to propose a PEP that makes this case overloadable I
might be amenable to accepting it, since chained comparisons are used
much less frequently than the and/or operators.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New PEP numbering scheme

2012-03-12 Thread Barry Warsaw 
On Mar 12, 2012, at 07:33 PM, Brett Cannon wrote:

>It came up at the sprints about how to choose new PEP numbers. It was
>agreed that the newest, *lowest* number should be used (e.g. 418) and not
>the next highest number (e.g. 3156). I have already updated PEP 1 to
>reflect this.

+1

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

Re: [Python-Dev] PEP 417: Adding mock to the Python Standard Library

2012-03-12 Thread Michael Foord 

On 12 Mar 2012, at 16:31, Guido van Rossum wrote:

> More to the point, I am approving the PEP.
> 
> We chatted briefly at the sprint and I just want to emphasize that the
> external version should not grow new features before the stdlib
> version has those same features (we don't want users complaining that
> the stdlib version is no good). Also, if you have some new features
> you're planning to add, add them now, before inclusion into the
> stdlib; and likewise, if you have some things you would like to
> remove, remove them now.
> 

Thanks. I'm happy to live with new feature releases only every 18 months in the 
external backport.

Before inclusion there is one obsolete feature I'd like to remove 
(mocksignature) and two minor features I'd like to add (support for attribute 
deletion and a helper function for mocking open as a context manager). Beyond 
that the api is stable. A bunch of Python 2  compatibility code can also be 
removed in the standard library version.

All the best,

Michael Foord



> Good luck!
> 
> --Guido
> 
> On Mon, Mar 12, 2012 at 4:01 PM, Gregory P. Smith  wrote:
>> +10 for the record.  (given we all already agreed upon this in the summit :)
>> 
>> make it so.
>> 
>> On Mon, Mar 12, 2012 at 3:05 PM, Michael Foord 
>> wrote:
>>> 
>>> Hello all,
>>> 
>>> At the Python Language Summit adding the "mock" library to the Python
>>> Standard Library was discussed and agreed. Here is a very brief PEP covering
>>> the decision and rationale.
>>> 
>>> All the best,
>>> 
>>> Michael Foord
>>> 
>>> 
>>> 
>>> 
>>> --
>>> http://www.voidspace.org.uk/
>>> 
>>> 
>>> May you do good and not evil
>>> May you find forgiveness for yourself and forgive others
>>> May you share freely, never taking more than you give.
>>> -- the sqlite blessing
>>> http://www.sqlite.org/different.html
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Python-Dev mailing list
>>> [email protected]
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>>> 
>> 
>> 
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>> 
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





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

Re: [Python-Dev] PEP 417: Adding mock to the Python Standard Library

2012-03-12 Thread Guido van Rossum 
On Mon, Mar 12, 2012 at 4:47 PM, Michael Foord  wrote:
>
> On 12 Mar 2012, at 16:31, Guido van Rossum wrote:
>
>> More to the point, I am approving the PEP.
>>
>> We chatted briefly at the sprint and I just want to emphasize that the
>> external version should not grow new features before the stdlib
>> version has those same features (we don't want users complaining that
>> the stdlib version is no good). Also, if you have some new features
>> you're planning to add, add them now, before inclusion into the
>> stdlib; and likewise, if you have some things you would like to
>> remove, remove them now.
>>
>
> Thanks. I'm happy to live with new feature releases only every 18 months in 
> the external backport.
>
> Before inclusion there is one obsolete feature I'd like to remove 
> (mocksignature) and two minor features I'd like to add (support for attribute 
> deletion and a helper function for mocking open as a context manager). Beyond 
> that the api is stable. A bunch of Python 2  compatibility code can also be 
> removed in the standard library version.

Sounds good. Congrats!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: give the AST class a __dict__

2012-03-12 Thread Victor Stinner 
> benjamin.peterson  wrote:
>> http://hg.python.org/cpython/rev/3877bf2e3235
>> changeset:   75542:3877bf2e3235
>> user:        Benjamin Peterson 
>> date:        Mon Mar 12 09:46:44 2012 -0700
>> summary:
>>   give the AST class a __dict__
>
> This seems to have broken the Windows buildbots.

http://hg.python.org/cpython/rev/6bee4eea1efa should fix the
compilation on Windows.

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Review of PEP 362 (signature object)

2012-03-12 Thread Guido van Rossum 
I'm very sympathetic to this PEP. I would accept it outright except I
have a few quibbles on details, and some questions and remarks.

- There are several examples of poor English grammar, perhaps from
your co-author. Can you fix these? (Do you need me to produce a list?)

- You're using an informal notation to indicate compound types, e.g.
dict(str, object). I'm not sure it's worth using this particular
notation without defining it (although maybe the time is ripe for
creating a PEP that proposes a standard use for parameter
annotations...). You're also not using it very consistently

- sig.name is currently the unqualified function name. Now we have
__qualname__ maybe this should be the qualified name instead?

- Did you think about whether var_args and var_kw_args should be '' or
None or undefined if these aren't present in the actual definition?

- If there is no return annotation, is return_annotation None or
undefined? (TBH I think undefined is awkward because you'd have to use
hasattr() to test for its presence. I'd be okay with equating None
with no return annotation. For parameter annotations I'm less sure,
it's not so bad to test for presence in the dict, and you can easily
use .get().)

- I don't quite understand how bind() is supposed to work. Maybe an
example would help? (It could also use some motivation. I think this
is meant to expose a canonical version of the algorithm that maps
arguments to parameters. What's a use case?)

- Why is bind() listed under attributes, while there's also a list of
methods? Is it something funky about self?

- The PEP still seems to support tuple unpacking, which is no longer
supported in Python 3. Please take it out.

- I see it was my idea to give kw-only parameter a valid but
meaningless position. I think I want to revert my opinion; it would be
odd if there's a (kw-only) *parameter* 5 that cannot correspond to
*argument* 5. So let's set it to None if it's kw-only. Maybe
sig.parameters should not have these guys? Or it should have a
separate sig.kw_only_parameters which is a dict??

- There is mention of has_annotation but no definition. Is this due to
a half revision of the PEP? I sort of see the point but maybe it's
more pragmatic to set it to None for an absent annotation? (Later:
maybe I see, there's a similar pattern for defaults, and it does make
sense to distinguish between "x" and "x = y".)

- And why are there two ways of getting the annotations, one via
sig.var_annotations[v] and once via sig[v].annotation ?

- Actually I now see there are also, kind of, two ways to access the
Parameter objects: sig[v] and sig.parameters[i]. But maybe that's more
defensible since we want to be able to access them by position or by
name.

- You have some examples like "var_args(*[1,2,3])" -- I think that
should just be "var_args(1, 2, 3)" right? Similar "var_kw_args(**{'a':
1})" should be "var_kw_args(a=1)"...

- You have some example code using try: [] //
except KeyError: pass // else: . Wouldn't that be expressed
cleaner using if  in :  ?

- Similar, this smells a bit; can you explain or improve?
try:
duck = sig.var_annotations[sig.var_kw_args]
except (KeyError, AttributeError):

That's all I have for now; on to reject^Wreview some more PEPs...

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Review of PEP 362 (signature object)

2012-03-12 Thread Nick Coghlan 
On Tue, Mar 13, 2012 at 10:51 AM, Guido van Rossum  wrote:
> - I don't quite understand how bind() is supposed to work. Maybe an
> example would help? (It could also use some motivation. I think this
> is meant to expose a canonical version of the algorithm that maps
> arguments to parameters. What's a use case?)

I can help with that part: one use case is to give early errors for
bad arguments to delayed calls. Currently, if you have a delayed call
(e.g. a callback of some kind) that accepts (callable, *args, **kwds),
there's no parameter checking until the call actually happens. That
can lead to quite a debugging hunt as you try to track down where the
bad callback was originally registered.

However, with bind() available, you can do an initial sanity check
that the arguments can at least be used to invoke the callable,
throwing an error on *registration* if the callback is simply never
going to work.

Another use case is more sophisticated protocol checking than a simple
hasattr() check for a method name - you can check that the method will
accept the arguments you want to pass, not just whether it exists or
not. (For example, this can help generate better error messages if a
protocol evolves to accept additional optional arguments, but
supporting those arguments is *required* for a particular application)

Regards,
Nick.

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

Re: [Python-Dev] Review of PEP 362 (signature object)

2012-03-12 Thread Brett Cannon 
On Mon, Mar 12, 2012 at 20:51, Guido van Rossum  wrote:

> I'm very sympathetic to this PEP. I would accept it outright except I
> have a few quibbles on details, and some questions and remarks.
>
> - There are several examples of poor English grammar, perhaps from
> your co-author. Can you fix these? (Do you need me to produce a list?)
>

Nope. I will do a re-read since it's an old PEP.


>
> - You're using an informal notation to indicate compound types, e.g.
> dict(str, object). I'm not sure it's worth using this particular
> notation without defining it (although maybe the time is ripe for
> creating a PEP that proposes a standard use for parameter
> annotations...). You're also not using it very consistently
>
> - sig.name is currently the unqualified function name. Now we have
> __qualname__ maybe this should be the qualified name instead?
>

Probably.


>
> - Did you think about whether var_args and var_kw_args should be '' or
> None or undefined if these aren't present in the actual definition?
>

It's an open issue in the PEP. Perhaps they can be set to their default
values of () and {}, respectively?


>
> - If there is no return annotation, is return_annotation None or
> undefined? (TBH I think undefined is awkward because you'd have to use
> hasattr() to test for its presence. I'd be okay with equating None
> with no return annotation. For parameter annotations I'm less sure,
> it's not so bad to test for presence in the dict, and you can easily
> use .get().)
>

I think it should be None since that is what the return value is


>
> - I don't quite understand how bind() is supposed to work. Maybe an
> example would help? (It could also use some motivation. I think this
> is meant to expose a canonical version of the algorithm that maps
> arguments to parameters. What's a use case?)
>

Nick addressed this.


>
> - Why is bind() listed under attributes, while there's also a list of
> methods? Is it something funky about self?
>

Probably just an oversight.


>
> - The PEP still seems to support tuple unpacking, which is no longer
> supported in Python 3. Please take it out.
>

Sure thing.


>
> - I see it was my idea to give kw-only parameter a valid but
> meaningless position. I think I want to revert my opinion; it would be
> odd if there's a (kw-only) *parameter* 5 that cannot correspond to
> *argument* 5. So let's set it to None if it's kw-only. Maybe
> sig.parameters should not have these guys? Or it should have a
> separate sig.kw_only_parameters which is a dict??
>

Yeah, trying to handle these odd cases is one of the reasons I have not
pushed hard for this PEP before. =)


>
> - There is mention of has_annotation but no definition. Is this due to
> a half revision of the PEP? I sort of see the point but maybe it's
> more pragmatic to set it to None for an absent annotation? (Later:
> maybe I see, there's a similar pattern for defaults, and it does make
> sense to distinguish between "x" and "x = y".)
>

I will clarify in the PEP.


>
> - And why are there two ways of getting the annotations, one via
> sig.var_annotations[v] and once via sig[v].annotation ?
>

Probably just made sense for some reason all those years ago.


>
> - Actually I now see there are also, kind of, two ways to access the
> Parameter objects: sig[v] and sig.parameters[i]. But maybe that's more
> defensible since we want to be able to access them by position or by
> name.
>
> - You have some examples like "var_args(*[1,2,3])" -- I think that
> should just be "var_args(1, 2, 3)" right? Similar "var_kw_args(**{'a':
> 1})" should be "var_kw_args(a=1)"...
>
>
Quite possibly.


> - You have some example code using try: [] //
> except KeyError: pass // else: . Wouldn't that be expressed
> cleaner using if  in :  ?
>

Yes. =)


>
> - Similar, this smells a bit; can you explain or improve?
>try:
>duck = sig.var_annotations[sig.var_kw_args]
>except (KeyError, AttributeError):
>
>
Sure.

-Brett


> That's all I have for now; on to reject^Wreview some more PEPs...
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Andrey Petrov 
Hi Pythonistas,

I've had the pleasure of speaking with Guido at PyCon and it became evident
that some of Python's included batteries are significantly lagging behind
the rapidly-evolving defacto standards of the community—specifically in
cases like urllib and urllib2, which lack important features provided by
alternatives like httplib2, requests, and my own urllib3.


Part 1:
I propose we add a snippet to the top of the documentation of specific
archaic standard modules which encourages users to investigate third-party
alternatives if they find the standard module frustrating or otherwise
lacking. These notes would target new users, including those coming from
other languages where the third-party library choices are not nearly as
amazing as they are in Python.

(For what it's worth, Guido has verbally agreed to a proposal of this
nature.)

What such a snippet might look like:

"Batteries are included with Python but sometimes they are old and
leaky—this is one of those cases. Please have a look in PyPI for more
modern alternatives provided by the Python community."

Additionally, I would like for us as a community to identify which other
standard libraries (cgi? ssl? others?) are candidates for this kind of
messaging in the official Python documentation.


Part 2:
I propose we add a new category of package identifiers such as "Topic ::
Standard Library Alternative :: {stdlib_package_name}" which authors of
libraries can tag themselves under. The documentation warning snippet will
provide a link to the appropriate PyPI query to list packages claiming to
be alternatives to the stdlib package in question.


Objections? Concerns? Improvements? What is the next step to making this
happen?

Pythonically yours,
- Andrey (on behalf of Ori Livneh, Kenneth Reitz, Brandon Rhodes, David
Wolever, and everyone else who contributed to this letter during our PyCon
sprint.)



P.S. Appendix: Here are some additional snippet alternatives that were
proposed:

> Batteries are included with Python but sometimes they are old and
leaky—this is one of those cases. Please have a look in PyPI for more
modern alternatives provided by the Python community.

> While this module has served Python programmers faithfully for many
years, there are now many powerful alternatives available as third-party
modules. To learn more about them, view the Python Package Index results
for the category "Topic :: Standard Library Alternative :: asyncore." —
[With the topic name as a hyperlink]

> This module has been identified by the community as crusty, a signal that
better alternatives exist outside the standard library. Because the Python
standard library is constained to maintain backward-compatibility, it does
not always reflect what is current or common in the Python community. If
you are not constrained to support legacy code, you may wish to browse the
Python Package Index for alternatives to this module.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread R. David Murray 
I don't like any of the suggested wordings.  I have no problem with
us recommending other modules, but most of the Python libraries are
perfectly functional (not "leaky" or some other pejorative), they just
aren't as capable as the wiz-bang new stuff that's available on PyPI.

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Eli Bendersky 
On Tue, Mar 13, 2012 at 05:07, R. David Murray  wrote:
> I don't like any of the suggested wordings.  I have no problem with
> us recommending other modules, but most of the Python libraries are
> perfectly functional (not "leaky" or some other pejorative), they just
> aren't as capable as the wiz-bang new stuff that's available on PyPI.
>

 +1 to David's comment, and -0 on the proposal as a whole.

The suggested wordings are simply offensive to those modules & their
maintainers specifically, and to Python generally.

Personally, I think an intelligent user should realize that a
language's standard library won't provide all the latest and shiniest
gadgets. Rather, it will focus on providing stable tools that have
withstood the test of time and can serve as a basis for building more
advanced tools. That intelligent user should also be aware of PyPI
(and the main Python page makes it prominent enough), so I see no
reason explicitly pointing to it in the documentation of several
modules.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread C. Titus Brown 
On Tue, Mar 13, 2012 at 05:22:45AM +0200, Eli Bendersky wrote:
> On Tue, Mar 13, 2012 at 05:07, R. David Murray  wrote:
> > I don't like any of the suggested wordings. ?I have no problem with
> > us recommending other modules, but most of the Python libraries are
> > perfectly functional (not "leaky" or some other pejorative), they just
> > aren't as capable as the wiz-bang new stuff that's available on PyPI.
> >
> 
>  +1 to David's comment, and -0 on the proposal as a whole.
> 
> The suggested wordings are simply offensive to those modules & their
> maintainers specifically, and to Python generally.
> 
> Personally, I think an intelligent user should realize that a
> language's standard library won't provide all the latest and shiniest
> gadgets. Rather, it will focus on providing stable tools that have
> withstood the test of time and can serve as a basis for building more
> advanced tools. That intelligent user should also be aware of PyPI
> (and the main Python page makes it prominent enough), so I see no
> reason explicitly pointing to it in the documentation of several
> modules.

I see the point, but as a reasonably knowledgeable Python programmer
(intelligent? who knows...) I regularly discover nifty new modules
that "replace" stdlib modules.  It'd be nice to have pointers in the
docs, although that runs the risk of having the pointers grow stale,
too.

--titus
-- 
C. Titus Brown, [email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Eli Bendersky 
On Tue, Mar 13, 2012 at 05:25, C. Titus Brown  wrote:
> On Tue, Mar 13, 2012 at 05:22:45AM +0200, Eli Bendersky wrote:
>> On Tue, Mar 13, 2012 at 05:07, R. David Murray  wrote:
>> > I don't like any of the suggested wordings. ?I have no problem with
>> > us recommending other modules, but most of the Python libraries are
>> > perfectly functional (not "leaky" or some other pejorative), they just
>> > aren't as capable as the wiz-bang new stuff that's available on PyPI.
>> >
>>
>>  +1 to David's comment, and -0 on the proposal as a whole.
>>
>> The suggested wordings are simply offensive to those modules & their
>> maintainers specifically, and to Python generally.
>>
>> Personally, I think an intelligent user should realize that a
>> language's standard library won't provide all the latest and shiniest
>> gadgets. Rather, it will focus on providing stable tools that have
>> withstood the test of time and can serve as a basis for building more
>> advanced tools. That intelligent user should also be aware of PyPI
>> (and the main Python page makes it prominent enough), so I see no
>> reason explicitly pointing to it in the documentation of several
>> modules.
>
> I see the point, but as a reasonably knowledgeable Python programmer
> (intelligent? who knows...) I regularly discover nifty new modules
> that "replace" stdlib modules.  It'd be nice to have pointers in the
> docs, although that runs the risk of having the pointers grow stale,
> too.
>

Exactly. It's not the job of the core developers to keep track of the
latest and greatest gadgets and to diligently update the docs when
something new comes out. Note that "the latest and coolest" changes
frequently, so this may mean different "recommendations" between 3.x.y
and 3.x.y+1, which is even more confusing.

Wasn't a PyPI recommendation / voting system discussed a while ago?
*That* would be much more appropriate than officially endorsing
specific modules by pointing to them in the standard documentation.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread C. Titus Brown 
On Tue, Mar 13, 2012 at 05:42:55AM +0200, Eli Bendersky wrote:
> On Tue, Mar 13, 2012 at 05:25, C. Titus Brown  wrote:
> > I see the point, but as a reasonably knowledgeable Python programmer
> > (intelligent? who knows...) I regularly discover nifty new modules
> > that "replace" stdlib modules. ?It'd be nice to have pointers in the
> > docs, although that runs the risk of having the pointers grow stale,
> > too.
> >
> 
> Exactly. It's not the job of the core developers to keep track of the
> latest and greatest gadgets and to diligently update the docs when
> something new comes out. Note that "the latest and coolest" changes
> frequently, so this may mean different "recommendations" between 3.x.y
> and 3.x.y+1, which is even more confusing.
> 
> Wasn't a PyPI recommendation / voting system discussed a while ago?
> *That* would be much more appropriate than officially endorsing
> specific modules by pointing to them in the standard documentation.

I feel like there's a middle ground where stable, long-term go-to modules could
be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect
almost everyone spends a certain amount of time in the Python docs (which is a
testimony to their quality IMO).  So I'm in favor of conservative link-outs
but without any deprecating language.

--titus
-- 
C. Titus Brown, [email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Brian Curtin 
On Mon, Mar 12, 2012 at 19:23, Andrey Petrov  wrote:
> What such a snippet might look like:
>
> "Batteries are included with Python but sometimes they are old and
> leaky—this is one of those cases. Please have a look in PyPI for more modern
> alternatives provided by the Python community."

What does "leaky" mean here? Someone's going to see that, think it has
memory leaks, then rant on the internet about how we ship crap and
just document it as so.


> Part 2:
> I propose we add a new category of package identifiers such as "Topic ::
> Standard Library Alternative :: {stdlib_package_name}" which authors of
> libraries can tag themselves under. The documentation warning snippet will
> provide a link to the appropriate PyPI query to list packages claiming to be
> alternatives to the stdlib package in question.

Automating it to something on PyPI is the not the right answer. People
will use it incorrectly, either in that they'll add it to packages for
which it isn't accurate, and people just flat out won't use it or know
about it. It won't be accurate this way, and anything that we're
documenting needs to be vetted.

It's not often that a great alternative comes up, so I don't see the
manual burden being too great.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Glenn Linderman 

On 3/12/2012 8:48 PM, C. Titus Brown wrote:

I feel like there's a middle ground where stable, long-term go-to modules could
be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect
almost everyone spends a certain amount of time in the Python docs (which is a
testimony to their quality IMO).  So I'm in favor of conservative link-outs
but without any deprecating language.


Any outward links will be somewhat intrusive, and their existence will 
admit that the stdlib module is limited in some fashion, such that 
someone invested time and effort to create an alternative.


On the other hand, if there were a standard place for external links to 
alternatives, say, perhaps, at the bottom of the left-hand table of 
contents for the module, and if it were Wiki-like (anyone could add an 
alternative) then the core developers wouldn't need to monitor and 
approve the alternatives. The alternatives would not be listed in the 
TOC, only the link, if alternatives were submitted.  At the link target 
Wiki, there could be various alternatives, pro/con comments, user votes, 
whatever seems useful.


If there is truly a desire by core developers to recommend specific 
alternative modules, then wording like the following seems neutral to me:


Alternatives to this module exist at [list of links], which may be 
updated more regularly than the stdlib.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Andrey Petrov 
On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin  wrote:
> On Mon, Mar 12, 2012 at 19:23, Andrey Petrov  wrote:
>> What such a snippet might look like:
>>
>> "Batteries are included with Python but sometimes they are old and
>> leaky—this is one of those cases. Please have a look in PyPI for more modern
>> alternatives provided by the Python community."
>
> What does "leaky" mean here? Someone's going to see that, think it has
> memory leaks, then rant on the internet about how we ship crap and
> just document it as so.

I agree Brian and David, the choice of "leaky" in the wording is poor.
It was supposed to be maintaining the "batteries" metaphor but it's
clearly ambiguous.

Perhaps something along the lines of...

"Batteries are included with Python but for stability and backwards
compatibility, some of the standard library is not always as modern as
alternatives provided by the Python community—this is one of those
cases. Please have a look at PyPI for more cutting-edge alternatives."

>> Part 2:
>> I propose we add a new category of package identifiers such as "Topic ::
>> Standard Library Alternative :: {stdlib_package_name}" which authors of
>> libraries can tag themselves under. The documentation warning snippet will
>> provide a link to the appropriate PyPI query to list packages claiming to be
>> alternatives to the stdlib package in question.
>
> Automating it to something on PyPI is the not the right answer. People
> will use it incorrectly, either in that they'll add it to packages for
> which it isn't accurate, and people just flat out won't use it or know
> about it. It won't be accurate this way, and anything that we're
> documenting needs to be vetted.
>
> It's not often that a great alternative comes up, so I don't see the
> manual burden being too great.

There are a dozen or more urllib/httplib/pycurl competitors on PyPI,
and new ones spring up all the time. I'm not sure how we would go
about objectively blessing the best "official" option at any given
moment, or how frequently we would have to do this.

With self-identifying, we could sort by some sort metric (monthly
downloads? magical score?) and create a somewhat-actionable list.

- Andrey
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Terry Reedy 

On 3/12/2012 10:23 PM, Andrey Petrov wrote:

I've had the pleasure of speaking with Guido at PyCon and it became
evident that some of Python's included batteries are significantly
lagging behind the rapidly-evolving defacto standards of the
community—specifically in cases like urllib and urllib2, which lack
important features provided by alternatives like httplib2, requests, and
my own urllib3.


Part 1:
I propose we add a snippet to the top of the documentation of specific
archaic standard modules which encourages users to investigate
third-party alternatives if they find the standard module frustrating or
otherwise lacking. These notes would target new users, including those
coming from other languages where the third-party library choices are
not nearly as amazing as they are in Python.


I would rather we figure out how to encourage authors of advancing 
packages to contribute better implementations of existing features and 
well-tested new features back to the stdlib module.


For instance, are you the same 'Andrey Petrov' who is'darkprokoba' on 
the tracker? As near as I can tell, that user has posted on one issue 
about free threading and nothing else, in particular, nothing about

web protocols. If that is you, why not?

> What such a snippet might look like:
> "Batteries are included with Python but sometimes they are old and
> leaky—this is one of those cases. Please have a look in PyPI for more
> modern alternatives provided by the Python community."

You have every right to work independently. develop alternative modules, 
and promote them. But suggesting that we denigrate our work to promote 
yours strikes me as inappropriate. If nothing else, it would discourage 
rather than encourage more contributions from more people.


> Additionally, I would like for us as a community to identify which
> other standard libraries (cgi? ssl? others?) are candidates for this
> kind of messaging in the official Python documentation.

To the degree feasible, stdlib modules should be the best possible in 
the area they cover. Then all who install Python would benefit. Do you 
disagree? I would like more of the community to help make that happen.


Any messages in the stdlib doc should be about modules that do things 
intentionally not covered in the stdlib.


--
Terry Jan Reedy


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

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Brian Curtin 
On Mon, Mar 12, 2012 at 21:14, Andrey Petrov  wrote:
> On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin  wrote:
>> On Mon, Mar 12, 2012 at 19:23, Andrey Petrov  wrote:
>>> What such a snippet might look like:
>>>
>>> "Batteries are included with Python but sometimes they are old and
>>> leaky—this is one of those cases. Please have a look in PyPI for more modern
>>> alternatives provided by the Python community."
>>
>> What does "leaky" mean here? Someone's going to see that, think it has
>> memory leaks, then rant on the internet about how we ship crap and
>> just document it as so.
>
> I agree Brian and David, the choice of "leaky" in the wording is poor.
> It was supposed to be maintaining the "batteries" metaphor but it's
> clearly ambiguous.
>
> Perhaps something along the lines of...
>
> "Batteries are included with Python but for stability and backwards
> compatibility, some of the standard library is not always as modern as
> alternatives provided by the Python community—this is one of those
> cases. Please have a look at PyPI for more cutting-edge alternatives."

Sorry for another color choice on the bikeshed, but I would drop the
word or references to "batteries". *We* know what "batteries included"
means, but there are undoubtedly people who won't get it. It's just
code - let's call it code.

>>> Part 2:
>>> I propose we add a new category of package identifiers such as "Topic ::
>>> Standard Library Alternative :: {stdlib_package_name}" which authors of
>>> libraries can tag themselves under. The documentation warning snippet will
>>> provide a link to the appropriate PyPI query to list packages claiming to be
>>> alternatives to the stdlib package in question.
>>
>> Automating it to something on PyPI is the not the right answer. People
>> will use it incorrectly, either in that they'll add it to packages for
>> which it isn't accurate, and people just flat out won't use it or know
>> about it. It won't be accurate this way, and anything that we're
>> documenting needs to be vetted.
>>
>> It's not often that a great alternative comes up, so I don't see the
>> manual burden being too great.
>
> There are a dozen or more urllib/httplib/pycurl competitors on PyPI,
> and new ones spring up all the time. I'm not sure how we would go
> about objectively blessing the best "official" option at any given
> moment, or how frequently we would have to do this.

The same way we choose to accept libraries into the standard library.
New ones spring up all the time - mature, proven, and widely used ones
do not. If someone thinks libfoo is ready, they suggest it. If we
haven't heard of it, the conversation ends. If we have people who know
it, maybe we have them look deeper and figure out if it's something we
can put our stamp on just like we might with the recent talk of
"experimental package" inclusion.

> With self-identifying, we could sort by some sort metric (monthly
> downloads? magical score?) and create a somewhat-actionable list.

Downloads don't mean the code is good. Voting is gamed. I really don't
think there's a good automated solution to tell us what the
high-quality replacement projects are.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Guido van Rossum 
On Mon, Mar 12, 2012 at 9:22 PM, Terry Reedy  wrote:
> I would rather we figure out how to encourage authors of advancing packages
> to contribute better implementations of existing features and well-tested
> new features back to the stdlib module.

I would not. There are many excellent packages out there that should
not be made into stdlib packages simply because their authors are not
done adding new features. If you contribute something to the stdlib
and also maintain a non-stdlib version of the same code to which you
regularly add features, your code is not ready for inclusion into the
stdlib. Not only should you be willing to wait 18 months (until the
next feature release) before your features are released, but you
should also accept that only the latest version of Python will see
those features.

This obviously makes it very unattractive for many authors to ever
contribute to the stdlib. That's fine. There's a healthy ecosystem of
3rd party modules. For some areas (web stuff especially) there's just
no way that the stdlib can keep up. Yes, the stdlib offerings work.
But no, they are not very convenient and may not support popular
idioms very well. For these types of modules I think it is a good idea
to place some sort of pointer in the stdlib docs to an external page
(maybe a wiki page) that collects a currently popular set of
alternatives, or perhaps a few pointers and wiki pages. We should
still be conservative with this, and we should word it to avoid
implying that the stdlib code is buggy -- it just isn't as spiffy or
featureful as the 3rd party options.

(Agreed that the "leaky" wording was unfortunate. I may have
inadvertently suggested this, taking the analogy with "batteries
included". But I didn't mean it to be literally included into the
stdlib.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Guido van Rossum 
On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin  wrote:
> Downloads don't mean the code is good. Voting is gamed. I really don't
> think there's a good automated solution to tell us what the
> high-quality replacement projects are.

Sure, these are imperfect metrics. But not having any metrics at all
is flawed too. Despite the huge flamewar we had 1-2 years ago about
PyPI comments, I think we should follow the lead of the many app
stores that pop up on the web -- users will recognize the pattern and
will tune their skepticism sensors as needed.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Eli Bendersky 
On Tue, Mar 13, 2012 at 06:43, Guido van Rossum  wrote:
> On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin  wrote:
>> Downloads don't mean the code is good. Voting is gamed. I really don't
>> think there's a good automated solution to tell us what the
>> high-quality replacement projects are.
>
> Sure, these are imperfect metrics. But not having any metrics at all
> is flawed too. Despite the huge flamewar we had 1-2 years ago about
> PyPI comments, I think we should follow the lead of the many app
> stores that pop up on the web -- users will recognize the pattern and
> will tune their skepticism sensors as needed.
>

An additional bonus of such a system is that we won't have to maintain
a separate Wiki page with "popular" choices. Pointing to the PyPI
"rating" page, which can presumably be filtered by tags (i.e. web,
scientific, XML, etc.) should be sufficient, given that such a rating
page exists.

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Matt Joiner 
Definitely think some library vetting needs to occur. Superior alternatives
do exist and are difficult to find and choose from. Stuff like LXML,
Requests, Tornado are clear winners.

The more of this done externally (ie PyPI the better). I still think a set
of requirements for "official approval" would be good. This could outline
things like requiring that certain stable Python versions are supported,
interface stability, demonstrated user base, documentation etc.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Senthil Kumaran 
On Mon, Mar 12, 2012 at 07:23:11PM -0700, Andrey Petrov wrote:
> I've had the pleasure of speaking with Guido at PyCon and it became evident
> that some of Python's included batteries are significantly lagging behind the
> rapidly-evolving defacto standards of the community specifically in cases like
> urllib and urllib2, which lack important features provided by alternatives 
> like
> httplib2, requests, and my own urllib3.

Well, I think I have address this because I am the maintainer of those
modules in standard lib.

First things first, it looks to me that trashing something gives good
motivation to you (and others working on related modules). I don't
have a problem with that.

But on the other hand, if you think things can be improved in stdlib,
you are welcome to contribute. Just remember that new features,
refactoring with backwards compatibility, 'cool api' for new features
should go in 3.3+ onwards. Bug fixes, confusions on what's RFC
supported vs what's defacto standards, fine line between bugs and
features, those can be considered for 2.7.

I am personally in favor of constantly improving the standard library
modules along with mention of any good libraries which can be useful
for the purposes of the user.

We already have lots of such references in standard library
documentation. If there is a well maintained package, as long as the
external package is active and maintained, we can have it as link in
the docs. Sometimes those external packages become inactive too, in
those cases, those should pruned. Its' all about maintaining libraries
and docs and being helpful.

-- 
Senthil

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

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Andrey Petrov 
Dear authors of Python's standard library: Please accept my deepest
apologies. We didn't mean for the messaging to come off as
unappreciative for you work, and I am very sorry for that!

Without the aforementioned urllib/httplib/etc I would have never made
it as far as to build my own libraries which have suited my needs
better than the foundations that originally allowed me to get off the
ground. I am very grateful for all of those responsible for building
the Python standard library and I appreciate your continued efforts.

Some specific replies:

@Senthil: I originally asked Guido for guidance on improving the
standard library and perhaps including some of my favourite projects,
but he pointed out that in a couple of years we might end up again in
the same position as before but with one extra library people will
complain about for being obsoleted yet remains impossible to
deprecate.

I agreed with Guido that embracing and even encouraging users to use the
rapidly-evolving community-built packages alongside the tried-and-true
standard library is the best move here.

@Terry: I don't know who 'darkprokoba' is. Unfortunately 'Andrey
Petrov' is a very common name. I go under the handle 'shazow' but I
haven't participated in core Python discussions until today.

I did not suggest for Python to endorse a specific module, even if it
is my own. In fact, I generally oppose doing this as I feel that when
Django was announced as the blessed 'winner' of the Python MVC
frameworks was a harmful event to all other competing frameworks at
the time.

My suggestion is to inform the users when there are other potentially
better suited alternatives available from the community PyPI and to
educate them how to find these alternatives.

- Andrey
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

2012-03-12 Thread Senthil Kumaran 
On Mon, Mar 12, 2012 at 10:48:04PM -0700, Andrey Petrov wrote:
> @Senthil: I originally asked Guido for guidance on improving the
> standard library and perhaps including some of my favourite projects,
> but he pointed out that in a couple of years we might end up again in
> the same position as before but with one extra library people will
> complain about for being obsoleted yet remains impossible to
> deprecate.
> 
> I agreed with Guido that embracing and even encouraging users to use the
> rapidly-evolving community-built packages alongside the tried-and-true
> standard library is the best move here.

I agree with that too. 

I think, any improvements which can made by external libraries, if
they can be considered as can be good improvement in the stdlib, It's
a good idea to push them in.

I looked at the requests, I think that apis for various HTTP verbs is
something interesting, I think web applications authors see some
advantage there explicit GET / POST and sending specific options to
those. That facility, if it can be brought into urllib.request (3.3
onwards) it could be nice. Also you could have noticed an addition of
method= parameter in 3.3

I have not had a chance to look at urllib3. Should do. I have been
following httplib2 and use it. 

Thanks,
Senthil


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