Re: [Python-Dev] ImportWarning flood
Guido van Rossum wrote: > On 6/24/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >>> Actually, your application *was* pretty close to being broken a few >>> weeks ago, when Guido wanted to drop the requirement that a package >>> must contain an __init__ file. In that case, "import math" would have >>> imported the directory, and given you an empty package. >> But this change was *not* made, and afaict it is not going to be made. > > Correct. We'll stick with the warning. (At least until Py3k but most > likely also in Py3k.) Perhaps ImportWarning should default to being ignored, the same way PendingDeprecationWarning does? Then -Wd would become 'the one obvious way' to debug import problems, since it would switch ImportWarning on without drowning you in a flood of import diagnostics the way -v can do. Import Errors could even point you in the right direction: >>> import mypackage.foo Traceback (most recent call last): File "", line 1, in ? ImportError: No module named mypackage.foo Diagnostic import warnings can be enabled with -Wd Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
--- "Martin v. L�wis" <[EMAIL PROTECTED]> wrote: > So spend some of the money to come up with an alternate solution for > 2.5b2. With a potential damage of a million dollars, it shouldn't be > too difficult to provide a patch by tomorrow, right? My share is only 10 man hours, payed for by the US government at a scientist salary. :-) A simple patch with a start is attached. Example: % ./python Python 2.5b1 (r25b1:47027, Jun 26 2006, 03:15:33) [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo Traceback (most recent call last): File "", line 1, in ImportError: No module named foo Note that subdirectories are searched for imports only if they contain an __init__.py file. See the section on "Packages" in the Python tutorial for details (http://www.python.org/doc/tut/). >>> The "No module named" message is repeated in these files (2.5b1 tree): ./Demo/imputil/knee.py ./Lib/ihooks.py ./Lib/modulefinder.py ./Lib/xmlcore/etree/ElementTree.py ./Lib/runpy.py ./Lib/imputil.py If there is a consenus, I'd create a new exception ImportErrorNoModule(name) that is used consistently from all places. This would ensure uniformity of the message in the future. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com import_patch Description: 467797280-import_patch ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5b1 Windows install
Aahz wrote: > Has anyone else tried doing an admin install with "compile .py files" > checked? It's causing my install to blow up, but I'd prefer to assume > it's some weird Windows config/bug unless other people also have it, in > which case I'll file an SF report. I tried this deliberately with b1 because it was broken in one of the alphas. It worked fine for me this time (installing over the top of alpha 2). I think there were some bad .py files around that caused the breakage in the earlier alpha - could those have been lying around in your install directory? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
James Y Knight <[EMAIL PROTECTED]> writes: > On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote: > >> --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >>> I think it is safe to say that Twisted is more widely used than >>> anything >>> Google has yet released. Twisted also has a reasonably plausible >>> technical reason to dislike this change. Google has a bunch of >>> engineers >>> who, apparently, cannot remember to create an empty __init__.py >>> file in >>> some directories sometimes. >> >> Simply adding a note to the ImportError message would solve this >> problem "just >> in time": >> > import mypackage.foo >> Traceback (most recent call last): >> File "", line 1, in ? >> ImportError: No module named mypackage.foo >> Note that subdirectories are searched for imports only if they >> contain an >> __init__.py file: http://www.python.org/doc/essays/packages.html >> > > I also dislike the warning solution. Making the ImportError message > more verbose seems like a much nicer solution. Me too. ImportError: no module named foo Note: directory foo/ with no __init__.py not imported would be nice, but I don't know how hard it would be to achieve. I'm scared of the import.c. Cheers, mwh -- While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work.-- C Hacking -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
On Mon, Jun 26, 2006 at 08:29:49AM +0200, "Martin v. Löwis" wrote: > (read some email archives > to find out what the original problem was). People at Google don't read manuals? --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
Nick Coghlan wrote: > Perhaps ImportWarning should default to being ignored, the same way > PendingDeprecationWarning does? > > Then -Wd would become 'the one obvious way' to debug import problems +1 -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple Switch statement
On 6/25/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Those were not empty words. I provided two non-trivial worked-out examples > taken from sre_constants.py and opcode.py. Nick provided a third example from > decimal.py. In all three cases, the proposal was applied effortlessly > resulting > in improved readability and speed. I hope you hold other proposals to the > same > standard. I appreciate your attempts to help us avoid overengineering this so I'm trying to find some real world examples of a pygame event loop that really show the benefit of supporting named constants and expressions. I may mess up irrelevant details, but the primary case looks something like the following (perhaps Pete Shinners could point us to a good example loop online somewhere): for event in pygame.event.get(): if event.type == pygame.KEYDOWN: ... elif event.type == pygame.KEYUP: ... elif event.type == pygame.QUIT: ... Here all the event types are integers, but are clearly meaningless as integers instead of an enumeration. I'd be sorely disappointed with the addition of a switch statement that couldn't support this as something like the following: for event in pygame.event.get(): switch event.type: case pygame.KEYDOWN: ... case pygame.KEYUP: ... case pygame.QUIT: ... I'd also generally like these to be captured like default values to function arguments are. The only argument against this that stuck with me is over the fact that locals cannot be used. If literals-only has a chance, than I would hope that every hashable non-local capturable expression should be at least as welcome. In summary I'm +0 on switch, but -1 on literal-only cases. I also would like to see a way to use 'is' instead of (or inaddition to) '==' for the comparison, but I don't have any use cases behind this. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
A.M. Kuchling wrote: > On Mon, Jun 26, 2006 at 08:29:49AM +0200, "Martin v. Löwis" wrote: >> (read some email archives >> to find out what the original problem was). > > People at Google don't read manuals? The documentation of how imports actually work isn't that easy to find? Guido's package essay on python.org and PEP 302 seem to cover the topic pretty well between them, but neither of them is part of the normal documentation. The situation shares some unfortunate similarities with that of the new-style class documentation - it's documented, just not in the places you might initially expect :( Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple Switch statement
On 6/26/06, Michael Urman <[EMAIL PROTECTED]> wrote: > I also would like to see a way to use 'is' instead of (or inaddition > to) '==' for the comparison, but I don't have any use cases behind > this. I've thought about this a bit, and I think it's a red herring. I've seen some places where 'is' is used to compare constants (e.g. sre_compare.py). But I'm pretty sure that this is a speed hack that can safely be forgotten once (if ever) we have a switch statement. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pypy-0.9.0: stackless, new extension compiler
Hi all! Michael Hudson wrote: > The PyPy development team has been busy working and we've now packaged > our latest improvements, completed work and new experiments as > version 0.9.0, our fourth public release. Unfortunately the download links for the release tarballs did not work until very recently. They are now working though. You can download the 0.9 release of PyPy under: http://codespeak.net/download/pypy/pypy-0.9.0.tar.bz2 http://codespeak.net/download/pypy/pypy-0.9.0.tar.gz http://codespeak.net/download/pypy/pypy-0.9.0.zip For detailed notes about how to get started into the world of PyPy see here: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html Sorry for the fuss and cheers, Carl Friedrich Bolz ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple Switch statement
Michael Urman wrote: > I'm trying to find some real world examples of a pygame event loop > >that really show the benefit of supporting named constants and >expressions. I may mess up irrelevant details, but the primary case >looks something like the following (perhaps Pete Shinners could point >us to a good example loop online somewhere): > >for event in pygame.event.get(): >if event.type == pygame.KEYDOWN: ... >elif event.type == pygame.KEYUP: ... >elif event.type == pygame.QUIT: ... > >Here all the event types are integers, but are clearly meaningless as >integers instead of an enumeration. I'd be sorely disappointed with >the addition of a switch statement that couldn't support this as >something like the following: > >for event in pygame.event.get(): >switch event.type: >case pygame.KEYDOWN: ... >case pygame.KEYUP: ... >case pygame.QUIT: ... > > With the simplified proposal, this would be coded with an inverse mapping: for event in pygame.event.get(): switch eventmap[event.type]: case 'KEYDOWN': ... case 'KEYUP': ... case 'QUIT': ... Hopefully, the static() proposal will work-out and the mapping won't be necessary. If it does work-out, you'll also get more error-checking than you get with either the if-elif version or the simplified switch-case. > >I also would like to see a way to use 'is' instead of (or inaddition >to) '==' for the comparison, but I don't have any use cases behind >this. > > If speed is the goal, this isn't necessary. The internal equality check takes a shortcut in the event of an identity match. OTOH, if the goal is having several distinct cases that are equal but not identical, then that's another story. I suggest leave the initial switch syntax as simple as possible and just switch on id(object). Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
Benji York <[EMAIL PROTECTED]> writes: > Nick Coghlan wrote: >> Perhaps ImportWarning should default to being ignored, the same way >> PendingDeprecationWarning does? >> >> Then -Wd would become 'the one obvious way' to debug import problems > > +1 I'm not sure what this would achieve -- people who don't know enough about Python to add __init__.py files aren't going to know enough to make suppressed-by-default warnings not suppressed. The more I think about it, the more I like the idea of saying something when an import fails only because of a missing __init__.py file. I guess I should try to implement it... Cheers, mwh -- I also feel it essential to note, [...], that Description Logics, non-Monotonic Logics, Default Logics and Circumscription Logics can all collectively go suck a cow. Thank you. -- http://advogato.org/person/Johnath/diary.html?start=4 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
Michael Hudson wrote: > Benji York <[EMAIL PROTECTED]> writes: > >>Nick Coghlan wrote: >> >>>Perhaps ImportWarning should default to being ignored, the same way >>>PendingDeprecationWarning does? >>> >>>Then -Wd would become 'the one obvious way' to debug import problems >> >>+1 > > I'm not sure what this would achieve I'm more concerned with what it shouldn't achieve (changing the rules in an annoying and disruptive way). > The more I think about it, the more I like the idea of saying > something when an import fails only because of a missing __init__.py > file. I totally agree! I just doubted that approach would be appealing [to Guido] when the choice of adding warnings had already been made. -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3103: A Switch/Case Statement
I've written a new PEP, summarizing (my reaction to) the recent discussion on adding a switch statement. While I have my preferences, I'm trying to do various alternatives justice in the descriptions. The PEP also introduces some standard terminology that may be helpful in future discussions. I'm putting this in the Py3k series to gives us extra time to decide; it's too important to rush it. http://www.python.org/dev/peps/pep-3103/ Feedback (also about misrepresentation of alternatives I don't favor) is most welcome, either to me directly or as a followup to this post. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On Mon, 26 Jun 2006, Guido van Rossum wrote: > I've written a new PEP, summarizing (my reaction to) the recent > discussion on adding a switch statement. While I have my preferences, > I'm trying to do various alternatives justice in the descriptions. Thanks for writing this up! The section that most draws my attention is "Semantics", and i guess it isn't a surprise to either of us that you had the most to say from the perspective you currently support (School II). :) Let me suggest a couple of points to add: - School I sees trouble in the approach of pre-freezing a dispatch dictionary because it places a new and unusual burden on the programmer to understand exactly what kinds of case values are allowed to be frozen and when the case values will be frozen. - In the School II paragraph you say "Worse, the hash function might have a bug or a side effect; if we generate code that believes the hash, a buggy hash might generate an incorrect match" -- but that is primarily a criticism of the School II approach, not of the School I approach as you have framed it. It's School II that mandates that the hash be the truth. (It looks to me like what you're actually criticizing here is based on some assumptions about how you think School I might be implemented, and having taken School I a number of steps down that (unexplained) road you then see problems with it.) Also, why is the discussion of School II mostly an argument against School I? What about describing the advantages of each school? -- ?!ng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Misleading error message from PyObject_GenericSetAttr
On 6/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 6/14/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > > ... It would be better to change the message > > to "'Foo' object has only read-only attributes (assign to .bar)" as in > > the case tp_setattro == tp_setattr == NULL in PyObject_SetAttr . > > I agree. Can you submit a patch to SF please? > Please see: https://sourceforge.net/tracker/index.php?func=detail&aid=1512942&group_id=5470&atid=305470 I've tested the patch by setting tp_setattr to 0 in Xxo_Type. With the patch: >>> import xx >>> x = xx.new() >>> x.a = 2 Traceback (most recent call last): File "", line 1, in AttributeError: 'xxmodule.Xxo' object has only read-only attributes (assign to .a) >>> del x.a Traceback (most recent call last): File "", line 1, in AttributeError: 'xxmodule.Xxo' object has only read-only attributes (del .a) Note that this log reveals a small inaccuracy in xxmodule.c : the module name is "xx," but Xxo type name is "xxmodule.Xxo." Should I submit a patch fixing that? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Mon, 26 Jun 2006, Guido van Rossum wrote: > > I've written a new PEP, summarizing (my reaction to) the recent > > discussion on adding a switch statement. While I have my preferences, > > I'm trying to do various alternatives justice in the descriptions. > > Thanks for writing this up! > > The section that most draws my attention is "Semantics", and i guess > it isn't a surprise to either of us that you had the most to say > from the perspective you currently support (School II). :) Let me > suggest a couple of points to add: > > - School I sees trouble in the approach of pre-freezing a dispatch > dictionary because it places a new and unusual burden on the > programmer to understand exactly what kinds of case values are > allowed to be frozen and when the case values will be frozen. Can you please edit the PEP yourself to add this? That will be most efficient. > - In the School II paragraph you say "Worse, the hash function > might have a bug or a side effect; if we generate code that > believes the hash, a buggy hash might generate an incorrect > match" -- but that is primarily a criticism of the School II > approach, not of the School I approach as you have framed it. > It's School II that mandates that the hash be the truth. You seem to misunderstand what I'm saying or proposing here; admittedly I think I left something out. With school I, if you want to optimize using a hash table (as in PEP 275 Solution 1) you have to catch and discard exceptions in hash(), and a bug in hash() can still lead this optimization astray: if A == B but hash(A) != hash(B), "switch A: // case B: ... // else: ..." may falsely take the else branch, thereby causing a hard-to-debug difference between optimized and unoptimized code. With school II, exceptions in hash() aren't caught or discarded; a bug in hash() leads to the same behavior as optimized school I, but the bug is not dependent on the optimization level. > (It looks to me like what you're actually criticizing here is > based on some assumptions about how you think School I might > be implemented, and having taken School I a number of steps > down that (unexplained) road you then see problems with it.) Right. School I appears just as keen as school II to use hashing to optimize things, but isn't prepared to pay the price in semantics; but I believe the optimizations are impossible to behave completely identically to the unoptimized code (not even counting side effects in hash() or __eq__()) so I believe the position that the optimized version is equivalent to the unoptimized "official semantics" according to school I is untenable. > Also, why is the discussion of School II mostly an argument against > School I? What about describing the advantages of each school? School II has the advantage of not incurring the problems I see with school I, in particular catching and discarding exceptions in hash() and differences between optimized and unoptimized code. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Switch statement
In http://mail.python.org/pipermail/python-dev/2006-June/066475.html Nick Coghlan wrote: > (Unlike Jim, I have no problems with restricting switch statements to > hashable objects and building the entire jump table at once - if what you want > is an arbitrary if-elif chain, then write one!) I haven't been clear. I don't object to building the entire table at once. I object to promising that this will happen, which forbids other implementations from using certain optimizations. I would prefer something like: There is no guarantee on how often or when the case statements will be evaluated, except that it will be after the enclosing scope exists and before the relevant test is needed. If a case expression has side effects, the behavior with respect to these side effects is explicitly undefined. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > In http://mail.python.org/pipermail/python-dev/2006-June/066475.html > Nick Coghlan wrote: > > > (Unlike Jim, I have no problems with restricting switch statements to > > hashable objects and building the entire jump table at once - if what you > > want > > is an arbitrary if-elif chain, then write one!) > > I haven't been clear. I don't object to building the entire table at > once. I object to promising that this will happen, which forbids > other implementations from using certain optimizations. > > I would prefer something like: > > There is no guarantee on how often or when the case statements will be > evaluated, except that it will be after the enclosing scope exists and > before the relevant test is needed. If a case expression has side > effects, the behavior with respect to these side effects is explicitly > undefined. This is the kind of language that makes C++ and Fortrans standards so difficult to interpret. I like Python's rules to be simple, and I prefer to occasionally close off a potential optimization path in the sake of simplicity. For example, I like left-to-right evaluation of operands and function arguments. The C++/Fortran style weasel words to allow optimizers to do sneaky stuff aren't really wort the trouble they can create in Python, where even the best optimization produces code that's much slower than C. In practice, most users observe the behavior of the one compiler they use, and code to that "standard"; so allowing different compilers or optimization levels to do different things when functions have side effects is just asking for surprises. In Python, the big speedups come from a change in algorithm. That's why it's imprtant to me that switch be dict-based (O(1)), as an alternative to an if/elif chain (O(N)). (The implementation doesn't have to use a regular dict, though; the important part is that it's based on hash() and __eq__().) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On Mon, 26 Jun 2006, Guido van Rossum wrote: > Can you please edit the PEP yourself to add this? That will be most efficient. I've done so, and tried to clarify the next line to match (see below). > With school I, if you want to > optimize using a hash table (as in PEP 275 Solution 1) you have to > catch and discard exceptions in hash(), and a bug in hash() can still > lead this optimization astray Right. As written, the problem "a buggy hash might generate an incorrect match" is not specific to School I; it's a problem with any approach that is implemented by a hash lookup. School II is necessarily implemented this way; School I might or might not be. So i think the part that says: the hash function might have a bug or a side effect; if we generate code that believes the hash, a buggy hash might generate an incorrect match doesn't belong there, and i'd like your consent to remove it. On the other hand, this criticism: if we generate code that catches errors in the hash to fall back on an if/elif chain, we might hide genuine bugs is indeed specific to School I + hashing. > Right. School I appears just as keen as school II to use hashing to > optimize things, but isn't prepared to pay the price in semantics; Ok. Then there's an inconsistency with the definition of School I: School I wants to define the switch statement in term of an equivalent if/elif chain To clear this up, i've edited the first line of the School II paragraph, which previously said: School II sees nothing but trouble in that approach It seems clear that by "that approach" you meant "trying to achieve if/elif semantics while using hash optimization" rather than the more general definition of School I that was given. I believe there are a few voices here (and i count myself among them) that consider the semantics more important than the speed and are in School I but aren't treating hash optimization as the quintessence of 'switch', and we shouldn't leave them out. -- ?!ng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 35, Issue 143
lt;[EMAIL PROTECTED]> wrote: > > So spend some of the money to come up with an > alternate solution for > > 2.5b2. With a potential damage of a million > dollars, it shouldn't be > > too difficult to provide a patch by tomorrow, > right? > > My share is only 10 man hours, payed for by the US > government at a scientist > salary. :-) > > A simple patch with a start is attached. Example: > > % ./python > Python 2.5b1 (r25b1:47027, Jun 26 2006, 03:15:33) > [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2 > Type "help", "copyright", "credits" or "license" for > more information. > >>> import foo > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named foo > Note that subdirectories are searched for imports > only if they contain an > __init__.py file. See the section on "Packages" in > the Python tutorial for > details (http://www.python.org/doc/tut/). > >>> > > > The "No module named" message is repeated in these > files (2.5b1 tree): > > ./Demo/imputil/knee.py > ./Lib/ihooks.py > ./Lib/modulefinder.py > ./Lib/xmlcore/etree/ElementTree.py > ./Lib/runpy.py > ./Lib/imputil.py > > If there is a consenus, I'd create a new exception > ImportErrorNoModule(name) > that is used consistently from all places. This > would ensure uniformity of the > message in the future. > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > -- next part -- > A non-text attachment was scrubbed... > Name: import_patch > Type: application/octet-stream > Size: 1090 bytes > Desc: 467797280-import_patch > Url : > http://mail.python.org/pipermail/python-dev/attachments/20060626/ce3bbfec/attachment-0001.obj > > > -- > > Message: 3 > Date: Mon, 26 Jun 2006 20:46:57 +1000 > From: Nick Coghlan <[EMAIL PROTECTED]> > Subject: Re: [Python-Dev] 2.5b1 Windows install > To: Aahz <[EMAIL PROTECTED]> > Cc: Python-Dev > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > Aahz wrote: > > Has anyone else tried doing an admin install with > "compile .py files" > > checked? It's causing my install to blow up, but > I'd prefer to assume > > it's some weird Windows config/bug unless other > people also have it, in > > which case I'll file an SF report. > > I tried this deliberately with b1 because it was > broken in one of the alphas. > It worked fine for me this time (installing over the > top of alpha 2). > > I think there were some bad .py files around that > caused the breakage in the > earlier alpha - could those have been lying around > in your install directory? > > Cheers, > Nick. > === message truncated === ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 35, Issue 143
;iso-8859-1">> --- "Martin v. L???wis" <[EMAIL PROTECTED] > wrote:> > So spend some of the money to come up with an> alternate solution for> > 2.5b2. With a potential damage of a million> dollars, it shouldn't be> > too difficult to provide a patch by tomorrow, > right?>> My share is only 10 man hours, payed for by the US> government at a scientist> salary. :-)>> A simple patch with a start is attached. Example:>> % ./python > Python 2.5b1 (r25b1:47027, Jun 26 2006, 03:15:33)> [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2> Type "help", "copyright", "credits" or "license" for> more information. > >>> import foo> Traceback (most recent call last):> File "", line 1, in > ImportError: No module named foo> Note that subdirectories are searched for imports > only if they contain an> __init__.py file. See the section on "Packages" in> the Python tutorial for> details (http://www.python.org/doc/tut/ ).> >>>>>> The "No module named" message is repeated in these> files (2.5b1 tree):>> ./Demo/imputil/knee.py> ./Lib/ihooks.py> ./Lib/modulefinder.py > ./Lib/xmlcore/etree/ElementTree.py> ./Lib/runpy.py> ./Lib/imputil.py>> If there is a consenus, I'd create a new exception> ImportErrorNoModule(name)> that is used consistently from all places. This > would ensure uniformity of the> message in the future.>> __> Do You Yahoo!?> Tired of spam? Yahoo! Mail has the best spam> protection around > http://mail.yahoo.com> -- next part --> A non-text attachment was scrubbed...> Name: import_patch> Type: application/octet-stream > Size: 1090 bytes> Desc: 467797280-import_patch> Url :>http://mail.python.org/pipermail/python-dev/attachments/20060626/ce3bbfec/attachment-0001.obj >>> -->> Message: 3> Date: Mon, 26 Jun 2006 20:46:57 +1000> From: Nick Coghlan <[EMAIL PROTECTED] >> Subject: Re: [Python-Dev] 2.5b1 Windows install> To: Aahz <[EMAIL PROTECTED]>> Cc: Python-Dev <[email protected] >> Message-ID: <[EMAIL PROTECTED]>> Content-Type: text/plain; charset=ISO-8859-1;> format=flowed>> Aahz wrote:> > Has anyone else tried doing an admin install with > "compile .py files"> > checked? It's causing my install to blow up, but> I'd prefer to assume> > it's some weird Windows config/bug unless other> people also have it, in > > which case I'll file an SF report.>> I tried this deliberately with b1 because it was> broken in one of the alphas.> It worked fine for me this time (installing over the> top of alpha 2). >> I think there were some bad .py files around that> caused the breakage in the> earlier alpha - could those have been lying around> in your install directory?>> Cheers, > Nick.>=== message truncated ===___Python-Dev mailing [email protected] http://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problems building Python on OSX 10.4.6?
[Bleh, sorry about the subject line on my first post. Forgot to edit it before I sent.] Hi all, I have been trying for some time to build Python 2.4.x from source on OS X 10.4.6. I've found *numerous* postings on various mailing lists and web pages documenting the apparently well-known problems of doing so. Various problems arise either in the ./configure step, with configure arguments that don't work, or in the compile, or in my case in the link step with libtool. The configure options I'm using are the following: --enable-framework --with-pydebug --with-debug=yes --prefix=/usr --with-dyld --program-suffix=.exe --enable-universalsdk I've managed to get past configure and can compile everything, but in the link I get the error "Undefined symbols: ___eprintf" . This appears to have something to do with dynamic library loading not properly pulling in libgcc. I've tried with -lgcc in the LD options, but that produces a configure error "cannot compute sizeof...". If I remove "--enable-framework" the complete build works, but unfortunately that is the one critical element that I need. The web pages I've found referring to this range from 2001 to present -- still apparently everybody is having problems with this. Does *anybody* here have Python built from source on this OS? Jeff ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
Michael Hudson wrote: > Benji York <[EMAIL PROTECTED]> writes: > >> Nick Coghlan wrote: >>> Perhaps ImportWarning should default to being ignored, the same way >>> PendingDeprecationWarning does? >>> >>> Then -Wd would become 'the one obvious way' to debug import problems >> >> +1 > > I'm not sure what this would achieve -- people who don't know enough > about Python to add __init__.py files aren't going to know enough to > make suppressed-by-default warnings not suppressed. The change was prompted by developers (specifically, Google developers). Developers should be able to put -Wd in their automated build scripts. > The more I think about it, the more I like the idea of saying > something when an import fails only because of a missing __init__.py > file. I guess I should try to implement it... This is by far and away my preference as well (stating which directories may have been importable if they had __init__.py in the exception) but it was shot down in the original discussion. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Mon, 26 Jun 2006, Guido van Rossum wrote: > > Can you please edit the PEP yourself to add this? That will be most > > efficient. > > I've done so, and tried to clarify the next line to match (see below). > > > With school I, if you want to > > optimize using a hash table (as in PEP 275 Solution 1) you have to > > catch and discard exceptions in hash(), and a bug in hash() can still > > lead this optimization astray > > Right. As written, the problem "a buggy hash might generate an > incorrect match" is not specific to School I; it's a problem with > any approach that is implemented by a hash lookup. School II is > necessarily implemented this way; School I might or might not be. > So i think the part that says: > > the hash function might have a bug or a side effect; if we > generate code that believes the hash, a buggy hash might > generate an incorrect match > > doesn't belong there, and i'd like your consent to remove it. I'd rather keep it, but clarify that school II considers the outcome of the hash() the official semantics, while school I + dict-based optimization would create optimized code that doesn't match the language specs. My point being that not following your own specs is a much more severe sin than trusting a buggy hash(). If hash() is buggy, school II's official spec means that the bug affects the outcome, and that's that; but because school I specifies the semantics as based on an if/elif chain, using a buggy hash() means not following the spec. If we choose school I, a user may assume that a buggy hash() doesn't affect the outcome because it's defined in terms of == tests only. > On the other hand, this criticism: > > if we generate code that catches errors in the hash to > fall back on an if/elif chain, we might hide genuine bugs > > is indeed specific to School I + hashing. Right. > > Right. School I appears just as keen as school II to use hashing to > > optimize things, but isn't prepared to pay the price in semantics; > > Ok. Then there's an inconsistency with the definition of School I: > > School I wants to define the switch statement in term of > an equivalent if/elif chain > > To clear this up, i've edited the first line of the School II > paragraph, which previously said: > > School II sees nothing but trouble in that approach > > It seems clear that by "that approach" you meant "trying to achieve > if/elif semantics while using hash optimization" rather than the > more general definition of School I that was given. Right. Thanks for the clarification; indeed, the only problem I have with the "clean" school I approach (no hash-based optimization) is that there's no optimization, and we end up once more having to tweak the ordering of the cases based on our expectation of their frequency (which may not match reality). Most school I proponents (perhaps you're the only exception) have claimed that optimization is desirable, but added that it would be easy to add hash-based optimization. IMO it's not so easy in the light of various failure modes of hash(). (A possible solution would be to only use hashing if the expression's type is one of a small set of trusted builtins, and not a subclass; we can trust int.__hash__, str.__hash__ and a few others.) > I believe > there are a few voices here (and i count myself among them) that > consider the semantics more important than the speed and are in > School I but aren't treating hash optimization as the quintessence > of 'switch', and we shouldn't leave them out. This is an important distinction; thanks for pointing it out. Perhaps we can introduce school Ia and Ib, where Ia is "clean but unoptimized" and Ib is "if/elif with hash-based optimization desirable when possible". Another distinction between the two schools is that school Ib will have a hard time optimizing switches based on named constants. I don't believe that the "callback if variable affecting expression value is ever assigned to" approach will work. School II is definitely more pragmatist; I really don't see much wrong with defining that it works a certain way, which is not exactly what you would expect but has the same effect in *most* common cases, and then explaining odd behavior in various corner cases out of that way, as long as I don't care about those corner cases. This is pretty much how I defend the semantics of default parameter values -- it doesn't matter that they are computed at function definition time instead of call time as long as you only use immutable constants (which could be named constants as long as they're immutable), which is the only use case I care about. There are many other examples of odd Python semantics that favor a relatively simple implementation and glorify that implementation as the official semantics. I find this much preferable over weasel words a la traditional language standards which give optimizers a lot of leeway at the cost of d
Re: [Python-Dev] pypy-0.9.0: stackless, new extension compiler
Congratulations! [EMAIL PROTECTED] wrote on 25/06/2006 13:07:01: > The PyPy development team has been busy working and we've now packaged > our latest improvements, completed work and new experiments as > version 0.9.0, our fourth public release. > > The highlights of this fourth release of PyPy are: > > **implementation of "stackless" features** > We now support the larger part of the interface of the original > Stackless Python -- see http://www.stackless.com for more. A > significant part of this is the pickling and unpickling of a running > tasklet. > > These features, especially the pickling, can be considered to be a > "technology preview" -- they work, but for example the error handling > is a little patchy in places. > > **ext-compiler** > The "extension compiler" is a new way of writing a C extension for > CPython and PyPy at the same time. For more information, see its > documentation: http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html > > **rctypes** > Most useful in combination with the ext-compiler is the fact that our > translation framework can translate code that uses the > standard-in-Python-2.5 ctypes module. See its documentation for more: > http://codespeak.net/pypy/dist/pypy/doc/rctypes.html > > **framework GCs** > PyPy's interpreter can now be compiled to use a garbage collector > written in RPython. This added control over PyPy's execution makes the > implementation of new and interesting features possible, apart from > being a significant achievement in its own right. > > **__del__/weakref/__subclasses__** > The PyPy interpreter's compatibility with CPython continues improves: > now we support __del__ methods, the __subclasses__ method on types and > weak references. We now pass around 95% of CPython's core tests. > > **logic space preview** > This release contains the first version of the logic object space, > which will add logical variables to Python. See its docs for more: > http://codespeak.net/pypy/dist/pypy/doc/howto-logicobjspace-0.9.html > > **high level backends preview** > This release contains the first versions of new backends targeting high > level languages such as Squeak and .NET/CLI and updated versions of the > JavaScript and Common Lisp backends. They can't compile the PyPy > interpreter yet, but they're getting there... > > **bugfixes, better performance** > As you would expect, performance continues to improve and bugs continue > to be fixed. The performance of the translated PyPy interpreter is > 2.5-3x times faster than 0.8 (on richards and pystone), and is now > stable enough to be able to run CPython's test suite to the end. > > **testing refinements** > py.test, our testing tool, now has preliminary support for doctests. > We now run all our tests every night, and you can see the summary at: > http://snake.cs.uni-duesseldorf.de/pypytest/summary.html > > What is PyPy (about)? > > > PyPy is a MIT-licensed research-oriented reimplementation of Python > written in Python itself, flexible and easy to experiment with. It > translates itself to lower level languages. Our goals are to target a > large variety of platforms, small and large, by providing a > compilation toolsuite that can produce custom Python versions. > Platform, memory and threading models are to become aspects of the > translation process - as opposed to encoding low level details into > the language implementation itself. Eventually, dynamic optimization > techniques - implemented as another translation aspect - should become > robust against language changes. > > Note that PyPy is mainly a research and development project and does > not by itself focus on getting a production-ready Python > implementation although we do hope and expect it to become a viable > contender in that area sometime next year. > > PyPy is partially funded as a research project under the European > Union's IST programme. > > Where to start? > - > > Getting started:http://codespeak.net/pypy/dist/pypy/doc/getting- > started.html > > PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ > > PyPy Homepage: http://codespeak.net/pypy/ > > The interpreter and object model implementations shipped with the 0.9 > version can run on their own and implement the core language features > of Python as of CPython 2.4. However, we still do not recommend using > PyPy for anything else than for education, playing or research > purposes. > > Ongoing work and near term goals > - > > The Just-in-Time compiler and other performance improvements will be one of > the main topics of the next few months' work, along with finishing the > logic object space. > > Project Details > --- > > PyPy has been developed durin
[Python-Dev] enhancements for uuid module
Hi Ka-Ping,
I would like to propose two enhancements for your uuid module in Python 2.5:
1) I've written functions to retrieve the MAC address that do not depend
on running external programs. Please see the attached file.
2) In order to reduce the pickle footprint of UUIDs I would add a
__reduce__ method to class UUID like
def __reduce__(self):
return (uuid, (self.int,))
together with a helper function (at module level) like
def uuid(i):
return UUID(int=i)
Please feel free to use the supplied code.
Cheers
Michael
# helper functions for determining host id
def _getMACAddrPosix(api=None):
import array, fcntl, socket
if api == 'cygwin':
# doesn't work currently due to a bug in cygwin python:
# cygwins SIOCGIF* are unsigned int greater than sys.maxint
# but fcntl.ioctl tries to convert them to an int
SIOCGIFCONF = 0x80087364L
SIOCGIFNAME = 0 # not defined on cygwin
SIOCGIFHWADDR = 0x80207369L
else: # default SIOCGIF* (taken from Linux)
SIOCGIFCONF = 0x8912
SIOCGIFNAME = 0x8910
SIOCGIFHWADDR = 0x8927
# function to get MAC address
def getHwAddr(ifName):
ifReq = _struct.pack('16s16s', ifName, '')
ifReq = fcntl.ioctl(sock, SIOCGIFHWADDR, ifReq)
ifn, ift, ifah, ifal = _struct.unpack('>16sHHL8x', ifReq)
return (long(ifah)<<32) + ifal
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
try:
# first try SIOCGIFCONF
try:
maxIfs = 32
lenIfReq = 32 # length of struct ifreq
lenBuf = lenIfReq * maxIfs
buf = array.array('c', '\0' * lenBuf)
ifConf = _struct.pack('iP', lenBuf, buf.buffer_info()[0])
ifConf = fcntl.ioctl(sock, SIOCGIFCONF, ifConf)
lenBuf, ptr = _struct.unpack('iP', ifConf)
nIfs = lenBuf // lenIfReq
for i in range(nIfs):
offset = i * lenIfReq
ifReq = buf.tostring()[offset : offset + lenIfReq]
ifName, fill = _struct.unpack("16s16s", ifReq)
if ifName != 'lo':
macAddr = getHwAddr(ifName)
if macAddr != 0:
return macAddr
except:
pass
# next try SIOCGIFNAME
ifIdx = 1
try:
assert SIOCGIFNAME != 0 # SIOCGIFNAME defined?
while True:
ifReq = _struct.pack('16si12x', '', ifIdx)
ifReq = fcntl.ioctl(sock, SIOCGIFNAME, ifReq)
ifName, fill = _struct.unpack('16s16s', ifReq)
if ifName != 'lo':
macAddr = getHwAddr(ifName)
if macAddr != 0:
return macAddr
ifIdx += 1
except:
pass
# next try to get if list via procfs
try:
devs = open('/proc/net/dev', 'r')
try:
for l in devs:
i = l.find(':')
if 0 < i <= 16:
ifName = l[:i].strip()
if ifName != 'lo':
macAddr = getHwAddr(ifName)
if macAddr != 0:
return macAddr
finally:
devs.close()
except:
pass
finally:
sock.close()
return None
def _getMACAddrLinux():
try:
sysnet = '/sys/class/net'
for ifn in _os.listdir(sysnet):
fAddr = open(_os.path.join(sysnet, ifn, 'address'))
sAddr = fAddr.readline().replace(':','').strip()
if len(sAddr) == 12:
macAddr = long("0x%s"%sAddr, 16)
if macAddr != 0:
return macAddr
except:
pass
return _getMACAddrPosix()
def _getMACAddrWin():
try:
from ctypes import Structure, windll, sizeof
from ctypes import POINTER, byref, SetPointerType
from ctypes import c_ulonglong, c_ulong, c_uint, c_ubyte, c_char
MAX_ADAPTER_DESCRIPTION_LENGTH = 128
MAX_ADAPTER_NAME_LENGTH = 256
MAX_ADAPTER_ADDRESS_LENGTH = 8
class IP_ADDR_STRING(Structure):
pass
LP_IP_ADDR_STRING = POINTER(IP_ADDR_STRING)
IP_ADDR_STRING._fields_ = [
("next", LP_IP_ADDR_STRING),
("ipAddress", c_char * 16),
("ipMask", c_char * 16),
("context", c_ulong)]
class IP_ADAPTER_INFO (Structure):
pass
LP_IP_ADAPTER_INFO = POINTER(IP_ADAPTER_INFO)
IP_ADAPTER_INFO._fields_ = [
("next", LP_IP_ADAPTER_INFO),
("comboIndex", c_ulong),
("adapterName", c_char * (MAX_ADAPTER_NAME_LENGTH + 4)),
("description", c_char * (MAX_ADAPTER_DESCRIPTION_LENGTH + 4)),
("addressLength", c_uint),
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On Mon, 26 Jun 2006, Guido van Rossum wrote: > Most school I proponents (perhaps you're the only exception) have > claimed that optimization is desirable, but added that it would be > easy to add hash-based optimization. IMO it's not so easy in the light > of various failure modes of hash(). (A possible solution would be to > only use hashing if the expression's type is one of a small set of > trusted builtins, and not a subclass; we can trust int.__hash__, > str.__hash__ and a few others.) That's a good idea! At first glance, it seems like that could lead to a plausible compromise. -- ?!ng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] School IIb?
Here's a possible adjustment to the School-II approach that i think avoids the issues i've been raising, while giving the desired O(n)-to-O(1) speedup in common situations. It's basically School-II dispatch, plus a check: On compilation, freeze any cases that meet the School-II conditions and have a trustworthy __hash__ method into a dictionary. At runtime, when the dictionary yields a hit, check if the case expression yields a different value. If the value has changed, use if/elif processing. In most cases the case-equality check will be cheap (e.g. an attribute lookup), but it would allow us to establish for sure that the switch value really matches the case value when we branch to a particular case, so we'd not be so vulnerable to __hash__ misbehaving, which seems to be your main source of discomfort with if/elif semantics. -- ?!ng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] School IIb?
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > Here's a possible adjustment to the School-II approach that i think > avoids the issues i've been raising, while giving the desired > O(n)-to-O(1) speedup in common situations. It's basically School-II > dispatch, plus a check: > > On compilation, freeze any cases that meet the School-II conditions > and have a trustworthy __hash__ method into a dictionary. At runtime, > when the dictionary yields a hit, check if the case expression yields > a different value. If the value has changed, use if/elif processing. > > In most cases the case-equality check will be cheap (e.g. an attribute > lookup), but it would allow us to establish for sure that the switch > value really matches the case value when we branch to a particular > case, so we'd not be so vulnerable to __hash__ misbehaving, which > seems to be your main source of discomfort with if/elif semantics. I don't see how this can work for named constants, since their value is unknown at compilation time. I also don't like that you apparently are fine with all sort of reorderings of the evaluation of the cases (the matching case is always evaluated redundantly; other cases may be evaluate if the optimization failed). hash() misbehaving is not my main source of discomfort. It's the messiness of trying to define rules that are as flexible as needed for optimization and yet claiming to maintain the strict if/elif-chain semantics. There's no messiness needed in the def-time-freeze rule; the optimizer can't screw it, because the rule is so much simpler. The code generator for optimized school I would be a beast. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] School IIb?
At 03:52 PM 6/26/2006 -0700, Guido van Rossum wrote: >It's the >messiness of trying to define rules that are as flexible as needed for >optimization and yet claiming to maintain the strict if/elif-chain >semantics. Hear, hear! We already have if/elif, we don't need another way to spell it. The whole point of switch is that it asserts that exactly *one* case is supposed to match -- which means by definition that the *order* of the cases must not matter. It is an unprioritized selection, rather than sequential selection. I think that probably the biggest misunderstanding of switch that has been put forth is that it's shorthand for a particular pattern of if-elif use, when in actuality it's the other way around: if-elif is sometimes used as a crude workaround for the absence of a switch feature. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 35, Issue 143
Hi all, Sorry for my inappropriate posting. I just joined the list and didn't realize the complete scope. I will stay on the list, I'm very interested in it from a semantics & implementation perspective as well. Thanks to Brett for the heads-up. Jeff --- Brett Cannon <[EMAIL PROTECTED]> wrote: > Python-Dev is about Python the language and its > development. Questions on > its use (and build) should be posted elsewhere (I > would try comp.lang.python > ). > > -Brett > > On 6/26/06, J. Jeffrey Close > <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > > I have been trying for some time to build Python > 2.4.x > > from source on OS X 10.4.6. I've found *numerous* > > postings on various mailing lists and web pages > > documenting the apparently well-known problems of > > doing so. Various problems arise either in the > > ./configure step, with configure arguments that > don't > > work, or in the compile, or in my case in the link > > step with libtool. > > > > The configure options I'm using are the following: > > --enable-framework --with-pydebug --with-debug=yes > > --prefix=/usr --with-dyld --program-suffix=.exe > > --enable-universalsdk > > > > I've managed to get past configure and can compile > > everything, but in the link I get the error > "Undefined > > symbols: ___eprintf" . This appears to have > > something to do with dynamic library loading not > > properly pulling in libgcc. I've tried with -lgcc > in > > the LD options, but that produces a configure > error > > "cannot compute sizeof...". > > > > If I remove "--enable-framework" the complete > build > > works, but unfortunately that is the one critical > > element that I need. > > > > The web pages I've found referring to this range > from > > 2001 to present -- still apparently everybody is > > having problems with this. Does *anybody* here > have > > Python built from source on this OS? > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > --- [EMAIL PROTECTED] wrote: > > > > > Send Python-Dev mailing list submissions to > > > [email protected] > > > > > > To subscribe or unsubscribe via the World Wide > Web, > > > visit > > > > http://mail.python.org/mailman/listinfo/python-dev > > > or, via email, send a message with subject or > body > > > 'help' to > > > [EMAIL PROTECTED] > > > > > > You can reach the person managing the list at > > > [EMAIL PROTECTED] > > > > > > When replying, please edit your Subject line so > it > > > is more specific > > > than "Re: Contents of Python-Dev digest..." > > > > > > > > > Today's Topics: > > > > > >1. Re: ImportWarning flood (Nick Coghlan) > > >2. Re: ImportWarning flood (Ralf W. > > > Grosse-Kunstleve) > > >3. Re: 2.5b1 Windows install (Nick Coghlan) > > >4. Re: ImportWarning flood (Michael Hudson) > > >5. Re: ImportWarning flood (A.M. Kuchling) > > >6. Re: ImportWarning flood (Benji York) > > >7. Re: Simple Switch statement (Michael > Urman) > > >8. Re: ImportWarning flood (Nick Coghlan) > > >9. Re: Simple Switch statement (Guido van > Rossum) > > > 10. Re: pypy-0.9.0: stackless, new extension > > > compiler > > > (Carl Friedrich Bolz) > > > > > > > > > > > > -- > > > > > > Message: 1 > > > Date: Mon, 26 Jun 2006 20:27:03 +1000 > > > From: Nick Coghlan <[EMAIL PROTECTED]> > > > Subject: Re: [Python-Dev] ImportWarning flood > > > To: Guido van Rossum <[EMAIL PROTECTED]> > > > Cc: [email protected] > > > Message-ID: <[EMAIL PROTECTED]> > > > Content-Type: text/plain; charset=ISO-8859-1; > > > format=flowed > > > > > > Guido van Rossum wrote: > > > > On 6/24/06, Jean-Paul Calderone > > > <[EMAIL PROTECTED]> wrote: > > > >>> Actually, your application *was* pretty > close to > > > being broken a few > > > >>> weeks ago, when Guido wanted to drop the > > > requirement that a package > > > >>> must contain an __init__ file. In that case, > > > "import math" would have > > > >>> imported the directory, and given you an > empty > > > package. > > > >> But this change was *not* made, and afaict it > is > > > not going to be made. > > > > > > > > Correct. We'll stick with the warning. (At > least > > > until Py3k but most > > > > likely also in Py3k.) > > > > > > Perhaps ImportWarning should default to being > > > ignored, the same way > > > PendingDeprecationWarning does? > > > > > > Then -Wd would become 'the one obvious way' to > debug > > > import problems, since it > > > would switch ImportWarning on without drowning > you > > > in a flood of import > > > diagnostics the way -v can do. > > > > > > Import Errors could even point you in the right > > > direction: > > > > > > >>> import mypackage.foo > > > Traceback (most recent call last): > > >File "", line 1, in ? > > > ImportError: No module named mypackage.foo > > > Diagnostic import warnings can be enabled > with > > > -Wd > > > > > > Cheers, > > > Nick. > > > > > > --
Re: [Python-Dev] ImportWarning flood
--- "Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote: > Michael Hudson wrote: > > > Benji York <[EMAIL PROTECTED]> writes: > > > >> Nick Coghlan wrote: > >>> Perhaps ImportWarning should default to being ignored, the same way > >>> PendingDeprecationWarning does? > >>> > >>> Then -Wd would become 'the one obvious way' to debug import problems > >> > >> +1 > > > > I'm not sure what this would achieve -- people who don't know enough > > about Python to add __init__.py files aren't going to know enough to > > make suppressed-by-default warnings not suppressed. > > The change was prompted by developers (specifically, Google developers). > Developers should be able to put -Wd in their automated build scripts. > > > The more I think about it, the more I like the idea of saying > > something when an import fails only because of a missing __init__.py > > file. I guess I should try to implement it... > > This is by far and away my preference as well (stating which directories > may have been importable if they had __init__.py in the exception) but > it was shot down in the original discussion. I guess it is probably quite tricky to implement. Note the list of files with the "No module named" message I posted earlier. Somehow you'd have to keep track of all potential directories in all these different contexts. I think a combination of pointing to the documentation and mentioning -Wd would cover all situations. Most people just need a reminder. That's easy to achieve with a new ImportErrorNoModule(name) exception. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple Switch statement
On 6/26/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > With the simplified proposal, this would be coded with an inverse mapping: > > for event in pygame.event.get(): > switch eventmap[event.type]: > case 'KEYDOWN': ... > case 'KEYUP': ... > case 'QUIT': ... Ah, here's where it gets interesting. While that definitely works on the surface, it can run into some difficulties of scope. SDL (on which pygame is based) allows user-defined events, also integers, but without a predefined meaning. If pygame provides the inverse mapping, it won't contain the user-defined events. If you construct it, you have to choose between a local lookup and a global one, and then we start seeing a global store for an essentially local construct, or we risk differences when there's more than one locality for using it. While you're right; it should be simple to ensure that the inverse map handles at least the set the switch handles, and it keeps evaluation simpler, I still find the limitation ugly. As mentioned, the early error checking is poor, and it just doesn't feel like the rest of python. > >I also would like to see a way to use 'is' [...]for the comparison > > [If] the goal is having several distinct cases that are equal but > not identical, then that's another story. I suggest leave the initial > switch syntax as simple as possible and just switch on id(object). Switching on id(object) only sounds palatable if we're not bound by the simple switch's limitations. Having a second (if inverted) mapping merely of identifier to object smells particularly rancid. What if I want some cases done as identity, but some as equality? Since I'm having no luck finding a real use case for this, perhaps I should assume a nested switch would be adequate. Assuming static or capture it doesn't look too bad, so I think I'll go with Guido's hypothesis that it's a red herring. switch id(value): case id(object): ... case id(None): ... else: switch value: case 1: ... case 'orange': else: raise ValueError Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Semantic of isinstance
Hello Python Dev, I am trying to understand the correct semantic of the isinstance built-in function and while doing so, I came across few cases which raise some questions. 1) First example - a class instance pretends to have different class via __class__. >>> class D(object): ... def getclass(self): ... print "D.getclass" ... return C ... __class__ = property(getclass) ... >>> isinstance(D(), D) True >>> isinstance(D(), C) D.getclass True isinstance in this case returns True to both C and D test. I would expect to see the __class__ property being called in both cases and get: >>> isinstance(D(), D) D.getclass False but that's not the case for some reason. It seems that the __class__ is only accessed in some cases, but not always, leading to what I think is a semantic inconsistency. 2) Second, slightly more complicated example, uses an instance with __bases__ on it as the 2nd parameter to isinstance: class E(object): def getbases(self): print "E.getbases" return () __bases__ = property(getbases) class C(object): def getbases(self): print "C.getbases" return (E,) # C() claims: "E is my base class" __bases__ = property(getbases) class D(object): def getclass(self): print "D.getclass" return C() # D() claims: "C() is my __class__" __class__ = property(getclass) class F(object): pass print "Test 1" print isinstance(D(), E()) # testing against E() instance print "Test 2" print isinstance(D(), E)# testing against E class The output here is: Test 1 E.getbases D.getclass C.getbases False Test 2 D.getclass False In the 2nd test, D.getclass is called to get the __class__ of D(), which returns C() instance. At this point I would expect that C.getbases gets called as __bases__ are retrieved, which would return tuple consisting of E and ultimately produce True result. However, in this case the __bases__ are never accessed on C() (the class of D()). The test_isinstance.py actually tests for similar case. My question is based on what assumptions does the standard Python implementation bypass the access to __bases__, __class__ etc. when evaluating isinstance? Did I happen to come across a bug or an inconsistency in Python implementation, or am I hitting an intentional behavior? Thanks very much for reading and some insights! Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Hi, Brett.
> I have been working on a design doc for restricted execution of Python
I'm excited to see that you're working on this.
> as part of my dissertation for getting Python into Firefox to replace
> JavaScript on the web.
Wow. What's your game plan? Do you have a story for convincing the
Mozilla folks to include Python in the standard Firefox distribution,
even though the whole browser UI is already written in Javascript?
Do you want Python to be used to scripts in web pages, Java-style
embedded objects, or both? I'm curious to know what you have in mind...
I'll post again with more detailed feedback on your document, but here's
a general comment. I'd really like to see some worked examples of how
you want to see restricted execution mode used, in order to motivate
and evaluate the design and implementation.
In particular, how do you envision restricted execution interacting
with the standard library? ("Not at all" is a possible answer.)
Are there existing modules or existing Python programs you expect
to just work using restricted execution mode, or are you willing to
ask programmers who use restricted execution to adopt a new style?
-- ?!ng
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
Hi, Brett.> I have been working on a design doc for restricted execution of PythonI'm excited to see that you're working on this.Yeah, I just hope I have a design that works. =)
> as part of my dissertation for getting Python into Firefox to replace> _javascript_ on the web.
Wow. What's your game plan? Do you have a story for convincing theMozilla folks to include Python in the standard Firefox distribution,even though the whole browser UI is already written in _javascript_?
Do you want Python to be used to scripts in web pages, Java-styleembedded objects, or both? I'm curious to know what you have in mind...The plan is to allow pure Python code to be embedded into web pages like _javascript_. I am not going for the applet approach like Java.
As for convincing the Mozilla folks, I want working code first before I try to do a big push. But the idea is that _javascript_ does not scale well for large applications, which more and more people want. Python provides a more structured approach to programming that can help facilitate designing large web applications that have a complicated client-side component. There is also a large userbase already that I hope will like this and speak up to say, "I want this!" But otherwise, no, no plan to get Mozilla to go along with it. =) If they don't pick it up I can probably go with an extension or something. It is my dissertation; can't expect too much real-world usage out of it. =)
I am not expecting Mozilla to rip out _javascript_. I just want the ability to do client-side scripting in a web page to be doable in Python instead. If they want to rewrite parts of Mozilla's UI in Python, then wonderful! But I would not be hurt or whatever if they didn't bother since that would be a huge undertaking. _javascript_ can live side-by-side with Python until people realize Python is better and slowly begin to migrate over. =)
I'll post again with more detailed feedback on your document, but here'sa general comment. I'd really like to see some worked examples of how
you want to see restricted execution mode used, in order to motivateand evaluate the design and implementation.The idea is that there be a separate Python interpreter per web browser page instance. So each tab in Mozilla would be running a Python interpreter. I don't think _javascript_'s security model is really that bad so I am trying to follow it within reason. So the main goal is for people who embed the interpreter and do not need any form of trusted interpreter to run to be able to easily have an interpreter(s) running in various states of restricted execution.
So, launch an interpreter, set the restrictions, pass in the DOM, and then execute the Python code in the HTML in this untrusted interpreter.
In particular, how do you envision restricted execution interactingwith the standard library? ("Not at all" is a possible answer.)Are there existing modules or existing Python programs you expectto just work using restricted execution mode, or are you willing to
ask programmers who use restricted execution to adopt a new style?I expect everything to work within the restricted bounds of security restrictions turned on for an interpreter. This means that if you allow file reading you can unpickle a file from disk. But if you don't, then you can still import 'pickle', but it will fail when you try to use
pickle.load() with a restricted execution exception. That is why I am placing the security restriction at the import level and then at key points in key objects (file, socket, sys.stdin, etc.); to minimize possible slip-ups in security by catching them at the OS/code boundary at the C level in the interpreter/stdlib.
I really don't want to ask programmer to adopt a new style. They might have to change very slightly ("where is the __file__ attribute on modules?"), but overall I want to minimize as much as possible a shift in Python programming style.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantic of isinstance
Martin Maly wrote: isinstance(D(), D) > > True > isinstance(D(), C) > > D.getclass > True This looks like a new/old class thing. Presumably once everything is changed over to new-style classes, this inconsistency will go away. And from the current behaviour, it looks like __class__ and __bases__ will be bypassed by isinstance() (unless Guido decides to change that). -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantic of isinstance
Thanks for the response. The code snippet I sent deals with new style classes only so I assume that in some cases isinstance falls back to old-style-like handling which then asks for __bases__ and __class__ etc, possibly incorrectly so on new style classes. Thanks again! Martin -Original Message- From: Greg Ewing [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 8:00 PM To: Martin Maly Cc: [email protected] Subject: Re: [Python-Dev] Semantic of isinstance Martin Maly wrote: isinstance(D(), D) > > True > isinstance(D(), C) > > D.getclass > True This looks like a new/old class thing. Presumably once everything is changed over to new-style classes, this inconsistency will go away. And from the current behaviour, it looks like __class__ and __bases__ will be bypassed by isinstance() (unless Guido decides to change that). -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED]+--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantic of isinstance
At 05:16 PM 6/26/2006 -0700, Martin Maly wrote: > >>> class D(object): >... def getclass(self): >... print "D.getclass" >... return C >... __class__ = property(getclass) >... > >>> isinstance(D(), D) >True > >>> isinstance(D(), C) >D.getclass >True > >isinstance in this case returns True to both C and D test. I would expect >to see the __class__ property being called in both cases and get: > > >>> isinstance(D(), D) >D.getclass >False > >but that's not the case for some reason. That's because isinstance checks type(D()) and finds it equal to D -- this shortcuts the process. > It seems that the __class__ is only accessed in some cases, but not > always, leading to what I think is a semantic inconsistency. It's not inconsistent - isinstance() checks __class__ in *addition* to type() in order to allow proxying tricks like lying about your __class__. It therefore returns true if either your real type *or* your __class__ matches, and as you can see, the real type is checked first. >class E(object): > def getbases(self): > print "E.getbases" > return () > __bases__ = property(getbases) > >class C(object): > def getbases(self): > print "C.getbases" > return (E,) # C() claims: "E is my base class" > __bases__ = property(getbases) > >class D(object): > def getclass(self): > print "D.getclass" > return C() # D() claims: "C() is my __class__" > __class__ = property(getclass) > > >class F(object): pass > > >print "Test 1" >print isinstance(D(), E()) # testing against E() instance >print "Test 2" >print isinstance(D(), E)# testing against E class > >The output here is: > >Test 1 >E.getbases >D.getclass >C.getbases >False > >Test 2 >D.getclass >False > >In the 2nd test, D.getclass is called to get the __class__ of D(), which >returns C() instance. At this point I would expect that C.getbases gets >called as __bases__ are retrieved, which would return tuple consisting of >E and ultimately produce True result. As it happens, this is due to the fact that E is a type, while E() is not. There's an optimization in the isinstance() machinery that simply checks to see if D().__class__ is a subtype of E. That's where your experiment fails. I'm not sure whether this behavior should be considered correct or not. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantic of isinstance
At 08:04 PM 6/26/2006 -0700, Martin Maly wrote: >Thanks for the response. The code snippet I sent deals with new style >classes only so I assume that in some cases isinstance falls back to >old-style-like handling which then asks for __bases__ and __class__ etc, >possibly incorrectly so on new style classes. Actually, it's correct behavior for isinstance() to inspect __class__, even on new-style classes. I suspect that the question of checking for __bases__ in one of the shortcut branches just didn't come up when the code was being written. This does appear to be a language design question, regarding how much of this machinery one is allowed to emulate. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Things to remember when adding *packages* to stdlib
On 6/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > I believe this change is all that's necessary on the Unix side to > > install wsgiref. Can someone please update the Windows build files to > > ensure wsgiref is installed in b2? Don't forget to update the NEWS > > entry too. > > It's installed in b1 already. The msi generator picks up all .py files > in Lib automatically, except for those that have been explicitly > excluded (the plat-* ones). Ah cool. I was confusing it with extensions and mis-remembering. > > Maybe someone could come up with a heuristic to add to Misc/build.sh > > which we could test in there. > > I think "make install INSTALL=true|grep true" should print the names > of all .py files in Lib, except for the ones in plat-*. I modified the build.sh script to run the installed version. As long as some test references the new package, this should catch the problem. I sure hope we don't allow a new package without tests. :-) I also modified the buildbot config to ignore changes if all the files in a revision are under Demo, Doc, or Misc. This change (if I got it right and it works) should help reduce some builds that have little benefit. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantic of isinstance
Phillip J. Eby wrote: > It's not inconsistent - isinstance() checks __class__ in *addition* to > type() in order to allow proxying tricks like lying about your > __class__. If this is a deliberate feature, it's a bit patchy, because it means the proxy can't lie about *not* being an instance of its real type. Perhaps Guido could clarify how much lying a proxy is supposed to be able to get away with? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Mon, 26 Jun 2006, Guido van Rossum wrote: > > Most school I proponents (perhaps you're the only exception) have > > claimed that optimization is desirable, but added that it would be > > easy to add hash-based optimization. IMO it's not so easy in the light > > of various failure modes of hash(). (A possible solution would be to > > only use hashing if the expression's type is one of a small set of > > trusted builtins, and not a subclass; we can trust int.__hash__, > > str.__hash__ and a few others.) > > That's a good idea! At first glance, it seems like that could lead to > a plausible compromise. I'm not so sure. I realized that school I really doesn't have a good story for optimizing cases involving named constants. Anyway, after this afternoon's discussion I rewrote the section of the PEP that discusses the semantic schools of though, hopefully representing and distinguishing the different schools more accurately. Look for revision 47120 (it's in svn, but it seems to take a while to propagate to python.org). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Semantic of isinstance
On 6/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > > It's not inconsistent - isinstance() checks __class__ in *addition* to > > type() in order to allow proxying tricks like lying about your > > __class__. > > If this is a deliberate feature, it's a bit patchy, because > it means the proxy can't lie about *not* being an instance > of its real type. > > Perhaps Guido could clarify how much lying a proxy is > supposed to be able to get away with? Sorry, I don't remember all the constraints. Read the code and weep. This should be revisited for Py3k. The code became convoluted out of some needs in Zope; I can't remember if it was Zope 2 or Zope 3 that needed this (probably both) and I can't remember the specific situation where it was needed. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
Guido van Rossum wrote: > Most school I proponents (perhaps you're the only exception) have > claimed that optimization is desirable, but added that it would be > easy to add hash-based optimization. IMO it's not so easy in the light > of various failure modes of hash(). (A possible solution would be to > only use hashing if the expression's type is one of a small set of > trusted builtins, and not a subclass; we can trust int.__hash__, > str.__hash__ and a few others.) that's the obvious approach for the optimize-under-the-hood school -- only optimize if you can do that cleanly (to enable optimization, all case values must be either literals or statics, have the same type, and belong to a set of trusted types). this gives a speedup in all main use cases, and clear semantics in all cases. another approach would be to treat switch/case and switch/case-static as slightly different constructs; if all cases are static, put the case values in a dictionary, and do the lookup as usual (propagating any errors). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On 6/26/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > Most school I proponents (perhaps you're the only exception) have > > claimed that optimization is desirable, but added that it would be > > easy to add hash-based optimization. IMO it's not so easy in the light > > of various failure modes of hash(). (A possible solution would be to > > only use hashing if the expression's type is one of a small set of > > trusted builtins, and not a subclass; we can trust int.__hash__, > > str.__hash__ and a few others.) > > that's the obvious approach for the optimize-under-the-hood school -- > only optimize if you can do that cleanly (to enable optimization, all > case values must be either literals or statics, have the same type, and > belong to a set of trusted types). this gives a speedup in all main use > cases, and clear semantics in all cases. > > another approach would be to treat switch/case and switch/case-static as > slightly different constructs; if all cases are static, put the case > values in a dictionary, and do the lookup as usual (propagating any errors). I think we need a PEP for const/static/only/cached/precomputed or whatever people like to call it. Once we have (say) static, I think making the case expressions static by default would still cover all useful cases, and would allow us to diagnose duplicate cases reliably (which the if/elif chain semantics don't allow IIUC). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems building Python on OSX 10.4.6?
On 26-jun-2006, at 23:03, J. Jeffrey Close wrote: > [Bleh, sorry about the subject line on my first post. > Forgot to edit it before I sent.] > > > Hi all, > > I have been trying for some time to build Python 2.4.x > from source on OS X 10.4.6. I've found *numerous* > postings on various mailing lists and web pages > documenting the apparently well-known problems of > doing so. Various problems arise either in the > ./configure step, with configure arguments that don't > work, or in the compile, or in my case in the link > step with libtool. > > The configure options I'm using are the following: > --enable-framework --with-pydebug --with-debug=yes > --prefix=/usr --with-dyld --program-suffix=.exe > --enable-universalsdk Which sources are you using? The 2.4.x tarballs don't support -- enable-universalsdk (and yes, configure won't complain about unknown or misspelled options, that's an entirely different subject). Those SDKs also don't support mixing --prefix and --enable-framework, the prefix argument will be ignored completely. Python 2.5 does support -- enable-universalsdk and specifiying other prefixes when using -- enable-framework. I have a patch that backports this to 2.4.x, but haven't applied this yet because I haven't had time to fully test this yet, hopefully I'll manage this week. BTW. --enable-framework --with-pydebug is all you need, the others are either default or deduced from the platform information by configure. And completely off-topic: please don't install your own build of python as /usr/bin/python. IMHO this is conceptually bad, but more importantly Apple uses python in some parts of the OS (PDF workflows for example) and this change could well break that. > > I've managed to get past configure and can compile > everything, but in the link I get the error "Undefined > symbols: ___eprintf" . This appears to have > something to do with dynamic library loading not > properly pulling in libgcc. I've tried with -lgcc in > the LD options, but that produces a configure error > "cannot compute sizeof...". What version of the developer tools are you using? And are you building on PPC or Intel? One way to work around the problems you're having is to install the binary install of 2.4.3. > > If I remove "--enable-framework" the complete build > works, but unfortunately that is the one critical > element that I need. > > The web pages I've found referring to this range from > 2001 to present -- still apparently everybody is > having problems with this. Does *anybody* here have > Python built from source on this OS? Obviously someone must have managed, there's a binary installer for the OS :-). And before you nobody that ran into this problem found it important enough to actually tell us about is. Ronald > > Jeff > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ > ronaldoussoren%40mac.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
