Re: [Python-Dev] PyRange_New() alternative?

--- Bob Ippolito <[EMAIL PROTECTED]> wrote: > > I am sure I can get this to work with some digging, but I am > > posting here to > > highlight a communication problem. I feel if a function is removed the > > alternative should be made obvious in the associated documentation; in > > particular if

Re: [Python-Dev] Numerical robustness, IEEE etc.

On 6/22/06, Aahz <[EMAIL PROTECTED]> wrote: > On Thu, Jun 22, 2006, Nick Maclaren wrote: > > > > 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 raise

Re: [Python-Dev] Switch statement

On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:54 PM 6/22/2006 -0700, Guido van Rossum wrote: > >Summarizing our disagreement, I think you feel that > >freeze-on-first-use is most easily explained and understood while I > >feel that freeze-at-def-time is more robust. I'm not sure how

Re: [Python-Dev] Numerical robustness, IEEE etc.

On Thu, Jun 22, 2006, Nick Maclaren wrote: > > 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. Then you need to write up a detailed design docu

Re: [Python-Dev] Numerical robustness, IEEE etc.

2006/6/22, Nick Maclaren <[EMAIL PROTECTED]>: > > 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 tryin

Re: [Python-Dev] PyRange_New() alternative?

--- Georg Brandl <[EMAIL PROTECTED]> wrote: > Well, PyRange_New *was* undocumented, Yes, that was clear. > However, it would perhaps be helpful to add a note to the whatsnew document > for users like yourself. Andrew, does that make sense? I am worried about using an alternative that is *again*

Re: [Python-Dev] Numerical robustness, IEEE etc.

Michael Hudson <[EMAIL PROTECTED]> wrote: > > Maybe append " for me, at least" to what I wrote then. But really, it > is hard: because Python runs on so many platforms, and platforms that > no current Python developer has access to. If you're talking about > implementing FP in software (are you?

Re: [Python-Dev] Numerical robustness, IEEE etc.

Very interesting. I need to investigate in more depth. > The work-in-progress can be seen in Python's SVN sandbox: > > http://svn.python.org/view/sandbox/trunk/decimal-c/ beelzebub$svn checkout http://svn.python.org/view/sandbox/trunk/decimal-c/ svn: PROPFIND request failed on '/view/sandbox/tru

Re: [Python-Dev] Switch statement

At 12:54 PM 6/22/2006 -0700, Guido van Rossum wrote: >Summarizing our disagreement, I think you feel that >freeze-on-first-use is most easily explained and understood while I >feel that freeze-at-def-time is more robust. I'm not sure how to get >past this point except by stating that you haven't co

Re: [Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9(Panther)

Ronald Oussoren schrieb: > > On Wednesday, June 21, 2006, at 09:43AM, Thomas Heller <[EMAIL PROTECTED]> > wrote: > >>Ronald Oussoren schrieb: will have a look. >>> >>> It is a platform bug, RTLD_LOCAL doesn't work on 10.3. The following C >>> snippet fails with the same error as ctypes:

Re: [Python-Dev] Switch statement

At 12:24 PM 6/22/2006 -0700, Guido van Rossum wrote: >OK, I think I see how this works. You pre-compute the expression at >def-time, squirrel it away in a hidden field on the function object, >and assign it to a local each time the statement is executed. More precisely, I'd say that the computatio

Re: [Python-Dev] Switch statement

On 6/22/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Wed, 21 Jun 2006, Guido van Rossum wrote: > > (Note how I've switched to the switch-for-efficiency camp, since it > > seems better to have clear semantics and a clear reason for the syntax > > to be different from if/elif chains.) > > I don't

Re: [Python-Dev] Switch statement

On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > >>[Phillip] > >>1. "case (literal|NAME)" is the syntax for equality testing -- you can't > >>use an arbitrary expression, not even a dotted name. > >[Guido] > >But dotted names are important! E.g. case re.DOTALL. And sometimes > >compile-time

Re: [Python-Dev] Switch statement

On Wed, 21 Jun 2006, Guido van Rossum wrote: > (Note how I've switched to the switch-for-efficiency camp, since it > seems better to have clear semantics and a clear reason for the syntax > to be different from if/elif chains.) I don't think switch-for-efficiency (at least if efficiency is the pri

Re: [Python-Dev] Switch statement

Fredrik Lundh wrote: > I'm not sure it should, actually -- the primary form is more flexible, > and it better matches how things work: it's the expression that's > special, not the variable. > > and things like > > radian = degree * static (math.pi / 180) > > would be pretty nice, for th

Re: [Python-Dev] Switch statement

At 11:52 AM 6/22/2006 -0700, Guido van Rossum wrote: >On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >>I think one of the problems I sometimes have in communicating with you is >>that I think out stuff from top to bottom of an email, and sometimes >>discard working assumptions once they're n

Re: [Python-Dev] Switch statement

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 >

Re: [Python-Dev] Switch statement

On 6/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > It's not magic if it can be explained. "def goes over all the cases > > and evaluates them in the surrounding scope and freezes the meaning of > > the cases that way as long as the function object survives" is not >

Re: [Python-Dev] PyRange_New() alternative?

On Jun 22, 2006, at 11:55 AM, Ralf W. Grosse-Kunstleve wrote: > --- Georg Brandl <[EMAIL PROTECTED]> wrote: > >> Ralf W. Grosse-Kunstleve wrote: >>> http://docs.python.org/dev/whatsnew/ports.html says: >>> >>> The PyRange_New() function was removed. It was never >>> documented, never >> used

Re: [Python-Dev] PyRange_New() alternative?

Ralf W. Grosse-Kunstleve wrote: > --- Georg Brandl <[EMAIL PROTECTED]> wrote: > >> Ralf W. Grosse-Kunstleve wrote: >> > http://docs.python.org/dev/whatsnew/ports.html says: >> > >> > The PyRange_New() function was removed. It was never documented, never >> used >> > in the core code, and had da

Re: [Python-Dev] test_ctypes failure on Mac OS X/PowerPC 10.3.9 (Panther)

Ronald Oussoren schrieb: > On 20-jun-2006, at 20:50, Ronald Oussoren wrote: > >> >> On 20-jun-2006, at 20:06, Thomas Heller wrote: >> >>> Trent Mick schrieb: Thomas and others, Has anyone else seen failures in test_ctypes on older Mac OS X/ PowerPC? Results are below. This

Re: [Python-Dev] Switch statement

On Wed, 21 Jun 2006, Guido van Rossum wrote: > I worry (a bit) about this case: > > y = 12 > def foo(x, y): > switch x: > case y: print "something" > > which to the untrained observer (I care about untrained readers much > more than about untrained writers!) looks like it would print >

Re: [Python-Dev] Switch statement

Guido van Rossum wrote: >> well, I find the proposed magic behaviour of "case" at least as confusing... > > It's not magic if it can be explained. "def goes over all the cases > and evaluates them in the surrounding scope and freezes the meaning of > the cases that way as long as the function obj

Re: [Python-Dev] PyRange_New() alternative?

--- Georg Brandl <[EMAIL PROTECTED]> wrote: > Ralf W. Grosse-Kunstleve wrote: > > http://docs.python.org/dev/whatsnew/ports.html says: > > > > The PyRange_New() function was removed. It was never documented, never > used > > in the core code, and had dangerously lax error checking. > > > > I u

Re: [Python-Dev] Switch statement

Guido van Rossum wrote: > Without const declarations none of this can work and > the "at-function-definition-time" freezing is the best, because most > predictable, approach IMO. I you like this approach best, then how about using the same approach as we have for function default argument values:

Re: [Python-Dev] Switch statement

On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I think one of the problems I sometimes have in communicating with you is > that I think out stuff from top to bottom of an email, and sometimes > discard working assumptions once they're no longer needed. We then end up > having arguments ov

Re: [Python-Dev] Switch statement

On 6/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > So the constant would be evaluated at function definition time? I find > > that rather confusing. > > well, I find the proposed magic behaviour of "case" at least as confusing... It's not magic if it can be explaine

Re: [Python-Dev] Switch statement

I think one of the problems I sometimes have in communicating with you is that I think out stuff from top to bottom of an email, and sometimes discard working assumptions once they're no longer needed. We then end up having arguments over ideas I already discarded, because you find the problem

Re: [Python-Dev] Switch statement

Guido van Rossum wrote: >> def foo(value): >> const bar = fie.fum >> if value == bar: >>... >> >> which would behave like >> >> def foo(value, bar=fie.fum): >> if value == bar: >> ... >> >> but without the "what if we pass in more than one

Re: [Python-Dev] Switch statement

On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:37 AM 6/22/2006 -0700, Guido van Rossum wrote: > >On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > This hypothetical "const" would be a *statement*, > > > executed like any other statement. It binds a name to a value -- and >

Re: [Python-Dev] Switch statement

On 6/22/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On 6/22/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > >> Guido van Rossum wrote: > >> > >> >> I've also been wondering whether the 'case' keyword is really necessary? > >> >> Would any ambiguities or other parsing p

Re: [Python-Dev] Switch statement

At 09:37 AM 6/22/2006 -0700, Guido van Rossum wrote: >On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > This hypothetical "const" would be a *statement*, > > executed like any other statement. It binds a name to a value -- and > > produces an error if the value changes. The compiler doesn

Re: [Python-Dev] Switch statement

Guido van Rossum wrote: > On 6/22/06, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> >> >> I've also been wondering whether the 'case' keyword is really necessary? >> >> Would any ambiguities or other parsing problems arise if you wrote: >> >> >> >> switch x: >> >>

Re: [Python-Dev] Switch statement

On 6/22/06, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > >> I've also been wondering whether the 'case' keyword is really necessary? > >> Would any ambiguities or other parsing problems arise if you wrote: > >> > >> switch x: > >> 1: foo(x) > >> 2: b

Re: [Python-Dev] Switch statement

On 6/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > a "constant" (or perhaps better, "const") primary would also be useful > in several other cases, including: > > - as a replacement for default-argument object binding > > - local dispatch tables, and other generated-but-static data structures >

Re: [Python-Dev] Switch statement

On 6/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > This hypothetical "const" would be a *statement*, > executed like any other statement. It binds a name to a value -- and > produces an error if the value changes. The compiler doesn't need to know > what it evaluates to at runtime; that's wh

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/22/06, Gerhard Häring <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> On 6/22/06, *Gerhard Häring* <[EMAIL PROTECTED] [EMAIL PROTECTED]>> wrote:>> Brett Cannon wrote: >  > I have been working on a design doc for restricted execution of> Python>  > [...]>> All the rest of th

Re: [Python-Dev] Switch statement

Guido van Rossum wrote: >> which simply means that expr will be evaluated at function definition >> time, rather than at runtime. example usage: >> >> var = expression >> if var == constant sre.FOO: >> ... >> elif var == constant sre.BAR: >> ... >> elif var i

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > On 6/22/06, *Gerhard Häring* <[EMAIL PROTECTED] > > wrote: > > Brett Cannon wrote: > > I have been working on a design doc for restricted execution of > Python > > [...] > > All the rest of the API made sense to me, but I coul

Re: [Python-Dev] Switch statement

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

Re: [Python-Dev] Switch statement

On 6/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > > switch x: > > case == 1: foo(x) > > Aesthetically, I don't like that. Me neither. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-

Re: [Python-Dev] Switch statement

On 6/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 01:16 PM 6/21/2006 -0700, Guido van Rossum wrote: > >Yeah, but if you have names for your constants it would be a shame if > >you couldn't use them because they happen to be defined in the same > >scope. > > Maybe the real answer is to have

Re: [Python-Dev] Switch statement

Guido van Rossum wrote: >> I've also been wondering whether the 'case' keyword is really necessary? >> Would any ambiguities or other parsing problems arise if you wrote: >> >> switch x: >> 1: foo(x) >> 2: bar(x) >> >> It is debatable whether this is more or less readable,

Re: [Python-Dev] Switch statement

On 6/22/06, Roger Miller <[EMAIL PROTECTED]> wrote: > Part of the readability advantage of a switch over an if/elif chain is > the semantic parallelism, which would make me question mixing different > tests in the same switch. What if the operator moved into the switch > header? > > switch x

Re: [Python-Dev] Allow assignments in 'global' statements?

On 6/21/06, Talin <[EMAIL PROTECTED]> wrote: > I'm sure I am not the first person to say this, but how about: > > global x = 12 > > (In other words, declare a global and assign a value to it - or another > way of saying it is that the 'global' keyword acts as an assignment > modifier.) -1. If

Re: [Python-Dev] doc for new restricted execution design for Python

On 6/22/06, Gerhard Häring <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> I have been working on a design doc for restricted execution of Python> [...]All the rest of the API made sense to me, but I couldn't understand whyPyXXX_MemoryFree is needed. How could memory usage possibly fall below 0?It

Re: [Python-Dev] Switch statement

At 01:08 PM 6/22/2006 +0200, M.-A. Lemburg wrote: >Phillip J. Eby wrote: > > Maybe the real answer is to have a "const" declaration, not necessarily > the > > way that Fredrik suggested, but a way to pre-declare constants e.g.: > > > > const FOO = 27 > > > > And then require case expressions

Re: [Python-Dev] ImportWarning flood

On Wed, Jun 21, 2006 at 10:34:53PM -0700, Ralf W. Grosse-Kunstleve wrote: > But this doesn't: > python -W'ignore:Not importing directory:ImportWarning' This is a bug. I've filed bug #1510580 and assigned it to Brett. I think the problem was exposed by the new-style exception change, but the actu

Re: [Python-Dev] Switch statement

Phillip J. Eby wrote: > Maybe the real answer is to have a "const" declaration, not necessarily the > way that Fredrik suggested, but a way to pre-declare constants e.g.: > > const FOO = 27 > > And then require case expressions to be either literals or constants. The > constants need not

Re: [Python-Dev] Switch statement

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 insid

Re: [Python-Dev] Numerical robustness, IEEE etc.

Michael Hudson wrote: > I get the impression that you would like to see floatobject.c > rewritten to make little or no use of the FPU, is that right? Also, > you seem to have an alternate model for floating point calculations in > mind, but seem very reluctant to actually explain what this is. >

Re: [Python-Dev] Numerical robustness, IEEE etc.

Nick Maclaren <[EMAIL PROTECTED]> writes: > Michael Hudson <[EMAIL PROTECTED]> wrote: >> >> This mail never appeared on python-dev as far as I can tell, so I'm >> not snipping anything. > > And it still hasn't :-( I am on the list of recipients without posting > rights, and the moderator appear

Re: [Python-Dev] Switch statement

Phillip J. Eby wrote: > switch x: > case == 1: foo(x) Aesthetically, I don't like that. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mail

Re: [Python-Dev] ImportWarning flood

--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > 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.) > but: why don't switch off the warnings

Re: [Python-Dev] doc for new restricted execution design for Python

Brett Cannon wrote: > I have been working on a design doc for restricted execution of Python > [...] All the rest of the API made sense to me, but I couldn't understand why PyXXX_MemoryFree is needed. How could memory usage possibly fall below 0? -- Gerhard _

Re: [Python-Dev] Switch statement

Ka-Ping Yee wrote: > Hmm, this is rather nice. I can imagine possible use cases for > >switch x: >case > 3: foo(x) >case is y: spam(x) >case == z: eggs(x) Part of the readability advantage of a switch over an if/elif chain is the semantic parallelism, which woul

Re: [Python-Dev] Allow assignments in 'global' statements?

Talin <[EMAIL PROTECTED]> wrote: > > I'm sure I am not the first person to say this, but how about: > > global x = 12 > > (In other words, declare a global and assign a value to it - or another > way of saying it is that the 'global' keyword acts as an assignment > modifier.) If we allow

Re: [Python-Dev] Switch statement

Fredrik Lundh wrote: > Q: If a program calls the 'func' function below as 'func()' > and ONE and TWO are both integer objects, what does 'func' ^^ Nothing at all, because you didn't call it! -- Greg ___