Mailman 3 March 2012 - Python-ideas

PEP
by Mark Janssen 08 Mar '12

08 Mar '12

On Thu, Feb 9, 2012 at 5:18 PM, Guido van Rossum <guido(a)python.org> wrote: > A dictionary would (then) be a SET of these. (Voila! things have already >> gotten simplified.) >> > > Really? So {a:1, a:2} would be a dict of length 2? > Eventually, I also think this will seque and integrate nicely into Mark >> Shannon's "shared-key dict" proposal (PEP 412). >> >> I just noticed something in Guido's example. Something gives me a strange feeling that using a variable as a key doesn't smell right. Presumably Python just hashes the variable's id, or uses the id itself as the key, but I wonder if anyone's noticed any problems with this, and whether the hash collision problems could be solved by removing this?? Does anyone even use this functionality -- of a *variable* (not a string) as a dict key? mark

4 3

Re: [Python-ideas] PEP
by Ethan Furman 08 Mar '12

08 Mar '12

Mark Janssen wrote: > On Thu, Mar 8, 2012 at 2:36 PM, Ethan Furman <ethan(a)stoneleaf.us > <mailto:ethan@stoneleaf.us>> wrote: > > Um, yes? As in, most of the time. Don't you? > > And Python uses whatever object the name is bound to: > > --> huh = 5 > --> d = {} > --> d[huh] = 'hrm' > --> d > {5: 'hrm'} > > > Hmm, wow, like never. But then didn't I decide that you're in a very > different Python group than I? Not worse, just different.... > > :) Apparently so. :) Yay, Python! ~Ethan~

1 0

"Submit your hash" - stats for stdlib
by anatoly techtonik 08 Mar '12

08 Mar '12

While writing the answer for the stackoverflow question about cross-language standard libraries, I realized that there is not enough statistics about module/function usage in Python. If there could be an utility that just walks through your project and gathers stats about calls from stdlib, then this utility can as well submit those stats to some stats.python.org endpoint for summarizing. The stats about stdlib module usage/function calls can be combined into reversible hashes for easy posting through at URL form at the site. Hashes are also useful to see if some big subtree is actually popular library, such as Django, to avoid duplicating the stats. If every installed package is run through such tool, then it might be even possible to detect the versions of libraries used regardless of metadata location (although MD5 seems a better solution in this case). 1. http://stackoverflow.com/questions/7654826/cross-language-standard-libraries -- anatoly t.

1 0

keyword arguments everywhere (stdlib) - issue8706
by Gregory P. Smith 05 Mar '12

05 Mar '12

Something I'd like to bring up at the language summit next week if we have time (suggestion: limit it to 20 minutes), lets start discussion now: 1) Should _*all_* Python base types support keyword arguments on all of their methods. 2) Should _*all_* stdlib extension modules support keyword arguments on all of their functions and methods? Assumptions: any newly supported keyword arguments would have meaningful names (and the documentation updated to reflect their name). How should "_*all_*" be defined in each of the above. One example against _*all_* is trivial single-argument functions such as chr(). One example for is the str.find method's start parameter being more obvious if named. An example of a rule of thumb that could be proposed: * All optional arguments should also be accepted as keywords. * Any public function or method that require multiple arguments should accept them as keywords. Why propose this? For consistency and to promote readable code. A reasonably often heard complaint from people new to Python that I have heard is how some things work as keyword arguments and some don't. Pure Python code can't (easily without gross hacks) be written to refuse to accept keyword arguments, the standard types and library should not be different. Documentation and docstrings have at times been inconsistent in the past with respect to what they call arguments and would be cleaned up as part of this to match the actual keyword argument accepted (that is worth doing on its own even without changing what the code accepts). A decision with discussion notes on this may be PEP worthy. for reference - this is http://bugs.python.org/issue8706 -gps

22 84

Re: [Python-ideas] doctest
by Ian Bicking 05 Mar '12

05 Mar '12

On Feb 17, 2012 4:12 PM, "Nick Coghlan" <ncoghlan(a)gmail.com> wrote: > > On Sat, Feb 18, 2012 at 7:57 AM, Mark Janssen <dreamingforward(a)gmail.com> wrote: > > Anyway... of course patches welcome, yes... ;^) > > Not really. doctest is for *testing code example in docs*. If you try > to use it for more than that, it's likely to drive you up the wall, so > proposals to make it more than it is usually don't get a great > reception (docs patches to make it's limitations clearer are generally > welcome, though). The stdib solution for test driven development is > unittest (the vast majority of our own regression suite is written > that way - only a small proportion uses doctest). This pessimistic attitude is why doctest is challenging to work with at times, not anything to do with doctest's actual model. The constant criticisms of doctest keep contributors away, and keep its many resolvable problems from being resolved. > An interesting third party alternative that has been created recently > is behave: http://crate.io/packages/behave/ This style of test is why it's so sad that doctest is ignored and unmaintained. It's based on testing patterns developed by people who care to promote what they are doing, but I'm of the strong opinion that they are inferior to doctest. Ian

12 34

Re: [Python-ideas] revisit pep 377: good use case?
by Craig Yoshioka 05 Mar '12

05 Mar '12

On Feb 29, 2012, at 8:01 PM, Nick Coghlan wrote: > On Thu, Mar 1, 2012 at 1:27 PM, Craig Yoshioka <craigyk(a)me.com> wrote: >> But you're not going to win me over by saying that the #1 goal of 'with' is too best match the flow-control semantics of try|except|finally. > > Um, you have that exactly backwards. *You* are the one agitating for > change, therefore the onus is on *you* to demonstrate that the > benefits exceed the costs. > I am aware that I need to motivate against a lot of inertia... 'win me over' was just a statement that that particular line of argument was unlikely to make me concede since I had already thought it through, and still came to a different conclusion. > Read PEP 343 - the with statement is a tool created specifically to > factor out try/except/finally statements where the body of the try > block is the only part that changes. The fact that it has other use > cases as well was an added bonus. > OK, then abstracting the concept of code running in a managed context wasn't the primary goal. That's too bad. > *You* are the one suggesting that it be enhanced to do more, *despite* > there being an existing PEP explicitly rejecting your proposed > enhancements as introducing unnecessary complexity. I am merely > telling you that the arguments you have presented so far are not > persuasive, since they add nothing beyond those that I included when I > wrote PEP 377. > except PEP 377 failed partially because there wasn't a concrete real-world example of where it would be useful. Thus, I thought presenting such an example might be enough to bring it up again. > Unless you have some compelling new information to present that can > clearly be handled *only* by changing the way the with statement > works, you're not going to win this one. Additional complexity is > inherently bad, so, without presentation of clear gains in > expressiveness and readability, the status quo will always win by > default (See http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html > & http://www.boredomandlaziness.org/2011/02/justifying-python-language-change…) > I gathered that that was your real argument, I just wanted it out. So it's just a matter of wether my example is compelling *enough*. I think my example is *compelling*, but can concede just one example still might not be good enough. As to the added 'complexity': There's the code complexity. I suspect that two or three lines of code would do it, but I'm still trying to interpret the Python compiler code, as this is the first time I've looked at it. Then there's the conceptual complexity of the new behavior, but if all current code works the same, and there isn't a noticeable performance penalty, and people are extremely unlikely to run into context managers that use the new functionality anyways, I don't see that 'complexity' being an issue either. I'm going to try and make the modifications and do some testing so I can make a stronger argument on the latter point. I use a lot of third-party packages to test against, and have close to 1M lines of internal python code as well.

3 3

revisit pep 377: good use case?
by Craig Yoshioka 02 Mar '12

02 Mar '12

So I've recently been trying to implement something for which I had hoped the 'with' statement would be perfect, but it turns out, won't work because Python provides no mechanism by which to skip the block of code in a with statement. I want to create some functionality to make it easy too wrap command line programs in a caching architecture. To do this there are some things that need to happen before and after the wrapped CLI program is called, a try,except,finally version might look like this: def cachedcli(*args): try: hashedoutput = hashon(args) if iscached(): return hashedoutput acquirelock() cli(*args,hashedoutput) iscached(True) return hashedoutput except AlreadyLocked: while locked: wait() return example(*args) finally: releaselock() the 'with' version would look like def cachedcli(*args) hashedpath = hashon(args) with cacheon(hashedpath): cli(hashedpath,*args) return hashedpath So obviously the 'with' statement would be a good fit, especially since non-python programmers might be wrapping their CLI programs... unfortunately I can't use 'with' because I can't find a clean way to make the with block code conditional. PEP377 suggested some mechanics that seemed a bit complicated for getting the desired effect, but I think, and correct me if I'm wrong, that the same effect could be achieved by having the __enter__ function raise a StopIteration that would be caught by the context and skip directly to the __exit__ function. The semantics of this even make some sense too me, since the closest I've been able to get to what I had hoped for was using an iterator to execute the appropriate code before and after the loop block: def cachedcli(*args) hashedpath = hashon(args) for _ in cacheon(hashedpath): cli(hashedpath,*args) return hashedpath this still seems non-ideal to me...

11 22

Is that possible to extract the distutils subcommand's argv and calling other commands?
by 罗勇刚(Yonggang Luo) 01 Mar '12

01 Mar '12

For example I am running command like python setup.py test -f install I want to pass -f argv to unittest, how I can do that? And after unittest, we can still running command install. -- 此致礼罗勇刚 Yours sincerely, Yonggang Luo

2 1