Re: [Python-Dev] [Tracker-discuss] Dates in python-dev
http://psf.upfronthosting.co.za/roundup/meta/issue274 ___ 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] Tuples and underorderable types
Raymond Hettinger wrote:
> The problem is that a basic python pattern is now broken
> in a way that may not readily surface during testing.
>
> I'm wondering if there is something we can do to mitigate
> the issue in a general way. It bites that the venerable technique
> of tuple sorting has lost some of its mojo. This may be
> an unintended consequence of eliminating default comparisons.
There could be a high performance, non-lame version of the mapping
pattern below available in the stdlib (or at least in the docs):
keymap = {type(lambda: 1) : id}
def decorate_helper(tup):
return tuple(keymap[type(i)](i) if type(i) in keymap else i for i in tup)
tasks = [(10, lambda: 0), (20, lambda: 1), (10, lambda: 2)]
tasks.sort(key=decorate_helper)
This works when comparing different types too, but then some care must
be taken to avoid bad surprises:
keymap[type(1j)] = abs
imaginary_tasks = [(10j, lambda: 0), (20, lambda: 1), (10+1j, lambda: 2)]
imaginary_tasks.sort(key=decorate_helper) # not so bad if intended
mixed_tasks = [(lambda: 0,), (0.0,), (2**32,)]
mixed_tasks.sort(key=decorate_helper) # oops, not the same order as in 2.x
Regards,
Daniel
___
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] Oddity PEP 0 key
MRAB wrote: > Are there Unicode codepoints for smilies? I'm thinking of :-) for > 'Accepted' and :-( for 'Rejected'. :-) Yes there are, but we'd need to set the font size to 'humongous' to see the smilies: ☹ ☺. In py3k: print(chr(0x2639), chr(0x263a)) In trunk: print(unichr(0x2639), unichr(0x263a)) <>___ 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] How to build Python 2.6.2 on HP-UX Itanium with thread support?
Hi Henning, henning.vonbargen wrote: > How to build Python 2.6.2 on HP-UX Itanium with thread support? [snip bit about python-list] I can't give you directions, but if you can describe your issues I might be able to help. I'll respond in python-list, as I think this is OT for python-dev. > Is HP-UX Itanium a supported platform at all? > BTW: A search for "supported platforms" at www.python.org does not help! Now, this looks like python-dev material. PEP 11[0], the information in README[1] and the notes in the downloads pages[2] could be improved and updated. If someone has time to invest in this, a compatibility matrix would be very nice to have. Regards, Daniel [0] http://www.python.org/dev/peps/pep-0011/ [1] http://svn.python.org/view/python/trunk/README?revision=72107&view=markup [2] http://www.python.org/download/source/ and http://www.python.org/download/other/ ___ 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] IronPython specific code in inspect module
Dino Viehland wrote: > What about instead defining __argspec__ for built-in functions/method > objects and allowing all the implementations to implement it? We could > all agree to return: > > [ > (return_type, (arg_types,...)), > (return_type, (arg_types,...)), > ] > > Then inspect can check for that attribute and support introspection on > built-ins. This would be an easy feature for us to implement and it > may also be for Jython as well given that we both get the power of our > platforms reflection capabilities. Any platform that implements it > lights up w/o new platform specific code. And maybe this needs to go > to python-ideas now :) Curiously, inspect limitations on CPython (can't inspect functools.partial, has issues with some descriptors and decorators) got us chatting about PEP 362: Function Signature Object[0] on #python-dev today. PEP 362 was also brought up in a recent thread where the executive summary was 'it just needs someone to guide it through the last steps'[1], and it would make this kind of introspection nice and clean[2]. It makes even more sense now we have PEP 3107: Function Annotations[3] in place. Cheers, Daniel [0] http://www.python.org/dev/peps/pep-0362/ [1] http://mail.python.org/pipermail/python-dev/2009-April/088517.html [2] http://mail.python.org/pipermail/python-dev/2009-April/088597.html [3] http://www.python.org/dev/peps/pep-3107/#parameters ___ 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] Roundup keywords for bug tracking
anatoly techtonik wrote: > > It is impossible to edit roundup keywords and this takes away the > flexibility in selecting bugs related to a module/function/test or > some other aspect of development. For example, I need to gather all > subprocess bugs in one query and things that won't be fixed in > deprecated os.popen() into another. In Trac I would use "subprocess" > and "os.popen" keywords. On ohloh I would add similar tags (if bugs > were software) without, but I can't do anything about Python roundup. > Is there any reason for such restriction? Well, keywords are used as a very restricted set of tags, so only users in the Developer group can create them. We've discussed free form issue tags that any user can create or edit in #python-dev and tracker-discuss[0]. I'm pretty sure they'd cover your use-case. I've submitted a patch to Rietveld[1], but it seems I never filled it in the meta-tracker, oopsie. If you (or anyone else) want to test-drive the tags feature, I can create an account in the experimental tracker[2] (which needs some attention anyway). I should be able to submit the patch to the meta-tracker during the weekend. Also, if you would like to bookmark arbitrary sets of issues, the bookmarklet and form in http://static.bot.bio.br/tool.html may be of help. You can paste the ids into the search page's ID field and create a query for a given (static) set of issues. Regards, Daniel [0] http://mail.python.org/pipermail/tracker-discuss/2009-April/002099.html [1] http://codereview.appspot.com/40100/show [2] http://bot.bio.br/python-dev-exp/issue5 ___ 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] run time error anlysis of python source code
Hi David, wrote: > > It appears that one possibility of investigation into the development of a > safety-critical variant of the python language There is some interesting work related to a safety-critical variant of Python. > would be to conduct run time > error analysis of the source code that is responsible for producing the > python language. There's been some effort into this too, and the Coverity and Klocwork based fixes could also be of interest to you. > Therefore, I will now conduct these run time error > analysis of the python source code as if the python environment itself was > to be utilized as a FADEC controller within an aircraft engine. Nice, what tools do you have available for this? Any papers that would be a good start on the topic? > I > have already conducted some analysis already and it appears to be some > concern with memory management within Python. I will redouble my efforts > and determine if I am correct and as a promise. I will give my findings to > everyone to enjoy if they so want it. I will also give the correct source > if anyone would want it for their own purposes. The source code that I will > be evaluating is the one responsible for the newer variants of Python 3.0. You want the py3k branch. BTW, take a look at Brett Cannon's work on Python security, as well as tav's. > I believe that I will name this new variant of the python language as > > Apocalypse Python !! Oh. Apocalypse Python !!, you say? Maybe something that conveys a security message or anything that doesn't relate to the end of the world could work better. > I will also develop a web-page for the development and evolution of > Apocalypse Python. Ah. Hm. David? Don't. I mean, read the mailing lists, take a look at open bug reports, read the community blogs. You'll get to know how things flow, you'll figure a nice way to relate your ideas to what people are discussing and past experiences. Make small contributions that bring us closer to... Apocalypse Python !!, then you'll have an easier time to push the idea of going the whole way towards it. Or just do it, dunno, if it makes you feel better go for it, we all have our own issues. That's why we have an issue tracker, it's s nice, wanna see it??? > If anyone has any questions, please let me know !!! OK, I promise. Daniel ___ 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: help needed
Hi Martin, "Martin v. Löwis" wrote: > In this thread, I'd like to collect things that ought to be done > but where Dirkjan has indicated that he would prefer if somebody else > did it. > > So far, I have only one item: build identification. If you want to work > on this, please either provide a patch (for trunk and/or py3k), or > (if you are a committer) create a subversion branch. I do want to help, but I believe I'll only have time a week from now. If we need/want Roundup tweaks to go with Mercurial, I can work on that (keep in mind we have a cool GSoC student working on Mercurial-Roundup integration, and I'm willing to work on our needs with him). For build identification, I'd only be able to do the C/Python side of things and (with luck) autoconf. Cheers, Daniel ___ 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
