Showing content from https://mail.python.org/pipermail/python-dev/2000-January.txt below:
. > ... > I thought a bit about how VB solves this. I think that when > you wrap up a VB app in, all the support code (mostly a big > DLL) is wrapped with it. When the user runs the installer, > the DLL is installed (probably in the WINDOWS directory). If > a user installs several VB apps built with the same VB > version, they all attempt to install the exact same DLL; of > course the installers notice this and optimize it away, keeping > a reference count. This is the way most *MS* DLLs work; stuff like the C runtime libraries and MS database drivers work exactly the same way. It's rare for pkgs other than MS's to attempt to use this mechanism, though (the reason is given below). > (Ignoring for now the fact that those reference counts don't > always work!) ? They work very well, in my experience. Where they fail is when installers & uninstallers break the rules. MS publishes the list of MS DLLs that are to be treated this way: an installer "must" use refcounting on the DLLs in the list. Alas, some (especially older) installation pkgs don't. Then the refcounts get screwed up. That's what makes the mechanism brittle: "the system" doesn't enforce it, it relies on universal & intelligent cooperation. It's very likely that someone distributing a Python app will neglect (out of ignorance) to bump the refcount on their Python components, so the refcount will be artificially low, and a later uninstall of some unrelated pkg that *did* follow the rules will merrily delete Python. Gordon and I will repeat this until it sinks in : almost everyone with a successful Windows product ships the non-MS DLLs they rely on and copies them into their own app directory. It's simple and it works; alternatives are complicated and don't work. Many even ship & copy MS DLLs (e.g., Scriptics copies its own msvcrt.dll (the MS C runtime) into Tcl's directories). Worrying about space consumed by redundant Python components is a bad case of premature optimization <0.3 wink>. > ... > How can we do something similar for Python? Seriously, short of getting MS to distribute Python and put the Python DLLs on The List of refcounted resources, we should pursue this line reluctantly if at all. MS may have a better scheme in the future, but for now better safe than sorry. a-couple-mb-on-a-modern-pc-isn't-worth-the-time-it-took- to-read-this -ly y'rs - tim From gstein@lyra.org Mon Jan 3 02:53:24 2000 From: gstein@lyra.org (Greg Stein) Date: Sun, 2 Jan 2000 18:53:24 -0800 (PST) Subject: [Python-Dev] new imputil.py Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1658348780-1657214722-946868004=:412 Content-Type: TEXT/PLAIN; charset=US-ASCII Happy New Year! I've attached a new imputil.py to this message. It isn't posted on my page yet, as I'd like some feedback before declaring this new version viable. In this imputil, there is an ImportManager class. It gets installed as the import hook, with the presumption that it is the only import hook (technically, it could chain, but I've disabled that for now). I think Python 1.6 should drop the __import__ builtin and move to something like sys.import_hook (to allow examination and change). Another alternative would be sys.get_import_hook() and sys.set_import_hook(). [ I don't think we would want a "set" that returned the old version as the only way to get the current hook function; we want to be able to easily find the ImportManager instance. ] The ImportManager knows how to scan sys.path when it needs to find a top-level module/package (e.g. given a.b.c, the "a" is the top-level; b.c falls "below" that). sys.path can contain strings which specify a filesystem directory, or it can contain Importer instances. The manager also records an ordered list of suffix/importer pairs. The add_suffix() method is used to append new suffixes, but clients can also access the .suffixes attribute for fine-grained manipulation/ordering. There is a new importer called _FilesystemImporter which understands how to look into a directory for Python modules. It borrows/refers to the ImportManager's .suffixes attribute, using that to find modules in a directory. This is also the Importer that gets associated with each filesystem-based module. The importers used for suffix-based importing are derived from SuffixImporter. While a function could be used here, future changes will be easier if we presume class instances. The new imputil works fine (use _test_revamp() to switch to the new import mechanism). Importer subclasses using the old imputil should continue to work, although I am deprecating the 2-tuple return value for get_code(). get_code() should return None or the 3-tuple form now. I think I still have a bit more work to do, to enable something like "import a.b.c" where a.zip is an archive on the path and "b.c" resides in the archive. Note: it *is* possible to do sys.path.append(ZipImporter(filename)) and have "a.b.c" in the Zip file. It would simply be nicer to be able to drop arbitrary .zip files onto the path and use their basename as the top-level name of a package. Anyhow: I haven't looked at this scenario yet to find what the new system is missing (if anything). As always: feedback is more than appreciated! Especially from people using imputil today. Did I break anything? Does the new scheme still feel right to you? etc. Cheers, -g p.s. I'd also like to remove PackageArchiveImporter and PackageArchive. They don't seem to add any real value. I might move DirectoryImporter and PathImporter to an "examples" file, too. -- Greg Stein, http://www.lyra.org/ --1658348780-1657214722-946868004=:412 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="imputil.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="imputil.py" Iw0KIyBpbXB1dGlsLnB5DQojDQojIFdyaXR0ZW4gYnkgR3JlZyBTdGVpbi4g UHVibGljIERvbWFpbi4NCiMgTm8gQ29weXJpZ2h0LCBubyBSaWdodHMgUmVz ZXJ2ZWQsIGFuZCBubyBXYXJyYW50aWVzLg0KIw0KIyBVdGlsaXRpZXMgdG8g aGVscCBvdXQgd2l0aCBjdXN0b20gaW1wb3J0IG1lY2hhbmlzbXMuDQojDQoj IEFkZGl0aW9uYWwgbW9kaWZpY2F0aW9ucyB3ZXJlIGNvbnRyaWJlZCBieSBN YXJjLUFuZHJlIExlbWJ1cmcgYW5kDQojIEdvcmRvbiBNY01pbGxhbi4NCiMN CiMgVGhpcyBtb2R1bGUgaXMgbWFpbnRhaW5lZCBieSBHcmVnIGFuZCBpcyBh dmFpbGFibGUgYXQ6DQojICAgIGh0dHA6Ly93d3cubHlyYS5vcmcvZ3JlZy9w eXRob24vaW1wdXRpbC5weQ0KIw0KIyBTaW5jZSB0aGlzIGlzbid0IGluIHRo ZSBQeXRob24gZGlzdHJpYnV0aW9uIHlldCwgd2UnbGwgdXNlIHRoZSBDVlMg SUQNCiMgZm9yIHRyYWNraW5nOg0KIyAgICRJZDogaW1wdXRpbC5weSx2IDEu OSAyMDAwLzAxLzAzIDAyOjM4OjI5IGdzdGVpbiBFeHAgJA0KIw0KDQojIG5v dGU6IGF2b2lkIGltcG9ydGluZyBub24tYnVpbHRpbiBtb2R1bGVzDQppbXBv cnQgaW1wDQppbXBvcnQgc3lzDQppbXBvcnQgc3Ryb3ANCmltcG9ydCBfX2J1 aWx0aW5fXw0KDQojIGZvciB0aGUgRGlyZWN0b3J5SW1wb3J0ZXINCmltcG9y dCBzdHJ1Y3QNCmltcG9ydCBtYXJzaGFsDQoNCl9TdHJpbmdUeXBlID0gdHlw ZSgnJykNCl9Nb2R1bGVUeXBlID0gdHlwZShzeXMpDQoNCmNsYXNzIEltcG9y dE1hbmFnZXI6DQogICJNYW5hZ2UgdGhlIGltcG9ydCBwcm9jZXNzLiINCg0K ICBkZWYgaW5zdGFsbChzZWxmKToNCiAgICAjIyMgd2FybmluZzogUHl0aG9u IDEuNiB3aWxsIGhhdmUgYSBkaWZmZXJlbnQgaG9vayBtZWNoYW5pc207IHRo aXMNCiAgICAjIyMgY29kZSB3aWxsIG5lZWQgdG8gY2hhbmdlLg0KICAgIHNl bGYuX19jaGFpbl9pbXBvcnQgPSBfX2J1aWx0aW5fXy5fX2ltcG9ydF9fDQog ICAgc2VsZi5fX2NoYWluX3JlbG9hZCA9IF9fYnVpbHRpbl9fLnJlbG9hZA0K ICAgIF9fYnVpbHRpbl9fLl9faW1wb3J0X18gPSBzZWxmLl9pbXBvcnRfaG9v aw0KICAgICMjIyBmaXggdGhpcw0KICAgICNfX2J1aWx0aW5fXy5yZWxvYWQg PSBOb25lDQogICAgI19fYnVpbHRpbl9fLnJlbG9hZCA9IHNlbGYuX3JlbG9h ZF9ob29rDQoNCiAgZGVmIGFkZF9zdWZmaXgoc2VsZiwgc3VmZml4LCBpbXBv cnRlcik6DQogICAgYXNzZXJ0IGlzaW5zdGFuY2UoaW1wb3J0ZXIsIFN1ZmZp eEltcG9ydGVyKQ0KICAgIHNlbGYuc3VmZml4ZXMuYXBwZW5kKChzdWZmaXgs IGltcG9ydGVyKSkNCg0KICAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQog ICMNCiAgIyBQUklWQVRFIE1FVEhPRFMNCiAgIw0KICBkZWYgX19pbml0X18o c2VsZik6DQogICAgIyB3ZSdyZSBkZWZpbml0ZWx5IGdvaW5nIHRvIGJlIGlt cG9ydGluZyBzb21ldGhpbmcgaW4gdGhlIGZ1dHVyZSwNCiAgICAjIHNvIGxl dCdzIGp1c3QgbG9hZCB0aGUgT1MtcmVsYXRlZCBmYWNpbGl0aWVzLg0KICAg IGlmIG5vdCBfb3Nfc3RhdDoNCiAgICAgIF9vc19ib290c3RyYXAoKQ0KDQog ICAgIyBJbml0aWFsaXplIHRoZSBzZXQgb2Ygc3VmZml4ZXMgdGhhdCB3ZSBy ZWNvZ25pemUgYW5kIGltcG9ydC4NCiAgICAjIFRoZSBkZWZhdWx0IHdpbGwg aW1wb3J0IGR5bmFtaWMtbG9hZCBtb2R1bGVzIGZpcnN0LCBmb2xsb3dlZCBi eQ0KICAgICMgLnB5IGZpbGVzIChvciBhIC5weSBmaWxlJ3MgY2FjaGVkIGJ5 dGVjb2RlKQ0KICAgIHNlbGYuc3VmZml4ZXMgPSBbIF0NCiAgICBmb3IgZGVz YyBpbiBpbXAuZ2V0X3N1ZmZpeGVzKCk6DQogICAgICBpZiBkZXNjWzJdID09 IGltcC5DX0VYVEVOU0lPTjoNCiAgICAgICAgc2VsZi5zdWZmaXhlcy5hcHBl bmQoKGRlc2NbMF0sIER5bkxvYWRTdWZmaXhJbXBvcnRlcihkZXNjKSkpDQog ICAgc2VsZi5zdWZmaXhlcy5hcHBlbmQoKCcucHknLCBQeVN1ZmZpeEltcG9y dGVyKCkpKQ0KDQogICAgIyBUaGlzIGlzIHRoZSBpbXBvcnRlciB0aGF0IHdl IHVzZSBmb3IgZ3JhYmJpbmcgc3R1ZmYgZnJvbSB0aGUNCiAgICAjIGZpbGVz eXN0ZW0uIEl0IGRlZmluZXMgb25lIG1vcmUgbWV0aG9kIChpbXBvcnRfZnJv bV9kaXIpIGZvciBvdXIgdXNlLg0KICAgIHNlbGYuZnNfaW1wID0gX0ZpbGVz eXN0ZW1JbXBvcnRlcihzZWxmLnN1ZmZpeGVzKQ0KDQogIGRlZiBfaW1wb3J0 X2hvb2soc2VsZiwgZnFuYW1lLCBnbG9iYWxzPU5vbmUsIGxvY2Fscz1Ob25l LCBmcm9tbGlzdD1Ob25lKToNCiAgICAiIiJQeXRob24gY2FsbHMgdGhpcyBo b29rIHRvIGxvY2F0ZSBhbmQgaW1wb3J0IGEgbW9kdWxlLiIiIg0KDQogICAg cGFydHMgPSBzdHJvcC5zcGxpdChmcW5hbWUsICcuJykNCg0KICAgICMgZGV0 ZXJtaW5lIHRoZSBjb250ZXh0IG9mIHRoaXMgaW1wb3J0DQogICAgcGFyZW50 ID0gc2VsZi5fZGV0ZXJtaW5lX2ltcG9ydF9jb250ZXh0KGdsb2JhbHMpDQoN CiAgICAjIGlmIHRoZXJlIGlzIGEgcGFyZW50LCB0aGVuIGl0cyBpbXBvcnRl ciBzaG91bGQgbWFuYWdlIHRoaXMgaW1wb3J0DQogICAgaWYgcGFyZW50Og0K ICAgICAgbW9kdWxlID0gcGFyZW50Ll9faW1wb3J0ZXJfXy5fZG9faW1wb3J0 KHBhcmVudCwgcGFydHMsIGZyb21saXN0KQ0KICAgICAgaWYgbW9kdWxlOg0K ICAgICAgICByZXR1cm4gbW9kdWxlDQoNCiAgICAjIGhhcyB0aGUgdG9wIG1v ZHVsZSBhbHJlYWR5IGJlZW4gaW1wb3J0ZWQ/DQogICAgdHJ5Og0KICAgICAg dG9wX21vZHVsZSA9IHN5cy5tb2R1bGVzW3BhcnRzWzBdXQ0KICAgIGV4Y2Vw dCBLZXlFcnJvcjoNCg0KICAgICAgIyBsb29rIGZvciB0aGUgdG9wbW9zdCBt b2R1bGUNCiAgICAgIHRvcF9tb2R1bGUgPSBzZWxmLl9pbXBvcnRfdG9wX21v ZHVsZShwYXJ0c1swXSkNCiAgICAgIGlmIG5vdCB0b3BfbW9kdWxlOg0KICAg ICAgICAjIHRoZSB0b3Btb3N0IG1vZHVsZSB3YXNuJ3QgZm91bmQgYXQgYWxs Lg0KICAgICAgICByYWlzZSBJbXBvcnRFcnJvciwgJ05vIG1vZHVsZSBuYW1l ZCAnICsgZnFuYW1lDQogICAgICAgIHJldHVybiBzZWxmLl9fY2hhaW5faW1w b3J0KG5hbWUsIGdsb2JhbHMsIGxvY2FscywgZnJvbWxpc3QpDQoNCiAgICAj IGZhc3QtcGF0aCBzaW1wbGUgaW1wb3J0cw0KICAgIGlmIGxlbihwYXJ0cykg PT0gMToNCiAgICAgIGlmIG5vdCBmcm9tbGlzdDoNCiAgICAgICAgcmV0dXJu IHRvcF9tb2R1bGUNCg0KICAgICAgaWYgbm90IHRvcF9tb2R1bGUuX19kaWN0 X18uZ2V0KCdfX2lzcGtnX18nKToNCiAgICAgICAgIyBfX2lzcGtnX18gaXNu J3QgZGVmaW5lZCAodGhlIG1vZHVsZSB3YXMgbm90IGltcG9ydGVkIGJ5IHVz KSwgb3INCiAgICAgICAgIyBpdCBpcyB6ZXJvLg0KICAgICAgICAjDQogICAg ICAgICMgSW4gdGhlIGZvcm1lciBjYXNlLCB0aGVyZSBpcyBubyB3YXkgdGhh dCB3ZSBjb3VsZCBpbXBvcnQNCiAgICAgICAgIyBzdWItbW9kdWxlcyB0aGF0 IG9jY3VyIGluIHRoZSBmcm9tbGlzdCAoYnV0IHdlIGNhbid0IHJhaXNlIGFu DQogICAgICAgICMgZXJyb3IgYmVjYXVzZSBpdCBtYXkganVzdCBiZSBuYW1l cykgYmVjYXVzZSB3ZSBkb24ndCBrbm93IGhvdw0KICAgICAgICAjIHRvIGRl YWwgd2l0aCBwYWNrYWdlcyB0aGF0IHdlcmUgaW1wb3J0ZWQgYnkgb3RoZXIg c3lzdGVtcy4NCiAgICAgICAgIw0KICAgICAgICAjIEluIHRoZSBsYXR0ZXIg Y2FzZSAoX19pc3BrZ19fID09IDApLCB0aGVyZSBjYW4ndCBiZSBhbnkgc3Vi LQ0KICAgICAgICAjIG1vZHVsZXMgcHJlc2VudCwgc28gd2UgY2FuIGp1c3Qg cmV0dXJuLg0KICAgICAgICAjDQogICAgICAgICMgSW4gYm90aCBjYXNlcywg c2luY2UgbGVuKHBhcnRzKSA9PSAxLCB0aGUgdG9wX21vZHVsZSBpcyBhbHNv DQogICAgICAgICMgdGhlICJib3R0b20iIHdoaWNoIGlzIHRoZSBkZWZpbmVk IHJldHVybiB3aGVuIGEgZnJvbWxpc3QgZXhpc3RzLg0KICAgICAgICByZXR1 cm4gdG9wX21vZHVsZQ0KDQogICAgaW1wb3J0ZXIgPSB0b3BfbW9kdWxlLl9f ZGljdF9fLmdldCgnX19pbXBvcnRlcl9fJykNCiAgICBpZiBpbXBvcnRlcjoN CiAgICAgIHJldHVybiBpbXBvcnRlci5fZmluaXNoX2ltcG9ydCh0b3BfbW9k dWxlLCBwYXJ0c1sxOl0sIGZyb21saXN0KQ0KDQogICAgIyBJZiB0aGUgaW1w b3J0ZXIgZG9lcyBub3QgZXhpc3QsIHRoZW4gd2UgaGF2ZSB0byBiYWlsLiBB IG1pc3NpbmcgaW1wb3J0ZXINCiAgICAjIG1lYW5zIHRoYXQgc29tZXRoaW5n IGVsc2UgaW1wb3J0ZWQgdGhlIG1vZHVsZSwgYW5kIHdlIGhhdmUgbm8ga25v d2xlZGdlDQogICAgIyBvZiBob3cgdG8gZ2V0IHN1Yi1tb2R1bGVzIG91dCBv ZiB0aGUgdGhpbmcuDQogICAgcmFpc2UgSW1wb3J0RXJyb3IsICdObyBtb2R1 bGUgbmFtZWQgJyArIGZxbmFtZQ0KICAgIHJldHVybiBzZWxmLl9fY2hhaW5f aW1wb3J0KG5hbWUsIGdsb2JhbHMsIGxvY2FscywgZnJvbWxpc3QpDQoNCiAg ZGVmIF9kZXRlcm1pbmVfaW1wb3J0X2NvbnRleHQoc2VsZiwgZ2xvYmFscyk6 DQogICAgIiIiUmV0dXJucyB0aGUgY29udGV4dCBpbiB3aGljaCBhIG1vZHVs ZSBzaG91bGQgYmUgaW1wb3J0ZWQuDQoNCiAgICBUaGUgY29udGV4dCBjb3Vs ZCBiZSBhIGxvYWRlZCAocGFja2FnZSkgbW9kdWxlIGFuZCB0aGUgaW1wb3J0 ZWQgbW9kdWxlDQogICAgd2lsbCBiZSBsb29rZWQgZm9yIHdpdGhpbiB0aGF0 IHBhY2thZ2UuIFRoZSBjb250ZXh0IGNvdWxkIGFsc28gYmUgTm9uZSwNCiAg ICBtZWFuaW5nIHRoZXJlIGlzIG5vIGNvbnRleHQgLS0gdGhlIG1vZHVsZSBz aG91bGQgYmUgbG9va2VkIGZvciBhcyBhDQogICAgInRvcC1sZXZlbCIgbW9k dWxlLg0KICAgICIiIg0KDQogICAgaWYgbm90IGdsb2JhbHMgb3Igbm90IGds b2JhbHMuZ2V0KCdfX2ltcG9ydGVyX18nKToNCiAgICAgICMgZ2xvYmFscyBk b2VzIG5vdCByZWZlciB0byBvbmUgb2Ygb3VyIG1vZHVsZXMgb3IgcGFja2Fn ZXMuIFRoYXQNCiAgICAgICMgaW1wbGllcyB0aGVyZSBpcyBubyByZWxhdGl2 ZSBpbXBvcnQgY29udGV4dCAoYXMgZmFyIGFzIHdlIGFyZQ0KICAgICAgIyBj b25jZXJuZWQpLCBhbmQgaXQgc2hvdWxkIGp1c3QgcGljayBpdCBvZmYgdGhl IHN0YW5kYXJkIHBhdGguDQogICAgICByZXR1cm4gTm9uZQ0KDQogICAgIyBU aGUgZ2xvYmFscyByZWZlciB0byBhIG1vZHVsZSBvciBwYWNrYWdlIG9mIG91 cnMuIEl0IHdpbGwgZGVmaW5lDQogICAgIyB0aGUgY29udGV4dCBvZiB0aGUg bmV3IGltcG9ydC4gR2V0IHRoZSBtb2R1bGUvcGFja2FnZSBmcW5hbWUuDQog ICAgcGFyZW50X2ZxbmFtZSA9IGdsb2JhbHNbJ19fbmFtZV9fJ10NCg0KICAg ICMgaWYgYSBwYWNrYWdlIGlzIHBlcmZvcm1pbmcgdGhlIGltcG9ydCwgdGhl biByZXR1cm4gaXRzZWxmIChpbXBvcnRzDQogICAgIyByZWZlciB0byBwa2cg Y29udGVudHMpDQogICAgaWYgZ2xvYmFsc1snX19pc3BrZ19fJ106DQogICAg ICBwYXJlbnQgPSBzeXMubW9kdWxlc1twYXJlbnRfZnFuYW1lXQ0KICAgICAg YXNzZXJ0IGdsb2JhbHMgaXMgcGFyZW50Ll9fZGljdF9fDQogICAgICByZXR1 cm4gcGFyZW50DQoNCiAgICBpID0gc3Ryb3AucmZpbmQocGFyZW50X2ZxbmFt ZSwgJy4nKQ0KDQogICAgIyBhIG1vZHVsZSBvdXRzaWRlIG9mIGEgcGFja2Fn ZSBoYXMgbm8gcGFydGljdWxhciBpbXBvcnQgY29udGV4dA0KICAgIGlmIGkg PT0gLTE6DQogICAgICByZXR1cm4gTm9uZQ0KDQogICAgIyBpZiBhIG1vZHVs ZSBpbiBhIHBhY2thZ2UgaXMgcGVyZm9ybWluZyB0aGUgaW1wb3J0LCB0aGVu IHJldHVybiB0aGUNCiAgICAjIHBhY2thZ2UgKGltcG9ydHMgcmVmZXIgdG8g c2libGluZ3MpDQogICAgcGFyZW50X2ZxbmFtZSA9IHBhcmVudF9mcW5hbWVb OmldDQogICAgcGFyZW50ID0gc3lzLm1vZHVsZXNbcGFyZW50X2ZxbmFtZV0N CiAgICBhc3NlcnQgcGFyZW50Ll9fbmFtZV9fID09IHBhcmVudF9mcW5hbWUN CiAgICByZXR1cm4gcGFyZW50DQoNCiAgZGVmIF9pbXBvcnRfdG9wX21vZHVs ZShzZWxmLCBuYW1lKToNCiAgICAjIHNjYW4gc3lzLnBhdGggbG9va2luZyBm b3IgYSBsb2NhdGlvbiBpbiB0aGUgZmlsZXN5c3RlbSB0aGF0IGNvbnRhaW5z DQogICAgIyB0aGUgbW9kdWxlLCBvciBhbiBJbXBvcnRlciBvYmplY3QgdGhh dCBjYW4gaW1wb3J0IHRoZSBtb2R1bGUuDQogICAgZm9yIGl0ZW0gaW4gc3lz LnBhdGg6DQogICAgICBpZiB0eXBlKGl0ZW0pID09IF9TdHJpbmdUeXBlOg0K ICAgICAgICBtb2R1bGUgPSBzZWxmLmZzX2ltcC5pbXBvcnRfZnJvbV9kaXIo aXRlbSwgbmFtZSkNCiAgICAgIGVsc2U6DQogICAgICAgIG1vZHVsZSA9IGl0 ZW0uaW1wb3J0X3RvcChuYW1lKQ0KICAgICAgaWYgbW9kdWxlOg0KICAgICAg ICByZXR1cm4gbW9kdWxlDQogICAgcmV0dXJuIE5vbmUNCg0KICBkZWYgX3Jl bG9hZF9ob29rKHNlbGYsIG1vZHVsZSk6DQogICAgIlB5dGhvbiBjYWxscyB0 aGlzIGhvb2sgdG8gcmVsb2FkIGEgbW9kdWxlLiINCg0KICAgICMgcmVsb2Fk aW5nIG9mIGEgbW9kdWxlIG1heSBvciBtYXkgbm90IGJlIHBvc3NpYmxlIChk ZXBlbmRpbmcgb24gdGhlDQogICAgIyBpbXBvcnRlciksIGJ1dCBhdCBsZWFz dCB3ZSBjYW4gdmFsaWRhdGUgdGhhdCBpdCdzIG91cnMgdG8gcmVsb2FkDQog ICAgaW1wb3J0ZXIgPSBtb2R1bGUuX19kaWN0X18uZ2V0KCdfX2ltcG9ydGVy X18nKQ0KICAgIGlmIG5vdCBpbXBvcnRlcjoNCiAgICAgIHJldHVybiBzZWxm Ll9fY2hhaW5fcmVsb2FkKG1vZHVsZSkNCg0KICAgICMgb2theS4gaXQgaXMg dXNpbmcgdGhlIGltcHV0aWwgc3lzdGVtLCBhbmQgd2UgbXVzdCBkZWxlZ2F0 ZSBpdCwgYnV0DQogICAgIyB3ZSBkb24ndCBrbm93IHdoYXQgdG8gZG8gKHll dCkNCiAgICAjIyMgd2Ugc2hvdWxkIGJsYXN0IHRoZSBtb2R1bGUgZGljdCBh bmQgZG8gYW5vdGhlciBnZXRfY29kZSgpLiBuZWVkIHRvDQogICAgIyMjIGZs ZXNoIHRoaXMgb3V0IGFuZCBhZGQgcHJvcGVyIGRvY2NvLi4uDQogICAgcmFp c2UgU3lzdGVtRXJyb3IsICJyZWxvYWQgbm90IHlldCBpbXBsZW1lbnRlZCIN Cg0KDQpjbGFzcyBJbXBvcnRlcjoNCiAgIkJhc2UgY2xhc3MgZm9yIHJlcGxh Y2luZyBzdGFuZGFyZCBpbXBvcnQgZnVuY3Rpb25zLiINCg0KICBkZWYgaW5z dGFsbChzZWxmKToNCiAgICBzeXMucGF0aC5pbnNlcnQoMCwgc2VsZikNCg0K ICBkZWYgaW1wb3J0X3RvcChzZWxmLCBuYW1lKToNCiAgICAiSW1wb3J0IGEg dG9wLWxldmVsIG1vZHVsZS4iDQogICAgcmV0dXJuIHNlbGYuX2ltcG9ydF9v bmUoTm9uZSwgbmFtZSwgbmFtZSkNCg0KICAjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjDQogICMNCiAgIyBQUklWQVRFIE1FVEhPRFMNCiAgIw0KICBkZWYg X2ZpbmlzaF9pbXBvcnQoc2VsZiwgdG9wLCBwYXJ0cywgZnJvbWxpc3QpOg0K ICAgICMgaWYgImEuYi5jIiB3YXMgcHJvdmlkZWQsIHRoZW4gbG9hZCB0aGUg Ii5iLmMiIHBvcnRpb24gZG93biBmcm9tDQogICAgIyBiZWxvdyB0aGUgdG9w LWxldmVsIG1vZHVsZS4NCiAgICBib3R0b20gPSBzZWxmLl9sb2FkX3RhaWwo dG9wLCBwYXJ0cykNCg0KICAgICMgaWYgdGhlIGZvcm0gaXMgImltcG9ydCBh LmIuYyIsIHRoZW4gcmV0dXJuICJhIg0KICAgIGlmIG5vdCBmcm9tbGlzdDoN CiAgICAgICMgbm8gZnJvbWxpc3Q6IHJldHVybiB0aGUgdG9wIG9mIHRoZSBp bXBvcnQgdHJlZQ0KICAgICAgcmV0dXJuIHRvcA0KDQogICAgIyB0aGUgdG9w IG1vZHVsZSB3YXMgaW1wb3J0ZWQgYnkgc2VsZi4NCiAgICAjDQogICAgIyB0 aGlzIG1lYW5zIHRoYXQgdGhlIGJvdHRvbSBtb2R1bGUgd2FzIGFsc28gaW1w b3J0ZWQgYnkgc2VsZiAoanVzdA0KICAgICMgbm93LCBvciBpbiB0aGUgcGFz dCBhbmQgd2UgZmV0Y2hlZCBpdCBmcm9tIHN5cy5tb2R1bGVzKS4NCiAgICAj DQogICAgIyBzaW5jZSB3ZSBpbXBvcnRlZC9oYW5kbGVkIHRoZSBib3R0b20g bW9kdWxlLCB0aGlzIG1lYW5zIHRoYXQgd2UgY2FuDQogICAgIyBhbHNvIGhh bmRsZSBpdHMgZnJvbWxpc3QgKGFuZCByZWxpYWJseSB1c2UgX19pc3BrZ19f KS4NCg0KICAgICMgaWYgdGhlIGJvdHRvbSBub2RlIGlzIGEgcGFja2FnZSwg dGhlbiAocG90ZW50aWFsbHkpIGltcG9ydCBzb21lIG1vZHVsZXMuDQogICAg Iw0KICAgICMgbm90ZTogaWYgaXQgaXMgbm90IGEgcGFja2FnZSwgdGhlbiAi ZnJvbWxpc3QiIHJlZmVycyB0byBuYW1lcyBpbg0KICAgICMgICAgICAgdGhl IGJvdHRvbSBtb2R1bGUgcmF0aGVyIHRoYW4gbW9kdWxlcy4NCiAgICAjIG5v dGU6IGZvciBhIG1peCBvZiBuYW1lcyBhbmQgbW9kdWxlcyBpbiB0aGUgZnJv bWxpc3QsIHdlIHdpbGwNCiAgICAjICAgICAgIGltcG9ydCBhbGwgbW9kdWxl cyBhbmQgaW5zZXJ0IHRob3NlIGludG8gdGhlIG5hbWVzcGFjZSBvZg0KICAg ICMgICAgICAgdGhlIHBhY2thZ2UgbW9kdWxlLiBQeXRob24gd2lsbCBwaWNr IHVwIGFsbCBmcm9tbGlzdCBuYW1lcw0KICAgICMgICAgICAgZnJvbSB0aGUg Ym90dG9tIChwYWNrYWdlKSBtb2R1bGU7IHNvbWUgd2lsbCBiZSBtb2R1bGVz IHRoYXQNCiAgICAjICAgICAgIHdlIGltcG9ydGVkIGFuZCBzdG9yZWQgaW4g dGhlIG5hbWVzcGFjZSwgb3RoZXJzIGFyZSBleHBlY3RlZA0KICAgICMgICAg ICAgdG8gYmUgcHJlc2VudCBhbHJlYWR5Lg0KICAgIGlmIGJvdHRvbS5fX2lz cGtnX186DQogICAgICBzZWxmLl9pbXBvcnRfZnJvbWxpc3QoYm90dG9tLCBm cm9tbGlzdCkNCg0KICAgICMgaWYgdGhlIGZvcm0gaXMgImZyb20gYS5iIGlt cG9ydCBjLCBkIiB0aGVuIHJldHVybiAiYiINCiAgICByZXR1cm4gYm90dG9t DQoNCiAgZGVmIF9pbXBvcnRfb25lKHNlbGYsIHBhcmVudCwgbW9kbmFtZSwg ZnFuYW1lKToNCiAgICAiSW1wb3J0IGEgc2luZ2xlIG1vZHVsZS4iDQoNCiAg ICAjIGhhcyB0aGUgbW9kdWxlIGFscmVhZHkgYmVlbiBpbXBvcnRlZD8NCiAg ICB0cnk6DQogICAgICByZXR1cm4gc3lzLm1vZHVsZXNbZnFuYW1lXQ0KICAg IGV4Y2VwdCBLZXlFcnJvcjoNCiAgICAgIHBhc3MNCg0KICAgICMgbG9hZCB0 aGUgbW9kdWxlJ3MgY29kZSwgb3IgZmV0Y2ggdGhlIG1vZHVsZSBpdHNlbGYN CiAgICByZXN1bHQgPSBzZWxmLmdldF9jb2RlKHBhcmVudCwgbW9kbmFtZSwg ZnFuYW1lKQ0KICAgIGlmIHJlc3VsdCBpcyBOb25lOg0KICAgICAgcmV0dXJu IE5vbmUNCg0KICAgICMjIyBiYWNrd2FyZHMtY29tcGF0DQogICAgaWYgbGVu KHJlc3VsdCkgPT0gMjoNCiAgICAgIHJlc3VsdCA9IHJlc3VsdCArICh7fSwp DQoNCiAgICBtb2R1bGUgPSBzZWxmLl9wcm9jZXNzX3Jlc3VsdChyZXN1bHQs IGZxbmFtZSkNCg0KICAgICMgaW5zZXJ0IHRoZSBtb2R1bGUgaW50byBpdHMg cGFyZW50DQogICAgaWYgcGFyZW50Og0KICAgICAgc2V0YXR0cihwYXJlbnQs IG1vZG5hbWUsIG1vZHVsZSkNCiAgICByZXR1cm4gbW9kdWxlDQoNCiAgZGVm IF9wcm9jZXNzX3Jlc3VsdChzZWxmLCAoaXNwa2csIGNvZGUsIHZhbHVlcyks IGZxbmFtZSk6DQogICAgIyBkaWQgZ2V0X2NvZGUoKSByZXR1cm4gYW4gYWN0 dWFsIG1vZHVsZT8gKHJhdGhlciB0aGFuIGEgY29kZSBvYmplY3QpDQogICAg aXNfbW9kdWxlID0gdHlwZShjb2RlKSBpcyBfTW9kdWxlVHlwZQ0KDQogICAg IyB1c2UgdGhlIHJldHVybmVkIG1vZHVsZSwgb3IgY3JlYXRlIGEgbmV3IG9u ZSB0byBleGVjIGNvZGUgaW50bw0KICAgIGlmIGlzX21vZHVsZToNCiAgICAg IG1vZHVsZSA9IGNvZGUNCiAgICBlbHNlOg0KICAgICAgbW9kdWxlID0gaW1w Lm5ld19tb2R1bGUoZnFuYW1lKQ0KDQogICAgIyMjIHJlY29yZCBwYWNrYWdl cyBhIGJpdCBkaWZmZXJlbnRseT8/DQogICAgbW9kdWxlLl9faW1wb3J0ZXJf XyA9IHNlbGYNCiAgICBtb2R1bGUuX19pc3BrZ19fID0gaXNwa2cNCg0KICAg ICMgaW5zZXJ0IGFkZGl0aW9uYWwgdmFsdWVzIGludG8gdGhlIG1vZHVsZSAo YmVmb3JlIGV4ZWN1dGluZyB0aGUgY29kZSkNCiAgICBtb2R1bGUuX19kaWN0 X18udXBkYXRlKHZhbHVlcykNCg0KICAgICMgdGhlIG1vZHVsZSBpcyBhbG1v c3QgcmVhZHkuLi4gbWFrZSBpdCB2aXNpYmxlDQogICAgc3lzLm1vZHVsZXNb ZnFuYW1lXSA9IG1vZHVsZQ0KDQogICAgIyBleGVjdXRlIHRoZSBjb2RlIHdp dGhpbiB0aGUgbW9kdWxlJ3MgbmFtZXNwYWNlDQogICAgaWYgbm90IGlzX21v ZHVsZToNCiAgICAgIGV4ZWMgY29kZSBpbiBtb2R1bGUuX19kaWN0X18NCg0K ICAgIHJldHVybiBtb2R1bGUNCg0KICBkZWYgX2xvYWRfdGFpbChzZWxmLCBt LCBwYXJ0cyk6DQogICAgIiIiSW1wb3J0IHRoZSByZXN0IG9mIHRoZSBtb2R1 bGVzLCBkb3duIGZyb20gdGhlIHRvcC1sZXZlbCBtb2R1bGUuDQoNCiAgICBS ZXR1cm5zIHRoZSBsYXN0IG1vZHVsZSBpbiB0aGUgZG90dGVkIGxpc3Qgb2Yg bW9kdWxlcy4NCiAgICAiIiINCiAgICBmb3IgcGFydCBpbiBwYXJ0czoNCiAg ICAgIGZxbmFtZSA9ICIlcy4lcyIgJSAobS5fX25hbWVfXywgcGFydCkNCiAg ICAgIG0gPSBzZWxmLl9pbXBvcnRfb25lKG0sIHBhcnQsIGZxbmFtZSkNCiAg ICAgIGlmIG5vdCBtOg0KICAgICAgICByYWlzZSBJbXBvcnRFcnJvciwgIk5v IG1vZHVsZSBuYW1lZCAiICsgZnFuYW1lDQogICAgcmV0dXJuIG0NCg0KICBk ZWYgX2ltcG9ydF9mcm9tbGlzdChzZWxmLCBwYWNrYWdlLCBmcm9tbGlzdCk6 DQogICAgJ0ltcG9ydCBhbnkgc3ViLW1vZHVsZXMgaW4gdGhlICJmcm9tIiBs aXN0LicNCg0KICAgICMgaWYgJyonIGlzIHByZXNlbnQgaW4gdGhlIGZyb21s aXN0LCB0aGVuIGxvb2sgZm9yIHRoZSAnX19hbGxfXycgdmFyaWFibGUNCiAg ICAjIHRvIGZpbmQgYWRkaXRpb25hbCBpdGVtcyAobW9kdWxlcykgdG8gaW1w b3J0Lg0KICAgIGlmICcqJyBpbiBmcm9tbGlzdDoNCiAgICAgIGZyb21saXN0 ID0gbGlzdChmcm9tbGlzdCkgKyBsaXN0KHBhY2thZ2UuX19kaWN0X18uZ2V0 KCdfX2FsbF9fJywgW10pKQ0KDQogICAgZm9yIHN1YiBpbiBmcm9tbGlzdDoN CiAgICAgICMgaWYgdGhlIG5hbWUgaXMgYWxyZWFkeSBwcmVzZW50LCB0aGVu IGRvbid0IHRyeSB0byBpbXBvcnQgaXQgKGl0DQogICAgICAjIG1pZ2h0IG5v dCBiZSBhIG1vZHVsZSEpLg0KICAgICAgaWYgc3ViICE9ICcqJyBhbmQgbm90 IGhhc2F0dHIocGFja2FnZSwgc3ViKToNCiAgICAgICAgc3VibmFtZSA9ICIl cy4lcyIgJSAocGFja2FnZS5fX25hbWVfXywgc3ViKQ0KICAgICAgICBzdWJt b2QgPSBzZWxmLl9pbXBvcnRfb25lKHBhY2thZ2UsIHN1Yiwgc3VibmFtZSkN CiAgICAgICAgaWYgbm90IHN1Ym1vZDoNCiAgICAgICAgICByYWlzZSBJbXBv cnRFcnJvciwgImNhbm5vdCBpbXBvcnQgbmFtZSAiICsgc3VibmFtZQ0KDQog IGRlZiBfZG9faW1wb3J0KHNlbGYsIHBhcmVudCwgcGFydHMsIGZyb21saXN0 KToNCiAgICAiIiJBdHRlbXB0IHRvIGltcG9ydCB0aGUgbW9kdWxlIHJlbGF0 aXZlIHRvIHBhcmVudC4NCg0KICAgIFRoaXMgbWV0aG9kIGlzIHVzZWQgd2hl biB0aGUgaW1wb3J0IGNvbnRleHQgc3BlY2lmaWVzIHRoYXQgPHNlbGY+DQog ICAgaW1wb3J0ZWQgdGhlIHBhcmVudCBtb2R1bGUuDQogICAgIiIiDQogICAg dG9wX25hbWUgPSBwYXJ0c1swXQ0KICAgIHRvcF9mcW5hbWUgPSBwYXJlbnQu X19uYW1lX18gKyAnLicgKyB0b3BfbmFtZQ0KICAgIHRvcF9tb2R1bGUgPSBz ZWxmLl9pbXBvcnRfb25lKHBhcmVudCwgdG9wX25hbWUsIHRvcF9mcW5hbWUp DQogICAgaWYgbm90IHRvcF9tb2R1bGU6DQogICAgICAjIHRoaXMgaW1wb3J0 ZXIgYW5kIHBhcmVudCBjb3VsZCBub3QgZmluZCB0aGUgbW9kdWxlIChyZWxh dGl2ZWx5KQ0KICAgICAgcmV0dXJuIE5vbmUNCg0KICAgIHJldHVybiBzZWxm Ll9maW5pc2hfaW1wb3J0KHRvcF9tb2R1bGUsIHBhcnRzWzE6XSwgZnJvbWxp c3QpDQoNCiAgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KICAjDQogICMg TUVUSE9EUyBUTyBPVkVSUklERQ0KICAjDQogIGRlZiBnZXRfY29kZShzZWxm LCBwYXJlbnQsIG1vZG5hbWUsIGZxbmFtZSk6DQogICAgIiIiRmluZCBhbmQg cmV0cmlldmUgdGhlIGNvZGUgZm9yIHRoZSBnaXZlbiBtb2R1bGUuDQoNCiAg ICBwYXJlbnQgc3BlY2lmaWVzIGEgcGFyZW50IG1vZHVsZSB0byBkZWZpbmUg YSBjb250ZXh0IGZvciBpbXBvcnRpbmcuIEl0DQogICAgbWF5IGJlIE5vbmUs IGluZGljYXRpbmcgbm8gcGFydGljdWxhciBjb250ZXh0IGZvciB0aGUgc2Vh cmNoLg0KDQogICAgbW9kbmFtZSBzcGVjaWZpZXMgYSBzaW5nbGUgbW9kdWxl IChub3QgZG90dGVkKSB3aXRoaW4gdGhlIHBhcmVudC4NCg0KICAgIGZxbmFt ZSBzcGVjaWZpZXMgdGhlIGZ1bGx5LXF1YWxpZmllZCBtb2R1bGUgbmFtZS4g VGhpcyBpcyBhIChwb3RlbnRpYWxseSkNCiAgICBkb3R0ZWQgbmFtZSBmcm9t IHRoZSAicm9vdCIgb2YgdGhlIG1vZHVsZSBuYW1lc3BhY2UgZG93biB0byB0 aGUgbW9kbmFtZS4NCiAgICBJZiB0aGVyZSBpcyBubyBwYXJlbnQsIHRoZW4g bW9kbmFtZT09ZnFuYW1lLg0KDQogICAgVGhpcyBtZXRob2Qgc2hvdWxkIHJl dHVybiBOb25lLCBvciBhIDMtdHVwbGUuDQoNCiAgICAqIElmIHRoZSBtb2R1 bGUgd2FzIG5vdCBmb3VuZCwgdGhlbiBOb25lIHNob3VsZCBiZSByZXR1cm5l ZC4NCg0KICAgICogVGhlIGZpcnN0IGl0ZW0gb2YgdGhlIDItIG9yIDMtdHVw bGUgc2hvdWxkIGJlIHRoZSBpbnRlZ2VyIDAgb3IgMSwNCiAgICAgIHNwZWNp Znlpbmcgd2hldGhlciB0aGUgbW9kdWxlIHRoYXQgd2FzIGZvdW5kIGlzIGEg cGFja2FnZSBvciBub3QuDQoNCiAgICAqIFRoZSBzZWNvbmQgaXRlbSBpcyB0 aGUgY29kZSBvYmplY3QgZm9yIHRoZSBtb2R1bGUgKGl0IHdpbGwgYmUNCiAg ICAgIGV4ZWN1dGVkIHdpdGhpbiB0aGUgbmV3IG1vZHVsZSdzIG5hbWVzcGFj ZSkuIFRoaXMgaXRlbSBjYW4gYWxzbw0KICAgICAgYmUgYSBmdWxseS1sb2Fk ZWQgbW9kdWxlIG9iamVjdCAoZS5nLiBsb2FkZWQgZnJvbSBhIHNoYXJlZCBs aWIpLg0KDQogICAgKiBUaGUgdGhpcmQgaXRlbSBpcyBhIGRpY3Rpb25hcnkg b2YgbmFtZS92YWx1ZSBwYWlycyB0aGF0IHdpbGwgYmUNCiAgICAgIGluc2Vy dGVkIGludG8gbmV3IG1vZHVsZSBiZWZvcmUgdGhlIGNvZGUgb2JqZWN0IGlz IGV4ZWN1dGVkLiBUaGlzDQogICAgICBpcyBwcm92aWRlZCBpbiBjYXNlIHRo ZSBtb2R1bGUncyBjb2RlIGV4cGVjdHMgY2VydGFpbiB2YWx1ZXMgKHN1Y2gN CiAgICAgIGFzIHdoZXJlIHRoZSBtb2R1bGUgd2FzIGZvdW5kKS4gV2hlbiB0 aGUgc2Vjb25kIGl0ZW0gaXMgYSBtb2R1bGUNCiAgICAgIG9iamVjdCwgdGhl biB0aGVzZSBuYW1lcy92YWx1ZXMgd2lsbCBiZSBpbnNlcnRlZCAqYWZ0ZXIq IHRoZSBtb2R1bGUNCiAgICAgIGhhcyBiZWVuIGxvYWRlZC9pbml0aWFsaXpl ZC4NCiAgICAiIiINCiAgICByYWlzZSBSdW50aW1lRXJyb3IsICJnZXRfY29k ZSBub3QgaW1wbGVtZW50ZWQiDQoNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIw0KIw0KIyBTb21lIGhhbmR5IHN0dWZmIGZvciB0aGUgSW1wb3J0ZXJz DQojDQoNCiMgYnl0ZS1jb21waWxlZCBmaWxlIHN1ZmZpYyBjaGFyYWN0ZXIN Cl9zdWZmaXhfY2hhciA9IF9fZGVidWdfXyBhbmQgJ2MnIG9yICdvJw0KDQoj IGJ5dGUtY29tcGlsZWQgZmlsZSBzdWZmaXgNCl9zdWZmaXggPSAnLnB5JyAr IF9zdWZmaXhfY2hhcg0KDQojIHRoZSBDX0VYVEVOU0lPTiBzdWZmaXhlcw0K X2Nfc3VmZml4ZXMgPSBmaWx0ZXIobGFtYmRhIHg6IHhbMl0gPT0gaW1wLkNf RVhURU5TSU9OLCBpbXAuZ2V0X3N1ZmZpeGVzKCkpDQoNCmRlZiBfY29tcGls ZShwYXRobmFtZSwgdGltZXN0YW1wKToNCiAgIiIiQ29tcGlsZSAoYW5kIGNh Y2hlKSBhIFB5dGhvbiBzb3VyY2UgZmlsZS4NCg0KICBUaGUgZmlsZSBzcGVj aWZpZWQgYnkgPHBhdGhuYW1lPiBpcyBjb21waWxlZCB0byBhIGNvZGUgb2Jq ZWN0IGFuZA0KICByZXR1cm5lZC4NCg0KICBQcmVzdW1pbmcgdGhlIGFwcHJv cHJpYXRlIHByaXZpbGVnZXMgZXhpc3QsIHRoZSBieXRlY29kZXMgd2lsbCBi ZQ0KICBzYXZlZCBiYWNrIHRvIHRoZSBmaWxlc3lzdGVtIGZvciBmdXR1cmUg aW1wb3J0cy4gVGhlIHNvdXJjZSBmaWxlJ3MNCiAgbW9kaWZpY2F0aW9uIHRp bWVzdGFtcCBtdXN0IGJlIHByb3ZpZGVkIGFzIGEgTG9uZyB2YWx1ZS4NCiAg IiIiDQogIGNvZGVzdHJpbmcgPSBvcGVuKHBhdGhuYW1lLCAncicpLnJlYWQo KQ0KICBpZiBjb2Rlc3RyaW5nIGFuZCBjb2Rlc3RyaW5nWy0xXSAhPSAnXG4n Og0KICAgIGNvZGVzdHJpbmcgPSBjb2Rlc3RyaW5nICsgJ1xuJw0KICBjb2Rl ID0gX19idWlsdGluX18uY29tcGlsZShjb2Rlc3RyaW5nLCBwYXRobmFtZSwg J2V4ZWMnKQ0KDQogICMgdHJ5IHRvIGNhY2hlIHRoZSBjb21waWxlZCBjb2Rl DQogIHRyeToNCiAgICBmID0gb3BlbihwYXRobmFtZSArIF9zdWZmaXhfY2hh ciwgJ3diJykNCiAgZXhjZXB0IElPRXJyb3I6DQogICAgcGFzcw0KICBlbHNl Og0KICAgIGYud3JpdGUoJ1wwXDBcMFwwJykNCiAgICBmLndyaXRlKHN0cnVj dC5wYWNrKCc8SScsIHRpbWVzdGFtcCkpDQogICAgbWFyc2hhbC5kdW1wKGNv ZGUsIGYpDQogICAgZi5mbHVzaCgpDQogICAgZi5zZWVrKDAsIDApDQogICAg Zi53cml0ZShpbXAuZ2V0X21hZ2ljKCkpDQogICAgZi5jbG9zZSgpDQoNCiAg cmV0dXJuIGNvZGUNCg0KX29zX3N0YXQgPSBfb3NfcGF0aF9qb2luID0gTm9u ZQ0KZGVmIF9vc19ib290c3RyYXAoKToNCiAgIlNldCB1cCAnb3MnIG1vZHVs ZSByZXBsYWNlbWVudCBmdW5jdGlvbnMgZm9yIHVzZSBkdXJpbmcgaW1wb3J0 IGJvb3RzdHJhcC4iDQoNCiAgbmFtZXMgPSBzeXMuYnVpbHRpbl9tb2R1bGVf bmFtZXMNCg0KICBqb2luID0gTm9uZQ0KICBpZiAncG9zaXgnIGluIG5hbWVz Og0KICAgIHNlcCA9ICcvJw0KICAgIGZyb20gcG9zaXggaW1wb3J0IHN0YXQN CiAgZWxpZiAnbnQnIGluIG5hbWVzOg0KICAgIHNlcCA9ICdcXCcNCiAgICBm cm9tIG50IGltcG9ydCBzdGF0DQogIGVsaWYgJ2RvcycgaW4gbmFtZXM6DQog ICAgc2VwID0gJ1xcJw0KICAgIGZyb20gZG9zIGltcG9ydCBzdGF0DQogIGVs aWYgJ29zMicgaW4gbmFtZXM6DQogICAgc2VwID0gJ1xcJw0KICAgIGZyb20g b3MyIGltcG9ydCBzdGF0DQogIGVsaWYgJ21hYycgaW4gbmFtZXM6DQogICAg ZnJvbSBtYWMgaW1wb3J0IHN0YXQNCiAgICBkZWYgam9pbihhLCBiKToNCiAg ICAgIGlmIGEgPT0gJyc6DQogICAgICAgIHJldHVybiBiDQogICAgICBwYXRo ID0gcw0KICAgICAgaWYgJzonIG5vdCBpbiBhOg0KICAgICAgICBhID0gJzon ICsgYQ0KICAgICAgaWYgYVstMTpdIDw+ICc6JzoNCiAgICAgICAgYSA9IGEg KyAnOicNCiAgICAgIHJldHVybiBhICsgYg0KICBlbHNlOg0KICAgIHJhaXNl IEltcG9ydEVycm9yLCAnbm8gb3Mgc3BlY2lmaWMgbW9kdWxlIGZvdW5kJw0K ICANCiAgaWYgam9pbiBpcyBOb25lOg0KICAgIGRlZiBqb2luKGEsIGIsIHNl cD1zZXApOg0KICAgICAgaWYgYSA9PSAnJzoNCiAgICAgICAgcmV0dXJuIGIN CiAgICAgIGxhc3RjaGFyID0gYVstMTpdDQogICAgICBpZiBsYXN0Y2hhciA9 PSAnLycgb3IgbGFzdGNoYXIgPT0gc2VwOg0KICAgICAgICByZXR1cm4gYSAr IGINCiAgICAgIHJldHVybiBhICsgc2VwICsgYg0KDQogIGdsb2JhbCBfb3Nf c3RhdA0KICBfb3Nfc3RhdCA9IHN0YXQNCg0KICBnbG9iYWwgX29zX3BhdGhf am9pbg0KICBfb3NfcGF0aF9qb2luID0gam9pbg0KDQpkZWYgX29zX3BhdGhf aXNkaXIocGF0aG5hbWUpOg0KICAiTG9jYWwgcmVwbGFjZW1lbnQgZm9yIG9z LnBhdGguaXNkaXIoKS4iDQogIHRyeToNCiAgICBzID0gX29zX3N0YXQocGF0 aG5hbWUpDQogIGV4Y2VwdCBPU0Vycm9yOg0KICAgIHJldHVybiBOb25lDQog IHJldHVybiAoc1swXSAmIDAxNzAwMDApID09IDAwNDAwMDANCg0KZGVmIF90 aW1lc3RhbXAocGF0aG5hbWUpOg0KICAiUmV0dXJuIHRoZSBmaWxlIG1vZGlm aWNhdGlvbiB0aW1lIGFzIGEgTG9uZy4iDQogIHRyeToNCiAgICBzID0gX29z X3N0YXQocGF0aG5hbWUpDQogIGV4Y2VwdCBPU0Vycm9yOg0KICAgIHJldHVy biBOb25lDQogIHJldHVybiBsb25nKHNbOF0pDQoNCmRlZiBfZnNfaW1wb3J0 KGRpciwgbW9kbmFtZSwgZnFuYW1lKToNCiAgIkZldGNoIGEgbW9kdWxlIGZy b20gdGhlIGZpbGVzeXN0ZW0uIg0KDQogIHBhdGhuYW1lID0gX29zX3BhdGhf am9pbihkaXIsIG1vZG5hbWUpDQogIGlmIF9vc19wYXRoX2lzZGlyKHBhdGhu YW1lKToNCiAgICB2YWx1ZXMgPSB7ICdfX3BrZ2Rpcl9fJyA6IHBhdGhuYW1l LCAnX19wYXRoX18nIDogWyBwYXRobmFtZSBdIH0NCiAgICBpc3BrZyA9IDEN CiAgICBwYXRobmFtZSA9IF9vc19wYXRoX2pvaW4ocGF0aG5hbWUsICdfX2lu aXRfXycpDQogIGVsc2U6DQogICAgdmFsdWVzID0geyB9DQogICAgaXNwa2cg PSAwDQoNCiAgICAjIGxvb2sgZm9yIGR5bmxvYWQgbW9kdWxlcw0KICAgIGZv ciBkZXNjIGluIF9jX3N1ZmZpeGVzOg0KICAgICAgZmlsZSA9IHBhdGhuYW1l ICsgZGVzY1swXQ0KICAgICAgdHJ5Og0KICAgICAgICBmcCA9IG9wZW4oZmls ZSwgZGVzY1sxXSkNCiAgICAgIGV4Y2VwdCBJT0Vycm9yOg0KICAgICAgICBw YXNzDQogICAgICBlbHNlOg0KICAgICAgICBtb2R1bGUgPSBpbXAubG9hZF9t b2R1bGUoZnFuYW1lLCBmcCwgZmlsZSwgZGVzYykNCiAgICAgICAgdmFsdWVz WydfX2ZpbGVfXyddID0gZmlsZQ0KICAgICAgICByZXR1cm4gMCwgbW9kdWxl LCB2YWx1ZXMNCg0KICB0X3B5ID0gX3RpbWVzdGFtcChwYXRobmFtZSArICcu cHknKQ0KICB0X3B5YyA9IF90aW1lc3RhbXAocGF0aG5hbWUgKyBfc3VmZml4 KQ0KICBpZiB0X3B5IGlzIE5vbmUgYW5kIHRfcHljIGlzIE5vbmU6DQogICAg cmV0dXJuIE5vbmUNCiAgY29kZSA9IE5vbmUNCiAgaWYgdF9weSBpcyBOb25l IG9yICh0X3B5YyBpcyBub3QgTm9uZSBhbmQgdF9weWMgPj0gdF9weSk6DQog ICAgZmlsZSA9IHBhdGhuYW1lICsgX3N1ZmZpeA0KICAgIGYgPSBvcGVuKGZp bGUsICdyYicpDQogICAgaWYgZi5yZWFkKDQpID09IGltcC5nZXRfbWFnaWMo KToNCiAgICAgIHQgPSBzdHJ1Y3QudW5wYWNrKCc8SScsIGYucmVhZCg0KSlb MF0NCiAgICAgIGlmIHQgPT0gdF9weToNCiAgICAgICAgY29kZSA9IG1hcnNo YWwubG9hZChmKQ0KICAgIGYuY2xvc2UoKQ0KICBpZiBjb2RlIGlzIE5vbmU6 DQogICAgZmlsZSA9IHBhdGhuYW1lICsgJy5weScNCiAgICBjb2RlID0gX2Nv bXBpbGUoZmlsZSwgdF9weSkNCg0KICB2YWx1ZXNbJ19fZmlsZV9fJ10gPSBm aWxlDQogIHJldHVybiBpc3BrZywgY29kZSwgdmFsdWVzDQoNCg0KIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0KIyBTaW1wbGUgZnVuY3Rpb24tYmFz ZWQgaW1wb3J0ZXINCiMNCmNsYXNzIEZ1bmNJbXBvcnRlcihJbXBvcnRlcik6 DQogICJJbXBvcnRlciBzdWJjbGFzcyB0byB1c2UgYSBzdXBwbGllZCBmdW5j dGlvbiByYXRoZXIgdGhhbiBtZXRob2Qgb3ZlcnJpZGVzLiINCiAgZGVmIF9f aW5pdF9fKHNlbGYsIGZ1bmMpOg0KICAgIHNlbGYuZnVuYyA9IGZ1bmMNCiAg ZGVmIGdldF9jb2RlKHNlbGYsIHBhcmVudCwgbW9kbmFtZSwgZnFuYW1lKToN CiAgICByZXR1cm4gc2VsZi5mdW5jKHBhcmVudCwgbW9kbmFtZSwgZnFuYW1l KQ0KDQpkZWYgaW5zdGFsbF93aXRoKGZ1bmMpOg0KICBGdW5jSW1wb3J0ZXIo ZnVuYykuaW5zdGFsbCgpDQoNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj Iw0KIw0KIyBCYXNlIGNsYXNzIGZvciBhcmNoaXZlLWJhc2VkIGltcG9ydGlu Zw0KIw0KY2xhc3MgUGFja2FnZUFyY2hpdmVJbXBvcnRlcihJbXBvcnRlcik6 DQogICIiIkltcG9ydGVyIHN1YmNsYXNzIHRvIGltcG9ydCBmcm9tIChmaWxl KSBhcmNoaXZlcy4NCg0KICBUaGlzIEltcG9ydGVyIGhhbmRsZXMgaW1wb3J0 cyBvZiB0aGUgc3R5bGUgPGFyY2hpdmU+LjxzdWJmaWxlPiwgd2hlcmUNCiAg PGFyY2hpdmU+IGNhbiBiZSBsb2NhdGVkIHVzaW5nIGEgc3ViY2xhc3Mtc3Bl Y2lmaWMgbWVjaGFuaXNtIGFuZCB0aGUNCiAgPHN1YmZpbGU+IGlzIGZvdW5k IGluIHRoZSBhcmNoaXZlIHVzaW5nIGEgc3ViY2xhc3Mtc3BlY2lmaWMgbWVj aGFuaXNtLg0KDQogIFRoaXMgY2xhc3MgZGVmaW5lcyB0d28gaG9va3MgZm9y IHN1YmNsYXNzZXM6IG9uZSB0byBsb2NhdGUgYW4gYXJjaGl2ZQ0KICAoYW5k IHBvc3NpYmx5IHJldHVybiBzb21lIGNvbnRleHQgZm9yIGZ1dHVyZSBzdWJm aWxlIGxvb2t1cHMpLCBhbmQgb25lDQogIHRvIGxvY2F0ZSBzdWJmaWxlcy4N CiAgIiIiDQoNCiAgZGVmIGdldF9jb2RlKHNlbGYsIHBhcmVudCwgbW9kbmFt ZSwgZnFuYW1lKToNCiAgICBpZiBwYXJlbnQ6DQogICAgICAjIHRoZSBJbXBv cnRlci5fZmluaXNoX2ltcG9ydCBsb2dpYyBlbnN1cmVzIHRoYXQgd2UgaGFu ZGxlIGltcG9ydHMNCiAgICAgICMgdW5kZXIgdGhlIHRvcCBsZXZlbCBtb2R1 bGUgKHBhY2thZ2UgLyBhcmNoaXZlKS4NCiAgICAgIGFzc2VydCBwYXJlbnQu X19pbXBvcnRlcl9fID09IHNlbGYNCg0KICAgICAgIyBpZiBhIHBhcmVudCAi cGFja2FnZSIgaXMgcHJvdmlkZWQsIHRoZW4gd2UgYXJlIGltcG9ydGluZyBh IHN1Yi1maWxlDQogICAgICAjIGZyb20gdGhlIGFyY2hpdmUuDQogICAgICBy ZXN1bHQgPSBzZWxmLmdldF9zdWJmaWxlKHBhcmVudC5fX2FyY2hpdmVfXywg bW9kbmFtZSkNCiAgICAgIGlmIHJlc3VsdCBpcyBOb25lOg0KICAgICAgICBy ZXR1cm4gTm9uZQ0KICAgICAgaWYgdHlwZShyZXN1bHQpID09IHR5cGUoKCkp Og0KICAgICAgICByZXR1cm4gKDAsKSArIHJlc3VsdA0KICAgICAgcmV0dXJu IDAsIHJlc3VsdA0KDQogICAgIyBubyBwYXJlbnQgd2FzIHByb3ZpZGVkLCBz byB0aGUgYXJjaGl2ZSBzaG91bGQgZXhpc3Qgc29tZXdoZXJlIG9uIHRoZQ0K ICAgICMgZGVmYXVsdCAicGF0aCIuDQogICAgYXJjaGl2ZSA9IHNlbGYuZ2V0 X2FyY2hpdmUobW9kbmFtZSkNCiAgICBpZiBhcmNoaXZlIGlzIE5vbmU6DQog ICAgICByZXR1cm4gTm9uZQ0KICAgIHJldHVybiAxLCAiIiwgeydfX2FyY2hp dmVfXyc6YXJjaGl2ZX0NCg0KICBkZWYgZ2V0X2FyY2hpdmUoc2VsZiwgbW9k bmFtZSk6DQogICAgIiIiR2V0IGFuIGFyY2hpdmUgb2YgbW9kdWxlcy4NCg0K ICAgIFRoaXMgbWV0aG9kIHNob3VsZCBsb2NhdGUgYW4gYXJjaGl2ZSBhbmQg cmV0dXJuIGEgdmFsdWUgd2hpY2ggY2FuIGJlDQogICAgdXNlZCBieSBnZXRf c3ViZmlsZSB0byBsb2FkIG1vZHVsZXMgZnJvbSBpdC4gVGhlIHZhbHVlIG1h eSBiZSBhIHNpbXBsZQ0KICAgIHBhdGhuYW1lLCBhbiBvcGVuIGZpbGUsIG9y IGEgY29tcGxleCBvYmplY3QgdGhhdCBjYWNoZXMgaW5mb3JtYXRpb24NCiAg ICBmb3IgZnV0dXJlIGltcG9ydHMuDQoNCiAgICBSZXR1cm4gTm9uZSBpZiB0 aGUgYXJjaGl2ZSB3YXMgbm90IGZvdW5kLg0KICAgICIiIg0KICAgIHJhaXNl IFJ1bnRpbWVFcnJvciwgImdldF9hcmNoaXZlIG5vdCBpbXBsZW1lbnRlZCIN Cg0KICBkZWYgZ2V0X3N1YmZpbGUoc2VsZiwgYXJjaGl2ZSwgbW9kbmFtZSk6 DQogICAgIiIiR2V0IGNvZGUgZnJvbSBhIHN1YmZpbGUgaW4gdGhlIHNwZWNp ZmllZCBhcmNoaXZlLg0KDQogICAgR2l2ZW4gdGhlIHNwZWNpZmllZCBhcmNo aXZlIChhcyByZXR1cm5lZCBieSBnZXRfYXJjaGl2ZSgpKSwgbG9jYXRlDQog ICAgYW5kIHJldHVybiBhIGNvZGUgb2JqZWN0IGZvciB0aGUgc3BlY2lmaWVk IG1vZHVsZSBuYW1lLg0KDQogICAgQSAyLXR1cGxlIG1heSBiZSByZXR1cm5l ZCwgY29uc2lzdGluZyBvZiBhIGNvZGUgb2JqZWN0IGFuZCBhIGRpY3QNCiAg ICBvZiBuYW1lL3ZhbHVlcyB0byBwbGFjZSBpbnRvIHRoZSB0YXJnZXQgbW9k dWxlLg0KDQogICAgUmV0dXJuIE5vbmUgaWYgdGhlIHN1YmZpbGUgd2FzIG5v dCBmb3VuZC4NCiAgICAiIiINCiAgICByYWlzZSBSdW50aW1lRXJyb3IsICJn ZXRfc3ViZmlsZSBub3QgaW1wbGVtZW50ZWQiDQoNCg0KY2xhc3MgUGFja2Fn ZUFyY2hpdmUoUGFja2FnZUFyY2hpdmVJbXBvcnRlcik6DQogICJQYWNrYWdl QXJjaGl2ZUltcG9ydGVyIHN1YmNsYXNzIHRoYXQgcmVmZXJzIHRvIGEgc3Bl Y2lmaWMgYXJjaGl2ZS4iDQoNCiAgZGVmIF9faW5pdF9fKHNlbGYsIG1vZG5h bWUsIGFyY2hpdmVfcGF0aG5hbWUpOg0KICAgIHNlbGYuX19tb2RuYW1lID0g bW9kbmFtZQ0KICAgIHNlbGYuX19wYXRoID0gYXJjaGl2ZV9wYXRobmFtZQ0K DQogIGRlZiBnZXRfYXJjaGl2ZShzZWxmLCBtb2RuYW1lKToNCiAgICBpZiBt b2RuYW1lID09IHNlbGYuX19tb2RuYW1lOg0KICAgICAgcmV0dXJuIHNlbGYu X19wYXRoDQogICAgcmV0dXJuIE5vbmUNCg0KICAjIGdldF9zdWJmaWxlIGlz IHBhc3NlZCB0aGUgZnVsbCBwYXRobmFtZSBvZiB0aGUgYXJjaGl2ZQ0KDQoN CiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMNCiMgRW11bGF0ZSB0aGUg c3RhbmRhcmQgZGlyZWN0b3J5LWJhc2VkIGltcG9ydCBtZWNoYW5pc20NCiMN CmNsYXNzIERpcmVjdG9yeUltcG9ydGVyKEltcG9ydGVyKToNCiAgIkltcG9y dGVyIHN1YmNsYXNzIHRvIGVtdWxhdGUgdGhlIHN0YW5kYXJkIGltcG9ydGVy LiINCg0KICBkZWYgX19pbml0X18oc2VsZiwgZGlyKToNCiAgICBzZWxmLmRp ciA9IGRpcg0KDQogIGRlZiBnZXRfY29kZShzZWxmLCBwYXJlbnQsIG1vZG5h bWUsIGZxbmFtZSk6DQogICAgaWYgcGFyZW50Og0KICAgICAgZGlyID0gcGFy ZW50Ll9fcGtnZGlyX18NCiAgICBlbHNlOg0KICAgICAgZGlyID0gc2VsZi5k aXINCg0KICAgICMgZGVmZXIgdGhlIGxvYWRpbmcgb2YgT1MtcmVsYXRlZCBm YWNpbGl0aWVzDQogICAgaWYgbm90IF9vc19zdGF0Og0KICAgICAgX29zX2Jv b3RzdHJhcCgpDQoNCiAgICAjIFJldHVybiB0aGUgbW9kdWxlIChhbmQgb3Ro ZXIgaW5mbykgaWYgZm91bmQgaW4gdGhlIHNwZWNpZmllZA0KICAgICMgZGly ZWN0b3J5LiBPdGhlcndpc2UsIHJldHVybiBOb25lLg0KICAgIHJldHVybiBf ZnNfaW1wb3J0KGRpciwgbW9kbmFtZSwgZnFuYW1lKQ0KDQogIGRlZiBfX3Jl cHJfXyhzZWxmKToNCiAgICByZXR1cm4gJzwlcy4lcyBmb3IgIiVzIiBhdCAw eCV4PicgJSAoc2VsZi5fX2NsYXNzX18uX19tb2R1bGVfXywNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VsZi5fX2NsYXNz X18uX19uYW1lX18sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHNlbGYuZGlyLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBpZChzZWxmKSkNCg0KIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIw0KIw0KIyBFbXVsYXRlIHRoZSBzdGFuZGFyZCBwYXRoLXN0 eWxlIGltcG9ydCBtZWNoYW5pc20NCiMNCmNsYXNzIFBhdGhJbXBvcnRlcihJ bXBvcnRlcik6DQogIGRlZiBfX2luaXRfXyhzZWxmLCBwYXRoPXN5cy5wYXRo KToNCiAgICBzZWxmLnBhdGggPSBwYXRoDQoNCiAgICAjIHdlJ3JlIGRlZmlu aXRlbHkgZ29pbmcgdG8gYmUgaW1wb3J0aW5nIHNvbWV0aGluZyBpbiB0aGUg ZnV0dXJlLA0KICAgICMgc28gbGV0J3MganVzdCBsb2FkIHRoZSBPUy1yZWxh dGVkIGZhY2lsaXRpZXMuDQogICAgaWYgbm90IF9vc19zdGF0Og0KICAgICAg X29zX2Jvb3RzdHJhcCgpDQoNCiAgZGVmIGdldF9jb2RlKHNlbGYsIHBhcmVu dCwgbW9kbmFtZSwgZnFuYW1lKToNCiAgICBpZiBwYXJlbnQ6DQogICAgICAj IHdlIGFyZSBsb29raW5nIGZvciBhIG1vZHVsZSBpbnNpZGUgb2YgYSBzcGVj aWZpYyBwYWNrYWdlDQogICAgICByZXR1cm4gX2ZzX2ltcG9ydChwYXJlbnQu X19wa2dkaXJfXywgbW9kbmFtZSwgZnFuYW1lKQ0KDQogICAgIyBzY2FuIHN5 cy5wYXRoLCBsb29raW5nIGZvciB0aGUgcmVxdWVzdGVkIG1vZHVsZQ0KICAg IGZvciBkaXIgaW4gc2VsZi5wYXRoOg0KICAgICAgcmVzdWx0ID0gX2ZzX2lt cG9ydChkaXIsIG1vZG5hbWUsIGZxbmFtZSkNCiAgICAgIGlmIHJlc3VsdDoN CiAgICAgICAgcmV0dXJuIHJlc3VsdA0KDQogICAgIyBub3QgZm91bmQNCiAg ICByZXR1cm4gTm9uZQ0KDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN CiMNCiMgRW11bGF0ZSB0aGUgaW1wb3J0IG1lY2hhbmlzbSBmb3IgYnVpbHRp biBhbmQgZnJvemVuIG1vZHVsZXMNCiMNCmNsYXNzIEJ1aWx0aW5JbXBvcnRl cihJbXBvcnRlcik6DQogIGRlZiBnZXRfY29kZShzZWxmLCBwYXJlbnQsIG1v ZG5hbWUsIGZxbmFtZSk6DQogICAgaWYgcGFyZW50Og0KICAgICAgIyB0aGVz ZSBtb2R1bGVzIGRlZmluaXRlbHkgZG8gbm90IG9jY3VyIHdpdGhpbiBhIHBh Y2thZ2UgY29udGV4dA0KICAgICAgcmV0dXJuIE5vbmUNCg0KICAgICMgbG9v ayBmb3IgdGhlIG1vZHVsZQ0KICAgIGlmIGltcC5pc19idWlsdGluKG1vZG5h bWUpOg0KICAgICAgdHlwZSA9IGltcC5DX0JVSUxUSU4NCiAgICBlbGlmIGlt cC5pc19mcm96ZW4obW9kbmFtZSk6DQogICAgICB0eXBlID0gaW1wLlBZX0ZS T1pFTg0KICAgIGVsc2U6DQogICAgICAjIG5vdCBmb3VuZA0KICAgICAgcmV0 dXJuIE5vbmUNCg0KICAgICMgZ290IGl0LiBub3cgbG9hZCBhbmQgcmV0dXJu IGl0Lg0KICAgIG1vZHVsZSA9IGltcC5sb2FkX21vZHVsZShtb2RuYW1lLCBO b25lLCBtb2RuYW1lLCAoJycsICcnLCB0eXBlKSkNCiAgICByZXR1cm4gMCwg bW9kdWxlLCB7IH0NCg0KDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQoj DQojIEludGVybmFsIGltcG9ydGVyIHVzZWQgZm9yIGltcG9ydGluZyBmcm9t IHRoZSBmaWxlc3lzdGVtDQojDQpjbGFzcyBfRmlsZXN5c3RlbUltcG9ydGVy KEltcG9ydGVyKToNCiAgZGVmIF9faW5pdF9fKHNlbGYsIHN1ZmZpeGVzKToN CiAgICAjIHRoaXMgbGlzdCBpcyBzaGFyZWQgd2l0aCB0aGUgSW1wb3J0TWFu YWdlci4NCiAgICBzZWxmLnN1ZmZpeGVzID0gc3VmZml4ZXMNCg0KICBkZWYg aW1wb3J0X2Zyb21fZGlyKHNlbGYsIGRpciwgZnFuYW1lKToNCiAgICByZXN1 bHQgPSBzZWxmLl9pbXBvcnRfcGF0aG5hbWUoX29zX3BhdGhfam9pbihkaXIs IGZxbmFtZSksIGZxbmFtZSkNCiAgICBpZiByZXN1bHQ6DQogICAgICByZXR1 cm4gc2VsZi5fcHJvY2Vzc19yZXN1bHQocmVzdWx0LCBmcW5hbWUpDQogICAg cmV0dXJuIE5vbmUNCg0KICBkZWYgZ2V0X2NvZGUoc2VsZiwgcGFyZW50LCBt b2RuYW1lLCBmcW5hbWUpOg0KICAgICMgVGhpcyBpbXBvcnRlciBpcyBuZXZl ciB1c2VkIHdpdGggYW4gZW1wdHkgcGFyZW50LiBJdHMgZXhpc3RlbmNlIGlz DQogICAgIyBwcml2YXRlIHRvIHRoZSBJbXBvcnRNYW5hZ2VyLiBUaGUgSW1w b3J0TWFuYWdlciB1c2VzIHRoZQ0KICAgICMgaW1wb3J0X2Zyb21fZGlyKCkg bWV0aG9kIHRvIGltcG9ydCB0b3AtbGV2ZWwgbW9kdWxlcy9wYWNrYWdlcy4N CiAgICAjIFRoaXMgbWV0aG9kIGlzIG9ubHkgdXNlZCB3aGVuIHdlIGxvb2sg Zm9yIGEgbW9kdWxlIHdpdGhpbiBhIHBhY2thZ2UuDQogICAgYXNzZXJ0IHBh cmVudA0KDQogICAgcmV0dXJuIHNlbGYuX2ltcG9ydF9wYXRobmFtZShfb3Nf cGF0aF9qb2luKHBhcmVudC5fX3BrZ2Rpcl9fLCBtb2RuYW1lKSwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZxbmFtZSkNCg0KICBkZWYg X2ltcG9ydF9wYXRobmFtZShzZWxmLCBwYXRobmFtZSwgZnFuYW1lKToNCiAg ICBpZiBfb3NfcGF0aF9pc2RpcihwYXRobmFtZSk6DQogICAgICByZXN1bHQg PSBzZWxmLl9pbXBvcnRfcGF0aG5hbWUoX29zX3BhdGhfam9pbihwYXRobmFt ZSwgJ19faW5pdF9fJyksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZnFuYW1lKQ0KICAgICAgaWYgcmVzdWx0Og0KICAgICAgICB2 YWx1ZXMgPSByZXN1bHRbMl0NCiAgICAgICAgdmFsdWVzWydfX3BrZ2Rpcl9f J10gPSBwYXRobmFtZQ0KICAgICAgICB2YWx1ZXNbJ19fcGF0aF9fJ10gPSBb IHBhdGhuYW1lIF0NCiAgICAgICAgcmV0dXJuIDEsIHJlc3VsdFsxXSwgdmFs dWVzDQogICAgICByZXR1cm4gTm9uZQ0KDQogICAgZm9yIHN1ZmZpeCwgaW1w b3J0ZXIgaW4gc2VsZi5zdWZmaXhlczoNCiAgICAgIGZpbGVuYW1lID0gcGF0 aG5hbWUgKyBzdWZmaXgNCiAgICAgIHRyeToNCiAgICAgICAgZmluZm8gPSBf b3Nfc3RhdChmaWxlbmFtZSkNCiAgICAgIGV4Y2VwdCBPU0Vycm9yOg0KICAg ICAgICBwYXNzDQogICAgICBlbHNlOg0KICAgICAgICByZXR1cm4gaW1wb3J0 ZXIuaW1wb3J0X2ZpbGUoZmlsZW5hbWUsIGZpbmZvLCBmcW5hbWUpDQogICAg cmV0dXJuIE5vbmUNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIw0K IyBTVUZGSVgtQkFTRUQgSU1QT1JURVJTDQojDQoNCmNsYXNzIFN1ZmZpeElt cG9ydGVyOg0KICBkZWYgaW1wb3J0X2ZpbGUoc2VsZiwgZmlsZW5hbWUsIGZp bmZvLCBmcW5hbWUpOg0KICAgIHJhaXNlIFJ1bnRpbWVFcnJvcg0KDQpjbGFz cyBQeVN1ZmZpeEltcG9ydGVyKFN1ZmZpeEltcG9ydGVyKToNCiAgZGVmIGlt cG9ydF9maWxlKHNlbGYsIGZpbGVuYW1lLCBmaW5mbywgZnFuYW1lKToNCiAg ICBmaWxlID0gZmlsZW5hbWVbOi0zXSArIF9zdWZmaXgNCiAgICB0X3B5ID0g bG9uZyhmaW5mb1s4XSkNCiAgICB0X3B5YyA9IF90aW1lc3RhbXAoZmlsZSkN Cg0KICAgIGNvZGUgPSBOb25lDQogICAgaWYgdF9weWMgaXMgbm90IE5vbmUg YW5kIHRfcHljID49IHRfcHk6DQogICAgICBmID0gb3BlbihmaWxlLCAncmIn KQ0KICAgICAgaWYgZi5yZWFkKDQpID09IGltcC5nZXRfbWFnaWMoKToNCiAg ICAgICAgdCA9IHN0cnVjdC51bnBhY2soJzxJJywgZi5yZWFkKDQpKVswXQ0K ICAgICAgICBpZiB0ID09IHRfcHk6DQogICAgICAgICAgY29kZSA9IG1hcnNo YWwubG9hZChmKQ0KICAgICAgZi5jbG9zZSgpDQogICAgaWYgY29kZSBpcyBO b25lOg0KICAgICAgZmlsZSA9IGZpbGVuYW1lDQogICAgICBjb2RlID0gX2Nv bXBpbGUoZmlsZSwgdF9weSkNCg0KICAgIHJldHVybiAwLCBjb2RlLCB7ICdf X2ZpbGVfXycgOiBmaWxlIH0NCg0KY2xhc3MgRHluTG9hZFN1ZmZpeEltcG9y dGVyKFN1ZmZpeEltcG9ydGVyKToNCiAgZGVmIF9faW5pdF9fKHNlbGYsIGRl c2MpOg0KICAgIHNlbGYuZGVzYyA9IGRlc2MNCg0KICBkZWYgaW1wb3J0X2Zp bGUoc2VsZiwgZmlsZW5hbWUsIGZpbmZvLCBmcW5hbWUpOg0KICAgIGZwID0g b3BlbihmaWxlbmFtZSwgc2VsZi5kZXNjWzFdKQ0KICAgIG1vZHVsZSA9IGlt cC5sb2FkX21vZHVsZShmcW5hbWUsIGZwLCBmaWxlbmFtZSwgc2VsZi5kZXNj KQ0KICAgIG1vZHVsZS5fX2ZpbGVfXyA9IGZpbGVuYW1lDQogICAgcmV0dXJu IDAsIG1vZHVsZSwgeyB9DQoNCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj Iw0KDQpkZWYgX3Rlc3RfZGlyKCk6DQogICJEZWJ1Zy90ZXN0IGZ1bmN0aW9u IHRvIGNyZWF0ZSBEaXJlY3RvcnlJbXBvcnRlcnMgZnJvbSBzeXMucGF0aC4i DQogIHBhdGggPSBzeXMucGF0aFs6XQ0KICBwYXRoLnJldmVyc2UoKQ0KICBm b3IgZCBpbiBwYXRoOg0KICAgIERpcmVjdG9yeUltcG9ydGVyKGQpLmluc3Rh bGwoKQ0KDQpkZWYgX3Rlc3RfcmV2YW1wKCk6DQogICJEZWJ1Zy90ZXN0IGZ1 bmN0aW9uIGZvciB0aGUgcmV2YW1wZWQgaW1wb3J0IHN5c3RlbS4iDQogIFBh dGhJbXBvcnRlcigpLmluc3RhbGwoKQ0KICBCdWlsdGluSW1wb3J0ZXIoKS5p bnN0YWxsKCkNCg0KZGVmIF9wcmludF9pbXBvcnRlcnMoKToNCiAgaXRlbXMg PSBzeXMubW9kdWxlcy5pdGVtcygpDQogIGl0ZW1zLnNvcnQoKQ0KICBmb3Ig bmFtZSwgbW9kdWxlIGluIGl0ZW1zOg0KICAgIGlmIG1vZHVsZToNCiAgICAg IHByaW50IG5hbWUsIG1vZHVsZS5fX2RpY3RfXy5nZXQoJ19faW1wb3J0ZXJf XycsICctLSBubyBpbXBvcnRlcicpDQogICAgZWxzZToNCiAgICAgIHByaW50 IG5hbWUsICctLSBub24tZXhpc3RlbnQgbW9kdWxlJw0KDQpkZWYgX3Rlc3Rf cmV2YW1wKCk6DQogIEltcG9ydE1hbmFnZXIoKS5pbnN0YWxsKCkNCiAgc3lz LnBhdGguaW5zZXJ0KDAsIEJ1aWx0aW5JbXBvcnRlcigpKQ0KDQojIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjDQo= --1658348780-1657214722-946868004=:412-- From mal@lemburg.com Mon Jan 3 12:28:34 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jan 2000 13:28:34 +0100 Subject: [Python-Dev] new imputil.py References: Message-ID: <387095F2.2FA64D8E@lemburg.com> Happy New Year :-) [new imputil.py] I tried the new module with the following code: import imputil,sys if sys.argv[1] != 'standard': print 'Installing imputil...', imputil.ImportManager().install() sys.path.insert(0, imputil.BuiltinImporter()) print 'done.' else: print 'Using builtin importer.' print print 'Importing standard stuff...', import string,re,os,sys print 'done.' print 'Importing mx Extensions...', from mx import DateTime,TextTools,ODBC,HTMLTools,UID,URL print 'done.' ### The new importer does load everything in the test set (top level modules, packages, extensions within packages) without problems on Linux. Some comments: · Why is the sys.path.insert(0,imputil.BuiltinImporter()) needed in order to get b/w compatibility ? · Why is there no __path__ aware code in imputil.py (this is definitely needed in order to make it a drop-in replacement) ? · Performance is still 50% of the Python builtin importer -- a bummer if you ask me. More aggressive caching is definitely needed, perhaps even some recoding of methods in C. · The old chaining code should be moved into a subclass of its own. · The code should not import strop directly as this module will probably go away RSN. Use string methods instead. · The design of the ImportManager has some minor flaws: the FS importer should be settable via class attributes, deinstallation should be possible, a query mechanism to find the importer used by a certain import would also be nice to be able to verify correct setup. · py/pyc/pyo file piping hooks would be nice to allow imports of signed (and trusted) code and/or encrypted code (a mixin class for these filters would do the trick). · Wish list: a distutils importer hooked to a list of standard package repositories, a module to file location mapper to speed up file system based imports, -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: Happy New Century ! Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gstein@lyra.org Mon Jan 3 13:53:00 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jan 2000 05:53:00 -0800 (PST) Subject: [Python-Dev] new imputil.py In-Reply-To: <387095F2.2FA64D8E@lemburg.com> Message-ID: Excellent... thanx for the feedback! Comments: On Mon, 3 Jan 2000, M.-A. Lemburg wrote: >... > The new importer does load everything in the test set > (top level modules, packages, extensions within packages) > without problems on Linux. Great! > Some comments: >=20 > =B7 Why is the sys.path.insert(0,imputil.BuiltinImporter())=20 > needed in order to get b/w compatibility ? Because I didn't want to build too much knowledge into the ImportManager. Heck, I think adding sys.path removed some of the design elegence; adding real knowledge of builtins... well, we'll just not talk about that. :-) We could certainly do it this way; let's see what Guido says. I'm not truly adverse to it, but I'd recommend against adding a knowledge of BuiltinImporter to the ImportManager. > =B7 Why is there no __path__ aware code in imputil.py (this is > definitely needed in order to make it a drop-in replacement) ? Because I don't like __path__ :-) I don't think it would be too hard to add, though. If Guido says we need __path__, then I'll add it. I do believe there was a poll a while back where he asked whether anybody truly used it. I don't remember the result and/or Guido's resolution of the matter. > =B7 Performance is still 50% of the Python builtin importer -- > a bummer if you ask me. More aggressive caching is definitely > needed, perhaps even some recoding of methods in C. I'm scared of caching and the possibility for false positives/negatives. But yes, it is still slower and could use some analysis and/or recoding *if* the speed is a problem. Slower imports does not necessarily mean they are "too slow." > =B7 The old chaining code should be moved into a subclass of > its own. Good thought. But really: I'd just rather torch it. This kind of depends on whether we can get away with saying the ImportManager is *the* gateway between the interpreter and Python-level import hooks. In other words, will ImportManager be the *only* Python code to ever be allowed to call sys.set_import_hook() ? If the ImportManager doesn't have to "play with other import hooks", then the chaining can be removed altogether. > =B7 The code should not import strop directly as this module > will probably go away RSN. Use string methods instead. Yah. But I'm running this against 1.5.2 :-) I might be able to do something where the string methods are used if available, and use the strop module if not. [ similar to the 'os' bootstrapping that is done ] Finn Bock emailed me to say that JPython does not have strop, but does have string methods. > =B7 The design of the ImportManager has some minor flaws: the > FS importer should be settable via class attributes, The class or the object itself? Putting a class in there would be nice, or possibly passing it to the constructor (with a suitable default). This is a good idea, though. Please clarify what you'd like to see, and I'll get it added. > deinstallation > should be possible, Maybe. This is somewhat dependent upon whether it must "play nice." Deinstallation would be quite easy if we move to a sys.get/set style of interface, and it wouldn't be an issue to do de-install code. > a query mechanism to find the importer > used by a certain import would also be nice to be able to > verify correct setup. module.__importer__ provides the importer that was used. This is defined behavior (the system relies on that being set to deal with packages properly). Is this sufficient, or were you looking for something else? module.__ispkg__ is also set to 0/1 accordingly. For backwards compat, __file__ and __path__ are also set. The __all__ attribute in an __init__.py file is used for "from package import *". > =B7 py/pyc/pyo file piping hooks would be nice to allow > imports of signed (and trusted) code and/or encrypted code > (a mixin class for these filters would do the trick). I'd happily accept a base SuffixImporter class for these "pipes". I don't believe that the ImportManager, Importer, or SuffixImporter base classes would need any changes, though. Note that I probably will rearrange the _fs_import() and friends, per Guido's suggestion to move them into a base class. That may be a step towards having "pipes" available. > =B7 Wish list: a distutils importer hooked to a list of standard > package repositories, a module to file location mapper to > speed up file system based imports,=20 I'm not sure what the former would do. distutils is still a little nebulous to me right now. For a mapper, we can definitely have a custom Importer that knows where certain modules are found. However, I suspect you're looking for some kind of a cache, but there isn't a hook to say "I found at location" (which would be used to build the mapping). Suggestions on both of these would be most welcome! Cheers, -g --=20 Greg Stein, http://www.lyra.org/ From gvwilson@nevex.com Mon Jan 3 14:02:32 2000 From: gvwilson@nevex.com (gvwilson@nevex.com) Date: Mon, 3 Jan 2000 09:02:32 -0500 (EST) Subject: [Python-Dev] Software Carpentry: GUI Toolkit? Message-ID: Hi, folks. I'm putting together guidelines for submissions to the Software Carpentry design competition (www.software-carpentry.com), and would like to know what I should recommend as a Python GUI toolkit. As I understand it, the alternatives are: - Tkinter: the "standard" answer, but many people think it's showing its age, and it's an installation and update headaches because of its Tcl dependencies. - some other GUI toolkit: but there's no consensus on which one, and documentation is lacking. - CGI scripts (i.e. all interfaces are web pages): has the virtue of simplicity, but could also make some useful interfaces difficult to build (e.g. no drag and drop), and would require users to run a server, or at least get exec privileges, which can be an installation headache. If I've missed a good answer, or if there's somewhere else I should look for a solution, I'd be grateful for a pointer. Thanks, Greg From jim@interet.com Mon Jan 3 14:31:53 2000 From: jim@interet.com (James C. Ahlstrom) Date: Mon, 03 Jan 2000 09:31:53 -0500 Subject: [Python-Dev] new imputil.py References: Message-ID: <3870B2D9.31D0D350@interet.com> Greg Stein wrote: > I've attached a new imputil.py to this message. It isn't posted on my page I don't think you should be using "public domain" as a copyright because you should be protecting the code. Better to use "all rights transferred to CNRI pursuant to the Python contribution agreement", or just copyright it yourself for now. You didn't incorporate the ZipImporter in ftp://ftp.interet.com/pub/importer.py Is that because you want me to, or doesn't it work? JimA From gmcm@hypernet.com Mon Jan 3 14:38:11 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Mon, 3 Jan 2000 09:38:11 -0500 Subject: [Python-Dev] new imputil.py In-Reply-To: References: <387095F2.2FA64D8E@lemburg.com> Message-ID: <1265213088-25101227@hypernet.com> Greg Stein wrote: > On Mon, 3 Jan 2000, M.-A. Lemburg wrote: [big snip] > > · Wish list: a distutils importer hooked to a list of standard > > package repositories, a module to file location mapper to speed > > up file system based imports, > For a mapper, we can definitely have a custom Importer that knows > where certain modules are found. However, I suspect you're > looking for some kind of a cache, but there isn't a hook to say > "I found at location" (which would be used to build > the mapping). > > Suggestions on both of these would be most welcome! Haven't played with the new one yet. But for awhile I've been considering a scheme where sys.path[0] has a cache of known binary extensions { logicalname: fullpath, ... } and sys.path[-1] is the brute force importer. For standalones, sys.path[0] could be hardcoded. For normal installations, sys.path[-1] could inform sys.path[0] when a .so / .dll / .pyd is found. So when a new one is installed, the first use will be expensive, but subsequent sessions would import it in 1 I/O. I'd also like to point out that archives *can* be used in a development situation. Obviously I wouldn't bother putting a module under current development into an archive. But if the source is still installed and you haven't mucked with the __file__ attribute when you put it in the archive, then tracebacks will show you what you need. IDLE doesn't know the difference. So for most developers, the standard library can be served from an archive with no effect (other than speed). - Gordon From gstein@lyra.org Mon Jan 3 14:57:35 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 3 Jan 2000 06:57:35 -0800 (PST) Subject: [Python-Dev] new imputil.py In-Reply-To: <3870B2D9.31D0D350@interet.com> Message-ID: On Mon, 3 Jan 2000, James C. Ahlstrom wrote: > Greg Stein wrote: > > I've attached a new imputil.py to this message. It isn't posted on my page > > I don't think you should be using "public domain" as a > copyright because you should be protecting the code. > Better to use "all rights transferred to CNRI pursuant > to the Python contribution agreement", or just copyright > it yourself for now. Public Domain means there are no copyrights on the code. Anybody can claim copyright to it. Anybody can start with my version, slap their name and license on it, and do as they wish. There isn't a way for anybody to "control" public domain software, so there is no need for protection. I like to use Public Domain for code that I want to see as broadly used as possible and/or for short things. There is also a lot that I just don't care what happens with it. If I don't have a vested interest in something, then PD is fine. I wrote imputil as a tool for myself. It isn't something that I feel a need to keep my name on it -- it works for me, it does what I want, it doesn't matter what others do it. It does matter than other people *can* do stuff with it, and PD gives them the most options. Shades of grey... hard to fully explain in an email... but that's the general sentiment. I've got a few things under other licenses, but PD seemed best for imputil. > You didn't incorporate the ZipImporter in > ftp://ftp.interet.com/pub/importer.py > Is that because you want me to, or doesn't it work? I had the redesign to do first. When that settles towards something that Guido is happy with (or he has decided to punt the design altogether), then I'll integrate the ZipImporter. Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@acm.org Mon Jan 3 20:05:22 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 3 Jan 2000 15:05:22 -0500 (EST) Subject: [Python-Dev] new imputil.py In-Reply-To: <1265213088-25101227@hypernet.com> References: <387095F2.2FA64D8E@lemburg.com> <1265213088-25101227@hypernet.com> Message-ID: <14449.258.374018.919406@weyr.cnri.reston.va.us> Gordon McMillan writes: > I'd also like to point out that archives *can* be used in a > development situation. Obviously I wouldn't bother putting a > module under current development into an archive. But if the > source is still installed and you haven't mucked with the > __file__ attribute when you put it in the archive, then > tracebacks will show you what you need. IDLE doesn't know > the difference. So for most developers, the standard library > can be served from an archive with no effect (other than speed). I don't see why we can't just add the source to the archive as well; this would allow proper tracebacks even outside the development of the library. Not including sources would cleanly result in the same situation as we currently see when there's only a .pyc file. Am I missing something fundamental? -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From mal@lemburg.com Mon Jan 3 18:22:02 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 03 Jan 2000 19:22:02 +0100 Subject: [Python-Dev] Better text processing support in py2k? References: <000901bf53e1$eb4248c0$472d153f@tim> Message-ID: <3870E8CA.7294B813@lemburg.com> Tim Peters wrote: > > >> This is why I do complex string processing in Icon <0.9 wink>. > > [MAL] > > You can have all that extra magic via callable tag objects > > or callable matching functions. It's not exactly nice to > > write, but I'm sure that a meta-language could do the > > conversions for you. > > That wasn't my point: I do it in Icon because it *is* "exactly nice to > write", and doesn't require any yet-another meta-language. It's all > straightforward, in a way that separate schemes pasted together can never be > (simply because they *are* "separate schemes pasted together" ). > > The point of my Python examples wasn't that they could do something > mxTextTools can't do, but that they were *Python* examples: every variation > I mentioned (or that you're likely to think of) was easy to handle for any > Python programmer because the "control flow" and "data type" etc aspects > could be handled exactly the way they always are in *non* pattern-matching > Python code too, rather than recoded in pattern-scheme-specific different > ways (e.g., where I had a vanailla "if/break", you set up a special > exception to tickle the matching engine). > > I'm not attacking mxTextTools, so don't feel compelled to defend it -- Oh, I wasn't defending it -- I know that it is cryptic and sometimes a pain to use. But given that you don't have to invoke a C compiler to get a raw speed I find it a rather useful alternative to code fast utility functions which would otherwise have to be written in C. The other reason it exists is simply because I don't like the recursive style of regexps too much. mxTextTools is simple and straightforward. Backtracking is still possible, but not recommended. > people using regexps in those examples are dead in the water. mxTextTools > is very good at what it does; if we have a real disagreement, it's probably > that I'm less optimistic about the prospects for higher-level wrappers > (e.g., MikeF's SimpleParse is much slower than "a real" BNF parsing system > (ARBNFPS), in part because he isn't doing all the optimizations ARBNFPS > does, but also in part because ARBNFPS uses an underlying engine more > optimized to its specific task than mxTextTool's more-general engine *can* > be). So I don't see mxTextTools as being the answer to everything -- and if > you hadn't written it, you would agree with that on first glance . Oh, I'm sure it *is* the answer to all out problems ;-) ... def main(*dummy): ... from mx.TextTools import * tag("",((main, Skip + CallTag, 0),)) > > Anyway, I'll keep focussing on the speed aspect of mxTextTools; > > others can focus on abstractions, so that eventually everybody > > will be happy :-) > > You and I will be, anyway . Happy New Year :-) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: Happy New Century ! Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Tue Jan 4 18:36:00 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 04 Jan 2000 19:36:00 +0100 Subject: [Python-Dev] new imputil.py References: Message-ID: <38723D90.D2AE1CA4@lemburg.com> Greg Stein wrote: > > Comments: > > On Mon, 3 Jan 2000, M.-A. Lemburg wrote: > >... > > The new importer does load everything in the test set > > (top level modules, packages, extensions within packages) > > without problems on Linux. > > Great! > > > Some comments: > > > > · Why is the sys.path.insert(0,imputil.BuiltinImporter()) > > needed in order to get b/w compatibility ? > > Because I didn't want to build too much knowledge into the ImportManager. > Heck, I think adding sys.path removed some of the design elegence; adding > real knowledge of builtins... well, we'll just not talk about that. :-) > > We could certainly do it this way; let's see what Guido says. I'm not > truly adverse to it, but I'd recommend against adding a knowledge of > BuiltinImporter to the ImportManager. I was under the impression that the ImportManager should replace the current implementation. In that light it should of course provide all the needed techniques per default without the need to tweak sys.path. > > · Why is there no __path__ aware code in imputil.py (this is > > definitely needed in order to make it a drop-in replacement) ? > > Because I don't like __path__ :-) I don't think it would be too hard to > add, though. > > If Guido says we need __path__, then I'll add it. I do believe there was a > poll a while back where he asked whether anybody truly used it. I don't > remember the result and/or Guido's resolution of the matter. AFAIK, JimF is using it in Zope. I will use it in the b/w compatibility package for the soon to be released mx Extensions packages (instead of using relative imports, BTW -- can't wait for those to happen). > > · Performance is still 50% of the Python builtin importer -- > > a bummer if you ask me. More aggressive caching is definitely > > needed, perhaps even some recoding of methods in C. > > I'm scared of caching and the possibility for false positives/negatives. > > But yes, it is still slower and could use some analysis and/or recoding > *if* the speed is a problem. Slower imports does not necessarily mean they > are "too slow." There has been some moaning about the current Python startup speed, so I guess people already find the existing strategy too slow. Anyway, put the cache risks into the user's hands and have them decide whether or not to use them. The important thing is providing a standard approach to caching which all importers can use and hook into rather than having three or four separate cache implementations. > > · The old chaining code should be moved into a subclass of > > its own. > > Good thought. But really: I'd just rather torch it. This kind of depends > on whether we can get away with saying the ImportManager is *the* gateway > between the interpreter and Python-level import hooks. In other words, > will ImportManager be the *only* Python code to ever be allowed to call > sys.set_import_hook() ? If the ImportManager doesn't have to "play with > other import hooks", then the chaining can be removed altogether. Hmm, nuking the chains might cause some problems with code using the old ni.py or other code such as my old ClassModules.py module which emulates modules using classes (provides all the cool __getattr__ and __setattr__ features to modules as well). > > · The code should not import strop directly as this module > > will probably go away RSN. Use string methods instead. > > Yah. But I'm running this against 1.5.2 :-) > > I might be able to do something where the string methods are used if > available, and use the strop module if not. > [ similar to the 'os' bootstrapping that is done ] > > Finn Bock emailed me to say that JPython does not have strop, but does > have string methods. Since imputil.py targets 1.6 you can safely assume that string methods are in place. > > · The design of the ImportManager has some minor flaws: the > > FS importer should be settable via class attributes, > > The class or the object itself? Putting a class in there would be nice, or > possibly passing it to the constructor (with a suitable default). > > This is a good idea, though. Please clarify what you'd like to see, and > I'll get it added. I usually put these things into the class so that subclasses can easily override the setting. > > deinstallation > > should be possible, > > Maybe. This is somewhat dependent upon whether it must "play nice." > Deinstallation would be quite easy if we move to a sys.get/set style of > interface, and it wouldn't be an issue to do de-install code. I was thinking mainly of debugging situations where you play around with new importer code -- its probably not important for production code. > > a query mechanism to find the importer > > used by a certain import would also be nice to be able to > > verify correct setup. > > module.__importer__ provides the importer that was used. This is defined > behavior (the system relies on that being set to deal with packages > properly). > > Is this sufficient, or were you looking for something else? I was thinking of a situations like: if : or if : raise SystemError,'wrong setup' Don't know if these queries are possible with the current flags and attributes. > module.__ispkg__ is also set to 0/1 accordingly. > > For backwards compat, __file__ and __path__ are also set. The __all__ > attribute in an __init__.py file is used for "from package import *". > > > · py/pyc/pyo file piping hooks would be nice to allow > > imports of signed (and trusted) code and/or encrypted code > > (a mixin class for these filters would do the trick). > > I'd happily accept a base SuffixImporter class for these "pipes". I don't > believe that the ImportManager, Importer, or SuffixImporter base classes > would need any changes, though. > > Note that I probably will rearrange the _fs_import() and friends, per > Guido's suggestion to move them into a base class. That may be a step > towards having "pipes" available. It would be nice to be able to use the concept of stackable streams as source for byte and source code. For this to work one would have to make the file reading process a little more abstract by using e.g. a StreamReader instead (see the current unicode-proposal.txt version). > > · Wish list: a distutils importer hooked to a list of standard > > package repositories, a module to file location mapper to > > speed up file system based imports, > > I'm not sure what the former would do. distutils is still a little > nebulous to me right now. Basically it should scan a set of URLs providing access to package repositories which hold distutils installable package archives. In case it finds a suitable package it should then proceed to auto-install it and then continue the normal import process. > For a mapper, we can definitely have a custom Importer that knows where > certain modules are found. However, I suspect you're looking for some kind > of a cache, but there isn't a hook to say "I found at > location" (which would be used to build the mapping). Right. I would like to see some standard mechanism used throughout the ImportManager for this. One which all importers can use and rely on. E.g. it would be nice to have an option to load the cache from disk upon startup to reduce search times. All this should be left for the user to configure with the standard setting being no cache at all (to avoid confusion and reduce support costs ;-). -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: Happy New Century ! Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jan 4 21:04:48 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 4 Jan 2000 16:04:48 -0500 (EST) Subject: [Python-Dev] new imputil.py References: Message-ID: <14450.24688.492098.917284@anthem.cnri.reston.va.us> Happy New Year! >>>>> "GS" == Greg Stein writes: GS> I think Python 1.6 should drop the __import__ builtin and move GS> to something like sys.import_hook (to allow examination and GS> change). Wait! You can't remove builtin __import__ without breaking code. E.g. Mailman uses __import__ quite a bit in its CGI (and other) harnesses. Why does __import__ need to be removed? Why can't it just just the same mechanism the import statement uses? GS> I might be able to do something where the string methods are GS> used if available, and use the strop module if not. [ similar GS> to the 'os' bootstrapping that is done ] GS> Finn Bock emailed me to say that JPython does not have strop, GS> but does have string methods. Sorry Greg, I haven't had time to look at this stuff at all, so maybe I'm missing something essential, but if you just continue to use the string module, you'll be fine for JPython and CPython 1.5.2. In CPython 1.5.2, you /will/ actually be using the strop module under the covers. In CPython 1.6 and JPython 1.1 you'll be using string methods under the covers. Your penalty is one layer of Python function calls. Never use strop directly though. >>>>> "MA" == M writes: MA> There has been some moaning about the current Python startup MA> speed, so I guess people already find the existing strategy MA> too slow. Definitely. -Barry From gmcm@hypernet.com Wed Jan 5 03:49:08 2000 From: gmcm@hypernet.com (Gordon McMillan) Date: Tue, 4 Jan 2000 22:49:08 -0500 Subject: [Python-Dev] new imputil.py In-Reply-To: <14449.258.374018.919406@weyr.cnri.reston.va.us> References: <1265213088-25101227@hypernet.com> Message-ID: <1265079245-1617919@hypernet.com> Fred L. Drake, Jr.wrote: > Gordon McMillan writes: > > I'd also like to point out that archives *can* be used in a > > development situation. Obviously I wouldn't bother putting a > > module under current development into an archive. But if the > > source is still installed and you haven't mucked with the > > __file__ attribute when you put it in the archive, then > > tracebacks will show you what you need. IDLE doesn't know > the > difference. So for most developers, the standard library > can > be served from an archive with no effect (other than speed). > > I don't see why we can't just add the source to the archive as > well; > this would allow proper tracebacks even outside the development > of the library. Not including sources would cleanly result in > the same situation as we currently see when there's only a .pyc > file. > Am I missing something fundamental? Sure you could. Then you could patch IDLE, Pythonwin, etc. to open the proper archive and extract the source. Then you could patch them (and archive) to update on the fly. And while you're at it, I'd really like a jacuzzi jet that gets my neck and shoulders without having to scrunch into all kinds of strange positions. - Gordon Return-Path: Delivered-To: python-dev@dinsdale.python.org Received: from python.org (parrot.python.org [132.151.1.90]) by dinsdale.python.org (Postfix) with ESMTP id A76701CD65 for ; Fri, 14 Jan 2000 12:39:29 -0500 (EST) Received: from merlin.codesourcery.com (IDENT:qmailr@[206.168.99.1]) by python.org (8.9.1a/8.9.1) with SMTP id MAA17463 for ; Fri, 14 Jan 2000 12:39:29 -0500 (EST) Received: (qmail 2115 invoked by uid 513); 14 Jan 2000 17:44:23 -0000 Mailing-List: contact publicity-help@software-carpentry.com; run by ezmlm Delivered-To: mailing list publicity@software-carpentry.com Received: (qmail 2110 invoked from network); 14 Jan 2000 17:44:19 -0000 Date: Fri, 14 Jan 2000 12:40:13 -0500 (EST) From: gvwilson@nevex.com To: publicity@software-carpentry.com Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168427786-1646135556-947871613=:8785" Subject: [Python-Dev] ANNOUNCEMENT: Open Source Design Competition Sender: python-dev-admin@python.org Errors-To: python-dev-admin@python.org X-BeenThere: python-dev@python.org X-Mailman-Version: 1.2 (experimental) Precedence: bulk List-Id: Python core developers This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168427786-1646135556-947871613=:8785 Content-Type: TEXT/PLAIN; charset=US-ASCII The Software Carpentry project is pleased to announce the launch of its first Open Source design competition. The project's logo is attached, and details of the competition are included below. This message is being sent to you because you have expressed an interest in covering this story, or publicizing this project. If you have any questions, or do not wish to receive future notices about Software Carpentry, please contact: Dr. Gregory V. Wilson Software Carpentry Project Coordinator (416) 593 2428 gvwilson@software-carpentry.com Thanks for your interest! Greg Wilson ---------------------------------------------------------------------- ---------------------------------------------------------------------- Los Alamos National Laboratory Code Sourcery, LLC Software Carpentry Open Source Design Competition $100,000 in Prizes! ---------------------------------------------------------------------- The Software Carpentry project is pleased to announce its first Open Source design competition, with prizes totaling $100,000. Students and professionals from any country, working individually or in teams, are invited to submit design outlines for: * a platform inspection tool to replace autoconf; * a dependency management tool to replace make; * an issue tracking system to replace gnats and Bugzilla; and * a unit and regression testing harness with the functionality of XUnit, Expect, and DejaGnu. Participants may submit separate entries in one or more categories by March 31, 2000. Entries must be in English, and no more than 5000 words long; examples are available at http://www.software-carpentry.com. The competition will be judged by a panel that includes the following noted software developers, authors, and computational scientists: Stephen Adler Brookhaven National Laboratory Frank Alexander Los Alamos National Laboratory Donnie Barnes Red Hat Chris DiBona VA Linux Paul Dubois Lawrence Livermore National Laboratory Andrew Hunt Pragmatic Programmers, LLC Stephen R. Lee Los Alamos National Laboratory Josh MacDonald University of California, Berkeley Brian Marick Reliable Software Technologies Doug Mewhort Queen's University Bruce Perens co-founder of the Open Source Initiative Dave Thomas Pragmatic Programmers, LLC Jon Udell author of Practical Internet Groupware Guido van Rossum inventor of Python Tom Van Vleck TransIlluminant Phil Wadler Bell Labs Scot Wingo AuctionRover The best four entries in each category will be awarded $2500, and invited to submit full designs by June 1, 2000. The best design in each category will then receive an additional $7500, while runners-up will each receive $2500. Once winning designs have been announced, $200,000 will be available through open bidding for implementation, testing, and documentation. All of the project's work will be Open Source; all tools will be written in, or scriptable with, Python, and will be required to run on both Linux and Microsoft Windows NT. ---------------------------------------------------------------------- The Software Carpentry project is sponsored by the Advanced Computing Laboratory at the U.S. Department of Energy's Los Alamos National Laboratory (http://www.acl.lanl.gov), and administered by Code Sourcery, LLC (http://www.codesourcery.com). The project's aim is to encourage adoption of better software development practices by making software tools easier to use, and by documenting design, testing, and related activities. For more information on the project, or to let us know that you intend to submit a proposal, see http://www.software-carpentry.com, or mail info@software-carpentry.com. --168427786-1646135556-947871613=:8785 Content-Type: IMAGE/GIF; name="software-carpentry-logo.gif" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="software-carpentry-logo.gif" R0lGODlhLAGhANX/AIACFYU8R2RkZqWlp0pKS+np6tXV1snJyr+/wLW2u+Dh 5srM1Pf4/PT1+e7v877Ax4GDiZygq6Sos4yPl5aZobm7wNrc4aywuXF0efv8 /M7PzywtLJF8U0s4F6mTa76pgXBeQE0+LeDb2M7JxsfAvaCPi7yysJBxb7Ge nf////7+/v39/fv7+/n5+fj4+Pb29vPz8/Ly8u/v7+3t7ebm5uLi4t3d3dnZ 2dLS0sXFxa6urh4eHg8PDwgICAMDAwAAACwAAAAALAGhAEAG/8CUcEgsGo/I pHLJbDqf0Kh0Sq1ar9isdsvter/gsFipcjXLQ1aBhtDg3m/NLdN0rZotVpPV aq7MTH9OLipFOSgxRXZ4dEx5e3pMLJFLGYBLgkxld0yLjpRKj0ktM4VEMgk6 FRcQGBILCrELEwITCRe4uRgEBAICvLwYF6sJEjV9RC4yRjKJRCwzoCkxy0QZ BdIupUUzL0WkpkMyMEUrMnQ2HOoeHh/u7OocJi8uOiEgNUYzAhsbO/0EMPDb UKFQDG/WYtjYEKJfCF4gfIEgQCOGtBfOhqiYcUmINmYIh7SQEU4ItSIZohWB UW3IigLIRM7gJI7csxmNaip5QYNmEv8XNKRV2EBBxYAdDNSETLKChs0lNTRU OFIBgqkZBZrA6MmEp7QiKOJxaDcihQsDJFCUKAHhBIgOHULEKGmEBoF//XYE HDhhhYoCLZXIKKADAwQlJ1sgmNBKgEDHkIsy2ZozCQsaHZFcXpoEcJMCMwTb ALWiRlYiMGx0/BtBQtaiLWxkFDKjhk8WNgKnmGGDZoFYFiwUFPLiBgRftf7S UGTjqRAZo4mUPj1EYcwUKmhoEABiLAEIE2h15/BWQGsJEnANuFGkQA1QGWjY zbvBVz8KQqavVE0kO42SL9jAmXu35bYSCnB15wEJNYR2SnRE0FBDSS40196E RMSWAAUYTHD/zAET2BCOCqbtl5l8ShRwA2dHyHCDc0JQcEEBKsBmgIOh3EAd Ei48oMABQjQgwQY//CCMQAqkUIOITKh4HRIz3HDJDOCBF94EFGQZwZbopYfL A/iZpWMnNmQ1UH13IZCGDRgqUVpvS5AIYYqjIQBXBwpyI+USF0TgCwQX3HJB el12GcFxyGG5I3Y2LIcdBCOscINhBVAAgwpsKlEDDoG1YMANoBSAw464UeBa jSq8gIOjQ9iAw1KqtinEpk/ZkCUFE0jwgKCDbqlDCpIaAIoMGuxIIg7OuYAD k0PQYEAMLliJpZZbnudlArcgMGcKMqxqjQ3PombAfxD4s8EuO+Aw/8QLBthQ GQ2jPnODAdfN4O0QGYALKw6yKonDbC8cZ0KEnPZnAwIXCMSrBAkMgN4F2oIC ww02LIArrlheeYEBBiRgWCutTHDAbCx8qoQNByx6BA0pE2FPCDDD3MEJ/E52 ALNEvDDAA7lIcIBPQqgQQcZYavBVEZgeAOMRNkxLrbW4YFvB1EvMcEA+SxB7 AycURPAA1kPAoIGwS7DwBotFlKyBNyxooIOVb0Nm2AC20UVEDQdU08IAx9ky qAQ6tBZBAllfrQQLENiWAwaE2y1E2+omoUEOYKcAQw5KE2FDDjbgC0LMoBNA ggH94ZADjrvlgMMdOADguuskDOHCAQdcV/8D5TkH8DoAnRfAuXSmoy6D6oWw MEG1UAeawNQP6FAAyp2ve0AOzt3OnkiTs5oCDTkYHaPXCGjve+0aGZDD9cTR HtjmN4Tzwi68CEDS8Br4ZL729F93Qw6sCABoehFwWGsQgLfo5WdyzvGdAUZ0 gwNQYAClaYXqfLI57b2AdkqYnAGTsD/04QB0IFyP44jguxzoznUBIIQiMPck I7DgADgQwe5OQJcVTE5lNSpULqRWgQdgrgjsY8LtSLcE7h0gEl37Wnswh7ac 5SAHujHC7A5QgZ7Y4G0DK10OtGcEDVDAMToolGEuMAFKcA99ncnBAokDARm0 QAcCoJHlMFeZI1z/DkhJeCIRn/PE2ZhvjyQAIeggsMb8TE98FXhdALAzucq9 4IkdCaJInkiOE7xOB2jMwBN3RIFiRG1qPcScmlKXg8qYL3ImeeL6upeMJ25w czlARhK1dbcnhkQFk9NAOC6Xgx2ZT5fr2iR2EsAGDOiABabA5e+GUEIzZCAC GMCA4KrlmAhQAI9KUqM1nog6I85gBCrAgWFGgL8nmhJ31XmiEvTIBNOhsgSC lBkGcDDCIdTgdSXYCSSX0AJb7uZ1J2hBODR5uhQMAFvL6+EDDrAAHejgAFw8 gjuZsD8NMAGWsvRa5bKZgyams5dLeCQ6i0ALPahgehtEggYOYAAJZGkC/xVY wNCuxJjH+OJj0QSZs95QCBX4tEXmXEIM1JnH852ij0T44xAgEE+YgQCYhtwi CYMatOk5cp+tWqYQ+tnRWu4RWAfQwfIesFCGamCUjJTqEGZAVSEo9aOrtKjs XFnLHOjBBRignVa358+gTY6eYRPmECrqvieKj44peB8EEmC4tWJVCBrcJvVq 2blw4EADzvCp76Ca1nKWMqkjnWMOlDA9NCLhrTFoasx0UE8hjK+OUnwsEri6 NCJUIAdldQMtjRBOtSrhrSdTnRCfqAcWJIABBRhAEbjXVSXwEnVHEGlEkaYB w0DXCKZL6RGGyATucRYJQ/2sc4mq0r3ycin72/+gSGejwBFNDnVsXZ1GTLcj roLidpV7YQ46wr0NKlN43RuR+XY01PppzqjBnKw9Efy4Q0YIsQcMLVsPcAkV mA+N6z1wIc0yPfh2jya9LecRQVu5FUxvKWeUzvQSqE3Q7uiOFPStWX44hhrb +MY4zrGOd3wEChSpSAQgggZ+zAMHaGQCO/DBj3uwAWwmYAc9+PEPesADAsig bVCWsg94QOUJFGADPNCLP6pMDwL0oMspoAAPeLABAoCZB79KAQ7M/GMl94AA 6LPBDqq8gx3QwAYEsDMBUJkCHWxAyUXqQQi+aoQBSJkHG0TAkvd4ADBLecoC eMoBwhyCPY8rBEr2AQH/cAPmu/AAAQYgUqIpYgRA86DOOwhTocNs6hvUYANR /oGoW3KALC+ZyzwYgAoIwGYwU2AFGOiBknfwKzPrpdNsnsGT2WzqDUzXCQT4 sQAi4VMMIPoHrFX1DwRAExzk+geScYG4JXOKV0+ZdAIokrBTkIFDF8nQRToM D5Q8gHj/YAchocG+EV1lCohbAOGogbt/QDgjZBvIL4CBxO1wkCRMQMoEsN+5 J/CXhf/bf+dmN7fc3QNGy07cGHBJkoFsUET34AARl3iqnJOAH+/gKRcHMk1q nug1FIkHCHn4DzjOwVxD2t9Dby2Pl870pk8h598uEsKdLgUWiBsCc/5xCByg /3Sqe/3rYA+72MdO9rKb/exg7zra174FtV/B7TiG+xVukMQFLMAAds+73u2O d54BkFBcGprc2S4EHXQnIj+lwgT6AZDjWJsKMKg44ckOg1y1poVFYEA0rTm0 WjAAaD5VAQNGnwHYTv4IGjh8CExwKeysgAUvSP1b7iSAGPjlCGfyR0Aw0I95 KwECIJgIAUDgAQ6A8/TIR4KMaOR7LkDUAqM1wnEwYPoxhGUdINgBCD4AD/J0 oBcU6EnimeBmc+nF8bEGmhPCiSibYqAEAxBB6Md/BI/JL/k6Xr5RBs8EBCjA AvNid7dQARyCHFZxY7giLVdyK11jLToQKAOgMkzAD///8Asb0HxOVwIJQnwl oH5RYDUDsCULyHkDQC+8pQIrkAMQEH804FBkwwI3sA05pn+yxgUzMAECeAEP sAp/QwEyKAYDQFPh8TRdskMLdQWL9w+7sAGE9nUkEHwR8R9OcAtgtDAXkAOp gDzWdDG3kjGN4RgQIAGJQAG/UgMllWMlABEPUQLVJwUwYCrV8lI38ADosSUv dTRZoANDeCvVUoTKcwASUFtWkEQbBXYFQAsYIHJI8AIScBydhAsM0yUmdwYN IBwVAE2GkVMR4IFigAHxtG1UsAInhEL9cgQqQAK7AwCshQUESIQPozw9JAGT uAWEKAYG4BcvYQAVwDcCAUH/VrACfOM/t1CHdRh9SEhPOAABB7h0MKBa15YE owgAJcB/Q4ACu5NPUnAAffiKCNVDDcWJXlCLNUYCL6ACN/A2eOgEIegYf4Me piIBEZAFIMICMdBv5Uh1gdRUaMUEluQ6J5COUWAAuwOQRIAD77hDzPMAC3AB hWhj4mhjNqBLnoJFUGAAtPA/XHIcrYEFiFMAK4AAAoAA1AgGKvAy8TSNTdCP AEACI2mK1ug6KNBaNRABUZNQZDU9ctV0SZQkPAYDAqCITYAAmNg1DEgL/oMr F3BdRlABEzBPktKUBMl0TNVUJwCOQWONJ/ACVmkF/ThdyQVKZIU5eLeV+ec1 Ephj/yIgAE04BS2AA40IAV2TADhwAwuwK72CK9EUTXJjGG1IdSegWnLRkmOg M7iFOQcwNtr1dQdgAQ7QgkqpYyUZkvjHY/R3ejDQl2AXkfESdv0mkpP5maAZ mqKJYyxAAVHmA6H2A/WBmhvgUUpgF1GnZISzAgKgZBsQRaNZFxhQJKipaz/A AxCAmj6ATbnZIoGmmoIIdnZxaZcmAAgBAUsWZymAdDzgKCtgb+hGFy9Acmj0 U0LHcRqAaIiGcC2wAz+2irsRaD6wARNSA+YpdXTgUzOwcDvQOfbGAzKQc6pZ A/KxnCxnBDHgcRAQlTlwaHcmBAjwbZLhUy6wcNUJA0bnkf/X+WMbgEwpsJs/ xnEKh2gU4B404Gi8SToqIGk/RgBZ0QBCF2RDwHNTFlHDVmdFoZ8DgEzitgFm oAImQKHI1JJCx5wlenspkAPv6aMCUApId2khQBMr0KMlGhhMGiYTEHWgKA7i 5qMUWps+ugNPcmtW+gMhYAH1pAND6qMbcBozMKZdygPe5qMEUEfq1qVT1nBC gKE+6gO/cqQlqp+Xpi4ygKZSZwNdKp2Ndmk7gJvFeaiIGnbhcAeCmaiO+qiQ GqmSOqk29kRoNDw5MBum81Xh1U0B5hIO1iyYo6SN5ET7dWAbxAJ9NSstFlWH 9TMukT1EwFbi5VatOg2qRAT7Q2j/LkBXCxZL+OKrQsBcIWFDxBNYIDUEv1RY MlZCOaFMldNMQrZXBDUb3OUSuSqqnKVMnnVOlcNLlBqu4hp2KMUEHROCW9ga uMCDnNcatZoCNwAxHKM6sKoEvWpXZbOqSGBiyZoEIUZRrVoDhycAl7A5a2kE tzNiCCAQhlE5zJUZRnBBUBRSgpVBoYUE2TVcprUyx4oYo0qxxhgFLIAACnkA dMiHOkhWKruyA+iNdUlWzJMAUZl8MTAeY2ECIyACOvuYSIAAjMd4FkgAmGcE IyAAMMMQDQEztTeuVhBZyio4EPAA6MBgKrAABJArhhIQDzB6n8cAMvULwEAB HzZfMnav//dFrbLVX9JxQ7P6qUEzYEQwVPUqBBF5VuvADnhbfOoAhSFwJwQg Y9wjAHihe9HkD7+CqR1xWSfQZhHBHXt7tQ1wO4DlERW7EWM7BKYjYqBgPiWm rykGqpk6VYwGt4E1t/AqY49EnErAlBGwsUigAg/gP42IAXLEtClQAuQhqEfA AXBBbvXUAuWHF3vRDxOgCfOXAifgAScAsU7AAjJQA4YKqZl7UXuFHa3xLPgx VK7LDWqkdG3pABNLBA3gC7O5UkNLtjw7WP1aBDJgs+zgDu8QD8F3J3ERva6F AHfxs8O7AYcht+ebPhpAA62AARmRKiOAiDdVCyQwF6HneiTgC/85iQT784zM VL1H4DuJWQSP9F1H0AKHKQb6F49d0E8zYAEXMBv09hhyamM4ygEw4wHd8Q4g sAHdEQJh6DCDcgEcbIrlor8WuAEi8HbYMZLhFHxjETs3BiQqsIIo/AX3kzOH ebaV4wJedCr4cTn+ZQAjc1Tto6vhmwL+938GoAAXIAQVgBy+0Bc4MGIVXDnm +MWWw1IlsTmoQ8VNWSUKiCu/8I7o8YASUAEblAHBM6swlGqMt4QqOg1RfGBT TDsotldts8XptGEpYAMmcCcKcj4xtiM2xMauJWNyBnOnoAGV0wIc8jM0QAEV 0F53cwCo80IR3AU1MiNC4wU0EBwWYJf/rHC1D2CUxWtjFqCMjLGA07KNXlIB CJCclnEmFqi7Tjd741EWU1APBfgnV6KMaKyMAzAVrzsDCLCCfwYBBWEcDYkE NXAj3WUAizLLNIIf7ELBQgADBlDOmrMACZArtBAMuAAowGIDcyBEBqDMwxou 2IExC8iHXMKNgbJW48IEMTDPGXAm6GKM7PLPh3MDN/C/9DYvrjkrz6ICCJIg 8hAhBhC98SoQMJULkAiPdaiF1vSFyqgDnYMb/1GSrGWGWFIYvUExYcDOwPgF RKmyUwOJW3KwXVAAeeyKXjIMEgDPcbICi9cPS2jUTqcCaYkBHd0q/SYAgQKJ CSCUdaglL4Ul/9YkhNf8GMoIASnzRVNAAzdAMhTjEyoSGBlgATLCADViOWWy XHuyLjfARW4NCMYDj2MdKIYyNECyJD7hItDl1kvRArbWHrlBRnvYgMkTKLu4 Bhkdt2OiETXwIjnz1yoAA4sR01/lAnFNQjH4LdviIpzsz9dRHFykIrdEAwqj 2rPxkQMgEBHAg4BzHmri1qAQA52tAhkgU1UyAQ7DGMqYU4n41tJhAxmMBR8k SNiIBTLS0hNgZEFziWVNAcvIBZXHgMZ8LaEE1BqlnLsNGQIgbEo3AwljHoIC OHU43U9AJR55xh1SBTEAE11RABWGAp9IA1mtBk0cjQAQANB9BDOgkv+w49DY wAQXgNDWci0JwDMhyyMFINApoAYt8ZBCcA0/2M0jfgQsoAMDoAMIIALlWAZf xCB+IQMqsQQwEOEz0Ii1sNIJcB6q28EbzhQig0vGFCczkL5VoAJGK0gEQI02 kIrX3QQ0kIoocAWV167JIzXNM4u02NtnuQUqCLYQIFBZYBQX2Y4h2MdYUJKE IwJwqQWZkAzS8AfhwACfo+S2lzYQuwgtEI1N6AJPkiolsQKtszuloJXlkOeN 0CfGXJOglADkkCpAwwJ5DjSWYAQtkBNJdF2ioBEqlCGZsQn90QJgWwt3Rel5 Lg0qkADH8T8tjR7KBenf8OmGLh0IIGypLAD/KbDp+XGPyaDRVCADqmXf5WAC 1yiYGRCN9KwZcOiHWL6DsTwGIB4GeKMCMoAAbFEFi+EYhdKA8JgFItAXMQBH wi4Fxu0EptRUHSDNTJABL+k6zAssZAnvyKtIjmN6CKBDsBhKFdDj9KZ2GeDv 4RDt9BbvKOgHK5ABdFPrQZjh5a4EBXgerUELWWIE8Q4sawUBHpkAkokv8Z4B FQ8Fp6haWSQJo3h8Yz6K724ENAk4+U5WbmO/IDw4TRwGOrMMMTACA1CDTOBF /qPoIviTPmgFVKIui5Phsrx+LmGSgsTNSIM0qAiTGoH0mtHu6t4fRHAAO9Ts 3bOPryv1UdA1FQDz/1F/BsZbC7y1BPfuP3GYJSi9JYDgdkaRA1Y9b3B/Y+yu WsrFBA1A6FygAiMAUK3V25itUDmwAAymk+lNmXDU5T8x4dH0Ugb9GB9TNKbX wDXQbwTA71SnAvBElV33kgGwldRYAigkiPxjkzeJAxUw80sn8DkmA+195AYw U16Ddy7F3M0t+ciRlz+JAFnNdCg4lZ9o8I361I5jFDuoULSjxcXf99L0AM+u YyvwRck+BTAAJnk5wJmol9KkAKP38Ty2An/ZVCCwdG53Axd+kwy1xmQXrw2g AEa/Yxb2k+Na9yFe503l1Njh9ZoABCnhkCi8HB65wwGHcBWHKug0JaUWrf/X 6PB1aCh0GayWfM2aJ5hCucpOrdxnrdzstg8tJQEh1A8JSjTuBgmhGG4SEgxu ENYKxx7LVBJUaBAiMadUVnAEBjJBQ8tYYORgnohI4YheXopWYliKXGCwYGSJ aKFaizJixFhdiXxxh0hNUY1jVodOX29na4lUoHOliZxTS4uyhzJgmIV4h2GA ua6FqFuKWl42Y5qThVq2g3tjo1/xU5e55VNY9LMnimBBgwcRJlS4kGFDhw8h RpQ4cSKpF+ZEqXjRjWLHKxk2FgPokWTJMis2/FD5Y8ceHit9bBDpZgWBlRMy 7FApoErKHz1umGyIYaXKmAR6FO1hQyjDG0l/0mj/qomGzqItJyTIAQECqgwC ivp4CVNHigEbdvhYyWMHgRkqKmwYq5Ltjh0TdBRdueOAzZVLIUAtGiLFhKIE JvhVWVaF4b8EfIgVfEAFBZgbCFiN6QiK4h88idgYu4NpCs8YIHi+1DisTx5J xXrWq5fAkKpqWRLw+cNHghVEYeKenUBI3Lli7W4YQEP4jxAveYyN2fznhhEU rBadEIkFBQwVYuTwnp03UBbZMRApMBeCEBc+fVCAImNsDxzpoiTYy/oHAQgq eyhAP5UIOMOG1OSaDbQqapjrEyFmkEGFDGSb7YcNMBKChd1+SA8bAaJzawgD MNBtrpXkG4K+lcqC8Jr3/26KAr4NVBjAwuGqGJAlVPjrL7+/aoCippU8BGgG IlrYjacCrNrhyEwU84EAHXJAAAPheKhhhbyMEkAGF27YbYMWVMABB80w0EAG IlbkbTmfPFTBANh6UGuHdfziAbf2hrCRxQxkuNIoAmqQBYcEBKPAAHRW8JM3 CGhwwQaweFuwiAZCUAoCBHLQgUMEWPgPwAMyoIFSlSAFSAMEoPJBBxyezGU3 HzYdYK4eBJEhOwIOcEGGAXAL8AUNHGPpgBlcwAG4CzUIapK/csghqaVuwGE3 DAwIUhMdiyoSExVY0GEAWWKgYA8BKOBsmAwOSI0AASbQkogbcqBBBhhqOCCH DP81MvfdAdaZRgUbDoihWvVykMEGQabY8lwK3krBhD0mKEWDHGaIQQYaqgyn iBsSe3eC0tygYYA9CMBggIiLKPdcHUqpcY8UlyigFRr0DbiI3T6h4F9hoHDh ZAJSRsCcFhC4IQYYYjAAgVMQsAGGF2ZwmjMVZphgDwwuEcIGBGqQQWMcKliT iJN1kEIFxXb4Z6q34RbqALl2CCGz1yKImw0DTlRpA8r0DlzwwQkv3PDDEU9c 8cUZb9zxxyGPXPLJKa/c8o8PUNcFJkTCWSpjNNBAHhkO0HaIGw4AOoUYDiDZ 64KH0QCHcArIQd0yNcBohnqLIBgeLg4Iioh8zZ7nAAP/ziig9FQMOEDnFGZY fogVmi9+9eOZGfhYbGTHKN/PNQxdHuVNTyEDHDRQHYbgDTzA+i4MCCffWKtA X3feo2heJBlyKD+FGhKGpOOdgWP0y4DstDCDG6guAzaowRlkcANG1UBeXLgB /VJAgxtgpAU3UFcKCnCDmTiwZUorQg1scAYY3MB6ILzB8zJwA/BBaIFEWIEN ZpiCFVqvEjbACJgwqEF5sACHRSiADVRHxAeySYI2pCBGYGADHqJQJB38YAif R8QcKlB1/0shK1hYBBrYIBxgamEEVXfDHEYQHSkg4eXgGEc5zpGOdZyIAWxX hnzZoAAI0IEEIkABCgRykBEw/2QO3NayHNyADkVgwQE04DEhaeAAM4GCCujV winYAGN6zIHrcgACDpTAHLVzHRV2NzsykE4DlpzFEroIBRZQ8ndaoBcGN5lH MtTOf1PY3SmnsDkcNDIVkNRCDApFBhrowJASuEAFFrAAA1iAmtSM5gUAKQFB HmAAE6CANr/5qjZSgQYfpEIBckgFfLmyZTV4HhVcUANhxECUIOgACbLAghrU 8gorsBcLJrABgaKMYUIoJxtqkM4poJMNMqhBhqaATHbmogbjhEILKiqJGphz CgeNRAIq8IBojnSkB1iASUWKUpIu4AEmXYAhCzlRx7WAA6IcJSZYoBuB7gAz uqEAMf+nkAAMCKAPRMNAL+14kAs84AEVkECJBBDVqEKgqRWw6lWF+i4BoAYC FLhqSCUAxxfY1AMe+MBZy8oBFMhDipqAgEB3mrISbcAAZZiAHzbQh7zq9T5J zcTFyveCBFwAmxCYgAMMoAEFqGATDDCXMwl7gQQkBl4iXcBTjYqBoU6ACdnD o7paoASRALB87MpB5z45DRx0UkU5GCYRPouNHGjAQLxDAQc4UNazfiCtNQXB b+3ZgQ5AQF0F0IAAeBpXzQqUOOFxXv408NaigkCq1AXBCXBwPAGyVgj8U+WI dNldJWCEXjNcgb7kwTHXqeBi6Kid8E4X3hS8YLbh4OQMQ3v/AC28oADMuEEE ADkB5M2jAMVQQQEEAAFAAjiqC2hAFFTwhQsUMgIWsFnLCiCHGWCwBTSYiQww yIJIFeEFNPBYAfg5XxpkqAAtPK8HbAoCAlC3usANrnBBgAMZeIwGmYFrW4Yq 0AdFiB0z0EAIqHsCUZ6AA9iSQgYK8E4Qv4IGbYRBhqeBYhJ7uAgy+KCI/+Hl XtCgiy7gsnpaaOZ3btgNMxjkBBAA1OlBYKtShYADGOtXIYwAtyC4wQqywFgr /Fa4EAA0FVqgU+UKQKA/JYMKFGAAEcBAA7k9wTv1DArlSdIMFtjATyWwAQbI ORLBa5hJaMBkD3CgoAsN7gjyTIW1/8EVLSlj9F1IDYUYTAACfbWDC4g11Knq N6n6AiYU6AVfIRggwQg42Qq8S+raAU4LLsiBA4wGBa1ZwHzRSqQNL8ZR1cq3 CAmwaW53W4JV9xm4wh3uocmJAB8vWqAQUAH/EEkG+jYhqjmgggzEZa46J7gE CJBBC0SQBk9AtAh4RKoYo1aG2tWVDDBQAqdZES0tgIQNIJGDCiJwgSPJRyMM 34XJWYEDAcnBAXTeTgpa8O1XuKMMHtfECMhaU7P2tqbuRnKvcy0DRdc6yBt4 eQswfUkXuKASmsXABKAOgaFqNsE6GIGEGnlvqafoI7HUxAswPg0XoDwXSQ+a zEMR8gwPIP/XhEjAF/wNBToLQNkOcYE9Q2DWD5zArDXtuQD+eIEI1J0MjKZ1 TwWatkcwlgYmGIAJMLYCeLdZsyUgQURWEC2KF04CEugv2w1CAwMUQAEXK8IC hM2nh6wAt2UFgd0EkNvXE3oCne+8ZAdA9hHRuiVzJYDuG6ICHXTgtxy49EPy pawb6KACxyZItJSNb37icfM6zEHt1/DT3dF2evqa4bTNwd7+nU4BCrAAvSoA B5BJFV4ZiBY6AFj988p32oG+2AyjNwBh2w3q3oRAcEMAwG6PsHSg+qwttYYA gA5gApJrA/ZAoEqDY3IAaMTvtYTA4uSLXrhPHKLl+8YrCnCgBHD/DLc+IAnk YbVcx/1yAP5yQP70hZ84huJsQAcgwAQiSAd0wBXWJwfCweFkK+6uwJJagF8w jQU6L/ukgAXkIAOK0GOYkAgQgAbMzwAMIAHKSeDsDCBmQgXIBAuEkF8syQK4 yrD6z5sKqfMEMLJ6xWNWwJKUkAFCAK5K5C5SAaIwLQOEcAnd0AlhILhsilRe oQjd0Apa4ACYr6kkK4AwTQViAAEEiQZoIAEKUJZkSaZAQe1qpO3uIAem0ABW 6gEkQKomIOwMwrC4ogwFicIEELKeSROnx/A2YA4fxCQGxt1EyQPEzQ1yYMKE jf2i6ukMqfog7N684z5ugAI0oAIoAH4g/wLkLgAJQ2+apMkBcGAC6oQHvimq LsAhKsMU+48CzNCQVpGwEmAAfO0OVAAW57BrhGIFTgDHRKlFBgEGKiACfrH2 KiCyCEsCFG6qvMkCsUAKTGACBgBiXEAHBAAHgE8IoK8MqA8K1C4FtG+2pC1a SDEFEkABKsACmgY71AICLkDqwCVavM6GvO/R7m8IEOAUUVGQxNH2CKsCdMAR OOkcqQCAcMAFMEAOdaMCbIMkKy5acpED8ccMAEsF/BC3lO1inE8IEkDgKCAR Isv20HDBAknqfrGr4AsD4UAEIGAGWMAECCAHKqNXNC4hnPHzEGJLLGDuqMqq nClVGkIByBDqwP/RJV9SAnQgJmexEFTgrQZKN2zSJGrAFlntDropwSpgsPYR wCqgUwZgAAIJplIRHKUKNXSgGGYAAmSABRBAAEYgBWznIkUhIvuSINpFAqKp qRgTDRXAIcrQDPFyHCXrAnRAk9AxoAJzAwbTJFZgMzVLCd1Am+AlH/fxMbOJ KmHKLgUpNoWNqxIAAkRANDEgNCXiCCVSbQiiBbzJm5jKOG0vAthRE75FCCKg JVURJiUrAYgNE1ZANx1QMAVnqNpz43RAaybAOAkLAcKTj5RQBVygACzgAiYg kOyy/wxrwriCK54O8ApB89gkWqxntc4xPL4JCXenPudvhiQw/PTFdBL/gJCg TgLAUxxHMbRWcHhacBg6EGEOIHsAywC+MRybaQBrEwH0xXo0MOMQ0GtcS2jg img2IFYAaAK7jyKHIDzkC4/qk77G7yf3JQqMjU3orC8vRtnYZbISjDFr05ko AAZWi35i8A0UABz7LwIe4AYSi9cWVLMgoALKR0kXgh8HAAcNAhQJqTlrD5tg KpAUwgW6SjbFMQ3JcTGBMBQqg0RTDG5ORgAejgiYaUv3cS+dSQJc8Q0KQAIW dFO5SrOGEiEKwA9EVRhLDZusMgIWQAr4kzLhLCGaMxXzkhVB6gLGUxQG6QEe tSOGRf+GijNJzRG3aiovYADQkDTNQArqMSRR/wMDuO0RFtJ8isAERNUPcMIN UE4q0fACtlAZzRQCGMlah5M5KcxGE+EBKEChhoEmiOBWe8lYq0AT9XBEBmDu omoCTCAXMSIHTgYDhDXwuO4jHq0cWaAAvKMAHKCf5KwhyeAh+2Ra+0AAIKki AXF4AuAEJoBAA0AHngsKTAAAAkAAAsBjLcokye2SEEBQa1RWE+ABwoAMatKT TksI2FWMgFILMPBTuwCSygUvLojOehUBEIAEaEDQrgAFheCPgrUxqbIMOGYD p8DZVqAABoAARvYCz9IgVKAEHBbJMAEFAOBrvzYAcDMKZiBkwVZsQ+EFCjQ9 VbYCDHEhZlYhbGAAKv8AfJDpABKg4N71EQ4gFAUAsvRSMrWpau3ABirmBZ6N JDBga0HgwQqhBMD2a0VAEyH3bN1VCwZpXMkVpB6AOOAWTXMVFDKgAHXAO7YK BwXio+xRAPax85gJkC73Cm4AAmLgIAVgckFhBdymBWZCdwONqBwWBOrBG9xm 7IRgBSo3bJkB6bCA5oYgeT02HZyXeIPGHLg1LyMrEUJqAdiO6RwJ01zAY1hg d83hVs2Jd7HAe1NhC9UXQojmXwgxQ3Q3aHpXUrRGAELOmSKAWPlx6eRgfIOG DV1gM12gBSZGBPhleudBpgCLCFgndUKjRxng9bY2aQJttdQlleDgBCI3AHT/ ZnM2VghIC0k4GGxPAHp69A0uhn6iLQUMQHPblqn8jWOUbX1gJwEXabs49AMl Ek3BRj2WQGfkJIeBx31UdMDcQwfehWjSJjwiKX+KMgX4p5JCgz+jqlI7T3An oMRSeAVoCWGQuAo4aQIQ+DNd64mH4L4yrtUI4gX4YGstEQpIoIMxwWy/9vII 4T0XTD219zEvIHQJYpASAJcOojEgYADy1nMjoQZM92LRUHAhBhRChZFGAAP+ 1SNgYGv7oDevoAY6mGUKQQTomBC+iTbX06o6l/AUIm4Z4jZVoAZoUJEJIQMi YKgowFT3mAKa8g4oYJg0QGVidxRiINd8gRkMQJND/2Bi56B2oRcgm4Fwz6Fj wRYFpqAFhnkKXpg2+7ilBiCNfkES9qHidIaV44ENxoEMXCAGiAPY9E8IF5Ub ahlecDmQAKmgoC2OYUEkJgCfZtfeLrAkuQGgUyC7AJlgSOaYNVmXy0AGDMBr wdYEJs94WokMZgkHYMCOT6B3mweXbOCbXJccQSqkDLGNDFqPTG2XIAkXyBl6 IMnsividcyF0SEAQYuA+IWAmmgddnZLOQDI84SUCztGUJG6RrEAH4sxwMeDQ 1geNr6AL2FgUcgCZa1ULShgATlgUHNpj0W4a8ldWUbmlHiCYQ2GlF4JT7AUH 9E+npwAGzAUDqJIf8fc0H/9BEv2pBPx5KhAAmRVvFOwYBcRanSLXpYtgALAp e0OaqdC6I8haIValFmpgJadaC3DAXBSsKunsPEGhHCvBXMYWFDZGHqAMy5qB zFRSkzugm7tsxVKBBiLXFWLgzNKhAD6oxLpItqXAjiugizZGJHAg5Aw7pFqq AurqwDCoxNpItn+IBlJsBmjgeTqMZW71hVKhAEB5dUh7epCbFZTbiAoMLvpK A3TABNikuVdbQv6Hsk9VayBgf7PAzNqIucuoyq7Dms3FBkTCnzAIBkYsCmRb C2pAA+inBRahc1QuHXTAtEvgdmwAB1TnBaTZqkXYooeBCmkHwG2ICsUgeVGA fl7/WQOugQZ8+5SBewHg1D1woO4KAAdmiAWqRR6MbIYaCAf4CUzJSGbRVE2w YREwggY0QF1YgArHR8VTQU1dgRH7SAAoYXhkPOVq3CzMpfYGVb3BsTQo7XZa 3IFt4CkLwAUoAAJIwAD4qQVOPHlw3Bio8CC2BJlLgA2ydpr/mgpWIKupmQwI u1BROQcWIIopYpDqliJUYGIAuQjcjM4yV0S3qjtJlQquAxxbYWLU2iOET81z jQXsOIxD4cFLQKZ0YLC2OQlw4AKe9XNx1SNEkpTtcb1TsTunjgwTQKYY6wZI AAaEytEWYgYyigyQSRqQF8GhOYPOFqgqYWgfDRK70oQ1/yyZTCYRDrulNOAB bGCrdWifyuAFwqYMzEy0V7rD+osMSgW24RydLEkGPGEIbB3a10eQnq5AYxMr t2pTs8I4+6rD4AGTIOCpzaecSM2f1Fr0YFo9Luh5kVkNymCOv3aXG6jJ+8kG /uwNzDYAzqASFggGImAxv1oJcEAHNKjXI+hTV2f0ymCFlqiHRx2MEJ4KiMgG BNt8bACJpiAHEtKgFkXiJCgDHqA7LwCPCHRTpa4X2c/pugqQWXyXNeQGhN4v ISDg871yS+BS7UAGwHY6p2AAOverlwC832axIeI9vYUQGEsBeM2bEIAKFyDn l9XpqG6rnO50BecvkVkAci0GTP+A6Zi+6U8ABRpJB6pKhk2qSuCmQEfeI37j rjNBBSyAHzWrQJ/pATRgAXDAE5WV6lBjAg5Vbgt8CFyACgncEVTgBExbAGZo YCS8GbLlDGpgyaeHwolgBir/eNVUJJrmdvLlmYC76isAvkqfny7/W4cgxVdc TV0cB8pnBarFehh64QEVTXUsx0VIyVecClUnxUuLCtEBBgzgi0ZAAD7JAN4H B0q+9Dm89dnkeEQvH0P0llfWAhrAASzgNYmABpJ/CARc9w3q/TVkEbRAYeRh BRKqZVgeCFKqU6hoNBJkqeWyYFsxUy2bMjqzZaKpGk37ssG0tJoXLJYgHo/c 4YBD2KL/MlsruuKWY1HVGMp0UWk5ZTG11BQswUA4WCS8RLHgRcWYMfHRqER9 6UUV1BAusdjMMOkIjNSwRGXYIMrRidVk/tlwMo3NLgFWMc257Ekywdj8WgZr IScrC2EcORM0LEtPU1czVaitHSzgJJBZg4cv52jAKDiKp1fPCAj4qcPHy8tn CDg7f8/rK6dpL2gcSOBqH0EmNnDAKCChWEF4NARAaChR4g0NA5fV0NBFCoF7 R0ZQi6HhRi5lLHAYAKUsgwEcdZa90NFmmwYcOUoa1MBrGQ0N+ZYV8ElthgYD UFwgaKAAgRYZRVVJc4ED4TQWLW0pUzFAQAVqGS8qI/pTmdOx/8mkGsCJrAVK aTBoQJX2gsZLFiA8GtkoLQMNrEDBKisAWMuAbQu4oVSbKBW1FjQeVaURZhpf XgkYFBhQUkWBnX/X6ZW71ayWtyqVGYIsLdLkaQVIURM8UUiKFS9uv2ChIsO7 2QRvBIzju+EACwtyDE+nQoYADC+TQ48ufTr16tBV2IBw07p1DTl+xmCjOsWN HMKXvMiRA2uBHGkteYe9ZAa5dyoM5LjIgk3cLd/tHJADQynQYN4eNsmXggzk lITfRTDUF4UNOdygSYBY1eDeKgGGVuABca3g3U/tHcDQfRRqot5OE76nS4AX 0adBb/gluOCHUeD30woBDljgebV51/9aCu0ZoEV5D0ZoUA6htcBGVAkuIYOQ UszQWwox+LVCAc8lAqUKMwyYwgtQKugXCwX0p6BnGWyphQuAzTBlCwVYOUOW bUYBg2dfhjkmMjKMR6WVUmrBwgynYalFBjOkqacWXwbqpxYzBOrCDDjFsCae TMQApZZcSlHAaYRGMeeonnGXqqqrstqqq6/CGquss9Jaq6234pqrrrvy2muu CQiwwQ47hCDAIQQQkEA8MmBAwLAbEDAAEzsmEJqv8Jgi7A4bCMBUsAJMeS04 KiCQAJm06vCDuuv+4IMP6+4QpjUCvPsDDwLwoC4BUmywLg7iKkcAuwOv6wNy AIeDw7o9kBb/aw7utssDDpkYILC6IdSZgw4DJOBSUzfsoK4PENCAwbY5yGBA yO3qMEYNRxUQxgpvQcXCGPK9psqcYNmAwMY6IFDhpJe+4IoK3RxgpZgHbJyA UdPY0AO7GyCQyQEW/8DwKgb4PADQZnU2M2xsJaABVDBUOZcqMSDg9QGgRnFD AjrokEOCfMCgQkIu0n3AnzrU2wMCNRySCJpnQtUzAq7M9Yjefc0nQxZzoRpO ugsPMBkL/f4gACE1YM2uDz1MkIkABK9bIQaorxsCBaKvq8Pr7fqwgwoEuFtv uxvcsTLqG0wGge4/6MD5uhuo4sLpBPvAw8HJYKD7vlHkwO7BOvAw/zy7ITiw xAQiv4vBBsMTQC+7zhJMdRQD7KB9uwIssbzIArRfsA8EECI/6gTU8C7E7QyM BxCAnboocDqI1QsCiqnGCr7Huh1QIBc3qFftECCDAeTrYpl4k+8m0BoViCKD PqgADEqoghhMIHrrwoAMZCC1glFgBTcwngAoYIEVDIBdpVOB7zAgBBdQQHjn k4HxBCLCCSyBBisb2VmM94OIaOEAzdGL+dp1KQPoTlpfmoAQ6yUAG/jOBAPA YMGStbqFCQ1rBLhUCs74gw20QAQT0J8PNgCBELALfkKIycJw8AIYvAAKA5iA 736wAxvMrnNbyWMmVlABdmGAAi5YYDUyQf+B+qEOfisYn76igADd6WCDxotg UzLYg38hw4E/2NfldmAx3hnghVpbggpWgJ8XxKB4eTTGC59oSR5A8HYU5EEP iklBAqTpShlUFwSUVoMfCeEAGigaBZxIyiXEYJnwUwEFgLkdFxgPA7N4ge/2 9ciFEZOY7FKWChKwLh5sJAOqJEAu3KkuHpAGaxvIRA02cC8m5DB2S3AjEucR vXeFUgUqeMEElvmDBLBgmVDEpkR1wTkfUOBPpvwXAgiAgcmIQJY2WJ4AcOA/ DahSB9QLWe5Eti49LqEGvVTpo4zXg2Hh9Fk+RMYK5OcDmC7hBgWjKftYV8Bc yECEz3PTKJnAgBD/1GufiWxeTnG6AaHZ05CTUcE8o5BVfLZgAgTI6BIsxsRl LK+OXF0XPfWBO3VtQAtvVVcFVCA/eDJBlT5okfE0U0p19eAJyxOn99iaL4Ol gJP06+Q1KEgBJbQge+oCagF6yRRkyC8EuVhBswhQJGSooHqYi0IFdBfBgGYt ATJgwQTXNYB3uMCUQkMGOEXW1hQMoJc+FK26LruEBCDrmgiAF1TWytjfvnMG M+jB6NK4rtJJw43BUtcOCkBJcMy1XdodGBRV4MRtMXeF3Cym6HqwU/T4rnkQ 8yu/RKdH/WVttinIqruGNbDmCUAH5C1YDwSAk9DxwJ+QXIYFHNpSBG4g/5Co zZqARceDCQBueKMDqkXvK7p9LuFyIhMWu3jAUIgVDAP61d3oqpsC3mbthTuo wQ562a6bNoycBOvKPs4IAQgU0pDg2kMOsntPAVgXt9kDZovdpUBLVMCJb/Tb +rLX4h6AZAvjezJNo4ADTsILAirUVwKYS+Ts+QADSrMBARxqLwJYgBpXy7GO 5TsAJW9gjgXLr5d3wAPJEjYKtX0flt9YZSGoAMfa20BGVyC8HgBTnRgwwegS LbUNwKYCOSaAZNr35Uc3TEyFhO5saskCFqzgutNSKDUUo9AVKM0aorZEqC2R iVUvYxYZgLUyUE3JWiot1XvwAgXIONkJdAHV3ERR6KdbveusJJIpBfDdRBHm 7GfblXWavdbtFqY7Hnz22dp+9gxq0IAMZOAt0OwVuZwFzA1gYNzbXje72+3u d8M73tIIAgA7 --168427786-1646135556-947871613=:8785-- From jeremy@cnri.reston.va.us Mon Jan 17 20:35:37 2000 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Mon, 17 Jan 2000 15:35:37 -0500 (EST) Subject: [Python-Dev] developers day session on compilers Message-ID: <14467.32025.761662.841271@goon.cnri.reston.va.us> I am championing a Developers' Day session on a Python compiler. There is a short Web page describing the goals of the session at http://www.python.org/workshops/2000-01/compiler.html. I'd appreciate feedback on the content and format of the session. If you have ideas for what we should talk about or do, please followup to me or to the list. Jeremy From mal@lemburg.com Tue Jan 18 22:55:04 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 18 Jan 2000 23:55:04 +0100 Subject: [Python-Dev] Python Tools/ Message-ID: <3884EF48.A6107775@lemburg.com> I was just looking through the Tools dir of the CVS version (looking for a tool which autoexpands tabs in Python source files -- which I didn't find) and found some other useful scripts along the way. To my surprise these executable files did not have a .py extension even though were Python source files. Is this intended ? I find that scripts like "world" provide useful information which would be nice to have in the standard lib -- with .py extension... Other tidbits: I noted that at least in my CVS tree the Tools/ht2html dir does not include any executable: have I missed something ? The script Tools/scripts/parseentities.py is not executable for some reason. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From guido@CNRI.Reston.VA.US Wed Jan 19 12:50:05 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 19 Jan 2000 07:50:05 -0500 Subject: [Python-Dev] Python Tools/ In-Reply-To: Your message of "Tue, 18 Jan 2000 23:55:04 +0100." <3884EF48.A6107775@lemburg.com> References: <3884EF48.A6107775@lemburg.com> Message-ID: <200001191250.HAA18786@eric.cnri.reston.va.us> > I was just looking through the Tools dir of the CVS version > (looking for a tool which autoexpands tabs in Python source > files -- which I didn't find) and found some other useful scripts > along the way. > > To my surprise these executable files did not have a .py > extension even though were Python source files. Is this > intended ? I find that scripts like "world" provide useful > information which would be nice to have in the standard > lib -- with .py extension... I would agree, but that's Barry's creation, so I'll let him answer for himself. Any other scripts with the same problem? > Other tidbits: > > I noted that at least in my CVS tree the Tools/ht2html > dir does not include any executable: have I missed something ? Actually, that directory is a ghost and shouldn't have been exported at all. (Barry, can you erase it from sweetpea?) > The script Tools/scripts/parseentities.py is not executable > for some reason. Fixed now. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 19 16:24:41 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 19 Jan 2000 11:24:41 -0500 (EST) Subject: [Python-Dev] Python Tools/ References: <3884EF48.A6107775@lemburg.com> Message-ID: <14469.58697.116588.501355@anthem.cnri.reston.va.us> >>>>> "M" == M writes: M> To my surprise these executable files did not have a .py M> extension even though were Python source files. Is this M> intended ? I find that scripts like "world" provide useful M> information which would be nice to have in the standard M> lib -- with .py extension... I hadn't thought about making world a module, but if others agree, I can play a little CVS magic to move the file to world.py. M> I noted that at least in my CVS tree the Tools/ht2html dir does M> not include any executable: have I missed something ? If you do a `cvs up -P' (-P for prune) you'll find that that directory goes away. At one point I started to add the ht2html scripts to the Python tools, but then we decided not to. Unfortunately, once a directory's been added to CVS it can never be removed (hence -P). If you're really interested in the ht2html scripts, which are used to build the Python.Org and JPython.Org sites (as well as my personal pages), please see http://www.python.org/~bwarsaw/software/pyware.html -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 19 17:32:50 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 19 Jan 2000 12:32:50 -0500 (EST) Subject: [Python-Dev] Python Tools/ References: <3884EF48.A6107775@lemburg.com> <14469.58697.116588.501355@anthem.cnri.reston.va.us> Message-ID: <14469.62786.178265.983781@anthem.cnri.reston.va.us> >>>>> "BAW" == Barry A Warsaw writes: BAW> If you do a `cvs up -P' (-P for prune) you'll find that that BAW> directory goes away. At one point I started to add the BAW> ht2html scripts to the Python tools, but then we decided not BAW> to. Unfortunately, once a directory's been added to CVS it BAW> can never be removed (hence -P). I just check this and there is no ht2html directory in Tools anymore. We probably did remove it after you (MAL) had checked it out. You can either ignore the directory, or delete it from your working dirs. If cvs complains after deleting it, you may have to manually edit the CVS/Entries file. Sorry about that -- we know better now. -Barry From gerrit@nl.linux.org Wed Jan 19 20:14:27 2000 From: gerrit@nl.linux.org (Gerrit Holl) Date: Wed, 19 Jan 2000 21:14:27 +0100 Subject: [Python-Dev] ''.join in 1.6 Message-ID: <20000119211427.A3755@stopcontact.palga.uucp> Hello, I have a question/suggestion about ''.join in Python 1.6. Suppose I have this list: l = ["This", "is", "a", "test"] Currently, I would join it this way into a tab-delimeted string: s = string.join(l, '\t') In 1.6, I should do it this way: '\t'.join(s) I think it would be better to have that method on the *list*: s.join('\t') That's more clear, isn't it? regards, Gerrit. -- Please correct any bad English you encounter in my email message! -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- From fredrik@pythonware.com Wed Jan 19 20:43:36 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 19 Jan 2000 21:43:36 +0100 Subject: [Python-Dev] ''.join in 1.6 References: <20000119211427.A3755@stopcontact.palga.uucp> Message-ID: <005e01bf62bd$dc8073d0$f29b12c2@secret.pythonware.com> > In 1.6, I should do it this way: > '\t'.join(s) >=20 > I think it would be better to have that method on the *list*: > s.join('\t') >=20 > That's more clear, isn't it? what if "s" is a tuple? an array? a user-defined sequence type? From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 19 20:36:24 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 19 Jan 2000 15:36:24 -0500 (EST) Subject: [Python-Dev] ''.join in 1.6 References: <20000119211427.A3755@stopcontact.palga.uucp> Message-ID: <14470.8264.686274.888365@anthem.cnri.reston.va.us> >>>>> "GH" == Gerrit Holl writes: GH> I think it would be better to have that method on the *list*: GH> s.join('\t') GH> That's more clear, isn't it? Perhaps, but you want join to work on any sequence don't you? By making it a method on string objects, you sort of get that for free (as opposed to putting it on lists, sequences, and requiring all class authors to add it as well). -Barry From da@ski.org Wed Jan 19 20:54:03 2000 From: da@ski.org (David Ascher) Date: Wed, 19 Jan 2000 12:54:03 -0800 Subject: [Python-Dev] ''.join in 1.6 In-Reply-To: <20000119211427.A3755@stopcontact.palga.uucp> Message-ID: <003b01bf62bf$5191abc0$c355cfc0@ski.org> Gerrit Holl > Currently, I would join it this way into a tab-delimeted string: > s = string.join(l, '\t') > > In 1.6, I should do it this way: > '\t'.join(s) > > I think it would be better to have that method on the *list*: > s.join('\t') > > That's more clear, isn't it? As Tim pointed out when they were discussed, the clearest way to express it with the new methods is to do: tab = '\t' tab.join(s) Similarly space = ' ' space.join(s) etc. --david ascher From da@ski.org Wed Jan 19 22:41:47 2000 From: da@ski.org (David Ascher) Date: Wed, 19 Jan 2000 14:41:47 -0800 Subject: [Python-Dev] SOAP Message-ID: <000101bf62ce$5e509e70$c355cfc0@ski.org> This is a multi-part message in MIME format. ------=_NextPart_000_0002_01BF628B.502D5E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Who if anyone is working on SOAP clients and servers for Python? --david ascher ------=_NextPart_000_0002_01BF628B.502D5E70 Content-Type: text/x-vcard; name="David Ascher.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="David Ascher.vcf" BEGIN:VCARD VERSION:2.1 N:Ascher;David FN:David Ascher ORG:Smith Kettlewell Eye Research Institute TEL;WORK;VOICE:415-345-2095 TEL;HOME;VOICE:415-345-2095 TEL;WORK;FAX:415-345-8455 ADR;WORK:;;2318 Fillmore St;San Francisco;CA;94115;US LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:2318 Fillmore St=3D0D=3D0ASan = Francisco, CA 94115=3D0D=3D0AUS ADR;HOME:;;522A Green St;San Francisco;CA;94133;US LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:522A Green St=3D0D=3D0ASan = Francisco, CA 94133=3D0D=3D0AUS EMAIL;PREF;INTERNET:da@ski.org REV:20000107T184849Z END:VCARD ------=_NextPart_000_0002_01BF628B.502D5E70-- From akuchlin@mems-exchange.org Thu Jan 20 04:19:33 2000 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Wed, 19 Jan 2000 23:19:33 -0500 Subject: [Python-Dev] Changing existing class instances Message-ID: <200001200419.XAA01969@mira.erols.com> Currently, when you replace a class definition with an updated version, it's really difficult to change existing class instances; you'd have to essentially sweep every Python object and check if it's an instance, starting at roots such as __main__ and sys.modules. This makes developing code in a long-running process difficult, Zope being the best example of this. When you modify a class definition used by Zope code, you can't update existing instances floating around in memory. Over dinner, a friend and I were discussing this, and we thought it probably isn't difficult to add an extra level of indirection to allow fixing this. The only other option we could think of is either the complete scan of all objects, or inserting a forwarding pointer into PyClassObjects that points to the replacing class if !NULL, and then chase pointers when accessing PyInstanceObject->in_class. A quick hack to implement the extra indirection took about half an hour. It does these things: * Defines a PyClassHandle type: struct _PyClassHandle { PyClassHandle *next; /* ptr to next PyClassHandle in linked list */ PyClassObject *klass; /* The class object */ } ; * The in_class attribute of PyInstanceObject becomes a PyClassHandle* instead of a PyClassObject*, and all code such as inst->in_class becomes inst->in_class->klass. * As a quick hack to allow changing the class object referenced by a handle, I added a .forward( ) method to class objects. This basically does self.handle->klass = . The end result is that obj.__class__.forward(newclass) changes obj to be an instance of newclass, and all other instances of obj.__class__ also mutate to become newclass instances. Making this purely automatic seems hard; you'd have to catch things like 'import ftplib; ftplib.FTP = myclass', which would require automatically calling ftplib.FTP.forward( myclass ) to make all existing FTP instances mutate. Would it be worthwhile to export some hook for doing this in 1.6? The cost is adding an extra pointer deref to all access to PyInstanceObject->in_class. (This could probably also be added to ExtensionClass, and probably doesn't need to be added to core Python to help out Zope. Just a thought...) -- A.M. Kuchling http://starship.python.net/crew/amk/ Here the skull of a consumptive child becomes part of a great machine for calculating the motions of the stars. Here, a yellow bird frets within the ribcage of an unjust man. -- Welcome to Orqwith, in DOOM PATROL #22 From guido@CNRI.Reston.VA.US Thu Jan 20 04:41:29 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 19 Jan 2000 23:41:29 -0500 Subject: [Python-Dev] Changing existing class instances In-Reply-To: Your message of "Wed, 19 Jan 2000 23:19:33 EST." <200001200419.XAA01969@mira.erols.com> References: <200001200419.XAA01969@mira.erols.com> Message-ID: <200001200441.XAA20952@eric.cnri.reston.va.us> > Currently, when you replace a class definition with an updated > version, it's really difficult to change existing class instances; > you'd have to essentially sweep every Python object and check if it's > an instance, starting at roots such as __main__ and sys.modules. This > makes developing code in a long-running process difficult, Zope being > the best example of this. When you modify a class definition used by > Zope code, you can't update existing instances floating around in > memory. There might be another solution. When you reload a module, the module object and its dictionary are reused. Perhaps class and function objects could similarly be reused? It would mean that a class or def statement looks for an existing object with the same name and type, and overwrites that. Voila, all references are automatically updated. This is more work (e.g. for classes, a new bytecode may have to be invented because the class creation process must be done differently) but it's much less of a hack, and I think it would be more reliable. (Even though it alters borderline semantics a bit.) (Your extra indirection also slows things down, although I don't know by how much -- not just the extra memory reference but also less locality of reference so more cache hits.) --Guido van Rossum (home page: http://www.python.org/~guido/) From tim_one@email.msn.com Thu Jan 20 05:59:51 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 20 Jan 2000 00:59:51 -0500 Subject: [Python-Dev] Changing existing class instances In-Reply-To: <200001200441.XAA20952@eric.cnri.reston.va.us> Message-ID: <000b01bf630b$91a409a0$31a2143f@tim> [Guido, on Andrew's idea for automagically updating classes] > There might be another solution. When you reload a module, > the module object and its dictionary are reused. > > Perhaps class and function objects could similarly be > reused? It would mean that a class or def statement > looks for an existing object with the same name and type, > and overwrites that. Voila, all references are > automatically updated. Too dangerous, I think. While uncommon in general, I've certainly seen (even written) functions that e.g. return a contained def or class. The intent in such cases is very much to create distinct defs or classes (despite having the same names). In this case I assume "the same name" wouldn't *usually* be found, since the "contained def or class"'s name is local to the containing function. But if there ever happened to be a module-level function or class of the same name, brrrr. Modules differ because their namespace "search path" consists solely of the more-global-than-global sys.modules. > This is more work (e.g. for classes, a new bytecode may > have to be invented because the class creation process > must be done differently) but it's much less of a hack, > and I think it would be more reliable. (Even though it > alters borderline semantics a bit.) How about an explicit function in the "new" module, new.update(class_or_def_old, class_or_def_new) which overwrites old's guts with new's guts (in analogy with dict.update)? Then no semantics change and you don't need new bytecodes. In return, a user who wants to e.g. replace an existing class C would need to do oldC = C do whatever they do to get the new C new.update(oldC, C) Building on that, a short Python loop could do the magic for every class and function in a module; and building on *that*, a short "updating import" function could be written in Python. View it as providing mechanism instead of policy <0.9 wink>. > (Your extra indirection also slows things down, although > I don't know by how much -- not just the extra memory > reference but also less locality of reference so more > cache hits.) Across the universe of all Python programs on all platforms, weighted by importance, it was a slowdown of nearly 4.317%. if-i-had-used-only-one-digit-everyone-would-have- known-i-was-making-it-up -ly y'rs - tim From gstein@lyra.org Thu Jan 20 07:48:29 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 19 Jan 2000 23:48:29 -0800 (PST) Subject: [Python-Dev] Changing existing class instances In-Reply-To: <000b01bf630b$91a409a0$31a2143f@tim> Message-ID: Oh man, oh man... I think this is where I get to say something akin to "I told you so." :-) I already described Tim's proposal in my type proposal paper, as a way to deal with incomplete classes. Essentially, a class object is created "empty" and is later "updated" with the correct bits. The empty class allows two classes to refer to each other in the "recursive type" scenario. In other words, I definitely would support a new class object behavior that allows us to update a class' set of bases and dictionary on the fly. This could then be used to support my solution for the recursive type scenario (which, in turn, means that we don't have to introduce Yet Another Namespace into Python to hold type names). Note: I would agree with Guido, however, on the "look for a class object with the same name", but with the restriction that the name is only replaced in the *target* namespace. i.e. a "class Foo" in a function will only look for Foo in the function's local namespace; it would not overwrite a class in the global space, nor would it overwrite class objects returned by a prior invocation of the function. Cheers, -g On Thu, 20 Jan 2000, Tim Peters wrote: > [Guido, on Andrew's idea for automagically updating > classes] > > > There might be another solution. When you reload a module, > > the module object and its dictionary are reused. > > > > Perhaps class and function objects could similarly be > > reused? It would mean that a class or def statement > > looks for an existing object with the same name and type, > > and overwrites that. Voila, all references are > > automatically updated. > > Too dangerous, I think. While uncommon in general, I've certainly seen > (even written) functions that e.g. return a contained def or class. The > intent in such cases is very much to create distinct defs or classes > (despite having the same names). In this case I assume "the same name" > wouldn't *usually* be found, since the "contained def or class"'s name is > local to the containing function. But if there ever happened to be a > module-level function or class of the same name, brrrr. > > Modules differ because their namespace "search path" consists solely of the > more-global-than-global sys.modules. > > > This is more work (e.g. for classes, a new bytecode may > > have to be invented because the class creation process > > must be done differently) but it's much less of a hack, > > and I think it would be more reliable. (Even though it > > alters borderline semantics a bit.) > > How about an explicit function in the "new" module, > > new.update(class_or_def_old, class_or_def_new) > > which overwrites old's guts with new's guts (in analogy with dict.update)? > Then no semantics change and you don't need new bytecodes. In return, a > user who wants to e.g. replace an existing class C would need to do > > oldC = C > do whatever they do to get the new C > new.update(oldC, C) > > Building on that, a short Python loop could do the magic for every class and > function in a module; and building on *that*, a short "updating import" > function could be written in Python. View it as providing mechanism instead > of policy <0.9 wink>. > > > (Your extra indirection also slows things down, although > > I don't know by how much -- not just the extra memory > > reference but also less locality of reference so more > > cache hits.) > > Across the universe of all Python programs on all platforms, weighted by > importance, it was a slowdown of nearly 4.317%. > > if-i-had-used-only-one-digit-everyone-would-have- > known-i-was-making-it-up -ly y'rs - tim > > > > _______________________________________________ > Python-Dev maillist - Python-Dev@python.org > http://www.python.org/mailman/listinfo/python-dev > -- Greg Stein, http://www.lyra.org/ From fredrik@pythonware.com Thu Jan 20 08:06:32 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 20 Jan 2000 09:06:32 +0100 Subject: [Python-Dev] SOAP References: <000101bf62ce$5e509e70$c355cfc0@ski.org> Message-ID: <006901bf631d$449eea50$f29b12c2@secret.pythonware.com> David Ascher wrote: > Who if anyone is working on SOAP clients and servers for Python? we are (or rather, we will). hope to have code available during (late) Q1. From gerrit@nl.linux.org Thu Jan 20 08:08:01 2000 From: gerrit@nl.linux.org (Gerrit Holl) Date: Thu, 20 Jan 2000 09:08:01 +0100 Subject: [Python-Dev] ''.join in 1.6 In-Reply-To: <005e01bf62bd$dc8073d0$f29b12c2@secret.pythonware.com>; from fredrik@pythonware.com on Wed, Jan 19, 2000 at 09:43:36PM +0100 References: <20000119211427.A3755@stopcontact.palga.uucp> <005e01bf62bd$dc8073d0$f29b12c2@secret.pythonware.com> Message-ID: <20000120090801.A903@stopcontact.palga.uucp> Fredrik Lundh wrote on 948314616: > > In 1.6, I should do it this way: > > '\t'.join(s) > > > > I think it would be better to have that method on the *list*: > > s.join('\t') > > > > That's more clear, isn't it? > > what if "s" is a tuple? an array? a user-defined > sequence type? I understand. Thanks for your answers. regards, Gerrit. -- Please correct any bad English you encounter in my email message! -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- From jim@digicool.com Thu Jan 20 14:06:29 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 20 Jan 2000 09:06:29 -0500 Subject: [Python-Dev] Changing existing class instances References: <200001200419.XAA01969@mira.erols.com> Message-ID: <38871665.C3B6FFEE@digicool.com> "A.M. Kuchling" wrote: > > Currently, when you replace a class definition with an updated > version, it's really difficult to change existing class instances; > you'd have to essentially sweep every Python object and check if it's > an instance, starting at roots such as __main__ and sys.modules. This > makes developing code in a long-running process difficult, Zope being > the best example of this. When you modify a class definition used by > Zope code, you can't update existing instances floating around in > memory. In the case of Zope, if the objects that you care about happen to be persistent objects, then it's relatively easy to arrange to get the objects flushed from memory and reloaded with the new classes. (There are some subtle issues to deal with, like worrying about multiple threads, but in a development environment, you can deal with these, for example, by limiting the server to one thread.) Note that this is really only a special case of a much larger problem. Reloading a module redefines the global variables in a module. It doesn't update any references to those global references from other places, such as instances or *other* modules. For example, imports like: from foo import spam are not updated when foo is reloaded. Maybe you are expecting too much from reload. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From jim@digicool.com Thu Jan 20 14:34:13 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 20 Jan 2000 09:34:13 -0500 Subject: Python 2 namespace change? (was Re: [Python-Dev] Changing existing class instances) References: <200001200419.XAA01969@mira.erols.com> <38871665.C3B6FFEE@digicool.com> Message-ID: <38871CE5.53FB9D68@digicool.com> Jim Fulton wrote: > > Reloading a module redefines the global variables in a module. > It doesn't update any references to those global references > from other places, such as instances or *other* modules. > > For example, imports like: > > from foo import spam > > are not updated when foo is reloaded. A change to the way that namespaces are handled could make this work and have a number of other benefits, like global name usage without namespace lookups. I've suggested this to Guido in the past. His reasonable response is that this would be too big a change for Python 1. Maybe this is something to consider for Python 2? The basic idea (borrowed from Smalltalk) is to have a kind of dictionary that is a collection of "association" objects. An association object is simply a pairing of a name with a value. Association objects can be shared among multiple namespaces. An import like: from foo import spam would copy the association between the name 'foo' and a value from module 'spam' into the current module. If foo is reloaded or if the name is reassigned in spam, the association is modified and the change is seen in any namespaces that imported foo. Similarly if a function uses a global variable: spam=1 def bar(): global spam return spam*2 the compiled function contains the association between spam and it's value. This means that: - When spam is used in the function, it doesn't have to be looked up, - The function object no longer needs to keep a reference to it's globals. This eliminates an annoying circular reference. (I would not replace existing dictionaries with this new kind. I'd have both kinds available.) I think that this would be a really nice change for Python 2. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From guido@CNRI.Reston.VA.US Thu Jan 20 15:20:45 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 20 Jan 2000 10:20:45 -0500 Subject: [Python-Dev] Changing existing class instances In-Reply-To: Your message of "Thu, 20 Jan 2000 00:59:51 EST." <000b01bf630b$91a409a0$31a2143f@tim> References: <000b01bf630b$91a409a0$31a2143f@tim> Message-ID: <200001201520.KAA21137@eric.cnri.reston.va.us> > From: "Tim Peters" > > [Guido, on Andrew's idea for automagically updating > classes] > > > There might be another solution. When you reload a module, > > the module object and its dictionary are reused. > > > > Perhaps class and function objects could similarly be > > reused? It would mean that a class or def statement > > looks for an existing object with the same name and type, > > and overwrites that. Voila, all references are > > automatically updated. > > Too dangerous, I think. While uncommon in general, I've certainly seen > (even written) functions that e.g. return a contained def or class. The > intent in such cases is very much to create distinct defs or classes > (despite having the same names). In this case I assume "the same name" > wouldn't *usually* be found, since the "contained def or class"'s name is > local to the containing function. But if there ever happened to be a > module-level function or class of the same name, brrrr. Agreed that that would be bad. But I wouldn't search outer scopes -- I would only look for a class/def that I was about to stomp on. > Modules differ because their namespace "search path" consists solely of the > more-global-than-global sys.modules. "The search path doesn't enter into it." > > This is more work (e.g. for classes, a new bytecode may > > have to be invented because the class creation process > > must be done differently) but it's much less of a hack, > > and I think it would be more reliable. (Even though it > > alters borderline semantics a bit.) > > How about an explicit function in the "new" module, > > new.update(class_or_def_old, class_or_def_new) > > which overwrites old's guts with new's guts (in analogy with dict.update)? > Then no semantics change and you don't need new bytecodes. Only a slight semantics change (which my full proposal would require too): function objects would become mutable -- their func_code, func_defaults, func_doc and func_globals fields (and, why not, func_name too) should be changeable. If you make all these assignable, it doesn't even have to be a privileged function. > In return, a > user who wants to e.g. replace an existing class C would need to do > > oldC = C > do whatever they do to get the new C > new.update(oldC, C) > > Building on that, a short Python loop could do the magic for every class and > function in a module; and building on *that*, a short "updating import" > function could be written in Python. View it as providing mechanism instead > of policy <0.9 wink>. That's certainly a reasonable compromise. Note that the update on a class should imply an update on its methods, right? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Jan 20 15:45:40 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 20 Jan 2000 10:45:40 -0500 Subject: Python 2 namespace change? (was Re: [Python-Dev] Changing existing class instances) In-Reply-To: Your message of "Thu, 20 Jan 2000 09:34:13 EST." <38871CE5.53FB9D68@digicool.com> References: <200001200419.XAA01969@mira.erols.com> <38871665.C3B6FFEE@digicool.com> <38871CE5.53FB9D68@digicool.com> Message-ID: <200001201545.KAA21304@eric.cnri.reston.va.us> > I've suggested this to Guido in the past. His > reasonable response is that this would be too big a > change for Python 1. Maybe this is something to consider > for Python 2? Note: from now on the new name for Python 2 is Python 3000. :-) > The basic idea (borrowed from Smalltalk) is to have a kind > of dictionary that is a collection of "association" > objects. An association object is simply a pairing of a > name with a value. Association objects can be shared among > multiple namespaces. I've never liked this very much, mostly because it breaks simplicity: the idea that a namespace is a mapping from names to values (e.g. {"limit": 100, "doit": , ...}) is beautifully simple, while the idea of inserting an extra level of indirection, no matter how powerful, is much murkier. There's also the huge change in semantics, as you point out; currently, from foo import bar has the same effect (on bar anyway) as import foo bar = foo.bar # i.e. copying an object reference del foo while under your proposal it would be more akin to changing all references to bar to become references to foo.bar. Of course that's what the moral equivalent of "from ... import ..." does in most other languages anyway, so we might consider this for Python 3000; however it would break a considerable amount of old code, I think. (Not to mention brain and book breakage. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Jan 20 16:01:38 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 20 Jan 2000 11:01:38 -0500 Subject: [Python-Dev] Python 1.6 timing Message-ID: <200001201601.LAA21359@eric.cnri.reston.va.us> Andrew let me repost this mail of his to this list. It's worth a discussion here (if not in a larger forum). My responses are at the bottom. ------- Forwarded Message Date: Wed, 19 Jan 2000 20:17:55 -0500 From: "A.M. Kuchling" To: guido@python.org Subject: Python 1.6 timing I thought a bit more about the release schedule for 1.6, and like the idea of delaying it less and less. Another bad effect of delaying it is that not having Unicode in the core handicaps developing XML tools; we can continue working with wstrop, or integrate MAL's code into the XML-SIG's CVS tree, but it might mean abandoning the XML processing field to Perl & Tcl because the tools can't be made fully standard compliant in time. Options I can think of: 1) Delegating some control to a pumpkin holder [...]. 2) Releasing the Unicode+sre modules as separate add-ons to 1.5. (But would that impose annoying backward-compatibility constraints when they get integrated into 1.6?) 3) Add Unicode, sre, Distutils, plus other minor things and call it 1.5.5, meaning it's not as big a revision as a 1.6 release, but it's bigger than just another patchlevel of bugfixes. I don't remember what other features were planned for 1.6; was there anything major, if static typing is left for 2.0? - -- A.M. Kuchling http://starship.python.net/crew/amk/ Life's too short for chess. -- H.J. Byron ------- End of Forwarded Message There are several other things I can think of now that were planned for 1.6: revamped import, rich comparisons, revised coercions, parallel for loop (for i in L; j in M: ...), extended slicing for all sequences. I've also been thinking about making classes be types (not as huge a change as you think, if you don't allow subclassing built-in types), and adding a built-in array type suitable for use by NumPy. I've also received a conservative GC patch that seems to be fairly easy to apply and has some of Tim Peters' blessing. For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more conservative agenda, as suggested by Andrew: Unicode and distutils are probably the most important things to integrate. (The import utilities are not ready for prime time in my opinion; there are too many issues.) Anybody care to be the pumpkin? That would cut the discussion short; otherwise the problem remains that I can't spend too much time on the next release unless I get funded for it; what little money I've received for CP4E I had better spend on getting some CP4E-related results ASAP, because the next installment of this funding is very much at stake... --Guido van Rossum (home page: http://www.python.org/~guido/) Life's better without braces. -- Bruce Eckel From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jan 20 16:21:30 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 20 Jan 2000 11:21:30 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing References: <200001201601.LAA21359@eric.cnri.reston.va.us> Message-ID: <14471.13834.480356.541389@anthem.cnri.reston.va.us> >>>>> "Guido" == Guido van Rossum writes: Guido> There are several other things I can think of now that were Guido> planned for 1.6: revamped import, rich comparisons, revised Guido> coercions, parallel for loop (for i in L; j in M: ...), Guido> extended slicing for all sequences. I've also been Guido> thinking about making classes be types (not as huge a Guido> change as you think, if you don't allow subclassing Guido> built-in types), and adding a built-in array type suitable Guido> for use by NumPy. I've also received a conservative GC Guido> patch that seems to be fairly easy to apply and has some of Guido> Tim Peters' blessing. All very cool things that could easily wait until 1.7. After all, what's in a number? If, as Andrew puts forth, getting a stable Python release with Unicode is very important for Python's future positioning, then I say let's go with his more modest list, mainly Unicode, sre, and Distutils. We've already got string meths, tons of library improvements, and sundry other things. That's a good enough laundry list for the next release. From a political standpoint, I'd call the next release 1.6 and not bother with another installment in 1.5.x series. And I agree with Andrew, we should fast track that release as much as possible. I'm not sure what the state of the Unicode patches, sre, or Distutils current is, although I haven't seen any of that stuff checked into the tree. My free-time plate is pretty full with JPython and Mailman, but I'm willing to help where possible. -Barry From jim@digicool.com Thu Jan 20 16:21:33 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 20 Jan 2000 11:21:33 -0500 Subject: Version numbering (was Re: [Python-Dev] Python 1.6 timing) References: <200001201601.LAA21359@eric.cnri.reston.va.us> Message-ID: <3887360D.C29A9836@digicool.com> Guido van Rossum wrote: > > Andrew let me repost this mail of his to this list. It's worth a > discussion here (if not in a larger forum). My responses are at the > bottom. > (snip) > > There are several other things I can think of now that were planned > for 1.6: revamped import, rich comparisons, revised coercions, > parallel for loop (for i in L; j in M: ...), extended slicing for all > sequences. I've also been thinking about making classes be types (not > as huge a change as you think, if you don't allow subclassing built-in > types), and adding a built-in array type suitable for use by NumPy. > I've also received a conservative GC patch that seems to be fairly > easy to apply and has some of Tim Peters' blessing. > > For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more > conservative agenda, as suggested by Andrew: Unicode and distutils are > probably the most important things to integrate. (The import > utilities are not ready for prime time in my opinion; there are too > many issues.) (snip) What is the basis of the Python numbering scheme? I thought that there was a notion that: - The first part changed with huge, possibly backward incompatible, changes, - The second part was for new functionality - The third part was for bug fixes. I thought I saw this scheme referenced somewhere and possibly even attributed to Guido. (?) I think that this is a better scheme that what I've seen with the 1.5 releases. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From petrilli@amber.org Thu Jan 20 16:33:52 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Thu, 20 Jan 2000 11:33:52 -0500 Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <14471.13834.480356.541389@anthem.cnri.reston.va.us>; from bwarsaw@cnri.reston.va.us on Thu, Jan 20, 2000 at 11:21:30AM -0500 References: <200001201601.LAA21359@eric.cnri.reston.va.us> <14471.13834.480356.541389@anthem.cnri.reston.va.us> Message-ID: <20000120113352.A23763@trump.amber.org> Barry A. Warsaw [bwarsaw@cnri.reston.va.us] wrote: > All very cool things that could easily wait until 1.7. After all, > what's in a number? If, as Andrew puts forth, getting a stable Python > release with Unicode is very important for Python's future > positioning, then I say let's go with his more modest list, mainly > Unicode, sre, and Distutils. We've already got string meths, tons of > library improvements, and sundry other things. That's a good enough > laundry list for the next release. Heck, Python is infinately more conservative in its numbering than a lot of projects. All that was mentioned would normally be enough to call it 2.0 easily. :-) Modesty can be counter productive in PR business...also there is the issue of having two copies of 1.5.x installed at the same time, which with Unicode could be a manjor consideraton for some of us. For me, numbering has always been (and I try and keep it this way with Zope): X.Y.Z X = structural changes, backward incompaibility Y = new features Z = bug fixes only Chris -- | Christopher Petrilli | petrilli@amber.org From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Jan 20 16:30:32 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 20 Jan 2000 11:30:32 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing References: <200001201601.LAA21359@eric.cnri.reston.va.us> <14471.13834.480356.541389@anthem.cnri.reston.va.us> <20000120113352.A23763@trump.amber.org> Message-ID: <14471.14376.9881.702264@anthem.cnri.reston.va.us> >>>>> "CP" == Christopher Petrilli writes: CP> For me, numbering has always been (and I try and keep it this CP> way with Zope): CP> X.Y.Z | X = structural changes, backward incompaibility | Y = new features | Z = bug fixes only I agree. -Barry From petrilli@amber.org Thu Jan 20 16:41:24 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Thu, 20 Jan 2000 11:41:24 -0500 Subject: [Python-Dev] SOAP In-Reply-To: <006901bf631d$449eea50$f29b12c2@secret.pythonware.com>; from fredrik@pythonware.com on Thu, Jan 20, 2000 at 09:06:32AM +0100 References: <000101bf62ce$5e509e70$c355cfc0@ski.org> <006901bf631d$449eea50$f29b12c2@secret.pythonware.com> Message-ID: <20000120114124.B23763@trump.amber.org> Fredrik Lundh [fredrik@pythonware.com] wrote: > David Ascher wrote: > > Who if anyone is working on SOAP clients and servers for Python? > > we are (or rather, we will). hope to have code > available during (late) Q1. > > For what it's worth, this is also Zope's strategy. We are commited to having full SOAP integration in the system soon (when soon is, is another queston for the marketing department). :-) I am pretty sure that it will be a bi-directional integration. Chris -- | Christopher Petrilli | petrilli@amber.org From akuchlin@mems-exchange.org Thu Jan 20 16:38:53 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu, 20 Jan 2000 11:38:53 -0500 (EST) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <14471.13834.480356.541389@anthem.cnri.reston.va.us> References: <200001201601.LAA21359@eric.cnri.reston.va.us> <14471.13834.480356.541389@anthem.cnri.reston.va.us> Message-ID: <14471.14877.434886.471929@amarok.cnri.reston.va.us> Barry A. Warsaw writes: > Guido> There are several other things I can think of now that were > Guido> planned for 1.6: revamped import, rich comparisons, revised > Guido> coercions, parallel for loop (for i in L; j in M: ...), > Guido> extended slicing for all sequences. I'm not clear on the status of these various things; how many of these changes are deep ones that need lots of design, or affect massive amounts of the code base? For example, revamped import is a tricky design problem (as we've seen on this list). Is the spec for rich comparisons clearly defined at this point? Something like the parallel for loop seems like a parser modification combined with a code-generator modification, with no subtle implications for the rest of the implementation, and so that seems a simple matter of programming -- a week or so of effort. (Maybe I've missed something?) > Guido> I've also been > Guido> thinking about making classes be types (not as huge a > Guido> change as you think, if you don't allow subclassing > Guido> built-in types), and adding a built-in array type suitable > Guido> for use by NumPy. I've also received a conservative GC > Guido> patch that seems to be fairly easy to apply and has some of > Guido> Tim Peters' blessing. Similarly, does the conservative GC patch splatter changes all over the place, or is it very localized? Is adding the NumPy array type straightforward? Remember, there would presumably be a couple of 1.6 alphas and betas to shake out bugs. >From a political standpoint, I'd call the next release 1.6 and not >bother with another installment in 1.5.x series. And I agree with Fair enough; forget about the 1.5.5 suggestion, and call it as 1.6. >tree. My free-time plate is pretty full with JPython and Mailman, but >I'm willing to help where possible. Ditto. -- A.M. Kuchling http://starship.python.net/crew/amk/ One trouble with being efficient is that it makes everybody hate you so. -- Bob Edwards, the Calgary Eyeopener, March 18, 1916 From jim@digicool.com Thu Jan 20 16:48:18 2000 From: jim@digicool.com (Jim Fulton) Date: Thu, 20 Jan 2000 11:48:18 -0500 Subject: Python 2 namespace change? (was Re: [Python-Dev] Changing existing class instances) References: <200001200419.XAA01969@mira.erols.com> <38871665.C3B6FFEE@digicool.com> <38871CE5.53FB9D68@digicool.com> <200001201545.KAA21304@eric.cnri.reston.va.us> Message-ID: <38873C52.29FEAC6D@digicool.com> Guido van Rossum wrote: > > > I've suggested this to Guido in the past. His > > reasonable response is that this would be too big a > > change for Python 1. Maybe this is something to consider > > for Python 2? > > Note: from now on the new name for Python 2 is Python 3000. :-) I like it. > > The basic idea (borrowed from Smalltalk) is to have a kind > > of dictionary that is a collection of "association" > > objects. An association object is simply a pairing of a > > name with a value. Association objects can be shared among > > multiple namespaces. > > I've never liked this very much, mostly because it breaks simplicity: > the idea that a namespace is a mapping from names to values > (e.g. {"limit": 100, "doit": , ...}) is beautifully > simple, while the idea of inserting an extra level of indirection, no > matter how powerful, is much murkier. How so? It doesn't change the mapping semantics. > There's also the huge change in semantics, as you point out; > currently, > > from foo import bar > > has the same effect (on bar anyway) as > > import foo > bar = foo.bar # i.e. copying an object reference > del foo > > while under your proposal it would be more akin to changing all > references to bar to become references to foo.bar. > > Of course that's what the moral equivalent of "from ... import ..." > does in most other languages anyway, so we might consider this for > Python 3000; Cool. Again, it would also make function global variable access faster and cleaner in some ways. > however it would break a considerable amount of old code, > I think. Really? I wonder. I bet it would break alot less old code that other recent changes. > (Not to mention brain It makes my brain feel much better. :) > and book breakage. :-) Hey, all of the books will have to be rewritten for Python 3000. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From gstein@lyra.org Thu Jan 20 17:22:40 2000 From: gstein@lyra.org (Greg Stein) Date: Thu, 20 Jan 2000 09:22:40 -0800 (PST) Subject: [Python-Dev] Python 1.6 timing In-Reply-To: <200001201601.LAA21359@eric.cnri.reston.va.us> Message-ID: On Thu, 20 Jan 2000, Guido van Rossum wrote: >... > Date: Wed, 19 Jan 2000 20:17:55 -0500 > From: "A.M. Kuchling" > To: guido@python.org > Subject: Python 1.6 timing > > I thought a bit more about the release schedule for 1.6, and like the > idea of delaying it less and less. Another bad effect of delaying it > is that not having Unicode in the core handicaps developing XML tools; > we can continue working with wstrop, or integrate MAL's code into the > XML-SIG's CVS tree, but it might mean abandoning the XML processing > field to Perl & Tcl because the tools can't be made fully standard > compliant in time. I agree with Andrew's basic premise. > Options I can think of: > > 1) Delegating some control to a pumpkin holder [...]. Seems fine. > 2) Releasing the Unicode+sre modules as separate add-ons to > 1.5. (But would that impose annoying > backward-compatibility constraints when they get integrated > into 1.6?) Icky. :-) > 3) Add Unicode, sre, Distutils, plus other minor things and > call it 1.5.5, meaning it's not as big a revision as a 1.6 > release, but it's bigger than just another patchlevel of > bugfixes. I don't remember what other features were > planned for 1.6; was there anything major, if static typing > is left for 2.0? Call it 1.6, per the rest of the thread. >... > For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more > conservative agenda, as suggested by Andrew: Unicode and distutils are > probably the most important things to integrate. Unicode: definitely. distutils seems pretty early, but I bet that some key concepts could be added to 1.6, to make the transition and continued development easier. Note that if an announcement were made to the effect of "feature freeze on February 15; only bug fixes afterwards," that you would get a lot of people scrambling to submit their pet features. This would be a good way to light some fires, to see what kinds of things get completed (i.e. we may think some things aren't ready or are too far out, put that deadline in and those positions could change...) > (The import > utilities are not ready for prime time in my opinion; there are too > many issues.) I'm waiting for that review :-) If you raise issues, then I can knock them down. I don't see all that many at the moment. But I'm biased :-) > Anybody care to be the pumpkin? That would cut the discussion short; > otherwise the problem remains that I can't spend too much time on the > next release unless I get funded for it; what little money I've > received for CP4E I had better spend on getting some CP4E-related > results ASAP, because the next installment of this funding is very > much at stake... I would volunteer for the pumpkin... around April-ish. My plate is rather full with completing mod_dav and then integrating that into Apache 2.0. Once the Apache integration begins, then I'd have some more free time. But this begs the question of: what does the pumpkin-holder mean in the *Python* world? If it is collating fixes, producing snapshots, etc, then I'm comfy with it. If it also contains responsibility for specific kinds of work, then Fred would probably veto me :-), as I've got an outstanding doc that I owe him (for about six months now... sigh; maybe I'll bribe MAL to write it; he knows the interface :-)). But stll: what's it mean? How does the pumpkin reduce the Guido-load, yet still enable the Guido-control? [ I just had a talk about this with the guys at Inprise, re: InterBase, mentioning that the Dictator model works well for Python, but doesn't necessarily work well for new projects or commercially-started projects due to control/prejudice issues. Python people like it because of the resulting simplicity and cleanliness; I doubt we want a pumpkin approach that would allow that to go away! ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From guido@CNRI.Reston.VA.US Thu Jan 20 17:20:33 2000 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 20 Jan 2000 12:20:33 -0500 Subject: Python 2 namespace change? (was Re: [Python-Dev] Changing existing class instances) In-Reply-To: Your message of "Thu, 20 Jan 2000 11:48:18 EST." <38873C52.29FEAC6D@digicool.com> References: <200001200419.XAA01969@mira.erols.com> <38871665.C3B6FFEE@digicool.com> <38871CE5.53FB9D68@digicool.com> <200001201545.KAA21304@eric.cnri.reston.va.us> <38873C52.29FEAC6D@digicool.com> Message-ID: <200001201720.MAA21534@eric.cnri.reston.va.us> [me] > > I've never liked this very much, mostly because it breaks simplicity: > > the idea that a namespace is a mapping from names to values > > (e.g. {"limit": 100, "doit": , ...}) is beautifully > > simple, while the idea of inserting an extra level of indirection, no > > matter how powerful, is much murkier. [Jim F] > How so? It doesn't change the mapping semantics. My assumption is that in your version, the dictionary would contain special
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4