Gustavo Carneiro wrote:
> However, PyObject_CallFunction does _not_
> consume such an object reference, contrary to what I believed for
> years.
Why do you say that? It certainly does.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
ht
Phillip J. Eby wrote:
> 1. "case (literal|NAME)" is the syntax for equality testing -- you can't
> use an arbitrary expression, not even a dotted name.
That's too restrictive. I want to be able to write
things like
class Foods:
Spam = 1
Eggs = 2
Ham = 3
...
switch f:
At first I was pretty excited about the switch proposals, but having
read the various discussions I have to say that my enthusiasm has cooled
quite a bit. The set of proposals that are currently being put forward
have enough caveats and restrictions as to make the statement far less
useful than
Phillip J. Eby wrote:
> At 05:30 PM 6/24/2006 -0700, Raymond Hettinger wrote:
>> [Phillip Eby]
>>> I would like to be able to use switches on types, enumerations, and the
>> like.
>>
>> Be careful about wanting everything and getting nothing.
>> My proposal is the simplest thing that gets the job
Raymond Hettinger wrote:
>>From what I can see, almost everyone wants a switch statement, though perhaps
> for different reasons.
>
> The main points of contention are 1) a non-ambiguous syntax for assigning
> multiple cases to a single block of code, 2) how to compile variables as
> constants
Raymond Hettinger wrote:
> [Phillip Eby]
>> I would like to be able to use switches on types, enumerations, and the like.
>
> Be careful about wanting everything and getting nothing.
> My proposal is the simplest thing that gets the job done for key use cases
> found
> in real code.
> Also, it i
At 05:30 PM 6/24/2006 -0700, Raymond Hettinger wrote:
>[Phillip Eby]
> > I would like to be able to use switches on types, enumerations, and the
> like.
>
>Be careful about wanting everything and getting nothing.
>My proposal is the simplest thing that gets the job done for key use cases
>found
>
On Sat, Jun 24, 2006, Raymond Hettinger wrote:
>
> So, that is it, my proposal for simple switch statements with a
> straight-forward implementation, fast execution, simply explained
> behavior, and applicability to to the most important use cases.
+1
I've been trying to write a response to these
[Phillip Eby]
> I would like to be able to use switches on types, enumerations, and the like.
Be careful about wanting everything and getting nothing.
My proposal is the simplest thing that gets the job done for key use cases
found
in real code.
Also, it is defined tightly enough to allow room f
Sorry this is slightly offtopic, but I think it's important...
According to recent experiments tracking down a memory leak, it
seems that PyObject_CallFunction(func, "N", object) and
PyObject_CallFunction(func, "O", object) are doing exactly the same
thing. However, documentation says "The C
At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote:
>Cases values must be ints, strings, or tuples of ints or strings.
-1. There is no reason to restrict the types in this fashion. Even if you
were trying to ensure marshallability, you could still include unicode and
longs. However, there i
>From what I can see, almost everyone wants a switch statement, though perhaps
for different reasons.
The main points of contention are 1) a non-ambiguous syntax for assigning
multiple cases to a single block of code, 2) how to compile variables as
constants in a case statement, and 3) handling
Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
> >> just map
>>> switch EXPR:
>>> case E1:
>>> ...
>>> case in E2:
>>> ...
>>> else:
>>> ...
>>>
>>> to
>>>
>>> VAR = EXPR
>>> if VAR == E1:
>>> ...
>>> elif VAR in E2:
>>>
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Jun 2006, Josiah Carlson wrote:
> > This is a good thing, because if switch/case ends up functionally
> > identical to if/elif/else, then it has no purpose as a construct.
>
> This doesn't make sense as a rule.
>
> Consider:
>
> "If x.y en
On Fri, 23 Jun 2006, Josiah Carlson wrote:
> This is a good thing, because if switch/case ends up functionally
> identical to if/elif/else, then it has no purpose as a construct.
This doesn't make sense as a rule.
Consider:
"If x.y ends up functionally identical to getattr(x, 'y'),
then
--- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> I think it is safe to say that Twisted is more widely used than anything
> Google has yet released. Twisted also has a reasonably plausible
> technical reason to dislike this change. Google has a bunch of engineers
> who, apparently, cannot rem
At 07:04 PM 6/24/2006 +0200, Fredrik Lundh wrote:
>I don't see this as much of a problem, really: we can simply restrict
>the optimization to well-known data types ("homogenous" switches using
>integers or strings should cover 99.9% of all practical cases), and then
>add an opcode that checks uses
Guido van Rossum wrote:
>> just map
>>
>> switch EXPR:
>> case E1:
>> ...
>> case in E2:
>> ...
>> else:
>> ...
>>
>> to
>>
>> VAR = EXPR
>> if VAR == E1:
>> ...
>> elif VAR in E2:
>> ...
>> else:
>> ...
On 6/23/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:>> > >Unfortunately, that doesn't help, because it is not where the issues> > >are. What I don't know is how much you know about numerical models,
> > >IEEE 754 in particular, and C99. You weren't active on the SC22WG14>
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Facundo Batista" <[EMAIL PROTECTED]> wrote:
> >
> > 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.
>
> Yes, but I have so far fa
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
>
> > 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
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
>
> Of interest among their C-EPs is one for adding the equivalent of our
> decimal module
> http://www.open-std.org/jtc1/sc22/wg14/www/projects#24732
IBM is mounting a major campaign to get its general decimal arithmetic
standardised as THE standard form
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> > SC22WG14? is that some marketing academy? not a very good one, obviously.
>
> That's because it's European ;-)
Er, please don't post ironic satire of that nature - many people will
believe it!
ISO is NOT European. It is the Internatational Standa
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> I suspect Nick spends way too much time reading standards ;-)
God help me, YES! And in trying to get them improved. Both of which
are very bad for my blood pressure :-(
My real interest is in portable, robust programming - I DON'T abuse
the terms to m
Michael Hudson <[EMAIL PROTECTED]> wrote:
>
> But, a floating point exception isn't a machine check interrupt, it's
> a program interrupt...
For reasons that I could go into, but are irrelevant, almost all
modern CPU architectures have one ONE interrupt mechanism, and use
it for both of those. It
To the moderator: this is getting ridiculous.
[EMAIL PROTECTED] wrote:
>
> > >Unfortunately, that doesn't help, because it is not where the issues
> > >are. What I don't know is how much you know about numerical models,
> > >IEEE 754 in particular, and C99. You weren't active on the SC22WG14
"Neal Norwitz" <[EMAIL PROTECTED]> wrote:
>
> Seriously, there seems to be a fair amount of miscommunication in this
> thread. ...
Actually, this isn't really a reply to you, but you have described
the issue pretty well.
> The best design doc that I know of is code. :-)
>
> It would be much easi
On Sat, 24 Jun 2006 16:24:11 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Jean-Paul Calderone wrote:
>> I am very unhappy that the burden of understanding Python's package
>> structure is being pushed onto end users in this way. Several of my
>> projects now emit three or four warning
Josiah Carlson wrote:
> This is a good thing, because if switch/case ends up functionally
> identical to if/elif/else, then it has no purpose as a construct.
there's no shortage of Python constructs that are functionally identical
to existing constructs. as with all syntactic "sugar", the empha
On Sat, 24 Jun 2006 07:27:15 -0700, Aahz <[EMAIL PROTECTED]> wrote:
>On Sat, Jun 24, 2006, Jean-Paul Calderone wrote:
>>
>> I am very unhappy that the burden of understanding Python's package
>> structure is being pushed onto end users in this way. Several of my
>> projects now emit three or four
On Sat, Jun 24, 2006, Jean-Paul Calderone wrote:
>
> I am very unhappy that the burden of understanding Python's package
> structure is being pushed onto end users in this way. Several of my
> projects now emit three or four warnings on import now.
>
> The Twisted plugin system relies on the fact
Jean-Paul Calderone wrote:
> I am very unhappy that the burden of understanding Python's package
> structure is being pushed onto end users in this way. Several of my
> projects now emit three or four warnings on import now.
So are you requesting that the change is reverted?
Regards,
Martin
On Sat, 24 Jun 2006 11:47:19 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Ralf W. Grosse-Kunstleve wrote:
>> --- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>
>>> I don't know. Whether a warning is a problem is a matter of attitude, also.
>>
>> Our users will think our applications a
Scott David Daniels wrote:
> ... (PyObject*) (void *) &PyRange_Type, ...
> Says a pointer to PyRange_Type should have the structure of a pointer
> PyObject. Since the prelude to PyTypeObject matches that of PyObject,
> this should be an effective cast.
The C standard says it's undefined behav
Martin v. Löwis wrote:
> Scott David Daniels wrote:
>> ... if I remember the standard
>> correctly, the following code shouldn't complain:
>>
>> PyObject_CallFunction((PyObject*) (void *) &PyRange_Type,
>> "lll", start, start+len*step, step)
>
> You remember the stand
The current train of thought seems to be to handle a switch statement as
follows:
1. Define switch explicitly as a hash table lookup, with the hash table
built at function definition time
2. Allow expressions to be flagged as 'static' to request evaluation at
def-time
3. Have the exp
On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:
> Brett Cannon wrote:
>> 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
Ralf W. Grosse-Kunstleve wrote:
> --- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> I don't know. Whether a warning is a problem is a matter of attitude, also.
>
> Our users will think our applications are broken if they see warnings like
> that. It is not professional.
Actually, your applic
Brett Cannon wrote:
> 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 interpreter
> ha
Ralf W. Grosse-Kunstleve wrote:
>> You remember the standard incorrectly.
>
> There are three standards to consider: C89/90, C99, C++97/98. Here you can
> find
> the opinion of one of the authors of the C++ standard in this matter:
>
> http://mail.python.org/pipermail/c++-sig/2005-December/00986
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Scott David Daniels wrote:
> > I am not sure about your compiler, but if I remember the standard
> > correctly, the following code shouldn't complain:
> >
> > PyObject_CallFunction((PyObject*) (void *) &PyRange_Type,
> >
--- "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I don't know. Whether a warning is a problem is a matter of attitude, also.
Our users will think our applications are broken if they see warnings like
that. It is not professional.
__
Do You Yahoo
Ralf W. Grosse-Kunstleve wrote:
>> This has nothing to do with beta1; the warnings module was introduced
>> many releases ago, along with all the mechanics to disable warnings.
>
> Due to the new ImportWarning first introduced in 2.5b1 the question of
> disabling warnings is becoming much more pre
Ralf W. Grosse-Kunstleve wrote:
> I am not an expert of the C/C++ language details, but the intermediate cast
> seems to be a great local alternative to the global -fno-strict-aliasing flag.
Depends on what you want to achieve. If you just want to make the
warning go away, the cast works fine. If
Scott David Daniels wrote:
> I am not sure about your compiler, but if I remember the standard
> correctly, the following code shouldn't complain:
>
> PyObject_CallFunction((PyObject*) (void *) &PyRange_Type,
> "lll", start, start+len*step, step)
You remember the sta
45 matches
Mail list logo
