Tim Peters wrote:
> Let's see. Should I watch a movie now, or search pre-string-method
> archives for quotes nobody really cares about? While I think about
> that ;-), you could look in _this_ thread for:
well, designing things based on how old farts think things where back
in the old days isn'
"Rudy Rudolph" <[EMAIL PROTECTED]> writes:
> def f(inout param):
> param += 5
> return "this is my result"
>
> # call it
> x = 2
> result = f(x)
> # x is now 7
In a dynamically typed language it's not going to work unless both
the parameter in the function defi
On 4/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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
> I don't
> want to make the 90% case require hardly any memorizing of what
> readers I need in what order.
...
> See, this is what I am worried about. I **really** like not having to
> figure out what I need to do to read by lines from a file. If the
> FileStream object had an __iter__ that did
and one small thing i forgot to mention --
file.read/write work with the new bytes() type, while
textfile.read/write work with strings (depends on the encoding)
-tomer
On 4/30/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> > I don't
> > want to make the 90% case require hardly any memorizing of
Le samedi 29 avril 2006 à 21:10 +0200, tomer filiba a écrit :
> and if we do that already, perhaps we should introduce async
> operations as a
> built-in feature? .NET does (BeginRead, EndRead, etc.)
> def async_read(self, count, callback)
> def async_write(self, data, callback)
I think m
On 4/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Python 2.3.5 (#2, Mar 6 2006, 10:12:24)
> [GCC 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> py> import locale
> py> locale.setlocale(locale.LC_ALL, "")
Guido van Rossum wrote:
> But a file with "löwis=1" in it causes a syntax error (even if an
> encoding is specified).
That's because it gets converted to UTF-8 first, and then the UTF-8
bytes don't count as Latin-1 letters.
> I believe this is a quirk of interactive mode only. Certainly the
> lan
I've looked over the PyGUI code a bit more carefully.
It still looks good to me as a Py3K standard portable GUI candidate.
In particular, it doesn't look like it would be hard to port to Java
Swing (for Jython) and Windows.Forms (for IronPython on .NET and
Mono). Might make good summer projects..
> Ron Adam:
> How about the '!' which is currently used indicate a python long and an
> integer. Here it would indicate the difference between a frozen
> container and a mutable container.
> frozen_set = {1, 2, 3}!
> frozen_dict = {1:'a', 2:'b', 3:'c'}!
Greg Wilson:
I mostly don't like
Greg Wilson wrote:
>> Ron Adam:
>> How about the '!' which is currently used indicate a python long and an
>> integer. Here it would indicate the difference between a frozen
>> container and a mutable container.
>> frozen_set = {1, 2, 3}!
>> frozen_dict = {1:'a', 2:'b', 3:'c'}!
>
> Greg
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> In general dict should not be looked at as an example: 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"
>> def async_read(self, count, callback)
>> def async_write(self, data, callback)
>I think many people would be happy if the proposal would use the
>Deferred abstraction which is built in Twisted. :-)
I almost agree. Not sure whether a Defered implementation in python core would be prefe
Bill Janssen wrote:
> I've looked over the PyGUI code a bit more carefully.
>
> It still looks good to me as a Py3K standard portable GUI candidate.
> In particular, it doesn't look like it would be hard to port to Java
> Swing (for Jython) and Windows.Forms (for IronPython on .NET and
> Mono). M
Fredrik Lundh wrote:
> 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.
+1
--
Greg
___
Python-3000 mailing list
[email protected]
http://mail.pyth
On 4/30/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I've looked over the PyGUI code a bit more carefully.
>
> It still looks good to me as a Py3K standard portable GUI candidate.
> In particular, it doesn't look like it would be hard to port to Java
> Swing (for Jython) and Windows.Forms (for Iro
"Bill Janssen" <[EMAIL PROTECTED]> wrote
a reply to my objection to his GUI proposal --
that makes the proposal more sensible to me.
I see you putting forth four propositions. My wording of them is:
1. Python 3 should (still) have a standard lib GUI system.
2a. TK/Tkinter should not be grandf
One of the things that's always puzzled me about Python 2.x is why any
of the following raise a TypeError:
Given a function "def foo(a, b, c=None)",
> foo(4)
> foo(4, 5, 6, 7)
> foo(4, 5, b=6)
> foo(4, 5, d=6)
all raise TypeErrors, as do several other classes of calling errors --
none of which h
Since Py3K is going to considerably change the behavior of the
fundamental collection types, it may be appropriate to revisit the
design of slicing. I would like to start the discussion by
mentioning some of the python 2.x slicing features that I don't
like. I fully anticipate that most
Barry Warsaw wrote:
> Well here's another nutty idea. We actually have two ways to create
> literal tuples, right?
An even nuttier idea: don't use {} at all for sets,
use backquotes instead. No inconsistency for empty
sets would be required then.
set3 = `1, 2, 3`
set1 = `1`
set0 = ``
20 matches
Mail list logo
