Nick Coghlan wrote:
> Kay Schluehr wrote:
>
>> While observing heated discussions about adaption and generic
>> functions I wonder if this
>> is a good opportunity for a modest complaint about the castration of
>> __getattr__ in new style classes.
>
>
> If you want to get full control back, that
Ian Bicking colorstudy.com> writes:
>
> Josiah Carlson wrote:
> > One of the features of generator expressions which makes it desireable
> > instead of list comprehensions is that generator expressions may use
> > less memory *now*, and may be able to start returning results *now*.
> >
> > Usin
Aahz pythoncraft.com> writes:
>
> On Tue, Apr 25, 2006, Brett Cannon wrote:
> >
> > I'll toss in my straw; I have no issue losing listcomps and favoring
> > ``list(genexp)``. TOOWTDI since there is not that huge of a "simple
> > over complex" savings. Probably never thought about this since I
Ian Bicking colorstudy.com> writes:
> > As a hypothetical example, supposed we defined a unary operator '?' such
that:
> >
> > ?x
> >
> > was syntactic sugar for:
> >
> > quoted('x')
> >
> > or even:
> >
> > quoted('x', (scope where x is or would be defined) )
> >
> > Where 'qu
Ian Bicking colorstudy.com> writes:
> > I want to go back for a moment to the original question. Whenever someone
asks
> > me "how should we solve this problem?" the first thing I always ask is "do
we
> > really need to?" Once we've answered that, we can then go on to the issue
of
> > coming up
On Wednesday 26 April 2006 09:03, Talin wrote:
> In my experience dict literals are far more useful than set literals.
> In fact, I don't think I've ever made a set literal. The only
> syntactical short cut that I would find useful for a set would
> be "new empty set", for which I think "set()" is
I've submitted the most recent revisions of the string formatting PEP to the pep
editor; In the mean time, you can read it here:
http://www.viridia.org/python/doc/PEP_AdvancedStringFormatting2.txt
-- Talin
___
Python-3000 mailing list
Python-3000@pyth
Edward Loper wrote:
> One way around this conflict might be to define a new factory function,
> that generates a set from an iterable. I.e., something like:
>
>s = set.from_iter(my_list)
>s = set.from_iter(enumerate(my_list))
>s = set.from_iter(x for x in collection if x>10)
>
> (Bu
Hi all,
How about including wxPython[1] and Wax[2] in the Py3k standard libs
and getting rid of the TK gui stuff?
Also, I think pywin32[3] should be included. Or is there already a way
to use Windows COM objects in Python that I missed?
PIL[4] would be great to have in the standard libs too. But
Kay Schluehr wrote:
> What I'm looking for is capturing the call of an arbitrary special
> method without implementing it explicitely. This would enable delegating
> a call on __add__ to another class that implements __add__. This could
> either be done by empowering __getattribute__ or use the
molasses wrote:
> Hi all,
>
> How about including wxPython[1] and Wax[2] in the Py3k standard libs
> and getting rid of the TK gui stuff?
>
> Also, I think pywin32[3] should be included. Or is there already a way
> to use Windows COM objects in Python that I missed?
>
> PIL[4] would be great to
On Tue, 2006-04-25 at 15:48 -0700, Aahz wrote:
> My opinion: if we were designing Python from scratch right now, we might
> well consider having only set literals and not dict literals. However,
> I don't think we can have both set and dict literals, and I think that
> removing dict literals (or
On Wed, 2006-04-26 at 08:03 +, Talin wrote:
> In my experience dict literals are far more useful than set literals. In
> fact, I
> don't think I've ever made a set literal. The only syntactical short cut that
> I
> would find useful for a set would be "new empty set", for which I think
> "s
> From: Talin <[EMAIL PROTECTED]>
> In my experience dict literals are far more useful than set literals. In
> fact, I
> don't think I've ever made a set literal.
I think this is because:
a) sets are new to Python --- habit and examples both encourage us to use
lists, even when the collection
On Apr 26, 2006, at 5:19 AM, Barry Warsaw wrote:
> On Tue, 2006-04-25 at 15:48 -0700, Aahz wrote:
>
>> My opinion: if we were designing Python from scratch right now, we
>> might
>> well consider having only set literals and not dict literals.
>> However,
>> I don't think we can have both se
Le mercredi 26 avril 2006 à 08:40 -0400, Greg Wilson a écrit :
> I think this is because:
>
> a) sets are new to Python --- habit and examples both encourage us to use
>lists, even when the collections in question aren't intrinsically
>ordered; and
>
> b) the current notation is unpleasan
On Apr 26, 2006, at 4:03 AM, Talin wrote:
> This means using '=' instead of ':' and allowing key names to be
> bare words
> instead of quoted strings.
For my money, this is another use case for symbols in Py3K. I very
often mistype string keys in dicts, where I think I would mistype
symbol
On 4/26/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> 2) set([1,2,3]) makes little sense anyway, since it
> probably isn't significantly more efficient than [1,2,3]
In the current implementation, is is less efficient.
But a set is what you really intend; using a list simply because it is
curren
On Tuesday 2006-04-25 20:20, Tim Peters wrote:
> Now you can only use a set if you can prove it exists, and one way to
> prove a set exists is via what was once called the Axiom of
> Comprehsion (but seems to be called the Axiom of Subsets more often
> these days). That says that if you have a se
Toby Dickenson wrote:
> On Wednesday 26 April 2006 09:03, Talin wrote:
>
>
>>In my experience dict literals are far more useful than set literals.
>>In fact, I don't think I've ever made a set literal. The only
>>syntactical short cut that I would find useful for a set would
>>be "new empty set",
Le mercredi 26 avril 2006 à 11:38 -0400, Jim Jewett a écrit :
> (2) How to make set usage at least as efficient.
> (3) Whether the tradeoffs are worth it.
Well, testing for inclusion in a container of 3 ints may not be
significant vs. all the overhead of the interpreter and vs. what you are
act
On 4/25/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> I think that a significant motivation for people that propose set
> literals is that the following is just plain ugly:
>
> s = set([1,2,3])
>
> It seems much more natural to write:
>
> s = set(1, 2, 3)
>
>s = set.from_iter(my_list)
>
Jim Jewett wrote:
> On 4/26/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
>>2) set([1,2,3]) makes little sense anyway, since it
>>probably isn't significantly more efficient than [1,2,3]
>
>
> In the current implementation, is is less efficient.
>
> But a set is what you really intend; using
Talin wrote:
>>>Where 'quoted' was some sort of class that behaved like a reference to a
>>>variable. So ?x.set( 1 ) is the same as x = 1.
>>
>>Sounds like lambda x: ...
>
>
> More differences than similarities, I think. For one thing, you can't use
> lambda x: ... to assign to x. And while you c
On 4/26/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> That's why I said "*significantly* more efficient" : I think both 3-int
> lists and 3-int sets are fast enough, aren't they ?
Raymond H should answer this; my memory is that he changed some
library code (or the compiler as a peephole optimiz
Talin wrote:
> Ian Bicking colorstudy.com> writes:
>>>I want to go back for a moment to the original question. Whenever someone
>>>asks
>>>me "how should we solve this problem?" the first thing I always ask is "do we
>>>really need to?" Once we've answered that, we can then go on to the issue of
Nick Coghlan wrote:
> I suspect the right answer to that is to provide better metaprogramming tools
> to make writing proxy objects easier, rather than providing additional
> fallback paths for the special methods in the interpreter (as the latter
> slows
> down the common case to benefit the c
Talin writes:
> 2) I noticed in your PEP that you followed the same mental model as is
currently
> used in the compiler, which is that *args and **args are treated as special
> cases. In other words, the description of a function's arguments consists of
an
> array of "regular" arguments, plus a cou
On Wed, 2006-04-26 at 12:07 -0400, Jim Jewett wrote:
> Alternatively, define a classmethod for the literal form. For me,
> even the much longer
>
> s = set.literal(1, 2, 3)
Or how about just set.new(1, 2, 3) ?
not-sure-it's-worth-it-ly y'rs,
-Barry
signature.asc
Description: This is a d
Edward Loper wrote:
>I think that a significant motivation for people that propose set
>literals is that the following is just plain ugly:
>
>s = set([1,2,3])
>
>It seems much more natural to write:
>
>s = set(1, 2, 3)
>
>However, it is fairly common to want to build a set from a collecti
Edward Loper <[EMAIL PROTECTED]> wrote:
>
> I think that a significant motivation for people that propose set
> literals is that the following is just plain ugly:
>
> s = set([1,2,3])
>
> It seems much more natural to write:
>
> s = set(1, 2, 3)
I agree.
> However, it is fairly comm
Talin <[EMAIL PROTECTED]> wrote:
> Ian Bicking colorstudy.com> writes:
> > Josiah Carlson wrote:
> > > One of the features of generator expressions which makes it desireable
> > > instead of list comprehensions is that generator expressions may use
> > > less memory *now*, and may be able to star
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>
>>Ian Bicking colorstudy.com> writes:
>>
>>>Josiah Carlson wrote:
>>>
One of the features of generator expressions which makes it desireable
instead of list comprehensions is that generator expressions may use
less memory *now
Ian Bicking <[EMAIL PROTECTED]> wrote:
>Josiah Carlson wrote:
> >Talin <[EMAIL PROTECTED]> wrote:
> >>Ian Bicking colorstudy.com> writes:
> >>>Josiah Carlson wrote:
> >>>
> One of the features of generator expressions which makes it desireable
> instead of list comprehensions is that gene
Josiah Carlson wrote:
>>It's not a huge difference, but to argue that it's unnecessary because
>>sorted() exists is the same as arguing that list/generator
>>comprehensions are unnecessary because of map/imap and filter/ifilter.
>
>
> You can draw parallels as to why my argument vis-a-vis sorte
On 4/26/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Edward Loper <[EMAIL PROTECTED]> wrote:
> >
> > I think that a significant motivation for people that propose set
> > literals is that the following is just plain ugly:
> >
> > s = set([1,2,3])
> >
> > It seems much more natural to write
Let me be the one to say no for a change.
Python 3000 will *not* add syntax to get generator expressions or list
(or set) comprehensions sorted. There is exactly one sort algorithm,
and it is list.sort(). There are exactly two sort APIs, the other
being the built-in sorted(). That's enough.
--
--
Ian Bicking <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Is this desireable? As I said above, yes. Is it a compelling syntax
> > addition? I don't believe so. Do Ian and Talin believe it compelling?
> > It would seem so. The question remains whether others also find it a
> > compelli
Agreed. set(), like list() and tuple(), should take exactly one
argument, which is an iterable providing the set elements.
Class methods are pretty ugly and should be limited to cases that are
rare but nevertheless useful -- dict.fromkeys saves a builtin and
that's about all there is to say in its
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 4/26/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Edward Loper <[EMAIL PROTECTED]> wrote:
> > >
> > > I think that a significant motivation for people that propose set
> > > literals is that the following is just plain ugly:
> > >
> > >
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Curiously, min() and max() successfully use the same overloading.
> However, these don't have the same problem, because min() or max() of
> one value makes no sense,
The expressions 'min(x)' and 'max(x)', x an order
On 4/26/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Indeed, but only with immutable iterable sequences. Mutable iterable
> sequences are unambiguous (they don't hash(), so can't be an entry in
> and of themselves).
Unfortunately, generator expressions happen to have a (useless) hash value.
>
Guido van Rossum wrote:
> I don't think this form (set(1, 2, 3)) will ever fly, because it would
> makes set(x) ambiguous.
For what it's worth, under the changes I was proposing set(x) would be
unambiguous -- it would mean a set containing the single element x. A
separate class method would be
On 4/26/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I don't think this form (set(1, 2, 3)) will ever fly, because it would
> > makes set(x) ambiguous.
>
> For what it's worth, under the changes I was proposing set(x) would be
> unambiguous -- it would mean a set contai
Greg Wilson cs.utoronto.ca> writes:
> Hi Guido,
>
> > On 4/24/06, Greg Wilson cs.utoronto.ca> wrote:
> > > On a completely different note, are you willing to consider native
> > > syntax for sets (as per PEP 218) in Python 3000?
>
> > I like to write {1, 2, 3} instead of set([1, 2, 3]) but I d
On 4/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> This is worth thinking about. Recently when pondering the
> question of when it would or would not be appropriate to
> put in type assertions to help catch bugs, I concluded
> that it makes the most sense to do so when building a
> data structure,
On 4/26/06, Talin <[EMAIL PROTECTED]> wrote:
> A set with a single element is:
>
>{1,}
>
> In other words, we steal the idea from tuples - a trailing comma is used as a
> way to signal that this is a comma-separated list of one item.
There's no need for this; there's no ambiguity. The ambiguit
Sorry for the belated response. Yes, I'd like to see this PEP. I'll
probably eventually end up rewriting it :-), but right now I'm
terribly overcommitted and really appreciate the help!!!
--Guido
On 4/24/06, Bill Birch <[EMAIL PROTECTED]> wrote:
> The optional static typing blog
> http://www.arti
On 4/26/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> 1) sets are most often built dynamically rather than statically (in my
> own experience)
The same is true to the same extent for lists and dicts.
And yet there are many uses for list and dict literals.
I've seen a lot of list and tuple lite
Talin schrieb:
>A set with no elements is:
>
> set()
>
>Alternatively, you could take the tuple idea one step further:
>
> {,}
>
>
If you want to simulate the mathematical notion of an empty set I would
say that {/} has a stronger mnemonic appeal.
Furthermore: what about notions of infinite
50 matches
Mail list logo
