Re: [Python-Dev] syntactic support for sets
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 between the current calling convention and the 'parenless' one reliably, eg.: S = set([]) There is no way to tell if that is a set containing an empty list created using the parenless syntax, or an empty set, as is created with the current calling convention. -- DISOBEY, v.t. To celebrate with an appropriate ceremony the maturity of a command. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 > >> > 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 if people did ignore it, > >> > for the most part. > > > >> Does it really? It's completely warning-free on Windows, and that's > >> the intent, and it takes ongoing work to keep it that way. Over at, > >> e.g., > > > > No, it's mostly warning-free, it just outputs a lot of text. By default, > > the warnings don't stand out much. And if you have a decent computer, it > > scrolls by pretty fast, too. ;) > > "make -s" is a wonderful thing :) > > Cheers, > mwh > > -- > In case you're not a computer person, I should probably point out > that "Real Soon Now" is a technical term meaning "sometime before > the heat-death of the universe, maybe". > -- Scott Fahlman <[EMAIL PROTECTED]> > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/evdo.hsdpa%40gmail.com > -- Robert Q Kim, Wireless Internet Advisor http://evdo-coverage.com/cellular-repeater.html http://hsdpa-coverage.com http://evdo-coverage.com/pocket-pc-pda-ppc.html 2611 S. Pacific Coast Highway 101 Suite 102 Cardiff by the Sea, CA 92007 206 984 0880 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 way. The normal make process shows quite a lot of output >> > on >> > systems that use gcc, so I wouldn't be surprised if people did ignore it, >> > for the most part. > >> Does it really? It's completely warning-free on Windows, and that's >> the intent, and it takes ongoing work to keep it that way. Over at, >> e.g., > > No, it's mostly warning-free, it just outputs a lot of text. By default, > the warnings don't stand out much. And if you have a decent computer, it > scrolls by pretty fast, too. ;) "make -s" is a wonderful thing :) Cheers, mwh -- In case you're not a computer person, I should probably point out that "Real Soon Now" is a technical term meaning "sometime before the heat-death of the universe, maybe". -- Scott Fahlman <[EMAIL PROTECTED]> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
[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 one thing
or another, the interpreter's corrective feedback is immediate:
>>> set(1, 2, 3)
Traceback (most recent call last):
set(1, 2, 3)
TypeError: set expected at most 1 arguments, got 3
There is futher feedback in the repr string which serves as a reminder
of how to construct a literal:
>>> set(xrange(3))
set([0, 1, 2])
Once the students have progressed beyond academic finger drills and
have started writing real code, have you observed a shift in emphasis
away from hard-coded literals and towards something like s=set(data)
where the data is either read-in from outside the script or generated by
another part of the program?
For academic purposes, I think the genexp form also has value in that
it is broadly applicable to more than just sets (i.e. dict comprehensions)
and that it doesn't have to grapple with arbitrary choices about whether
{1,2,3} would be a set or frozenset.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[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 explicitly promise e >= 0. That's what I did :-) "The docs" are in longobject.h. You can tell which functions I wrote, BTW, because they're the ones with comments in the header file documenting what they do. It's an ongoing mystery to me why nobody else found that to be a practice worth emulating ;-)/:-( ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
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 would you do with {'title'} -- create a four element set consisting
> of letters or a single element set consisting of a string?
I think the answer to this one is clearly that it is a single element
set consisting of a string, just as ['title'] is a single element list
consisting of a string.
I believe the confusion arises if Brett's proposal for ``set(1, 2, 3,
4, 5)`` is considered. Currently, set('title') is a five element set
consisting of letters. But set('title', 'author') would be a two
element set consisting of two strings? The problem is in calling the
set constructor, not in writing a set literal.
That said, I don't think there's really that much of a need for set
literals. I use sets almost exclusively to remove duplicates, so I
almost always start with empty sets and add things to them. And I'm
certainly never going to write ``set([1, 1, 2])`` when I could just
write ``set([1, 2])`.
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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: > > assert(e >= 0); > > after the call. Done, 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. Reading--imagine-that-ly y'rs, -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 lot of output on > > systems that use gcc, so I wouldn't be surprised if people did ignore it, > > for the most part. > Does it really? It's completely warning-free on Windows, and that's > the intent, and it takes ongoing work to keep it that way. Over at, > e.g., No, it's mostly warning-free, it just outputs a lot of text. By default, the warnings don't stand out much. And if you have a decent computer, it scrolls by pretty fast, too. ;) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
[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 a four element set consisting
of letters or a single element set consisting of a string?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
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 the empty set?),
Ones that work now:
frozenset(z for z in x if (z%2))
set()
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 ().
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
[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 he even starts, I'd like to
> know if this would ever be considered for inclusion into the language.
Generator expressions make syntactic support irrelevant:
x = set(xrange(1,6))
y = set(z for z in x if (z % 2))
y = frozenset(z for z in x if (z % 2))
Accordingly,Guido rejected the braced notation for set comprehensions.
See: http://www.python.org/peps/pep-0218.html
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
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 for a
> frozen set? for the empty set?), but before he even starts, I'd like to
> know if this would ever be considered for inclusion into the language.
I am -0 on set syntax support. If the set() constructor was expanded
to take an arbitrary number of arguments (and thus be more inline with
the dict constructor) then the syntax need really starts to go away
since the above could be done as ``set(1, 2, 3, 4, 5)``.
As for the set copmrehension/expression/thing, I don't think that is
needed at all when ``set(z for z in x if z % 2)`` will get the job
done just as well without adding more syntactic sugar to the language
for something that is so easy to do already.
> p.s. please Cc: me as well as the list, since I'm no longer subscribed.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 can't remember a time when signed hex, oct, or binary representation wasn't a major inconvenience, let alone something desirable. Don't get me started about hex(id(object()))! I typically use hex for addresses and bit fields, binary for bit flags and other bit twiddling, and oct for OS/file system interfaces. In none of those cases do you actually need or want signed values. IME. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 > > Well, that's pretty bizarre. There's _obviously_ no way to get to a > reference to `e` without going through > > x = _PyLong_AsScaledDouble(vv, &e); > > first. That isn't a useful warning. This has been discussed many times on the GCC mailing list. Ultimately, detecting whether a variable is using initialized or not (given full interprocedural and whole-program compilation) is a problem that can be reduced to the halting problem. The only thing that GCC should (and will) do is finding a way to be consistent across different releases and optimization levels, and to produce an useful number of warnings, while not issuing too many false positives. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 -O2). In # this scheme a whole file is parsed first and optimized later. The # following basic inter-procedural optimizations are implemented: # # - ... The actual "might be uninitialized" warning comes from the SSA branch, which was merged in 4.0, as somebody else pointed out. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 binary ? That would sidestep the issue of 'b' and 'c' being valid hexadecimal digits as well. Regarding negative numbers, I think they're a red herring. If there is any need for a new literal format, it would be to express ~0x0f, not -0x10. 1xf0 has been proposed before, but I think YAGNI. /Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
[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 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.
> >
> >[snip discussion over radix and compliments]
> >
> >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 to me, it all looks like noise.
>
> You don't have to use any other radix, any more than you have to use all forms
> of float literals if you are happy with xx.yy. The others just become
> available
> through a consistent methodology.
>
> >Peronally, I was on board for the removal of octal literals, if only
> >because I find _seeing_ a leading zero without something else (like the
> >'x' for hexidecimal) to be difficult, and because I've found little use
> >for them in my work (decimals and hex are usually all I need).
>
> I agree that 8r641 is more easily disambiguated than 0641 ;-)
>
> But how do you represent a negative int in hex? Or have you never encountered
> the need?
> The failure of current formats with respect to negative values whose values
> you
> want to specify in a bit-specifying format was my main point.
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.
Certainly it may or may not be the case in what you are doing (hence
your exposition on signs, radixes, etc.).
Would the i32() function you previously defined, as well as a utility
h32() function which does the reverse be a reasonable start? Are there
any radixes beyond binary, octal, decimal, and hexidecimal that people
want to use? Does it make sense to create YYrX syntax for integer
literals for basically 4 representations, all of which can be handled by
int('XX', YY) (ignoring the runtime overhead)? Does the suffix idea
for different types (long, decimal, ...) necessarily suggest that
suffixes for radixes for one type (int/long) is a good idea (1011b,
2000o, ...) are a good idea?
I'll expand what I said before; there are many things that would make
integer literals more convenient for heavy (or experienced) users of
non-decimal or non-decimal-non-positive literals, but it wouldn't
necessarily increase the understandability of code which uses them.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 branch is added which fails to initialize the variable, you don't get the warning anymore, not even from compilers which previously did a correct analysis. Whether this is a big deal, I don't know. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] syntactic support for sets
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'd like to
know if this would ever be considered for inclusion into the language.
Thanks,
Greg
p.s. please Cc: me as well as the list, since I'm no longer subscribed.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 to me, it all looks like noise. As a Unix weenie and occasional bit twiddler, I've had needs for octal, hex, and binary literals. +1 for coming up with a common syntax for these. -1 on removing any way to write octal literals. 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). -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 observer; perhaps a suffix letter is more readable, since we >> >don't need arbitrary radix support anyway. > >[snip discussion over radix and compliments] > >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 to me, it all looks like noise. You don't have to use any other radix, any more than you have to use all forms of float literals if you are happy with xx.yy. The others just become available through a consistent methodology. > >Peronally, I was on board for the removal of octal literals, if only >because I find _seeing_ a leading zero without something else (like the >'x' for hexidecimal) to be difficult, and because I've found little use >for them in my work (decimals and hex are usually all I need). I agree that 8r641 is more easily disambiguated than 0641 ;-) But how do you represent a negative int in hex? Or have you never encountered the need? The failure of current formats with respect to negative values whose values you want to specify in a bit-specifying format was my main point. Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The path module PEP
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. -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
[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 arbitrary radix support anyway. [snip discussion over radix and compliments] 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 to me, it all looks like noise. Peronally, I was on board for the removal of octal literals, if only because I find _seeing_ a leading zero without something else (like the 'x' for hexidecimal) to be difficult, and because I've found little use for them in my work (decimals and hex are usually all I need). Should it change for me? Of course not, but I think that adding different ways to spell integer values will tend to confuse new and seasoned python users. Some will like the flexibility that adding new options offers, but I believe such a change will be a net loss for the understandability of those pieces of code which use it. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[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 if people did ignore it, > for the most part. Does it really? It's completely warning-free on Windows, and that's the intent, and it takes ongoing work to keep it that way. Over at, e.g., http://www.python.org/dev/buildbot/g5%20osx.3%20trunk/builds/46/step-compile/0 I only see one gcc warning, coming from Python/Python-ast.c. I suppose that isn't a complete build, though. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [EMAIL PROTECTED] failing sender verification.
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 HELO/EHLO first HELO argon.maildefence.co.uk 250 bag.python.org MAIL FROM: <> 250 Ok RCPT TO: [EMAIL PROTECTED] 553 invalid bounce (address does not send mail) The MoinMoin instance on Python.org is sending mail as "[EMAIL PROTECTED]". Can somebody take a look? Or at least tell me who to contact. Thanks, David. PS: Please CC me in replies as I am not currently subscribed. -- It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 examples: > > 644o # I _think_ the small 'o' cannot be easily confused with 0 or O, >but.. > 10h # hex.. hm.. but we already have 0x10 > 101b # binary > > Another possility is to extend the 0x syntax to non-hex, > > 0xff # hex > 0o644 # octal > 0b1101 # binary > > I'm unsure which one I like better. > Sorry if I seem to be picking nits, but IMO there's more than a nit here: The trouble with all of these is that they are all literals for integers, but integers are signed, and there is no way to represent the sign bit (wherever it is for a particular platform) along with the others, without triggering a promotion to positive long. So you get stuff like >>> def i32(i): return int(-(i&0x8000))+int(i&0x7fff) ... >>> MYCONST = i32(0x87654321) >>> MYCONST -2023406815 >>> type(MYCONST) >>> hex(MYCONST) '-0x789abcdf' Oops ;-/ >>> hex(MYCONST&0x) '0x87654321L' instead of MYCONST = 16cf87654321 Hm... maybe an explicit ordinary sign _after_ the prefix would be more mnemonic instead of indicating it with the radix-complement (f or 0 for hex). E.g., MYCONST = 16r-87654321 # all bits above the 8 are ones and MYCONST = 16r+87654321 # explicitly positive, all bits above 8 (none for 32 bits) are zeroes MYCONST = 16r87654321# implicitly positive, ditto or the above in binary MYCONST = 2r-11110110010101110011 # leading bits are ones (here all are specified for 32-bit int, but # effect would be noticeable for smaller numbers or wider ints) MYCONST = 2r+11110110010101110011 # leading bits are zeroes (ditto) MYCONST = 2r11110110010101110011 # ditto This could also be done as alternative 0x syntax, e.g. using 0h, 0o, and 0b, but I sure don't like that '0o' ;-) BTW, for non-power-of-two radices(?), it should be remembered that the '-' is mnemonic for the symbol for (radix-1), and '+' or no sign is mnemonic for a prefixed 0 (which is 0 in any allowable radix) in order to have this notation have general radix expressivity for free ;-) Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 same value. > > For me, adding the radix to the right instead of left looks nicer: > 23r8, 13r16, etc., since a radix is almost like a unit, and units are > always to the right. Plus, we already use suffix characters to the > right, like 10L. And I seem to recall an old assembler (a z80 > assembler, IIRC :P) that used a syntax like 10h and 11b for hex an bin > radix. ffr16 #16rff or 255 Iamadeadparrotr36 # 36rIamadeadparrot or 3120788520272999375597 Suffix syntax for bases higher than 10 is ambiguous with variable names. Prefix syntax is not. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 all, they are just warnings.
>
>> Well, indeed, but "no warnings" is a useful policy -- it makes new
>> warnings much easier to spot :)
>
>> The warnings under discussion seem rather excessive to me.
>
> Yes, and more than that; fixing them 'properly' requires more than just
> initializing them. There is no sane default for some of those warnings, so a
> proper fix would have to check for a sane value after the function returns.
> That is, if we take the warning seriously. If we don't take it seriously,
> initializing the variable may surpress a warning in the future: one of the
> called functions could change, opening a code path that in fact doesn't
> initialize the output variable. But initializing to a sentinel value,
> checking the value before use and handling that case sanely isn't always
> easy, or efficient. Hence my suggestion to let this wait a bit (since they
> are, at this time, spurious errors). Fixing the warnings *now* won't fix any
> bugs, may mask future bugs, and may not be necessary if gcc 4.0.4 grows a
> better way to surpress these warnings. Or gcc 4.0 may grow more such
> warnings, in which case we may want to change the 'no warnings' policy or
> the flags to gcc, or add a 'known spurious warnings' checking thing to the
> buildbot.
>
Although it is no consolation, there are two types of unused variable
warnings: the known-error ("is used uninitialized in this function") and
a probable-error ("may be used uninitialized in this function"). It may
be reasonable to ignore the probable-error case. I think someone even
mentioned that they really should be an "info" and not a "warning".
The points in the code clearly should have attention brought to them
because there is a real possibility of error, but as you say, there is
no way to rid yourself of this type of warning.
Also, note that the phrasing "is"/"may be" is a change from 3.x to 4.x.
The old warning was "might" always, and as I understand gcc the "might"
of 3.x maps directly to the "is" of 4.x -- leaving "may be" an entirely
new thing to 4.x.
From gcc/tree-ssa.c:
The second pass follows PHI nodes to find uses that are potentially
uninitialized. In this case we can't necessarily prove that the use
is really uninitialized. This pass is run after most optimizations,
so that we thread as many jumps and possible, and delete as much dead
code as possible, in order to reduce false positives. We also look
again for plain uninitialized variables, since optimization may have
changed conditionally uninitialized to unconditionally uninitialized.
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[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 conservative assumptions, and so long as
it's actually staring at code I don't mind that at all. What I would
mind is griping about some_func(&a) possibly not setting `a` in the
_absence_ of staring at `some_func`'s internals.
> If you take the
>
> if (vv == NULL || !PyLong_Check(vv)) {
> PyErr_BadInternalCall();
> return -1;
> }
>
> case in _PyLong_AsScaledDouble, *exponent won't be initialized.
Certainly, and I don't expect a compiler to realize that this branch
is impossible when _PyLong_AsScaledDouble is invoked from the call
sites where gcc is complaining.
> Then, in PyLong_AsDouble, with
>
> x = _PyLong_AsScaledDouble(vv, &e);
> if (x == -1.0 && PyErr_Occurred())
> return -1.0;
>
> it looks like the return would not be taken if PyErr_Occurred returns
> false. Of course, it won't, but that is difficult to analyse.
PyLong_AsDouble already did:
if (vv == NULL || !PyLong_Check(vv)) {
PyErr_BadInternalCall();
return -1;
}
before calling _PyLong_AsScaledDouble(), and the latter's `x` is the
former's `vv`. That is, the check you showed above from
_PyLong_AsScaledDouble() is exactly the same as the check
PyLong_AsDouble already made. To exploit that, gcc would have to
realize PyLong_Check() is a "pure enough" function, and I don't expect
gcc to be able to figure that out.
>> I don't know. 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 these warnings (or are they,
>> and people have been ignoring that?).
> gcc 4 does inlining in far more cases now.
OK then. 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:
assert(e >= 0);
after the call.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 warnings. > Well, indeed, but "no warnings" is a useful policy -- it makes new > warnings much easier to spot :) > The warnings under discussion seem rather excessive to me. Yes, and more than that; fixing them 'properly' requires more than just initializing them. There is no sane default for some of those warnings, so a proper fix would have to check for a sane value after the function returns. That is, if we take the warning seriously. If we don't take it seriously, initializing the variable may surpress a warning in the future: one of the called functions could change, opening a code path that in fact doesn't initialize the output variable. But initializing to a sentinel value, checking the value before use and handling that case sanely isn't always easy, or efficient. Hence my suggestion to let this wait a bit (since they are, at this time, spurious errors). Fixing the warnings *now* won't fix any bugs, may mask future bugs, and may not be necessary if gcc 4.0.4 grows a better way to surpress these warnings. Or gcc 4.0 may grow more such warnings, in which case we may want to change the 'no warnings' policy or the flags to gcc, or add a 'known spurious warnings' checking thing to the buildbot. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 -- it makes new warnings much easier to spot :) The warnings under discussion seem rather excessive to me. Cheers, mwh -- Ignoring the rules in the FAQ: 1" slice in spleen and prevention of immediate medical care. -- Mark C. Langston, asr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 these warnings. The fact that the ioctl call with nchannels happens well after potential problem spots doesn't matter. It appears that GCC has eliminated it from the decision process for the purposes of these warnings already. The problem roots from the ambiguity of the returns. At compile-time, there is no way for GCC that the return value will be negative in the error case, and thus the return may cause us to go down an execution path that ssize (and nchannels) need to be initialized. This check seems to be very shallow, even if you provide a guarantee that the return value will be well-behaved, GCC has already given up on figuring this out. The rule of thumb here seems to be "if you make a call to a function which provides the condition for the uninitialized variable is used, then the condition is decided to be ambiguous." 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. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 particular context. > > I would think that if it is deemed undesirable for a leading 0 to imply > octal, then it would be best to decide on a different syntax for octal > literals and use that syntax consistently everywhere. +1, and then issue a warning every time the parser sees leading 0 octal constant instead of the new syntax, although the old syntax would continue to work for compatibility reasons. > > 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 same value. For me, adding the radix to the right instead of left looks nicer: 23r8, 13r16, etc., since a radix is almost like a unit, and units are always to the right. Plus, we already use suffix characters to the right, like 10L. And I seem to recall an old assembler (a z80 assembler, IIRC :P) that used a syntax like 10h and 11b for hex an bin radix. 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 examples: 644o # I _think_ the small 'o' cannot be easily confused with 0 or O, but.. 10h # hex.. hm.. but we already have 0x10 101b # binary Another possility is to extend the 0x syntax to non-hex, 0xff # hex 0o644 # octal 0b1101 # binary I'm unsure which one I like better. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 of gcc >>aren't producing these warnings (or are they, and people have been >>ignoring that?). > > > 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 if people did ignore it, > for the most part. > > 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 in > linuxaudio's lad_obuffree/lad_bufsize/lad_obufcount. 'ssize' gets a warning, > 'nchannels' doesn't, yet how they are treated is not particularly different. > The ssize output parameter gets set inside a switch, is directly followed by > a break, and the switch is directly followed by a set of the nchannels > output parameter. The only way through the switch is through the set of > ssize. I understand the compiler doesn't "see" it this way, but who knows > for how long :) > > I guess we ignore this until we're closer to a 2.5alpha1 ;P > I don't quite understand what's the big deal. The compiler issues a warning. We know better (and I agree, we *do* know better in most of these cases), but it's easy to add a "= 0" to the declaration of the variable to shut up the compiler, hopefully with a comment saying as much. That's what I've been doing in my code that generated these warnings. It's clearly a "bug" in the compiler that it isn't smart enough to figure out that variable do actually only get used after they've been set. Hence, this is Somebody Else's Problem. -- Sjoerd Mullender signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 these warnings (or are they, and people have been > ignoring that?). 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 if people did ignore it, for the most part. 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 in linuxaudio's lad_obuffree/lad_bufsize/lad_obufcount. 'ssize' gets a warning, 'nchannels' doesn't, yet how they are treated is not particularly different. The ssize output parameter gets set inside a switch, is directly followed by a break, and the switch is directly followed by a set of the nchannels output parameter. The only way through the switch is through the set of ssize. I understand the compiler doesn't "see" it this way, but who knows for how long :) I guess we ignore this until we're closer to a 2.5alpha1 ;P -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
