Re: [Python-Dev] ETree: xml vs xmlcore
Aahz wrote: > Did we make a final decision about whether the canonical location for > ElementTree should be xml or xmlcore? the original idea was to use "xml" to get the latest and greatest from either the core or PyXML, "xmlcore" to use the bundled version. I see no reason to change this just because people have short memory ;-) (in other words, the modules should be documented as xml.xxx, with a note that says that they're also available as xmlcore.xxx. this applies to all modules under xml, not just etree.). > Also, there's no ElementTree or > xmlcore that I can find at http://docs.python.org/dev/ under global > module index or library reference. the docs are still sitting in the patch tracker. looks like the "just post text files; we'll fix the markup" approach doesn't work. oh well, there's plenty of time to fix that before 2.5 final. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > Perhaps I misunderstood Josiah's comment; I thought he was implying > that a switch should be significantly *faster* than if/elif, and was > arguing against features that would jeopardize that speedup. I would > think that it would be fine if some switches could be compiled into > some kind of lookup table while others would just be translated into a > series of if/elifs. As long as the compiler can tell the difference. I personally don't find switch/case statements to be significantly (if at all) easier to read than if/elif/else chains, but that is subjective, and I note that Ka-Ping finds switch/case to be significantly easier to read. Regardless of readability (I know that readability counts), TOOWTDI. If we allow somewhat arbitrary cases, then any potential speedup may be thrown away (which would bother those of us who use dispatching), and we essentially get a different syntax for if/elif/else. I don't know about everyone else, but I'm not looking for a different syntax for if/elif/else, I'm looking for fast dispatch with some reasonable syntax. In my opinion, the most reasonable syntax is a semantic change for fast dispatch inside of specifically crafted if/elif chains of the form: if/elif non_dotted_name == constant_expression: As stated various ways by various people, you can generate a hash table during function definition (or otherwise), verify that the value of non_dotted_name is hashable, and jump to particular offsets. If you are careful with your offsets, you can even have parallel if/elif/else tests that fall through in the case of a 'non-hashable'. There is a drawback to the non-syntax if/elif/else optimization, specifically that someone could find that their dispatch mysteriously got slower when they went from x==1 to including some other comparison operator in the chain somewhere. Well, that and the somewhat restricted set of optimizations, but we seem to be headed into that restricted set of optimizations anyways. One benefit to the non-syntax optimization is that it seems like it could be implemented as a bytecode hack, allowing us to punt on the entire discussion, and really decide on whether such a decorator should be in the standard library (assuming someone is willing to write the decorator). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
On 6/19/06, Trent Mick <[EMAIL PROTECTED]> wrote: > Trent Mick wrote: > > Trent Mick wrote: > >> * [ 1462338 ] upgrade pyexpat to expat 2.0.0 > >>http://python.org/sf/1462338 > >> > >> * [ 1295808 ] expat symbols should be namespaced in pyexpat > >>http://python.org/sf/1295808 > > > > These are in now. I don't see any failures yet, either on the buildbots > > or on the Windows/Linux/Mac OS X boxes I tested on. > > It looks like this broke the x86 cygwin build: > > http://python.org/dev/buildbot/trunk/x86%20cygwin%20trunk/builds/859/step-test/0 Unfortunately, it's always red, athough this failure is new. > I don't have this environment setup right now, though I'll try to check > in the morning if someone hasn't beaten me to it. (Showing my ignorance > here and grasping at straws: this wouldn't be because of some extern > C-name-mangling-with-underscore-prefix thing would it?) I didn't see where pyexpat.c got rebuilt in the compile/test steps. Which would explain why it can't find new names. Not sure if that's the problem or not. make distclean is supposed to clean that up, hmm I wonder if distclean was run before this build. I'm gonna try to force another build on cygwin. Anthony might need to do a manual make distclean. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
Trent Mick wrote: > Trent Mick wrote: >> * [ 1462338 ] upgrade pyexpat to expat 2.0.0 >>http://python.org/sf/1462338 >> >> * [ 1295808 ] expat symbols should be namespaced in pyexpat >>http://python.org/sf/1295808 > > These are in now. I don't see any failures yet, either on the buildbots > or on the Windows/Linux/Mac OS X boxes I tested on. It looks like this broke the x86 cygwin build: http://python.org/dev/buildbot/trunk/x86%20cygwin%20trunk/builds/859/step-test/0 > gcc -shared -Wl,--enable-auto-image-base > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.o > > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmlparse.o > > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmlrole.o > > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmltok.o > -L/usr/local/lib -L. -lpython2.5 -o > build/lib.cygwin-1.5.19-i686-2.5/pyexpat.dll > build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.o: > In function `set_error': > /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:126: > undefined reference to `_XML_GetCurrentLineNumber' > /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:127: > undefined reference to `_XML_GetCurrentColumnNumber' > /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:131: > undefined reference to `_XML_ErrorString' > ... I don't have this environment setup right now, though I'll try to check in the morning if someone hasn't beaten me to it. (Showing my ignorance here and grasping at straws: this wouldn't be because of some extern C-name-mangling-with-underscore-prefix thing would it?) Modules/pyexpat.c:5 #include "expat.h" Modules/expat/expat.h:18 #include "expat_external.h" Modules/expat/expat_external.h:12 #include "pyexpatns.h" Modules/expat/pyexpatns.h:52 #define XML_GetCurrentLineNumberPyExpat_XML_GetCurrentLineNumber I don't see where the disconnect is. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ETree: xml vs xmlcore
Did we make a final decision about whether the canonical location for ElementTree should be xml or xmlcore? Also, there's no ElementTree or xmlcore that I can find at http://docs.python.org/dev/ under global module index or library reference. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
Trent Mick wrote: > * [ 1462338 ] upgrade pyexpat to expat 2.0.0 >http://python.org/sf/1462338 > > * [ 1295808 ] expat symbols should be namespaced in pyexpat >http://python.org/sf/1295808 These are in now. I don't see any failures yet, either on the buildbots or on the Windows/Linux/Mac OS X boxes I tested on. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XP build failing
FYI, the tests all pass on my box again. Going offline line to check the disk. > ... > I probably left the 2.4 buildbot tree in a broken state, > BTW -- if I don't remember to fix that, somebody poke me :-) I should clarify that that's _my_ 2.4 buildbot tree, only on my machine. I didn't break your 2.4 buildbot tree, let alone "the" 2.4 buidbot tree. I don't even know what that means :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XP build failing
[Brett] >> Looks like Tim's XP box is crapping out on a header file included from >> Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an >> external svn pull and thus got bit by it? [Martin] > No, that comes straight out of > > http://svn.python.org/projects/external/tcl8.4.12/generic/tclDecls.h > > atleast in theory: there is a build process for tcl running if it wasn't > built before. Could just as well also be a hard disk corruption. It's a Mystery, and I couldn't find anything wrong in tclDecls.h by eyeball either. Blowing away some directories to force a rebuild of the tcltk directory appears to have cured it. There's no other evidence of disk problems here, but after the current test run finishes I'm taking the box down to run some pre-boot disk diagnostics. I probably left the 2.4 buildbot tree in a broken state, BTW -- if I don't remember to fix that, somebody poke me :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyString_FromFormat
Kristján V. Jónsson wrote:
> One thing I have often lamented having in PyString_FromFormat (and
> cousins, like PyErr_Format) is to be able to integrate PyObject
> pointers. Adding something like %S and %R (for str() and repr()
> respectively) seems very useful to me. Is there any reason why this
> isn´t there?
Not sure what the specific use case is, but I think I would use
PyString_Format instead, and use everything you can use in a %
operator. If you want to avoid explicit argument tuple building,
you can also write
static PyObject *fmt = NULL;
if (!fmt) fmt = PyString_FromString("Foo %s bar %s foobar %d");
res = PyMethod_Call(fmt, "__mod__", "(OOi)", o1, o2, 42);
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XP build failing
Brett Cannon wrote: > http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/676/step-compile/0 > > Looks like Tim's XP box is crapping out on a header file included from > Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an > external svn pull and thus got bit by it? No, that comes straight out of http://svn.python.org/projects/external/tcl8.4.12/generic/tclDecls.h atleast in theory: there is a build process for tcl running if it wasn't built before. Could just as well also be a hard disk corruption. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
On Mon, 19 Jun 2006, Guido van Rossum wrote: > If you want to encourage people to use your module > with older versions, the right path is to have a distribution (can be > very light-weight) on your own website and add it to PyPI Okay, i've removed the comment and submitted the package to PyPI. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.getmtime now returns a float?
Gregory P. Smith wrote:
> os.path.getmtime returns a float on linux (2.5a2/b1 HEAD); in 2.4 it
> returned an int. this change makes sense, its what time.time returns.
>
> should there be a note in Misc/NEWS or whatsnew mentioning this minor
> change (or did i miss it)? It breaks code that unintentionally
> depended on it returning an int.
There is an entry in Misc/NEWS:
- stat_float_times is now True.
The change was originally announced in
http://www.python.org/doc/2.3/whatsnew/node18.html
which says
During testing, it was found that some applications will break if time
stamps are floats. For compatibility, when using the tuple interface of
the stat_result time stamps will be represented as integers. When using
named fields (a feature first introduced in Python 2.2), time stamps are
still represented as integers, unless os.stat_float_times() is invoked
to enable float return values:
>>> os.stat("/tmp").st_mtime
1034791200
>>> os.stat_float_times(True)
>>> os.stat("/tmp").st_mtime
1034791200.6335014
In Python 2.4, the default will change to always returning floats.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Thomas Heller wrote: > It should be noted that I once started to convert the import machinery > to be fully unicode aware. As far as I can tell, a *lot* has to be changed > to make this work. Is that code available somewhere still? Does it still work? > I started with refactoring Python/import.c, but nobody responded to the > question > whether such a refactoring patch would be accepted or not. I would like to see minimal changes only. I don't see why massive refactoring would be necessary: the structure of the code should persist - only the data types should change from char* to PyObject*. Calls like stat() and open() should be generalized to accept PyObject*, and otherwise keep their interface. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation enhancement: "MS free compiler"?
On 6/19/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Cameron Laird wrote: > > I'm channeling a correspondent, who tells me that Python documentation > > (Python 2.5 announcement, and so on) mentions compatibility of sources > > with "the MS free compiler"; that's the default toolchain for Windows. > > > > Apparently we're in conflict with Microsoft on that: some hyperlinks > > refer to http://msdn.microsoft.com/visualc/vctoolkit2003/ >, which > > begins, > > The Visual C++ Toolkit 2003 has been > > replaced by Visual C++ 2005 Express > > Edition. > > The latter is available at no charge, incidentally. > > It would be good to know where the hyperlink supposedly is, so we know > who can update it. There's one in PCBuild/README - I don't know if that's the one referred to. However, there is no valid replacement link, so I'm not sure what it should be replaced with (other than a suggestion that the only way of getting the toolkit compiler is by "unofficial" means). > In any case, changing the reference to VS 2005 is the wrong thing to > do - VS 2005 is *not* the default tool chain on Windows. So the update > should be that there is no free compiler from MS anymore (or perhaps > it should point to the .NET SDK, provided that has a free compiler). As far as I know, there is *no* replacement for the Toolkit compiler (where replacement implies builds to link with msvcr71.dll, and is an optimising compiler). MS withdrew the toolkit compiler right after my patch to document how to use it was committed :-( I was sufficiently annoyed and demotivated by this, that I never did anything to fix the documentation, particularly as I don't have a good suggestion. I'll see if I have time to look at the README and suggest suitable words. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] XP build failing
http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/676/step-compile/0Looks like Tim's XP box is crapping out on a header file included from Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an external svn pull and thus got bit by it? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation enhancement: "MS free compiler"?
Cameron Laird wrote: > I'm channeling a correspondent, who tells me that Python documentation > (Python 2.5 announcement, and so on) mentions compatibility of sources > with "the MS free compiler"; that's the default toolchain for Windows. > > Apparently we're in conflict with Microsoft on that: some hyperlinks > refer to http://msdn.microsoft.com/visualc/vctoolkit2003/ >, which > begins, > The Visual C++ Toolkit 2003 has been > replaced by Visual C++ 2005 Express > Edition. > The latter is available at no charge, incidentally. It would be good to know where the hyperlink supposedly is, so we know who can update it. In any case, changing the reference to VS 2005 is the wrong thing to do - VS 2005 is *not* the default tool chain on Windows. So the update should be that there is no free compiler from MS anymore (or perhaps it should point to the .NET SDK, provided that has a free compiler). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Delaney, Timothy (Tim) wrote: > Guido van Rossum wrote: > > >>I wonder if there should be two default clauses, or some other >>syntactic way to indicate whether we expect all x to be hashable? > > > switch expr: > case 1: > statements > case 2: > statements > else: > statements > except KeyError: > statements > finally: > statements Small variation: switch expr: case 1: statements case 2: statements else: statements except: statements -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Heller wrote: > Martin v. Löwis wrote: >> Guido van Rossum wrote: 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want to get rid of it, *now* would be the time. >>> I'm all for it. >>> >>> While I am an enthusiastic supporter of several of those additions, I >>> am *not* in favor of the special status granted to software >>> contributed by certain developers, since it is a burden for all other >>> developers. >> Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the >> status of each of these has been clarified. >> >> Each maintainer should indicate whether he is happy with a "this is >> part of Python" approach. If so, the entry should be removed from PEP >> 360 (*); if not, the code should be removed from Python before beta 1. > > I will be happy to say "ctypes is part of Python" (although I *fear* it > is not one of the packages enthusiastically supported by Guido ;-). The same goes for the sqlite3 module. I see it as part of Python and also see it as my job synchronize bugfixes with the external version both ways. I'll also add statements to the source files to ask developers to keep Python 2.3 compatibility. > [...] > I am *very* thankful for the fixes, the code review, the suggestions, > and the encouragement I got by various python-devers. [...] Ditto :-) So, somebody can please adjust the PEPs for the sqlite3 module accordingly. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElxytdIO4ozGCH14RAs8PAJ9/+zGGFj3nLyKPNN+B+UmG3gaJeQCfV7Uc g0PjyvOfXVkA2cohQjJrzeI= =nM4W -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote: > I wonder if there should be two default clauses, or some other > syntactic way to indicate whether we expect all x to be hashable? switch expr: case 1: statements case 2: statements else: statements except KeyError: statements finally: statements switch expr: case 1: statements case 2: statements else: statements except KeyError: statements finally: statements :) Seriously, I think I'd rather be explicit and just have KeyError propagate. If someone is expecting occasional unhashable values, they can just wrap it in try/except. try: switch expr: case 1: statements case 2: statements else: statements except KeyError: statements finally: statements The first syntax though does have the advantage that it could catch only KeyErrors raised from the switch statement. That could be easily handled by a separate SwitchKeyError exception (inheriting from KeyError). Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] beta1 coming real soon
[Neal Norwitz wrote on June 8th] > It's June 9 in most parts of the world. The schedule calls for beta 1 > on June 14. That means there's less than 4 days until the expected > code freeze. Please don't rush to get everything in at the last > minute. The buildbots should remain green to keep Anthony happy and > me sane (or is it the other way around). > > If you plan to make a checkin adding a feature (even a simple one), > you oughta let people know by responding to this message. Please get > the bug fixes in ASAP. Remember to add tests! [and then Anthony Baxter wrote today] > Subject: TRUNK FREEZE IMMINENT FOR 2.5 BETA 1 - 00:00 UTC,20-JUNE-2006 > > The trunk will be FROZEN for 2.5b1 from 00:00UTC on Tuesday, 20th of > June. That's about 16 hours from now. Please don't checkin while the > trunk is frozen, unless you're one of the release team (me, Martin, > Fred, Ronald). Can I, or will I be able to get these PyExpat fixes? * [ 1462338 ] upgrade pyexpat to expat 2.0.0 http://python.org/sf/1462338 * [ 1295808 ] expat symbols should be namespaced in pyexpat http://python.org/sf/1295808 The second one is that one I care about (and is well tested in Komodo on four platforms). It will be very important to have that one in the Python/Mozilla world (which with Mark Hammond's recent work for mozilla.org -- making Python a first class language in the browser along with JavaScript) because this namespacing is required to avoid crashing conflicts with another version of the expat symbols in the mozilla process. Martin v. L. wanted the namespacing fix to be preceded by the upgrade to expat 2.0.0 -- which I have a patch for also. I haven't checked in yet, because I dropped the ball for a few weeks here. I'm going to start working on checking it in right now and will probably just go for it (because I have a few hours until Anthony's deadline ;)) unless I hear some screams. Honestly I didn't intentionally wait until the pending trunk-freeze email came. Cheers, Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] os.getmtime now returns a float?
os.path.getmtime returns a float on linux (2.5a2/b1 HEAD); in 2.4 it returned an int. this change makes sense, its what time.time returns. should there be a note in Misc/NEWS or whatsnew mentioning this minor change (or did i miss it)? It breaks code that unintentionally depended on it returning an int. -g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
Guido van Rossum wrote: > # At the time of writing this module was compatible with Python 2.3 and > later. :-) Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
Ka-Ping Yee wrote: > This sentiment is puzzling to me. It seems you assume that we can trust > future developers to change the code but we can't trust them to update > the documentation. That's precisely my expectation. Suppose Python 3.0 unifies int and long, and deprecates the L suffix. Then, if not 0 <= time_low < 1<<32L: will change to if not 0 <= time_low < 1<<32: While this will work fine in Python 2.4 and onwards, it will break 2.3. Whoever is making the change won't even think of the necessity of a documentation change - after all, this is supposed to be a style change, only. People do make whole-sale style changes to the entire library from time to time. > So we can't have documentation even if it's factually > true just because someone might forget to update it? Sure, we can, and if you want that to, we should (you are the author, so your view is quite important), and I'll shut up. I just wanted to caution about a risk here. > If you see a better way to word the comment to reduce the possibility > of misunderstanding, that's cool with me. I'd just like people who > get their hands on the module to know that they can use it with 2.3. I personally didn't find it misleading at all, and see no need to change it for *that* reason. I see a potential risk in it wrt. future changes, but perhaps I'm paranoid. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Kristján V. Jónsson wrote: > Wouldn´t it be possible then to emulate the unix way? Simply encode > any unicode paths to utf-8, process them as normal, and then decode > them just prior to the actual windows io call? That won't work. People also put path names from the ANSI code page onto sys.path and expect that to work - it always worked, and is a nearly-complete work-around to put directories with funny characters onto sys.path. sys.path is a list, so we have little control over what gets put onto it. > Of course, once there, why not do it unicode all the way up to that > last point? Unless there are platforms without wchar_t that would > make sense. Again, we can't really control that. Also, most platforms have no wchar_t API for file IO. We would have to encode each sys.path element for each stat() call, which would be quite expensive > At any rate, I am trying to find a coding path of least resistance > here. Regardless of the timeline or acceptance in mainstream python > for this feature, it is something I will have to patch in for our > application. The path with least resistance should be usage of 8.3 directory names. The one to implement in future Python versions should be the rewrite of import.c, to operate on PyObject* instead of char*, and perform conversion to the native API only just before calling the native API. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Kristján V. Jónsson wrote: > I don't have specific information on the machines. We didn´t try > very hard to get things to work with 2.3 since we simply assumed it > would work automatically when we upgraded to a more mature 2.4. I > could try to get more info, but it would be 2.3 specific. Have there > been any changes since then? Not in that respect, no. > Note that it may not go into program files at all. Someone may want > to install his modules in a folder named in the honour of his mother. It's certainly possible to set this up in a way that it won't work, on any localized version: just use a path name that isn't supported in the ANSI code page. However, that should rarely happen: the name of his mother should still be expressable in the ANSI code page, if the system is setup correctly. > Also, I really would like to see a general solution that doesn´t > assume that the path name can somhow be transmuted to an ascii name. (Please don't say ASCII here. Windows *A APIs are named that way because Microsoft Windows has the notion of an "ANSI code page", which, in turn, is just a code page indirection so some selected code page meant to support the characters of the user's locale) > Users are unpredictable. When you have a wide distribution , you > come up against all kinds of problems (Currently we have around > 500.000 users in china.) Also, relying on some locale settings is not > acceptable. Sure, but stating that doesn't really help. Code contributions would help, but that part of Python has been left out of using the *W API, because it is particularly messy to fix. > Funny that no other platforms could benefit from a unicode import > path. Does that mean that windows will reign supreme? That is the case, more or less. Or, more precisely: - On Linux, Solaris, and most other Unices, file names are bytes on the system API, and are expected to be encoded in the user's locale. So if your locale does not support a character, you can't name a file that way, on Unix. There is a trend towards using UTF-8 locales, so that the locale contains all Unicode characters. - On Mac OS X, all file names are UTF-8, always (unless the user managed to mess it up), so you can have arbitrary Unicode file names That means that the approach of converting a Unicode sys.path element to the file system encoding will always do the right thing on Linux and OS X: the file system encoding will be the locale's encoding on Linux, and will be UTF-8 on OS X. It's only Windows which has valid file names that cannot be represented in the current locale. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [Guido] > > I'm not so sure about there being no hidden surprises. I betcha that > > there are quire a few bits of code that curerntly use the if/elif > > style and seem to beg for a switch statement that depend on the > > ordering of the tests. A typical example would be to have one of the > > earlier tests express an exception to a later test that is a range > > test. > > That's a tricky issue. Whenever the cases overlap, I would expect a > successive comparison approach to jump to the first match while a hash > table approach would jump to the last match (just like a dictionary > retains only the latest (key,value) pair when fed successive pairs with > identical keys and differing values). But it would be easy enough to define a dict-filling function that updates only new values. (PyDict_Merge has an option to do this, although it's not currently exposed to Python.) > > (Surely we're going to support range tests... sre_compile.py > > uses 'in' almost as often as 'is'.) > > When the ranges have a short length as they do in sre, I expect that the > syntax would allow the range to be captured on one line but have > multiple entries in the hash table which each dispatch to the same > target code suite: > > switch x: > case 0, 2, 4, 6: handle_even() > case 1, 3, 5, 9: handle_odd() > default: handle_fractions() Was it decided yet how to write the cases for a switch that tests for tuples of values? Requiring parentheses might be sufficient, essentially making what follows a case *always* take on sequence syntax. > Unfortunately, that approach is less than ideal for bigger ranges: > >switch x: >case xrange(0,sys.maxint,2): handle_odd() >case xrange(1,sys.maxint,2): handle_even() >default: handle_fractions() Right. This would be fine syntactically but clearly breaks the dict implementation... > Other types of range checks get us back into the area of arbitrary > expressions in case values and having to repeat the variable name: > >switch x: >case x < 60: return "too cold" >case 60 <= x < 80: return "just right" >case 80 <= x: return "too hot" > > Choose your poison. How much range flexibility do you want and how much > implementation and behavioral complexity are you willing to pay for it. In order to decide, we should look at current usage of long if/elif chains. > >> If use cases eventually emerge for an alternative path using successive > >> == comparisons, then it can always be considered and added later. For > >> now, YAGNI (neither the functionality, nor the implementation headaches, > >> nor the complexity of explaining what it does under all the various > >> cases). > > > > I say, let someone give a complete implementation a try, and then try > > to modify as much standard library code as possible to use it. Then > > report back. That would be a very interesting experiment to do. (And > > thanks for the pointer to sre_compile.py as a use case!) > > Hmm, it could be time for the Georg bot to graduate to big game. > Georg, are you up to it? Georg is a bot? :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
>> My thought is that we *should* define switching in terms of hash >> tables. It builds off of existing knowledge and therefore has a near >> zero learning curve. The implementation is straight-forward and there >> are none of the hidden surprises that we would have with >> fastpath/slowpath approaches which use different underlying magic >> methods and do not guarantee order of execution. > > > I'm not so sure about there being no hidden surprises. I betcha that > there are quire a few bits of code that curerntly use the if/elif > style and seem to beg for a switch statement that depend on the > ordering of the tests. A typical example would be to have one of the > earlier tests express an exception to a later test that is a range > test. That's a tricky issue. Whenever the cases overlap, I would expect a successive comparison approach to jump to the first match while a hash table approach would jump to the last match (just like a dictionary retains only the latest (key,value) pair when fed successive pairs with identical keys and differing values). > (Surely we're going to support range tests... sre_compile.py > uses 'in' almost as often as 'is'.) When the ranges have a short length as they do in sre, I expect that the syntax would allow the range to be captured on one line but have multiple entries in the hash table which each dispatch to the same target code suite: switch x: case 0, 2, 4, 6: handle_even() case 1, 3, 5, 9: handle_odd() default: handle_fractions() Unfortunately, that approach is less than ideal for bigger ranges: switch x: case xrange(0,sys.maxint,2): handle_odd() case xrange(1,sys.maxint,2): handle_even() default: handle_fractions() Other types of range checks get us back into the area of arbitrary expressions in case values and having to repeat the variable name: switch x: case x < 60: return "too cold" case 60 <= x < 80: return "just right" case 80 <= x: return "too hot" Choose your poison. How much range flexibility do you want and how much implementation and behavioral complexity are you willing to pay for it. >> If use cases eventually emerge for an alternative path using successive >> == comparisons, then it can always be considered and added later. For >> now, YAGNI (neither the functionality, nor the implementation headaches, >> nor the complexity of explaining what it does under all the various >> cases). > > > I say, let someone give a complete implementation a try, and then try > to modify as much standard library code as possible to use it. Then > report back. That would be a very interesting experiment to do. (And > thanks for the pointer to sre_compile.py as a use case!) Hmm, it could be time for the Georg bot to graduate to big game. Georg, are you up to it? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Kristján V. Jónsson wrote: > The signal() doc is rather vague on the point, since it doesn´t > define the availible set of signals. It doesn´t even say that a > signal identifier is an integer. But it says that it should return > EINVAL if it "cannot satisfy the request". What "signal() doc" are you looking at? I'm looking at http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf section 7.14. This is ISO C99 (actually, technical corrigendum 2 of that), and it does not mention EINVAL. (BTW, signal does not *return* EINVAL, it returns SIG_ERR and sets errno). signal() isn't vague about the set of available signals. 7.14/3 lists some, then 7.14/4 says # The complete set of signals, their semantics, and their default # handling is implementation-defined; all signal numbers shall be # positive. > It doesn´t say "if the request is invalid" Ah, so you are looking at the Microsoft documentation? As the implementation isn't compliant to standard C, I would not expect their documentation to faithfully reproduce standard C. > but I don't want to go into hairsplitting here. It's an important point. If Python does not follow some relevant standard, and therefore breaks, it is Python that must be fixed. If it breaks on some system which in itself violates some standard, we have the choice of either working around or ignoring the system. > But I completely disagree when you insist that microsoft has broken > the C library. But they have. A program that is compliant to standard C used to work with earlier versions of the C library, and stops working with the current version. > What they have done is added parameter validation, > and thus simply added code in the "undefined" domain. Except that the set of supported signals is not "undefined", it's "implementation-defined". See 3.4.1 for a definition of "implementation-defined behaviour", and 3.4.3 for a definition of "undefined behaviour". > I would also > like to point out that, again apart from signal(), you are relying on > undefined behaviour of fopen and others. That is true, so we should fix Python here. > So, it is my suggestion that in stead of going all defensive, and > shouting "breakage", why not simply fix those very dubious CRT usage > patterns? Think of it as lint. Again, for fopen: sure. For signal, this is not possible: We want to set *all* signal handlers on a system, but we have know way of determining at compile time what "all signal handlers" are. Standard C is deliberately designed to allow applications to do that, and with msvcr80.dll, we can't. > Also, consider this: in the case of file() and strftime() we are > passing in dynamic strings. The strings are not within control of > python. Normally these are static strings, within the control of the > developer which has the function reference on hand, knows what he > wants and so on. Yet, here we are passing in any old strings. There > is a huge undefined domain there, and we should be very concerned > about that. It is a wonder we haven´t seen these functions crash > before. No, that's not a wonder. It's actually unfortunate that standard C did not make it an error, but they likely didn't do it because of existing practice. However, the usual, natural, straight-forward way of processing the mode string (in a loop with a switch statement) can't possible cause crashes. > (And by the way, why does pythoncore.dll mess with signal() anyway? So we can redirect all signals handlers to Python code if the user wishes so. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
On 6/19/06, Michael Hudson <[EMAIL PROTECTED]> wrote: > Nick Maclaren <[EMAIL PROTECTED]> writes: > > 2) Because some people are dearly attached to the current behaviour, > > warts and all, and there is a genuine quandary of whether the 'right' > > behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R- > > finally-specifies (let's ignore C99 and Java as beyond redemption), > > Why? Maybe it's clear to you, but it's not totally clear to me, and > it any case the discussion would be better informed for not being too > dismissive. I just happened to be reading this, which I found very convincing: How Java's Floating-Point Hurts Everyone Everywhere http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
On 6/19/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On 6/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > As for the comment: It apparently *is* misleading, George mistakenly > > took it as a requirement for future changes, rather than a factual > > statement about the present (even though it uses the tense of simple > > present). Anybody breaking 2.3 compatibility will have to remember > > to remove the comment, which he likely won't. > > This sentiment is puzzling to me. It seems you assume that we can trust > future developers to change the code but we can't trust them to update > the documentation. It's sad but true that comments often are out of date for several releases until someone notices them. > So we can't have documentation even if it's factually > true just because someone might forget to update it? Why is the mere > possibility of incorrect documentation in the future more significant > than actual correct documentation in the present? Couldn't the same > argument be used to support removing all documentation from all code? I think it has to be weighed in each case. In *this* particular case the relevance of the comment seems quite minimal and removing it seems appropriate. > If you see a better way to word the comment to reduce the possibility > of misunderstanding, that's cool with me. I'd just like people who > get their hands on the module to know that they can use it with 2.3. Well even if the comment remains, they are going to have to try it before they can trust the comment (see above). There is lots of code in the stdlib that is compatible with Python 2.3 (or 1.5.2 for that matter). How important is it to record that fact? I'd say not at all. The Python standard library of a particular Python version shouldn't be seen as an additional way to distribute code that's intended for other versions. If you want to encourage people to use your module with older versions, the right path is to have a distribution (can be very light-weight) on your own website and add it to PyPI (Cheese Shop). You can put the same version distributed with Python 2.5 there; this isn't going to be something with maintenance and featuer evolution, presumably, since it's only needed until they catch up with 2.5 or later. If you still aren't convinced, how about a comment like this: # At the time of writing this module was compatible with Python 2.3 and later. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [...] Can we conclude that arbitrary expressions are > fine for the switch value but that the case values must be constants? That's too strong I believe. If some or all of the cases are arbitrary expressions the compiler should try to deal. (Although we might have to add a rule that if more than one case matches there's no guarantee which branch is taken.) In particular I expect that named constants are an important use case (e.g. all of sre_compile.py uses names to compare the op with). The compiler can't really tell with any degree of certainty that a name won't ever be rebound (it would take a pretty smart global code analyzer to prove that). > That would neatly dispense with some proposed hypergeneralizations and > keep the discussion focused. > > > >> Given: > >> > >> switch x: > >> case 1: one() > >> case 2: two() > >> case 3: three() > >> default: too_many() > >> > >> Do we require that x be hashable so that the compiler can use a lookup > >> table? > > > > > > That's a good question. We could define switch/case in terms of a hash > > table created by the compiler, and then raising an exception if x is > > unhashable is fair game. > > > +1 > > > Or we could define it in terms of successive > > '==' comparisons, and then the compiler would have to create code for > > a slow path in case x is unhashable. > > Too perilous. I would not like to put us in a position of generating > duplicate code or funky new opcodes for the case suites. Also, it is > better for the user to know that __hash__ is going to be called, that > the default-clause will execute when the key in not found, and that a > KeyError would be raised if x is unhashable. This is simple, > explainable, consistent behavior. Besides, if we've agreed that the > case values are required to be constants, then there isn't much in the > way of use cases for x being unhashable. Well, the hypothetical use case is one where we have an arbitrary object of unknown origin or type, and we want to special-case treatment for a few known values. I wonder if there should be two default clauses, or some other syntactic way to indicate whether we expect all x to be hashable? OTOH maybe doign the simplest thing that could possibly work is the right thing here, so I'm not going to push back hard. I guess practicality beats purity and all that. Actually there are quiet a few zen of Python rules that endorse the view that requiring x to be hashable is Pythonic, so I'm being swayed as I write this. ;-) > > I don't think I'm in favor of > > always taking the default path when x is unhashable; that would cause > > some surprises if an object defines __eq__ to be equal to ints (say) > > but not __hash__. > > > That would be unpleasant. > > > > > > Note that we currently don't have a strong test for hashable; it's > > basically "if hash(x) doesn't raise an exception" which means that we > > would have to catch this exception (or perhaps only TypeError) in > > order to implement the slow path for the successive-comparisons > > semantics. > > > > I note that C doesn't require any particular implementation for > > switch/case; there's no rule that says the numbers must fit in an > > array of pointers or anything like that. So I would be careful before > > we define this in terms of hash tables. OTOH the hash table semantics > > don't require us to commit to a definition of hashable, which is an > > advantage. > > > > How's that for a wishy-washy answer. :-) > > > Perfect. Wishy-washy answers reflect an open mind and they contain the > seeds of complete agreement. Thanks. Lawyers have different reasons for being wishy-washy but among geeks there can be clarity in wshy-washiness. :-) > My thought is that we *should* define switching in terms of hash > tables. It builds off of existing knowledge and therefore has a near > zero learning curve. The implementation is straight-forward and there > are none of the hidden surprises that we would have with > fastpath/slowpath approaches which use different underlying magic > methods and do not guarantee order of execution. I'm not so sure about there being no hidden surprises. I betcha that there are quire a few bits of code that curerntly use the if/elif style and seem to beg for a switch statement that depend on the ordering of the tests. A typical example would be to have one of the earlier tests express an exception to a later test that is a range test. (Surely we're going to support range tests... sre_compile.py uses 'in' almost as often as 'is'.) > If use cases eventually emerge for an alternative path using successive > == comparisons, then it can always be considered and added later. For > now, YAGNI (neither the functionality, nor the implementation headaches, > nor the complexity of explaining what it does under all the various cases). I say, let someone give a complete implementation a try, and then try to modify as much
Re: [Python-Dev] uuid backward compatibility
On 6/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > As for the comment: It apparently *is* misleading, George mistakenly > took it as a requirement for future changes, rather than a factual > statement about the present (even though it uses the tense of simple > present). Anybody breaking 2.3 compatibility will have to remember > to remove the comment, which he likely won't. This sentiment is puzzling to me. It seems you assume that we can trust future developers to change the code but we can't trust them to update the documentation. So we can't have documentation even if it's factually true just because someone might forget to update it? Why is the mere possibility of incorrect documentation in the future more significant than actual correct documentation in the present? Couldn't the same argument be used to support removing all documentation from all code? If you see a better way to word the comment to reduce the possibility of misunderstanding, that's cool with me. I'd just like people who get their hands on the module to know that they can use it with 2.3. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
>> > But there is a definite readability improvement in that you *know*
>> > that it's always the same variable that is being compared and that no
>> > other conditions are snuck into some branches.
>>
>> Hmm, when I saw that "arbitrary expressions" were being proposed, I took
>> that took mean that the variable would have to be repeated in the
>> branches:
>>
>>switch x:
>> case x.endswith('wart'): salicylic_acid()
>> case x.endswith('roid'): preparation_h()
>> default: chicken_soup()
>
>
> That seems insane, since then it would be *just* different syntax for
> if/elif. The example looks deceptive: surely the 'switch' expression
> should allow an arbitrary expression, so the 'case' wouldn't be able
> to refer to the switch part by a name unless there was syntax (or a
> convention) for defining a name by which it could be referenced. I
> think Perl 6 is defining a very general "matching" syntax which people
> interested in this might want to study, just to see how far one can
> stretch the insanity.
I share that view 100%. Can we conclude that arbitrary expressions are
fine for the switch value but that the case values must be constants?
That would neatly dispense with some proposed hypergeneralizations and
keep the discussion focused.
>> Given:
>>
>> switch x:
>> case 1: one()
>> case 2: two()
>> case 3: three()
>> default: too_many()
>>
>> Do we require that x be hashable so that the compiler can use a lookup
>> table?
>
>
> That's a good question. We could define switch/case in terms of a hash
> table created by the compiler, and then raising an exception if x is
> unhashable is fair game.
+1
> Or we could define it in terms of successive
> '==' comparisons, and then the compiler would have to create code for
> a slow path in case x is unhashable.
Too perilous. I would not like to put us in a position of generating
duplicate code or funky new opcodes for the case suites. Also, it is
better for the user to know that __hash__ is going to be called, that
the default-clause will execute when the key in not found, and that a
KeyError would be raised if x is unhashable. This is simple,
explainable, consistent behavior. Besides, if we've agreed that the
case values are required to be constants, then there isn't much in the
way of use cases for x being unhashable.
> I don't think I'm in favor of
> always taking the default path when x is unhashable; that would cause
> some surprises if an object defines __eq__ to be equal to ints (say)
> but not __hash__.
That would be unpleasant.
>
> Note that we currently don't have a strong test for hashable; it's
> basically "if hash(x) doesn't raise an exception" which means that we
> would have to catch this exception (or perhaps only TypeError) in
> order to implement the slow path for the successive-comparisons
> semantics.
>
> I note that C doesn't require any particular implementation for
> switch/case; there's no rule that says the numbers must fit in an
> array of pointers or anything like that. So I would be careful before
> we define this in terms of hash tables. OTOH the hash table semantics
> don't require us to commit to a definition of hashable, which is an
> advantage.
>
> How's that for a wishy-washy answer. :-)
>
Perfect. Wishy-washy answers reflect an open mind and they contain the
seeds of complete agreement.
My thought is that we *should* define switching in terms of hash
tables. It builds off of existing knowledge and therefore has a near
zero learning curve. The implementation is straight-forward and there
are none of the hidden surprises that we would have with
fastpath/slowpath approaches which use different underlying magic
methods and do not guarantee order of execution.
If use cases eventually emerge for an alternative path using successive
== comparisons, then it can always be considered and added later. For
now, YAGNI (neither the functionality, nor the implementation headaches,
nor the complexity of explaining what it does under all the various cases).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On Mon, 19 Jun 2006, Guido van Rossum wrote: > Um, is this dogma? Wouldn't a switch statement also be a welcome > addition to the readability? I haven't had the time to follow this > thread (still catching up on my Google 50%) but I'm not sure I agree > with the idea that a switch should only exist for speedup. I feel quite strongly that readability should be the primary motivator for just about any new syntax. Choosing an implementation that runs at a reasonable speed is also worthwhile consideration, but readability is where it starts, IMHO. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> >> A switch-statement offers only a modest readability improvement over
> >> if-elif chains.
> >
> >
> > Probably, which is why it hasn't been added yet. :-)
> >
> > But there is a definite readability improvement in that you *know*
> > that it's always the same variable that is being compared and that no
> > other conditions are snuck into some branches.
>
> Hmm, when I saw that "arbitrary expressions" were being proposed, I took
> that took mean that the variable would have to be repeated in the branches:
>
>switch x:
> case x.endswith('wart'): salicylic_acid()
> case x.endswith('roid'): preparation_h()
> default: chicken_soup()
That seems insane, since then it would be *just* different syntax for
if/elif. The example looks deceptive: surely the 'switch' expression
should allow an arbitrary expression, so the 'case' wouldn't be able
to refer to the switch part by a name unless there was syntax (or a
convention) for defining a name by which it could be referenced. I
think Perl 6 is defining a very general "matching" syntax which people
interested in this might want to study, just to see how far one can
stretch the insanity.
> > I would
> > think that it would be fine if some switches could be compiled into
> > some kind of lookup table while others would just be translated into a
> > series of if/elifs. As long as the compiler can tell the difference.
> >
> That's a worthy goal; of course, the devil is in the details. Given:
>
> switch x:
> case 1: one()
> case 2: two()
> case 3: three()
> default: too_many()
>
> Do we require that x be hashable so that the compiler can use a lookup
> table?
That's a good question. We could define switch/case in terms of a hash
table created by the compiler, and then raising an exception if x is
unhashable is fair game. Or we could define it in terms of successive
'==' comparisons, and then the compiler would have to create code for
a slow path in case x is unhashable. I don't think I'm in favor of
always taking the default path when x is unhashable; that would cause
some surprises if an object defines __eq__ to be equal to ints (say)
but not __hash__.
Note that we currently don't have a strong test for hashable; it's
basically "if hash(x) doesn't raise an exception" which means that we
would have to catch this exception (or perhaps only TypeError) in
order to implement the slow path for the successive-comparisons
semantics.
I note that C doesn't require any particular implementation for
switch/case; there's no rule that says the numbers must fit in an
array of pointers or anything like that. So I would be careful before
we define this in terms of hash tables. OTOH the hash table semantics
don't require us to commit to a definition of hashable, which is an
advantage.
How's that for a wishy-washy answer. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code coverage reporting.
Brett Cannon wrote: > Ah, do the union of the coverage! Yeah, that would be nice and give the > most accurate coverage data in terms of what is actually being tested. > But as Titus says in another email, question is how to get that data > sent back to be correlated against. It might be interesting as a BuilBot extension: you already know the definitive identity of the thing that you're running (svn path and revision), a central server with established communication channel, plus all the other BuildBot machinery. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
>> A switch-statement offers only a modest readability improvement over
>> if-elif chains.
>
>
> Probably, which is why it hasn't been added yet. :-)
>
> But there is a definite readability improvement in that you *know*
> that it's always the same variable that is being compared and that no
> other conditions are snuck into some branches.
Hmm, when I saw that "arbitrary expressions" were being proposed, I took
that took mean that the variable would have to be repeated in the branches:
switch x:
case x.endswith('wart'): salicylic_acid()
case x.endswith('roid'): preparation_h()
default: chicken_soup()
> I would
> think that it would be fine if some switches could be compiled into
> some kind of lookup table while others would just be translated into a
> series of if/elifs. As long as the compiler can tell the difference.
>
That's a worthy goal; of course, the devil is in the details. Given:
switch x:
case 1: one()
case 2: two()
case 3: three()
default: too_many()
Do we require that x be hashable so that the compiler can use a lookup
table?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code coverage reporting.
On 6/19/06, Benji York <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> But it does seem accurate; random checking of some modules that got high> but not perfect covereage all seem to be instances where dependency> injection would be required to get the tests to work since they were > based on platform-specific things.> I don't know if we need it hooked into the buildbots (unless it is dirt> cheap to generate the report).It would be interesting to combine the coverage over several platforms and report that.Ah, do the union of the coverage! Yeah, that would be nice and give the most accurate coverage data in terms of what is actually being tested. But as Titus says in another email, question is how to get that data sent back to be correlated against. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > On 6/18/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > [...] Offering arbitrary expressions whose > meaning can vary at runtime would kill any potential speedup (the > ultimate purpose for having a switch statement), [...] > > Um, is this dogma? Wouldn't a switch statement also be a welcome > addition to the readability? I haven't had the time to follow this > thread (still catching up on my Google 50%) but I'm not sure I agree > with the idea that a switch should only exist for speedup. > > A switch-statement offers only a modest readability improvement over > if-elif chains. Probably, which is why it hasn't been added yet. :-) But there is a definite readability improvement in that you *know* that it's always the same variable that is being compared and that no other conditions are snuck into some branches. > If a proposal introduces a switch-statement but doesn't > support fast dispatch, then it loses much of its appeal. Historically, the > switch-statement discussions centered around fast dispatch without function > call overhead or loss of direct read/write to local variables (see > sre_compile.py and sre_parse.py for code would would see a speed benefit but > almost no improvement in readability). Well yes duh, of course a switch syntax should be as fast as a corresponding if/elif dispatch series. (I look upon dict-of-functions-based dispatch as a tool for a completely different use case.) Perhaps I misunderstood Josiah's comment; I thought he was implying that a switch should be significantly *faster* than if/elif, and was arguing against features that would jeopardize that speedup. I would think that it would be fine if some switches could be compiled into some kind of lookup table while others would just be translated into a series of if/elifs. As long as the compiler can tell the difference. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
At 09:27 AM 6/19/2006 -0700, Raymond Hettinger wrote: >Guido van Rossum wrote: >>Um, is this dogma? Wouldn't a switch statement also be a welcome >>addition to the readability? I haven't had the time to follow this >>thread (still catching up on my Google 50%) but I'm not sure I agree >>with the idea that a switch should only exist for speedup. >> > >A switch-statement offers only a modest readability improvement over >if-elif chains. If a proposal introduces a switch-statement but doesn't >support fast dispatch, then it loses much of its appeal. I would phrase that a lot differently. A switch statement is *very* attractive for its readability. The main problem is that if the most expressive way to do something in Python is also very slow -- i.e., people use it when they should be using a dictionary of functions -- then it adds to the "Python is slow" meme by attractive nuisance. :) Therefore, a switch statement should be made to perform at least as well as a dictionary of functions, or having it might actually be a bad thing. In any case, we *can* make it perform as well as a dictionary of functions, and we can do it with or without another opcode. What really needs to be decided on (i.e. by the BDFL) is the final syntax of the statement itself, and the semantics of evaluation time for the 'case' expressions, either at first execution of the switch statement, or at function definition time. If explaining the evaluation time is too difficult, however, it might be an argument against the optimization. But, I don't think that either first-use evaluation or definition-time evaluation are too hard to explain, since Python has both kinds of evaluation already. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote: On 6/18/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: [...] Offering arbitrary expressions whose meaning can vary at runtime would kill any potential speedup (the ultimate purpose for having a switch statement), [...] Um, is this dogma? Wouldn't a switch statement also be a welcome addition to the readability? I haven't had the time to follow this thread (still catching up on my Google 50%) but I'm not sure I agree with the idea that a switch should only exist for speedup. A switch-statement offers only a modest readability improvement over if-elif chains. If a proposal introduces a switch-statement but doesn't support fast dispatch, then it loses much of its appeal. Historically, the switch-statement discussions centered around fast dispatch without function call overhead or loss of direct read/write to local variables (see sre_compile.py and sre_parse.py for code would would see a speed benefit but almost no improvement in readability). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to branch release25-maint?
Anthony Baxter wrote: >A question has been asked about branching release25-maint at the time >of beta1. I was actually thinking about doing this for 2.5rc1 - once >we're in release candidate stage we want to really be careful about >checkins. I'm not sure it's worth branching at beta1 - it's a bit >more work all round, vs what I suspect will be a small amount of 2.6 >work landing on the trunk nownownow. Also, I'd prefer people's cycles >be spent on bughunting 2.5 rather than worrying about shiny new >features for the release that's, what, 18 months away? > > I recommend holding-off on a 2.6 branch until someone actually has some non-trivial amount of 2.6 code ready for a commit. My guess is that we are all focused on 2.5 or are participating in intoxicating Py3k discussions. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improve error msgs?
>>
In abstract.c, there are many error messages like
>>
>> type_error("object does not support item assignment");
>>
>> It helps debugging if the object's type was prepended.
>> Should I go through the code and try to enhance them
>> where possible?
>
> So that's definite "perhaps"?
>
> Anyway, posted patch 1507676.
Sigh. I guess I'll have to commit it to get a second (actually,
third, thanks Armin) opinion...
If you want an opinion on whether it is useful, then yes, it is
useful. Honestly I thought that was kind of obvious since better, more
informative error messages are always better as long as the verbosity
is not insane.
As for looking at the patch, that is just the usual time/priority
problem. =)
Also, be sure to pay attention to speed when it comes to exceptions
that are both generated and caught internally -- those need to remain
as fast and lightweight as possible (not spending time inside sprintf()
and the like). Grep for PyErr_ExceptionMatches to get a feel for which
should treated with care. Please do not mindlessly go through and
change all the exception messaging. Instead, devote some thought to
which messages are detrimentally uninformative and are not part of time
critical execution paths.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setobject code
Alexander Belopolsky wrote: >1. Is there a reason not to have PySet_CheckExact, given that >PyFrozenSet_CheckExact exists? Similarly, why PyAnySet_Check, but no >PySet_Check or PyFrozenSet_Check? > > If you NEED PySet_CheckExact, then say so. Adding it is trivial. Each of the six combinations needs to be evaluated on its own merits. Do you have use case where it is important to know that you have a set, that it is not frozen, and that it is not a subtype? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug: xml.dom.pulldom never gives you END_DOCUMENT events with an Expat parser
Hm... Perhaps the xml-sig would be a better place to discuss this?
On 6/11/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> First, sorry for posting this here, I closed my SourceForge account a
> few months ago and I can't get it reopened...
>
> I'm using python 2.2.1 but a diff on SVN showed that there was no
> change at this level, so the following bug should still be there in
> current versions (I'll try with a 2.4 at work tomorrow). On my
> machine, xml.sax.make_parser returns an
> xml.sax.expatreader.ExpatParser instance.
>
> The problem is: I'm never given END_DOCUMENT events.
>
> Code to reproduce:
>
> from xml.dom.pulldom import parseString
> reader = parseString('text')
> # The following 2 lines will produce, in order:
> # START_DOCUMENT, START_ELEMENT, TEXT, END_ELEMENT
> # Note the lack of the END_DOCUMENT event.
> for event,node in reader:
>print event
> # The following line will get an END_DOCUMENT event
> print reader.getEvent()[0]
> # The following line will throw a SAXParseException,
> # because the SAX parser's close method has been
> # called twice
> print reader.getEvent()[0]
>
>
> Cause:
>
> The xml.dom.pulldom.DOMEventStream.getEvent method, when it has no
> more event in its internal stack, calls the SAX parser's close()
> method (which is OK) then immediately returns 'None', ignoring any
> event that could have been generated by the call to the close()
> method. If you call getEvent later, it will send you the remaining
> events until there are no more left, and then will call the SAX
> parser's close() method again, causing a SAXParseException.
> Because expat (an maybe other parsers too) has no way to know when the
> document ends, it generates the endDocument/END_DOCUMENT event only
> when explicitely told that the XML chunk is the final one (i.e. when
> the close() method is called)
>
>
> Proposed fix:
>
> Add a "parser_closed" attribute to the DOMEventStream class,
> initialized to "False". After having called self.parser.close() in the
> xml.dom.pulldom.DOMEventStream.getEvent method, immediately set this
> "parser_closed" attribute to True and proceed. Finally, at the
> beginning of the "while" loop, immediately returns "None" if
> "parser_closed" is "True" to prevent a second call to
> self.parser.close().
> With this change, any call to getEvent when there are no event left
> will return None and never throw an exception, which I think is the
> expected behavior.
>
>
> Proposed code:
>
> The "closed" attribute is initialized in the "__init__" method:
> def __init__(self, stream, parser, bufsize):
> self.stream = stream
> self.parser = parser
> self.parser_closed = False
> self.bufsize = bufsize
> if not hasattr(self.parser, 'feed'):
> self.getEvent = self._slurp
> self.reset()
>
> The "getEvent" method becomes:
> def getEvent(self):
> # use IncrementalParser interface, so we get the desired
> # pull effect
> if not self.pulldom.firstEvent[1]:
> self.pulldom.lastEvent = self.pulldom.firstEvent
> while not self.pulldom.firstEvent[1]:
> if self.parser_closed:
> return None
> buf = self.stream.read(self.bufsize)
> if buf:
> self.parser.feed(buf)
> else:
> self.parser.close()
> self.parser_closed = True
> rc = self.pulldom.firstEvent[1][0]
> self.pulldom.firstEvent[1] = self.pulldom.firstEvent[1][1]
> return rc
>
> The same problem seems to exist in the
> xml.dom.pulldom.DOMEventStream._slurp method, when the SAX parser is
> not an IncrementalParser, as the parser's close() method is never
> called. I suggest adding a call to the close() method in there.
> However, as I only have expat as an option, which implements
> IncrementalParser, I can't test it...
> The _slurp method would become:
> def _slurp(self):
> """ Fallback replacement for getEvent() using the
> standard SAX2 interface, which means we slurp the
> SAX events into memory (no performance gain, but
> we are compatible to all SAX parsers).
> """
> self.parser.parse(self.stream)
> self.parser.close()
> self.getEvent = self._emit
> return self._emit()
> The _emit method raises exceptions when there are no events left, so I
> propose changing it to:
> def _emit(self):
> """ Fallback replacement for getEvent() that emits
> the events that _slurp() read previously.
> """
> if not self.pulldom.firstEvent[1]:
> return None
> rc = self.pulldom.firstEvent[1][0]
> self.pulldom.firstEvent[1] = self.pulldom.firstEvent[1][1]
> return rc
>
> Hope this helps.
>
> --
> Thomas Broyer
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listin
Re: [Python-Dev] Misleading error message from PyObject_GenericSetAttr
On 6/14/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > When an extension type Foo defines tp_getattr, but leaves tp_setattr > NULL, an attempt to set an attribute bar results in an AttributeError > with the message "'Foo' object has no attribute 'bar'". This message > is misleading because the object may have the attribute 'bar' as > implemented in tp_getattr. It would be better to change the message > to "'Foo' object has only read-only attributes (assign to .bar)" as in > the case tp_setattro == tp_setattr == NULL in PyObject_SetAttr . I agree. Can you submit a patch to SF please? > I've also noticed that the exceptions raised from PyObject_SetAttr are > TypeErrors. Shouldn't PyObject_GenericSetAttr raise a TypeError if > tp_setattr is null but tp_getattr is not? This would be consistent > with the errors from read-only descriptors. Attempting to obtain complete consistency between TypeError and AttributeError is hopeless. But if you want to submit a patch to reduce a particular bit of inconsistency (without increasing it elsewhere) it might well be accepted. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyString_FromFormat
On 6/19/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: > One thing I have often lamented having in PyString_FromFormat (and cousins, > like PyErr_Format) is to be able to integrate PyObject pointers. Adding > something like %S and %R (for str() and repr() respectively) seems very > useful to me. Is there any reason why this isn´t there? Asking "why" a particular feature is omitted rarely is a good starting point. We collectively probably don't remember, or misremember the discussion if there was any; the most likely reason is simply that nobody thought it was useful at the time, and nobody who thought it *was* useful put enough effort in to provide the feature. If I had to make a guess, %S and %R as you propose have the very real possibility to fail. PyString_FromFormat() currently only fails if it runs out of memory. This is especially helpful for PyErr_Format() -- the last thing you want to hapen during formatting of an error message is to get an error in the formatting. But there are always ways to handle that if the use case is strong enough. If you want to gather use cases, you could scour the Python source code for calls to either API immediately preceded by a call to PyObject_Str/Repr() to produce a string to be included into the message. If you find many, you are not alone and you have a good use case. Personally, I think it's not worth the trouble. But I wouldn't necessarily reject a patch (not that I'm in the business of accepting individual patches any more -- others will weigh in there). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
On 6/16/06, Kristján V. Jónsson <[EMAIL PROTECTED]> wrote: > Although python has had full unicode support for filenames for a long time > on selected platforms (e.g. Windows), there is one glaring deficiency: It > cannot import from paths containing unicode. I´ve tried creating folders > with chinese characters and adding them to path, to no avail. I don't know exactly where this discussion is heading at this point, but I think it's clear that there's a real (though -- yet -- rare) problem, for which currently only ugly work-arounds exist. I'm not convinced that it occurs on other platforms than Windows -- everyone else seems to use UTF-8 for pathnames, while Windows is stuck with code pages and other crap, and the only reasaonably way to access Unicode pathnames is via the Windows-specific Unicode API (which is why import is the last place where this isn't easily solved, as the import machinery is completely 8-bit-based). Has it been determined yet whether the DOS 8+3 filename cannot be used as a workaround? Perhaps it would be good enough to wait for Py3k? That will have pure Unicode strings and the import machinery will be completely rewritten anyway. (And I wouldn't be surprised if that rewrite were to use pure Python code.) Py3k will be released later than Python 2.6, but most likely before 2.7. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Wouldn´t it be possible then to emulate the unix way? Simply encode any unicode paths to utf-8, process them as normal, and then decode them just prior to the actual windows io call? It would make sense to just use the utf-8 encoding all the way for all platforms (since it is easy to work with), and then convert to most appropriate encoding for the platform in question right at the end, e.g. unicode for windows, mbcs for windows without unicode (win98) (which relies on the LC_LOCALE setting) and whatever 8 bit encoding is appropriate for the particular unix platform. Of course, once there, why not do it unicode all the way up to that last point? Unless there are platforms without wchar_t that would make sense. At any rate, I am trying to find a coding path of least resistance here. Regardless of the timeline or acceptance in mainstream python for this feature, it is something I will have to patch in for our application. Cheers, Kristján -Original Message- From: Nick Coghlan [mailto:[EMAIL PROTECTED] Sent: 19. júní 2006 13:46 To: Kristján V. Jónsson Cc: "Martin v. Löwis"; Python Dev Subject: Re: [Python-Dev] unicode imports Kristján V. Jónsson wrote: > Funny that no other platforms could benefit from a unicode import path. > Does that mean that windows will reign supreme? Please explain. As near as I can tell, other platforms use encoded strings with the normal (byte-based) posix file API, so the Python interpreter and the file system simply need to agree on the encoding (typically utf-8) in order for both filesystem access and importing from non-ASCII paths to work. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/18/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > [...] Offering arbitrary expressions whose > meaning can vary at runtime would kill any potential speedup (the > ultimate purpose for having a switch statement), [...] Um, is this dogma? Wouldn't a switch statement also be a welcome addition to the readability? I haven't had the time to follow this thread (still catching up on my Google 50%) but I'm not sure I agree with the idea that a switch should only exist for speedup. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
At 12:10 AM 6/20/2006 +1000, Nick Coghlan wrote:
>Caching on first use would be the easiest to explain I think. Something like:
>
> if jump_dict is NULL:
> jump_dict = {FIRST_CASE : JUMP_TARGET_1,
> SECOND_CASE : JUMP_TARGET_2,
> THIRD_CASE : JUMP_TARGET_3}
> jump_to_case(value, jump_dict)
> ELSE_CLAUSE
> jump_to_end()
Sadly, it's not *quite* that simple, due to the fact that co_lnotab must be
increase in line numbers as bytecode offsets increase. It would actually
look more like:
LOAD_DEREF jumpdictN
JUMP_IF_FALSE initfirstcase
do_switch:
...
initfirstcase:
DUP_TOP
# compute case value
LOAD_CONST firstcaseoffset
ROT_THREE
STORE_SUBSCR
JUMP_FORWARD initsecondcase
firstcaseoffset:
first case goes here
...
initsecondcase:
DUP_TOP
# compute case value
LOAD_CONST secondcaseoffset
ROT_THREE
STORE_SUBSCR
JUMP_FORWARD initthirdcase
secondcaseoffset:
second case goes here
...
...
initlastcase:
DUP_TOP
# compute case value
LOAD_CONST lastcaseoffset
ROT_THREE
STORE_SUBSCR
JUMP_ABSOLUTE doswitch
lastcaseoffset:
last case goes here
The above shenanigans are necessary because the line numbers of the code
for computing the case expressions have to be interleaved with the line
numbers for the code for the case suites.
Of course, we could always change how co_lnotab works, which might be a
good idea anyway. As our compilation techniques become more sophisticated,
it starts to get less and less likely that we will always want bytecode and
source code to be in exactly the same sequence within a given code object.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Phillip J. Eby wrote:
>>> Either way would work, and both would allow multiple versions of the same
>>> switch statement to be spun off as closures without losing their
>> "constant"
>>> nature or expressiveness. It's just a question of which one is easier to
>>> explain. Python already has both types of one-time initialization:
>>> function defaults are computed at definition time, and modules are only
>>> loaded once, the first time you import them.
>> I would go with the former rather than the latter, if only for
>> flexibility.
>
> There's no difference in flexibility. In either case, the dictionary
> should be kept in a cell in the function's closure, not with the code
> object. It would simply be a difference in *when* the values were
> computed, and by which code object. To be done at function definition
> time, the enclosing code block would have to do it, which would be sort of
> weird from a compiler perspective, and there would be an additional problem
> with getting the line number tables correct. But that's going to be tricky
> no matter which way it's done.
Caching on first use would be the easiest to explain I think. Something like:
if jump_dict is NULL:
jump_dict = {FIRST_CASE : JUMP_TARGET_1,
SECOND_CASE : JUMP_TARGET_2,
THIRD_CASE : JUMP_TARGET_3}
jump_to_case(value, jump_dict)
ELSE_CLAUSE
jump_to_end()
'jump_dict' would be held in a cell on the function's closure (since the
calculated case values might depend on global or closure variables)
'jump_to_case' would be the new opcode, taking two arguments off the stack
(the jump dictionary and the switch value), executing the matching case (if
any) and jumping to the end of the switch statement.
If no case is matched, then fall through to the else clause and then jump to
the end of the statement.
Then the optimisation of the case where all of the case expressions are
literals would come under the purview of a constant-folding compiler
automatically when it figures out that the dictionary literal only contains
constants.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Kristján V. Jónsson wrote:
> Funny that no other platforms could benefit from a unicode import path.
> Does that mean that windows will reign supreme? Please explain.
As near as I can tell, other platforms use encoded strings with the normal
(byte-based) posix file API, so the Python interpreter and the file system
simply need to agree on the encoding (typically utf-8) in order for both
filesystem access and importing from non-ASCII paths to work.
On Windows, though, most of the file system interaction code has had to be
updated to use the wide-character API where possible. import.c is one of the
few holdouts that relies entirely on the byte-based posix API.
If I had to put money on what's currently happening on your test machine, it's
that import.c is trying to do u'c:/tmp/\u814c'.encode('mbcs'), getting
'c:/tmp/?' and proceeding to do nothing useful with that path entry. Checking
the result of sys.getfilesystemencoding() should be able to confirm that.
So it looks like it ain't really gonna work properly on Windows unless
import.c is rewritten to use the Unicode-aware platform independent IO
implementation in posixmodule.c.
Until that happens (hopefully by Python 2.6), I like MvL's suggestion - look
at the 8.3 DOS name on the command prompt and put that into sys.path. ctypes
and/or pywin32 should let you get at that information programmatically.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code coverage reporting.
Benji York wrote: > Brett Cannon wrote: >> But it does seem accurate; random checking of some modules that got high >> but not perfect covereage all seem to be instances where dependency >> injection would be required to get the tests to work since they were >> based on platform-specific things. > >> I don't know if we need it hooked into the buildbots (unless it is dirt >> cheap to generate the report). > > It would be interesting to combine the coverage over several platforms > and report that. The code coverage report should include how often a line got executed, not just if it got executed at all. This makes it possible to se hotspots in the code. BTW, if there's interest, I can change the code behind http://coverage.livinglogic.de so that instead of importing the data into a database, static HTML files are created, so that we can run the job more often on one of the Python servers. Currently the job runs once a month with ./python Lib/test/regrtest.py -T -N -R :: -uurlfetch,largefile,network,decimal and takes about one hour to run the tests. The source code is available from http://styx.livinglogic.de/~walter/python/coverage/PythonCodeCoverage.py Servus, Walter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
At 12:28 AM 6/19/2006 -0700, Josiah Carlson wrote:
>"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> > At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
> > >The non-fast version couldn't actually work if it referenced any names,
> > >given current Python semantics for arbitrary name binding replacements.
> >
> > Actually, one could consider "case" expressions to be computed at function
> > definition time, the way function defaults are. That would solve the
> > problem of symbolic constants, or indeed any sort of expressions.
>
>Using if/elif/else optimization precludes any non-literal constants, so
>we would necessarily have to go with a switch/case for this semantic. It
>seems as though it would work well, and wouldn't be fraught with
>any of the gotchas that catch users like:
> def fcn(..., dflt={}, dflt2=[]):
>...
>
>
> > An alternate possibility would be to have them computed at first use and
> > cached thereafter.
> >
> > Either way would work, and both would allow multiple versions of the same
> > switch statement to be spun off as closures without losing their
> "constant"
> > nature or expressiveness. It's just a question of which one is easier to
> > explain. Python already has both types of one-time initialization:
> > function defaults are computed at definition time, and modules are only
> > loaded once, the first time you import them.
>
>I would go with the former rather than the latter, if only for
>flexibility.
There's no difference in flexibility. In either case, the dictionary
should be kept in a cell in the function's closure, not with the code
object. It would simply be a difference in *when* the values were
computed, and by which code object. To be done at function definition
time, the enclosing code block would have to do it, which would be sort of
weird from a compiler perspective, and there would be an additional problem
with getting the line number tables correct. But that's going to be tricky
no matter which way it's done.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code coverage reporting.
Brett Cannon wrote: > But it does seem accurate; random checking of some modules that got high > but not perfect covereage all seem to be instances where dependency > injection would be required to get the tests to work since they were > based on platform-specific things. > I don't know if we need it hooked into the buildbots (unless it is dirt > cheap to generate the report). It would be interesting to combine the coverage over several platforms and report that. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Thomas Heller wrote: > It should be noted that I once started to convert the import machinery > to be fully unicode aware. As far as I can tell, a *lot* has to be changed > to make this work. > > I started with refactoring Python/import.c, but nobody responded to the > question > whether such a refactoring patch would be accepted or not. Perhaps someone should start a PEP on this subject ?! (not me, though :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 19 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When to branch release25-maint?
Anthony Baxter <[EMAIL PROTECTED]> writes: > A question has been asked about branching release25-maint at the time > of beta1. I was actually thinking about doing this for 2.5rc1 - once > we're in release candidate stage we want to really be careful about > checkins. I'm not sure it's worth branching at beta1 - it's a bit > more work all round, vs what I suspect will be a small amount of 2.6 > work landing on the trunk nownownow. Also, I'd prefer people's cycles > be spent on bughunting 2.5 rather than worrying about shiny new > features for the release that's, what, 18 months away? > > Anyway, thought I'd open this up for discussion... I agree with you. If people want to work on new features, they can create branches for that -- by default, bug fixes should go into 2.5 without further effort. Cheers, mwh -- I wouldn't trust the Anglo-Saxons for much anything else. Given they way English is spelled, who could trust them on _anything_ that had to do with writing things down, anyway? -- Erik Naggum, comp.lang.lisp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
Nick Maclaren <[EMAIL PROTECTED]> writes: > As I have posted to comp.lang.python, I am not happy with Python's > numerical robustness - because it basically propagates the 'features' > of IEEE 754 and (worse) C99. That's not really now I would describe the situation today. > Yes, it's better, but I would like to make it a LOT better. I > already have a more robust version of 2.4.2, but there are some > problems, technical and political. I should appreciate advice. I would like to see Tim Peters' opinion on all this. > 1) Should I start off by developing a testing version, to give people > a chance to scream at me, or write a PEP? "Yes" Or did you want advice on which? I think a PEP would make a lot of sense. > 2) Because some people are dearly attached to the current behaviour, > warts and all, and there is a genuine quandary of whether the 'right' > behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R- > finally-specifies (let's ignore C99 and Java as beyond redemption), Why? Maybe it's clear to you, but it's not totally clear to me, and it any case the discussion would be better informed for not being too dismissive. > there might well need to be options. These can obviously be done by > a command-line option, an environment variable or a float method. > There are reasons to disfavour the last, but all are possible. Which > is the most Pythonesque approach? I have heard Tim say that there are people who would dearly like to be able to choose. Environment variables and command line switches are not Pythonic. > 3) I am rather puzzled by the source control mechanism. Are commit > privileges needed to start a project like this in the main tree? Yes. You can also use svk, I believe, but I don't really know anything about that. > 4) Is there a Python hacking document? Specifically, if I want to > add a new method to a built-in type, is there any guide on where to > start? Don't think so. There's some stuff under http://www.python.org/dev/ but nothing that would cover this. > 5) I am NOT offering to write a full floating-point emulator, though > it would be easy enough and could provide repeatable, robust results. > "Easy" does not mean "quick" :-( Maybe when I retire. Incidentally, > experience from times of yore is that emulated floating-point would > be fast enough that few, if any, Python users would notice. Maybe you're right, but I personally doubt this last bit. Speaking more generally, it would be nice if you gave more explanations of why the changes you want to make are desirable -- and for that matter, more details about what they actually are. I'm interested in making Python's floating point story better, and have worked on a few things for Python 2.5 -- such as pickling/marshalling of special values -- but I'm not really a numerical programmer and don't like to guess what they need. Cheers, mwh -- Python enjoys making tradeoffs that drive *someone* crazy . -- Tim Peters, comp.lang.python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyString_FromFormat
One thing I have often lamented having in PyString_FromFormat (and cousins, like PyErr_Format) is to be able to integrate PyObject pointers. Adding something like %S and %R (for str() and repr() respectively) seems very useful to me. Is there any reason why this isn´t there? Cheers, Kristján ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
It should be noted that I once started to convert the import machinery to be fully unicode aware. As far as I can tell, a *lot* has to be changed to make this work. I started with refactoring Python/import.c, but nobody responded to the question whether such a refactoring patch would be accepted or not. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
I don't have specific information on the machines. We didn´t try very hard to get things to work with 2.3 since we simply assumed it would work automatically when we upgraded to a more mature 2.4. I could try to get more info, but it would be 2.3 specific. Have there been any changes since then? Note that it may not go into program files at all. Someone may want to install his modules in a folder named in the honour of his mother. Also, I really would like to see a general solution that doesn´t assume that the path name can somhow be transmuted to an ascii name. Users are unpredictable. When you have a wide distribution , you come up against all kinds of problems (Currently we have around 500.000 users in china.) Also, relying on some locale settings is not acceptable. My machine here has the icelandic locale. Yet, I need to be able to set up and use a chinese install. Likewise, many machines in china will have an english locale. A default encoding and locale is essentially an evil hack in our increasingly global environment. We have converted more or less our entire code base to unicode because keeping track of encoded strings is simply unworkable in a large project. Funny that no other platforms could benefit from a unicode import path. Does that mean that windows will reign supreme? Please explain. Cheers, Kristján -Original Message- From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] Sent: 17. júní 2006 08:42 To: Kristján V. Jónsson Cc: Python Dev Subject: Re: [Python-Dev] unicode imports Kristján V. Jónsson wrote: > The standard install path in chinese distributions can be with a > non-ANSI path, and installing an embedded python application there > will break it. I very much doubt this. On a Chinese system, the Program Files folder likely has a non-*ASCII* name, but it will have a fine *ANSI* name, as the ANSI code page on that system should be either 936 (simplified chinese) or 950 (traditional chinese) - unless the system is misconfigured. Can you please report what the path is, what the precise name of the operating system is, and what the system locale and the system code page are? > A completely parallel implementation on the sys.path[i] level? You should also take a look at what the 8.3 name of the path is. I really cannot believe that the path is unaccessible to DOS programs. > Are there other platforms beside Windows that would profit from this? No. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Well, my particular test uses u'c:/tmp/\u814c' If that cannot be encoded in mbcs, then mbcs isn't useful. Note that this is both an issue of python being able to run from an arbitrary install position, and also the ability of users to import and run scripts from any other arbitrary directory. Kristján -Original Message- From: Neil Hodgson [mailto:[EMAIL PROTECTED] Sent: 17. júní 2006 04:53 To: Kristján V. Jónsson Cc: Python Dev Subject: Re: [Python-Dev] unicode imports Kristján V. Jónsson: > Although python has had full unicode support for filenames for a long > time on selected platforms (e.g. Windows), there is one glaring > deficiency: It cannot import from paths containing unicode. I´ve > tried creating folders with chinese characters and adding them to path, to no > avail. > The standard install path in chinese distributions can be with a > non-ANSI path, and installing an embedded python application there will break > it. It should be unusual for a Chinese installation to use an install path that can not be represented in MBCS. Try encoding the install directory into MBCS before adding it to sys.path. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Okay, for specifics which demonstrate the problem.
I have a directory, C:\tmp\腌
In it, there is a file, doo.py
>d = os.listdir(u"c:/tmp")[-1]
>d
u'\u814c'
>>> d2 = os.listdir(u"c:/tmp/"+d)
>>> d2
[u'doo.py']
>>> p = u"c:/tmp/"+d
>>> p
u'c:/tmp/\u814c'
>>> sys.path.append(p)
>>> import doo
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named doo
>>> p.encode("mbcs")
'c:/tmp/?'
>>> p.encode("gb2312")
'c:/tmp/\xeb\xe7'
Running your example test code gives:
Prefixes: C:\PyDev25 C:\PyDev25
Path: ['c:\\tmp', 'c:\\documents and settings\\kristjan\\my documents\\python',
'C:\\PyDev25\\PCbuild8\\python25.zip', 'C:\\PyDev25\\DLLs', 'C:\\PyDev25\\lib',
'C:\\PyDev25\\lib\\plat-win', 'C:\\PyDev25\\lib\\lib-tk', 'C:\\PyDev25\\PCbuild8
', 'C:\\PyDev25', 'C:\\PyDev25\\lib\\site-packages']
Default encoding: ascii
Input encoding: cp850 Output encodings: cp850 cp850
-Original Message-
From: Nick Coghlan [mailto:[EMAIL PROTECTED]
Sent: 17. júní 2006 04:17
To: Phillip J. Eby
Cc: Kristján V. Jónsson; Python Dev
Subject: Re: [Python-Dev] unicode imports
Phillip J. Eby wrote:
> Actually, you would want to put it in sys.path_hooks, and then
> instances would be placed in path_importer_cache automatically. If
> you are adding it to the path_hooks after the fact, you should simply
> clear the path_importer_cache. Simply poking stuff into the
> path_importer_cache is not a recommended approach.
Oh, I agree - poking it in directly was a desperation measure if the path_hooks
machinery didn't like Unicode either.
I've since gone and looked, and you may be screwed either way - the standard
import paths appear to be always put on the system path as encoded 8-bit
strings, not as Unicode objects.
That said, it also appears that the existing machinery *should* be able to
handle non-ASCII path items, so long as 'Py_FileSystemDefaultEncoding' is set
correctly. If it isn't handling it, then there's something else going wrong.
Modules/getpath.c and friends don't encode the results returned by the platform
APIs, so the strings in
Kristján, can you provide more details on the fault you get when trying to
import from the path containing the Chinese characters? Specifically:
What is the actual file system path?
What do sys.prefix, sys.exec_prefix and sys.path contain?
What does sys.getdefaultencoding() return?
What do sys.stdin.encoding, sys.stdout.encoding and sys.stderr.encoding say?
What does "python -v" show?
Does adding the standard lib directories manually to sys.path make any
difference?
Does setting PYTHONHOME to the appropriate settings make any difference?
Running something like the following would be good:
import sys
print "Prefixes:", sys.prefix, sys.exec_prefixes
print "Path:", sys.path
print "Default encoding:", sys.getdefaultencoding()
print "Input encoding:", sys.stdin.encoding,
print "Output encodings:", sys.stdout.encoding, sys.stderr.encoding
try:
import string # Make python -v do something interesting
except ImportError:
print "Could not find string module"
sys.path.append(u"stdlib directory name")
try:
import string # Make python -v do something interesting
except ImportError:
print "Could not find string module"
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode imports
Ideally, I would like for python to "simply work." It seems to me that it is mostly a question of time when all modern platforms offer unicode filesystems and hence unicode APIs. IMHO, stuff like the importer should really be written in native unicode and revert to ASCII only as a fallback for unsupporting platforms. is WITH_UNICODE ever left undefined these days? And sure, module names need to be python identifiers (thus ASCII), although I wouldn't be surprised if that restriction were lifted in a not too distant future :) After all, we support the utf-8 encoding of source files, but I cannot write "kristján = 1". But that's for a future PEP. Kristján -Original Message- From: Nick Coghlan [mailto:[EMAIL PROTECTED] Sent: 16. júní 2006 15:30 To: Kristján V. Jónsson Cc: Python Dev Subject: Re: [Python-Dev] unicode imports Kristján V. Jónsson wrote: > A cursory glance at import.c shows that the import mechanism is fairly > complicated, and riddled with "char *path" thingies, and manual string > arithmetic. Do you have any suggestions on a clean way to unicodify > the import mechanism? Can you install a PEP 302 path hook and importer/loader that can handle path entries that are Unicode strings? (I think this would end up being the parallel implementation you were talking about, though) If the code that traverses sys.path and sys.path_hooks is itself unicode-unaware (I don't remember if it is or isn't), then you might be able to trick it by poking a Unicode-savvy importer directly into the path_importer_cache for affected Unicode paths. One issue is that the package and file names still have to be valid Python identifiers, which means ASCII. Unicode would be, at best, permitted only in the path entries. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
The signal() doc is rather vague on the point, since it doesn´t define the availible set of signals. It doesn´t even say that a signal identifier is an integer. But it says that it should return EINVAL if it "cannot satisfy the request". It doesn´t say "if the request is invalid", but I don't want to go into hairsplitting here. So I could agree with you there. But I completely disagree when you insist that microsoft has broken the C library. What they have done is added parameter validation, and thus simply added code in the "undefined" domain. I would also like to point out that, again apart from signal(), you are relying on undefined behaviour of fopen and others. It may well cause a crash on one of your other platforms one day, you have no way of knowing. VS2005 just pointed that out to you. So, it is my suggestion that in stead of going all defensive, and shouting "breakage", why not simply fix those very dubious CRT usage patterns? Think of it as lint. Also, consider this: in the case of file() and strftime() we are passing in dynamic strings. The strings are not within control of python. Normally these are static strings, within the control of the developer which has the function reference on hand, knows what he wants and so on. Yet, here we are passing in any old strings. There is a huge undefined domain there, and we should be very concerned about that. It is a wonder we haven´t seen these functions crash before. I would like to see the question about whether or not to use VS2005 be made purely on the merit of what is most practical (and useful) for people, rather than some emotional arguments about with loaded terms like "breakage", and personal feelings towards Microsoft. (And by the way, why does pythoncore.dll mess with signal() anyway? shouldn´t that be python.exe? I don´t want a dll that I embed to mess with my signal handling) Cheers, Kristján -Original Message- From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] Sent: 17. júní 2006 13:28 To: Scott Dial Cc: Python Dev; Kristján V. Jónsson Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1? Sure, I can *make* the library conform to C 99. I could also write my own C library entirely to achieve that effect. The fact remains that VS 2005 violates standard C where VS 2003 and earlier did not: A conforming program will abort, instead of completing successfully. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
This is, in fact, exactly what the python trunk does right now. This is done in exceptions.c Kristján -Original Message- From: Scott Dial [mailto:[EMAIL PROTECTED] Sent: 17. júní 2006 12:54 To: Python Dev Cc: "Martin v. Löwis"; Kristján V. Jónsson Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1? I'm nobody but I don't find your argument compelling. I suggest you go read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] TRUNK FREEZE IMMINENT FOR 2.5 BETA 1 - 00:00 UTC, 20-JUNE-2006
The trunk will be FROZEN for 2.5b1 from 00:00UTC on Tuesday, 20th of June. That's about 16 hours from now. Please don't checkin while the trunk is frozen, unless you're one of the release team (me, Martin, Fred, Ronald). I'll send another note once we're done with the release. Please note that once this release is done, the trunk is in FEATURE FREEZE. No new features should be checked in without prior approval - checkins that violate this will quite probably get backed out. Once the beta is out, I expect that we'll get quite a bit more anal about any checkins that break the buildbots. Please, please make sure you run the test suite before checking in - and if you're at all concerned that your checkin might have strange platform dependencies, check the buildbot status page (http://www.python.org/dev/buildbot/trunk/) after your checkin to make sure it didn't break anything. The plan at the moment is to branch the trunk for release25-maint when the first release candidate for 2.5 final is cut. This is currently scheduled for August 1st - about 6 weeks away. Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
> >The non-fast version couldn't actually work if it referenced any names,
> >given current Python semantics for arbitrary name binding replacements.
>
> Actually, one could consider "case" expressions to be computed at function
> definition time, the way function defaults are. That would solve the
> problem of symbolic constants, or indeed any sort of expressions.
Using if/elif/else optimization precludes any non-literal constants, so
we would necessarily have to go with a switch/case for this semantic. It
seems as though it would work well, and wouldn't be fraught with
any of the gotchas that catch users like:
def fcn(..., dflt={}, dflt2=[]):
...
> An alternate possibility would be to have them computed at first use and
> cached thereafter.
>
> Either way would work, and both would allow multiple versions of the same
> switch statement to be spun off as closures without losing their "constant"
> nature or expressiveness. It's just a question of which one is easier to
> explain. Python already has both types of one-time initialization:
> function defaults are computed at definition time, and modules are only
> loaded once, the first time you import them.
I would go with the former rather than the latter, if only for
flexibility.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
