Greg Ewing <[EMAIL PROTECTED]> writes:
> Edward C. Jones wrote:
>
> > Maybe some day a sufficiently portable automatic garbage collector will
> > be available for C. Until then, we'll have to live with reference counts.
>
> Even if it did become available, we might not want to
> use it. In rece
On 4/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> My revision is both pasted below and attached as a text file. I am not
> posting because I prefer you send the original after one more check and
Thanks Terry. I sent it.
Everyone feel free to spread the word.
n
Andy Sy wrote:
> Does this mean that Py3K intends to reuse major portions of
> Python 2.x's implementation?
I expect that almost all of it will be reused.
The difficulty with improving on the current generator
model is that the only way to do any better is to use
full coroutines. That means eith
Thomas Wouters wrote:
> I believe Guido is referring to
> http://www.awl.com/cseng/titles/0-201-43305-2
Are there any published papers about this, or is that book
the only source?
--
Greg
___
Python-3000 mailing list
[email protected]
http://mail
Boris Borcic wrote:
> given- much clearer and slightly more concise; or
> ? - slightly clearer and much more concise ?
That would be replacing something that's familiar to
at least some people (even if they are geeks) with
something that's familiar to nobody.
If you really want to r
Erno Kuusela wrote:
> The refcounting vs generational GC reasoning I've heard argues that
> refcounting is less cache-friendly: The cache line containing the
> refcount field of the pointed-to objects is dirtied (or at least
> loaded) every time something is done with the reference,
Has anyone ac
I'm changing the list and the subject, pulling this quote out of python-dev:
On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I was hoping that for Python 3.0, we could get around to unkludge the
> sys.path/meta_path/path_hooks/path_importer_cache big ball of hacks,
> possibly
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
>
> > I believe Guido is referring to
> > http://www.awl.com/cseng/titles/0-201-43305-2
>
> Are there any published papers about this, or is that book
> the only source?
What can be more published than a book? :-)
I'm sure
On Thu, Apr 20, 2006 at 07:59:43PM +1200, Greg Ewing wrote:
> Andy Sy wrote:
>
> > Does this mean that Py3K intends to reuse major portions of
> > Python 2.x's implementation?
>
> I expect that almost all of it will be reused.
>
Couldn't PyPy be considered an interesting contender ?
> The diff
Renaming lambda is off the table. It would be change for change's sake.
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Boris Borcic wrote:
>
> > given- much clearer and slightly more concise; or
> > ? - slightly clearer and much more concise ?
>
> That would be replacing somethin
On 20 Apr 2006 10:15:08 +0300, Erno Kuusela <[EMAIL PROTECTED]> wrote:
> The refcounting vs generational GC reasoning I've heard argues that
> refcounting is less cache-friendly: The cache line containing the
> refcount field of the pointed-to objects is dirtied (or at least
> loaded) every time so
Some wilder ideas for keyword-only arguments:
def spam(a, b, c, {d, e, f=x}):
# d, e are mandatory keyword-only
# f is optional keyword-only
Writing them inside {} is meant to make them look
like a set, therefore unordered.
Problem is it looks a little ugly when all you have
is keyw
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> The difficulty with improving on the current generator
> model is that the only way to do any better is to use
> full coroutines. That means either using threads (which
> you can do now if you want), or turning the whole
> implementation inside-ou
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Some wilder ideas for keyword-only arguments:
>
>def spam(a, b, c, {d, e, f=x}):
> # d, e are mandatory keyword-only
> # f is optional keyword-only
IMO anything using any kind of nested brackets inside the argument
list is doomed. S
Barry Warsaw wrote:
> On Wed, 2006-04-19 at 20:17 +1000, Nick Coghlan wrote:
>
>> Unfortunately, the thread fizzled without generating any additional
>> interest.
>> I don't recall the topic really coming up since then.
>
> Maybe because the proposal got too complex while trying to be so
> gene
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Also,
> the argument about dirtying cache lines seem to be relevant to SMP
> architectures and probably doesn't apply much to Python as long as we
> have the GIL (which is not going away).
I guess the primary cost would probably be incurring the ca
[Erno Kuusela]
>> The refcounting vs generational GC reasoning I've heard argues that
>> refcounting is less cache-friendly: The cache line containing the
>> refcount field of the pointed-to objects is dirtied (or at least
>> loaded) every time something is done with the reference,
[Greg Ewing]
>
Jim Jewett wrote:
> On 4/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>> Then you'd have:
>>
>>def f(a, *(b, c=1, *args), **(d, e=2, **kwds)):
>># Silly function
>>
>> 'a' would be a normal positional-or-keyword argument
>> 'b' would be a required positional-only argument
>
> Am I
Tim Peters wrote:
> Yes, but I don't think anyone's offering to build a P3K chip for us ;-)
Since you mention it, one of the things that's been
occupying my mind in idle moments recently is trying to
imagine what a Python chip *would* be like, and maybe
even designing it and prototyping it with a
Guido van Rossum wrote:
> On 4/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> I'd like to be able to simply import a file if I have the filename. And
>> I'd like to be able to load sourcecode from an Oracle database and have
>> useful "filename" and line number information if I get a tracebac
On 4/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Thomas Wouters wrote:
> >
> > > I believe Guido is referring to
> > > http://www.awl.com/cseng/titles/0-201-43305-2
> >
> > Are there any published papers about this, or is that book
> >
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I'll also point people to this page, which contains a very accurate
>> description of the issues with super:
>> http://fuhm.net/super-harmful/
>
> Hmm, the reference to Dylan's next method (along with a few other
> comments in this thread) makes me believ
Sorry, there's so much here that seems poorly thought out that I don't
know where to start.
Getting rid of the existing import syntax in favor of the incredibly
verbose and ugly
foo = import("foo")
just isn't acceptable.
Importing from remote URLs is a non-starter from a security POV; and
usi
On 4/20/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 4/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > Thomas Wouters wrote:
> > >
> > > > I believe Guido is referring to
> > > > http://www.awl.com/cseng/titles/0-201-43305-2
> > >
> >
Guido van Rossum wrote:
> Sorry, there's so much here that seems poorly thought out that I don't
> know where to start.
Consider it a collection of wild ideas.
> Getting rid of the existing import syntax in favor of the incredibly
> verbose and ugly
>
> foo = import("foo")
>
> just isn't acc
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Some wilder ideas for keyword-only arguments:
>def spam(a, b, c, {d, e, f=x}):
> # d, e are mandatory keyword-only
> # f is optional keyword-only
I see several sources of complexity.
Long sequences where order matters are bad, but
On 4/20/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Right. Part of the problems would be solved if we forced
> keyword arguments only in super calls (as everything else
> is really a latent bug),
As mentioned elsewhere, for a well-known API like __getattr__, it
really isn't a bug to use positi
Guido van Rossum wrote:
> On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > I was hoping that for Python 3.0, we could get around to unkludge the
> > sys.path/meta_path/path_hooks/path_importer_cache big ball of hacks,
> > possibly by replacing sys.path with something a bit m
I'm pretty sure reddit.com had the Py3K project in mind when it brought
this to the top of my "recommended" list.
http://www.theonion.com/content/node/47469
must-hurry-ly yrs /F
___
Python-3000 mailing list
[email protected]
http://mail.pyth
On 20/04/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> So maybe you should be able to write that as
>
>def spam{d, e, f=x}:
> ...
>
> Then if you have some positional args as well,
>
>def spam(a, b, c){d, e, f=x}:
> ...
>
> And incorporating all the possible features,
>
>def spa
On 4/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Sorry, there's so much here that seems poorly thought out that I don't
> > know where to start.
>
> Consider it a collection of wild ideas.
>
> > Getting rid of the existing import syntax in favor of the incredibl
On 4/20/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > > I was hoping that for Python 3.0, we could get around to unkludge the
> > > sys.path/meta_path/path_hooks/path_importer_cache big ball of ha
On 4/20/06, Sam Pointon <[EMAIL PROTECTED]> wrote:
> Following on from this, how about using [] for positional-only
> arguments as well?
Forget it. Too different with not enough benefits.
Remember, we don't want to emulate Perl 6!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Greg Ewing wrote:
> Tim Peters wrote:
>
>> Yes, but I don't think anyone's offering to build a P3K chip for us ;-)
>
> Since you mention it, one of the things that's been
> occupying my mind in idle moments recently is trying to
> imagine what a Python chip *would* be like, and maybe
> even desig
Andy Sy <[EMAIL PROTECTED]> wrote:
> Err... thank you once again for being redundant, reiterating what is
> already pretty much dead clear to everyone and saying nothing new
> in general.
And yet, here I notice that you've still not described a syntax or its
execution semantics. Instead you've c
Op do, 20-04-2006 te 16:27 +0100, schreef Guido van Rossum:
> On 4/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > Importing from remote URLs is a non-starter from a security POV; and
> > > using HTTPS would be too slow. For code that's known to reside
> > > remot
Guido van Rossum wrote:
> I'm changing the list and the subject, pulling this quote out of python-dev:
>
> On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>>I was hoping that for Python 3.0, we could get around to unkludge the
>>sys.path/meta_path/path_hooks/path_importer_ca
It must not be my day. I don't understand anything you're saying.
On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Cleaning up import stuff would be excellent. Time spent debugging
> imports is time wasted, but it happens all too often.
>
> I would argue against any list of loaders, or list o
> It would be interesting to bring ILU up-to-date. Get the ILU C
> library compiling nicely on POSIX (should be trivial), then bring the
> Python bindings up-to-date. That would, once again, give us ONC RPC
> and CORBA compatibility, both IPC and RPC.
Actually, I tried this last night on a Fedor
Guido van Rossum wrote:
> It must not be my day. I don't understand anything you're saying.
Hmm... well, trying again...
> On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>Cleaning up import stuff would be excellent. Time spent debugging
>>imports is time wasted, but it happens all too of
Guido van Rossum wrote:
> On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>>Some wilder ideas for keyword-only arguments:
>>
>> def spam(a, b, c, {d, e, f=x}):
>> # d, e are mandatory keyword-only
>> # f is optional keyword-only
>
>
> IMO anything using any kind of nested brackets
Guido van Rossum wrote:
>> * Circular imports should fail more nicely. Everyone suffers this at
>> some time; maybe it can't be fixed, but at least it should be clear
>> what's happening.
>
> It probably can't be fixed (or do you see a fix?). Do you mean it
> should be easier to debug, or do you
Let me just add that Andy is wasting his time. Python 3000 won't have
continuations.
On 4/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Andy Sy <[EMAIL PROTECTED]> wrote:
> > Err... thank you once again for being redundant, reiterating what is
> > already pretty much dead clear to everyone
On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> With the ambiguity of sys.path, it's hard to statically determine if you
> have all the requirements.
[And, as you said elsewhere, whether it is the version you expected,
and whether it will actually load or get skipped because of an earlier
im
Jim Jewett wrote:
> On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>
>>With the ambiguity of sys.path, it's hard to statically determine if you
>>have all the requirements.
>
>
> [And, as you said elsewhere, whether it is the version you expected,
> and whether it will actually load or ge
Guido van Rossum wrote:
> Let me just add that Andy is wasting his time. Python 3000 won't have
> continuations.
Huh? Futures are very different from continuations. I still have a
hard time understanding continuations (and am no fan of them), but
futures seem to be a rather simple abstraction t
At 04:33 PM 4/20/2006 +0100, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>On 4/20/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> >
> > > On 4/20/06, in python-dev, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > > > I was hoping that for Python 3.0, we could get around to
Andy Sy writes:
> Does this mean that Py3K intends to reuse major portions of
> Python 2.x's implementation?
Aahz already answered this, but I'd like to restate more forcefully:
It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing
CPython codebase, with a few changes and some cru
On 4/20/06, Andy Sy <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Let me just add that Andy is wasting his time. Python 3000 won't have
> > continuations.
>
> Huh? Futures are very different from continuations. I still have a
> hard time understanding continuations (and am no fan of
[Guido, to Andy Sy]
> ...
> If you want to contribute a pure Python module that implements some
> useful form of futures, you don't have to wait for Python 3.0. But
> before you contribute this to Python 2.6 (it's too late for 2.5), you
> should probably have released it successfully as a separate
On 4/20/06, Jan Claeys <[EMAIL PROTECTED]> wrote:
> A man-in-the-middle-attack and other ways to "inject" a different module
> than intended by the author are also possible with the current default
> filesystem based imports, so I don't think that's a good argument
> against http-imports (or other
Guido writes
> Let me just add that Andy is wasting his time. Python 3000 won't have
> continuations.
Andy writes:
> Huh? Futures are very different from continuations. I still have a
> hard time understanding continuations (and am no fan of them), but
> futures seem to be a rather simple abstra
There are still a bunch of tests failing in the py3k (sic) branch:
test_class fails because hash() of a new-style class that defines
__eq__ or __cmp__ doesn't raise an exception. There's a design issue
here: should the default hash be changed to raise an exception in this
case (perhaps triggering
(Sorry, Guido, meant to reply to list, not to you privately.)On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
test_exception fails with a SystemError for popping a non-exceptionoff the stack
I already fixed that one (it's not just a test fix, it's an actual bug,
so per your request I didn't
On 4/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> There are still a bunch of tests failing in the py3k (sic) branch:
>
> test_class fails because hash() of a new-style class that defines
> __eq__ or __cmp__ doesn't raise an exception. There's a design issue
> here: should the default hash b
Walter Dörwald wrote:
> import foo from url("file:~guido/python-packages/foo")
Hard-wiring pathnames, URLs etc. into one's code on a
regular basis would be an extremely BAD idea. The way
to do that is via configuration mechanisms external
to the program.
It might be useful to have the ability fo
Jim Jewett wrote:
> I also see the value of keyword-only arguments without unlimited
> positional arguments. Whether it deserves syntax and what that syntax
> should be (such as * or *None) may need a pronouncement eventually,
> but it doesn't have to be complex.
My previous post was just wild
Erno Kuusela <[EMAIL PROTECTED]> wrote:
> The refcounting vs generational GC reasoning I've heard argues that
> refcounting is less cache-friendly
I believe that's correct. A state of the art generational GC would
outperform reference counting, even given Python's enormous
allocation rate. Howev
Greg Ewing wrote:
> Jim Jewett wrote:
>
>> I also see the value of keyword-only arguments without unlimited
>> positional arguments. Whether it deserves syntax and what that syntax
>> should be (such as * or *None) may need a pronouncement eventually,
>> but it doesn't have to be complex.
>
> M
Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Erno Kuusela <[EMAIL PROTECTED]> wrote:
> > The refcounting vs generational GC reasoning I've heard argues that
> > refcounting is less cache-friendly
>
> I believe that's correct. A state of the art generational GC would
> outperform reference count
On 4/20/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > a bunch of tests for XML modules all fail (perhaps some of these are
> > related): minidom, sax, xdrlib, xml_etree
>
> I'm not sure if they're related, but I do believe they're all ca
61 matches
Mail list logo
