[Python-Dev] Seeking students for the Summer of Code
There is less than a week left before students must submit a final application. There are a bunch of ideas up on the wiki: http://wiki.python.org/moin/SummerOfCode/ The wiki has instructions for how to submit a proposal. There are many different areas including: core language features, libraries, and applications. This is a great opportunity to get real coding experience. Not to mention the chance to work with a nice and fun group of people. The earlier you submit an application, the more feedback you can get to improve it and increase your liklihood of getting accepted. Feel free to contact me if you have any questions. Cheers, n ___ 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] binary trees. Review obmalloc.c
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote: > Comparison of functions of sorting and binary trees not absolutely > correctly. I think that function sort will lose considerably on > greater lists. Especially after an insert or removal of all one element. Generally speaking, people who understand at least some of Python's internals (list internals specifically), will not be *removing* entries from lists one at a time (at least not using list.pop(0) ), because that is slow. If they need to remove items one at a time from the smallest to the largest, they will usually use list.reverse(), then repeatedly list.pop(), as this is quite fast (in general). However, as I just said, people usually don't remove items from just-sorted lists, they tend to iterate over them via 'for i in list:' . - Josiah As an aside, I have personally implemented trees a few times for different reasons. One of the issues I have with most tree implementations is that it is generally difficult to do things like "give me the kth smallest/largest item". Of course the standard solution is what is generally called a "partial order" or "order statistic" tree, but then you end up with yet another field in your structure. One nice thing about Red-Black trees combined with order-statistic trees, is that you can usually use the uppermost bit of the order statistics for red/black information. Of course, this is really only interesting from an "implement this in C" perspective; because if one were implementing it in Python, one may as well be really lazy and not bother implementing guaranteed balanced trees and be satisfied with randomized-balancing via Treaps. Of course all of this discussion about trees in Python is fine, though there is one major problem. With minimal work, one can construct 3 values such that ((a < b < c) and (c < a)) is true. ___ 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] signature object issues (to discuss while I am out of contact)
Brett Cannon wrote: > On 5/2/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> All of the use cases I can think of (introspection for documentation >> purposes >> or argument checking purposes) don't really suffer either way >> regardless of >> whether the signature retrieval is spelt "obj.__signature__" or >> "inspect.getsignature(obj)". >> > > It does for decorators. How do you make sure that a decorator uses > the signature object of the wrapped function instead of the decorator? > Or are you saying to just not worry about that right now? Ah, good point. In that case, I'd be in favour of including the attribute in the PEP, and having inspect.getsignature() check for that attribute before manually building a signature object from the function and its code object. The other nice thing about the attribute is that it allows otherwise uninspectable functions (like C functions) to choose to declare their API for introspection purposes. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Date for DC-area Python sprint?
I found out that May 27th is on Memorial Day weekend, and some people will doubtless have travel plans. Let's aim for the next Saturday, June 3rd. (No intersection with the Need for Speed sprint; oh well.) I'll post a detailed announcement and set up a wiki page when things are nailed down, but it looks like the sprint can be from 9 or 10AM to 4PM, or thereabouts. Wireless will be available. Does anyone else want to organize sprints for that day? --amk ___ 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] Python for Windows CE
Hi, I would like to explore the possibility of submitting patches to allow Python to work on Windows CE out of the box. I have a few questions in preparation: 1. Is there any reason in principle why patches for Windows CE support would be rejected? 2. Should I submit unified diffs or context diffs? One page says: "Context diffs are preferred, so generate the patch using diff -c." http://www.python.org/dev/tools/ Another says: "We like unified diffs. We grudgingly accept contextual diffs..." http://www.python.org/dev/patches/ 3. The page http://www.python.org/dev/patches/style/ says that platform-specific code should use preprocessor symbols documented for the compiler, but existing Python code uses e.g. the invented MS_WIN32 symbol instead of the standard _WIN32. Should we create a symbol MS_WINCE for consistency or use the more common _WIN32_WCE? 4. The latest existing patch set uses os.name = "ce", and this can be used to distinguish Windows CE from other operating systems in Python code. The existing patches also set sys.platform = "Pocket PC", but I am not so keen on keeping this, mainly because Windows CE is equivalent to Win32 in many cases. Any comments? 5. Windows CE lacks some header files that are present on other platforms, e.g. . If we ignore the actual declarations in the header for a moment, there are a few ways to solve this problem: (a) The obvious solution is to wrap each #include inside #ifndef MS_WINCE...#endif (b) Instead we could use #ifdef HAVE_DIRECT_H, requiring patches to #define HAVE_DIRECT_H for other platforms (c) The existing patch set uses a simpler solution by creating a (possibly empty) direct.h in a Windows CE-specific subdirectory of the Python source tree, and adding that directory to the compiler include path. This means that the source files probably won't need to be patched and it may help when building C extension modules. Is there any objection to the method (c) of providing missing headers? What is the preferred solution? In later emails I will of course go into more detail about the patches required. Any general tips on how to submit good patches are welcome. Thanks, Luke Dunstan ___ 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] Shared libs on Linux (Was: test failures in test_ctypes (HEAD))
[Crossposting to both python-dev and ctypes-users, please respond to the list that seems most appropriate] Guido van Rossum wrote: > I see test failures in current HEAD on my Google Red Hat Linux desktop > that the buildbots don't seem to have: > > ./python -E -tt ../Lib/test/regrtest.py test_ctypes > test_ctypes > test test_ctypes failed -- errors occurred; run in verbose mode for details > > More details from running this manually: > $ ./python ../Lib/test/test_ctypes.py > . > . (lots of passing tests; then:) > . > test_gl (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR > test_glu (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR > test_glut (ctypes.test.test_find.Test_OpenGL_libs) ... ERROR > > == > ERROR: test_gl (ctypes.test.test_find.Test_OpenGL_libs) > -- > Traceback (most recent call last): > File "/home/guido/projects/python/trunk/Lib/ctypes/test/test_find.py", > line 42, in setUp > self.glut = CDLL(lib_glut) > File "/home/guido/projects/python/trunk/Lib/ctypes/__init__.py", > line 288, in __init__ > self._handle = _dlopen(self._name, mode) > OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersion I have now changed the test to ignore the case when the libglut.so library cannot be loaded because of missing symbols. I could not reproduce the failure on any of the systems I have access to. I've installed fedora 5, but the test succeeds on this system (I assume redhat desktop is different from fedora, though). Unfortunately I don't know enough about shared libs on linux to make the test more correct. I would appreciate explanations or pointers to explanations how shard library loading on linux works in detail. The most important questions now is: - When I load shared libs, sometimes it is required to use the RTLD_GLOBAL flag (RTLD_LOCAL is the default), although in most casesthis is not needed. I think I do understand what RTLD_GLOBAL does, I just do not know how to determine if it is required or not. The runtime loader seems to have access to this information - is there a way for me to find out? Thanks, Thomas ___ 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] Python for Windows CE
Luke Dunstan wrote: > 1. Is there any reason in principle why patches for Windows CE support would > be rejected? No, not in principle. Of course, - the patch shouldn't break anything - you should state an explicit commitment to support the port for some years (or else it might get removed at the slightest problem) > 2. Should I submit unified diffs or context diffs? Yes, please :-) Actually, unified diffs are common these days, in particular as subversion generates them. > 3. The page http://www.python.org/dev/patches/style/ says that > platform-specific code should use preprocessor symbols documented for the > compiler, but existing Python code uses e.g. the invented MS_WIN32 symbol > instead of the standard _WIN32. Should we create a symbol MS_WINCE for > consistency or use the more common _WIN32_WCE? Depends on who defines it. If the compiler defines it on its own, it is best to use that. If some header file that gets unconditionally included defines it, that is just as well. If you explicitly define something, try to follow the conventions you like best. > 4. The latest existing patch set uses os.name = "ce", and this can be used > to distinguish Windows CE from other operating systems in Python code. The > existing patches also set sys.platform = "Pocket PC", but I am not so keen > on keeping this, mainly because Windows CE is equivalent to Win32 in many > cases. Any comments? I would guide the decision based on the number of API changes you need to make to the standard library (e.g. distutils). In any case, the platform module should be able to reliably report the specific system (including the specific processor architecture). > (b) Instead we could use #ifdef HAVE_DIRECT_H, requiring patches to #define > HAVE_DIRECT_H for other platforms That would be best. Python generally uses autoconf methodology, which implies that conditionally-existing headers should be detected using HAVE_*_H. Regards, Martin ___ 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 3102: Keyword-only arguments
> > >make_person(=name, =age, =phone, =location) > > > > And even with Terry's use case quoted I can't make out what you meant > > that to do. > > I meant it to do the same thing as > >make_person(name=name, age=age, phone=phone, location=location) > > I come across use cases for this fairly frequently, usually > when I have an __init__ method that supplies default values > for a bunch of arguments, and then wants to pass them on to Me too! I would have thought that the one obvious way to get rid of the wanky feeling would have been to write: def make_person(name, age, phone, location): ... make_person(name, age, phone, location) IMHO, keyword arguments are often overused like that. Many times they don't improve readability any more than naming your variables sensibly do. No, I have not studied how my API:s are used (and how they evolve) over a longer period of time. -- mvh Björn ___ 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] mail to talin is bouncing
Guido van Rossum python.org> writes: > Sorry to bother the list -- talin, mail to you is bouncing: Someone sent me mail? Cool! :) Sorry about that, I'm in the process of migrating hosting providers, and I forgot to add an email account for myself :) It should be better now, I'll do some more tests tonight. (This is all part of my mad scheme to get my TurboGears/AJAX-based online collaborative Thesaurus project available to the outside world.) -- Talin ___ 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] lambda in Python
Today i ran into one of Guido van Rossum's blog article titled “Language Design Is Not Just Solving Puzzles” at http://www.artima.com/weblogs/viewpost.jsp?thread=147358 The article reads very kooky. The bottom line is that Guido simply does not like the solution proposed for fixing the lambda construct in Python, and for whatever reasons thinks that no solution would satisfy him about this. But instead, he went thru sophistry on the ignorance and psychology of coder mass in the industry, with mentions of the mysterious Zen, the cool Google, the Right Brain, Rube Goldberg contraption irrelevancies. From his article, i noticed that there's largish thread of discussions on lambda. The following is a essay i wrote after reading another one of Guido blog, in which shows prejudice and ignorance about functional programing. I hope it can reduce the ignorance about lambda and functional programing. -- Lambda in Python 3000 Xah Lee, 20050930 On Guido van Rossum's website: http://www.artima.com/weblogs/viewpost.jsp?thread=98196 (local copy) dated 20050310, he muses with the idea that he would like to remove lambda, reduce(), filter() and map() constructs in a future version Python 3000. Guido wrote: «filter(P, S) is almost always written clearer as [x for x in S if P(x)], and this has the huge advantage that the most common usages involve predicates that are comparisons, e.g. x==42, and defining a lambda for that just requires much more effort for the reader (plus the lambda is slower than the list comprehension)» The form “[x for x in S if P(x)]” is certainly not more clear than “filter(P, S)”. The latter is clearly a function, what is the former? A function every programer in any language can understand and appreciate its form and function. Why would anyone to expect everyone to appreciate a Python syntactical idiosyncrasy “[x for ...]”? Also, the argument that the form “filter(F,S)” being cumbersome because the first argument is a function and that mostly likely it would be a function that returns true/false thus most people will probably use the inline “lambda” construct and that is quite cumbersome than if the whole thing is written with the syntactical idiosyncrasy “[x for ...]”, is rather inane, as you can now see. The filter(decision_function,list) form is clean, concise, and helps thinking. Why it helps thinking? Because it condenses the whole operation into its mathematical essence with the most clarity. That is, it filters, of a list, and by a yes/no decision function. Nothing is more, and nothing can be less. It is unfortunate that we have the jargon Lambda and Predicate developed by the tech geekers of the functional programing community. The lambda could be renamed Pure Function and the Predicate could be called True/False function, but the world of things being the way they are already, it is unwise to rewrite every existing Perl program just because somebody invented another language. If the predicate P in filter(P,S) is cumbersome, so would exactly the same thing appear in the syntactical idiosyncrasy: “[x for x in S if P(x)]”. Guido added this sting as a afterthought: «(plus the lambda is slower than the list comprehension)» Which is faster is really the whim and capacity of Python compiler implementators. And, weren't we using clarity as the judgement a moment ago? The concept of a function every programer understands, but what the heck is a List Comprehension? Why don't you scrap list comprehension in Python 3000 and create a table() function that's simpler in syntax and more powerful in semantics? ( See http:// xahlee.org/perl-python/list_comprehension.html ) «Why drop lambda? Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; also, there is a widespread misunderstanding that lambda can do things that a nested function can't -- I still recall Laura Creighton's Aha!-erlebnis after I showed her there was no difference! Even with a better name, I think having the two choices side-by-side just requires programmers to think about making a choice that's irrelevant for their program; not having the choice streamlines the thought process. Also, once map(), filter() and reduce() are gone, there aren't a whole lot of places where you really need to write very short local functions; Tkinter callbacks come to mind, but I find that more often than not the callbacks should be methods of some state-carrying object anyway (the exception being toy programs).» In the outset Guido here assumes a moronitude about the set of Python users and what they are familiar of. Python users 10 years ago are not the same Python users today, and will certainly not be the same 10 years later if you chop off lambda. Things change, math literacy advances, and what users you have changes with what you are. A function is the gist
Re: [Python-Dev] lambda in Python
This is utterly irrelevant for python-dev. Please take it elsewhere. Thanks, Anthony ___ 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 3102: Keyword-only arguments
BJörn Lindqvist wrote: > would have thought that the one obvious way to get rid of > the wanky feeling would have been to write: > > def make_person(name, age, phone, location): ... > > make_person(name, age, phone, location) This doesn't fly in something like PyGUI, where there are literally dozens of potential arguments to many of the constructors. The only sane way to deal with that is for them to be keyword-only, at least conceptually if not in actual implementation. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [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
[Python-Dev] Python long command line options
Hi all! Martin von Löwis said that it'd be necessary to discuss a patch to Python's ability to parse command-line parameters to the interpreter here, and I thought I might start the ball rolling. The associated patch of mine is: http://sourceforge.net/tracker/index.php?func=detail&aid=1481112&group_id=5470&atid=305470 which refers to: http://groups.google.de/group/comp.lang.python/browse_thread/thread/e3db1619040d7c6c/3c119e09122c83ed?hl=de#3c119e09122c83ed (sorry for the long URLs, tinyurl isn't working for me at the moment...) The patch itself is an extension of the Python/getopt.c module to handle long command-line parameters (including option data passed as --=), which are specified in the optstring as: "[(longopt)][:]" for example: "V(version)" or "c(command):" The patch doesn't change behaviour on old optstrings, except where an old optstring relied on the fact that one of :, (, ) are valid parameter names (because of the unconditional strchr to find the option name). I've not found any reference to _PyOS_GetOpt besides the one in Modules/main.c, so I don't think this change in behaviour breaks any existing code. The patch relies only on usability of strchr (which the old getopt.c did too), removes a usage of strcmp which was completely unneccesary, fixes some checks which were unneccesarily broad (>= replaced by ==), and compilation doesn't show any warnings on gcc 3.4.6; as for Windows (and MSVC), I don't have the means to test there. The current patch offers prefix matching: when an option is only specified with a significant amount of prefix characters which doesn't match any other long option, the patch assumes that the user meant this option. For example: --ver would also be interpreted as command-line parameter --version just as would --v --ve --vers --versi --versio if there are no other long options that start with the corresponding prefix. This "trick" is easy enough to remove from the sources, though, so that only correctly spelled options are actually returned. Anyway, back on topic, I personally agree with the people who posted to comp.lang.python that --version (and possibly --help, possibly other long parameters too) would be useful additions to Pythons command-line parameters, as it's increasingly getting more common amongst GNU and BSD utilities to support these command-line options to get information about the utility at hand (very popular amongst system administrators) and to use long commandline options to be able to easily see what an option does when encountered in a shell script of some sort. And, as this doesn't break any old code (-V isn't going away by the patch), I personally find this to be a very useful change. Your thoughts? --- Heiko. ___ 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] lambda in Python
xahlee xahlee.org> writes: > Today i ran into one of Guido van Rossum's blog article titled > “Language Design Is Not Just Solving Puzzles” at > http://www.artima.com/weblogs/viewpost.jsp?thread=147358 The confrontational tone of this post makes it pretty much impossible to have a reasonable debate on the subject. I'd suggest that if you really want to be heard (instead of merely having that "I'm right" feeling) that you try a different approach. -- Talin ___ 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
