I'm starting up a continuous build of sorts on the PSF machine for the
3k branch. Right now the failures will only go to me. I've excluded
the two tests that are known to currently fail. This will help us
find new failures (including ref leaks). Probably in a week or so
I'll send the results to
On 5/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I just fixed the doctest failures; but for the compiler package I
> > need help. Would you have the time?
>
> I don't really know the compiler package at all. I'll have a look, but
> it's going to take me a while to e
Guido van Rossum wrote:
> On 5/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Thanks for checking in xrange! Woot!
>> >
>> > test_compiler and test_transformer are waiting for someone to clean up
>> > the compiler package (I forget what it doesn't support, perhape
Yes, I have read Swift :-) And in that spirit, I don't know whether to take
this proposal seriously because it's kind of radical. Nevertheless, here
goes...
It has occurred to me that as Python stands today, an indent always begins
with a colon. So in principle, we could define anything that lo
Daniel Stutzbach wrote:
> The use came I'm thinking of is this:
>
> A container type or an iterable where the first few entries contain
> one type of information, and the rest of the entries are something
> that will either be discard or run through for-loop.
If you know you're dealing with an i
>> 1. in Grammar changes: Each shortstringchar or longstringchar must
>>be a character whose Unicode ordinal value is between 1 and
>>127 inclusive.
>
> Sounds like a good fix to me; I agree that bytes literals, like
> Unicode literals, should not vary depending on the source encoding. In
On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> That's not symmetric. readline() returns a string that includes a
> trailing \n even if the actual file contained \r or \r\n. write()
> already is supposed to translate \n anywhere (not just at the end of
> the line) into the specified or pla
On 5/7/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > And what do you return when it doesn't support the container protocol?
>
> Assign the iterator object with the remaining items to d.
>
> > Think about the use cases. It seems that *yo
On 5/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
[...]
> This PEP proposes class decorators, an extension to the function
> and method decorators introduced in PEP 318.
[...]
> The semantics and design goals of class decorators are the same as
> for function decorators ([#semantics]_, [#goals]_)
On 5/7/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> my original idea about the new i/o foundation was more elaborate
> than the pep, but i have to admit the pep is more feasible and
> compact. some comments though:
>
> writeline
> -
> TextIOBase should grow a writeline(
Guido pointed out that this PEP hadn't been sent to the list yet.
Abstract
This PEP proposes class decorators, an extension to the function
and method decorators introduced in PEP 318.
Rationale
=
When function decorators were originally debated for inclusion in
Python 2.4, c
On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It's been settled by default -- nobody submitted a PEP to kill the GIL
> in time for the April 30 deadline, and I won't accept one now.
oh, i didn't mean to submit a PEP about that -- i don't have the time
or the brainpower to do that. i was
On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> And what do you return when it doesn't support the container protocol?
Assign the iterator object with the remaining items to d.
> Think about the use cases. It seems that *your* use case is some kind
> of (car, cdr) splitting known from Li
On 5/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Can I go ahead and mark PEP 3129 as "accepted"?
Almost. I'm ok with it, but I think that to follow the procedure you
ought to post the full text at least once on python-3000, so you can
add the date to the "Post-History" header. In the mean tim
On 5/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Thanks for checking in xrange! Woot!
> >
> > test_compiler and test_transformer are waiting for someone to clean up
> > the compiler package (I forget what it doesn't support, perhapes only
> > nonlocal needs to be
Committed revision 55172.
For the record, I'm more and more -1 on this (and on its companion to
remove \ line continuation). These seem pretty harmless features that
serve a purpose; those of us who don't like them can avoid them.
--Guido
On 5/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Rewrit
On 5/5/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> i have to admit i've been neglecting the list in the past few months,
> and i don't know whether the issue i want to bring up has been
> settled already.
It's been settled by default -- nobody submitted a PEP to kill the GIL
in time for the Apri
On 5/6/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> i finished reading almost all of the new peps, so to prevent cluttering
> i'll post all my comments in a single message.
Please don't do that -- it leads to multiple discussions going on in
the same email thread, and that's really hard to keep t
On 5/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I just read PEP 3112, and I believe it contains a
> flaw/underspecification.
>
> It says
>
> # Each shortstringchar or longstringchar must be a character between 1
> # and 127 inclusive, regardless of any encoding declaration [2] in the
> #
[+python-3000; replies please remove python-dev]
On 5/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote:
> >
> > On Saturday 05 May 2007, Aahz wrote:
> > > I'm with MAL and Fred on making literals immutable -- that's safe and
> > > lots of newbies
On 5/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> On 5/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > I don't think that returning the type given is a goal
> > that should be attempted, because it can only ever work
> > for a fixed set of known types. Given an arbitrary
> > sequence type, t
On 5/7/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> some time ago i was working on a sketch for a new socket module
> (called sock2) which had a clear distinction between connected sockets,
> listener sockets and datagram sockets. each protocol was implemented
> as a subclass of one of these base
Can I go ahead and mark PEP 3129 as "accepted"?
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Guido van Rossum wrote:
> Thanks for checking in xrange! Woot!
>
> test_compiler and test_transformer are waiting for someone to clean up
> the compiler package (I forget what it doesn't support, perhapes only
> nonlocal needs to be added.)
It's definitely lagging on set comprehensions as wel
FWIW and in light of the thread on removing __del__ from the language, I
just posted Yet Another Recipe for automatic finalization:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519621
It allows writing a finalizer as a single __finalize__ method, at the
cost of explicitly calling an en
Rewritten -- please tell me if there are any concerns I have missed.
And of course, please tell me if you have a suggestion for the open
issue -- how to better support external internationalization tools, or
at least xgettext in particular.
-jJ
---
PEP: 3126
Titl
Thanks for checking in xrange! Woot!
test_compiler and test_transformer are waiting for someone to clean up
the compiler package (I forget what it doesn't support, perhapes only
nonlocal needs to be added.)
Looks like you diagnosed the doctest failure correctly. This is
probably because, when
On 5/7/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> for instance, there's no point in UDP sockets having listen(), or send()
> or getpeername() -- with UDP you only ever use sendto and recvfrom.
> on the other hand,
Actually, you can connect() UDP sockets, and then you can use send(),
recv(), and
[Talin]
> Note that Jython and IronPython don't have the same restrictions in this
> regard as CPython. Both VMs are able to run in multiprocessing
> environments. (I don't know whether or not Jython/IronPython even have a
> GIL or not.)
they don't. they rely on jvm/clr for GC, and probably per-th
my original idea about the new i/o foundation was more elaborate
than the pep, but i have to admit the pep is more feasible and
compact. some comments though:
writeline
-
TextIOBase should grow a writeline() method, to be symmetrical
with readline(). the reason is simpl
There are 3* failing tests:
test_compiler test_doctest test_transformer
* plus a few more when running on a 64-bit platform
These failures occurred before and after xrange checkin.
Do other people see these failures? Any ideas when they started?
The doctest failures are due to no space at t
On 5/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I don't know how the filters for checkin emails are set up, but this
> seems wrong: mail related to the p3yk branch goes to
> python-3000-checkins, but mail related to the py3k-unistr branch goes
> to python-checkins. There are a bunch of bra
32 matches
Mail list logo
