Re: [Python-Dev] Switch statement

[Greg Ewing]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Josiah Carlson]

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 that, then we necessarily need to allow:

global x, y, z = 12, 13, 14

... while I have also thought to myself 'it would be really nice to be
able to assign to a global when I declare a value to be global', it has
usually been a case of early optimization for me.  I don't really know
how I feel about either example above, I'd probably be +0.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Roger Miller]

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 would make me question mixing different 
tests in the same switch.  What if the operator moved into the switch 
header?

 switch x ==:
 case 1: foo(x)
case 2, 3: bar(x)

 switch x in:
case (1, 3, 5): do_odd(x)
case (2, 4, 6): do_even(x)

"switch x:" could be equivalent to "switch x ==:", for the common case.

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, but it seemed 
like an interesting question for the language lawyers.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Gerhard Häring]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ImportWarning flood

[Ralf W. Grosse-Kunstleve]

--- "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
> 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.

In our applications we typically address this type of problem with informative
exceptions. For example, if a Boost.Python wrapped C++ object doesn't support
pickling:

  RuntimeError: Pickling of "cctbx_sgtbx_ext.space_group_symbols" instances is
not enabled (http://www.boost.org/libs/python/doc/v2/pickle.html)

Something like this could help newcomers just the same without impacting
experienced users with large, complex package structures. E.g.:

>>> import mypackage.foo
Traceback (most recent call last):
  File "", line 1, in ?
ImportError: No module named mypackage.foo
Note that subdirectories are searched for imports only if they contain an
__init__.py file: http://www.python.org/doc/essays/packages.html


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Greg Ewing]

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/mailman/options/python-dev/archive%40mail-archive.com

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

[Michael Hudson]

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 appears to be on holiday.

They've appeared now, it seems the moderator is back :-)

>> But I wouldn't characterize anything Python does in the floating  
>> point area as "designed", particularly.  Portability makes that hard.
>
> Not really.  We managed even back in the 1970s, when there was a LOT
> more variation.  Writing code that would work, unchanged, on an IBM 360,
> an ICL 1900 and a CDC 6600 was, er, interesting 

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?), then I guess it gets easier.

>> Well, if you can't explain what your intentions are to *me*, as a  
>> mathematics-degree holding core Python developer that has done at  
>> least some work in this area, I posit that you aren't going to get  
>> very far.
>
> 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.

>> I'm not intimately familiar with the standards like 754 but I have  
>> some idea what they contain, and I've read appendix F of C99, if that  
>> helps you target your explanations.
>
> 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.

>> Why does it need to be program global?  In my not-really-thought-out  
>> plans for straightening out CPython's floating point story I had  
>> envisioned code to be written something like this:
> 
> No, you are thinking at too low a level.

Well, I was just trying to get you to actually explain your intent :-)

> The problem with such things is that they related to the interfaces
> between types, and it is those aspects where object-orientation
> falls down so badly.  For example, consider conversion between float
> and long - which class should control the semantics?

This comment seems not to relate to anything I said, or at least not
obviously.

>> 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 :-)

> 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...

> 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?

> Oh, that's the calm, moderate description.  The reality is worse.

Yes, but fortunately irrelevant...

>> > Secondly, for things that don't need to be brings
>> > up my point of adding methods to a built-in class.
>> 
>> This isn't very hard, really, in fact float has class methods in 2.5...
>
> Thanks.  I will look, but remember this is being done at the C level.

So is my code.

>> >> I'm interested in making Python's floating point story better, and
>> >> have worked on a few things for Python 2.5 -- such as
>> >> pickling/marshalling of special values -- but I'm not really a
>> >> numerical programmer and don't like to guess what they need.
>> >
>> > Ah.  I must get a snapshot, then.  That was one of the lesser things
>> > on my list.
>> 
>> It was fairly straightforward, and still caused portability problems...
>
> Now, why did I predict that?  Did you, by any chance, include
> System/390 and VAX support in your code :-)

God no, it was just mundane stuff like SIZEOF_FLOAT not being defined
on windows.

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 m

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

[Nick Coghlan]

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.
> 
> I think you should probably write a PEP.

I suggest using PEP 327 as a starting point, though. A few of the issues 
Cowlishaw talks about in the General Decimal Arithmetic spec are specific to 
hardware implementations, sure, but it doesn't appear to involve anything 
numerically insane (granted, they've added exp, ln and log10 to the spec since 
PEP 327 was implemented. . .).

The only downside I know of when it comes to trying to do serious number 
crunching with the current decimal implementation is the loss of raw speed 
relative to hardware floating point, and Mateusz is working on improving that 
situation.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Nick Coghlan]

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. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[M.-A. Lemburg]

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 be computable at compile time, just runtime.  If a 
> constant is defined using a foldable expression (e.g. FOO = 27 + 43), then 
> the compiler can always optimize it down to a code level 
> constant.  Otherwise, it can just put constants into cells that the 
> functions use as part of their closure.  (For that matter, the switch 
> statement jump tables, if any, can be put in a cell too.)
> 
>> I don't like "first use" because it seems to invite tricks.
> 
> Okay, then I think we need a way to declare a global as being constant.  It 
> seems like all the big problems with switch/case basically amount to us 
> trying to wiggle around the need to explicitly declare constants.

I don't think that this would help us much:

If you want the compiler to "see" that a name binds to a constant,
it would need to have access to the actual value at compile time
(e.g. code object definition time).

However, it is common practice to put constants which you'd use
in e.g. parsers into a separate module and you certainly don't
want to have the compiler import the module and apply attribute
lookups.

This means that you'd have to declare a symbol constant in the
scope where you want to use it as such. Which would result in
long sections of e.g.

const case1
const case2
...
const caseN

In the end, making this implicit in the case part of the switch
statement would save us a lot of typing.

However, there's another catch: if we do allow arbitrary expressions
in the case parts we still need to evaluate them at some point:

a. If we do so at compile time, the results may be a lot different
than at execution time (e.g. say you use time.time() in one of the
case value expressions).

b. If we evaluate them at code object execution time (e.g. module
import), then we'd run into similar problems, but at least
the compiler wouldn't have to have access to the used symbols.

c. If we evaluate at first-use time, results of the evaluation
become unpredictable and you'd also lose a lot of the
speedup since building the hash table would consume cycles
that you'd rather spend on doing other things.

d. Ideally, you'd want to create the hash table at compile time
and this is only possible using literals or by telling the
compiler to regard a specific set of globals as constant, e.g.
by passing a dictionary (mapping globals to values) to compile().

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 22 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/

2006-07-03: EuroPython 2006, CERN, Switzerland  10 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ImportWarning flood

[A.M. Kuchling]

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 actual bug is in warnings.py; the check for a legal category is
wrong.

> Also, the magic incantation to silence the warnings would be very helpful 
> here:

Good idea; I'll add it.

You could add the following to your site.py or your .pythonrc.py:

warnings.filterwarnings('ignore', 'Not importing directory', ImportWarning)

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Phillip J. Eby]

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 to be either literals or constants.  The
> > constants need not be computable at compile time, just runtime.  If a
> > constant is defined using a foldable expression (e.g. FOO = 27 + 43), then
> > the compiler can always optimize it down to a code level
> > constant.  Otherwise, it can just put constants into cells that the
> > functions use as part of their closure.  (For that matter, the switch
> > statement jump tables, if any, can be put in a cell too.)
> >
> >> I don't like "first use" because it seems to invite tricks.
> >
> > Okay, then I think we need a way to declare a global as being 
> constant.  It
> > seems like all the big problems with switch/case basically amount to us
> > trying to wiggle around the need to explicitly declare constants.
>
>I don't think that this would help us much:
>
>If you want the compiler to "see" that a name binds to a constant,
>it would need to have access to the actual value at compile time
>(e.g. code object definition time).

No, it wouldn't.  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 what LOAD_NAME or LOAD_DEREF are 
for.  ;)


>However, it is common practice to put constants which you'd use
>in e.g. parsers into a separate module and you certainly don't
>want to have the compiler import the module and apply attribute
>lookups.

Not necessary, but I see it does produce a different problem.


>This means that you'd have to declare a symbol constant in the
>scope where you want to use it as such. Which would result in
>long sections of e.g.
>
>const case1
>const case2
>...
>const caseN

Actually, under my proposal it'd be:

const FOO = somemodule.FOO
const BAR = somemodule.BAR

etc.  Which is probably actually worse.  But I see your point.


>In the end, making this implicit in the case part of the switch
>statement would save us a lot of typing.
>
>However, there's another catch: if we do allow arbitrary expressions
>in the case parts we still need to evaluate them at some point:
>
>a. If we do so at compile time, the results may be a lot different
>than at execution time (e.g. say you use time.time() in one of the
>case value expressions).

We can't do that at compile time.

>b. If we evaluate them at code object execution time (e.g. module
>import), then we'd run into similar problems, but at least
>the compiler wouldn't have to have access to the used symbols.
>
>c. If we evaluate at first-use time, results of the evaluation
>become unpredictable and you'd also lose a lot of the
>speedup since building the hash table would consume cycles
>that you'd rather spend on doing other things.

Assuming that a sequential search takes 1/2N equality tests on average, 
you'll come out ahead by the third switch executions, assuming that the 
time to add a dictionary entry or do a hash lookup is roughly equal to an 
if/else test.  The first execution would put N entries in the dictionary, 
and do 1 lookup.  The second execution does 1 lookup, so we're now at N+2 
operations, vs N operations on average for sequential search.  At the third 
execution, we're at N+3 vs. 2.5N, so for more than 6 entries we're already 
ahead.


>d. Ideally, you'd want to create the hash table at compile time
>and this is only possible using literals or by telling the
>compiler to regard a specific set of globals as constant, e.g.
>by passing a dictionary (mapping globals to values) to compile().

I still think that it suffices to assume that an expression produced using 
only symbols that aren't rebound are sufficiently static for use in a case 
expression.  If a symbol is bound by a single import statement (or other 
definition), or isn't bound at all (e.g. it's a builtin), it's easy enough 
to assume that it's going to remain the same.

Combine that compile-time restriction with a first-use build of the 
dictionary, and I think you have the best that we can hope to do in 
balancing implementation simplicity with usefulness and 
non-confusingness.  If it's not good enough, it's not good enough, but I 
don't think there's anything we've thought of so far that comes out with a 
better set of tradeoffs.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 can't in real life, but people could call MemoryFree() too many times.  Plus you need some way to lower the amount when memory is freed.  No need to penalize a script that does a bunch of malloc/free calls compared to one that just does a bunch of malloc calls.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 you get this feeling, surely you're overusing global.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 ==:
>  case 1: foo(x)
> case 2, 3: bar(x)
>
>  switch x in:
> case (1, 3, 5): do_odd(x)
> case (2, 4, 6): do_even(x)
>
> "switch x:" could be equivalent to "switch x ==:", for the common case.

That's difficult (I mean impossible) for Python's parser, since x ==
is also the legal start of an expression.

> 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, but it seemed
> like an interesting question for the language lawyers.

That's no problem for the parser, as long as the expressions are
indented. ABC did this.

But I think I like an explicit case keyword better; it gives a better
error message if the indentation is forgotten.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Georg Brandl]

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, but it seemed
>> like an interesting question for the language lawyers.
> 
> That's no problem for the parser, as long as the expressions are
> indented. ABC did this.
> 
> But I think I like an explicit case keyword better; it gives a better
> error message if the indentation is forgotten.

It also overthrows the notion that suites are started by statements, not
by expressions.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 a "const" declaration, not necessarily the
> way that Fredrik suggested, but a way to pre-declare constants e.g.:
>
>  const FOO = 27

The problem with this is that I don't see how to export this property
from one module to another. If module A has the above statement and
module B does "from A import FOO" then how does the parser know that
FOO is a constant when it's parsing B? (Remeber the parser only sees
one module at a time; I don't want to drop this separate compilation
facility.) It seems you would still end up with lots of duplicate
const declarations (e.g. "from A import const FOO"). And it should
also be possible to say "import A" and then use "A.FOO" as a constant.

I really don't think this ad-hoc solution is going to work.

> And then require case expressions to be either literals or constants.  The
> constants need not be computable at compile time, just runtime.  If a
> constant is defined using a foldable expression (e.g. FOO = 27 + 43), then
> the compiler can always optimize it down to a code level
> constant.  Otherwise, it can just put constants into cells that the
> functions use as part of their closure.  (For that matter, the switch
> statement jump tables, if any, can be put in a cell too.)
>
> >I don't like "first use" because it seems to invite tricks.
>
> Okay, then I think we need a way to declare a global as being constant.  It
> seems like all the big problems with switch/case basically amount to us
> trying to wiggle around the need to explicitly declare constants.

And I don't believe declaring constants is going to work; not without
a much bigger change to the language and the way we think about it.
This is because "const-ness" isn't a property that you can encode as a
new type of object. It is a compile-time property of *names*. The only
similar thing in Python is globals. But global declarations are
intentionally a bit clunky because we believe overuse of the feature
would be a mistake. But we wouldn't want to discourage constant
declaration if we had them, so having to repeat the 'constant' keyword
in every module that uses a particular constant would be a painful
wart.

Is your objection purely based on the problems of getting switch to
behave the same way inside and outside a function? I'd rather forbid
or cripple switch outside functions than either add constant
declarations or switch to first-use semantics.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Gerhard Häring]

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 couldn't understand why
> 
> PyXXX_MemoryFree
> 
> is needed. How could memory usage possibly fall below 0?
> 
> It can't in real life, but people could call MemoryFree() too many 
> times.  Plus you need some way to lower the amount when memory is 
> freed.  No need to penalize a script that does a bunch of malloc/free 
> calls compared to one that just does a bunch of malloc calls.

But if you want to limit the amount of memory a Python interpreter can 
use, wouldn't you have to integrate that resource checking into the 
standard Alloc/Dealloc functions instead of only enforcing the resource 
limit when some new API functions are called?

Existing extension modules and existing C code in the Python interpreter 
have no idea of any PyXXX_ calls, so I don't understand how new API 
functions help here.

-- Gerhard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Fredrik Lundh]

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 in constant (sre.FIE, sre.FUM):
>>  ...
> 
> This gets pretty repetitive. One might suggest that 'case' could imply
> 'constant'...?

possibly, but I find that a tad too magic for my taste.

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

- explicit (but still anonymous) constant/expression "folding"

an alternative would be to add a const declaration that can only be used 
in local scopes; i.e.

 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 argument?" issue.

yet another alternative would be a const declaration that you could use 
on a global level, but I fail to see how you could propagate the "const- 
ness" property to whoever wants to use a const object -- unless, of 
course, you implement

 const bar = fie.fum

 def foo(value):
if value == bar:
   ...

as

 class constant_wrapper(object):
 def __init__(self, value):
 self.value = value

 bar = constant_wrapper(fie.fum)

 def foo(value, bar=bar.value):
 if value == bar:
 ...

(except for the default argument thing; see above).  the result is a 
kind of semi-constant objects that would be useful, but perhaps not 
constant enough...)

it might be too much C# exposure, but I think I prefer the "explicit 
when using" approach...



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 the API made sense to me, but I couldn't understand why
>> PyXXX_MemoryFree>> is needed. How could memory usage possibly fall below 0?>> It can't in real life, but people could call MemoryFree() too many> times.  Plus you need some way to lower the amount when memory is
> freed.  No need to penalize a script that does a bunch of malloc/free> calls compared to one that just does a bunch of malloc calls.But if you want to limit the amount of memory a Python interpreter can
use, wouldn't you have to integrate that resource checking into thestandard Alloc/Dealloc functions instead of only enforcing the resourcelimit when some new API functions are called?Yep.  That API will be used directly in the changes to pymalloc and PyMem_*() macros (or at least the basic idea).  It is not *only* for extension modules but for the core as well.
Existing extension modules and existing C code in the Python interpreterhave no idea of any PyXXX_ calls, so I don't understand how new API
functions help here.The calls get added to pymalloc and PyMem_*() under the hood, so that existing extension modules use the memory check automatically without a change.  The calls are just there in case some one has some random need to do their own malloc but still want to participate in the cap.  Plus it helped me think everything through by giving everything I would need to change internally an API.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 what LOAD_NAME or LOAD_DEREF are
> for.  ;)

Please think this through more. How do you implement the "produces an
error if the value changes" part? Is the const property you're
thinking of part of the name or of the object it refers to?

The only way I can see it work is if const-ness is a compile-time
property of names, just like global. But that requires too much
repetition when a constant is imported.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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
>
> - explicit (but still anonymous) constant/expression "folding"
>
> an alternative would be to add a const declaration that can only be used
> in local scopes; i.e.
>
>  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 argument?" issue.

So the constant would be evaluated at function definition time? I find
that rather confusing. Especially since common uses will probably
include

  const true = True
  while true:
...code...

This is a well-meaning attempt to let the compiler optimize this to a
test-less infinite loop that works but throws the baby out with the
bathwater.

> yet another alternative would be a const declaration that you could use
> on a global level, but I fail to see how you could propagate the "const-
> ness" property to whoever wants to use a const object -- unless, of
> course, you implement
>
>  const bar = fie.fum
>
>  def foo(value):
> if value == bar:
>...
>
> as
>
>  class constant_wrapper(object):
>  def __init__(self, value):
>  self.value = value
>
>  bar = constant_wrapper(fie.fum)
>
>  def foo(value, bar=bar.value):
>  if value == bar:
>  ...
>
> (except for the default argument thing; see above).  the result is a
> kind of semi-constant objects that would be useful, but perhaps not
> constant enough...)

I fail to see the usefulness of this wrapper. The wrapper isn't
completely transparent o some code that uses type checks may need to
be modified. The wrapper doesn't get removed by a simple assignment;
after

  const a = 1
  b = a

how do we prevent b from being treated as a constant?

> it might be too much C# exposure, but I think I prefer the "explicit
> when using" approach...

It may be not enough C# exposure, but I don't know exactly which
approach you are referring to.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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: bar(x)
> >>
> >> It is debatable whether this is more or less readable, but it seemed
> >> like an interesting question for the language lawyers.
> >
> > That's no problem for the parser, as long as the expressions are
> > indented. ABC did this.
> >
> > But I think I like an explicit case keyword better; it gives a better
> > error message if the indentation is forgotten.
>
> It also overthrows the notion that suites are started by statements, not
> by expressions.

I'm not sure I care about that. Do you use this in teaching? How does
it help you?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Georg Brandl]

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:
>> >>  1: foo(x)
>> >> 2: bar(x)
>> >>
>> >> It is debatable whether this is more or less readable, but it seemed
>> >> like an interesting question for the language lawyers.
>> >
>> > That's no problem for the parser, as long as the expressions are
>> > indented. ABC did this.
>> >
>> > But I think I like an explicit case keyword better; it gives a better
>> > error message if the indentation is forgotten.
>>
>> It also overthrows the notion that suites are started by statements, not
>> by expressions.
> 
> I'm not sure I care about that. Do you use this in teaching? How does
> it help you?

I just realized that my post could be misunderstood: The sentence referred
to the "case"-less form. (And it's just a "feeling" thing)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Phillip J. Eby]

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't need to know
> > what it evaluates to at runtime; that's what LOAD_NAME or LOAD_DEREF are
> > for.  ;)
>
>Please think this through more. How do you implement the "produces an
>error if the value changes" part? Is the const property you're
>thinking of part of the name or of the object it refers to?
>
>The only way I can see it work is if const-ness is a compile-time
>property of names, just like global. But that requires too much
>repetition when a constant is imported.

Right; MAL pointed that out in the message I was replying to, and I 
conceded his point.  Of course, if you consider constness to be an implicit 
property of imported names that aren't rebound, the repetition problem goes 
away.

And if you then require all "case" expressions to be either literals or 
constant names, we can also duck the "when does the expression get 
evaluated?" question.  The obvious answer is that it's evaluated wherever 
you bound the name, and the compiler can either optimize the switch 
statement (or not), depending on where the assignment took place.  A switch 
that's in a loop or a function call can only be optimized if all its 
constants are declared outside the loop or function body; otherwise it 
degrades to an if/elif chain.

There's actually an in-between possibility, too: you could generate if's 
for constants declared in the loop or function body, and use a dictionary 
for any literals or constants declared outside the loop or function 
body.  The only problem that raises is the possibility of an "inner 
constant" being equal to an "outer constant", creating an ambiguity.  But 
we could just say that nearer constants take precedence over later ones, or 
force you to introduce the cases such that inner constants appear first.

(This approach doesn't really need an explicit "const foo=bar" declaration, 
though; it just restricts cases to using names that are bound only once in 
the code of the scope they're obtained from.)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 problems arise if you wrote:
> >> >>
> >> >>  switch x:
> >> >>  1: foo(x)
> >> >> 2: bar(x)
> >> >>
> >> >> It is debatable whether this is more or less readable, but it seemed
> >> >> like an interesting question for the language lawyers.
> >> >
> >> > That's no problem for the parser, as long as the expressions are
> >> > indented. ABC did this.
> >> >
> >> > But I think I like an explicit case keyword better; it gives a better
> >> > error message if the indentation is forgotten.
> >>
> >> It also overthrows the notion that suites are started by statements, not
> >> by expressions.
> >
> > I'm not sure I care about that. Do you use this in teaching? How does
> > it help you?
>
> I just realized that my post could be misunderstood: The sentence referred
> to the "case"-less form. (And it's just a "feeling" thing)

I understood that. And I don't have the same feeling. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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
> > > produces an error if the value changes.  The compiler doesn't need to know
> > > what it evaluates to at runtime; that's what LOAD_NAME or LOAD_DEREF are
> > > for.  ;)
> >
> >Please think this through more. How do you implement the "produces an
> >error if the value changes" part? Is the const property you're
> >thinking of part of the name or of the object it refers to?
> >
> >The only way I can see it work is if const-ness is a compile-time
> >property of names, just like global. But that requires too much
> >repetition when a constant is imported.
>
> Right; MAL pointed that out in the message I was replying to, and I
> conceded his point.  Of course, if you consider constness to be an implicit
> property of imported names that aren't rebound, the repetition problem goes
> away.

Um, technically names are never imported, only objects. Suppose module
A defines const X = 1, and module B imports A. How does the compiler
know that A.X is a constant?

I still don't see how const declarations can be made to work, and
unless you can show me how I don't see how they can help.

> And if you then require all "case" expressions to be either literals or
> constant names, we can also duck the "when does the expression get
> evaluated?" question.  The obvious answer is that it's evaluated wherever
> you bound the name, and the compiler can either optimize the switch
> statement (or not), depending on where the assignment took place.

I don't understand what you're proposing. In particular I don't
understand what you mean by "wherever you bound the name".

So (evading the import problem for a moment) suppose we have

const T = int(time.time())

def foo(x):
  switch x:
case T: print "Yes"
else: print "No"

Do you consider that an optimizable switch or not?

> A switch
> that's in a loop or a function call can only be optimized if all its
> constants are declared outside the loop or function body; otherwise it
> degrades to an if/elif chain.

What do you mean by a switch in a function call? Syntactically that
makes no sense. Do you mean in a function definition?

I think you're trying to give a heuristic here for when it's likely
that the switch will be executed multiple times with all cases having
the same values (so the optimized dict can be reused).

I'm afraid this is going to cause problems with predictability. Also,
if it degenerates to an if/elif chain, does it still require the
switch expression to be hashable?

> There's actually an in-between possibility, too: you could generate if's
> for constants declared in the loop or function body, and use a dictionary
> for any literals or constants declared outside the loop or function
> body.  The only problem that raises is the possibility of an "inner
> constant" being equal to an "outer constant", creating an ambiguity.  But
> we could just say that nearer constants take precedence over later ones, or
> force you to introduce the cases such that inner constants appear first.
>
> (This approach doesn't really need an explicit "const foo=bar" declaration,
> though; it just restricts cases to using names that are bound only once in
> the code of the scope they're obtained from.)

Please, think through the notion of const declarations more before
posting again. Without const declarations none of this can work and
the "at-function-definition-time" freezing is the best, because most
predictable, approach IMO.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Fredrik Lundh]

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 argument?" issue.
> 
> 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...

>> (except for the default argument thing; see above).  the result is a
>> kind of semi-constant objects that would be useful, but perhaps not
>> constant enough...)
> 
> I fail to see the usefulness of this wrapper. The wrapper isn't
> completely transparent o some code that uses type checks may need to
> be modified. The wrapper doesn't get removed by a simple assignment;
> after
> 
>   const a = 1
>   b = a
> 
> how do we prevent b from being treated as a constant?

we cannot -- this approaches assigns (a small amount of) const-ness to 
objects, not names.

>> it might be too much C# exposure, but I think I prefer the "explicit
>> when using" approach...
> 
> It may be not enough C# exposure, but I don't know exactly which
> approach you are referring to.

the original one: if you want to treat an expression as a constant, you 
have to be explicit.  examples:

>>> a "constant" (or perhaps better, "const") primary would also be useful
>>> in several other cases, including:
>>>
>>> - as a replacement for default-argument object binding

this is used when you want to pass an *object* into an inner function, 
rather than a name:

 def foo(value, bar=fie.fum):
 if value == bar:
 ...

can be written

 def foo(value):
 if value == const bar:
 ...

>>> - local dispatch tables, and other generated-but-static data structures

 def foo(value):
 table = const {
 1: "one",
 2: "two",
 3: fie.fum,
 }

(maybe "static" would be a better keyword?)

>>> - explicit (but still anonymous) constant/expression "folding"

 def foo(value):
 if value < const (math.pi / 2):
 ...

and so on.  to implement this, the runtime simply evaluates the "const" 
expressions together with the default value expressions, and assigns the 
result to some func_xxx attribute.  everything else works as usual.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Phillip J. Eby]

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 
problems with them faster than I do, and you assume that those problems 
carry through to the end of my message.  :)  So, I'm partially reversing 
the order of my reply, so you can see what I'm actually proposing, before 
the minutiae of responding the objections you raised to stuff I threw out 
either in my previous message or the message before that.   Hopefully this 
will help.


At 10:44 AM 6/22/2006 -0700, Guido van Rossum wrote:
>Please, think through the notion of const declarations more before
>posting again. Without const declarations none of this can work

Actually, the "const" declaration part isn't necessary and I already 
discarded the idea in my  previous reply to you, noting that the 
combination of these facets can be made to work without any explicit const 
declarations:

1. "case (literal|NAME)" is the syntax for equality testing -- you can't 
use an arbitrary expression, not even a dotted name.

2. NAME, if used, must be bound at most once in its defining scope

3. Dictionary optimization can occur only for literals and names not bound 
in the local scope, others must use if-then.

This doesn't require explicit "const" declarations at all.  It does, 
however, prohibit using "import A" and then switching on a bunch of "A.foo" 
values.  You have to "from A import foo, bar, baz" instead.

If you like this, then you may not need to read the rest of this message, 
because most of your remaining comments and questions were based on an 
assumption that "const" declarations were necessary.


>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
> > > > produces an error if the value changes.  The compiler doesn't need 
> to know
> > > > what it evaluates to at runtime; that's what LOAD_NAME or 
> LOAD_DEREF are
> > > > for.  ;)
> > >
> > >Please think this through more. How do you implement the "produces an
> > >error if the value changes" part? Is the const property you're
> > >thinking of part of the name or of the object it refers to?
> > >
> > >The only way I can see it work is if const-ness is a compile-time
> > >property of names, just like global. But that requires too much
> > >repetition when a constant is imported.
> >
> > Right; MAL pointed that out in the message I was replying to, and I
> > conceded his point.  Of course, if you consider constness to be an implicit
> > property of imported names that aren't rebound, the repetition problem goes
> > away.
>
>Um, technically names are never imported, only objects. Suppose module
>A defines const X = 1, and module B imports A. How does the compiler
>know that A.X is a constant?

It doesn't.  You have to "from A import X".  At that point, you have a name 
that is bound by an import that can be considered constant as long as the 
name isn't rebound later.


> > And if you then require all "case" expressions to be either literals or
> > constant names, we can also duck the "when does the expression get
> > evaluated?" question.  The obvious answer is that it's evaluated wherever
> > you bound the name, and the compiler can either optimize the switch
> > statement (or not), depending on where the assignment took place.
>
>I don't understand what you're proposing. In particular I don't
>understand what you mean by "wherever you bound the name".
>
>So (evading the import problem for a moment) suppose we have
>
>const T = int(time.time())
>
>def foo(x):
>   switch x:
> case T: print "Yes"
> else: print "No"
>
>Do you consider that an optimizable switch or not?

Yes.  What I'm trying to do is separate "when the dictionary is 
constructed" from "when the expression is evaluated".  If we restrict the 
names used to names that have at most one binding in their defining scope, 
then we can simply add the dictionary entries whenever the *name is 
bound*.  Ergo, the evaluation time is apparent from simple reading of the 
source - we are never moving the evaluation, only determining how early we 
can add information to the switching dictionary.

Thus, the answer to "when is the expression evaluated" is "when it's 
executed as seen in the source code".  There is thus no magic of either 
first-use or function-definition involved.  What you see is exactly what 
you get.


> > A switch
> > that's in a loop or a function call can only be optimized if all its
> > constants are declared outside the loop or function body; otherwise it
> > degrades to an if/elif chain.
>
>What do you mean by a switch in a function cal

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 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
magic.

> >> (except for the default argument thing; see above).  the result is a
> >> kind of semi-constant objects that would be useful, but perhaps not
> >> constant enough...)
> >
> > I fail to see the usefulness of this wrapper. The wrapper isn't
> > completely transparent o some code that uses type checks may need to
> > be modified. The wrapper doesn't get removed by a simple assignment;
> > after
> >
> >   const a = 1
> >   b = a
> >
> > how do we prevent b from being treated as a constant?
>
> we cannot -- this approaches assigns (a small amount of) const-ness to
> objects, not names.

OK, so neither a nor b is really a constant; it's just that they have
a value that is a constant wrapper.

I'm still confused how this wrapper would be used at run time.
(Because at compile time we *don't* generally know whether a
particular value contains a const wrapper or not.)

> >> it might be too much C# exposure, but I think I prefer the "explicit
> >> when using" approach...
> >
> > It may be not enough C# exposure, but I don't know exactly which
> > approach you are referring to.
>
> the original one: if you want to treat an expression as a constant, you
> have to be explicit.  examples:
>
> >>> a "constant" (or perhaps better, "const") primary would also be useful
> >>> in several other cases, including:
> >>>
> >>> - as a replacement for default-argument object binding
>
> this is used when you want to pass an *object* into an inner function,
> rather than a name:
>
>  def foo(value, bar=fie.fum):
>  if value == bar:
>  ...
>
> can be written
>
>  def foo(value):
>  if value == const bar:
>  ...
>
> >>> - local dispatch tables, and other generated-but-static data structures
>
>  def foo(value):
>  table = const {
>  1: "one",
>  2: "two",
>  3: fie.fum,
>  }
>
> (maybe "static" would be a better keyword?)

At least it resembles the corresponding C keyword better than 'const'.

'static' tells me something useful (at least if I know C/C++/Java).
And I have some idea on how to implement it (not so different from the
def-time switch freezing).

However it should be

  static table = {...}

But I don't see how this would require the const-wrapper.

And I still think that this is not as nice as def-time freezing
switches; static or const causes clumsy syntax when importing
constants from another module since you have to repeat the const-ness
for each imported constant in each importing module.

> >>> - explicit (but still anonymous) constant/expression "folding"
>
>  def foo(value):
>  if value < const (math.pi / 2):
>  ...
>
> and so on.  to implement this, the runtime simply evaluates the "const"
> expressions together with the default value expressions, and assigns the
> result to some func_xxx attribute.  everything else works as usual.

Yup, got it. This is clearly implementable and has clear semantics.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 over ideas I already discarded, because you find the
> problems with them faster than I do, and you assume that those problems
> carry through to the end of my message.  :)

You *do* have a text editor that lets you go back to the top of the
draft to remove discarded ideas, don't you? :-)

It's a reasonable form of discourse to propose an idea only to shoot
it down, but usually this is introduced by some phrase that hints to
the reader what's going to happen. You can't expect the reader to read
the entire email before turning on their brain. :)

> So, I'm partially reversing
> the order of my reply, so you can see what I'm actually proposing, before
> the minutiae of responding the objections you raised to stuff I threw out
> either in my previous message or the message before that.   Hopefully this
> will help.
>
> At 10:44 AM 6/22/2006 -0700, Guido van Rossum wrote:
> >Please, think through the notion of const declarations more before
> >posting again. Without const declarations none of this can work
>
> Actually, the "const" declaration part isn't necessary and I already
> discarded the idea in my  previous reply to you, noting that the
> combination of these facets can be made to work without any explicit const
> declarations:
>
> 1. "case (literal|NAME)" is the syntax for equality testing -- you can't
> use an arbitrary expression, not even a dotted name.

But dotted names are important! E.g. case re.DOTALL. And sometimes
compile-time constant expressions are too. Example: case sys.maxint-1.

> 2. NAME, if used, must be bound at most once in its defining scope

That's fine -- but doesn't extend to dotted names.

> 3. Dictionary optimization can occur only for literals and names not bound
> in the local scope, others must use if-then.

So this wouldn't be optimized?!

NL = "\n"
for line in sys.stdin:
  switch line:
"abc\n": ...
NL: ...

> This doesn't require explicit "const" declarations at all.  It does,
> however, prohibit using "import A" and then switching on a bunch of "A.foo"
> values.  You have to "from A import foo, bar, baz" instead.
>
> If you like this, then you may not need to read the rest of this message,
> because most of your remaining comments and questions were based on an
> assumption that "const" declarations were necessary.

I like it better than const declarations, but I don't like it as much
as the def-time-switch-freezing proposal; I find the limitiation to
simple literals and names too restrictive, and there isn't anything
else like that in Python. I also don't like the possibility that it
degenerates to if/elif. I like predictability. I like to be able to
switch on dotted names.

Also, when using a set in a case, one should be able to use an
expression like s1|s2 in a case.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[M.-A. Lemburg]

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:

Variables which are to be regarded as constant within the
scope of the function are declared as such by using a "const"
declaration (much like we already have with the
global declaration).

a,b,c,d = range(4)
defvalue = 1

def switch(x=defvalue):
const a,b,c,d
switch x:
case a: return 'foo'
case b: return 'foo'
case c: return 'foo'
case d: return 'foo'
else: raise ValueError(x)

This declaration would cause the compiler to generate
LOAD_NAME opcodes just like for defvalue which then gets
executed at code object execution time, ie. when the
function is created.

This would also work out for the solution 1 case
in the PEP (if-elif-else)...  :-)

def switch(x=defvalue):
const a,b,c,d
if x == a: return 'foo'
elif x == b: return 'bar'
elif x == c: return 'baz'
elif x == d: return 'bazbar'
else: raise ValueError(x)

Furthermore, the compiler could protect the constant
names from assignments (much in the same way it
applies special treatment to variables declared global
in a scope).

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)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 22 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/

2006-07-03: EuroPython 2006, CERN, Switzerland  10 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ralf W. Grosse-Kunstleve]

--- 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 use this function (don't remember how I found it; this was years ago),
> > therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2).
> Is
> > there an alternative spelling for PyRange_New()?
> 
> You can call PyRange_Type with the appropriate parameters.

Thanks a lot for the hint! However, I cannot find any documentation for
PyRange_*. I tried this page...

  http://docs.python.org/api/genindex.html

and google. Did I miss something?

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 there is no existing documentation for the alternative.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Fredrik Lundh]

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 object survives" is not
> magic.

well, people find "def goes over all default values and evaluates them 
in the surrounding scope (etc)" pretty confusing, and the default values 
are all part of the function header.  here you're doing the same thing 
for some expressions *inside* the function body, but not all.  it might 
be easy to explain, but I don't think it's easy to internalize.

> I'm still confused how this wrapper would be used at run time.
> (Because at compile time we *don't* generally know whether a
> particular value contains a const wrapper or not.)

oh, it would require the compiler to check for const-ness on globals 
when the function object is created, which would work for simple names, 
and require some yet-to-be-determined-handwaving-hackery for anything 
else...

> - local dispatch tables, and other generated-but-static data structures
>>  def foo(value):
>>  table = const {
>>  1: "one",
>>  2: "two",
>>  3: fie.fum,
>>  }
>>
>> (maybe "static" would be a better keyword?)
> 
> At least it resembles the corresponding C keyword better than 'const'.
> 
> 'static' tells me something useful (at least if I know C/C++/Java).
 >
> And I have some idea on how to implement it (not so different from the
> def-time switch freezing).
> 
> However it should be
> 
>   static table = {...}

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 those of us who likes our Python fast.

> But I don't see how this would require the const-wrapper.

it wouldn't.

> And I still think that this is not as nice as def-time freezing
> switches; static or const causes clumsy syntax when importing
> constants from another module since you have to repeat the const-ness
> for each imported constant in each importing module.

well, the point is that you only have to spell it out if you actually 
care about things being constant/static/evaluated once/early, and when 
you do, it's always obvious for the reader what you're doing.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Ka-Ping Yee]

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
> something if x equals y, the argument, while in fact it prints
> something if x equals 12.

I am quite concerned about this case too.  I think if Python were
to behave this way, it would be a new pitfall for people learning
the language -- like other pitfalls such as using unbound locals,
mutable default arguments, or the historical non-nested scopes.
I'm not saying the other pitfalls don't have good reasons -- some
are outweighed by other design advantages (unbound locals are a
consequence of having no variable declarations) and some have
since been fixed (like nested scopes).  But i'd be wary of adding
a new pitfall to that list without a very substantial win.

> Me too. I guess I was just pointing out that "just" evaluating it in
> the global scope would not give an error, just like this is valid (but
> confusing):
>
> y = 12
> def foo(y=y):
>   print y
> y = 13
> foo()  # prints 12

I see how frozen-cases and default-arguments could have comparable
semantics, but i do think frozen-cases are more confusing.  In this
default-arguments example, there is at least a hint from the syntax
that we're introducing a new local variable, so there is a landmark
where the reader can hang the mental note that a new thing is being
introduced.  Also, it is easier to see that default arguments are
being fixed at function-definition time because their value
expressions are localized in the source code in the "def" line, a
line that makes sense to be evaluating at definition time.

For frozen-cases, you don't have this kind of landmark, and the bits
that are evaluated at function-definition time are scattered and
mixed with the rest of the function evaluated at function-call time.
That's pretty subtle; i can't think of any other Python construct
off the top of my head that mixes evaluation times like that.  (Yes,
the compiler does optimize literals, but it's done in a way that
doesn't affect semantics.)


-- ?!ng
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Thomas Heller]

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 is running a build of the trunk from last
 night:

./configure && make && ./python.exe Lib/test/test_ctypes.py

 Note that the test does NOT fail on the Mac OS X/x86 10.4.6 box
 that I have.
>>>
>>> It also works on 10.4.?? Power PC.  I guess the fix has to wait until
>>> I'm able to install 10.3 on my mac, I have the DVDs already but
>>> have not
>>> yet had the time.  If anyone is willing to give me ssh access to a
>>> 10.3
>>> box I can try to fix this earlier.
>>
>> I had some problems with my 10.3-capable box, but happily enough it
>> decided to come alive again. I'm currently booted into 10.3.9 and
>> 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: FAIL: dlcompat: unable  
> to open this file with RTLD_LOCAL. This seems to be confirmed by this  
> sourcet test file from darwin: http://darwinsource.opendarwin.org/ 
> 10.4.1/dyld-43/unit-tests/test-cases/dlopen-RTLD_LOCAL/main.c.

Hm, what does this mean, and how can the test be repaired?  Maybe I have 
to wait until I can play with Panther to understand this issue...

Would loading the dylib with RTLD_GLOBAL work (or any other flags)?
Does RTLD_LOCAL not work with dylibs, but with other libraries (are 
there any)?

Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Georg Brandl]

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 dangerously lax error checking.
>> > 
>> > I use this function (don't remember how I found it; this was years ago),
>> > therefore my code doesn't compile with 2.5b1 (it did OK before with 2.5a2).
>> Is
>> > there an alternative spelling for PyRange_New()?
>> 
>> You can call PyRange_Type with the appropriate parameters.
> 
> Thanks a lot for the hint! However, I cannot find any documentation for
> PyRange_*. I tried this page...
> 
>   http://docs.python.org/api/genindex.html
> 
> and google. Did I miss something?
> 
> 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 there is no existing documentation for the alternative.

Well, PyRange_New *was* undocumented, so there's no place in the documentation
where it would have been.

However, it would perhaps be helpful to add a note to the whatsnew document
for users like yourself. Andrew, does that make sense?

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Bob Ippolito]

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
>>> in the core code, and had dangerously lax error checking.
>>>
>>> I use this function (don't remember how I found it; this was  
>>> years ago),
>>> therefore my code doesn't compile with 2.5b1 (it did OK before  
>>> with 2.5a2).
>> Is
>>> there an alternative spelling for PyRange_New()?
>>
>> You can call PyRange_Type with the appropriate parameters.
>
> Thanks a lot for the hint! However, I cannot find any documentation  
> for
> PyRange_*. I tried this page...
>
>   http://docs.python.org/api/genindex.html
>
> and google. Did I miss something?
>
> 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 there is no existing documentation for the alternative.

He means something like this:
PyObject_CallFunction(PyRange_Type, "llli", ...)

-bob

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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
> > magic.
>
> well, people find "def goes over all default values and evaluates them
> in the surrounding scope (etc)" pretty confusing, and the default values
> are all part of the function header.

I think it's more surprising than confusing, in the same way as
mutable class variables are, or the sharing that follows from "a = [];
b = a".

The switch proposal has less opportunity for this particular surprise
because the case expressions must be immutable (or at least hashable,
which pretty much boils down to the same thing).

> here you're doing the same thing
> for some expressions *inside* the function body, but not all.  it might
> be easy to explain, but I don't think it's easy to internalize.

It's hard to see how it will lead to actual surprises given even only
moderately decent coding style (which would imply not changing global
variables as implied "parameters").

> > I'm still confused how this wrapper would be used at run time.
> > (Because at compile time we *don't* generally know whether a
> > particular value contains a const wrapper or not.)
>
> oh, it would require the compiler to check for const-ness on globals
> when the function object is created, which would work for simple names,
> and require some yet-to-be-determined-handwaving-hackery for anything
> else...

I'd like to see more examples that show how it works. Some simple
"this works, that doesn't, because..." demos.

> > - local dispatch tables, and other generated-but-static data structures
> >>  def foo(value):
> >>  table = const {
> >>  1: "one",
> >>  2: "two",
> >>  3: fie.fum,
> >>  }
> >>
> >> (maybe "static" would be a better keyword?)
> >
> > At least it resembles the corresponding C keyword better than 'const'.
> >
> > 'static' tells me something useful (at least if I know C/C++/Java).
> >
> > And I have some idea on how to implement it (not so different from the
> > def-time switch freezing).
> >
> > However it should be
> >
> >   static table = {...}
>
> 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.

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. So this
would be allowed?

  a = static 1
  a = static 2  # same variable

> and things like
>
>  radian = degree * static (math.pi / 180)
>
> would be pretty nice, for those of us who likes our Python fast.

No argument there.

> > And I still think that this is not as nice as def-time freezing
> > switches; static or const causes clumsy syntax when importing
> > constants from another module since you have to repeat the const-ness
> > for each imported constant in each importing module.
>
> well, the point is that you only have to spell it out if you actually
> care about things being constant/static/evaluated once/early, and when
> you do, it's always obvious for the reader what you're doing.

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.

I'm also unclear on what you propose this would do *without* the
statics. Would it be a compile-time error? Compile the dict each time
the switch is executed? Degenerate to an if/elif chain? Then what if x
is unhashable? What if *some* cases are static and others aren't?

Also, do you still see any use for the const wrapper that you brought
up earlier? I don't at this point.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Georg Brandl]

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.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Phillip J. Eby]

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 no longer needed.  We then end up
>>having arguments over ideas I already discarded, because you find the
>>problems with them faster than I do, and you assume that those problems
>>carry through to the end of my message.  :)
>
>You *do* have a text editor that lets you go back to the top of the
>draft to remove discarded ideas, don't you? :-)

Well, usually the previous idea seems an essential part of figuring out the 
new idea, and showing why the new idea is better.  At least the way I think 
about it.  But now that I've noticed this seems to be a recurring theme in 
our discussions, I'll try to be more careful.


>It's a reasonable form of discourse to propose an idea only to shoot
>it down, but usually this is introduced by some phrase that hints to
>the reader what's going to happen. You can't expect the reader to read
>the entire email before turning on their brain. :)

Well, you can't expect me to know ahead of time what ideas I'm going to 
discard before I've had the ideas that will replace them.  ;-)  But again, 
I'll be more careful in future about retroactively adding such warnings or 
removing the old ideas entirely.


>>1. "case (literal|NAME)" is the syntax for equality testing -- you can't
>>use an arbitrary expression, not even a dotted name.
>
>But dotted names are important! E.g. case re.DOTALL. And sometimes
>compile-time constant expressions are too. Example: case sys.maxint-1.

True - but at least you *can* use them, with "from re import DOTALL" and 
"maxint_less_1 = sys.maxint-1".  You're just required to disambiguate 
*when* the calculation of these values is to be performed.


>>2. NAME, if used, must be bound at most once in its defining scope
>
>That's fine -- but doesn't extend to dotted names.

Right, hence #1.


>>3. Dictionary optimization can occur only for literals and names not bound
>>in the local scope, others must use if-then.
>
>So this wouldn't be optimized?!
>
>NL = "\n"
>for line in sys.stdin:
>  switch line:
>"abc\n": ...
>NL: ...

This would result in a switch dictionary with "abc\n" in it, preceded by an 
if line==NL test.  So it's half-optimized.  The more literals, the more 
optimized.  If you put the same switch in a function body, it becomes fully 
optimized if the NL binding stays outside the function definition.

Note that you previously proposed a switch at top level not be optimized at 
all, so this is an improvement over that.


>I like it better than const declarations, but I don't like it as much
>as the def-time-switch-freezing proposal; I find the limitiation to
>simple literals and names too restrictive, and there isn't anything
>else like that in Python.

Well, you can't "def" a dotted name, but I realize this isn't a binding.


>I also don't like the possibility that it
>degenerates to if/elif. I like predictability.

It is predictable: anything defined in the same scope will be if/elif, 
anything defined outside will be dict-switched.


>I like to be able to switch on dotted names.
>Also, when using a set in a case, one should be able to use an
>expression like s1|s2 in a case.

...which then gets us back to the question of when the dots or "|" are 
evaluated.  My proposal forces you to make the evaluation time explicit, 
visible, and unquestionably obvious in the source, rather than relying on 
invisible knowledge about the function definition time.

"First time use" is also a more visible approach, because it does not 
contradict the user's assumption that evaluation takes place where the 
expression appears.  The "invisible" assumption is only that subsequent 
execution will reuse the same expression results without recalculating them 
-- it doesn't *move* the evaluation somewhere else.

I seem to recall that in general, Python prefers to evaluate expressions in 
the order that they appear in source code, and that we try to preserve that 
property as much as possible.  Both the "names and literals only" and 
"first-time use" approaches preserve that property; "function definition 
time" does not.

Of course, it's up to you to weigh the cost and benefit; I just wanted to 
bring this one specific factor (transparency of the source) to your 
attention.  This whole "const" thread was just me trying to find another 
approach besides "first-time use" that preserves that visibility property 
for readers of the code.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Georg Brandl]

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 those of us who likes our Python fast.

Nice approach, though I wonder if it's unambiguous enough without
some parenthesizing.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Ka-Ping Yee]

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
primary design motivator) makes sense without some strong evidence
that the use of if/elif constructs often causes a severe speed problem
in many Python programs.  (Premature optimization and all that.)
Long if/elif chains probably don't occur often enough or slow down
programs enough to invent syntax *just* for speed; and even if they
did, i don't think there's any precedent for a Python statement
invented primarily as a speed optimization.

I'm hoping we can talk more about the question: How can a new statement
help programmers express their intent more clearly?

So far i've seen two possible answers to that question:

1.  The switched-on expression is written and evaluated just once.

2.  The cases could help you unpack things into local variables.

(There was some discussion about unpacking earlier:
http://mail.python.org/pipermail/python-dev/2005-April/052780.html
which petered out, though there may still be the possibility of
designing something quite useful and readable.)

Any others?


-- ?!ng
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 constant expressions are too. Example: case sys.maxint-1.
> [Phillip]
> True - but at least you *can* use them, with "from re import DOTALL" and
> "maxint_less_1 = sys.maxint-1".  You're just required to disambiguate
> *when* the calculation of these values is to be performed.

Yeah, but the result is a quite crippled case expression that's not
like anything in Python.

> >>2. NAME, if used, must be bound at most once in its defining scope
> >
> >That's fine -- but doesn't extend to dotted names.
>
> Right, hence #1.

Which I don't like.

(I know, I'm repeating myself here. Better than contradicting myself. :-)

> >>3. Dictionary optimization can occur only for literals and names not bound
> >>in the local scope, others must use if-then.
> >
> >So this wouldn't be optimized?!
> >
> >NL = "\n"
> >for line in sys.stdin:
> >  switch line:
> >"abc\n": ...
> >NL: ...
>
> This would result in a switch dictionary with "abc\n" in it, preceded by an
> if line==NL test.  So it's half-optimized.  The more literals, the more
> optimized.  If you put the same switch in a function body, it becomes fully
> optimized if the NL binding stays outside the function definition.

That still seems really weird, especially if you consider the whole
thing already being inside a def(). It would optimize references to
non-locals but not references to locals...?

> Note that you previously proposed a switch at top level not be optimized at
> all, so this is an improvement over that.

I don't particularly care about top-level switches; I don't expect
they'll be used much and I don't expect people to care about their
speed much. A for loop using some local variables is also quite slow
outside a function; if anybody complains we just tell them to put it
in a function.

I do care about switch/case being easy to use and flexible in likely
use cases, which include using constants defined in a different
module.

> >I like it better than const declarations, but I don't like it as much
> >as the def-time-switch-freezing proposal; I find the limitiation to
> >simple literals and names too restrictive, and there isn't anything
> >else like that in Python.
>
> Well, you can't "def" a dotted name, but I realize this isn't a binding.

You could have left that out of your email and we'd all have been happier. :-)

> >I also don't like the possibility that it
> >degenerates to if/elif. I like predictability.
>
> It is predictable: anything defined in the same scope will be if/elif,
> anything defined outside will be dict-switched.

But that's pretty subtle. I'd much rather see a rule that
*effectively* rules out non-constant cases completely. IMO the
def-time-switch-freeze proposal does this.

> >I like to be able to switch on dotted names.
> >Also, when using a set in a case, one should be able to use an
> >expression like s1|s2 in a case.
>
> ...which then gets us back to the question of when the dots or "|" are
> evaluated.  My proposal forces you to make the evaluation time explicit,
> visible, and unquestionably obvious in the source, rather than relying on
> invisible knowledge about the function definition time.

At the cost of more convoluted code. It means in many cases I'd
probably continue to use if/elif chains because refactoring it into a
switch is too much effort. Thereby relegating switch to something only
used by speed freaks. While I want my switch to be fast, I don't want
it to be a freak.

> "First time use" is also a more visible approach, because it does not
> contradict the user's assumption that evaluation takes place where the
> expression appears.  The "invisible" assumption is only that subsequent
> execution will reuse the same expression results without recalculating them
> -- it doesn't *move* the evaluation somewhere else.

Have you made up your mind yet where the result of the first-time
evaluated value should be stored? On the function object? That implies
that it doesn't help for inner defs that are called only once per
definition (like certain callback patterns).

> I seem to recall that in general, Python prefers to evaluate expressions in
> the order that they appear in source code, and that we try to preserve that
> property as much as possible.  Both the "names and literals only" and
> "first-time use" approaches preserve that property; "function definition
> time" does not.

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.

> Of course, it's up to you to weigh the cost and benefit; I just wanted to
> bring this one specific factor (transparency of the source) to your
> atte

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 think switch-for-efficiency (at least if efficiency is the
> primary design motivator) makes sense without some strong evidence
> that the use of if/elif constructs often causes a severe speed problem
> in many Python programs.  (Premature optimization and all that.)
> Long if/elif chains probably don't occur often enough or slow down
> programs enough to invent syntax *just* for speed; and even if they
> did, i don't think there's any precedent for a Python statement
> invented primarily as a speed optimization.

My position is more nuanced that that. I like having a switch because
it can make certain types of code more readable. (I keep referring to
sre_parse.py and sre_compile.py -- has anyone else looked at these at
all?) But I also like switch because it can be implemented using a
single dict lookup with a pre-computed dict, if certain conditions on
the cases are met. I find that those conditions generally met by code
that lends itself for using a switch. I believe that switch would be
better understood if it *always* precomputed the dict, and failed
immediately with an exception (at run time) if the precompilation
wasn't feasible.

> I'm hoping we can talk more about the question: How can a new statement
> help programmers express their intent more clearly?
>
> So far i've seen two possible answers to that question:
>
> 1.  The switched-on expression is written and evaluated just once.
>
> 2.  The cases could help you unpack things into local variables.
>
> (There was some discussion about unpacking earlier:
> http://mail.python.org/pipermail/python-dev/2005-April/052780.html
> which petered out, though there may still be the possibility of
> designing something quite useful and readable.)

I'm not convinced that the matching idea (which your URL seems to
refer to) works well enough in Python to consider. Anyway, it's a
completely different approach and should probably be discussed
separately rather than as a variant of switch/case.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Phillip J. Eby]

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 computation is moved to function 
definition time and becomes an anonymous free variable.  The body of the 
static expression becomes a LOAD_DEREF of the free variable, rather than 
computation of the expression.

The debug trace will show the function definition going to the lines that 
contain the static expressions, but that's understandable.

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; i.e. it belongs to the 
function, as opposed to each execution of the function.  (Whereas I was 
reading "const" as meaning "immutable" or "non-rebindable", which made no 
sense in the context.)


>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'm also unclear on what you propose this would do *without* the
>statics. Would it be a compile-time error? Compile the dict each time
>the switch is executed? Degenerate to an if/elif chain? Then what if x
>is unhashable? What if *some* cases are static and others aren't?

If we allow non-static cases, then they should become "if"s that happen 
prior to a dictionary lookup on the remaining static/literal ones.  Or we 
could just say that each adjacent block of static cases is its own 
dictionary lookup, and the rest happen in definition order.  (i.e., you 
replace contiguous static/literal runs with dictionary lookups, and 
everything else is if-elif.)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Thomas Heller]

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: FAIL: dlcompat: unable to 
>>> open this file with RTLD_LOCAL. This seems to be confirmed by this 
>>> sourcet test file from darwin: 
>>> http://darwinsource.opendarwin.org/10.4.1/dyld-43/unit-tests/test-cases/dlopen-RTLD_LOCAL/main.c.
>>>  
>>> 
>>
>>What does this mean?  Would it work with RTLD_GLOBAL, is there any other 
>>way to repair it, or does loading dylibs not work at all on Panther?
> 
> Using RTLD_GLOBAL does work. This should also be fairly save as RTLD_GLOBAL 
> seems to be the same as RTLD_LOCAL when using two-level namespaces (which is 
> the default on OSX and used by Python).

This sounds like RTLD_GLOBAL should be the default mode on OS X.

Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Phillip J. Eby]

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 convinced me... I
>think it's time to sit back and wait for someone else to weigh in with
>a new argument.

Which I think you and Fredrik have found, if "case" implies "static".  It 
also looks attractive as an addition in its own right, independent of "switch".

In any case, my point wasn't to convince you but to make you aware of 
certain costs and benefits that I wasn't sure you'd perceived.  It's clear 
from your response that you *have* perceived them now, so I'm quite 
satisfied by that outcome -- i.e., my goal wasn't to "convince" you to 
adopt a particular proposal, but rather to make sure you understood and 
considered the ramifications of the ones under discussion.

That being said, there isn't anything to "get past"; from my POV, the 
discussion is already a success.  :)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Maclaren]

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/trunk/decimal-c'
svn: PROPFIND of '/view/sandbox/trunk/decimal-c': Could not read chunk size: 
connection was closed by server. (http://svn.python.org)


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  [EMAIL PROTECTED]
Tel.:  +44 1223 334761Fax:  +44 1223 334679
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Maclaren]

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?), then I guess it gets easier.

No, I am not.  And it isn't as hard as is currently made out.

> > 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.  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.

> > 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.

> > The problem with such things is that they related to the interfaces
> > between types, and it is those aspects where object-orientation
> > falls down so badly.  For example, consider conversion between float
> > and long - which class should control the semantics?
> 
> This comment seems not to relate to anything I said, or at least not
> obviously.

I am afraid that it did.  I pointed out that some of the options
needed to control the behaviour of the implicit conversions between
built-in classes.  Now, right back in the Simula days, those issues
were one of the reasons of the religious war between the multiple
inheritance people and those who thought it was anathema.  My claim
is that such properties need to be program-global, or else you will
have the most almighty confusion.

You can take the Axiom approach of having a superclass to which
such things are bound, but most programming languages have always
had difficulty with properties that aren't clearly associated with
a single class - ESPECIALLY when they affect primitives.

> >> 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.  The fact
is that they are unspecified - IDEALLY, things like floating-point
traps would be handled thread-locally (and thus neither change context
not affect other cores, as was done on the Ferranti Atlas and many
other machines), 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 - which
is a serious design error.

> > 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?

> > 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 t

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

[Ralf W. Grosse-Kunstleve]

--- 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* not documented. There
is no mention of "PyRange" in the Python C API documentation, not even "range".

Unless I am the only user of PyRange_New() in the whole wide world a few extra
lines in the "changes" document will prevent recurring questions.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Facundo Batista]

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 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.  I do, of
> course, need to exclude the cases when the code is testing states
> explicitly, twiddling bits and so on.

Well, so I'm completely lost... because, if all you want is to be able
to chose a returned value or an exception raised, you actually can
control that in Decimal.

Regards,

-- 

.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Aahz]

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 document FOR PYTHON that
specifies how a smart person like Michael Hudson would go about
implementing what you want.  Keep in mind that Python does *not*
currently require C99 (and it's not clear when it will) and that Python
runs on multiple hardware platforms and operating systems, so your scheme
needs to be either independent of hardware/OS or you need to clearly
specify how your scheme can EASILY be made to work on any system.

You can't expect us to do your legwork for you, and you can't expect
that Tim Peters is the only person on the dev team who understands what
you're getting at.

Incidentally, your posts will go directly to python-dev without
moderation if you subscribe to the list, which is a Good Idea if you want
to participate in discussion.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"I saw `cout' being shifted "Hello world" times to the left and stopped
right there."  --Steve Gonedes
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Switch statement

[Guido van Rossum]

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 to get
> >past this point except by stating that you haven't convinced me... I
> >think it's time to sit back and wait for someone else to weigh in with
> >a new argument.
>
> Which I think you and Fredrik have found, if "case" implies "static".  It
> also looks attractive as an addition in its own right, independent of 
> "switch".
>
> In any case, my point wasn't to convince you but to make you aware of
> certain costs and benefits that I wasn't sure you'd perceived.  It's clear
> from your response that you *have* perceived them now, so I'm quite
> satisfied by that outcome -- i.e., my goal wasn't to "convince" you to
> adopt a particular proposal, but rather to make sure you understood and
> considered the ramifications of the ones under discussion.
>
> That being said, there isn't anything to "get past"; from my POV, the
> discussion is already a success.  :)

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]

(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.

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.

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.

:-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Neal Norwitz]

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 raised.
>
> Then you need to write up a detailed design document FOR PYTHON that

The best design doc that I know of is code. :-)

Seriously, there seems to be a fair amount of miscommunication in this
thread.  It would be much easier to communicate using code snippets.
I'd suggest pointing out places in the Python code that are lacking
and how you would correct them.  That will make it easier for everyone
to understand each other.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ralf W. Grosse-Kunstleve]

--- 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 there is no existing documentation for the alternative.
> 
> He means something like this:
> PyObject_CallFunction(PyRange_Type, "llli", ...)

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'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


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). 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.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com