Re: [Python-Dev] Switch statement
Phillip J. Eby wrote:
> I think I like it. I was confused by what Fredrik meant by "const", but
> your renaming it to "static" makes more sense to me;
footnote: I suggested static in my list of use cases; while "const"
makes sense in many cases, "static" makes more sense for things like this:
> def foo(value):
> table = const {
> 1: "one",
> 2: "two",
> 3: fie.fum,
> }
>
> (maybe "static" would be a better keyword?)
...at least for C/C++ heads; if you look things up in a dictionary, I'd
say that the noun "constant", in the meaning
2. a. A quantity assumed to have a fixed value in a
specified mathematical context.
b. An experimental or theoretical condition, factor,
or quantity that does not vary or that is regarded
as invariant in specified circumstances.
makes at least as much sense as the adjective "static":
1. a. Having no motion; being at rest; quiescent.
b. Fixed; stationary.
>> Unfortunately this would probably cause people to write
>>
>> switch x:
>> case static re.DOTALL: ...
>> case static re.IGNORECASE: ...
>>
>> which is just more work to get the same effect as the
>> def-time-switch-freezing proposal.
>
> Without the "static", the reordering of execution isn't obvious. But
> perhaps that could be lived with, if the explanation was, "well, static
> is implied by case".
I'd still prefer the "explicit is better than implicit" route, approach
switch/case (if added) is defined in terms of if/elif, and optimizations
are handled by the optimizer/code generator.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote: > That sounds like a good solution all around. I hope that others can > also find themselves in this. > > (1) An expression of the form 'static' has the semantics of > evaluating the atom at the same time as the nearest surrounding > function definition. If there is no surrounding function definition, > 'static' is a no-op and the expression is evaluated every time. > [Alternative 1: this is an error] [Alternative 2: it is evaluated > before the module is entered; this would imply it can not involve any > imported names but it can involve builtins] [Alternative 3: > precomputed the first time the switch is entered] +0.5 on this (still looking for some obvious drawback). as for static in non-local scopes, an error feels more pythonic, but that would complicate things if you want to move code from a local to a global context (but how often do you do that ?). alternative 2 and 3 feels "too magic", again. > (2) All case expressions in a switch have an implied 'static'. I'm still -0 on implied static. and only +0 on switch/case, in general. but it's growing on me. (now, if you're written "implied 'break'", I'm all for it) > (3) A switch is implemented using a dict which is precomputed at the > same time its static expressions are precomputed. The switch > expression must be hashable. Overlap between different cases will > raise an exception at precomputation time. +0 on switch/case, but -0.5 on a "in terms of implementation" rather than "in terms of existing language constructs" approach. as I mentioned before, I'd prefer if the switch/case/case-in/else was defined in terms of a corresponding if/elif/else construct (but where the controlling expression is only evaluated once). after all, Python's a dynamic language, and I'm not convinced that I would never want to use dynamically evaluated case values. just map switch EXPR: case E1: ... case in E2: ... else: ... to VAR = EXPR if VAR == E1: ... elif VAR in E2: ... else: ... where VAR is a temporary variable, and case and case-in clauses can be freely mixed, and leave the rest to the code generator. (we could even allow "switch EXPR [as VAR]" to match a certain other sugar construct). I'm also a K&R guy, so switch/case/case-in/else should all have the same indent. anything else is just sloppy design. > Independent from this, I wonder if we also need static names of the form > > static = > > which would be similar to > >= static () > > but also prevents from being assigned to elsewhere in the same scope. -0 from here; I don't see an obvious need for static names, but it may grow on me. > Also, I haven't heard a lot of thumbs up or down on the idea of using > > case X: > > to indicate a single value and > > case in S: > > to indicate a sequence of values. +1 from here. it's obvious, useful, and therefore perfectly pythonic. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Fredrik Lundh wrote: > I'd still prefer the "explicit is better than implicit" route, approach > switch/case (if added) is defined in terms of if/elif, and optimizations > are handled by the optimizer/code generator. s/approach/where/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyRange_New() alternative?
[Ralf W. Grosse-Kunstleve] > Thanks! This does the trick for me: > > #if PY_VERSION_HEX >= 0x0203 > PyObject_CallFunction( > (PyObject*) &PyRange_Type, "lll", start, start+len*step, step) Note that this is extremely lax about possible overflow in the arithmetic. For that reason it can't be recommend for general use. > #else > PyRange_New(start, len, step, 1) > #endif > > I've tested this with Python 2.2.3, 2.3.4, 2.4.3, 2.5b1. Python 2.2.3 (RedHat > WS 3) compiles the PyRange_Type call, but there is a runtime error: > > TypeError: cannot create 'xrange' instances Sorry, I didn't follow that. The only mention of PyRange_Type in the #if'ed code above is in a block that looks like it should be entirely ignored in a 2.2.3 Python (provided you're using the right header files and the C compiler isn't broken). > I am compiling the code above with a C++ compiler (in the context of > Boost.Python). Newer g++ versions unfortunatly produce a warning if -Wall is > specified: > > warning: dereferencing type-punned pointer will break strict-aliasing rules > > This refers to the (PyObject*) &PyRange_Type cast. > I believe the warning is bogus, but people still get upset about it (google > the > C++-SIG archive). Compile all of Python that way, and you'll probably see more of those than you can count ;-) Python is normally compiled with, and is _intended_ to be compiled with, -fno-strict-aliasing If you didn't do that, try it. > Is there a chance that PyRange_New() could be resurrected, > with the fragment above (plus additional overflow check for start+len*step) as > the implementation? That would fix the problems of the old implementation, > there would be no reason to have the cast in C++, no frustrated end-users, and > one change less to document. The deprecation of PyRange_New was duly announced in the NEWS file for Python 2.4: """ What's New in Python 2.4 (release candidate 1) == *Release date: 18-NOV-2004* ... C API - - The PyRange_New() function is deprecated. """ Since it was never documented to begin with, it was a "use at your own risk" thing anyway. As you're currently it's only known user throughout all of history :-), if you do all the work of rehabilitating it, I'd be at best a weak -1 anyway: one of the problems with PyRange_New was that its signature was wildly different than the builtin range()'s. That made it a poor API for "surprise, surprise!" reasons alone. That was a mistake, and I'd rather inconvenience you than pass that mistake on to our precious children ;-) OTOH, I'd have no objection to a new C API function with a (start, stop, step) signature. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Fredrik Lundh wrote: > (now, if you're written "implied 'break'", I'm all for it) note to self: the fact that it's a holiday doesn't mean that you should post before you'd had enough coffee. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Moving the ctypes repository to python.org
Now that ctypes is no longer an externally maintained module, imo the repository should be moved from SF cvs to python.org svn. The current layout is different than the main python trunk, and it should be preserved so that I can still do standalone releases. I think the best would be to import it into an url like http://svn.python.org/projects/sandbox/trunk/ctypes/ Is it possible to take the CVS repository files (they can be accessed with rsync), and import that, preserving the whole history, into SVN? I would be responsible to merge changes from the sandbox to the Python trunk and vice versa. On the other hand, it may be possible to use the svn:external facility to have Modules/_ctypes and Lib/ctypes use certain directories in the sandbox tree (although I do not know how good this works in reality). Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyRange_New() alternative?
--- Tim Peters <[EMAIL PROTECTED]> wrote: > [Ralf W. Grosse-Kunstleve] > > Thanks! This does the trick for me: > > > > #if PY_VERSION_HEX >= 0x0203 > > PyObject_CallFunction( > > (PyObject*) &PyRange_Type, "lll", start, start+len*step, step) > > Note that this is extremely lax about possible overflow in the > arithmetic. For that reason it can't be recommend for general use. > > > #else > > PyRange_New(start, len, step, 1) > > #endif > > > > I've tested this with Python 2.2.3, 2.3.4, 2.4.3, 2.5b1. Python 2.2.3 > (RedHat > > WS 3) compiles the PyRange_Type call, but there is a runtime error: > > > > TypeError: cannot create 'xrange' instances > > Sorry, I didn't follow that. The only mention of PyRange_Type in the > #if'ed code above is in a block that looks like it should be entirely > ignored in a 2.2.3 Python (provided you're using the right header > files and the C compiler isn't broken). First I tried the PyRange_Type code with Python 2.2.3 and no #ifdef. I resorted to the #ifdef and the old PyRange_New() call only because it didn't work. > Compile all of Python that way, and you'll probably see more of those > than you can count ;-) Python is normally compiled with, and is > _intended_ to be compiled with, > > -fno-strict-aliasing > > If you didn't do that, try it. I missed this. Thanks for pointing it out. > Since it was never documented to begin with, it was a "use at your own > risk" thing anyway. As you're currently it's only known user > throughout all of history :-), if you do all the work of > rehabilitating it, I'd be at best a weak -1 anyway: one of the > problems with PyRange_New was that its signature was wildly different > than the builtin range()'s. That made it a poor API for "surprise, > surprise!" reasons alone. That was a mistake, and I'd rather > inconvenience you than pass that mistake on to our precious children > ;-) I agree, although I find it hard to believe I am that unique. I'll google for PyRange_New in a couple of years to see how many more people got stranded. :-) Although it will bias the measure of my uniqueness, I still believe you should tell people in the documentation what to do, e.g. PyObject_CallFunction((PyObject*) &PyRange_Type, "lll", start, stop, step) which avoids showing the sloppy start+len*step hack. BTW: by the time my children pick up programming nobody under 30 will use C Python anymore. ;-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
On 6/22/06, Nick Maclaren <[EMAIL PROTECTED]> wrote: > > Not a lot. Annex F in itself is only numerically insane. You need to> > know the rest of the standard, including that which is documented only> > in SC22WG14 messages, to realise the full horror. [...]>Unfortunately, that doesn't help, because it is not where the issues>are. What I don't know is how much you know about numerical models,>IEEE 754 in particular, and C99. You weren't active on the SC22WG14 >reflector, but there were some lurkers.Hand wave, hand wave, hand wave. Many of us here aren't stupid and have more than passing experience with numerical issues, even if we haven't been "active on SC22WG14". Let's stop with the high-level pissing contest and lay out a clear technical description of exactly what has your knickers in a twist, how it hurts Python, and how we can all work together to make the pain go away. A good place to start: You mentioned earlier that there where some nonsensical things in floatobject.c. Can you list some of the most serious of these? Thanks,-Kevin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
Nick Maclaren <[EMAIL PROTECTED]> writes: >> > My intentions are to provide some numerically robust semantics, >> > preferably of the form where straightforward numeric code (i.e. code >> > that doesn't play any bit-twiddling tricks) will never invoke >> > mathematically undefined behaviour without it being flagged. See >> > Kahan on that. >> >> That doesn't actually explain the details of your intent very much. > > Let's try again. You say that you are a mathematician. I don't think I said that; I said I have a mathematics degree (I guess I'm a computer scientist, these days). > The standard floating-point model is that it maps functions defined > on the reals (sometimes complex) to approximations defined on > floating- point. The conventional interpretation was that any > operation that was not mathematically continuous in an open region > including its argument values (in the relevant domain) was an error, > and that all such errors should be flagged. That is what I am > talking about. It's all classic behaviour - nothing unusual. Well, I think you've used longer words than necessary, but thanks for the explanation. >> > Not a lot. Annex F in itself is only numerically insane. You need to >> > know the rest of the standard, including that which is documented only >> > in SC22WG14 messages, to realise the full horror. >> >> That's not why I was mentioning it. I was mentioning it to give the >> idea that I'm not a numerical expert but, for example, I know what a >> denorm is. > > Unfortunately, that doesn't help, because it is not where the issues > are. What I don't know is how much you know about numerical models, > IEEE 754 in particular, and C99. You weren't active on the SC22WG14 > reflector, but there were some lurkers. I'm in no way deeply enough involved to be reading that sort of email, which I would have thought would have been obvious from the other things I have said. >> >> This could be implemented by having a field in the threadstate of FPU >> >> flags to check after each fp operation (or each set of fp operations, >> >> possibly). I don't think I have the guts to try to implement >> >> anything sensible using HW traps (which are thread-local as well, >> >> aren't they?). >> > >> > Gods, NO!!! >> >> Good :-) > > ! I am sorry, but that isn't an appropriate response. Um, I think we've been misreading each other here. >> > Sorry, but I have implemented such things (but that was on a far >> > architecture, and besides the system is dead). Modern CPU >> > architectures don't even DEFINE whether interrupt handling is local >> > to the core or chip, and document that only in the release notes, >> > but what is clear is that some BLACK incantations are needed in >> > either case. >> >> Well, I only really know about the PowerPC at this level... > > Do you? Can you tell me whether interrupts stop the core or chip, > for each of the classes of interrupt, and exactly what the incantation > is for changing to the other mode? No. I've only played on single processor, single core machines. >> > Think of taking a machine check interrupt on a multi- core, >> > highly-pipelined architecture and blench. And, if that is an >> > Itanic, gibber hysterically before taking early retirement on the >> > grounds of impending insanity. >> >> What does a machine check interrupt have to do with anything? > > Because a machine check is one of the classes of interrupt that you > POSITIVELY want the other cores stopped until you have worked out > whether it impacts just the interrupted core or the CPU as a whole. > Inter alia, the PowerPC architecture takes one when a core has just > gone AWOL - and there is NO WAY that the dead core can handle the > interrupt indicating its own demise! But, a floating point exception isn't a machine check interrupt, it's a program interrupt... >> Now, a more general reply: what are you actually trying to acheive >> with these posts? I presume it's more than just make wild claims >> about how much more you know about numerical programming than anyone >> else... > > Sigh. What I am trying to get is floating-point support of the form > that, when a programmer makes a numerical error (see above), he gets > EITHER an exception value returned OR an exception raised. See, that wasn't so hard! We'd have saved a lot of heat and light if you'd said that at the start (and if you think you'd made it clear already: you hadn't). Cheers, mwh -- ... so the notion that it is meaningful to pass pointers to memory objects into which any random function may write random values without having a clue where they point, has _not_ been debunked as the sheer idiocy it really is.-- Erik Naggum, comp.lang.lisp ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
Nick Maclaren wrote: > Unfortunately, that doesn't help, because it is not where the issues > are. What I don't know is how much you know about numerical models, > IEEE 754 in particular, and C99. You weren't active on the SC22WG14 > reflector, but there were some lurkers. SC22WG14? is that some marketing academy? not a very good one, obviously. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
[Kevin Jacobs]
> ...
> A good place to start: You mentioned earlier that there where some
> nonsensical things in floatobject.c. Can you list some of the most serious
> of these?
I suspect Nick spends way too much time reading standards ;-) What he said is:
If you look at floatobject.c, you will find it solid with constructions that
make limited sense in C99 but next to no sense in C89.
And, in fact, C89 truly defines almost nothing about floating-point
semantics or pragmatics. Nevertheless, if a thing "works" under gcc
and under MS C, then "it works" for something like 99.9% of Python's
users, and competitive pressures are huge for other compiler vendors
to play along with those two.
I don't know what specifically Nick had in mind, and join the chorus
asking for specifics. I _expect_ he's got a keen eye for genuine
coding bugs here, but also expect I'd consider many technically
dubious bits of FP code to be fine under the "de facto standard"
dodge.
For an example much worse than anything in floatobject.c _could_ be, C
doesn't guarantee that an "int" can hold an integer larger than 32767.
I doubt Python would run _at all_ on a platform with 16-bit ints, and
the "de facto standard" Python actually tries to follow is that an int
holds at least 32 bits. Even more fundamental than that, we use
-fno-strict-aliasing under gcc because our C code is in fact in
undefined-behavior-land all over the place when casting between
PyObject* and pointers to objects of conceptual PyObject subclasses.
Because of the _way_ these casts are done, we're almost certainly in
no real trouble under any compiler, and the real reason we use
-fno-strict-aliasing under gcc is just to shut up the annoying warning
messages.
WRT floatobject.c, part of Python's assumed "de facto C standard" is
that no FP operation will raise SIGFPE, or cause "abnormal"
termination of the program by any other means. C89 doesn't say say
squat about that of any real use. C99 kinda does, sometimes, under
some conditions. The IEEE-754 standard mandates "no-stop mode" for
its default numeric environment, and Python effectively assumes that,
and _forces_ it on platforms where it's not the default. The only
known platform to date on which it was necessary to do so can be
deduced from Python's main() function:
int
main(int argc, char **argv)
{
...
#ifdef __FreeBSD__
fp_except_t m;
m = fpgetmask();
fpsetmask(m & ~FP_X_OFL);
#endif
return Py_Main(argc, argv);
}
So, sure, everything we do is undefined, but, no, we don't really care
:-) If a non-trivial 100%-guaranteed-by-the-standard-to-work C
program exists, I don't think I've seen it.
Changes in float behavior really have to go thru the numerical Python
users, because they have the largest stake. From that community, by
far the most frequent request | hear (even to the extent that people
seek me out at conferences and hint that they're willing to throw
money at it ;-)) is for a way to stop Python from raising
ZeroDivisionError on float divides. They may or may not be aware of
the dubious justifications for the no-stop results IEEE-754 mandates
for the various div-by-0 sub-cases, but they're eager to live with
them regardless. Even those who agree those "should be" errors (seems
to be a minority these days) would rather search result arrays for
NaNs and Infs after-the-fact than litter masses of array-syntax-driven
computation with hard-to-get-right recovery code. For a stupid
example, in
a = b / c
you may be dividing millions of array elements: do you really want to
throw away all the work you've done so far just because division
#1384923 divided by 0? "Yes" if you think the entire world is beyond
salvation if that happens, but that's rarely the case. When writing a
_scalar_ loop you generally don't mind catching exceptions, or even
doing
if c[i]:
a[i] = b[i] / c[i]
You can treat each computation specially, because you're only _doing_
one computation at a time. When computing with giant aggregates,
exceptions can be much harder to live with.
BTW, Nick, are you aware of Python's fpectl module? That's
user-contributed code that attempts to catch overflow, div-by-0, and
invalid operation on 754 boxes and transform them into raising a
Python-level FloatingPointError exception. Changes were made all over
the place to try to support this at the time. Every time you see a
PyFPE_START_PROTECT or PyFPE_END_PROTECT macro in Python's C code,
that's the system it's trying to play nicely with. "Normally", those
macros have empty expansions.
fpectl is no longer built by default, because repeated attempts failed
to locate any but "ya, I played with it once, I think" users, and the
masses of platform-specific #ifdef'ery in fpectlmodule.c were
suffering fatal bit-rot. No users + no maintainers means I expect
it's likely that module will go away in the foreseeable future. You'd
probably hate its _approach_ to this anyway ;-)
__
Re: [Python-Dev] Moving the ctypes repository to python.org
On 6/23/06, Thomas Heller <[EMAIL PROTECTED]> wrote: Is it possible to take the CVS repository files (they can be accessedwith rsync), and import that, preserving the whole history, into SVN?I don't remember a svn-specific tool for it (although I am fairly out of touch in that regard). However, if no one else comes up with a better alternative, I believe you could use 'tailor' to recreate the history in subversion. It'd do a checkin for every checkin in CVS, and take a while, so you'd probably want to test it in a private subversion tree, and run it 'for real' in a directory that won't generate checkins to python-checkins ;) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the ctypes repository to python.org
> I think the best would be to import it into an url like > > http://svn.python.org/projects/sandbox/trunk/ctypes/ > > Is it possible to take the CVS repository files (they can be accessed > with rsync), and import that, preserving the whole history, into SVN? It should be possible to use cvs2svn itself, creating a dump file, and loading that dump file into an existing repository with 'svnadmin load --parent-dir'. -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the ctypes repository to python.org
>> I think the best would be to import it into an url like >> >> http://svn.python.org/projects/sandbox/trunk/ctypes/ >> >> Is it possible to take the CVS repository files (they can be accessed >> with rsync), and import that, preserving the whole history, into SVN? > Gustavo Niemeyer schrieb: > It should be possible to use cvs2svn itself, creating a dump file, > and loading that dump file into an existing repository with > 'svnadmin load --parent-dir'. > Yes, that is what I'm experimenting with currently. One problem that occurs is the following. It seems that cvs2svn does not handle a branch correctly... Here is a partial output of 'cvs log _ctypes.c' running on the SF CVS repository: RCS file: /cvsroot/ctypes/ctypes/source/_ctypes.c,v Working file: _ctypes.c head: 1.340 branch: locks: strict access list: symbolic names: ... branch_1_0: 1.226.0.2 ... keyword substitution: kv total revisions: 431; selected revisions: 431 ... revision 1.307 date: 2006/03/03 20:17:15; author: theller; state: Exp; lines: +1373 -815 Moving files from branch_1_0 to HEAD. revision 1.306 date: 2006/03/03 19:47:24; author: theller; state: dead; lines: +0 -0 Remove all files, will add them from 'branch_1_0' again. revision 1.305 date: 2005/05/11 19:17:15; author: theller; state: Exp; lines: +7 -1 oops - patch was incomplete. revision 1.304 date: 2005/05/11 19:11:35; author: theller; state: Exp; lines: +24 -5 Don't call __init__, only __new__, when an ctypes object is retrieved from a base object. ... What I did was at a certain time develop in the 'branch_1_0' branch, leaving HEAD for experimental work. Later I decided that this was wrong, cvs removed all files in HEAD, and added them back from a branch_1_0 checkout. Maybe doing this was another bad idea, as the trunk in the converted SVN repository only lists _ctypes.c revisions corresponding to the CVS version numbers 1.307 up to the current CVS head 1.340. All the older versions from 1.1 up to 1.226.2.55 show up in the branch_1_0 branch that cvs2svn has created - although in CVS only the versions 1.226.0.2 up to 1.226.2.55 were ever in the branch_1_0 branch. Is that a bug in cvs2svnn? Oh well, maybe I deserve that - but 'cvs log' shows much more info the 'svn log' now (when running in the trunk checkout). Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > (1) An expression of the form 'static' has the semantics of > evaluating the atom at the same time as the nearest surrounding > function definition. If there is no surrounding function definition, > 'static' is a no-op and the expression is evaluated every time. > [Alternative 1: this is an error] [Alternative 2: it is evaluated > before the module is entered; this would imply it can not involve any > imported names but it can involve builtins] [Alternative 3: > precomputed the first time the switch is entered] I'm +1 on alternative 1, but -1 on all others, with a small caveat that I'll mark with * later on. > (2) All case expressions in a switch have an implied 'static'. +1 > (3) A switch is implemented using a dict which is precomputed at the > same time its static expressions are precomputed. The switch > expression must be hashable. Overlap between different cases will > raise an exception at precomputation time. +1 (As I was catching up on the flurry of emails from yesterday this morning, I noticed to my surprise that you came around to precisely what I had hoped for in a switch/case statement; I'm going to have to try not posting on a subject more often <.5 wink>) > Independent from this, I wonder if we also need static names of the form > > static = > > which would be similar to > >= static () > > but also prevents from being assigned to elsewhere in the same scope. * I don't particularly care for the literal syntax of static. I like the /idea/, but I don't believe that it is as useful as people think it is. Let me explain. Given your previously proposed 'all cases have an implied static', that handles the switch/case statement, the purpose of 'static' is to explain what happens to the switch/case statement, not that people would actually use it as such in the switch/case example (as it is implied, and people are insane about trying to reduce how much they type). For general variables, like say; math.pi, re.DOTALL, sys.maxint, len, int, Exception, etc., many of them are merely references to their values, that is, there are no value manipulations. This case is quite conveniently covered by Raymond's "Decorator for BindingConstants at compile time", a sexy decorator available in the cookbook [1]. That decorator can handle all of the non-modifying value assignments, and in the case of Frederick's previously described: if value < const (math.pi / 2): ... ... a small modification to Raymond's recipe that allows keyword arguments (on the decorator) would preserve the beauty of the function definition, at the cost of an uglier decorator. @make_constants(math_pi_2=(math.pi / 2)) def foo(value): if value < math_pi_2: ... Now, it's not as slick as a static unary operator, but it handles the simple references case quite well, and can be hacked to handle the saving of expressions without significant difficulty, though such uglifies the decorator call significantly. If a variant of that decorator were available in the standard library, maybe with simple variants, I believe much of the general talk about 'static' will go away. I could certainly be wrong, but that's ok too. > Also, I haven't heard a lot of thumbs up or down on the idea of using > > case X: > > to indicate a single value and > > case in S: > > to indicate a sequence of values. +1 > (I'm not counting all the hypergeneralizations that were proposed like > > case == X: > case < X: > case is X: > case isinstance X: > > since I'm -1 on all those, no matter how nicely they align. The 'case == X' was cute, though if it was an alternative spelling of 'case X', I doubt it would be used terribly often. Regardless, I'm -1 on all other cases, and would not be concerned to lose the '== X' version. - Josiah [1] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: ... > (1) An expression of the form 'static' has the semantics of > evaluating the atom at the same time as the nearest surrounding > function definition. If there is no surrounding function definition, > 'static' is a no-op and the expression is evaluated every time. > [Alternative 1: this is an error] [Alternative 2: it is evaluated > before the module is entered; this would imply it can not involve any > imported names but it can involve builtins] [Alternative 3: > precomputed the first time the switch is entered] +1, preferably with alternative 1. I've occasionally (ab)used the fact that default values are computed at def time to get similar semantics, but that (whence the "ab") has all sorts of issues (such as "exposing" arguments you really do NOT want to be passed). > (2) All case expressions in a switch have an implied 'static'. > > (3) A switch is implemented using a dict which is precomputed at the > same time its static expressions are precomputed. The switch > expression must be hashable. Overlap between different cases will > raise an exception at precomputation time. +0, just because I care about switch only up to a point!-) > Independent from this, I wonder if we also need static names of the form > > static = > > which would be similar to > >= static () > > but also prevents from being assigned to elsewhere in the same scope. Lovely!!! Definitely +1. Could perhaps THIS use of static be allowed even outside of a def? I'd just love to have such static names in modules and classes, too (with runtime checks of errant assignments, if needed). > Also, I haven't heard a lot of thumbs up or down on the idea of using > > case X: > > to indicate a single value and > > case in S: > > to indicate a sequence of values. > > (I'm not counting all the hypergeneralizations that were proposed like > > case == X: > case < X: > case is X: > case isinstance X: > > since I'm -1 on all those, no matter how nicely they align. Agreed on the generalizations, but allowing (just) "case == X" and "case in S" looks more readable to me than "case X" and "case in S". Since I'm not overly focused on switch/case anyway, _and_ this choice is just about syntax sugar anyway, my preference's mild!-) Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > > (1) An expression of the form 'static' has the semantics of > > evaluating the atom at the same time as the nearest surrounding > > function definition. If there is no surrounding function definition, > > 'static' is a no-op and the expression is evaluated every time. > > [Alternative 1: this is an error] [Alternative 2: it is evaluated > > before the module is entered; this would imply it can not involve any > > imported names but it can involve builtins] [Alternative 3: > > precomputed the first time the switch is entered] > > I'm +1 on alternative 1, but -1 on all others, with a small caveat that > I'll mark with * later on. I'm beginning to lean in that direction myself. A clean rule for switches would be that if it's not inside a function, the cases must be compile-time constant expressions. > > (2) All case expressions in a switch have an implied 'static'. > > +1 > > > (3) A switch is implemented using a dict which is precomputed at the > > same time its static expressions are precomputed. The switch > > expression must be hashable. Overlap between different cases will > > raise an exception at precomputation time. > > +1 (As I was catching up on the flurry of emails from yesterday this > morning, I noticed to my surprise that you came around to precisely what > I had hoped for in a switch/case statement; I'm going to have to try not > posting on a subject more often <.5 wink>) No kidding. There is such a thing as too much heat. I need to do this more often myself, too! > > Independent from this, I wonder if we also need static names of the form > > > > static = > > > > which would be similar to > > > >= static () > > > > but also prevents from being assigned to elsewhere in the same scope. > > * I don't particularly care for the literal syntax of static. What do you mean by "literal syntax of static"? Do you mean 'static' or 'static' '=' ? Or something else? > I like > the /idea/, but I don't believe that it is as useful as people think it > is. Let me explain. Given your previously proposed 'all cases have an > implied static', that handles the switch/case statement, the purpose of > 'static' is to explain what happens to the switch/case statement, not > that people would actually use it as such in the switch/case example (as > it is implied, and people are insane about trying to reduce how much > they type). I'm all for typing less if it makes things clearer for the reader. I'm not for reductions in what you type at the expense of readability. Often, reducing redundant boiler plate is of the first category, since the reader must just skip the boiler plate if it's explicitly typed. > For general variables, like say; math.pi, re.DOTALL, sys.maxint, len, > int, Exception, etc., many of them are merely references to their values, > that is, there are no value manipulations. This case is quite > conveniently covered by Raymond's "Decorator for BindingConstants at > compile time", a sexy decorator available in the cookbook [1]. That > decorator can handle all of the non-modifying value assignments, and in > the case of Frederick's previously described: But it is an absolutely yucky approach. It modifies byte code. That makes it break in future Python versions (Python's byte code is not standardized across versions), as well in Jython, IronPython, and sandboxed Python (which will make a come-back, see Brett's post). If it's as valuable as to let people devise the crap in that cookbook entry (no offense, I'm sure it's a great intellectual accomplishment, but it's fundamentally the wrong approach) then it's worth adding something to the language to do it right. As the cookbook discussion mentions, the decorator assumes that all globals are constant. That is way too implicit for me. (IOW, the existence of that cookbook entry proves to me that the language needs to support something like this explicitly.) > if value < const (math.pi / 2): > ... > > ... a small modification to Raymond's recipe that allows keyword > arguments (on the decorator) would preserve the beauty of the function > definition, at the cost of an uglier decorator. > > @make_constants(math_pi_2=(math.pi / 2)) > def foo(value): > if value < math_pi_2: > ... Realistically that would be way too verbose. Note how the string approximating math...pi...2 now occurs three times in the code where Fredrik's example had it only once! > Now, it's not as slick as a static unary operator, but it handles the > simple references case quite well, and can be hacked to handle the > saving of expressions without significant difficulty, though such > uglifies the decorator call significantly. If a variant of that > decorator were available in the standard library, maybe with simple > variants, I believe much of the general talk about 'static' will go away. > I could certainly be wrong
Re: [Python-Dev] Switch statement
On 6/23/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Independent from this, I wonder if we also need static names of the form > > > > static = > > > > which would be similar to > > > >= static () > > > > but also prevents from being assigned to elsewhere in the same scope. > > Lovely!!! Definitely +1. Could perhaps THIS use of static be allowed > even outside of a def? I'd just love to have such static names in > modules and classes, too (with runtime checks of errant assignments, > if needed). It would provide no speed advantage, and I don't see how the staticness would be transferred upon import into another module. Runtime checks of errant assignments would be relatively easy: trap this in the module setattr operation, and henceforth let module.__dict__ return a read-only dict wrapper. (Except that would break "exec E in globals()". I guess it would have to be a dict wrapper that only makes those specific keys read-only...) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
"Alex Martelli" <[EMAIL PROTECTED]> wrote: > On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Independent from this, I wonder if we also need static names of the form > > > > static = > > > > which would be similar to > > > >= static () > > > > but also prevents from being assigned to elsewhere in the same scope. > > Lovely!!! Definitely +1. Could perhaps THIS use of static be allowed > even outside of a def? I'd just love to have such static names in > modules and classes, too (with runtime checks of errant assignments, > if needed). The problem is that there would need to be a change to modules to be more class-like (read-only properties), as "module.foo = x" would need to raise an exception if foo was static in module. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Georg Brandl wrote: > M.-A. Lemburg wrote: > >> A nice side-effect would be that could easily use the >> same approach to replace the often used default-argument-hack, >> e.g. >> >> def fraction(x, int=int, float=float): >> return float(x) - int(x) >> >> This would then read: >> >> def fraction(x): >> const int, float >> return float(x) - int(x) > > There's a certain risk that the premature-optimization fraction will > plaster every function with const declarations, but they write > unreadable code anyway ;) > > Aside from this, there's still another point: assume you have quite a > number of module-level string "constants" which you want to use in a switch. > You'd have to repeat all of their names in a "const" declaration in order > to use them this way. If you want to use the switch-dispatch table optimization, yes. I'm sure we could find ways to make such declarations more user-friendly. E.g. to declare all symbols imported from a module constant: # Declare the name "module" constant: const module # Declare all references "module." constant: const module.* This would allow you to e.g. declare all builtins constant, avoiding cluttering up your code with const declarations, as in the above example. Note that such a declaration would go beyond just the use in a switch statement. It allows you to declare names reserved within the scope you are defining them in and gives them a special meaning - much like "global" does. Indeed, with this kind of declaration you wouldn't need to add the switch statement to benefit from the dispatch table optimization, since the compiler could easily identify an if-elif-else chain as being optimizable even if it uses symbols instead of literals for the values. Furthermore, the compiler could do other optimizations on the const declared names, such as optimizing away global lookups and turning them into code object constants lookups. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 23 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
[delurking in response to the first really decisive message in the thread] ;-) On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > (1) An expression of the form 'static' has the semantics of > evaluating the atom at the same time as the nearest surrounding > function definition. FWIW, +1. This is clear and useful. And code like the following could be fixed by simply adding a "static" before the "i", instead of adding default arguments:: funcs = [] for i in xrange(10): def f(): return i funcs.append(f) > If there is no surrounding function definition, > 'static' is a no-op and the expression is evaluated every time. > [Alternative 1: this is an error] +1 on the error. Function definition time doesn't really make sense for modules. Only +0 on allowing only compile-time constants, since it would be a little harder to explain. I guess you'd want to tell people something like "think of a module as being a function that is defined at compile time and called on import". > (2) All case expressions in a switch have an implied 'static'. +1. You already have to understand that switch statements are evaluated at function definition time, so the 'static' does seem a bit redundant. > (3) A switch is implemented using a dict which is precomputed at the > same time its static expressions are precomputed. The switch > expression must be hashable. Overlap between different cases will > raise an exception at precomputation time. +1. What a wonderful, simple explanation. =) > Independent from this, I wonder if we also need static names of the form > > static = > > which would be similar to > >= static () > > but also prevents from being assigned to elsewhere in the same scope. -0. I'm not sure how often this is really necessary. I'd rather see static expressions in Python 2.6, see how people use them, and then decide whether or not static names are also needed. > Also, I haven't heard a lot of thumbs up or down on the idea of using > > case X: > > to indicate a single value and > > case in S: > > to indicate a sequence of values. +1. This syntax seems pretty intuitive. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Reading on in the thread it seems that there's agreement on using "static" instead of "const", to s/const/static :-) M.-A. Lemburg wrote: > Georg Brandl wrote: >> M.-A. Lemburg wrote: >> >>> A nice side-effect would be that could easily use the >>> same approach to replace the often used default-argument-hack, >>> e.g. >>> >>> def fraction(x, int=int, float=float): >>> return float(x) - int(x) >>> >>> This would then read: >>> >>> def fraction(x): >>> const int, float >>> return float(x) - int(x) >> There's a certain risk that the premature-optimization fraction will >> plaster every function with const declarations, but they write >> unreadable code anyway ;) >> >> Aside from this, there's still another point: assume you have quite a >> number of module-level string "constants" which you want to use in a switch. >> You'd have to repeat all of their names in a "const" declaration in order >> to use them this way. > > If you want to use the switch-dispatch table optimization, yes. > > I'm sure we could find ways to make such declarations more > user-friendly. E.g. to declare all symbols imported from a > module constant: > > # Declare the name "module" constant: > const module > > # Declare all references "module." constant: > const module.* > > This would allow you to e.g. declare all builtins constant, > avoiding cluttering up your code with const declarations, > as in the above example. > > Note that such a declaration would go beyond just the use in > a switch statement. It allows you to declare names reserved > within the scope you are defining them in and gives them > a special meaning - much like "global" does. > > Indeed, with this kind of declaration you wouldn't need to > add the switch statement to benefit from the dispatch > table optimization, since the compiler could easily identify > an if-elif-else chain as being optimizable even if it uses > symbols instead of literals for the values. > > Furthermore, the compiler could do other optimizations on the > const declared names, such as optimizing away global lookups > and turning them into code object constants lookups. > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 23 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > (3) A switch is implemented using a dict which is precomputed at the > same time its static expressions are precomputed. The switch > expression must be hashable. Overlap between different cases will > raise an exception at precomputation time. How does this interact with __contains__, __len__, and __iter__ for the 'case in S' statement? Would it work with a class that only implements __contains__, such as a continuous range class? -- Eric Sumner ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > > > Independent from this, I wonder if we also need static names of the form > > > > > > static = > > > > > > which would be similar to > > > > > >= static () > > > > > > but also prevents from being assigned to elsewhere in the same > > > scope. > > > > * I don't particularly care for the literal syntax of static. > > What do you mean by "literal syntax of static"? Do you mean 'static' > or 'static' '=' ? Or something else? The existance of the static keyword and its use in general. You later stated that decorators were the wrong way of handling it. I believe that the... static = ...would require too many changes to what some regular python users have come to expect from at least module namespaces. I have nothing constructive to say about the function local case. I believe that static is generally fine for the... static ... case, whether it is prefixed with a ' =', or some other operation on the value. Allowing things like 'value < static (math.pi / 2)' brings up the question of where the calculated value of (math.pi / 2) will be stored. Presumably it would be stored in a function or module const table, and that is fine. But what does the operation: = static ...do? In a function namespace, do we calculate expression, assign it to the local on function definition and call it good? Or do we load the stored evaluated each pass through during runtime, making it effectively equivalent to: = I hope it's the latter (assign it to the local from a const table at the point of the ' = static ...' line). > > For general variables, like say; math.pi, re.DOTALL, sys.maxint, len, > > int, Exception, etc., many of them are merely references to their values, > > that is, there are no value manipulations. This case is quite > > conveniently covered by Raymond's "Decorator for BindingConstants at > > compile time", a sexy decorator available in the cookbook [1]. That > > decorator can handle all of the non-modifying value assignments, and in > > the case of Frederick's previously described: > > But it is an absolutely yucky approach. It modifies byte code. That > makes it break in future Python versions (Python's byte code is not > standardized across versions), as well in Jython, IronPython, and > sandboxed Python (which will make a come-back, see Brett's post). You make a good point. It really is only usable in particular CPython versions at any one time, though I am generally of a different opinion: if for some desired operation X you can get identical functionality and/or speed improvements during runtime without additional syntax, and it is easy to use, then there is no reason to change syntax. It seems that this particular operation can be cumbersome, is a maintenance nightmare, and isn't applicable to non-CPython, so it violates my reasons for 'shouldn't become syntax'. If it makes others happy, static is fine with me. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Numerical robustness, IEEE etc.
Nick Maclaren wrote: > The standard floating-point model is that it maps functions defined on > the reals (sometimes complex) to approximations defined on floating- > point. OK. > The conventional interpretation was that any operation that > was not mathematically continuous in an open region including its > argument values (in the relevant domain) was an error, and that all > such errors should be flagged. That is what I am talking about. Not a bad goal, but not worth sweating over, since it isn't sufficient. It still allows functions whose continuity does not extend to the next possible floating point approximation, or functions whose value, while continuous, changes "too much" in that region. > Unfortunately, that doesn't help, because it is not where the issues > are. What I don't know is how much you know about numerical models, > IEEE 754 in particular, and C99. You weren't active on the SC22WG14 For some uses, it is more important to be consistent with established practice than to be as correct as possible. If the issues are still problems, and can't be solved in languages like java, then ... the people who want "correct" behavior will be a tiny minority, and it makes sense to have them use a 3rd-party extension. > For example, consider conversion between float > and long - which class should control the semantics? The current python approach with binary fp is to inherit from C (consistency with established practice). The current python approach for Decimal (or custom classes) is to refuse to guess in the first place; people need to make an explicit conversion. How is this a problem? > they are unspecified - IDEALLY, things like floating-point > traps would be handled thread-locally ... but things like TLB > miss traps, device interrupts and machine-check interrupts > need to be CPU-global. Unfortunately, modern architectures > use a single mechanism for all of them That sounds like a serious problem for some combination of threading and trying to use hardware floating point at maximum efficiency. It does not sound like a problem for software implementations, like python's Decimal package. It *might* limit the gains that a portable C re-implementation could get, but if you need the absolute fastest and you need threads -- maybe that is again the domain of a 3rd-party extension. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
At 07:51 PM 6/23/2006 +0200, M.-A. Lemburg wrote: >Furthermore, the compiler could do other optimizations on the >const declared names, such as optimizing away global lookups >and turning them into code object constants lookups. Technically, they'd have to become LOAD_DEREF on cells set up by the module level code and attached to function objects. 'marshal' won't be able to save function references or other such objects to a .pyc file. It's interesting that this line of thinking does get us closer to the long-desired builtins optimization. I'm envisioning: static __builtin__.* or something like that. Hm. Maybe: from __builtin__ import static * :) In practice, however, this doesn't work for * imports unless it causes all global-scope names with no statically detectable assignments to become static. That could be a problem for modules that generate symbols dynamically, like 'opcode' in the stdlib. OTOH, maybe we could just have a LOAD_STATIC opcode that works like LOAD_DEREF but falls back to using globals if the cell is empty. Interestingly, a side effect of making names static is that they also become private and untouchable from outside the module. Hm. Did I miss something, or did we just solve builtin lookup optimization? The only problem I see is that currently you can stick a new version of 'len()' into a module from outside it, shadowing the builtin. Under this scheme (of making all read-only names in a module become closure variables), such an assignment would change the globals, but have no effect on the module's behavior, which would be tied to the static definitions created at import time. >-- >Marc-Andre Lemburg >eGenix.com > >Professional Python Services directly from the Source (#1, Jun 23 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 >[email protected] >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Eric Sumner <[EMAIL PROTECTED]> wrote:
> On 6/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > (3) A switch is implemented using a dict which is precomputed at the
> > same time its static expressions are precomputed. The switch
> > expression must be hashable. Overlap between different cases will
> > raise an exception at precomputation time.
>
> How does this interact with __contains__, __len__, and __iter__ for
> the 'case in S' statement? Would it work with a class that only
> implements __contains__, such as a continuous range class?
No; in order to make it possible to use a single dict lookup for
dispatch, the set members are expanded into the dict key. If you have
a large contiguous range, you'll be better off (sometimes *much*
better) doing an explicit if/elif check before entering the switch.
Let me sketch a prototype for the code that builds the dict given the cases:
def build_switch(cases, globals):
"""
Args:
cases: [(op, expr, offset), ...]
# op in ('==', 'in')
# expr is a string giving an expression
# offset is an integer offset where to jump for this case
globals: dict used as a namespace
"""
dispatch = {}
for op, expr, offset in cases:
value = eval(expr, globals)
switch op:
case '==':
if value in dispatch:
raise RuntimeError("duplicate switch case %r == %r" % (expr, value))
dispatch[value] = offset
case 'in':
for val in value:
if val in dispatch:
raise RuntimeError("duplicate switch case %r contains %r"
% (expr, val))
dispatch[val] = offset
return dispatch
Of course, the real implementation would not use eval() or represent
the expressions as strings or represent all the cases as a list; the
compiler would probably generate byte code corresponding to the body
of either of the above cases for each case in the switch being
compiled. The dispatch dicts would be passed into the function object
constructor somehow. Lots of details for whoever wants to implement
this. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > (3) A switch is implemented using a dict which is precomputed at the > > same time its static expressions are precomputed. The switch > > expression must be hashable. Overlap between different cases will > > raise an exception at precomputation time. > > +0 on switch/case, but -0.5 on a "in terms of implementation" rather > than "in terms of existing language constructs" approach. > > as I mentioned before, I'd prefer if the switch/case/case-in/else was > defined in terms of a corresponding if/elif/else construct (but where > the controlling expression is only evaluated once). > > after all, Python's a dynamic language, and I'm not convinced that I > would never want to use dynamically evaluated case values. just map > > switch EXPR: > case E1: > ... > case in E2: > ... > else: > ... > > to > > VAR = EXPR > if VAR == E1: > ... > elif VAR in E2: > ... > else: > ... > > where VAR is a temporary variable, and case and case-in clauses can be > freely mixed, and leave the rest to the code generator. (we could even > allow "switch EXPR [as VAR]" to match a certain other sugar construct). This used to be my position. I switched after considering the alternatives for what should happen if either the switch expression or one or more of the case expressions is unhashable. (Not to mention if one of them has a broken __hash__ method.) Unless all values are literals (or at least compile-time constant expressions involving only literals) the compiler can't know whether any particular switch could involve non-hashable values, and it would have to write code that catches exceptions from hashing and falls back to an if/elif chain implementation (unless you don't care at all about speedups). I don't think that static would help enough; static doesn't promise that the value is hashable. > I'm also a K&R guy, so switch/case/case-in/else should all have the same > indent. anything else is just sloppy design. I'm on the fence about the exact syntax. I see four alternatives: we can use case or not, and we can indent it or not. The only weird thing about not indenting the cases is that python-mode.el and all other IDEs would have be taught that the line following switch ...: should not be indented. But all things considered I'm probably most in favor of unindented cases using the case keyword; working at Google has taught me that indentation levels are a precious resource, and I'm slightly uncomfortable with not having an explicit case keyword in the light of coding errors involving typos or misindents. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > You later stated that decorators were the wrong way of handling it. I > believe that the... > static = > ...would require too many changes to what some regular python users have > come to expect from at least module namespaces. I have nothing > constructive to say about the function local case. It looks like "static NAME = EXPR" is still pretty controversial. "NAME = static EXPR" seems to be getting universal +1s OTOH. > Allowing things like 'value < static (math.pi / 2)' brings up the > question of where the calculated value of (math.pi / 2) will be stored. > Presumably it would be stored in a function or module const table, and > that is fine. A new category of data stored on the function object, computed at function def time. It would be an array and there would be a new opcode to load values in this array in O(1) time. > But what does the operation: > = static > ...do? In a function namespace, do we calculate expression, assign it > to the local on function definition and call it good? That would be impossible; the local namespace doesn't exist when the function object is created (except for the cells used to reference variables in outer function scopes). > Or do we > load the stored evaluated each pass through during runtime, > making it effectively equivalent to: > = > I hope it's the latter (assign it to the local from a const table at the > point of the ' = static ...' line). Yes, the latter should be good enough. [On Raymond's optimizing decorator] > You make a good point. It really is only usable in particular CPython > versions at any one time, though I am generally of a different opinion: > if for some desired operation X you can get identical functionality > and/or speed improvements during runtime without additional syntax, and > it is easy to use, then there is no reason to change syntax. There problem with hacks like that decorator is that if it misbehaves (e.g. you have a global that sometimes is reassigned) you end up debugging really hairy code. The semantics aren't 100% clear. I'm all for telling people "you can do that yourself" or even "here is a standard library module that solves your problem". But the solution needs to satisfy a certain cleanliness standard. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Python is a beautiful simple language with a rich standard library. Python has done fine without a switch statement up to now. Guido left it out of the original language for some reason (my guess is simplicity). Why is it needed now? What would be added next: do while or goto? The urge to add syntax should be resisted unless there is a high payoff (such as yield). There are much better ways for the developers to spend their time and energy (refactoring os comes to mind). Please keep Python simple. -1 on the switch statement. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
Ralf W. Grosse-Kunstleve wrote: >>> Is there a way to set the warning options via an environment variable? >> This is off-topic for python-dev, > > What is the channel I should use? (I am testing a beta 1.) The specific question was "Is there a way to set the warning options via an environment variable?" This has nothing to do with beta1; the warnings module was introduced many releases ago, along with all the mechanics to disable warnings. >> but: why don't switch off the warnings >> in the code? > > We support installation from sources with the native Python if available. Any > Python >= 2.2.1 works. It would be frustrating if we had to give up on this > just because of a warning designed for newcomers. I guess you misunderstood. I propose you put warnings.simplefilter() into your code. The warnings was introduced before 2.2.1 IIRC, so this should work on all releases you want to support (but have no effect on installations where the warning isn't generated). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Hm. Did I miss something, or did we just solve builtin lookup > optimization? The only problem I see is that currently you can stick a new > version of 'len()' into a module from outside it, shadowing the > builtin. Under this scheme (of making all read-only names in a module > become closure variables), such an assignment would change the globals, but > have no effect on the module's behavior, which would be tied to the static > definitions created at import time. Or we could arrange for such assignments to be dynamically illegal. We could have some provision whereby any name that's known to the compiler to be a built-in, and for which the compiler can't see an explicit assignment, is implicitly made static. This would make it a run-time error if "import *" were to redefine such a name. The module object would have to know which names are static and disallow assignments to these. It would also have to export __dict__ as a proxy that disallows such assignments. I think it can be made to work. I do think this would require static names as well as static expressions. This is definitely still in the brainstorm phase! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Switch statement
In http://mail.python.org/pipermail/python-dev/2006-June/066399.html, PJE wrote: >> Python prefers to evaluate expressions in the order that they >> appear in source code, ... "first-time use" preserves that >> property; "function definition time" does not. Guido wrote: > But first-time has the very big disadvantage IMO that there's no > safeguard to warn you that the value is different on a subsequent > execution -- you just get the old value without warning. That is true either way, and is already true with computed default arguments. The only difference is that your mental model has even longer to become inconsistent. (The time between definition and first use.) First time use also lets you use a constant (such as a dotted name from another module) that may not yet be defined when the function is defined, but will be defined before the function is used. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the ctypes repository to python.org
Thomas Heller wrote: > What I did was at a certain time develop in the 'branch_1_0' branch, leaving > HEAD for experimental work. Later I decided that this was wrong, cvs removed > all > files in HEAD, and added them back from a branch_1_0 checkout. Maybe doing > this was another bad idea, as the trunk in the converted SVN repository > only lists _ctypes.c revisions corresponding to the CVS version numbers > 1.307 up to the current CVS head 1.340. All the older versions from 1.1 up to > 1.226.2.55 show up in the branch_1_0 branch that cvs2svn has created - > although > in CVS only the versions 1.226.0.2 up to 1.226.2.55 were ever in the > branch_1_0 > branch. Is that a bug in cvs2svnn? I doubt it. I'm pretty sure the subversion repository *does* contain all the old files, in the old revisions. What happens if you do the following on your converted subversion repository: 1. find out the oldest version of the files from svn log. Say this is version 1000. 2. Explicitly check out the trunk at version 950 (i.e. some plenty revisions before your copied the files from the branch). I expect that this will give you the files just before you deleted them; doing "svn log" on this sandbox will then give you all the old log messages and versions. If that is what happens, here is why: "svn log" will trace a file through all its revisions, and across "svn copy"s, back to when it was added into the repository. At that point, "svn log" stops. An earlier file with the same name which got removed is considered as a different file, so "svn log" does not show its revisions. If you don't want that do happen, you could try to "outdate" (cvs -o) the deletion and readdition in CVS, purging that piece of history. I'm not entirely certain whether this should work. If that isn't what happens, I'd be curious to look at the CVS and SVN tarballs. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Switch statement
In http://mail.python.org/pipermail/python-dev/2006-June/066409.html,
Guido wrote
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition.
(A) I prefer a term other than 'static'.
Looking at various contexts in just C, C++, and Java, I have seen
static used to imply (at least) each of private, global, singleton,
class-level, and constant.
This suggested usage sounds more like a cross between "auxiliary
variable in a Lisp lambda form" and "compile-time defined constant".
(B) I would prefer semantics closer to Java's final variables: by
declaring something final, you would be promising that the next
expression can be treated as though it were a literal constant.
Python will evaluate it at least once after the "final" keyword but
before it gets used; anything more than that should be up to the
implementation.
The only advantage I see of specifying the time more tightly is that
people could use things that really aren't constant, iff they get the
timing right.
In http://mail.python.org/pipermail/python-dev/2006-June/066432.html,
Steven Bethard posted a fix for the "I-didn't-want-a-closure" problem
that uses this -- but realistically, people would still be burned by
unexpected closures just as often as they are today; the only benefit
is that the correct workaround is cleaner.
First time use has more compelling use cases, but I'm not sure they're
compelling enough.
(C) Yes, I realize that you prefer to freeze only objects (the
results of expressions), and weren't sure about the form which also
froze the name. But realistically, if a "final" name is rebound, that
is probably an error worth flagging. I do realize that this gets into
a wider issue about how to seal a namespace.
> If there is no surrounding function definition,
> 'static' is a no-op and the expression is evaluated every time.
uhm ... OK ... so why even allow it at all? Just for consistency with
the implied static of a case statement, even though it won't mean the
same thing?
> [Alternative 1: this is an error]
OK, but ...
Things like re.DOTALL should also be final; things like
urlparse.uses_relative should not. It seems a shame to spend a
keyword saying "treat this as constant" and still not be able to do so
with module-level globals.
> [Alternative 2: it is evaluated before the module is entered;
> this would imply it can not involve any imported names but it can
> involve builtins]
And parsing must take at least one more pass, and static still better
not appear inside an if statement, and ...
> [Alternative 3: precomputed the first time the switch is entered]
OK, though it will be anti-efficient compared to bailing out when you
hit a match.
Alternative 4: computed at some point after discovering it is final,
but before using it. For case expressions, this would be after
starting to compute the switch dictionary, but before executing
anything in the suite of this or a later alternative.
> (2) All case expressions in a switch have an implied 'static'.
Good. But again, I would prefer that the names also be frozen, so
that people won't expect that they can change the clauses; using a
variable in a clause should be fine, but rebinding that name later
(within the same persistent scope) is at best misleading.
> (3) A switch is implemented using a dict which is precomputed at the
> same time its static expressions are precomputed. The switch
> expression must be hashable. Overlap between different cases will
> raise an exception at precomputation time.
Again, I'm not sure it makes sense to specify the time. Any
specification will cause the following to be well-defined, but someone
will be surprised at any particular result. My best guess is that it
your proposal would catch ("A1", "B1", "C1", "D2")
a="A1"
b="B1"
c="C1"
d="D1"
def f(v):
if sys.version_info > (2, 5, 0, "", 0):
a="A2"
else:
a="A3"
b = static "B2"
c = "C2"
static d = "D2"
switch v:
case in (a, b, c, d): ...
I'm not convinced that we should forbid building the dictionary as
needed, so that it may not contain the last several cases until it
gets an input that doesn't match earlier cases. (Though I do see the
argument for raising an Exception as early as possible if there are
conflicts.)
-jJ
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > In http://mail.python.org/pipermail/python-dev/2006-June/066399.html, PJE > wrote: > >> Python prefers to evaluate expressions in the order that they > >> appear in source code, ... "first-time use" preserves that > >> property; "function definition time" does not. > > Guido wrote: > > But first-time has the very big disadvantage IMO that there's no > > safeguard to warn you that the value is different on a subsequent > > execution -- you just get the old value without warning. > > That is true either way, and is already true with computed default > arguments. The only difference is that your mental model has even > longer to become inconsistent. (The time between definition and first > use.) > > First time use also lets you use a constant (such as a dotted name > from another module) that may not yet be defined when the function is > defined, but will be defined before the function is used. I should probably just pronounce on this; I'm not going to change my mind, so def-time-freeze it is (if we do this at all). Ditto for static inside a function (if we do that at all). Static and switch outside a function are still somewhat open; I'm currently leaning towards making static expressions outside a function illegal and limit switches outside a function to compile-time-constant expressions. Here are a few examples showing my objections against first-use. def foo(c): def bar(x): switch x: case c: print 42 else: print 0 return bar p = foo(1) p(1) # prints 42 q = foo(2) q(2) # does this print 42 or 0? I think q(2) should print 42; otherwise it's not clear what object should be used to hold the frozen switch dict; it can't be the code object since code objects need to be immutable and cannot have any variable state. But then the def time enters into it anyway... Another example is this: def foo(c, x): switch x: case c: print 42 else: print 0 Should this be allowed? The first-use rule has no strong motivation to forbid it, since *knowing* the first-rule it's reasonable to expect that *any* case expression will just be evalluated in the local scope at the first use of the switch. But it's just begging for confusion if the reader isn't clued in to the first-use rule. The def-time rule simply forbids this; any switch you're likely to write with the def-time rule is almost certain to use only global and imported variables that are constants in the user's mind. With the def-time rule, you'd have to work a lot harder to construct an example that works differently than the casual reader would expect. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
This post is too long for me to respond right now. I'm inviting others
to respond. I've got a feeling you're coming late to this discussion
and we're going around in circles.
--Guido
On 6/23/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> In http://mail.python.org/pipermail/python-dev/2006-June/066409.html,
> Guido wrote
>
> > (1) An expression of the form 'static' has the semantics of
> > evaluating the atom at the same time as the nearest surrounding
> > function definition.
>
> (A) I prefer a term other than 'static'.
>
> Looking at various contexts in just C, C++, and Java, I have seen
> static used to imply (at least) each of private, global, singleton,
> class-level, and constant.
>
> This suggested usage sounds more like a cross between "auxiliary
> variable in a Lisp lambda form" and "compile-time defined constant".
>
> (B) I would prefer semantics closer to Java's final variables: by
> declaring something final, you would be promising that the next
> expression can be treated as though it were a literal constant.
> Python will evaluate it at least once after the "final" keyword but
> before it gets used; anything more than that should be up to the
> implementation.
>
> The only advantage I see of specifying the time more tightly is that
> people could use things that really aren't constant, iff they get the
> timing right.
>
> In http://mail.python.org/pipermail/python-dev/2006-June/066432.html,
> Steven Bethard posted a fix for the "I-didn't-want-a-closure" problem
> that uses this -- but realistically, people would still be burned by
> unexpected closures just as often as they are today; the only benefit
> is that the correct workaround is cleaner.
>
> First time use has more compelling use cases, but I'm not sure they're
> compelling enough.
>
> (C) Yes, I realize that you prefer to freeze only objects (the
> results of expressions), and weren't sure about the form which also
> froze the name. But realistically, if a "final" name is rebound, that
> is probably an error worth flagging. I do realize that this gets into
> a wider issue about how to seal a namespace.
>
> > If there is no surrounding function definition,
> > 'static' is a no-op and the expression is evaluated every time.
>
> uhm ... OK ... so why even allow it at all? Just for consistency with
> the implied static of a case statement, even though it won't mean the
> same thing?
>
> > [Alternative 1: this is an error]
>
> OK, but ...
>
> Things like re.DOTALL should also be final; things like
> urlparse.uses_relative should not. It seems a shame to spend a
> keyword saying "treat this as constant" and still not be able to do so
> with module-level globals.
>
> > [Alternative 2: it is evaluated before the module is entered;
> > this would imply it can not involve any imported names but it can
> > involve builtins]
>
> And parsing must take at least one more pass, and static still better
> not appear inside an if statement, and ...
>
> > [Alternative 3: precomputed the first time the switch is entered]
>
> OK, though it will be anti-efficient compared to bailing out when you
> hit a match.
>
> Alternative 4: computed at some point after discovering it is final,
> but before using it. For case expressions, this would be after
> starting to compute the switch dictionary, but before executing
> anything in the suite of this or a later alternative.
>
> > (2) All case expressions in a switch have an implied 'static'.
>
> Good. But again, I would prefer that the names also be frozen, so
> that people won't expect that they can change the clauses; using a
> variable in a clause should be fine, but rebinding that name later
> (within the same persistent scope) is at best misleading.
>
> > (3) A switch is implemented using a dict which is precomputed at the
> > same time its static expressions are precomputed. The switch
> > expression must be hashable. Overlap between different cases will
> > raise an exception at precomputation time.
>
> Again, I'm not sure it makes sense to specify the time. Any
> specification will cause the following to be well-defined, but someone
> will be surprised at any particular result. My best guess is that it
> your proposal would catch ("A1", "B1", "C1", "D2")
>
> a="A1"
> b="B1"
> c="C1"
> d="D1"
> def f(v):
> if sys.version_info > (2, 5, 0, "", 0):
> a="A2"
> else:
> a="A3"
> b = static "B2"
> c = "C2"
> static d = "D2"
> switch v:
> case in (a, b, c, d): ...
>
> I'm not convinced that we should forbid building the dictionary as
> needed, so that it may not contain the last several cases until it
> gets an input that doesn't match earlier cases. (Though I do see the
> argument for raising an Exception as early as possible if there are
> conflicts.)
>
> -jJ
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/pyth
Re: [Python-Dev] Switch statement
On Fri, 2006-06-23 at 16:16 -0400, Edward C. Jones wrote: > Please keep Python simple. +1 on this sentiment. I use switch statements all the time in C, but I'd rather not see them in Python - even though I'd use them if they were there! - purely to keep the cognitive overhead low. 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/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Here are a few examples showing my objections against first-use. [Problem with nested scopes; today this usually shows up as (invalid) bug reports about lambda, in which failure to bind a "default" variable "to itself" causes it to take on the value at the end of the loop, instead of the value of the index when defined.] [Problem with using a parameter as a case selector -- at least these aren't available at definition time.] > With the def-time rule, you'd have to work a lot harder to construct > an example that works differently than the casual reader would expect. Anything which use the same names in the local scope, particularly if those names are themselves marked final (or static). a=1 b=2 c=3 def f(v): a=4# This gets ignored? final b=5# But what about this? It is local, but a constant known in advance switch v: case in (a, b, c): ... final c=6# Also a constant, but textually after the case keyword. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> No; in order to make it possible to use a single dict lookup for
> dispatch, the set members are expanded into the dict key. If you have
> a large contiguous range, you'll be better off (sometimes *much*
> better) doing an explicit if/elif check before entering the switch.
In that case, I would argue that the proposed syntax is misleading.
Regardless of how it is implemented, a switch statement is
conceptually a chain of if/elif statements. As such, the 'in'
keyword, if it is allowed at all, should behave like it does in if
statements, rather than it does in loops. If, for implementation
reasons, you want to ensure that all of the sets are enumerable, I
would recommend a syntax like this:
"case" ["*"] expression ("," ["*"] expression)* ":" suite
This is consistent with parameter lists, which emphasizes that the
sequences are being enumerated instead of simply tested against.
-- Eric Sumner
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On Fri, 23 Jun 2006 13:38:35 -0700, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote: >On Fri, 2006-06-23 at 16:16 -0400, Edward C. Jones wrote: > >> Please keep Python simple. > >+1 on this sentiment. > I agree. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyRange_New() alternative?
Ralf W. Grosse-Kunstleve wrote: > Thanks! This does the trick for me: > > #if PY_VERSION_HEX >= 0x0203 > PyObject_CallFunction( > (PyObject*) &PyRange_Type, "lll", start, start+len*step, step) > #else > PyRange_New(start, len, step, 1) > #endif > > I am compiling the code above with a C++ compiler (in the context of > Boost.Python). Newer g++ versions unfortunatly produce a warning if -Wall is > specified: > > warning: dereferencing type-punned pointer will break strict-aliasing rules I am not sure about your compiler, but if I remember the standard correctly, the following code shouldn't complain: PyObject_CallFunction((PyObject*) (void *) &PyRange_Type, "lll", start, start+len*step, step) -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
"Eric Sumner" <[EMAIL PROTECTED]> wrote:
>
> On 6/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > No; in order to make it possible to use a single dict lookup for
> > dispatch, the set members are expanded into the dict key. If you have
> > a large contiguous range, you'll be better off (sometimes *much*
> > better) doing an explicit if/elif check before entering the switch.
>
> In that case, I would argue that the proposed syntax is misleading.
> Regardless of how it is implemented, a switch statement is
> conceptually a chain of if/elif statements. As such, the 'in'
> keyword, if it is allowed at all, should behave like it does in if
> statements, rather than it does in loops. If, for implementation
> reasons, you want to ensure that all of the sets are enumerable, I
> would recommend a syntax like this:
>
>"case" ["*"] expression ("," ["*"] expression)* ":" suite
>
> This is consistent with parameter lists, which emphasizes that the
> sequences are being enumerated instead of simply tested against.
You apparently missed the post where Guido expressed that he believes
that one of the valid motivators for the switch statement and the
dict-based dispatching was for that of speed improvements. He also
already stated that cases could essentially only be examples for which
Python does pre-computation and the storing of constants (he didn't use
those words, and there are caveats with regards to module.attr and
global 'constants', but that was the gist I got from it).
As such, because any explicit range object is neither dict-accessable as
the values in the range would be, nor are they generally precomputed (or
precomputable) as constants (like (1,2,3) is and 1+1 should be), your
particular use-case (range objects that may implement __contains__ fast,
but whose __iter__ returns a huge number of values if it were
implemented as such) is not covered under switch/case, and we would
likely point you back off to if/elif/else.
This is a good thing, because if switch/case ends up functionally
identical to if/elif/else, then it has no purpose as a construct. On
the other hand, because it is different from if/elif/else, and it is
different in such a way to make certain blocks of code (arguably) easier
to read or understand, (likely provably) faster, then it actually has a
purpose and use.
- Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > This is a good thing, because if switch/case ends up functionally > identical to if/elif/else, then it has no purpose as a construct. On > the other hand, because it is different from if/elif/else, and it is > different in such a way to make certain blocks of code (arguably) easier > to read or understand, (likely provably) faster, then it actually has a > purpose and use. Excellent formulation! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On Jun 22, 2006, at 3:24 PM, Phillip J. Eby wrote: > Well, you can't "def" a dotted name, but I realize this isn't a > binding. I have actually wanted to do that before. It would be nice if you could. :) James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
> > In that case, I would argue that the proposed syntax is misleading.
> > Regardless of how it is implemented, a switch statement is
> > conceptually a chain of if/elif statements. As such, the 'in'
> > keyword, if it is allowed at all, should behave like it does in if
> > statements, rather than it does in loops. If, for implementation
> > reasons, you want to ensure that all of the sets are enumerable, I
> > would recommend a syntax like this:
> >
> >"case" ["*"] expression ("," ["*"] expression)* ":" suite
> >
> > This is consistent with parameter lists, which emphasizes that the
> > sequences are being enumerated instead of simply tested against.
>
> You apparently missed the post where Guido expressed that he believes
> that one of the valid motivators for the switch statement and the
> dict-based dispatching was for that of speed improvements. He also
> already stated that cases could essentially only be examples for which
> Python does pre-computation and the storing of constants (he didn't use
> those words, and there are caveats with regards to module.attr and
> global 'constants', but that was the gist I got from it).
I admit that I came into this discussion in the middle, and my initial
post was for informational (to me) purposes only. I did not mean to
imply by that post that the proposal was flawed in any way, just to
verify that I properly understood the proposal. I am sorry if I was
unclear about this.
> As such, because any explicit range object is neither dict-accessable as
> the values in the range would be, nor are they generally precomputed (or
> precomputable) as constants (like (1,2,3) is and 1+1 should be), your
> particular use-case (range objects that may implement __contains__ fast,
> but whose __iter__ returns a huge number of values if it were
> implemented as such) is not covered under switch/case, and we would
> likely point you back off to if/elif/else.
I concur. I actually suspected as much prior to my original message
on this topic, but I wanted to make sure I was understanding things
correctly before attempting to make a suggestion.
> This is a good thing, because if switch/case ends up functionally
> identical to if/elif/else, then it has no purpose as a construct. On
> the other hand, because it is different from if/elif/else, and it is
> different in such a way to make certain blocks of code (arguably) easier
> to read or understand, (likely provably) faster, then it actually has a
> purpose and use.
Again, I concur. My point was not that the mechanics of the construct
were incorrect, but that the proposed syntax misrepresented its
function. Again, I am sorry if I was unclear about this.
-- Eric Sumner
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Moving the ctypes repository to python.org
Thomas Heller wrote: > Is it possible to take the CVS repository files (they can be accessed > with rsync), and import that, preserving the whole history, into SVN? Yes: http://cvs2svn.tigris.org/ You just need a maintainer of the Python SVN repository to load the dump files this tool generates. -- Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
Fredrik Lundh wrote: > Nick Maclaren wrote: > >> Unfortunately, that doesn't help, because it is not where the issues >> are. What I don't know is how much you know about numerical models, >> IEEE 754 in particular, and C99. You weren't active on the SC22WG14 >> reflector, but there were some lurkers. > > SC22WG14? is that some marketing academy? not a very good one, obviously. http://www.open-std.org/jtc1/sc22/wg14/ Looks like python-dev for C, only with extra servings of international bureaucracy and vendor self-interest to make life more complicated ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> SC22WG14? is that some marketing academy? not a very good one, >> obviously. > > http://www.open-std.org/jtc1/sc22/wg14/ > > Looks like python-dev for C, only with extra servings of international > bureaucracy and vendor self-interest to make life more complicated ;) Of interest among their C-EPs is one for adding the equivalent of our decimal module http://www.open-std.org/jtc1/sc22/wg14/www/projects#24732 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote:
> That sounds like a good solution all around. I hope that others can
> also find themselves in this.
>
> (1) An expression of the form 'static' has the semantics of
> evaluating the atom at the same time as the nearest surrounding
> function definition. If there is no surrounding function definition,
> 'static' is a no-op and the expression is evaluated every time.
> [Alternative 1: this is an error] [Alternative 2: it is evaluated
> before the module is entered; this would imply it can not involve any
> imported names but it can involve builtins] [Alternative 3:
> precomputed the first time the switch is entered]
I'm thinking that outside of a function, 'static' just means that the
expression is evaluated at compile-time, with whatever symbols the
compiler has access to (including any previously-defined statics in that
module). The result of the expression is then inserted into the module
code just like any literal.
So for example:
a = static len( "1234" )
compiles as:
a = 4
...assuming that you can call 'len' at compile time.
The rationale here is that I'm trying to create an analogy between
functions and modules, where the 'static' declaration has an analogous
relationship to a module as it does to a function. Since a module is
'defined' when its code is compiled, that would be when the evaluation
occurs.
I'm tempted to propose a way for the compiler to import static
definitions from outside the module ('static import'?) however I
recognize that this would greatly increase the fragility of Python,
since now you have the possibility that a module could be compiled with
a set of numeric constants that are out of date with respect to some
other module.
-- Talin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
Guido van Rossum wrote: > On 6/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Talin wrote: >> > I don't get what the problem is here. A switch constant should have >> > exactly the bahavior of a default value of a function parameter. We >> > don't seem to have too many problems defining functions at the module >> > level, do we? >> >> Because in function definitions, if you put them inside another >> function, the >> defaults of the inner function get reevaluated every time the outer >> function >> is run. Doing that for the switch statement would kinda defeat the whole >> point. . . > > Really? Then where would you store the dict? You can't store it on the > code object because that's immutable. You can't store it on the > function object (if you don't want it to be re-evaluated when the > function is redefined) because a new function object is created by > each redefinition. There needs to be *some* kind of object with a > well-defined life cycle where to store the dict. > > I'd say that we should just add a warning against switches in nested > functions that are called only once per definition. I wasn't very clear. . . Talin noted that there's no ambiguity with the timing of the evaluation of default function arguments, regardless of whether the function definition is at module scope or inside another function - the default arguments are simply evaluated every time the function definition is executed. So he wondered why that simplicity didn't translate to the evaluation of switch cases. With a switch statement, we want the cases evaluated when the *containing* def statement is executed, not every time the switch statement itself is executed. Which makes things far more complex :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Numerical robustness, IEEE etc.
[/F] > SC22WG14? is that some marketing academy? not a very good one, obviously. That's because it's European ;-) The ISO standards process has highly visible layers of bureaucracy, and, in full, JTC1/SC22/WG14 is just the Joint ISO/IEC Technical Committee 1's SubCommittee 22's Working Group 14 . JTC1 is in charge of information technology standards; JTC1/SC22 "programming languages, their environments and system software interfaces"; and JTC1/SC22/WG14 the C programming language. POSIX lives right next door in TC/SC/WG space, at JTC1/SC22/WG15. IOW, these are the friendly folks who define what C is. In America, it's usually just called "the ANSI C committee" instead, probably for the same reason Americans prefer intuitive names like "mile" and "gallon" over puffed up technical gibberish like "metre" and "litre" ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyRange_New() alternative?
--- Scott David Daniels <[EMAIL PROTECTED]> wrote: > Ralf W. Grosse-Kunstleve wrote: > > Thanks! This does the trick for me: > > > > #if PY_VERSION_HEX >= 0x0203 > > PyObject_CallFunction( > > (PyObject*) &PyRange_Type, "lll", start, start+len*step, step) > > #else > > PyRange_New(start, len, step, 1) > > #endif > > > > I am compiling the code above with a C++ compiler (in the context of > > Boost.Python). Newer g++ versions unfortunatly produce a warning if -Wall > is > > specified: > > > > warning: dereferencing type-punned pointer will break strict-aliasing rules > > I am not sure about your compiler, but if I remember the standard > correctly, the following code shouldn't complain: > > PyObject_CallFunction((PyObject*) (void *) &PyRange_Type, > "lll", start, start+len*step, step) Thanks for the suggestion! I just tried: g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) g++ (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) g++ (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8) with -Wall -Wno-sign-compare. These compilers don't issue the "will break strict-aliasing rules" warning with or without the intermediate (void *). However, I also tried: g++ (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3) which issues the warning without the (void *), but not with the (void *). I am not an expert of the C/C++ language details, but the intermediate cast seems to be a great local alternative to the global -fno-strict-aliasing flag. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
--- "Martin v. L�wis" <[EMAIL PROTECTED]> wrote: > The specific question was > > "Is there a way to set the warning options via an environment variable?" > > This has nothing to do with beta1; the warnings module was introduced > many releases ago, along with all the mechanics to disable warnings. Due to the new ImportWarning first introduced in 2.5b1 the question of disabling warnings is becoming much more pressing (I am assuming that I am not again the only person on the planet to have this problem). > I guess you misunderstood. Yes. > I propose you put warnings.simplefilter() > into your code. The warnings was introduced before 2.2.1 IIRC, so this > should work on all releases you want to support (but have no effect on > installations where the warning isn't generated). Where would I put the warnings.simplefilter()? I have hundreds of scripts and __init__.py files. I just came accross this situation (simplified): % cd boost/boost % python2.5 >>> import math __main__:1: ImportWarning: Not importing directory 'math': missing __init__.py This is because there is a subdirectory math in boost/boost, something that I cannot change. The PYTHONPATH is not set at all in this case. I.e. I get the ImportWarning just because my current working directory happens to contain a subdirectory which matches one of the Python modules in the standard library. Isn't this going to cause widespread problems? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
