On Tue, Jan 31, 2006 at 08:16:21PM -0500, Tim Peters wrote:
Is this version of gcc broken in some way relative to other gcc versions,
or newer, or ... ? We certainly don't want to see warnings under gcc,
since it's heavily used, but I'm not clear on why other versions of gcc
aren't producing
Thomas Wouters wrote:
On Tue, Jan 31, 2006 at 08:16:21PM -0500, Tim Peters wrote:
Is this version of gcc broken in some way relative to other gcc versions,
or newer, or ... ? We certainly don't want to see warnings under gcc,
since it's heavily used, but I'm not clear on why other versions
On Tue, 2006-01-31 at 17:17 -0500, Andrew Koenig wrote:
Apart from making 0640 a syntax error (which I think is wrong too),
could this be solved by *requiring* the argument to be a string? (Or
some other data type, but that's probably overkill.)
That solves the problem only in that
Thomas Wouters wrote:
My main problem with fixing the warnings is that I don't see the difference
between, for example, the 'ssize' variable and the 'nchannels' variable
As was pointed out elsewhere, any variable that is passed by-reference
to another function is ignored for the purposes of
On Wed, Feb 01, 2006 at 01:51:03PM +, Michael Hudson wrote:
Scott Dial [EMAIL PROTECTED] writes:
So, either the GCC people have not noticed this problem, or (more
likely) have decided that this is acceptable, but clearly it will cause
spurious warnings. Hey, after all, they are just
[Martin v. Löwis]
It inlines the function to make this determination.
Very cool! Is this a new(ish) behavior?
Now, it's not true that e can be uninitialized then, but there
the gcc logic fails:
That's fine -- there are any number of ways a compiler can reach a
wrong conclusion by making
Thomas Wouters wrote:
On Wed, Feb 01, 2006 at 01:51:03PM +, Michael Hudson wrote:
Scott Dial [EMAIL PROTECTED] writes:
So, either the GCC people have not noticed this problem, or (more
likely) have decided that this is acceptable, but clearly it will cause
spurious warnings. Hey, after
On 2/1/06, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote:
On Tue, 2006-01-31 at 17:17 -0500, Andrew Koenig wrote:
I am personally partial to allowing an optional radix (in decimal) followed
by the letter r at the beginning of a literal, so 19, 8r23, and 16r13 would
all represent the
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the
casual observer; perhaps a suffix letter is more readable, since we
don't need arbitrary radix support anyway.
/me thinks of some
Hi there,
Recently, updates from MoinMoin have started getting quarantined due to sender
verification failing. On investigating the problem, it seems that an assumption
about the webmaster mailbox is incorrect:
220 bag.python.org ESMTP Postfix (Debian/GNU)
MAIL FROM:
503 Error: send
[Thomas Wouters]
Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3
(in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
behaves the same way. The normal make process shows quite a lot of output on
systems that use gcc, so I wouldn't be surprised
On Feb 1, 2006, at 7:33 AM, Gustavo J. A. M. Carneiro wrote:
Another possility is to extend the 0x syntax to non-hex,
0xff # hex
0o644 # octal
0b1101 # binary
+1
James
___
Python-Dev mailing list
Python-Dev@python.org
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the
casual observer; perhaps a suffix letter is more readable, since we
don't need
I've submitted an updated version of the PEP. The only major change is
that instead of the method atime and property getatime() there is now
only one method named atime(). Also some information about the string
inheritance problem in Open Issues. I still have no idea what to do
about it though.
On Wed, 01 Feb 2006 09:47:34 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the
casual
On Wed, 2006-02-01 at 09:47 -0800, Josiah Carlson wrote:
I hope I'm not the only one who thinks that simple is better than
complex, at least when it comes to numeric constants. Certainly it
would be _convenient_ to express constants in a radix other than decimal,
hexidecimal, or octal, but
Hi,
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
would be legal. There are of course issues (what's the syntax for a
frozen set? for the empty set?), but before he even starts,
Sjoerd Mullender wrote:
I don't quite understand what's the big deal.
Traditionally, people see two problems with these initializations:
- the extra initialization may cause a performance loss.
- the initialization might hide real bugs later on. For example,
if an additional control flow
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 09:47:34 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think
On Wed, 1 Feb 2006, Barry Warsaw wrote:
The proposal for something like 0xff, 0o664, and 0b1001001 seems like
the right direction, although 'o' for octal literal looks kind of funky.
Maybe 'c' for oCtal? (remember it's 'x' for heXadecimal).
Shouldn't it be 0t644 then, and 0n1001001 for
Tim Peters wrote:
It inlines the function to make this determination.
Very cool! Is this a new(ish) behavior?
In 3.4:
http://gcc.gnu.org/gcc-3.4/changes.html
# A new unit-at-a-time compilation scheme for C, Objective-C, C++ and
# Java which is enabled via -funit-at-a-time (and implied by
On Wed, 2006-02-01 at 11:07 -0800, Josiah Carlson wrote:
In my experience, I've rarely had the opportunity (or misfortune?) to
deal with negative constants, whose exact bit representation I needed to
get just right. For my uses, I find that specifying -0x... or -...
to be sufficient.
I
[Greg Wilson]
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
would be legal. There are of course issues (what's the syntax for a
frozen set? for the empty set?), but before
At 01:55 PM 2/1/2006 -0500, Greg Wilson wrote:
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
would be legal. There are of course issues (what's the syntax for a
frozen set? for
[Phillip J. Eby]
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
The PEP records that Tim argued for leaving the extra parentheses.
What would you do with {'title'} -- create
On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
[Thomas Wouters]
Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3
(in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
behaves the same way. The normal make process shows quite a
On Wed, Feb 01, 2006 at 10:15:15AM -0500, Tim Peters wrote:
Thomas, for these _PyLong_AsScaledDouble()-caller cases, I suggest doing
whatever obvious thing manages to silence the warning. For example, in
PyLong_AsDouble:
int e = -1; /* silence gcc warning */
and then add:
Raymond Hettinger wrote:
[Phillip J. Eby]
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
The PEP records that Tim argued for leaving the extra parentheses.
What
[Greg Wilson]
This is a moderately-fertile source of bugs for newcomers: judging from
the number of students who come into my office with code that they think
ought to work, but doesn't, most people believe that:
set(1, 2, 3)
Like many things in Python where people pre-emptively believe
Thomas Wouters [EMAIL PROTECTED] writes:
On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
[Thomas Wouters]
Well, I said 4.0.3, and that was wrong. It's actually a pre-release of
4.0.3
(in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
behaves the same
Thomas thanks.. useful string ... bob
On 2/1/06, Michael Hudson [EMAIL PROTECTED] wrote:
Thomas Wouters [EMAIL PROTECTED] writes:
On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
[Thomas Wouters]
Well, I said 4.0.3, and that was wrong. It's actually a pre-release of
On Wed, Feb 01, 2006 at 03:03:22PM -0500, Phillip J. Eby wrote:
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
In any case I don't think it's possible to differentiate
32 matches
Mail list logo
