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
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
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
--- "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
--- "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,
> >
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
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:
> --- "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
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
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
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
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
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
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, 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
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
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 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
"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
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
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
"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
"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
"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
"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
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
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>
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:
>> ...
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
--- 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
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
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
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:
>>>
>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
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
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
[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
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
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
>
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
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
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
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:
> 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:
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
45 matches
Mail list logo
