On Fri, Feb 26, 2010 at 20:08, Glenn Linderman <v+pyt...@g.nevcal.com<v%2bpyt...@g.nevcal.com> > wrote:
> On approximately 2/26/2010 5:13 PM, came the following characters from the > keyboard of Brett Cannon: > > On Fri, Feb 26, 2010 at 15:35, Glenn Linderman > <v+pyt...@g.nevcal.com<v%2bpyt...@g.nevcal.com><mailto: >> v%2bpyt...@g.nevcal.com <v%252bpyt...@g.nevcal.com>>> wrote: >> >> On approximately 2/26/2010 2:55 PM, came the following characters >> from the keyboard of Brett Cannon: >> >> >> Maybe Greg's and my response to the mention of dropping >> this feature >> is too strong -- after all we're both dinosaurs. And maybe the >> developers who want the feature can write their own loader. >> >> >> We could also provide if necessary. >> >> >> So if the implementation stores .pyc by default in a >> version-specific place, then it seems there are only two things >> needed to make a python byte-code only distribution... >> >> 1) rename all the .pyc to .py >> 2) packaging >> >> When a .pyc is renamed to .py, Python (3.1 at least) recognizes >> and uses it... I assume by design, rather than accident, but I >> don't know the history. >> >> >> This does not work for me (nor should it): >> >> > touch temp.py >> > python3 -c "import temp" >> > rm temp.py >> > mv temp.pyc temp.py >> > python3 -c "import temp" >> Traceback (most recent call last): >> File "<string>", line 1, in <module> >> File "temp.py", line 2 >> SyntaxError: Non-UTF-8 code starting with '\x95' in file temp.py on line >> 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for >> details >> >> -Brett >> > > I'll admit to not doing exhaustive testing, but I'll not admit to not doing > any testing... because it was sort of a wild idea. Someone else called it > "kooky", which is fair. > > What I did was: > > python -m test > ren test.pyc foo.py > foo.py > > and it worked. Then I posted, knowing that I'd also tested, the other day, > several .py into a .zip named .py, and once that worked, then I changed to > putting all .pyc into the .zip named .py and that worked too... including > imports of the several modules from the "__main__.pyc". Of course, all > those were still named .pyc inside the .zip named .py. > > So I'm not sure what the difference is... .pyc as .py works from the > command line, but not from import? Some specialty because of using -c ? > > I'd guess the technique could be made to work, probably not require > extensive changes, if Python developers wanted to make it work. I think it > could be efficient and that same someone that called it "kooky" admitted it > would solve their use case, at least. > > I'm not sure why what you did is different than what I did, -M uses runpy which is not directly equivalent to importing. > nor why you state without justification that it shouldn't work... It just is not supposed to happen that way. Masquerading a bytecode file as a source file shouldn't work; imp.get_suffixes() controls how files should be interpreted based on their file extension. -Brett > I might be able to figure out the former if I spend enough time with the > documentation, if it is documented, but I'm too new to Python to understand > the latter without explanation. Could you supply at least the latter > explanation? I'd like to understand the issue here, whether or not the > "kooky" idea goes forward. > > > -- > 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
