John J Lee wrote:
I can see that people not knowing how to spell "hierarchy" might be a problem here <wink>
Heh, good point. I always get confused by the place of the 'heir' in the 'hierarchy'. I had a seriously hard time coming up with a one word name that suggested the right semantics for that category. If the idea gets any interest, it'd be nice to find a better word for that case. I was tempted to use __ambiguous__, though :) Hmm, __scan__ could be an option. The other two are fairly specific about where to look, but category 'C' requests a scan of the package heirarchy. A: from __absolute__.dotted.name import foo B: from __relative__.dotted.name import bar C: from __scan__.dotted.name import foobar D: from dotted.name import barfoo I suspect the 'as' clause would be heavily used with this construct, but it wouldn't be compulsory - as far as module referencing in the code goes, I don't think there's anything illegal about the special names. Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
It's interesting that the "scan upwards on the package name" gets so much support. Back when packages were first introduced, there was a period of time when they were a user-level construct, implemented by a module named "ni" (after the Knights who say "Ni!"). This implemented a full scan upward as the only way. When I reimplemented packages in C, I decided that the scan wasn't used much, and could actually be detrimental (I feared that too many global modules would be accidentally hidden), so I changed it to only looking in only two places: the current package and the toplevel (sys.path). But at the time it was a given that the import syntax would not be changed. Now that we're entertaining new import syntax, we can do better. How about this for Python 3.0: import P.Q (1) from P.Q import X (2) would only look for P in sys.path (I'll call this "absolute import"); and from ...P.Q import X (3) would scan for P upwards from the current package. It would require exactly three dots. P.Q of course stands for any dotted name. Python 2.x would continue to use the current ("ambiguous import") semantics for (1) and (2), but would also support (3) with the Python 3.0 semantics. It might also be possible to set a "no ambiguous imports" flag to switch to 3.0 semantics for (1) and (2). This might be a __future__ statement in the package's __init__.py, e.g. from __future__ import absolute_import I think this addresses all the concerns I've seen brought up in this thread so far against my original proposal and the variations that were subsequently suggested. --Guido van Rossum (home page: http://www.python.org/~guido/)
On 17-dec-03, at 18:21, Guido van Rossum wrote:
It's interesting that the "scan upwards on the package name" gets so much support.
I would actually be surprised if people who say they want "scan upward"
actually want something else: they want to scan upward up to a limit.
If you have a complex package with, say, three levels you may want to
scan up through the levels of your own package. However, if your package
is later incorporated in a third party package I can hardly imagine that
you want to scan in there too.
--
Jack Jansen,
[Guido]
It's interesting that the "scan upwards on the package name" gets so much support.
[Jack]
I would actually be surprised if people who say they want "scan upward" actually want something else: they want to scan upward up to a limit.
There's a negation missing here, but I think I understand you.
If you have a complex package with, say, three levels you may want to scan up through the levels of your own package. However, if your package is later incorporated in a third party package I can hardly imagine that you want to scan in there too.
I think someone actually posted a use case: they were referring to a global 3rd party module from within a package, and then later they were moving the module into the package. For both to work without changes to the import statement the scan would have to go all the way up. If we can disregard this use case, I still like my original proposal better, because it is more explicit: you have to use the right number of dots, and (like Unix paths starting with ../ or ../../ etc.) it is still completely explicit what you are referring to (assuming the current package/directory is known). But I expect the ... version will work just as well in practice: in debugged code, the ... refers to a particular ancestor, so what's above that is irrelevant; and what's below that is typically only two or at most three levels deep -- I should think a group of cooperating package authors who can't keep a namespace of that size coordinated will have bigger problems... And the advantage of the ... version is that it's more conspicuous than a single dot (for the most common case), and you don't have to count dots. --Guido van Rossum (home page: http://www.python.org/~guido/)
"Guido van Rossum"
I think someone actually posted a use case: they were referring to a global 3rd party module from within a package, and then later they were moving the module into the package. For both to work without changes to the import statement the scan would have to go all the way up.
Why should this sort of thing work "automatically"? When I restructure a package's modules, I don't usually assume that all imports will continue to work unchanged. The main use case IMHO is to move an entire package (or self contained module) in a package to achive some sort of required structuring or, more important, resolve naming conflicts. This includes adding or re-naming some organizational package names do to company merging or aquisitions.
If we can disregard this use case, I still like my original proposal better, because it is more explicit: you have to use the right number of dots, and (like Unix paths starting with ../ or ../../ etc.) it is still completely explicit what you are referring to (assuming the current package/directory is known).
+1 I like your original proposal more than this one. There should be some solution about from-less import however, to support the fully-qualified name syntax. For example, I prefer writing "struct.pack" over writing just "pack" because it is more explicit to the reader what happens. Or e. g. os.path.split is another example. Maybe just omit the dots for the name?
But I expect the ... version will work just as well in practice: in debugged code, the ... refers to a particular ancestor, so what's above that is irrelevant; and what's below that is typically only two or at most three levels deep -- I should think a group of cooperating package authors who can't keep a namespace of that size coordinated will have bigger problems...
I'd prefer to explicitly specify the number of steps "up" the hierarchy. - It prevents accidentially taking a wrong module (e. g. a "global" one) because a module is missing. - It prevents changing semantics because someone (else) adds a module with that name on some other level of the hierarchy. - Explicit is better than implicit ;-)
And the advantage of the ... version is that it's more conspicuous than a single dot (for the most common case), and you don't have to count dots.
If there are more than 2 (or maybe 3) dots in the original proposal's use, I think something is wrong with package structure - not with the syntax. And you are normally importing modules from your own package with relative imports, so there should hardly be a need to "count the dots" I think. / Werner
On Wed, 17 Dec 2003, Werner Schiendl wrote: [...]
There should be some solution about from-less import however, to support the fully-qualified name syntax. For example, I prefer writing "struct.pack" over writing just "pack" because it is more explicit to the reader what happens. Or e. g. os.path.split is another example.
Yes.
Maybe just omit the dots for the name?
As Guido pointed out, it would be a shame to break the rule that 'import x' currently lets you refer to plain old 'x'. And it would be ugly to have '.x' appear in programs, I think (and Guido mentioned with statements, though maybe he's kidding about that). So, why not this? from ... import x John
So, why not this?
from ... import x
Yes, I forgot about that. My original proposal allowed using just one or more dots; the three-dots proposal with scan-up semantics should also allow just that. In terms of the Grammar file: dotted_name: NAME ('.' NAME)* | '...' [NAME ('.' NAME)*] BTW, it seems that for breaking up long imports, the parentheses proposal has received universal acclaim. So if we add either of the dotted-from proposals to 2.4, we should also add the parenthesized syntax: from ...... import (......), and for symmetry also without from. --Guido van Rossum (home page: http://www.python.org/~guido/)
I think someone actually posted a use case: they were referring to a global 3rd party module from within a package, and then later they were moving the module into the package. For both to work without changes to the import statement the scan would have to go all the way up.
Why should this sort of thing work "automatically"? When I restructure a package's modules, I don't usually assume that all imports will continue to work unchanged.
The main use case IMHO is to move an entire package (or self contained module) in a package to achive some sort of required structuring or, more important, resolve naming conflicts. This includes adding or re-naming some organizational package names do to company merging or aquisitions.
I agree that the use case is not very strong. There really seem to be two camps here; some people like scan-up semantics so much they want to make it the default, others hate it and want to banish even the bastardized version of it that is the current default ("ambiguous import" or perhaps we can call it "search current then global").
If we can disregard this use case, I still like my original proposal better, because it is more explicit: you have to use the right number of dots, and (like Unix paths starting with ../ or ../../ etc.) it is still completely explicit what you are referring to (assuming the current package/directory is known).
+1
I like your original proposal more than this one.
I like its preciseness, but I have to admit that the three dots are enticing.
There should be some solution about from-less import however, to support the fully-qualified name syntax. For example, I prefer writing "struct.pack" over writing just "pack" because it is more explicit to the reader what happens. Or e. g. os.path.split is another example.
Maybe just omit the dots for the name?
from ... import os.path could be made to work (even though today, in a from-import statement, the name after the import keyword cannot have dots in it).
But I expect the ... version will work just as well in practice: in debugged code, the ... refers to a particular ancestor, so what's above that is irrelevant; and what's below that is typically only two or at most three levels deep -- I should think a group of cooperating package authors who can't keep a namespace of that size coordinated will have bigger problems...
I'd prefer to explicitly specify the number of steps "up" the hierarchy.
- It prevents accidentially taking a wrong module (e. g. a "global" one) because a module is missing.
But that would case pretty obvious error message, wouldn't it?
- It prevents changing semantics because someone (else) adds a module with that name on some other level of the hierarchy.
- Explicit is better than implicit ;-)
You know, I'm torn on this one. Maybe some more people can "vote" on their preferences.
And the advantage of the ... version is that it's more conspicuous than a single dot (for the most common case), and you don't have to count dots.
If there are more than 2 (or maybe 3) dots in the original proposal's use, I think something is wrong with package structure - not with the syntax.
Right. :-)
And you are normally importing modules from your own package with relative imports, so there should hardly be a need to "count the dots" I think.
Of course. --Guido van Rossum (home page: http://www.python.org/~guido/)
Jack Jansen
If you have a complex package with, say, three levels you may want to scan up through the levels of your own package. However, if your package is later incorporated in a third party package I can hardly imagine that you want to scan in there too.
The main use I have in mind for scan-upwards is for when you're importing something that's *not* part of your package. It's probably top-level, but someone might want to put you and it into a package one day, so you shouldn't hard-wire a top-level reference to it. That's why I think scan-upwards should be the default -- because you never know when someone might want to repackage you into a different environment in the future. Referring to related modules in your package is a different matter -- for that, you should probably be using explicitly relative references. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
The main use I have in mind for scan-upwards is for when you're importing something that's *not* part of your package. It's probably top-level, but someone might want to put you and it into a package one day, so you shouldn't hard-wire a top-level reference to it.
You could hardwire a relative reference to it though.
That's why I think scan-upwards should be the default -- because you never know when someone might want to repackage you into a different environment in the future.
I don't know if I want to encourage this kind of repackaging. There are various downsides (such as possible deployment of two differently repackaged versions of the same code) and I think some of the burden should be placed on the repackager. After all, after repackaging, the repackager is really responsible for the repackaged code. The nice thing about absolute imports is that it's very simple to write a tool that changes all absolute imports of a given package into some other import, if you really want that. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 2003-12-17 at 21:02, Guido van Rossum wrote:
I don't know if I want to encourage this kind of repackaging.
I concur. I'm sure it's just me, but supporting this repacking use case makes me very uncomfortable. It feels like I'm loosing a solid grounding about where and how Python finds modules named in import statements. -Barry
import P.Q (1) from P.Q import X (2)
would only look for P in sys.path (I'll call this "absolute import"); and
from ...P.Q import X (3)
would scan for P upwards from the current package.
I think this addresses all the concerns I've seen brought up in this thread so far
No, it doesn't address my concern that scan-upwards semantics should be the default, in the sense of being what should be used in the absence of a reason to do otherwise, and should therefore have the most straightforward syntax. Also, you don't seem to have anything for the explicitly-relative case, which might not be strictly necessary, but I think I'd feel more comfortable if it were available somehow. Thinking about the double_underscore names, it might not be so bad if they were a bit shorter, e.g. A: __root__.P.Q B: __here__.P.Q __here__.__parent__.P.Q C: P.Q Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
On Thu, 18 Dec 2003, Greg Ewing wrote:
Thinking about the double_underscore names, it might not be so bad if they were a bit shorter, e.g.
A: __root__.P.Q B: __here__.P.Q __here__.__parent__.P.Q C: P.Q
Why separate __here__ and __parent__? (I may just be confused, here.) Aren't both about getting the relative package container? Discussing schemes for explicit relative and absolute imports with some colleagues a few days ago, we liked '__pkg__' for the package containing the current module - and __pkg__.__pkg__ to mean its' container (and so on, for those non-programmers out there:-). Someone also wanted explicit expression of absolute, which we thought might be '__python__'. A: __python__.P.Q B: __pkg__.P.Q __pkg__.__pkg__.P.Q C: P.Q That said, *i* much prefer the leading '.' scheme - i think the underscores are distinctly *not* easier to read, and i'm not bothered, anyway, by the "punctuality" of the leading-'.' - i think it stands out enough to be noticable, and the fractured-path implication of it conveys the relativeness... Ken klm@zope.com
On Wed, 2003-12-17 at 18:57, Ken Manheimer wrote:
That said, *i* much prefer the leading '.' scheme - i think the underscores are distinctly *not* easier to read, and i'm not bothered, anyway, by the "punctuality" of the leading-'.' - i think it stands out enough to be noticable, and the fractured-path implication of it conveys the relativeness...
Just to continue my contrarian ways, the leading-dot thingie was one of the things that always bugged me about zcml. :) -Barry
I think this addresses all the concerns I've seen brought up in this thread so far
No, it doesn't address my concern that scan-upwards semantics should be the default, in the sense of being what should be used in the absence of a reason to do otherwise, and should therefore have the most straightforward syntax.
It doesn't address that becaseu I don't want that to be the default. I'm considering adding syntax for relative imports so that the default import syntax can be absolute only, rather than ambiguous. IMO scan-upwards as the default is worse than ambiguous.
Also, you don't seem to have anything for the explicitly-relative case, which might not be strictly necessary, but I think I'd feel more comfortable if it were available somehow.
That's why I originally proposed single, double, triple (etc.) leading dots.
Thinking about the double_underscore names, it might not be so bad if they were a bit shorter, e.g.
I *really* don't like using double-underscore names here unless it was for extremely uncommon cases. There are two proposals that I can live with: my original proposal with the leading dots counting the number of levels up, or the triple-dot proposal with scan-up semantics. In both cases, the default semantics would switch to absolute for Python 3.0. I cannot accept scan-up as default, and I don't think we can come up with two separate clearly distinguishable non-default syntaxes to separate scan-up and explicit relative semantics, so you have to pick one there. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido:
I cannot accept scan-up as default
In that case, it's probably better not to have it at all, and I'd go for your first proposal. One leading dot seems to stand out pretty well to my eyes -- more is not necessary. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
I cannot accept scan-up as default
In that case, it's probably better not to have it at all, and I'd go for your first proposal. One leading dot seems to stand out pretty well to my eyes -- more is not necessary.
But you're okay with two or more dots for extra levels up, right? (Note that this leading-dot algorithm is nearly the same as the old MacOS pathname syntax, except they did it with colons: :foo was foo in the current directory, ::foo was foo in the parent directory, etc., and foo:bar was an absolute pathname. The only difference is that for backwards compatibility reasons they interpreted no colons as relative to the current directory rather than absolute.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido:
But you're okay with two or more dots for extra levels up, right?
Yes, that's fine.
(Note that this leading-dot algorithm is nearly the same as the old MacOS pathname syntax
I noticed that, too. Also I think VMS did something similar with dots in its pathnames. So there are precedents... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Greg> Also I think VMS did something similar with dots in its Greg> pathnames. So there are precedents... Yes, but the dots were kind of hard to miss what with the directory portion of a path enclosed in [ ... ] Skip
[Guido]
... (Note that this leading-dot algorithm is nearly the same as the old MacOS pathname syntax, except they did it with colons: :foo was foo in the current directory, ::foo was foo in the parent directory, etc., and foo:bar was an absolute pathname. The only difference is that for backwards compatibility reasons they interpreted no colons as relative to the current directory rather than absolute.)
More relevant to most of the world <wink> is that it's even more similar to the pathname syntax in the Win9x/ME command.com shells: C:\Code\python\PCbuild>cd ...\Zope C:\Code\Zope> I expect that basing Python syntax on obsolete, hated OSes is a smart contrarian move <wink>>
Guido van Rossum
There are two proposals that I can live with: my original proposal with the leading dots counting the number of levels up, or the triple-dot proposal with scan-up semantics. In both cases, the default semantics would switch to absolute for Python 3.0.
If that's what you;d like a vote on, I prefer the triple-dot proposal. As far as semantics go, I have no opinion (I don't have any use for either option) but I *really* dislike the look of the single dot. I'm not a great fan of the triple dot, but it's the lesser of the two evils. I have to admit to some confusion here, though. At the moment, the following works: pkg\__init__.py: print "importing pkg" import a pkg\a.py: print "importing a" import b pkg\b.py: print "importing b" >>> import pkg importing pkg importing a importing b Is the proposal that any of this *stop* working? I assume not. Otherwise, I'm -1 on the whole thing. I see no reason to break this usage, and good reason (I can rename pkg - before final release, obviously - without needing to do a search-and-replace edit on everything in the package). I think this whole thing needs a PEP, though. If only to be completely clear on what is and is not changing, and to record discarded options. Paul. -- This signature intentionally left blank
If that's what you;d like a vote on, I prefer the triple-dot proposal. As far as semantics go, I have no opinion (I don't have any use for either option) but I *really* dislike the look of the single dot. I'm not a great fan of the triple dot, but it's the lesser of the two evils.
Your vote doesn't help me; the triple dot proposal is semantically different from the single dot.
I have to admit to some confusion here, though. At the moment, the following works:
pkg\__init__.py: print "importing pkg" import a pkg\a.py: print "importing a" import b pkg\b.py: print "importing b"
>>> import pkg importing pkg importing a importing b
Is the proposal that any of this *stop* working? I assume not. Otherwise, I'm -1 on the whole thing. I see no reason to break this usage, and good reason (I can rename pkg - before final release, obviously - without needing to do a search-and-replace edit on everything in the package).
The idea is indeed to break this in Python 3.0 (but not earlier for backwards compatibility reasons). In 3.0, you would have to (and in 2.4 perhaps you could) write this as from . import a or from ... import a depending on which proposal is accepted.
I think this whole thing needs a PEP, though. If only to be completely clear on what is and is not changing, and to record discarded options.
Correct. I have no time to write it though. --Guido van Rossum (home page: http://www.python.org/~guido/)
+1 for the '.' proposal, where (to verify my understanding): - '.' indicates "import from the current package", '..' means "import from the package of my package", and so forth, - imports where the package part lacks a leading '.' are absolute, ie from the top level of the path. -1 for the '...' proposal, where '...' means a search from the current package up to the most superior containing package (which is actually a virtual package that entails the entire path). Ie, i am for absolute being the default and explicit-relative being available, and against ambiguous relative aka scanning the hierarchy. (I might be convinced otherwise about the scanning deal, but i think the more deterministic we can make imports, while still keeping them flexible enough to do what people need, the better.) I also like your proposal for a "no ambiguous imports" flag from __future__ import absolute_import Ken klm@zope.com
[Ken Manheimer]
+1 for the '.' proposal, where (to verify my understanding):
- '.' indicates "import from the current package", '..' means "import from the package of my package", and so forth,
- imports where the package part lacks a leading '.' are absolute, ie from the top level of the path.
-1 for the '...' proposal, where '...' means a search from the current package up to the most superior containing package (which is actually a virtual package that entails the entire path).
Ie, i am for absolute being the default and explicit-relative being available, and against ambiguous relative aka scanning the hierarchy. (I might be convinced otherwise about the scanning deal, but i think the more deterministic we can make imports, while still keeping them flexible enough to do what people need, the better.)
Thanks! Your vote is especially important for me because as far as I can remember you proposed the scan-up rule for the very first version of "ni" that we developed together back in 1995!
I also like your proposal for a "no ambiguous imports" flag
from __future__ import absolute_import
OK. Wanna write a PEP? Just kidding, I know you have less time than I do for it. So... *anybody* wanna write a PEP about this? (The parentheses proposal should also be folded in.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, 18 Dec 2003, Guido van Rossum wrote:
Thanks! Your vote is especially important for me because as far as I can remember you proposed the scan-up rule for the very first version of "ni" that we developed together back in 1995!
Older and*/*or wiser?-) FWIW, i also proposed using a leading '.' (and a leading '_', when '.' was refused because the parser couldn't handle it) for what we're now calling explict relative imports. Ken klm@zope.com
On Thu, Dec 18, 2003, Guido van Rossum wrote:
OK. Wanna write a PEP? Just kidding, I know you have less time than I do for it. So... *anybody* wanna write a PEP about this? (The parentheses proposal should also be folded in.)
Since nobody else has volunteered, I guess I'll write the PEP. Expect it sometime in the next couple of weeks. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
Since nobody else has volunteered, I guess I'll write the PEP. Expect it sometime in the next couple of weeks.
Thanks, Aahz! --Guido van Rossum (home page: http://www.python.org/~guido/)
Hey, I'm a new lurker (hoping to change that) here on the python-dev list, and I thought I would post a message about a new PEP I recently submitted entitled "A Case for Some". The PEP talks about how there exists None, that is false, and that is smaller than any other object ( min(None, a) -> None ). However, there doesn't exist an equivalent true value that is larger than any other number, like ( max(Some, a) -> Some ). Personally, I think the introduction of Some offers a nice compliment to None, especially because it allows algorithms that require an initialization of infinity to not require large numbers. Some would be sufficient. It also has the side benefit of being funny. I just wanted to get the discussion going. How does everyone feel about Some? Thanks, - Josiah Carlson
I'm a new lurker (hoping to change that) here on the python-dev list, and I thought I would post a message about a new PEP I recently submitted entitled "A Case for Some".
The PEP talks about how there exists None, that is false, and that is smaller than any other object ( min(None, a) -> None ). However, there doesn't exist an equivalent true value that is larger than any other number, like ( max(Some, a) -> Some ).
Personally, I think the introduction of Some offers a nice compliment to None, especially because it allows algorithms that require an initialization of infinity to not require large numbers. Some would be sufficient. It also has the side benefit of being funny.
I just wanted to get the discussion going. How does everyone feel about Some?
-1. Depending on your algorithm you can already use sys.maxint, or a large float (e.g. 1e300), or you can write 1e1000 (or 1e300**2) which on most systems evaluates to a floating point Infinity. And "Some" sounds like a really strange spelling of "Infinity". There's also a PEP (PEP 754) to add a proper way to spell floating point Infinity. Or you could reverse signs and use min(None, -a). --Guido van Rossum (home page: http://www.python.org/~guido/)
Paul Moore
If that's what you'd like a vote on, I prefer the triple-dot proposal.
How would you spell relative references to parent packages using the triple-dot version? Remember we've dropped the idea of search-upwards, so that would have to be made explicit somehow.
pkg\__init__.py: print "importing pkg" import a pkg\a.py: print "importing a" import b pkg\b.py: print "importing b"
>>> import pkg importing pkg importing a importing b
Is the proposal that any of this *stop* working?
I think the proposal is for it to keep working for backwards compatibility now, but to stop working in Python 3.0. Is that correct? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
On Fri, 2003-12-19 at 05:57, Greg Ewing wrote:
How would you spell relative references to parent packages using the triple-dot version?
Does anybody have an example, in released code, of where this kind of repackaging relative imports is being used? I'd like to look at some real-world examples. Thanks, -Barry
Does anybody have an example, in released code, of where this kind of repackaging relative imports is being used? I'd like to look at some real-world examples.
I'm citing an example from the Jython compile of the Plucker distiller, for one. That's available as part of the Plucker package from www.plkr.org -- look at the Makefile in parser/python. But I'd guess most real examples are proprietary code (I can think of a couple right now). Bill
On Thu, 2003-12-18 at 07:24, Greg Ewing wrote:
Thinking about the double_underscore names, it might not be so bad if they were a bit shorter, e.g.
A: __root__.P.Q B: __here__.P.Q __here__.__parent__.P.Q C: P.Q
I like this, although I'm not so sure about __here__.__parent__. What I like about this is the explicitness of where your search starts. -Barry
participants (14)
-
Aahz -
Barry Warsaw -
Bill Janssen -
Greg Ewing -
Guido van Rossum -
Jack Jansen -
John J Lee -
Josiah Carlson -
Ken Manheimer -
Nick Coghlan -
Paul Moore -
Skip Montanaro -
Tim Peters -
Werner Schiendl