[Python-Dev] Core projects for Summer of Code
> Summer of Code is ramping up. Every year the common complaint is that not
> enough Python core projects get proposed by students, and of course a big
> reason for that is often the only encouragement we offer prospective
> students is a link to the PEP index.
>
> The challenge is finding project ideas for them that could reasonably occupy
> them for the entire Summer and which the results of their work can be
> demonstrated. They're being paid for specific projects so "Spend the Summer
> fixing bugs on the tracker" is a no-go, and Google has outlined that Summer
> of Code is about code, not documentation.
Improve doctest by allowing it to be aware of nested test scopes such
that a variable defined at "class-level scope" (i.e. the variable b
defined at the class-level doctest """>>> b=Bag("abacab")""") can be
used in "method-level scopes" without re-defining it every time for
each method's doctest (each method would reset the given variable (if
used) to its original state rather than live mutated between
equal-level scopes).
Would be a great improvement for doctest in my opinion--both in
ease-of-use, and reduction of redundant, error-prone ("did you define
your test variable the same in each method?") code)--as well as other
benefits.
Appreciate any consideration...
marcos
___
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] Mercurial migration: progress report (PEP 385)
>> Is it really that confusing? I have never heard of anyone asking "what >> is py3k?" > > Do you read python-list? It has been asked. Also, some people seem to > think that py3k is different from python 3. Personally, I vote for keeping the "3k" for 3000 (or is it 3072?). I believe that py3k represents a ideal that hasn't been reached, despite being hoped for in python3. By keeping it, it confers the idea continual evolution *within* the language until that hypothetical ideal is reached. Clearly, there are times when a language reaches only a local maximum, and must depart from itself to arrive at a more global optimum (an annealing problem in the minimization of frustration energy). If py3k wasn't kept, another term would eventually need to be invented. marcos ___ 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] Retrieve an arbitrary element from a set without removing it
[Guido wrote:] > - If sets were to grow an API to non-destructively access the object > stored in the set for a particular key, then dicts should have such a > method too. > - I still wish we could go back in time and unify sets and dicts, if > only to find out how that experiment would turn out. +5. If Python3 were to have this feature it would make it worth migrating to (and nearly worthy of the intent that was behind the idea of python3k). FWIW ... :) marcos ___ 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] Retrieve an arbitrary element from a set without removing it
[I wrote:] > If Python3 were to have this feature it would make it worth > migrating to Sorry that may have sounded more harsh than I expected. If I had more resources, I'd propose (and volunteer) a python3000 branch where any and all who were disappointed at the *lack* of compatability changes could continue working on the core language. (Moratorium controversy solved and quaranteened--any desireable features for the working branch would be back-propagated via the time machine as BDFL permits.) marcos ___ 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] nonlocals() function?
On Sat, Apr 3, 2010 at 6:31 AM, Nick Coghlan wrote: > Steve Bonner wrote: >> What do we think of adding a built-in nonlocals() function that would >> be similar to globals() and locals()? Like those functions, it would >> return a dictionary of variable names and their values. Since we now >> have the nonlocal statement, it would be consistent to keep the >> three scopes local/nonlocal/global with parallel capabilities. And it >> might sometimes be useful for code inside a nested function to see >> what variables are available at the enclosing level. > > That isn't as easy as it may sound. locals() and globals() are each > single namespaces, while the nonlocals may actually span multiple > namespaces. This is probably is way off, but why not use sets. It seems that these special "functions" (which actually don't do any transformations) should be properties or attributes, and in any case would be better served by returning (holding) sets, then one could do standard set operations on them (including the set difference operations upon the set named "locals"). These old functions predate the introductions of attributes/properties and sets, and like anything that is sure to be a group containing no duplicates, it should really return a set to remove the ambiguity to the programmer (unlike returning a list as is presently). That includes dir() too and probably others. python3k-to-you-toly yours, marcos ___ 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] nonlocals() function?
> globals() and locals() return dicts mapping names to objects. Damn, I totally pulled a *?!* on that one. I should have pulled out my Python reference. I was thinking of dir() and thought that these functions were similar. Apologies for that. However, I still do believe that as a general practice (not necessarily a Python one), return types should be the most specific type which will hold the data. > I'm not sure why you think that the globals() and locals() > You say > they should be properties and attributes, but properties of what? They would be properties of the implicit "main" [function] object. Sorry again for not checking before opening my "mouth". marcos ___ 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] [RELEASED] 2.7 beta 1
> On behalf of the Python development team, I'm merry to announce the first beta > release of Python 2.7. > > Python 2.7 is scheduled (by Guido and Python-dev) to be the last major version > in the 2.x series. Though more major releases have not been absolutely ruled > out, it's likely that the 2.7 release will an extended period of maintenance > for > the 2.x series. May I propose that the developers consider keeping this release *beta* until after the present Python moratorium? That is, don't let it be marked as *official* until after, say, Python 3.3. There are so many features taken from 3.0 that I fear that it will postpone its adoption interminably (it is, in practice, treated as "beta" software itself). By making it doctrine that it won't be official until the next "major" Python release, it will encourage those who are able, to just make the jump to 3.0, while those who cannot will have the subtle pressure to make the shift, however gradual. Additionally, it will give the community further incentive to make Python3 all that it was intended to be. Personally, the timing of v3 prevented me from fully participating in that effort, and, not ignoring the work of those who did contribute, I think many of us feel that it has not reached its potential. Just a small suggestion... .. . marcos ___ 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 signal processing question
> We'are sorry but we cannot help you. This mailing list is to work on > developing Python (fixing bugs and adding new features to Python itself); if > you're having problems using Python, please find another forum. Probably > python-list (comp.lang.python) news group/mailing list is the best place. > See http://www.python.org/community/ for other lists/news groups/fora. > Thank you for understanding. > > Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix > programmer guide. Wha? How could this not be the right place? He's not asking about USING python, but asking: WHERE in the PYTHON CODE BASE does the signal get checked? A-bit-miffed-at-the-cold-shoulderly yours, Marcos (wink wink) ___ 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-dev signal-to-noise processing question
>> 1. I suggested one improvement to the canned response in my previous >> post: expand 'using' to 'using or understanding'. > > I changed wording to "if you're having problems learning, understanding > or using Python" I think it's critical to disambiguate between questions about "using and programming with the Python language" versus working with the actual code base that makes Python. Your boilerplate is appropriate for the former, but completely confusing for the latter. As to your question of how best to handle inquiries from the blue or "noisy questions", I personally prefer the following (only slightly tongue-in-cheek): ...After a sufficient period of waiting, say a day or two with no response: "busy busy busy, the gnomes must be hard at work. You've no answer. That means that your question(s) either isn't interesting enough in an obvious way, or it's simply off-topic. If you feel you been unfairly ignored, you might try rewording the question, doing some research to show that you've checked the obvious, or try the following venues: comp.lang.python, for blah blah blah python-ideas,for pitching your new lambda form, to etc, etc" In any case, Mr Crute gave a quite perfect answer, not that such detail should be exptected. Cheers, Marcos ___ 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-dev signal-to-noise processing question
> > > ...After a sufficient period of waiting, say a day or two with no > response: > > > > Ok, I'll wait a bit longer. > > I don't think that's a good idea. My bad, I really only meant a "sufficient delay to allow the possibility of an interested party replying". I actually figured about a day. > OTOH I think as quick as possible an answer is a good idea here. It > saves the intended audience the thought about whether to reply or not, The intended audience (the python developers or other interested lurkers) hardly need to give much thought on whether or not to reply. No one on a -dev list is expected to be a tutor. To have any reply whatsoever should be considered a bestowal of time without equal merit, or gratis. Ideally, those who aren't subscribed should get an immediate, automatic reply about resources available and how to engage the community without raising the ire of same. If there's no such automatic resource, but a designated list manager, this should be sent in private so as not to engage or bother the rest of the list with canned responses, otherwise publically so as to avoid duplication of effort. To those who *are* subscribed, they probably don't need to be told. A reference or link to ESR's "How to Ask Questions The Smart Way" (http://catb.org/esr/faqs/smart-questions.html) is a pretty good inclusion also. For those who may have never heard of it, it's pretty much the authority on developer list etiquette. $0.02, Marcos ___ 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] constant/enum type in stdlib
Is immutability a general need that should have general solution? By generalizing the idea to lists/tuples, set/frozenset, dicts, and strings (for example), it seems one could simplify the container classes, eliminate code complexity, and perhaps improve resource utilization. mark ___ 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] Things to Know About Super
It seems that the frustration with super revolves around how Python currently conflates (as well as many users) two very different types of inheritance, both "is-a" and "has-a" (or compositional) inheritance. Unfortunately, Python assists this confusion because the language doesn't provide a distinct enough way to differentiate between them. For the former (i.e. is-a inheritance), users should not have to explicitly make a call to the super class (via super() or otherwise)--this should be automatic for every method held in common so as to guarantee the invariants of the simpler class. For this type of inheritance it makes more sense to be explicit about *bypassing* a call to the parent class--IF necessary (perhaps to take advantage of an optimization available only in the subclass)--rather than explicit about *making* one. This would remove many of the bugs, misuses, and frustrations with super(). No more ambiguity and confusion because the language now guarantees certain behavior. Super() would then be limited to cooperative mixin classes; for all others, explicit naming of the class would be required. But perhaps that there is some language abstraction that has yet to be fully invented that would tie it all together nicely. By the way, regarding your trait implementation, it may be worthwhile revisiting the discussion surrounding the Prothon language discussed a few years ago on comp.lang.python which got rid of classes and metaclasses and replaced them with prototypes. Regards, zipher ___ 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] compiler optimizations: collecting ideas
"Daniel Furrer" <[EMAIL PROTECTED]> wrote: > As part of an advanced compiler design course at our university (ETH > Zurich), we have to implement an optimization (or various thereof). > I've spoken with a couple of people who are, like me, very fascinated by > Python. > So I would just like to ask if somebody has any ideas on what we could do? > > - We've been working on generating Control Flow Graphs, generating Static > Single Assignment Form (inserting phi-nodes) and removing it again. We've > also implemented techniques like constant folding, copy propagation, Common > Subexpression Elimination etc. How about a graphical program-visualization meta-tool that would allow making optimizations (as well as debugging) easier. Take your control flow graph data put it into fractal or recursive/foldable graphical "cloud" and visualize the running program therein. Find interesting audio and visual constructs (color, intensity, etc) to isomorphically map interesting programming data into non-arbitrary visual iconography and design. Each entrance into a code-block is like a photon entering a molecular form, and as more photons enter a given block in a given time frame, heat is generated in that code block, causing it to glow for an amount of time. Code that runs for a long time, glows as it is run. If it returns a value all that warmth in the code block gets turned into a flash of light and the code-block goes dark again. The description is pretty sloppy, but I know there's a killer app there somewhere. I've been wanting such a tool for awhile. (Imagine using such a tool with a powerful abstract language like LISP. It would remove all the obtuse parenthetical list expressions and put it into a graphical visual language where nodes consisting of subgraphs could be moved around as needed. Language syntax would become more-or-less obsolete!) Go even further and imagine the internet in such a cloud, where users can navigate by looking at "heat" activity therein. Each time a user visits and "looks" at a given site eventually condenses into "water" and you have pools of interest Please tell me this is a cool idea or not so I don't wonder why no one else is thinking about such things. And on your way, save the world... Oh, and, if it is a cool idea, is there any company interested in hiring? haha marcos ___ 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
