--- Martin v. L�wis [EMAIL PROTECTED] wrote:
The specific question was
Is there a way to set the warning options via an environment variable?
This has nothing to do with beta1; the warnings module was introduced
many releases ago, along with all the mechanics to disable warnings.
Due
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 standard
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 pressing
--- 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,
lll,
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/009869.html
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
have no
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 application
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 and
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
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 standard
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
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 are broken if they see
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 that
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 warnings
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 emphasis
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 warnings on import
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 easier to
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 is
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 mean
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 Standards
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 of
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 am talking
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 failed to get hold
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 reflector, but
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:
...
where VAR is a temporary variable,
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 a
--- 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 remember
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 ends up
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:
...
else:
...
where VAR
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
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
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
in real
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 is
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 in a
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 done for key
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
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
46 matches
Mail list logo
