Mailman 3 March 2012 - Python-ideas

Save memory when forking with *really* immutable objects
by Larry Hastings March 13, 2012

March 13, 2012

I'll admit in advance that this is in all likelyhood a terrible idea. What I'm curious about is why it wouldn't work, or if it wouldn't even help ;-) One problem for CPython is that it can't share data across processes very often. If you have an application server, and you fork a hundred processes to handle requests, your memory use will be "C * n * p" where C is a constant, n is the number of processes, and p is the average memory consumption of your app. I fear C is very nearly near … [View More]

1 0

Saving state or data from Python objects (Was: Serializable method)
by anatoly techtonik March 10, 2012

March 10, 2012

On Sat, Mar 10, 2012 at 2:59 PM, Masklinn <masklinn(a)masklinn.net> wrote: > but it still ends > up with the format's semantics not necessarily mapping 1:1 to Python > semantics This is the right problem. If we take user approach to see what is the hard time users have - there are two different user stories: 1. Is about saving current state of a program by magically taking all object space (or a portion of) and save it in into a file Goals: Don't make me think Security: Not … [View More]

1 0

Serializable method
by Jakob Bowyer March 10, 2012

March 10, 2012

So originally I presented this idea for serialize methods something like to_json() but the idea was rightly shot down where the language would have to support most formats and this could lead to confusion or complication. So this is a newer version of that idea. I think that object should provide an __serializable__ method which in-turn allows the user to define in it how the object is to be serialized, the default operation should be something along the lines of return self.__dict__ but … [View More]

8 12

Loop labels
by Matt Joiner March 10, 2012

March 10, 2012

Several languages allow break and continue statements to take a count or loop label for greater flexibility. Dealing with nested loops and control flow around them is definitely something I and probably most programmers deal with everyday. Generally for very complex control flow one might employ functions, and use return statements to work around any shortcomings. This is not always ideal in CPython because of the performance cost of function calls, and lack of anonymous functions. The other … [View More]

8 13

import fallback syntax
by Chris Withers March 8, 2012

March 8, 2012

Hi All, I see a lot of Python like this: try: from cDecimal import Decimal except ImportError: from decimal import Decimal ...and nest deeper if you're talking about ElementTree. How about some syntactical sugar to make this less obnoxious: from cDecimal or decimal import Decimal from x.y.z import X as X or a.b.z import Y as X or what do people think? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

8 9

PEP
by Mark Janssen March 8, 2012

March 8, 2012

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 … [View More]

4 3

Re: [Python-ideas] PEP
by Ethan Furman March 8, 2012

March 8, 2012

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 > … [View More]

1 0

"Submit your hash" - stats for stdlib
by anatoly techtonik March 8, 2012

March 8, 2012

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 … [View More]

1 0

keyword arguments everywhere (stdlib) - issue8706
by Gregory P. Smith March 6, 2012

March 6, 2012

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_*" … [View More]

22 84

Re: [Python-ideas] doctest
by Ian Bicking March 5, 2012

March 5, 2012

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 … [View More]

12 34

Re: [Python-ideas] revisit pep 377: good use case?
by Craig Yoshioka March 5, 2012

March 5, 2012

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 … [View More]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. [View Less]

3 3

revisit pep 377: good use case?
by Craig Yoshioka March 2, 2012

March 2, 2012

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 … [View More]

11 22

Is that possible to extract the distutils subcommand's argv and calling other commands?
by 罗勇刚(Yonggang Luo) March 1, 2012

March 1, 2012

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