[Python-Dev] str.partition?
Hi, a while ago, Raymond proposed str.partition, and I guess the reaction was positive. So what about including it now? Georg ___ 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] New-style icons, .desktop file
Nick Coghlan wrote: Georg Brandl wrote: Hi, some time ago, someone posted in python-list about icons using the Python logo from the new site design [1]. IMO they are looking great and would be a good replacement for the old non-scaling snakes on Windows in 2.5. Those are *really* pretty. And the self-referential PIL source code and disassembly is just plain brilliant. . . You could even use a similar style for a Python egg icon by placing the plus-Python logo in front of a file folder picture. However, the concerns raised on python-list about the similarities between the .exe and .pyc icons are valid, IMO. I also agree with Andrew Clover's own comment that having the Windows shortcut symbol cover the Python logo on the .exe is a bad thing. I've now got back an email from Andrew. About licensing, he says Whatever licence is easiest, I'm not too worried about it. He'll make some tweaks to the images, then I think they'll be ready. Now, are there any other opinions? Georg ___ 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] elementtree in stdlib
Greg Ewing wrote: Trent Mick wrote: try: import xml.etree.ElementTree as ET # in python =2.5 except ImportError: ... etc ad nauseam For situations like this I've thought it might be handy to be able to say import xml.etree.ElementTree or cElementTree or \ elementtree.ElementTree or lxml.etree as ET Suppose I wanted to implement that, what would be the best strategy to follow: - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c - emit different bytecodes in compile.c - directly create TryExcept AST nodes in ast.c ? Georg ___ 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] elementtree in stdlib
Nick Coghlan wrote: Georg Brandl wrote: Greg Ewing wrote: Trent Mick wrote: try: import xml.etree.ElementTree as ET # in python =2.5 except ImportError: ... etc ad nauseam For situations like this I've thought it might be handy to be able to say import xml.etree.ElementTree or cElementTree or \ elementtree.ElementTree or lxml.etree as ET Suppose I wanted to implement that, what would be the best strategy to follow: - change handling of IMPORT_NAME and IMPORT_FROM in ceval.c - emit different bytecodes in compile.c - directly create TryExcept AST nodes in ast.c Definitely option 3, since you only have to modify the parser and the AST compiler. To change it in compile.c, you have to first modify the parser, the AST definition and the AST compiler in order to get the info to the bytecode compiler. To change it in ceval.c, you have to first modify the parser, the AST definition, the AST compiler and the bytecode compiler in order to get the info to the eval loop. Given that import statements aren't supposed to be in time critical code, go for the easy option :) Well, if there's an encouraging word from more developers, I can try it. Georg ___ 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] Who understands _ssl.c on Windows?
Michael Hudson wrote: Tim Peters [EMAIL PROTECTED] writes: _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary when socketmodule.c is compiled, but (for some unknown reason) only to a 4-byte boundary when _ssl.c is compiled. Although that seems to match the details in the bug report, I have no theory for how that could happen (I don't see any MS packing pragmas anywhere). Well, poking a bit reveals that _ssl and _socket are built by quite different mechanisms: _socket by a .vcproj but _ssl by _ssl.mak. I don't see anything overly suspicious in _ssl.mak, but I don't really know much about Windows compiler options... A mailing list post found via Google suggests that Visual Studio automatically sets the struct member alignment to 4 bytes when building via old .mak files, for compatibility with older VC++. Anyway, a /Zp8 flag should correct this. Georg ___ 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] Request for review
Seo Sanghyeon wrote: Can someone have a look at #860326? I got bitten by it today, and I can see no reason not to apply suggested patch. I've reviewed it and checked it in. Cheers, Georg ___ 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] Request for review
Georg Brandl wrote: Seo Sanghyeon wrote: Can someone have a look at #860326? I got bitten by it today, and I can see no reason not to apply suggested patch. I've reviewed it and checked it in. Hm. This broke a few doctests. I can fix them, but I wonder if doctest should accept a bare exception name if the exception is defined in the current module. Or should it ignore the module name altogether? (Background: In normal exception tracebacks, non-builtin exceptions are printed with their module name prepended: Traceback: [...] decimal.InvalidOperation: ... When formatted by traceback.format_exception_only, the module name was omitted, which the patch mentioned above corrected. Since doctest relies on that behavior, three stdlib doctests broke.) Georg ___ 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-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: [georg.brandl] Author: georg.brandl Date: Wed Apr 12 23:14:09 2006 New Revision: 45321 Modified: python/trunk/Lib/test/test_traceback.py python/trunk/Lib/traceback.py python/trunk/Misc/NEWS Log: Patch #860326: traceback.format_exception_only() now prepends the exception's module name to non-builtin exceptions, like the interpreter itself does. And all the trunk buildbot runs have failed since, in at least test_decimal, test_doctest and test_unpack. Please run tests before checking in. Well, it's tempting to let the buildbots run the tests for you wink Honestly, I didn't realize that doctest relies on traceback. Running the test suite takes over half an hour on this box, so I decided to take a chance. The 2.4 backport of this patch should be reverted, since it changes visible behavior (for example, all the 2.4 branch buildbot runs also fail now). Right. That's too much of a behavior change. Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in). I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. Cheers, Georg ___ 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] Any reason that any()/all() do not take a predicate argument?
Mikhail Glushenkov wrote: Hi, sorry if this came up before, but I tried searching the archives and found nothing. It would be really nice if new builtin truth functions in 2.5 took a predicate argument(defaults to bool), so one could write, for example: seq = [1,2,3,4,5] if any(seq, lambda x: x==5): ... Well, does if any(x == 5 for x in seq) meet your needs? Georg ___ 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-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: [Georg Brandl] Well, it's tempting to let the buildbots run the tests for you wink Honestly, I didn't realize that doctest relies on traceback. Running the test suite takes over half an hour on this box, so I decided to take a chance. Nobody ever expects that a checkin will break tests, so merely expecting that a checkin won't break tests is not sufficient reason to skip running tests. You made a checkin that broke every buildbot slave we have, and I suggest you're taking a wrong lesson from that ;-) No objection, mylord ;) Do release-build tests without -uall take over half an hour on your box? Running that much is good enough precaution. Even (on boxes with makefiles) running make quicktest is mounds better than doing no testing. All the cases of massive buildbot test breakage we've seen this week would have been caught by doing just that much before checkin. Until now, I've always run with -uall. Running make quicktest is fine, but if the buildbots starts failing with -uall afterwards, no one will accept that as an excuse ;) When previously-passing buildbots start failing, it at least stops me cold, and (I hope) stops others too. Sometimes it's unavoidable. For example, I spent almost all my Python time Monday repairing a variety of new test failures unique to the OpenBSD buildbot (that platform is apparently unique in assigning addresses with the sign bit set, which broke all sorts of tests after someone changed id() to always return a positive value). That's fine -- it happens. It's the seemingly routine practice this week of checking in changes that break the tests everywhere that destroys productivity without good cause. I see, and I'm sorry I was part of it. Relatedly, if someone makes a checkin and sees that it breaks lots of buildbot runs, they should revert the patch themself instead of waiting for someone else to get so frustrated that they do it. Reverting is very easy with svn, but people are reluctant to revert someone else's checkin. The buildbot system is useless so long as the tests fail, and having the tests pass isn't optional. For excuse, I posted here immediately after I saw that the tests failed, asking whether to change doctest or revert my change. I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. Fine. There's another one, python.org/sf/1326077, which looks suspicious to me too. Georg ___ 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] New-style icons, .desktop file
Martin v. Löwis wrote: Fredrik Lundh wrote: you do wonderful stuff, and then you post the announcement as a followup to a really old message, to make sure that people using a threaded reader only stumbles upon this by accident... this should be on the python.org frontpage! I also wonder what the actions should be for the Windows release. Are these contributed to Python? With work of art, I'm particular cautious to include them without a specific permission of the artist, and licensing terms under which to use them. And then, technically: I assume The non-vista versions should be included the subversion repository, and the vista versions ignored? Or how else should that work? I would say yes. Vista isn't out there yet, and the icons can always be updated in 2.6. Georg ___ 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] what do you like about other trackers and what do you hate about SF?
Brett Cannon wrote: I am starting to hash out what the Call for Trackers is going to say on the Infrastructure mailing list. Laura Creighton suggested we have a list of features that we would like to see and what we all hate about SF so as to provide some guidelines in terms of how to set up the test trackers that people try to sell us on. So, if you could, please reply to this message with ONE thing you have found in a tracker other than SF that you have liked (especially compared to SF) and ONE thing you dislike/hate about SF's tracker. I will use the replies as a quick-and-dirty features list of stuff that we would like to see demonstrated in the test trackers. I'd like to have an ability to interconnect bugs (this patch fixes this bug, this bug is related to this other bug, etc.) with automatic closing of dependents etc. In SF, I hate that there is no possibility to close a bug with a checkin. And that SF displays only the full name of an item submitter, but not commenters. Georg ___ 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] 2.5 open issues
Martin v. Löwis wrote: Neal Norwitz wrote: Who is the owner for getting new icons installed with the new logo? Nobody, so far (for Windows). Somebody should contact the owner and find out what the license on this work is, and then tell me what to do with them. I assume the py and pyc icons are to be replaced, and I also assume the Vista icons are to be ignored, but what about the other(s)? As I posted here previously, I contacted the owner, and he said that he didn't care about specifying a license. I guess that means that we can pick one ;) Georg ___ 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] Float formatting and #
Is there a reason why the alternate format isn't documented for float conversions in http://docs.python.org/lib/typesseq-strings.html ? '%#8.f' % 1.0 keeps the decimal point while '%8.f' % 1.0 drops it. Also, for %g the alternate form keeps trailing zeroes. While at it, I noticed a difference between %f and %g: '%.3f' % 1.123 is 1.123 while '%.3g' % 1.123 is 1.12. Is that intentional? Georg ___ 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] Float formatting and #
Georg Brandl wrote: Is there a reason why the alternate format isn't documented for float conversions in http://docs.python.org/lib/typesseq-strings.html ? '%#8.f' % 1.0 keeps the decimal point while '%8.f' % 1.0 drops it. Also, for %g the alternate form keeps trailing zeroes. While at it, I noticed a difference between %f and %g: '%.3f' % 1.123 is 1.123 while '%.3g' % 1.123 is 1.12. Is that intentional? Reviewing the printf man page, this is okay since for %f, the precision is the number of digits after the decimal point while for %g, it is the number of significant digits. Still, that should be documented in the Python manual. Georg ___ 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] 2.5 open issues
Neal Norwitz wrote: Here's what's left for 2.5 after the most recent go around. There's no owner for these items. If no one takes them, they won't get done and I will move them to deferred within a week: * Add @decorator decorator to functional, rename to functools? What's the benefit of @decorator? Creating decorators that don't hinder introspection. Who made functional? It's new in 2.5, right? If so, move it or it will be functional for all 2.x. * Remove the fpectl module? Does anyone use this? It can probably be removed, but someone needs to do the work. * new icons is lost and needs a shepherd to make python look spiffy I've already done the work for Unixy platforms. Georg ___ 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-checkins] r45770 - in python/trunk:
A.M. Kuchling wrote: On Fri, Apr 28, 2006 at 01:13:21AM +0200, thomas.wouters wrote: - Warn-raise ImportWarning when importing would have picked up a directory as package, if only it'd had an __init__.py. This swaps two tests (for case-ness and __init__-ness), but case-test is not really more expensive, and it's not in a speed-critical section. For the what's new, I'd like to clarify the purpose of this change. Is the plan to make __init__.py optional in subpackages in 2.6, and this warning is a first step toward that? Or is this just to improve the error reporting when a directory lacking an __init__.py is found, and no further changes will be in 2.6? From what I have read out of the quite lengthy thread on this topic, there's no decision yet. Georg ___ 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] Problem with inspect and PEP 302
Recently, the inspect module was updated to conform with PEP 302. Now this is broken: import inspect inspect.stack() The traceback shows clearly what's going on. However, I don't know how to resolve the problem. Georg ___ 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] Adding functools.decorator
Nick Coghlan wrote: Collin Winters has done the work necessary to rename PEP 309's functional module to functools and posted the details to SF [1]. I'd like to take that patch, tweak it so the C module is built as _functools rather than functools, and then add a functools.py consisting of: I'm all for it. (You could integrate the C version of decorator from my SF patch, but I think Python-only is enough). from _functools import * # Pick up functools.partial def _update_wrapper(decorated, func, deco_func): # Support naive introspection decorated.__module__ = func.__module__ decorated.__name__ = func.__name__ decorated.__doc__ = func.__doc__ decorated.__dict__.update(func.__dict__) # Provide access to decorator and original function decorated.__decorator__ = deco_func decorated.__decorates__ = func def decorator(deco_func): Wrap a function as an introspection friendly decorator function def wrapper(func): decorated = deco_func(func) if decorated is func: return func _update_wrapper(decorated, func, deco_func) return decorated # Manually make this decorator introspection friendly _update_wrapper(wrapper, deco_func, decorator) return wrapper After typing those four lines of boilerplate to support naive introspection out in full several times for contextlib related decorators, I can testify that doing it by hand gets old really fast :) Agreed. Georg ___ 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] Adding functools.decorator
Guido van Rossum wrote: On 4/30/06, Georg Brandl [EMAIL PROTECTED] wrote: Nick Coghlan wrote: Collin Winters has done the work necessary to rename PEP 309's functional module to functools and posted the details to SF [1]. I'd like to take that patch, tweak it so the C module is built as _functools rather than functools, and then add a functools.py consisting of: I'm all for it. (You could integrate the C version of decorator from my SF patch, but I think Python-only is enough). Stronger -- this should *not* be implemented in C. There's no performance need, and the C code is much harder to understand, check, and modify. +1. I expect that at some point people will want to tweak what gets copied by _update_wrapper() -- e.g. some attributes may need to be deep-copied, or personalized, or skipped, etc. What exactly do you have in mind there? If someone wants to achieve this, she can write his own version of @decorator. One thing that would be nice to copy is the signature, but for that, like demonstrated by Simon Belak, exec trickery is necessary, and I think that's one step too far. The basic wish is just to let introspective tools, and perhaps APIs that rely on function's __name__ and __doc__ work flawlessly with decorators applied, nothing more. (Doesn't this already apply to __decorator__ and __decorates__? I can't prove to myself that these get set to the right things when several decorators are stacked on top of each other.) I don't think they're necessary. I'm curious if @decorator is the right name and the right API for this though? The name is overly wide (many things are decorators but should not be decorated with @decorator) and I wonder of a manual call to _update_wrapper() wouldn't be just as useful. Still, _update_wrapper would need to be defined somewhere, and it would have to be called in the body of the decorator. (Perhaps with a simpler API -- I'm tempted to call YAGNI on the __decorator__ and __decorates__ attributes.) I think there are too many design options here to check this in without more discussion. So let the discussion begin! Georg ___ 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] PEP 3102: Keyword-only arguments
Zachary Pincus wrote: Some thoughts from a lurker, largely concerning syntax; discount as you wish. First: Keyword-only arguments are not required to have a default value. Since Python requires that all arguments be bound to a value, and since the only way to bind a value to a keyword-only argument is via keyword, such arguments are therefore 'required keyword' arguments. Such arguments must be supplied by the caller, and they must be supplied via keyword. So what would this look like? def foo(*args, kw1, kw2): That seems a bit odd, as my natural expectation wouldn't be to see kw1 ands kw2 as required, no-default keyword args, but as misplaced positional args. Perhaps this might be a little better? def foo(*args, kw1=, kw2=): I'm rather not sure. At least it makes it clear that kw1 and kw2 are keyword arguments, and that they have no default values. Interesting, but perhaps a little too fancy. Though, I'm kind of neutral on the whole bit -- in my mind keyword args and default-value args are pretty conflated and I can't think of any compelling reasons why they shouldn't be. It's visually handy when looking at some code to see keywords and be able to say ok, those are the optional args for changing the handling of the main args. I'm not sure where the big win with required keyword args is. Personally I think that required keyword args will not be the most used feature brought by this PEP. More important is that you can give a function as many positional args as you want, all sucked up by the *args, and still supply a controlling keyword arg. For that matter, why not default positional args? I think everyone will agree that seems a bit odd, but it isn't too much odder than required keyword args. (Not that I'm for the former! I'm just pointing out that if the latter is OK, there's no huge reason why the former wouldn't be, and that is in my mind a flaw.) Second: def compare(a, b, *, key=None): This syntax seems a bit odd to me, as well. I always understood the *args syntax by analogy to globbing -- the asterisk means to take all the rest, in some sense in both a shell glob and *args. In this syntax, the asterisk, though given a position in the comma- separated list, doesn't mean take the rest and put it in this position. It means stop taking things before this position, which is a bit odd, in terms of items *in* an argument list. It continues to mean take the rest, but because there is no name to put it into, it will raise an exception if a rest is present. For me, it seems consistent. I grant that it makes sense as a derivation from *ignore-type solutions, but as a standalone syntax it feels off. How about something like: def compare(a, b; key=None): The semicolon is sort of like a comma but more forceful; it ends a phrase. This seems like a logical (and easily comprehended by analogy) use here -- ending the positional arguments phrase. Guido already ruled it out because it's an end of statement marker and nothing else. Georg ___ 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] PEP 3101: Advanced String Formatting
Zachary Pincus wrote:
I'm not sure about introducing a special syntax for accessing
dictionary entries, array elements and/or object attributes *within a
string formatter*... much less an overloaded one that differs from
how these elements are accessed in regular python.
Yes, I also think that's a bad idea.
Compound names are a sequence of simple names seperated by
periods:
My name is {0.name} :-\{\}.format(dict(name='Fred'))
And these escapes are also a bad idea. As it is, the backslashes stay in the
string, but it is not obvious to newcomers whether \{ is a general string
escape. The right way to do it would be \\{, but that's becoming rather
longly. Why not use something like {{?
Compound names can be used to access specific dictionary entries,
array elements, or object attributes. In the above example, the
'{0.name}' field refers to the dictionary entry 'name' within
positional argument 0.
Barring ambiguity about whether .name would mean the name attribute
or the name dictionary entry if both were defined, I'm not sure I
really see the point. How is:
d = {last:'foo', first:'bar'}
My last name is {0.last}, my first name is {0.first}..format(d)
really that big a win over:
d = {last:'foo', first:'bar'}
My last name is {0}, my first name is {1}..format(d['last'], d
['first'])
Or even:
d = {last:'foo', first:'bar'}
My last name is {last}, my first name is {first}..format(**d)
Georg
___
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] more pyref: a better term for string conversion
Guido van Rossum wrote: Backticks certainly are deprecated -- Py3k won't have them (nor will they become available for other syntax; they are undesirable characters due to font issues and the tendency of word processing tools to generate backticks in certain cases where you type forward ticks). And would it be acceptable for 2.5 to issue a DeprecationWarning for backticks? Georg ___ 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] test failures in test_ctypes (HEAD)
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 You might be interested in https://sourceforge.net/tracker/?func=detailatid=105470aid=1478253group_id=5470 Georg ___ 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 long command line options
Heiko Wundram wrote: 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? Personally, I'm +1, but wonder if it would be enough to support '--help' and '--version'. We then could cut out the best guess code and the code to enable --opt=value. Georg ___ 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] lambda in Python
xahlee wrote: I do not wish to be the subject of mobbing here. If you have opinions on what i wrote, respond to the subject on topic as with any discussion. Please do not start a gazillion war-cry on me. If you cannot tolerate the way i express my opinions, at this moment write a polite request to me and cc to the sys op of this forum. If the sysop deems fit, I'd be happy to be asked to leave by the sysop. There's no sysop needed to tell you this: This is a mailing list and newsgroup (no forum) devoted to the development *of* *Python*. Obviously, we all like Python the way it is and people who disagree (especially those who accuse the BDFL of being ignorant) don't belong here. Georg ___ 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] Py_ssize_t formatting
Martin v. Löwis wrote: Georg Brandl wrote: Similary, there's no way for a structmember to be of type Py_ssize_t... Right. At least, not with changing structmember.[ch]. Did you mean without? Can I submit a patch? Georg ___ 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] zlib module doesn't build - inflateCopy() not found
Martin v. Löwis wrote: Guido van Rossum wrote: It seems I have libz 1.1.4. Is this no longer supported? Apparently so. This function started to be used with r46012 | georg.brandl | 2006-05-16 09:38:27 +0200 (Di, 16 Mai 2006) | 3 lines Geänderte Pfade: M /python/trunk/Doc/lib/libzlib.tex M /python/trunk/Lib/test/test_zlib.py M /python/trunk/Misc/NEWS M /python/trunk/Modules/zlibmodule.c Patch #1435422: zlib's compress and decompress objects now have a copy() method. zlib itself contains inflateCopy since Changes in 1.2.0 (9 March 2003) - Added inflateCopy() function to record state for random access on externally generated deflate streams (e.g. in gzip files) The options for Python now are these: 1. require users to install zlib 1.2.x if they want the zlib module drawback: more work for the system administrator 2. conditionalize copy/uncopy on the system zlib being 1.2.x drawback: Python applications relying on these functions would break if the system zlib is too old 3. make setup.py fall back to the bundled zlib if the system zlib is too old drawback: you get all the problems of static linking, e.g. the size increase, and the problems with two zlib versions living in the same address space for some embedded Python applications I'm not volunteering to implement any of the options. Of course, option 4 is to revert the patch if none of these options are acceptable. Georg ___ 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] Import hooks falling back on built-in import machinery?
While working on a patch involving sys.path_importer_cache, I discovered that if a path_hooks import hook has been found for a given sys.path entry, but isn't able to import a specific module, find_module() tries to import the module from this sys.path entry as a regular file. This results in e.g. doing an open call to /usr/lib/python25.zip/x.py when I do import x, while I think that once a sys.path entry has been identified as belonging to a sys.path_hooks importer instance, it shouldn't be handled by the built-in machinery anymore since the path string could be anything. PEP 302 says ...it was chosen to ... simply fall back to the built-in logic if no hook on sys.path_hooks could handle the path item, but that's refering to sys.path entries, not individual module names to be imported. Georg ___ 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] A Horrible Inconsistency
Martin v. Löwis wrote: Fredrik Lundh wrote: -1 * (1, 2, 3) () -(1, 2, 3) Traceback (most recent call last): File stdin, line 1, in module TypeError: bad operand type for unary - We Really Need To Fix This! I can't find this inconsistency horrible. py +Hello Traceback (most recent call last): File stdin, line 1, in ? TypeError: bad operand type for unary + py +1*Hello 'Hello' Don't tell me that! I was actually working on a patch right now... Georg ___ 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] A Horrible Inconsistency
Georg Brandl wrote: Martin v. Löwis wrote: Fredrik Lundh wrote: -1 * (1, 2, 3) () -(1, 2, 3) Traceback (most recent call last): File stdin, line 1, in module TypeError: bad operand type for unary - We Really Need To Fix This! I can't find this inconsistency horrible. py +Hello Traceback (most recent call last): File stdin, line 1, in ? TypeError: bad operand type for unary + py +1*Hello 'Hello' Don't tell me that! I was actually working on a patch right now... Since I've already been bombarded with questions by some fellow Germans (which once again prove that they've got no sense of humour at all ;): this was a joke. georG ___ 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] Request for patch review
I've worked on two patches for NeedForSpeed, and would like someone familiar with the areas they touch to review them before I check them in, breaking all the buildbots which aren't broken yet ;) They are: http://python.org/sf/1346214 Better dead code elimination for the AST compiler http://python.org/sf/921466 Reduce number of open calls on startup GB Thanks! Georg ___ 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] A Horrible Inconsistency
Facundo Batista wrote: 2006/5/26, Sean Reifschneider [EMAIL PROTECTED]: On Fri, May 26, 2006 at 12:37:02PM -0300, Facundo Batista wrote: - Treat the negative as a reverser, so we get back (3, 2, 1). Then we could get: print -123 321 An integer is NOT a sequence. OTOH, that should be consistent to -1 * 123 321 This is actually a nice idea, because it's even a more nonintuitive answer for Python newbies posting to c.l.py asking how to reverse a string wink Georg ___ 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] A Horrible Inconsistency
Fredrik Lundh wrote: Sean Reifschneider wrote: - Treat the negative as a reverser, so we get back (3, 2, 1). Then we could get: print -123 321 Yay! and while we're at it, let's fix this: 0.66 * (1, 2, 3) (1, 2) and maybe even this 0.5 * (1, 2, 3) (1, 1) but I guess the latter one might need a pronunciation. No, no, no! Floating point is so inaccurate! It has to be Decimal(0.5) * (1, 2, 3) (1, Decimal(1)) Georg ___ 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] Remove METH_OLDARGS?
In the process of reviewing and possibly extending getargs.c, I stumbled over the compatibility flag supposedly used for METH_OLDARGS functions. No code in the core uses this calling convention any more, and it has been deprecated for quite a long time (since 2.2), so would it be appropriate to end support for it in 2.5? [G] ___ 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-checkins] Python Regression Test Failures refleak (101)
Michael Hudson wrote: So I think I'll be reading through exceptions.c pretty carefully. I don't think Sean and Richard have acquired as much paranoid anal-mindedness and I have when hacking on Python C internals yet :) I intended to go through the code again today or tomorrow, looking for things we missed, but I was on the plane until now, so obviously you were faster. Thanks for doing our work, though ;) Georg ___ 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] Remove METH_OLDARGS?
Neal Norwitz wrote: On 5/28/06, Georg Brandl [EMAIL PROTECTED] wrote: In the process of reviewing and possibly extending getargs.c, I stumbled over the compatibility flag supposedly used for METH_OLDARGS functions. No code in the core uses this calling convention any more, and it has been deprecated for quite a long time (since 2.2), so would it be appropriate to end support for it in 2.5? There's still a ton used under Modules. Also, if no flag is specified, it will default to 0 (ie, METH_OLDARGS). I wonder how many third party modules use METH_OLDARGS directly or more likely indirectly. These modules can be converted. I would like to get rid of the flag, but I'm not sure we can do it safely until 3.0. It has been deprecated since 2.2, so it'd be no surprise if it went away. We'd still have to support PyArg_Parse since it's a public API function and not deprecated, but it could just convert the arguments to new style and call PyArg_ParseTuple. Also, it would be easy to detect METH_OLDARGS in PyCFunction_New and raise an appropriate exception. It's not my decision though. Georg ___ 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-checkins] Python Regression Test Failures refleak (101)
Michael Hudson wrote: Georg Brandl [EMAIL PROTECTED] writes: Michael Hudson wrote: So I think I'll be reading through exceptions.c pretty carefully. I don't think Sean and Richard have acquired as much paranoid anal-mindedness and I have when hacking on Python C internals yet :) I intended to go through the code again today or tomorrow, looking for things we missed, but I was on the plane until now, so obviously you were faster. Oh right. I'd have preferred you didn't check in unfinished code to the trunk, I think... I blame it on Tim since he said OK ;) Thanks for doing our work, though ;) It has to be said, the degree of the refleaks put me into emergency fire fighting mode... I hadn't expected so many of them, but I also have to admit that we didn't have that much time on Saturday and wanted the branch merged for obvious reasons... [G] ___ 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-checkins] Python Regression Test Failures refleak (101)
Michael Hudson wrote: Michael Hudson [EMAIL PROTECTED] writes: I think I've fixed the refleaks too, but running regrtest -R :: takes rther a while. I hadn't: test_codecs and test_codeccallbacks both leak, the latter quite spectacularly (9000+ refleaks a run). The test_codecs leaks come from calls to codecs.decode_charmap, I'm not sure that it's to do with the exceptions.c changes. The test_codeccallbacks leaks seem more like they could be exception related: when a unicode decoding fails, two references are leaked. I've run out of energy for these tonight. I repaired that, it was in the GetStart/GetEnd functions for UnicodeErrors. Currently running -R ::, so let's see... Georg ___ 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] feature request: inspect.isgenerator
Fredrik Lundh wrote: Terry Reedy wrote: def isgenerator(func): return func.func_code.co_flags == 99 but it is rather ugly (horrible indeed). To me, part of the beauty of Python is that is so easy to write such things so compactly, so that we do not need megaAPIs with hundreds of functions and methods. so what's so easy about the magic constant 99 ? is there some natural and obvious connection between generators and that number that I'm missing, or is that constant perhaps best hidden inside some introspection support module? It seems to be a combination of CO_NOFREE, CO_GENERATOR, CO_OPTIMIZED and CO_NEWLOCALS. The first four CO_ constants are already in inspect.py, the newer ones (like CO_GENERATOR) aren't. I wonder whether a check shouldn't just return (co_flags 0x20), which is CO_GENERATOR. Georg ___ 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] Remove METH_OLDARGS?
Thomas Wouters wrote: On 5/29/06, *Fredrik Lundh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: this is a clear case of unnecessary meddling. removing it won't remove much code (a whopping 11 lines is dedicated to this), nor give any speed ups whatsoever; all you're doing is generating extra work and support issues for a bunch of third-party developers. trust me, we have better things to do with our time. -1 on meddling with this before 3.0. -1 from me, too, for the same reason. It would be nice if the use of PyArg_Parse could generate a (C) compile-time warning, but since it can't, I think a runtime warning for this minor case is just overkill. (The C compile-time warning would be useful in other cases, too... hmm, perhaps we can do some post-processing of .o files, looking for deprecated symbols left undefined...) Isn't there at least a GCC __attribute__((deprecated))? Georg ___ 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] Remove METH_OLDARGS?
Martin v. Löwis wrote: Georg Brandl wrote: Isn't there at least a GCC __attribute__((deprecated))? Yes, but it applies to functions only. I guess you could make a __deprecated__ function, and then expand METH_OLDARGS to a call of that function. That won't help in cases where there are no flags given at all in the method structures. I thought more about PyArg_Parse for __deprecated__. If you look at the patch on SF, it's creating warnings whenever a new CFunction is created with a METH_OLDARGS flag. I'm not sure this is the right way since it may mean that users of extensions using METH_OLDARGS might get a warning each time they get a bound method using it. Georg ___ 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] Remove METH_OLDARGS?
Martin v. Löwis wrote: Guido van Rossum wrote: I think that should be done for 2.5, but nothing else. Or, perhaps a deprecation warning could be generated if it is still used. I'll let Martin decide this one. I just sent a message to some that producing a DeprecationWarning is fine, but now I read some opposition; given that this really just needs very little code to support it, and given that run-time warnings annoy the users, not the module authors, I agree that this should stay silently until 3.0. We should still continue to remove all uses we have ourselves. The only modules METH_OLDARGS is now used in are fl, sv, gl, cl and Tkinter (for the latter there is my patch on SF for review). sv and cl are listed in PEP 356 as possibly being removed, I don't know whether the other ones are used anymore. Georg ___ 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] Remove METH_OLDARGS?
Fredrik Lundh wrote: Georg Brandl wrote: I'd be satisfied with a deprecation warning for PyArg_Parse, though we (*) should really figure out how to make it work on Windows. I haven't seen anyone object to the C compiler deprecation warning. There is something at http://msdn2.microsoft.com/en-us/library/044swk7y.aspx but it says only C++. and links to http://msdn2.microsoft.com/en-us/library/c8xdzzhh.aspx which provides a pragma that does the same thing, and is documented to work for both C and C++, and also works for macros. But we'd have to use an #ifdef for every deprecated function. Of course, there aren't so many of them. Georg ___ 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] A can of worms... (does Python C code have a new C style?)
Martin Blais wrote: Hi all I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a new indentation for style for the Python C source files, with * indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think) (Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct? The consensus at NFS was that it also applies to newly written C files. I did update the PEP, but that doesn't seem to have propagated to the web site yet. However, people were maintaining the existing styles when they were editing part of existing files (I setup emacs users with two c-styles, python and python-new, so they could switch per-file), but using the new guidelines for new files. I look at the source code, and there is a bit of a mix of the two styles in some places. That's bad, but is the way the code was written and should not be changed for the sake of changing. Is there a grand plan to convert all the code at once at some point? If not, how is it that these new guidelines are supposed to take effect? AFAIK not before Python 3.0 since it would unnecessarily break, for instance, svn blame and make merging more difficult. [...] In addition, should this be applied, we should probably create a Subversion hook that will automatically convert tabs to spaces, or fails the commit if the files don't comply. For the future (=Py3k), I think this would be nice. Georg ___ 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] Arguments and PyInt_AsLong
Looking at #1153226, I found this: We introduced emitting a DeprecationWarning for PyArg_ParseTuple integer arguments if a float was given. This doesn't affect functions like file.seek which use PyInt_AsLong to parse their argument. PyInt_AsLong calls the nb_int slot which silently converts floats to ints. Is that acceptable, should PyInt_AsLong not accept other numbers or should the functions be changed? Georg ___ 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] feature request: inspect.isgenerator
Michele Simionato wrote: Neal Norwitz nnorwitz at gmail.com writes: I wonder whether a check shouldn't just return (co_flags 0x20), which is CO_GENERATOR. Makes more sense. Okay, but my point is that the final user should not be expected to know about those implementation details. The one obvious way to me is to have an inspect.isgenerator, analogous to inspect.isfunction, inspect.ismethod, etc. The typical use case is in writing a documentation/debugging tool. Now I was writing a decorator that needed to discriminate in the case it was decorating a regular function versus a generator. I'd say, go ahead and write a patch including docs, and I think there's no problem with accepting it (as long as it comes before beta1). Georg ___ 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] feature request: inspect.isgenerator
Michele Simionato wrote: Georg Brandl g.brandl at gmx.net writes: I'd say, go ahead and write a patch including docs, and I think there's no problem with accepting it (as long as it comes before beta1). I was having a look at http://docs.python.org/dev/lib/inspect-types.html and it would seem that adding isgenerator would imply changing inspect.getmembers() and its documentation. Yep. Also, should one add a GeneratorType, perhaps as a subclass of FunctionType? Add GeneratorType where? There is already one in the types module. Georg ___ 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] feature request: inspect.isgenerator
Michele Simionato wrote: Georg Brandl g.brandl at gmx.net writes: Also, should one add a GeneratorType, perhaps as a subclass of FunctionType? Add GeneratorType where? There is already one in the types module. Yep, this is the crux. types.GeneratorType refers to generator objects, which in an improper sense are instances of a generator function. I.e. def g(): yield 1 # this is a generator go = g() # this is a generator object I want isgenerator(g) == True, but isgenerator(go) == False. Ah, ok. But then I would name the function differently, perhaps isgeneratorfunc(). So, what should be the class of g ? Maybe we can keep FunctionType and don't bother. I would say, keep FunctionType. There's no real need to know the exact type except for inspecting, and for that, the new function in inspect can be used. Georg ___ 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] S/390 buildbot URLs problematic
The S/390 buildbot should be renamed. While the URLs buildbot generates in its email messages work, the ones that are on the overview page don't. Georg ___ 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] SF patch #1473257: Add a gi_code attr to generators
Phillip J. Eby wrote: At 09:53 PM 5/31/2006 +0200, Collin Winter wrote: Hi Phillip, Do you have any opinion on this patch (http://python.org/sf/1473257), which is assigned to you? I didn't know it was assigned to me. I guess SF doesn't send any notifications, and neither did Georg, so your email is the very first time that I've heard of it. BTW, there's another one: #1483133. Georg ___ 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] Unhashable objects and __contains__()
Collin Winter wrote:
I recently submitted a patch that would optimise in (5, 6, 7) (ie,
in ops on constant tuples) to in frozenset([5, 6, 7]). Raymond
Hettinger rejected (rightly) the patch since it's not semantically
consistent. Quoth:
Sorry, this enticing idea has already been explored and
rejected. This is issue is that the transformation is not
semanatically neutral. Currently, writing {} in (1,2,3)
returns False, but after the transformation would raise an
exception, TypeError: dict objects are unhashable.
My question is this: maybe set/frozenset.__contains__ (as well as
dict.__contains__, etc) should catch such TypeErrors and convert them
to a return value of False? It makes sense that {} in frozenset([(1,
2, 3]) should be False, since unhashable objects (like {}) clearly
can't be part of the set/dict/whatever.
I am, however, a bit unsure as to how __contains__() would be sure it
was only catching the this object can't be hash()ed TypeErrors, as
opposed to other TypeErrors that might legimately arise from a call to
some __hash__() method.
Idea: what if Python's -O option caused PySequence_Contains() to
convert all errors into False return values?
It would certainly give me an uneasy feeling if a command-line switch
caused such a change in semantics.
Georg
___
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] Request for patch review
Georg Brandl wrote: I've worked on two patches for NeedForSpeed, and would like someone familiar with the areas they touch to review them before I check them in, breaking all the buildbots which aren't broken yet ;) They are: http://python.org/sf/1346214 Better dead code elimination for the AST compiler No one wants to look at this? It's not too complicated, I promise. http://python.org/sf/921466 Reduce number of open calls on startup GB That's now committed. Georg ___ 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] Unhashable objects and __contains__()
Collin Winter wrote: On 6/4/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 6/3/06, Georg Brandl [EMAIL PROTECTED] wrote: Collin Winter wrote: Idea: what if Python's -O option caused PySequence_Contains() to convert all errors into False return values? It would certainly give me an uneasy feeling if a command-line switch caused such a change in semantics. I missed that. Collin must be suffering from a heat stroke. :-) I don't think Munich gets hot enough for heat stroke ; ) I can confirm that, unfortunately. The best thing you can say about our weather at the moment is that the winter is relatively mild :( The more likely culprit is a lack of coffee this morning and a bit too much weissbier last night. I'd blame it on the coffee. Georg ___ 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 Benchmarks
Thomas Wouters wrote: On 6/8/06, *M.-A. Lemburg* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Perhaps it's a new feature in gcc 4.0 that makes the slow-down I see turn into a speedup :-) It seems so. I tested with gcc 2.95, 3.3 and 4.0 on FreeBSD 4.10 (only machine I had available with those gcc versions) and both 2.95 and 4.0 show a 10-20% speedup of your testcase in 2.5 compared to 2.4. 3.3 showed a 10% slowdown or so. Does 4.0 show a general slowdown on your test machines? I saw a drop of average Pystones from 44000 to 4 and from 42000 to 39000 on my boxes switching from GCC 3.4.6 to 4.1.1. Georg ___ 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] zlib module doesn't build - inflateCopy() not found
Chris AtLee wrote: On 5/21/06, Guido van Rossum [EMAIL PROTECTED] wrote: Then options 2 and 3 are both fine. Not compiling at all is *not*, so if nobody has time to implement 2 or 3, we'll have to do 4. --Guido Is this thread still alive? At least I still have this on my todo list. I've posted patch #1503046 to sourceforge which implements option #2 by checking for inflateCopy() in the system zlib during the configure step. Thank you! As this involves autotools magic, I hope Martin (who assigned the patch to himself) can look over it instead of me. Georg ___ 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] Segmentation fault in collections.defaultdict
Nick Coghlan wrote: Kevin Jacobs [EMAIL PROTECTED] wrote: Try this at home: import collections d=collections.defaultdict(int) d.iterkeys().next() # Seg fault d.iteritems().next() # Seg fault d.itervalues().next() # Fine and dandy This all worked fine for me in rev 46739 and 46849 (Kubuntu 6.06, gcc 4.0.3). Python version: Python 2.5a2 (trunk:46822M, Jun 10 2006, 13:14:15) [GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] on linux2 Either something got broken and then fixed again between the two revs I tried, there's a problem specific to GCC 4.0.2, or there's a problem with whatever local modifications you have in your working copy :) Same here. I tried with the same revision as Kevin, and got no segfault at all (using GCC 4.1.1 on Linux). Note that GCC 4.0.2 20050901 (prerelease) sound like something that's not really been thoroughly tested ;) Georg ___ 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] file()
Guido van Rossum wrote: Yup, although it's a change in behavior that would need to be studied carefully for backwards incompatibilities. Usually it's given as a constant, so there won't be any problems; but there might be code that receives a mode string and attempts to test its validity by trying it and catching IOError, such code would have to be changed. --Guido On 6/12/06, Kristján V. Jónsson [EMAIL PROTECTED] wrote: I notice that file() throws an IOError when it detects an invalid mode string. Wouldn't a ValueError be more appropriate? The situation is even more complex with the current trunk. open() raises ValueError if it detects an invalid the mode string, such as universal newline mode and a writable mode combined (the definition of what is invalid has been made stricter, the mode string now must begin with r, w, a or U), but it raises IOError if the OS call to fopen() fails because of an invalid mode string. This might need unification. Georg ___ 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] file()
Guido van Rossum wrote: On 6/12/06, Georg Brandl [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Yup, although it's a change in behavior that would need to be studied carefully for backwards incompatibilities. Usually it's given as a constant, so there won't be any problems; but there might be code that receives a mode string and attempts to test its validity by trying it and catching IOError, such code would have to be changed. --Guido On 6/12/06, Kristján V. Jónsson [EMAIL PROTECTED] wrote: I notice that file() throws an IOError when it detects an invalid mode string. Wouldn't a ValueError be more appropriate? The situation is even more complex with the current trunk. open() raises ValueError if it detects an invalid the mode string, such as universal newline mode and a writable mode combined (the definition of what is invalid has been made stricter, the mode string now must begin with r, w, a or U), but it raises IOError if the OS call to fopen() fails because of an invalid mode string. This might need unification. That would be hard to fix unless we get rid of the stdio-based implementation (which I intend to do in Py3k). I say we leave it alone for now -- fopen() can fail for any number of platform-dependent reasons and we can't really expect to do look-before-you-leap on this. One option would be to raise IOError in the former case too. That's what I meant with unification. Cheers, Georg ___ 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] Long options support
I've just closed a bug report wishing for long option support, pointing to a patch sitting in the patch tracker implementing this. Should we accept at least the very common options --help and --version in 2.5? Georg ___ 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] Improve error msgs?
Georg Brandl wrote: In abstract.c, there are many error messages like type_error(object does not support item assignment); It helps debugging if the object's type was prepended. Should I go through the code and try to enhance them where possible? So that's definite perhaps? Anyway, posted patch 1507676. Georg ___ 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] Switch statement
Guido van Rossum wrote: On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote: I say, let someone give a complete implementation a try, and then try to modify as much standard library code as possible to use it. Then report back. That would be a very interesting experiment to do. (And thanks for the pointer to sre_compile.py as a use case!) Hmm, it could be time for the Georg bot to graduate to big game. Georg, are you up to it? I feel I am, and I'll have enough time until 2.6 anyway. However, I first want to know that the syntax and semantics have been properly discussed and fixed. One thing I like to propose which could resolve the ambiguity of case 1,2,3: is: switch x: case (1, 2, 3): # if x is the tuple (1,2,3) case in 1, 2, 3: # if x is 1, 2 or 3 Georg is a bot? :-) Yes, I was initiated in Reykjavik ;) Georg ___ 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] Switch statement
Ka-Ping Yee wrote: On Wed, 21 Jun 2006, Phillip J. Eby wrote: Well, EIBTI and all that: switch x: case == 1: foo(x) case in S: bar(x) It even lines up nicely. :) Hmm, this is rather nice. I can imagine possible use cases for switch x: case 3: foo(x) case is y: spam(x) Ha, a slight reminiscence of BASIC... case == z: eggs(x) An interesting use case for which this offers no corresponding syntax is case instanceof ClassA: ham(x) which doesn't work because Python spells a type test as isinstance(a, b) rather than with an operator. (I suppose whether we want it to be an operator might be another question to think about for Python 3000.) FWIW, I like is a most, but there's no way to spell this as one word without confusing readers. Georg ___ 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: http://docs.python.org/dev/whatsnew/ports.html says: The PyRange_New() function was removed. It was never documented, never used in the core code, and had dangerously lax error checking. I use this function (don't remember how I found it; this was years ago), therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2). Is there an alternative spelling for PyRange_New()? You can call PyRange_Type with the appropriate parameters. Georg ___ 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] Switch statement
Guido van Rossum wrote: I've also been wondering whether the 'case' keyword is really necessary? Would any ambiguities or other parsing problems arise if you wrote: switch x: 1: foo(x) 2: bar(x) It is debatable whether this is more or less readable, but it seemed like an interesting question for the language lawyers. That's no problem for the parser, as long as the expressions are indented. ABC did this. But I think I like an explicit case keyword better; it gives a better error message if the indentation is forgotten. It also overthrows the notion that suites are started by statements, not by expressions. Georg ___ 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] Switch statement
Guido van Rossum wrote: On 6/22/06, Georg Brandl [EMAIL PROTECTED] wrote: Guido van Rossum wrote: I've also been wondering whether the 'case' keyword is really necessary? Would any ambiguities or other parsing problems arise if you wrote: switch x: 1: foo(x) 2: bar(x) It is debatable whether this is more or less readable, but it seemed like an interesting question for the language lawyers. That's no problem for the parser, as long as the expressions are indented. ABC did this. But I think I like an explicit case keyword better; it gives a better error message if the indentation is forgotten. It also overthrows the notion that suites are started by statements, not by expressions. I'm not sure I care about that. Do you use this in teaching? How does it help you? I just realized that my post could be misunderstood: The sentence referred to the case-less form. (And it's just a feeling thing) Georg ___ 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] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: --- Georg Brandl [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: http://docs.python.org/dev/whatsnew/ports.html says: The PyRange_New() function was removed. It was never documented, never used in the core code, and had dangerously lax error checking. I use this function (don't remember how I found it; this was years ago), therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2). Is there an alternative spelling for PyRange_New()? You can call PyRange_Type with the appropriate parameters. Thanks a lot for the hint! However, I cannot find any documentation for PyRange_*. I tried this page... http://docs.python.org/api/genindex.html and google. Did I miss something? I am sure I can get this to work with some digging, but I am posting here to highlight a communication problem. I feel if a function is removed the alternative should be made obvious in the associated documentation; in particular if there is no existing documentation for the alternative. Well, PyRange_New *was* undocumented, so there's no place in the documentation where it would have been. However, it would perhaps be helpful to add a note to the whatsnew document for users like yourself. Andrew, does that make sense? Georg ___ 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] Switch statement
M.-A. Lemburg wrote: A nice side-effect would be that could easily use the same approach to replace the often used default-argument-hack, e.g. def fraction(x, int=int, float=float): return float(x) - int(x) This would then read: def fraction(x): const int, float return float(x) - int(x) There's a certain risk that the premature-optimization fraction will plaster every function with const declarations, but they write unreadable code anyway ;) Aside from this, there's still another point: assume you have quite a number of module-level string constants which you want to use in a switch. You'd have to repeat all of their names in a const declaration in order to use them this way. Georg ___ 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] Simple Switch statement
Raymond Hettinger wrote: No thanks. That is its own can of worms. The obvious solutions (like const declarations, macros, or a syntax to force compile-time expression evaluation) are unlikely to sit well because they run afoul Python's deeply ingrained dynamism. I think perhaps you haven't been paying close attention to Fredrik's proposal. Yes, I have been. That is one of the three options I listed above. Each has its own issues. The static() keyword works like Forth's brackets for forcing compile-time evaluation. The issue for us is that unlike other Python expressions, there are inconvenient limitiations on what can be expressed inside: five = 5 eight = [8] def f(x, six=6): seven = 7 a = static(five + 4)# this is legal b = static(six + 4) # this is illegal c = static(seven + 4) # this is illegal d = static(eight + [4]) # this is illegal Why would the last line be illegal? That will be a perpetual maintenance trap and conundrum for newbies. In contrary to other newbie traps such as mutable default arguments, if this would give a clear exception message like function-local name cannot be used in static expression, I can't imagine it would be a bigger problem than e.g. why is my floating point result incorrect. Georg ___ 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] PEP 328 and PEP 338, redux
Guido van Rossum wrote: On 6/27/06, Greg Ewing [EMAIL PROTECTED] wrote: Giovanni Bajo wrote: This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. Could this be reconsidered for Py3k? You have a point. Added to PEP 3100. Georg ___ 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] document @property?
In followup to a clpy discussion, should the docs contain a note that property can be used as a decorator for creating read-only properties? Georg ___ 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] LOAD_CONST POP_TOP
Hi,
the following patch tries to fix the LOAD_CONST POP_TOP optimization
lost in 2.5 (bug #1333982).
An example for this is:
def f():
'a' # docstring
'b'
Georg
PS: Hmm. While looking, I see that 2.4 doesn't optimize away other constants
like
def g():
1
Index: Python/compile.c
===
--- Python/compile.c(Revision 47150)
+++ Python/compile.c(Arbeitskopie)
@@ -775,10 +775,16 @@
}
break;
+ case LOAD_CONST:
+ cumlc = lastlc + 1;
+ /* Skip over LOAD_CONST POP_TOP */
+ if (codestr[i+3] == POP_TOP) {
+ memset(codestr+i, NOP, 4);
+ cumlc = 0;
+ break;
+ }
/* Skip over LOAD_CONST trueconst
JUMP_IF_FALSE xx POP_TOP */
- case LOAD_CONST:
- cumlc = lastlc + 1;
j = GETARG(codestr, i);
if (codestr[i+3] != JUMP_IF_FALSE ||
codestr[i+6] != POP_TOP ||
___
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] Empty Subscript PEP on Wiki - keep or toss?
[EMAIL PROTECTED] wrote: Noam Raphael posted an empty subscript PEP on the Python Wiki: http://wiki.python.org/moin/EmptySubscriptListPEP It's not linked to by any other pages on the wiki. Is there a reason it wasn't added to the peps repository? Perhaps the author forgot to submit it to the PEP editor, or he decided to abandon it after the mostly negative discussion here. Georg ___ 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] Bug in stringobject?
Georg Brandl wrote:
In string_replace, there is
if (PyString_Check(from)) {
/* Can this be made a '!check' after the Unicode check? */
}
#ifdef Py_USING_UNICODE
if (PyUnicode_Check(from))
return PyUnicode_Replace((PyObject *)self,
from, to, count);
#endif
else if (PyObject_AsCharBuffer(from, tmp_s, tmp_len))
return NULL;
[the same check with to]
return (PyObject *)replace((PyStringObject *) self,
(PyStringObject *) from,
(PyStringObject *) to, count);
Can this be correct if from or to isn't a string object, but a
char buffer compatible object?
May I note that this is still unresolved? I can submit a bug report
and add it to PEP 356, too...
Georg
___
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] Bug in stringobject?
Fredrik Lundh wrote: Georg Brandl wrote: Can this be correct if from or to isn't a string object, but a char buffer compatible object? May I note that this is still unresolved? I can submit a bug report and add it to PEP 356, too... it's already on my todo list, but that list is full of stuff, so having it on the official todo list is probably a good idea. if you do add it, assign it to me. Done. #1515471. Georg ___ 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] Time-out in URL Open
[EMAIL PROTECTED] wrote: Facundo I need a timeout in urlopen, just to be able to make: urllib2.urlopen(http://no.host.org;, timeout=2) Facundo This is actually not possible, but I'll make it work. Facundo I want to know, please, if this is useful in general, for me to Facundo post a patch in SF. As others have posted, yes, it would be useful for 2.6. However, you should consider how that might be applied to the other Internet service modules (ftplib, telnetlib, urllib, etc). There was one patch that did this: http://python.org/sf/723312. Georg ___ 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] Explicit Lexical Scoping (pre-PEP?)
Guido van Rossum wrote: On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:18 AM 7/5/2006 +0200, Guido van Rossum wrote: I don't see anything else that's attractive. The realistic options are: 1. do nothing 2. extend global's meaning 3. add outer keyword Did you also consider and reject: * Alternate binding operators (e.g. :=, .=, etc.) Brr. * Alternate spelling of outer names when binding (e.g. .x = whatever to bind an outer x) We looked at and rejected globals.x = whatever. I think the same reasoning applies here. If so, then these should probably be added to the rejected alternatives for Py3K so they don't get rehashed. Georgbot? I added the alternative binding operators. The discussion about .x seems to be still in progress. Georg ___ 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] Missing 2.5 feature
Tim Peters wrote: Back in: http://mail.python.org/pipermail/python-dev/2005-March/051856.html I made a pitch for adding: sys._current_frames() to 2.5, which would return a dict mapping each thread's id to that thread's current (Python) frame. As noted there, an extension module exists along these lines that's used at least by the popular Zope DeadlockDebugger product, but it's not possible to do it correctly in an extension. The latter is why it needs to be in the core (so long as it's in an extension, it risks segfaulting, because the core's internal `head_mutex` lock isn't exposed). I forgot about this but was recently reminded. How much opposition would there be to sneaking this into 2.5b2? It would consist of adding a relatively simple new function, docs, and tests; since it wouldn't _change_ any existing code, it would have a hard time breaking anything that currently works. If you just check it in, using an appropriate log message[1] I think nobody would object. wink Georg [1] Thinking of Whitespace normalization... ___ 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] Missing 2.5 feature
Richard Jones wrote: On 09/07/2006, at 9:05 AM, Anthony Baxter wrote: I'm really not keen on this seeming tide of new features wink that seem to be popping up. We're only a few days away from the second and final planned beta - it's getting _awfully_ late to be slotting in new features. And besides, one person has already been told that there's absolutely no new features added after the beta freeze, ever. Last time I looked, features approved by the BDFL and/or release manager were OK to go in. Besides, quite a few bugfixes are likely to introduce more new features than this ;) Cheers, Georg ___ 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] Minor: Unix icons for 2.5?
Anthony Baxter wrote: There's an open PEP-356 issue for update the icons to the newer shinier ones for Unix. As far as I can see, there's the 14x15 GIF images used for Idle and the documentation. Note that for me at least, idle comes up without an icon _anyway_. Are there any others I missed? In case we add a Python .desktop file (as proposed in patch #1353344), we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in is attached. Georg Index: Misc/python.desktop.in === --- Misc/python.desktop.in (Revision 0) +++ Misc/python.desktop.in (Revision 0) @@ -0,0 +1,14 @@ +[Desktop Entry] +Encoding=UTF-8 +Name=Python Programming Language +Name[sv]=Programspråket Python +Name[de]=Die Programmiersprache Python +Comment=Program in Python +Comment[sv]=Programmera med Python +Comment[de]=Programmieren in Python +Exec=python_VER_ %f +Terminal=true +Type=Application +Icon=pycon.png +Categories=Application;Development;ConsoleOnly +MimeType=text/x-python;application/x-python Index: Makefile.pre.in === --- Makefile.pre.in (Revision 47289) +++ Makefile.pre.in (Arbeitskopie) @@ -89,6 +89,8 @@ INCLUDEDIR=@includedir@ CONFINCLUDEDIR=$(exec_prefix)/include SCRIPTDIR= $(prefix)/lib +DESKTOPDIR= $(prefix)/share/applications +ICONDIR=$(prefix)/share/icons # Detailed destination directories BINLIBDEST=$(LIBDIR)/python$(VERSION) @@ -614,7 +616,7 @@ $(TESTPYTHON) $(TESTPROG) $(MEMTESTOPTS) # Install everything -install: @FRAMEWORKINSTALLFIRST@ altinstall bininstall maninstall @FRAMEWORKINSTALLLAST@ +install: @FRAMEWORKINSTALLFIRST@ altinstall bininstall maninstall desktopinstall @FRAMEWORKINSTALLLAST@ # Install almost everything without disturbing previous versions altinstall:@FRAMEWORKALTINSTALLFIRST@ altbininstall libinstall inclinstall libainstall \ @@ -687,6 +689,25 @@ $(INSTALL_DATA) $(srcdir)/Misc/python.man \ $(DESTDIR)$(MANDIR)/man1/python.1 +# Install the .desktop file and the icons +desktopinstall: + @for i in $(DESKTOPDIR) $(ICONDIR) $(ICONDIR)/hicolor $(ICONDIR)/hicolor/16x16 $(ICONDIR)/hicolor/32x32 $(ICONDIR)/hicolor/48x48; \ + do \ + if test ! -d $(DESTDIR)$$i; then \ + echo Creating directory $$i; \ + $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \ + elsetrue; \ + fi; \ + done + sed 's/_VER_/$(VERSION)$(EXE)/' $(srcdir)/Misc/python.desktop.in $(srcdir)/Misc/python.desktop + $(INSTALL_DATA) $(srcdir)/Misc/python.desktop $(DESTDIR)$(DESKTOPDIR)/python.desktop + for i in 16x16 32x32 48x48; \ + do \ + $(INSTALL_DATA) $(srcdir)/Misc/py-$$i.png $(DESTDIR)$(ICONDIR)/hicolor/$$i/py.png; \ + $(INSTALL_DATA) $(srcdir)/Misc/pyc-$$i.png $(DESTDIR)$(ICONDIR)/hicolor/$$i/pyc.png; \ + $(INSTALL_DATA) $(srcdir)/Misc/pycon-$$i.png $(DESTDIR)$(ICONDIR)/hicolor/$$i/pycon.png; \ + done + # Install the library PLATDIR= plat-$(MACHDEP) EXTRAPLATDIR= @EXTRAPLATDIR@ @@ -1076,7 +1097,7 @@ # Declare targets that aren't real files .PHONY: all sharedmods oldsharedmods test quicktest memtest .PHONY: install altinstall oldsharedinstall bininstall altbininstall -.PHONY: maninstall libinstall inclinstall libainstall sharedinstall +.PHONY: maninstall libinstall inclinstall libainstall sharedinstall desktopinstall .PHONY: frameworkinstall frameworkinstallframework frameworkinstallstructure .PHONY: frameworkinstallmaclib frameworkinstallapps frameworkinstallunixtools .PHONY: frameworkaltinstallunixtools recheck autoconf clean clobber distclean ___ 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] get for lists and tuples?
Russell E. Owen wrote: I'd like to have the get method available for lists and tuples. (I figured this must have been discussed before but can't recall it and didn't turn anything up on google). It's obviously not a use-all-the-time method (or it'd already be there), but I find myself wanting it often enough to justify it in my own mind (and curse this omission, relative to dict). Basically I run into it when parsing data of variable length (where the extra elements have some obvious default value), including config files, sys.argv (for simple command scripts), that sort of thing. Yes a 4-liner does the job, but get would be a much clearer way to write it. A 4-liner? x = (list[i:i+1] or (default,))[0] is just one line ;) Honestly, often enough you can work around with slices in one or the other way. Anyway, I'm just testing the waters. If it's not heresy then I'd like to do what I can to make it happen. IMO there's almost no chance this can go into 2.5. Georg ___ 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] Minor: Unix icons for 2.5?
Fred L. Drake, Jr. wrote: Anthony Baxter wrote: There's an open PEP-356 issue for update the icons to the newer shinier ones for Unix. As far as I can see, there's the 14x15 GIF images used for Idle and the documentation. Note that for me at least, idle comes up without an icon _anyway_. A pyfav.(gif|png) replacement would be quite welcome! On Tuesday 11 July 2006 13:25, Georg Brandl wrote: In case we add a Python .desktop file (as proposed in patch #1353344), we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in is attached. I know the .desktop files have become fairly standard, but are these our responsibility or does that rest with the distributions/integrators? (I'm not objecting, but I'm not sure what the right thing really is since Python is an interpreter, not a desktop application.) I'm also not very sure, as I myself would never start python via a menu entry. But for newcomers, it could be as it is for Windows users: A menu entry that starts the interpreter in a terminal window, and maybe one for IDLE too. Georg ___ 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] get for lists and tuples?
Anthony Baxter wrote: On Wednesday 12 July 2006 03:39, Georg Brandl wrote: Anyway, I'm just testing the waters. If it's not heresy then I'd like to do what I can to make it happen. IMO there's almost no chance this can go into 2.5. almost? I'll go you one better. No way at all will it be in 2.5. And I'd be a firm -1 on adding in to 2.6 as well. It encourages bad coding. You shouldn't be searching lists and tuples like that unless you know what you're doing. NB: I did not support adding that method, only notified the OP of the 2.5 situation. Georg ___ 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] Minor: Unix icons for 2.5?
Martin v. Löwis wrote: Georg Brandl wrote: In case we add a Python .desktop file (as proposed in patch #1353344), we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in is attached. Independent of whether this should be done at all, I have a comment on the patch. Instead of invoking sed, I would use autoconf machinery here +Exec=python_VER_ %f This would become [EMAIL PROTECTED]@@EXEEXT@ %f + sed 's/_VER_/$(VERSION)$(EXE)/' $(srcdir)/Misc/python.desktop.in $(srcdir)/Misc/python.desktop This could go away, and configure should grow AC_CONFIG_FILES(Makefile.pre Modules/Setup.config Misc/python.desktop) Ah, thanks. I'm not very fit with autoconf magic. Georg ___ 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] Long options support
Fredrik Lundh wrote:
Georg Brandl wrote:
I've just closed a bug report wishing for long option support,
pointing to a patch sitting in the patch tracker implementing
this.
Should we accept at least the very common options --help and
--version in 2.5?
Guido pronounced on this in May
Late it comes, but here is a patch for getopt.c implementing
this pronouncement. I think there's no need to wait for 2.6 with it,
or is there?
Cheers,
Georg
Index: Python/getopt.c
===
--- Python/getopt.c (Revision 50599)
+++ Python/getopt.c (Arbeitskopie)
@@ -24,6 +24,9 @@
* [EMAIL PROTECTED]
*---*/
+/* Modified to support --help and --version, as well as /? on Windows
+ * by Georg Brandl. */
+
#include stdio.h
#include string.h
@@ -43,15 +46,35 @@
if (*opt_ptr == '\0') {
- if (_PyOS_optind = argc || argv[_PyOS_optind][0] != '-' ||
- argv[_PyOS_optind][1] == '\0' /* lone dash */ )
+ if (_PyOS_optind = argc)
return -1;
+#ifdef MS_WINDOWS
+ else if (strcmp(argv[_PyOS_optind], /?) == 0) {
+ ++_PyOS_optind;
+ return 'h';
+ }
+#endif
+ else if (argv[_PyOS_optind][0] != '-' ||
+argv[_PyOS_optind][1] == '\0' /* lone dash */ )
+ return -1;
+
else if (strcmp(argv[_PyOS_optind], --) == 0) {
++_PyOS_optind;
return -1;
}
+ else if (strcmp(argv[_PyOS_optind], --help) == 0) {
+ ++_PyOS_optind;
+ return 'h';
+ }
+
+ else if (strcmp(argv[_PyOS_optind], --version) == 0) {
+ ++_PyOS_optind;
+ return 'V';
+ }
+
+
opt_ptr = argv[_PyOS_optind++][1];
}
@@ -62,7 +85,7 @@
if (_PyOS_opterr)
fprintf(stderr, Unknown option: -%c\n, option);
- return '?';
+ return '_';
}
if (*(ptr + 1) == ':') {
@@ -76,7 +99,7 @@
if (_PyOS_opterr)
fprintf(stderr,
Argument expected for the -%c option\n, option);
- return '?';
+ return '_';
}
_PyOS_optarg = argv[_PyOS_optind++];
Index: Modules/main.c
===
--- Modules/main.c (Revision 50599)
+++ Modules/main.c (Arbeitskopie)
@@ -40,7 +40,7 @@
static int orig_argc;
/* command line options */
-#define BASE_OPTS c:dEhim:OQ:StuUvVW:xX
+#define BASE_OPTS c:dEhim:OQ:StuUvVW:xX?
#ifndef RISCOS
#define PROGRAM_OPTS BASE_OPTS
@@ -62,7 +62,7 @@
-c cmd : program passed in as string (terminates option list)\n\
-d : debug output from parser (also PYTHONDEBUG=x)\n\
-E : ignore environment variables (such as PYTHONPATH)\n\
--h : print this help message and exit\n\
+-h : print this help message and exit (also --help)\n\
-i : inspect interactively after running script, (also PYTHONINSPECT=x)\n\
and force prompts, even if stdin does not appear to be a terminal\n\
;
@@ -78,7 +78,7 @@
static char *usage_3 = \
see man page for details on internal buffering relating to '-u'\n\
-v : verbose (trace import statements) (also PYTHONVERBOSE=x)\n\
--V : print the Python version number and exit\n\
+-V : print the Python version number and exit (also --version)\n\
-W arg : warning control (arg is action:message:category:module:lineno)\n\
-x : skip first line of source, allowing use of non-Unix forms of #!cmd\n\
file : program read from script file\n\
@@ -313,6 +313,7 @@
Py_UnicodeFlag++;
break;
case 'h':
+ case '?':
help++;
break;
case 'V':
___
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] Pronouncement on SF #1520294 sought
Barry Warsaw wrote: Just as 2.5b2 was being release, I updated SF patch #1520294: https://sourceforge.net/tracker/index.php? func=detailaid=1520294group_id=5470atid=305470 This fixes the pydoc, inspect, and types modules for built-in types like getset and member descriptors. I'm not sure if Georg has had a chance to look over the latest rev of the patch (which is currently assigned to him). I have now reviewed it and added a comment to the patch. Georg ___ 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] Strategy for converting the decimal module to C
Raymond Hettinger wrote: Aahz wrote: On Tue, Jul 18, 2006, Raymond Hettinger wrote: P.S. The dictionary approach to context objects should likely be abandoned for the C version. If the API has to change a bit, then so be it. Why do you say that? The rest I agree with; seems to me that making a small wrapper for dict access works well, too. I think it was tripping-up the folks working on the C implementation. Georg can speak to it more directly. IIRC, the issue was that the context object exposed a dictionary which a user could update directly and there was no notification back to the surrounding object so it could update an underlying bitfield representation. Yes, that's exactly what the problem was. Working with bitfields internally is fine as long as Python code doesn't want to change the dicts exposed as a wrapper. If the current approach gets in their way, the C implementers should feel free to make an alternate design choice. +1. (cDecimal is an ugly name, but a sound concept) I don't know what progress Mateusz' work has made until now, but he wrote at one time that he would start optimizing as soon as he's certain that it works. Georg ___ 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] Support for PyGetSetDefs in pydoc
Barry Warsaw wrote: Why did I do this instead of trying to hunt down some existing getset or member descriptor? For one thing, there really aren't very good candidates for such objects in the built-in modules. You can't use objects like datetime.timedelta.days in types.py because datetime is not importable early enough for types.py to use it. Even if there were likely candidates, they would be accidents of implementation and it doesn't seem like a good idea to force force some future datetime maintainer to have to fix types.py when she decides that datetime.timedelta.days should be implemented in some other way. A 3rd party extension module doesn't work either because you really need the tie-in from types.py, inspect.py, and pydoc.py. You certainly don't want to go poking new values into types.py from the outside, and besides inspect.py and pydoc.py also need to learn about these fundamental built-in Python types. ISTM the most straightforward approach is to provide these types in a built-in C module, linked into the interpreter so types.py can get access to it as early as it needs to. Also, because the type that these descriptors are attached to cannot be instantiated from Python, they should be quite benign, existing only in order to give type() something to query. Perhaps you could put the objects into _testcapi. That way no new module has to be deployed (is _testcapi installed on every system?) Georg ___ 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] FW: Bug? Certainly a new *behavior* from subprocess in 2.5 on Win32
Kevin Jacobs [EMAIL PROTECTED] wrote: On 7/21/06, *Nick Coghlan* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Delaney, Timothy (Tim) wrote: Looks like there's a bug in Popen.__del__ in 2.5. I'm not in a position to have a look right now. For those not watching python-checkins, a check for is not None has been added before the offending line in Popen.__del__. (by Georg, IIRC) Many thanks for accepting my patch. There remains a potentially related problem in popen2.py, but it may be a lower priority, since most folks should be using subprocess. def __del__(self): # In case the child hasn't been waited on, check if it's done. self.poll(_deadstate=sys.maxint) if self.sts 0: if _active: # Child is still running, keep us alive until we can wait on it. _active.append(self) The is _active check, unless it intendeds to check for either empty or None, should probably be revised to: def __del__(self): # In case the child hasn't been waited on, check if it's done. self.poll(_deadstate=sys.maxint) if self.sts 0: if _active is None: # Child is still running, keep us alive until we can wait on it. _active.append(self) However, there may be a clever reason for doing what is doing that I do not see. There's no reason (I know since I added the check myself ;). Thanks for pointing out that obvious bug. (fixed in rev 50759). Georg ___ 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] remaining issues from Klocwork static analysis
Martin v. Löwis wrote:
Neal Norwitz wrote:
# 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
Not quite sure what it is complaining about, but
else if (PyTuple_Check(closure)) {
Py_XINCREF(closure);
}
looks indeed suspicious: Why do we check for NULL (XINCREF) when
we know closure can't be NULL (Tuple_Check). Drop the X, and see
if the warning goes away
In comparison, the PyFunction_SetDefaults function does check for
NULL, and raises an error in this case. However, since it is a C API function
only, passing NULL is an error anyway.
Georg
___
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] remaining issues from Klocwork static analysis
Neal Norwitz wrote:
On 7/25/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
# 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
Not quite sure what it is complaining about, but
else if (PyTuple_Check(closure)) {
Py_XINCREF(closure);
}
looks indeed suspicious: Why do we check for NULL (XINCREF) when
we know closure can't be NULL (Tuple_Check). Drop the X, and see
if the warning goes away
Yes, I definitely think dropping the X would make the warning go away.
Do we want to check for a NULL pointer and raise an exception? The
docs don't address the issue, so I think if we added a check, ie: if
(closure PyTuple_Check(closure)) and got rid of the X that would be
fine as well.
You'll have to do something about the error message, then, since it
uses closure-ob_type.
Georg
___
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] Release manager pronouncement needed: PEP 302 Fix
Neal Norwitz wrote: What is the behaviour that was added which broke compliance? What is the benefit of the behaviour? sys.path_importer_cache is now used to cache if a real directory exists on the filesystem. Previously, a value of None for a given sys.path entry told find_module that no import hook exist, so it should look for a filesystem directory. Now, the entry is set to True if that directory really exists and to False if it doesn't exist, thus saving quite a few open() calls to files in these not existing dirs. From your description of fixing the problem, it seems there's some risk invovled as it's modiyfing import.c, plus adding new features. What is your recommendation? I would prefer fixing the docs. Importing from filesystem directories is common enough to be special cased. Georg ___ 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] Release manager pronouncement needed: PEP 302 Fix
Armin Rigo wrote: Hi Phillip, On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote: If we don't revert it, there are two ways to fix it. One is to just change PEP 302 so that the behavior is unbroken by definition. :) The other is to actually go ahead and fix it by adding PathImporter and NullImporter types to import.c, along with a factory function on sys.path_hooks to create them. (This would've been the PEP-compliant way to implement the need-for-speed patch.) So, fix by documentation, fix by fixing, or fix by reverting? Which should it be? fix by changing the definition looks like a bad idea to me. The import logic is already extremely complicated and delicate, any change to it is bound to break *some* code somewhere. Though beta1 and beta2 shipped with this change nobody reported any bug that could be linked to it. sys.path_importer_cache is quite an internal thing and most code, even import hooks, shouldn't have to deal with it. Georg ___ 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] uuid test suite failing
The UUID test suite, which wasn't run by regrtest.py until now, is now failing on some buildbots (and my machine). This should be fixed before releasing something. Georg ___ 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] uuid test suite failing
Georg Brandl wrote: The UUID test suite, which wasn't run by regrtest.py until now, is now failing on some buildbots (and my machine). This should be fixed before releasing something. Okay, after fixing the test on my machine (locale issue) it looks like some ifconfigs don't like to be called without arguments. -a seems to be supported everywhere though, so I guess it's reasonable to use that flag on every platform. Any objections? Georg ___ 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] Release manager pronouncement needed: PEP 302 Fix
Phillip J. Eby wrote: sys.path_importer_cache is quite an internal thing Whose behavior is documented in a PEP. Correct. and most code, even import hooks, shouldn't have to deal with it. That doesn't make it unimportant. It's a visible change in specified behavior between Python versions -- precisely the sort of thing that makes people mad at us renegade cowboy Python-dev hackers changing their language for no apparent reason. The strftime thing that recently got hashed to death here was also an internal thing which most code shouldn't have to deal with. This is precisely how these kinds of problems happen. So, this needs to either be documented in the What's New document and PEP 302 at a minimum, or it needs to be reverted, unless somebody wants to bless the feature addition to fix it. I agree with you (now). ;) I'm willing to write code that makes it PEP 302 compliant, if the release manager will bless such an addition. But if that's not acceptable, then somebody needs to produce the necessary documentation updates or revert the patch. A possible third option would be to store the information this is an invalid path somewhere else, that is, an internal dictionary only available to import.c. I will write up docs and update the PEP in any case, if the release manager agrees. Georg ___ 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] Using Python docs
Regarding bug 469773, I think it would be great to have such a document Using Python, containing the manual page and platform- specific hints on how to invoke the interpreter and scripts (e.g. explaining the shebang for Unices). I'd be willing to help write up such a document. Another thing that could be helpful is a list of frequently needed documentation sections, that is, a list of keywords and respective links to topics that are hard to find for newbies, such as the section String formatting or some locations in the reference manual. Georg ___ 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] Py2.5 release schedule
Barry Warsaw wrote: if isinstance(obj, ClassType) which fails in Python 2.5. I actually rewrote it like so: if isinstance(obj, ClassType) or isinstance(obj, type(type)) The second type seems to be superfluous. ;) Georg ___ 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] segmentation fault in Python 2.5b3 (trunk:51066)
Martin v. Löwis wrote: Ralf Schmitt schrieb: I've been trying to port our software to python 2.5. unfortunately I'm getting constantly hit by segfaults. I understand it's unfortunate for you, but it is fortunate for us that you have been trying to port your application before 2.5 was released, and reported the bug when you discovered it. So thanks for reporting it. FWIW, the bug that Thomas found was introduced by patch #1434038, and committed as r42916. I already fixed it locally and will commit as soon as trunk is unfrozen. Georg ___ 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] 2.5 status
Neal Norwitz wrote: Things are getting better, but we still have some really important outstanding issues. PLEASE CONTINUE TESTING AS MUCH AS POSSIBLE. Also, it would be great to use as many tools as possible to find bugs and improve quality. It would be especially nice to run Purify on Windows. I've updated PEP 356 with the current status. The current schedule is: rc 1:August 18, 2006 [planned] final: September 12, 2006 [planned] This somewhat strange schedule is to accommodate availability of people cutting the release. A branch will be made when the release candidate is done. Don't try to rush bug fixes in. Let's try to keep things stable. Keep the doc fixes coming. http://python.org/sf/1523610 - PyArg_ParseTupleAndKeywords potential core dump This one's almost fixed if we can decide what to do with levels. I wrote some time ago: With respect to this bug (which is about stack issues in Python/getargs.c involving misuse of the levels array), I think that we can drop the levels thing completely. It's only there to tell the user which exact item passed as part of a tuple argument cannot be accepted (and only if that function is implemented in C code). As tuple arguments are very rare argument x should be enough to tell the user that something's wrong with that tuple. Georg ___ 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
