Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> 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] w
Kay Schluehr wrote:
> 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.
It al
> A set with no elements is:
>set()
I prefer Guido's earlier suggestion of {/} for the empty set (assuming no
parsing ambiguities?):
a) requiring 'set()' for empty sets is inconsistent with (), [], {} for
empty collections of other kinds
b) {/} kind of looks like phi (circle with a slash
On Thursday 2006-04-27 11:42, Georg Brandl wrote:
> Kay Schluehr wrote:
...
> > Furthermore: what about notions of infinite sets?
>
> Can you elaborate on that?
Seems to me that if you want infinite sets, you want some type
other than "set". Ah, the wonders of duck typing. (Just as if
you want ma
Michael Chermside wrote:
> Brett responds:
>> Yeah, I see what you are saying. But I actually held this view long
>> before Iearned how Python did things underneath the covers.
>>
>> I have no clue how people tend to view things. Anyone else care to
>> comment on how they tend to see arguments?
>
Greg Wilson wrote:
>> A set with no elements is:
>>set()
>
> I prefer Guido's earlier suggestion of {/} for the empty set (assuming no
> parsing ambiguities?):
I believe the leading '{' should be enough to clue the parser in to what's
going on (i.e. '{/' is currently a syntax error)
I think
Guido van Rossum wrote:
> 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.
>
Nick Coghlan wrote:
> I think I'm a convert - +1 for set literals, with {/} for the empty set.
I'm +1 on set literals, but -1 on {/} for the empty set. I much prefer
set() -- {/} seems too Perlesque and magical-looking. I don't think we
have three subsequent punctuation marks as an atom anywhere e
Georg just added the idea of automatically invoking str() in str.join() to PEP
3100 with a question mark on the end. I thought I'd responded when Talin first
brought it up, but couldn't find a record of that in the archive (this is why
one suggestion per message is a good idea ;)
I tried to imp
Ivan Krstic wrote:
> Nick Coghlan wrote:
>> I think I'm a convert - +1 for set literals, with {/} for the empty set.
>
> I'm +1 on set literals, but -1 on {/} for the empty set. I much prefer
> set() -- {/} seems too Perlesque and magical-looking.
I could certainly live with set(). The ASCII-art
Nick Coghlan wrote:
> Georg just added the idea of automatically invoking str() in str.join() to
> PEP
> 3100 with a question mark on the end. I thought I'd responded when Talin
> first
> brought it up, but couldn't find a record of that in the archive (this is why
> one suggestion per message
Giovanni Bajo wrote:
> > Since this is still well into the future, by the time Py3k rolls
> > around it might be possible to include the option of easy-installing
> > various packages from the Python installer.
>
> As usually said, this would be miss the *main* point of having a standard
> library
Crutcher Dunnavant wrote:
> Having been shot down so hard on my request to bring for loops into
> symetry with list comprehensions, I have a new proposal - stackable
> blocks.
>
> This is a very _small_ amount of syntax sugar, the basic idea is that
> any block headers can be stacked on the same l
Georg Brandl wrote:
> As a side note, I named the thing "string.join()" because I didn't know what
> to
> write.
join()
it's time to make this a builtin. the "it's the separator that's doing the
joining" idea is silly and unintuitive, and should be fixed.
_
Fredrik Lundh wrote:
> it's time to make this a builtin. the "it's the separator that's doing the
> joining" idea is silly and unintuitive, and should be fixed.
+1 on this; I've thought this for a long time.
--
Ivan Krstic <[EMAIL PROTECTED]> | GPG: 0x147C722D
__
Ivan Krstic wrote:
>Fredrik Lundh wrote:
>
>
>>it's time to make this a builtin. the "it's the separator that's doing the
>>joining" idea is silly and unintuitive, and should be fixed.
>>
>>
>
>+1 on this; I've thought this for a long time.
>
>
>
Strong +1.
This fixes a long-standing micr
Nick Coghlan gmail.com> writes:
> > My mental model matches Brett's.
>
> I think of them as separate things, too. Separate attributes also makes it
> easier to add additional metadata later, and the structure of each attribute
> can be well-defined.
>
> For example, given:
>
> def f(req:int,
On Thu, Apr 27, 2006, Raymond Hettinger wrote:
> Ivan Krstic wrote:
>>Fredrik Lundh wrote:
>>>
>>>it's time to make this a builtin. the "it's the separator that's doing the
>>>joining" idea is silly and unintuitive, and should be fixed.
>>
>>+1 on this; I've thought this for a long time.
>
> Stron
On Thu, 2006-04-27 at 10:08 -0700, Aahz wrote:
> While I hate the way it looks, I never have gotten mixed up about the
> order of arguments since switching to ''.join(l).
Which is why
EMPTYSTRING = ''
...
EMPTYSTRING.join(seq)
looks much better. But hey, yeah, a join() builtin would be fine
Nick Coghlan wrote:
> Another point in favour of set literals is that they let an optimising
> compiler play games because the compiler knows that the contents of
> that literal are supposed to be hashable, even if it can't resolve
> them right now, and it knows that the result is going to be an a
On 4/27/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-04-27 at 10:08 -0700, Aahz wrote:
>
> > While I hate the way it looks, I never have gotten mixed up about the
> > order of arguments since switching to ''.join(l).
>
> Which is why
>
> EMPTYSTRING = ''
>
> ...
>
> EMPTYSTRING.join(s
Barry Warsaw wrote:
> On Thu, 2006-04-27 at 10:08 -0700, Aahz wrote:
>> -0
>>
>>
>>While I hate the way it looks, I never have gotten mixed up about the
>>order of arguments since switching to ''.join(l).
Me too on all counts including the -0.
>
>
> Which is why
>
> EMPTYSTRING = ''
>
> ..
On 4/27/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> As a side note, I named the thing "string.join()" because I didn't know what
> to
> write. The str type will be dead, and I assume that the new string type will
> have a different name.
>
> Will it be "unicode"? Or "text"? Or "string"?
"str" o
[Barry Warsaw]
>> ...
>> While I hate the way it looks, I never have gotten mixed up about the
>> order of arguments since switching to ''.join(l).
[Tim Hochberg]
> Me too on all counts including the -0.
>> ...
>> But hey, yeah, a join() builtin would be fine if it
>> took the string arg first, s
On 4/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ... the dict constructor signature is
> already too far overloaded, giving a different meaning to keyword
> args, and distinguishing between a mapping and a sequence is iffy: it
> requires a "keys" method which is kind of sub-optimal compare
Tim Peters wrote:
> > In which case why would we need a builtin?
>
> Because people enjoy arguing about the best order for the arguments,
> and about the best default separator value, neither of which you _can_
> argue about in the method spelling ;-)
no, because people enjoy writing readable cod
At 07:16 PM 4/27/2006 +0200, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> But hey, yeah, a join() builtin would be fine if it
>took the string arg first, so that
>
>''.join(seq) == join('', seq)
And thanks to the time machine, str.join('', seq) does this already:
Python 2.2.2 (#1, Feb 24 2003, 19:1
[pep-3100 checkin]
> {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
I presume this means that there will never be dictionary comprehensions (as
they would aspire to have an identical notation).
> There's no frozenset literal; they are too rarely needed.
Actually, they are one
[Fredrik Lundh]
> no, because people enjoy writing readable code. doing things by exe-
> cuting methods attached to literals isn't very readable, and isn't used
> for anything else.
As Barry often says, he spells it TAB.join() or BLANK.join() (etc)
instead. That's very readable.
> I don't think
On 4/27/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [pep-3100 checkin]
> > {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
>
> I presume this means that there will never be dictionary
> comprehensions (as they would aspire to have an identical
> notation).
Why would that be n
Phillip J. Eby wrote:
> And thanks to the time machine, str.join('', seq) does this already:
>
> Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
> [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> str.join('',['a','b','c
On Thu, Apr 27, 2006 at 10:18:23AM -0700, Alex Martelli wrote:
> On 4/27/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > On Thu, 2006-04-27 at 10:08 -0700, Aahz wrote:
> >
> > > While I hate the way it looks, I never have gotten mixed up about the
> > > order of arguments since switching to ''.join
On 4/27/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
>
> > And thanks to the time machine, str.join('', seq) does this already:
> >
> > Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
> > [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
> > Type "help", "copyright", "credits"
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> hopefully, the Py3K distributors will use semi-automatic tools to
> download
> all they need to build a battery-included release. pushing all that over
> to
> the end users would be a major mistake.
> (python-dev and
Raymond Hettinger wrote:
> [pep-3100 checkin]
>> {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
>
> I presume this means that there will never be dictionary comprehensions (as
> they would aspire to have an identical notation).
>
>
>
>> There's no frozenset literal; they are t
On 4/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> I think it's been suggested before that there should be a PY2.x to PY3.x
> conversion utility to facilitate the move to PY3K. So maybe a sticking
> point as when to *not* do something would be, if it's not possible to
> translate a changed 2.x feat
On Thu, 2006-04-27 at 11:49 -0700, Raymond Hettinger wrote:
> [pep-3100 checkin]
> > {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
>
> I presume this means that there will never be dictionary
> comprehensions (as they would aspire to have an identical notation).
>
>
>
> > Ther
On Thu, 2006-04-27 at 12:57 -0600, Steven Bethard wrote:
> On 4/27/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > [pep-3100 checkin]
> > > {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)).
> >
> > I presume this means that there will never be dictionary
> > comprehensions (as the
On Thu, 2006-04-27 at 16:44 -0400, Barry Warsaw wrote:
> for x in (1, 2, 3, 5, 7, 11)
Uh, ignore that. Order matters.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-3000 mailing list
Python-3000@python.org
Guido van Rossum wrote:
> On 4/27/06, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I think it's been suggested before that there should be a PY2.x to PY3.x
>> conversion utility to facilitate the move to PY3K. So maybe a sticking
>> point as when to *not* do something would be, if it's not possible to
>
I just read PEP 3002 and while I like most of what I see (thanks
Steven Bethard!) there's one section that stands out as problematic.
I'm quoting it here:
"""
Optional Extensions
===
Instead of the python3warn.py script, a branch of Python 3000 could be
maintained that added warni
Ron Adam a écrit :
> Raymond Hettinger wrote:
>>I forsee {} vs {/} as being a prominent entry on everyone's list of Python
>>pitfalls, faqs, and common errors. Maybe PyLint or PyChecker will be able to
>>scan to see how the object is used and determine whether the two were
>>mixed-up.
>>
>
> I
Barry Warsaw wrote:
> Okay, radical/insane/heretical question time: do we really need literal
> tuple syntax? IOW, what if (1, 2, 3) created a frozenset instead of a
> tuple?
>
> Or perhaps an even stupider idea: what if the compiler could recognize
> certain use cases and generate different type
Barry Warsaw python.org> writes:
> Or perhaps an even stupider idea: what if the compiler could recognize
> certain use cases and generate different types depending on how the
> object is used.
Hey! If anyone is going to post stupid ideas to this list, it's gonne be ME!
Got that?
Speaking of w
On Thu, 2006-04-27 at 16:05 -0700, Eli Stevens (WG.c) wrote:
> I think you'd have to create a tuple, and convert it to a set on the
> fly. Which should x be in the following:
>
> x = (1, 2, 1)
> dictOfCallables["foo"](x)
Well here's another nutty idea. We actually have two ways to create
lite
On Thu, 2006-04-27 at 10:18 -0700, Alex Martelli wrote:
> > ''.join(seq) == join('', seq)
>
> I think I would prefer a signature of:
> join(seq, joiner='')
Except that I think it would be a mistake to have that and keep
the .join() method on strings because that would increase the confusion
On 4/27/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Crutcher Dunnavant wrote:
> > Having been shot down so hard on my request to bring for loops into
> > symetry with list comprehensions, I have a new proposal - stackable
> > blocks.
> >
> > This is a very _small_ amount of syntax sugar, the basi
Baptiste> Actually I think we need both {/} as the empty set and {:} as
Baptiste> the empty dict.
Baptiste> {} should raise SyntaxError, '{} is ambiguous, use {/} for
Baptiste> set, {:} for dict'
Piggybacking on this post and Barry's heretical ideas, (/) looks more like
the null
Barry> x = 1, 2, 3
Barry> x = (1, 2, 3)
Barry> So let's keep the first and hijack the second to be set
Barry> constructor notation.
This is a fairly common error:
x = 1,
For that reason I prefer to always use parens for tuple literals.
Skip
[Alex Martelli, suggests that a functional join's default
separator be the empty string]
>> Rationale: an emptystring joiner is the most frequent cases, but
>> several others (space, newline, space-comma, ...) occur often enough
>> to be worth allowing the joiner to be optionally specified.
[Barr
On 4/27/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Fredrik Lundh]
> > no, because people enjoy writing readable code. doing things by exe-
> > cuting methods attached to literals isn't very readable, and isn't used
> > for anything else.
>
> As Barry often says, he spells it TAB.join() or BLANK.
On 4/27/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 4/27/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > On Thu, 2006-04-27 at 10:08 -0700, Aahz wrote:
> >
> > > While I hate the way it looks, I never have gotten mixed up about the
> > > order of arguments since switching to ''.join(l).
> >
>
Specifically, I'm thinking of the 300MHz Palm TX sitting on the table
beside me, which should be more than powerful enough to run Python, but
in general I think it should be easier to cross-compile Python for new
architectures. I've taken a stab at it, and perhaps it's because I
don't have eno
Blake,
What problems did you have? There is a patch or two up on SF that
address some of the issues.
I know of some problems, but we don't have a volunteer to work on
these issues. So if you could be that volunteer, maybe we could solve
this problem. Not for 3.0 in the future, but for 2.5 toda
On 4/27/06, Talin <[EMAIL PROTECTED]> wrote:
> Nick Coghlan gmail.com> writes:
>
> > > My mental model matches Brett's.
> >
> > I think of them as separate things, too. Separate attributes also makes it
> > easier to add additional metadata later, and the structure of each attribute
> > can be wel
I mentioned this a couple of weeks ago, and here it is again.
The biggest wart in Python 2, the one that forces me to use another
language, is the lack of a standard GUI. By standard, I mean that
when you install Python on a system, the GUI toolkit is also
installed.
I suggest that for Python 3K
"Brett Cannon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I wouldn't want it added without ditching the other two versions as
> well. Personally I would be fine if string.join() stayed and we
> considered removing str.join() and just made the string module more
> prominent (af
"Crutcher Dunnavant" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I don't really care how it gets spelled. In the current system, I
> _have_ to break the context spec up on multiple lines,
I consider that a plus. It is part of Python's basic indented statement
structure, which
On 4/27/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Crutcher Dunnavant" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > I don't really care how it gets spelled. In the current system, I
> > _have_ to break the context spec up on multiple lines,
>
> I consider that a plus. It
[EMAIL PROTECTED] schrieb:
>Piggybacking on this post and Barry's heretical ideas, (/) looks more like
>the null set to me... Actually, if Py3k is going to be Unicode only, why
>not use Ø as the null set? ;-)
>
>
Yes, Py3K + Unicode rulez! I'm +1 on this but not before having a Py3K
keyboard :
Guido van Rossum schrieb:
>I suppose the PEP 3002 proposal was written with the assumption that a
>*syntactic* conversion would be doable purely mechanically, and that
>the semantic issues would be sorted out using a second phase tool.
>
I have a question towards the syntax/semantics distinction
61 matches
Mail list logo
