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 differenti
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-rel
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)
>> >
[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 beli
[Thomas]
> Done,
Thanks!
> although it was nowhere near obvious to me that -1 would be a sane
> sentinel value ;) Not that I don't believe you, but it took some actual
> reading of _PyLong_AsScaledDouble to confirm it.
Nope, the thing to do was to read the docs for _PyLong_AsScaledDouble,
which
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 parenthes
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:
>
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 quit
[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'} -- cr
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
[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?),
On 2/1/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> 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
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
Tim Peters <[EMAIL PROTECTED]> wrote:
> [Thomas Wouters]
>> I noticed a few compiler warnings, when I compile Python on my amd64 with
>> gcc 4.0.3:
>>
>> Objects/longobject.c: In function 'PyLong_AsDouble':
>> Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
>> function
>
>
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
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 bin
[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 be
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 branc
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, I'
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,
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
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.
--
[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
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
http://ma
[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 surpri
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: sen
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
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
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 warni
[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 c
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
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 warnings.
Well, indeed, but "no warnings" is a useful policy --
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 t
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:
> 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 ve
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 produc
36 matches
Mail list logo
