There is less than a week left before students must submit a final
application. There are a bunch of ideas up on the wiki:
http://wiki.python.org/moin/SummerOfCode/
The wiki has instructions for how to submit a proposal. There are
many different areas including: core language features, lib
Guido van Rossum wrote:
> This also explains
> why I'm no fan of the oft-proposed idea that slices should avoid
> making physical copies even if they make logical copies -- the
> complexity of that approach horrifies me.)
FWIW, I've now realised it is possible to create a "seqview" type which
pr
Le mercredi 03 mai 2006 à 07:46 +0200, Fredrik Lundh a écrit :
> Antoine Pitrou wrote:
>
> > Including a simplistic GUI library in the stdlib is really *not* helpful
> > to developers, it can even be deceptive.
>
> what makes discussions like these impossible is that everyone is assuming
> that t
Guido writes:
> (I had a bad
> experience in my youth with strings implemented as trees, so I'm
> biased against complicated string implementations. This also explains
> why I'm no fan of the oft-proposed idea that slices should avoid
> making physical copies even if they make logical copies -- the
Josiah Carlson writes:
> it would be nice if *anyone* were to reply with
> something, *anything*, even "...I have low hopes for something useful
> coming out of this." (my favorite Guido quote, btw) would give me some
> perspective to either acknowledge my insanity, or the other thing.
I think kee
Tim Delaney writes:
> >> Thomas Wouters writes:
> >>> [...] They're
> >>> neutered anyway.
> [snip Michael Chermside ;)]
** Ouch!! **
Squeeky-voicedly yours,
Michael Chermside
___
Python-3000 mailing list
[email protected]
http://mail.python.org
Tim Peters writes:
> IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> for Python to try to define % the same way for ints and floats.
[...]
> I'd like to see this change in Python 3000. Note that IBM's proposed
> standard for decimal arithmetic (which Python's "dec
Michael Chermside wrote:
> No argument here with regard to strings implemented as trees, but I
> think you may be needlessly worried about physical vs logical copies
> for slices. Since strings (and slices of strings) are immutable, the
> implementation is quite simple. Read the Java "String" clas
Michael> So why not make "x % y" for floats behave exactly like it does
Michael> for integers and provide a separate operation with your
Michael> described behavior?
%% anyone?
(Skip ducks and runs...)
Skip
___
Python-3000 mailing list
Pyth
Josiah Carlson wrote:
> I assure you, it takes me far longer to write these messages than it
> takes to read them.
I'm not so sure ;-)
> But it would be nice if *anyone* were to reply with
> something, *anything*, even "...I have low hopes for something useful
> coming out of this." (my favorite
(used the wrong address and first sent it in private to Michael, sorry)
Le mercredi 03 mai 2006 à 04:41 -0700, Michael Chermside a écrit :
> Tim Peters writes:
> > IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> > for Python to try to define % the same way for ints and flo
Michael Chermside wrote:
[on implementing str slices as views]
> > Read the Java "String" class to see
> > just how easy. The slice returns a subclass of str that stores a
> > start and stop position but redirects data access to the buffer used
> > by the original str. The only tricky part is t
Le mercredi 03 mai 2006 à 04:41 -0700, Michael Chermside a écrit :
> Tim Peters writes:
> > IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> > for Python to try to define % the same way for ints and floats.
>[...]
> > I'd like to see this change in Python 3000. N
> From: Raymond Hettinger <[EMAIL PROTECTED]>
> Set literals are not worth committing atrocities elsewhere in the
> language.
I think "atrocities" is a little strong...
> I think Guido had the best solution. Use set() for empty sets, use {}
> for empty dicts, use {genexp} for set comprehensions/
Le mercredi 03 mai 2006 à 09:22 -0400, Greg Wilson a écrit :
> I obviously haven't done the experiment yet, but I can pretty much
> guarantee you that newbies will trip over the inconsistency you're
> proposing:
>
> TypeTwo elementsOne elementEmpty
> List[1, 2]
On 5/3/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> TypeTwo elementsOne elementEmpty
> List[1, 2] [1][]
> Dict{1:'a', 2:'b'} {1:'a'}{}
> Set {1, 2} {1}set()
You left off Tuple
Nick Coghlan wrote:
> Guido van Rossum wrote:
>> This also explains
>> why I'm no fan of the oft-proposed idea that slices should avoid
>> making physical copies even if they make logical copies -- the
>> complexity of that approach horrifies me.)
>
> FWIW, I've now realised it is possible to cre
On Wed, May 03, 2006 at 08:43:45AM -0500, Michael Urman wrote:
> If people are dead set on a set literal, why not look further, to
> atrocities like <1,2>, <1>, <>; @{1,2}, @{1}, @{}; {{1,2}}, {{1}},
> {{}}; etc.? I know there has been resistance to grouped <> before (not
> for sets), but I can't r
On Wed, May 03, 2006, Antoine wrote:
> Le mercredi 03 mai 2006 ? 04:41 -0700, Michael Chermside a ?crit :
>> Tim Peters writes:
>>>
>>> IMO, it was a mistake (and partly my fault cuz I didn't whine early)
>>> for Python to try to define % the same way for ints and floats.
>>[...]
>>> I'
Armin Rigo wrote:
> Hi Seo,
>
> On Tue, May 02, 2006 at 04:02:46PM +0900, Sanghyeon Seo wrote:
>
>> What do you think about this Signature PEP?
>> http://mail.python.org/pipermail/python-3000/2006-April/001249.html
>>
>
> It's a language design issue so it's off topic :-)
>
> More seriously
On 5/2/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I think Guido had the best solution. Use set() for empty sets, use {}
> for empty dicts, use {genexp} for set comprehensions/displays, use
> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> literals. We can always add
On Tue, May 02, 2006 at 09:44:06AM -0700, Guido van Rossum wrote:
> Oops. I lost track of the bytes proto-PEP. CC'ing Neil now -- Neil,
> did you submit that to the PEP editors?
No, just before I wrote it, you suggested that we didn't need to
contact the editors to add a new PEP to the index (just
On 5/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I'm still thinking that it might be a good idea to (optionally) delay de-
> coding of strings until you're actually doing something that needs access
> to the individual characters, though. (UTF-8 to UTF-8 shuffling is an
> increasingly common
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 5/2/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > This is one of the reasons why I'm pushing for some string methods on
> > the bytes object. Even if bytes resize themselves quickly during
> > 'extension', a single allocation with a single pa
On 5/3/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Guido writes:
> > (I had a bad
> > experience in my youth with strings implemented as trees, so I'm
> > biased against complicated string implementations. This also explains
> > why I'm no fan of the oft-proposed idea that slices should avoi
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
>
> On 5/2/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> > I think Guido had the best solution. Use set() for empty sets, use {}
> > for empty dicts, use {genexp} for set comprehensions/displays, use
> > {1,2,3} for explicit set literals, and use {
On 5/2/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 5/2/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >
> > I think Guido had the best solution. Use set() for empty sets, use {}
> > for empty dicts, use {genexp} for set comprehensions/displays, use
> > {1,2,3} for explicit set literals, a
On 5/3/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> I obviously haven't done the experiment yet, but I can pretty much
> guarantee you that newbies will trip over the inconsistency you're
> proposing:
>
> TypeTwo elementsOne elementEmpty
> List[1, 2] [1]
On 5/3/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> I'm not sure we need a comprehension syntax for dicts, but I'm not
> sure we need one for sets either.
Perhaps not. Though in the history of math, set comprehensions were
the inspiration for Python's list comprehensions.
Also, I think we ought to
On 5/3/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > I wonder if that's really true. After all you still pay the overhead
> > for the list. In fact, here's a challenge for you: implement += on
> > bytes to be as fast as the list append + later joi
There is a current thread on notations for sets and dicts. A more
general question is: How should the precious pairs of bracketing
characters,(), {}, and [] be used? Currently, parentheses are used for
grouping, function calls and tuples. Curly brackets are used for
dictionaries and, perhaps in
On 5/3/06, Edward C. Jones <[EMAIL PROTECTED]> wrote:
> There is a current thread on notations for sets and dicts. A more
> general question is: How should the precious pairs of bracketing
> characters,(), {}, and [] be used? Currently, parentheses are used for
> grouping, function calls and tuples
Jim Jewett wrote:
> On 5/2/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>> I think Guido had the best solution. Use set() for empty sets, use
>> {} for empty dicts, use {genexp} for set comprehensions/displays, use
>> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
>> li
I suspect Raymond has plenty of good reasons to shoot this one down.
I'll add a few more: what's the union of {1:1} and {1:2}? The
intersection? The difference? Refuse the temptation to guess!
--Guido
On 5/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
>
> > On 5/2/0
Guido van Rossum wrote:
> I suspect Raymond has plenty of good reasons to shoot this one down.
>
> I'll add a few more: what's the union of {1:1} and {1:2}? The
> intersection? The difference? Refuse the temptation to guess!
Yep - that's a large part of what I meant by the set/dict methods not
c
On 5/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Just wanted to put it out there so it could be shot down quickly (and
> added to PEP 3099) or hailed as the greatest achievement in language
> design ever ;)
You seem to have missed that I already pronounced on this. The new set
syntax
Guido van Rossum wrote:
> On 5/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
>> Just wanted to put it out there so it could be shot down quickly (and
>> added to PEP 3099) or hailed as the greatest achievement in language
>> design ever ;)
>
> You seem to have missed that I already pron
Michael Chermside wrote:
> Providing both operations is a no-brainer. But only one gets to be
> spelled "x % y".
Personally I wouldn't mind if *neither* operation on
floats were spelled x % y. The number of times I can
remember doing a mod on floats is vanishingly small,
and I'd never be able to
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> OK, point taken, for this particular set of parameters (building a 16
> MB string from 1K identical blocks).
>
> But how much slower will the list.append version be if the blocks are
> 10 bytes instead of 1024? That could make a huge difference. (In
Oleg Broytmann wrote:
>I am one of those mouse-haters, and I use keyboard as much as possible.
> All platforms allow me to do it with keyboard shortcuts, default buttons
> and tabs over all widgets.
It's reasonable to have some way of controlling
everything with the keyboard, although it seem
Terry Reedy wrote:
> -the ability to ignore platforn standards and give an app a unique look and
> feel. A start on this, for instance, is being able to give dialog boxes a
> custom background instead of uniform gray or whatever.
You can do this in PyGUI by adding a View that fills the
whole w
Edward C. Jones wrote:
> Does the language need
> more bracketing pairs, perhaps "<<<", ">>>"?
I hope not. I find any use of < and > as brackets to
be ugly, and the more of them there are in a row,
the uglier.
--
Greg Ewing, Computer Science Dept, +--+
Unive
Guido van Rossum wrote:
> I'll add a few more: what's the union of {1:1} and {1:2}?
An exception?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm
> "tomer" == tomer filiba <[EMAIL PROTECTED]> writes:
> read(x) guarantees to return x bytes, or EOFError otherwise (and
> also restoing the stream position).
This would require arbitrarily large buffer for a socket stream. I'm
unsure if that's desiable. Maybe you could move the buff
[Aahz]
> Well, yes, but Uncle Timmy is jumping up and down and screaming for a
> change.
That's a pretty bizarre characterization, if I say so myself. But
since I've already been accused, I may as well live up to it ;-):
> Granted, I think we should show respect for our numerical
> elders, but I
I have not yet posted the PEP 3101 - Advanced String Formatting to
c.l.p. yet because I am still in the process of collecting feedback
from python-dev. My plan is to do a slow escalation of feedback
collection over the course of the next several weeks; As I see it,
there's really no hurry about thi
> "Michael" == Michael Chermside <[EMAIL PROTECTED]> writes:
> What needs to be decided for Py3K is whether to DROP support for
> TK. I am actually mildly in favor of dropping TK support in the
> core if we can make it easy enough to download and install
> separately.
You can't
Given that this PEP is shorter, there is less to discuss. :)
It seems that most people are in favor of the first part of the
proposal, which is relaxing the restriction that *args must come
after any keyword arguments. There is less agreement on the
proposal to have non-defaulted arguments after t
48 matches
Mail list logo
