On 4/27/06, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> 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
> o
Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> 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 to
On Thu, Apr 27, 2006 at 04:02:14PM -0400, Terry Reedy wrote:
> The initial download for Internet Explorer
> updates is less than a megabyte. It looks at what you have and displays a
> menu of optional components, and then downloads and installs the 15-30
> megabytes actually needed.
Thus ma
Mike> I particularly dislike any notion of using a phi or phi-like
Mike> symbol to represent python set construction.
You did notice the ;-) in my post on that topic, right? That was meant to
imply it wasn't a serious proposal. Being a US programmer myself, I
understand that typing Ø
Tim Peters wrote:
>> I don't think anyone on this list can take the "but if there's more than
>> one argument, *I* am going to be confused" argument seriously.
>
> Then you don't remember that the order of arguments here _was_ a
> frequent confusion in the old days.
nope.
any pointers ?
__
Terry Reedy wrote:
>> 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 others could provide "profiles" for well-known and teste
OK, OK, just so I can get it off my chest:
- introduce '@' as a prefix operator meaning 'freeze'.
- [1, 2, 3] is a mutable sequence (our old friend the list)
- {1, 2, 3} is a mutable set
- @{1, 2, 3} is an immutable set (i.e., a frozen set --- frozen
at creation, so all current optimizations
On Apr 27, 2006, at 7:47 PM, Talin wrote:
> Or alternatively, the Pascal notation:
>
> 1..10
+1..2 :>
Cheers,
Kendall
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://m
Sets and dicts are similar beasts, right? "A set object is an
unordered collection of immutable values." Dicts can be described as
sets with lookup values associated with the keys. Sets can be
described as dicts with only keys, no values.
So how about creating a new base set/mapping type (call
On 4/27/06, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Yes, Py3K + Unicode rulez! I'm +1 on this but not before having a Py3K
> keyboard :)
I know you were only joking in a dreamy sort of way; but I have a
serious point to make against Unicode in the language source code.
*Supporting* Unicode is v
On Fri, Apr 28, 2006 at 01:02:44AM -0400, Terry Reedy wrote:
>
> "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
Barry writes:
> Well here's another nutty idea. We actually have two ways to create
> literal tuples, right?
>
> x = 1, 2, 3
> x = (1, 2, 3)
>
> So let's keep the first and hijack the second to be set constructor
> notation.
Nutty and wrong (but don't let that stop you from continuing to
think up
On 4/28/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> - introduce '@' as a prefix operator meaning 'freeze'.
I mostly like the concept, but not the operator. Using @ limits it to
syntax-created literals (because of ambiguity with decorators). Since
numbers are already immutable, that basically me
> Guido van Rossum:
> Hopefully Python 4000 will be designed in a different world.
When the first (and only) Cray-3 was delivered, Seymour Cray announced
that he had already started designing the Cray-4, and that he was planning
to use the planet Neptune as a cooling system... ;-)
Greg
__
> Python already comes with a standard GUI toolkit; tk.
With a decidedly unpythonic bad interface. And it's not standard; I
frequently find Python installations where no one has installed Tk.
Pardon me for being blunt: Tkinter is a half-assed "solution" that's
set Python back for years.
> Also
Jim Jewett wrote:
> On 4/28/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
>> - introduce '@' as a prefix operator meaning 'freeze'.
>
> I mostly like the concept, but not the operator. Using @ limits it to
> syntax-created literals (because of ambiguity with decorators). Since
> numbers are already
On 4/28/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> > If it is really limited to literals, then I'm not sure it matters; the
> > freeze should have the only reference.
> I'd like to say:
> x = 123 and x's value will never ever change
> Opens up lots of optimization possibilities, and makes cod
> > Greg Wilson:
> > I'd like to say:
> > x = 123 and x's value will never ever change
> > Opens up lots of optimization possibilities, and makes code much safer.
> Jim Jewett:
> So now were back to looking for a const marker.
Greg Wilson:
Yep. But I'm happy to stick to arguing about set litera
There's a new SoC mailing list.
[EMAIL PROTECTED]
You can sign up here: http://mail.python.org/mailman/listinfo/soc2006
This list is for any SoC discussion: mentors, students, idea, etc.
Student can submit applications starting May 1, so now is the time to
get students interested in your
"Bill Janssen" <[EMAIL PROTECTED]> wrote in message
news:06Apr28.101121pdt."58641"@synergy1.parc.xerox.com...
>> PyGUI doesn't have nearly the market
>> penetration (into the Python GUI toolkit area) to justify its inclusion
>> into the python standard library.
>
> Doesn't matter. Putting it int
On 4/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/28/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> > - introduce '@' as a prefix operator meaning 'freeze'.
>
> I mostly like the concept, but not the operator.
Let me go on record as not liking the concept. IMO it's usually a
mistake to want t
On 4/23/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> So for instance this:
>
> for file in open_files:
> if file.readable():
> ...
>
> can be spelled like this.
>
> for file in open_files: if file.readable():
> ...
Since this discussion is still going on, let me add my -1 in the hop
> On 4/28/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
>> - introduce '@' as a prefix operator meaning 'freeze'.
Nice idea, but is it possible to be more radical ?
How about having all the existing literal syntaxes produce frozen containers,
using explicit calls to dict(), set(), list(), etc, to cre
Guido van Rossum wrote:
> I want good Unicode support for string literals and comments.
> Everything else in the language ought to be ASCII.
Does that include restricting identifiers to ASCII as well?
I was hoping to propose a PEP on non-ASCII identifiers some
day; that would (of course) include
Neal Norwitz wrote:
> 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
On 4/28/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I want good Unicode support for string literals and comments.
> > Everything else in the language ought to be ASCII.
>
> Does that include restricting identifiers to ASCII as well?
Yes, that's my intent.
> I wa
On Fri, Apr 28, 2006 at 08:09:24AM -0400, Greg Wilson wrote:
> OK, OK, just so I can get it off my chest:
>
> - introduce '@' as a prefix operator meaning 'freeze'.
>
> - [1, 2, 3] is a mutable sequence (our old friend the list)
>
> - {1, 2, 3} is a mutable set
>
> - @{1, 2, 3} is an immutable
On 4/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> You did notice the ;-) in my post on that topic, right? That was meant to
> imply it wasn't a serious proposal.
Sure did . I'd be shocked if non-ascii punctuation was ever
seriously considered. But ascii phi-like things have been propo
Guido van Rossum wrote:
>> I was hoping to propose a PEP on non-ASCII identifiers some
>> day; that would (of course) include a requirement that the
>> standard library would always be restricted to ASCII-only
>> identifiers as a style-guide.
>
> IMO communication about code becomes much more cumb
i've seen discussion about improving the IO stack of python, to rely less on
the low-level lib-c implementation. so, i wanted to share my ideas in
that niche.
i feel today's sockets are way *outdated* and overloaded. python's sockets are
basically a wrapper for the low-level BSD sockets... but IMH
Brian Harring wrote:
>Potentially a stupid question, but I've been following this thread for
>a while and I'm still not seeing the real gain of extending the syntax
>for frozen markers/set literals.
>
>Someone care to recap what actually is gained from having a set
>literal?
>~harring
>
>
Go
On 4/28/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >> I was hoping to propose a PEP on non-ASCII identifiers some
> >> day; that would (of course) include a requirement that the
> >> standard library would always be restricted to ASCII-only
> >> identifiers as a st
Good ideas. Sockets follow the C API to the letter; this was a good
idea when I first created the socket extension module, but nowadays it
doesn't feel right. Also, the socket.py module contains a lot of code
(a whole buffering file implementation!) that ought to be subsumed
into the new I/O stack.
Le vendredi 28 avril 2006 à 15:12 -0400, Terry Reedy a écrit :
> The generic solution is better package fetching, such as apparently done (I
> have not used them yet) by setuptools and easy_install. The installing an
> app needing wxPython should fetch and install that also and installing an
>
tomer filiba wrote:
> Each protocol would subclass {Stream/Dgram/Raw}Socket
> and add its protocol-specific options.
>
> here's an example for a hierarchy:
> Socket
> RawSocket
> DgramSocket
> UDPSocket
> StreamSocket
> TCPSocket
> SSLSocket
My one small co
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Better not ship a "standard GUI system" and let everybody choose,
> IMHO.
In this case, I agree.
There is simply no good enough solution for a GUI. There are far too many
advanced different libraries with different wrappers. Some are portable, some
are
Antoine Pitrou wrote:
> I don't see what the problem is with installing wxPython separately from
> Python. There are installers for Windows, and any decent Linux distro
> packages it (so you can just type "urpmi wxPython" or whatever). Also,
> py2exe and py2app handle it gracefully if you want to s
If you move forward with this, please review (learn from and steal the
best parts of) the ACE APIs. http://cs.wustl.edu/~schmidt/ACE.html
They've done a lot of work in this area and have a lot of experience.
It would also be good to talk to the twisted guys.
We should also support epoll beyond
Guido van Rossum wrote:
>> The distinction of letters and digits is also straight-forward:
>> a digit is ASCII [0-9]; it's a separate lexical class only
>> because it plays a special role in (number) literals. More
>> generally, there is the distinction of starter and non-starter
>> characters.
>
Raymond Hettinger wrote:
> The only bump in the road is that the {} notation is so similar to
> dictionaries that care must be taken to keep the two as distinct as
> possible.
Here's a summary of the suggestions we've seen so far for empty sets & dicts
Possibilities for an empty set:
set() - e
On 4/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> {} however, can appear only standalone. It is not permitted for it to follow
> an expression. If we change that, we can use it to support an alternate
> invocation syntax for functions that currently expect an iterable as their
> first argument.
Maybe it's just me, but I've previously implemented much of this with
asyncore subclasses. While I didn't go all-out on the properties (I
never need to change the underlying options beyond setting it as
non-blocking), I did end up with a fairly standard __init__ signature
that solved many of my a
[Fredrik]
>>> I don't think anyone on this list can take the "but if there's more than
>>> one argument, *I* am going to be confused" argument seriously.
[Tim]
>> Then you don't remember that the order of arguments here _was_ a
>> frequent confusion in the old days.
[Fredrik]
> nope.
>
> any poin
Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> > Python already comes with a standard GUI toolkit; tk.
>
> With a decidedly unpythonic bad interface. And it's not standard; I
> frequently find Python installations where no one has installed Tk.
> Pardon me for being blunt: Tkinter is a half-assed
44 matches
Mail list logo
