Re: [Python-Dev] Another version of Python
> "Steven" == Steven D'Aprano writes: Steven> For what it's worth, I have compiled a list of between 14 and 27 Steven> implementations of Python, depending on how conservative you are Steven> at defining "implementation". Steven> I then went to the wiki and discovered my list was nowhere near Steven> complete. Obviously this information is extensive and rapidly Steven> changing, so I think it would be better to have the current Steven> implementation page be fairly minimal but link to the wiki for Steven> more details: Steven> http://wiki.python.org/moin/implementation Steven> http://www.python.org/dev/implementations/ I added Like, Python and LOLPython to the wiki page in a new section, "Just For Fun". I don't see the source for the /dev/implementations page in my python.org website checkout. I'll suggest the link to the other pydotorg types. Skip ___ 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] __file__
Brett Cannon wrote: > On Fri, Feb 26, 2010 at 20:08, Glenn Linderman I'm not sure why what you did is different than what I did, > > > -M uses runpy which is not directly equivalent to importing. It's actually execution which is different from importing. Direct execution doesn't care about filenames (it inspects the file itself to figure out what it is), while importing cares a great deal. Note that Glenn ran "foo.py" directly, while Brett did "import temp". Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] __file__
Glenn Linderman wrote: > But if the technique can work from the command line, it seems the > same technique could be re-used in the importer. Not really - we only get away with the fun and games at execution time because __main__ is a bit special (and always has been). Those tricks would be a lot harder to pull off for a normal module import (if they were possible at all - I'm not sure they would be). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] __file__
Steven D'Aprano wrote: > On Sat, 27 Feb 2010 09:09:26 am Brett Cannon wrote: >> I think it's almost a dis-service to support bytecode-only >> files as it leads people who are misinformed or simply don't take the >> time to understand what is contained in a .pyc file into a false >> sense of security about their code not being easy to examine by >> someone else. > > You say that as if it were a bad thing. > > *wink* > > Personally, I can't imagine ever wanting to ship a .pyc module without > the .py, but since Python already gives people the opportunity to shoot > themselves in the foot, meh, we're all adults here. I do recall a > poster on comp.lang.python pulling his hair out over a customer who was > too big to fire, but who had the obnoxious habit of making random > so-called "fixes" to the poster's .py files, so perhaps byte-code only > distribution isn't all bad. I think the use case of "keep the user from fiddling casually with our application" is a valid one. There's a fairly vast difference between "open source file, edit code, hit save" and "decompile pyc, open decompiled source file, edit code, save next to pyc with correct name". The former makes it easy for folks that know just enough to be dangerous to get themselves in trouble. The latter raises the bar far enough that people with the ability to do it should also know better than to try (or at least, not to call the support line when it doesn't work). I do like the idea of pulling .pyc only imports out into a separate importer, but would go so far as to suggest keeping them as a command line option rather than as a separately distributed module. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] __file__
On Feb 28, 2010, at 01:38 AM, Nick Coghlan wrote: >I think the use case of "keep the user from fiddling casually with our >application" is a valid one. Doesn't the existing support for zipimport satisfy that use case already, and probably better so? Heck you can even name your zip file "application.dat" to really throw naive users off the scent. ;) -Barry signature.asc Description: PGP signature ___ 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] __file__
On Feb 26, 2010, at 10:59 PM, Michael Foord wrote: >There are several companies who currently ship bytecode only. (There was >someone on the IronPython mailing list only last week asking if >IronPython could support pyc files for this reason). For many >pointy-haired-bosses 'some' protection is enough and having Python not >support this (out of the box) would be a black mark against Python for them. Would it not be better to ship a zip file with an obfuscated name? Doesn't that satisfy the use case nicely? -Barry signature.asc Description: PGP signature ___ 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] __file__
On Feb 26, 2010, at 08:30 PM, Ron Adam wrote: >It does not make sense (to me) to have byte code only modules and packages >in python's lib directory. The whole purpose (as far as I know) is for >modules and packages located there to be shared. And as such, the source >file becomes a source of documentation. Not supporting bytecode only >python modules and packages in pythons "lib" directory may be good. Actually, it's not the standard library that's the issue, it's third party modules that OS vendors distribute. -Barry signature.asc Description: PGP signature ___ 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] __file__
On Feb 26, 2010, at 02:29 PM, Guido van Rossum wrote: >Byte-code only wasn't always supported. We added it knowing full well >it had all those problems (plus, it locks in the Python version), >simply because a certain class of developers won't stop asking for it. >Their users are apparently too dumb to decode bytecode but smart >enough to read source code, even if they don't understand it, and this >knowledge could hurt them. Presumably users smart enough to decode >bytecode will know enough not to hurt themselves. For now, I've added a open issues section to the PEP describing the options for bytecode-only support. I think there are better ways to satisfy the bytecode-only packager requirements than supporting it by default, always, in the standard importer, but let's enumerate the pros and cons and then make a decision. -Barry signature.asc Description: PGP signature ___ 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] __file__
On Feb 26, 2010, at 02:55 PM, Brett Cannon wrote: >Here is a question for Barry to think about if he decides to move forward >with all of this: would mixed support for both bytecode-only and >source/bytecode be required for the same directory, or could it be one or >the other but not both? Differing semantics based on what is found in the >directory would make the path hook more expensive (which is a one-time cost >per directory), but it would cut stat calls in the finder in half (which is >a cost made per import). It seems a bit magical to me, and the rules a bit difficult to predict. For example, what would be the trigger to enable bytecode-only support for a package directory? Would it be the absence of an __init__.py file? What if some .pyc files had .py file but not all of them? Wouldn't the trigger depend on import order? OTOH, maybe you're on to something. Perhaps we could add a flag to the package's namespace to turn this on. You'd have to include the __init__.py to get things going, but after that, everything else in the package could be .pyc-only. -Barry signature.asc Description: PGP signature ___ 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] __file__
On Feb 26, 2010, at 05:11 PM, Guido van Rossum wrote: >Barry's PEP would fix this even if we kept supporting .pyc-only files: >the lingering .pyc files will be in the __pycache__ directory which is >*not* searched -- only .pyc files directly in the source directory >will be found -- where the PEP will never place them, at least not by >default. Exactly so. -Barry signature.asc Description: PGP signature ___ 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 3188: Implementation Questions
On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing wrote: > Meador Inge wrote: > > 3. Using Decimal keeps the desired precision, >> > > Well, sort of, but then you end up doing arithmetic in > decimal instead of binary, which could give different > results. > Even with the user-defined precision capabilities of the 'Decimal' class? In other words, can I create an instance of a 'Decimal' that behaves (in all operations: arithmetic, comparison, etc...) exactly as the extended double precision type offered by a given machine? Maybe the solution is to give ctypes long double objects > the ability to do arithmetic? > Maybe, but then we would have to give all numeric 'ctypes' the ability to do arithmetic -- which may be more than we want. -- Meador ___ 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] __file__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Bicking wrote: > The one issue I thought would be resolved by not easily allowing > .pyc-only distributions is the case when you rename a file (say > module.py to newmodule.py) and there is a module.pyc laying around, > and you don't get the ImportError you would expect from "import > module" -- and to make it worse everything basically works, except > there's two versions of the module that slowly become different. This > regularly causes problems for me, and those problems would get more > common and obscure if the pyc files were stashed away in a more > invisible location. > > I can't even tell what the current proposal is; maybe this is > resolved? If distributing bytecode required renaming pyc files to .py > as Glenn suggested that would resolve the problem quite nicely from my > perspective. (Frankly I find the whole use case for distributing > bytecodes a bit specious, but whatever.) The consensus as I recal was that a .pyc file in the main package directory would be importable without a .py file (just as it is today), but that .pyc files in the cache directory would not be importable in the absence of a .py file. Package distributors who wanted to ship bytecode-only distributions would need to arrange to have the .pyc files created "in place' (by disabling the cachedir option) or move them from the cachedir before bundling. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuJUFIACgkQ+gerLs4ltQ6pnwCfVmDO8uiP9eSsjJf4ees35xus SEUAn0oKJwv9bGksxcMTHSfBbDV2Ujb7 =Vdpi -END PGP SIGNATURE- ___ 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] __file__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: > On Feb 26, 2010, at 02:55 PM, Brett Cannon wrote: > >> Here is a question for Barry to think about if he decides to move forward >> with all of this: would mixed support for both bytecode-only and >> source/bytecode be required for the same directory, or could it be one or >> the other but not both? Differing semantics based on what is found in the >> directory would make the path hook more expensive (which is a one-time cost >> per directory), but it would cut stat calls in the finder in half (which is >> a cost made per import). > > It seems a bit magical to me, and the rules a bit difficult to predict. For > example, what would be the trigger to enable bytecode-only support for a > package directory? Would it be the absence of an __init__.py file? What if > some .pyc files had .py file but not all of them? Wouldn't the trigger depend > on import order? > > OTOH, maybe you're on to something. Perhaps we could add a flag to the > package's namespace to turn this on. You'd have to include the __init__.py to > get things going, but after that, everything else in the package could be > .pyc-only. Why not just leave the code for import in the package directory as it is today, where .pyc files are already importable in the absence of a .py file? As long as file in the cachedir are *not* importable without the source, both sides win, AFAICT: most people will no longer have .pyc's in their package direoctories, and those who want them can get them, thorugh some means (moving from the cachedir, or disabling the cachedir feature). Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuJUXkACgkQ+gerLs4ltQ76UACeMtgUz+mxmxlU1wLgl58R4ZA0 aVMAoKEmVG0D8a37Ftag6srPQSWfptON =49Tz -END PGP SIGNATURE- ___ 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 3188: Implementation Questions
Meador Inge schrieb: > On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing > wrote: > >> Meador Inge wrote: >> >> 3. Using Decimal keeps the desired precision, >>> >> >> Well, sort of, but then you end up doing arithmetic in >> decimal instead of binary, which could give different >> results. >> > > Even with the user-defined precision capabilities of the 'Decimal' class? > In other words, can I create an instance of a 'Decimal' that behaves (in all > operations: arithmetic, comparison, etc...) exactly as the extended double > precision type offered by a given machine? > > Maybe the solution is to give ctypes long double objects >> the ability to do arithmetic? >> > > Maybe, but then we would have to give all numeric 'ctypes' the ability to do > arithmetic -- which may be more than we want. See issue 887237: http://bugs.python.org/issue887237 -- Thanks, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
On Sat, Feb 27, 2010 at 10:56:13AM -0500, Barry Warsaw wrote: > On Feb 26, 2010, at 10:59 PM, Michael Foord wrote: > > >There are several companies who currently ship bytecode only. (There was > >someone on the IronPython mailing list only last week asking if > >IronPython could support pyc files for this reason). For many > >pointy-haired-bosses 'some' protection is enough and having Python not > >support this (out of the box) would be a black mark against Python for them. > > Would it not be better to ship a zip file with an obfuscated name? Doesn't > that satisfy the use case nicely? Sure, we combine that with putting .pyo files inside the zipfile tough (for assert statements and if __debug__ blocks). I'm rather confused about everything proposed by now but would that keep working? Also somewhere else in the thread it seemed like both you and Guido suggested that simply creating a directory with some .pyc (or .pyo I guess) files in would keep working, just by default they won't be written there by python. Or is it that functionality some want to cut because of the doubling of the stat calls? (But even then I'm not convinced that would double the stat calls for normal users, only for those who only ship .pyc files) Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.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] __file__
Steven D'Aprano writes: > Personally, I can't imagine ever wanting to ship a .pyc module without > the .py, but since Python already gives people the opportunity to shoot > themselves in the foot, meh, we're all adults here. Not sure I've seen it mentioned in this thread, but for myself, I've certainly used (indirectly) such a distribution many times when packaging applications with py2exe for installation on Windows clients. That puts all the pyc files into a single support zip file from which the application runs. That seems a perfectly useful use case, and not due to any issues with security/obfuscation. The matching interpreter is being packaged with the application, so there's no version worries with the pyc. The files are internal to a zip, so why complicate things with recompiling and writing locally on the user's machine, particularly when on newer versions of Windows the installation directory might not be writable anyway. As long as executing from pyc files continues to work, presumably py2exe can be updated to collect those files from any new cache location during the build process. But I do think it's useful to continue to support executing them directly outside of any new cache location, which it sounds like is the direction being taken. -- David ___ 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] __file__
Guido van Rossum wrote: Their users are apparently too dumb to decode bytecode but smart enough to read source code, even if they don't understand it, and this knowledge could hurt them. I think it's like putting a lock on your door. It won't stop anyone who's determined to get in, but it makes it hard for them to argue in court that they wandered in accidentally. Also it may make it easier to get the idea of using Python past PHBs. That seems to me like a good reason for keeping the feature. -- 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] __file__
Glenn Linderman wrote: What I did was: python -m test ren test.pyc foo.py foo.py and it worked. Source files mentioned on the command line aren't required to have a .py extension. I think what's happening is that the interpreter ignores the filename altogether in that case and examines the contents of the file to figure out what it is, in order to support running .pyc files from the command line. -- 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] __file__
Le Fri, 26 Feb 2010 14:29:03 -0800, Guido van Rossum a écrit : > > Byte-code only wasn't always supported. We added it knowing full well it > had all those problems (plus, it locks in the Python version), simply > because a certain class of developers won't stop asking for it. Their > users are apparently too dumb to decode bytecode but smart enough to > read source code, even if they don't understand it, and this knowledge > could hurt them. The idea that too much knowledge hurts users doesn't sound very Pythonic to me. As I understand it, the people interested in bytecode-only distributions are commercial companies willing to ease support. Why don't they whip up a specialized importer, and perhaps make it available as a recipe or a PyPI module somewhere? The idea that we should provide built-in support for a stupid (non-)security mechanism sounds insane to me. Finally, the sight of commercial companies not being able to do their work and begging open source projects to do it for them makes me *yawn*. If you aren't proficient or motivated enough to build your own internal commodities, perhaps you shouldn't do claim to do business at all. regards Antoine. ___ 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] __file__
On 28/02/2010 01:22, Antoine Pitrou wrote: Le Fri, 26 Feb 2010 14:29:03 -0800, Guido van Rossum a écrit : Byte-code only wasn't always supported. We added it knowing full well it had all those problems (plus, it locks in the Python version), simply because a certain class of developers won't stop asking for it. Their users are apparently too dumb to decode bytecode but smart enough to read source code, even if they don't understand it, and this knowledge could hurt them. The idea that too much knowledge hurts users doesn't sound very Pythonic to me. As I understand it, the people interested in bytecode-only distributions are commercial companies willing to ease support. Why don't they whip up a specialized importer, and perhaps make it available as a recipe or a PyPI module somewhere? The idea that we should provide built-in support for a stupid (non-)security mechanism sounds insane to me. Finally, the sight of commercial companies not being able to do their work and begging open source projects to do it for them makes me *yawn*. If you aren't proficient or motivated enough to build your own internal commodities, perhaps you shouldn't do claim to do business at all. Well if we'd *never* had this feature this argument would be very strong indeed. On the other hand if we want them to switch to Python 3 - but by the way we cut one of the features you rely on, but don't worry all you have to do is recode it yourself - doesn't make a very convincing argument. Michael Foord regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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 3188: Implementation Questions
Meador Inge wrote: Even with the user-defined precision capabilities of the 'Decimal' class? In other words, can I create an instance of a 'Decimal' that behaves (in all operations: arithmetic, comparison, etc...) exactly as the extended double precision type offered by a given machine? It's not precision that's the issue, it's that the number base is different. That affects which numbers can be represented exactly, and how results that can't be represented exactly are rounded. I would be very surprised if there is a way of configuring the Decimal type so that it gives identical results to that of any IEEE binary floating point type, including rounding behaviour, denormalisation, etc. -- 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] __file__
Le Sun, 28 Feb 2010 01:25:38 +, Michael Foord a écrit : > > Well if we'd *never* had this feature this argument would be very > strong indeed. On the other hand if we want them to switch to Python > 3 - but by the way we cut one of the features you rely on, but don't > worry all you have to do is recode it yourself - doesn't make a very > convincing argument. I understand it. On the other hand, it is certainly one of the least important issues involved in porting to py3k. (even for those people who liked the feature) And I think the prospect of a slight simplification (or de-complexification) of the import machinery is an important selling point. Regards Antoine. ___ 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] __file__
Floris Bruynooghe wrote: (But even then I'm not convinced that would double the stat calls for normal users, only for those who only ship .pyc files) It would increase the number of stat calls for normal users by 50%. You would need to look for a .pyc in the source directory, then .py in the source directory and .pyc in the cache directory. That's compared to two stat calls currently, for .py and .pyc. A solution might be to look for the presence of the cache directory, and only look for a .pyc in the source directory if there is no cache directory. Testing for the cache directory would only have to be done once per package and the result remembered, so it would add very little overhead. -- 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] __file__
On approximately 2/27/2010 5:25 PM, came the following characters from the keyboard of Greg Ewing: Glenn Linderman wrote: What I did was: python -m test ren test.pyc foo.py foo.py and it worked. Source files mentioned on the command line aren't required to have a .py extension. I think what's happening is that the interpreter ignores the filename altogether in that case and examines the contents of the file to figure out what it is, in order to support running .pyc files from the command line. Thanks for the explanation. Brett mentioned something like runpy vs import using different techniques. Which is OK, I guess, but if the command line/runpy can do it, the importer could do it. Just a matter of desire and coding. Whether it is worth pursuing further depends on people's perceptions of "kookiness" vs. functional and performance considerations. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] __file__
Glenn Linderman wrote: > Thanks for the explanation. Brett mentioned something like runpy vs > import using different techniques. Which is OK, I guess, but if the > command line/runpy can do it, the importer could do it. Just a matter > of desire and coding. Whether it is worth pursuing further depends on > people's perceptions of "kookiness" vs. functional and performance > considerations. As I said previously, don't underestimate how different __main__ is from everything else. The most obvious difference is that the code for __main__ is executed without holding the import lock, but there are other important differences as well (such as the module object being created directly by the interpreter startup sequence and hence a lot of the import machinery being bypassed). Even the -m switch doesn't really follow the normal import paths (it just finds the code object for the named module and then runs it directly instead of importing it). Direct execution starts with a filename (or a module name when using -m) then works out how to execute it as __main__. Importing starts with a module name, tries to find a matching filename and create the corresponding module. The different starting points and the different end goals affect the assumptions that are made while the interpreter figures out what it needs to do. The behaviour of runpy is different from import precisely because it aims to mimic execution of __main__ rather than a normal import. If there weren't quite so many semantic differences between direct execution and normal import, the module would have been a lot easier to write :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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
