Talin wrote:
> No responses? I'm surprised...
>
> (I assume the PEP editor is on vacation, since I haven't gotten a response
> from that channel either.)
A couple of days isn't really that long for Py3k stuff, and py-dev has been
pretty busy for the last few days :)
[...]
> Or if you just want m
Guido van Rossum wrote:
> > I'm afraid I disagree. PEP 302 actually has some tremendous advantages
> > over a pure objects-on-sys.path approach:
> >
> > * Strings can be put in any configuration file, and used in .pth files
> >
> > * Strings can be put in environment variables (like PYTHONPATH).
It's an interesting idea; it's been brought up before but nobody AFAIK
has ever implemented it. I like the scoping requirement. I suggest you
try to implement it and see how well it works. You probably also want
to be able to hook list, tuple and dict displays (perhaps by supplying
an alternative f
Thanks for the discussions on the hows-and-whys of futures and
asynchronous approaches in Python... they have been enlightening.
[OT stuff below]
Michael Chermside wrote:
> It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing
> CPython codebase, with a few changes and some cruf
Greg Ewing wrote:
> BTW, if you *really* want to understand continuations, you
> need to carry out the following exercise: Write a Scheme
> interpreter in Scheme, doing it in a continuation-passing
> style. [1]
>
> You'll find that it's possible to do this using a subset
> of Scheme that doesn't
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote:
> Greg Ewing canterbury.ac.nz> writes:
>
> > Giovanni Bajo wrote:
> >
> > > Another (similar) way would be to let the user pay for the high
> > > typechecking
> > > price in normal cases *but* provide a list[int] class, which is a list
> > > decorated
Ian Bicking wrote:
> Maybe you wouldn't have to mix it all together... if sys.path,
> sys.meta_path, and sys.modules (and maybe some other stuff I don't know
> of) were really instance variables of some ModuleEnvironment object, and
> you could instantiate a new ModuleEnvironment that was specif
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Removing string %-formatting would be a backwards compatibility nightmare.
> I doubt there's a Python program on the planet that would continue working if
> it was removed (I know most of mine would break in verbose mode). Even those
> which
Andy Sy wrote:
> > It is a FUNDAMENTAL PRECONDITION of Py3K that it will BE the existing
> > CPython codebase, with a few changes and some cruft removed. We are
> > NOT going to re-write from the ground up. If you don't know why, go
> > read "http://www.joelonsoftware.com/articles/fog69.ht
> I already have a rough draft PEP and implementation for a
> __signature__ object from a couple of months ago (sparked my thinking
> on __introspects__). I will go ahead and start another email thread
> with the PEP so that details can get hashed out on that separately.
I was wondering if maybe
> Guido van Rossum wrote:
> If I have some utterly dynamic
> code that comes up with a list of a million ints, and then I pass
> that
> as an argument to a function that requests the argument type is
> list[int],
>
> you wrap it in something that checks elements for intness
> as you access
On Sat, 22 Apr 2006 03:12 am, Jim Jewett wrote:
> On 4/20/06, Birch, Bill <[EMAIL PROTECTED]> wrote:
> > Type comparison operators would only need a deep
> > inspection of the types when the godel strings don't match.
> > If most comparisons will be an exact match (not a subtype)
> > the lookup sho
On Sat, 22 Apr 2006 06:39 pm, Guido van Rossum wrote:
>
> No. This is the kind of thing that would very quickly turn "optional"
> typing into *mandatory* typing. One library package adds type
> declarations. Now all packages that use it are required to either add
> type declarations or explicit con
On Sat, 22 Apr 2006 06:39 pm, Guido van Rossum wrote:
...
>
> No. This is the kind of thing that would very quickly turn "optional"
> typing into *mandatory* typing. One library package adds type
> declarations. Now all packages that use it are required to either add
> type declarations or explicit
On 22/04/06, Paul Svensson <[EMAIL PROTECTED]> wrote:
> At the risk of hypergeneralization... If *arg means "put the rest of the
> positional arguments in arg", then if we simply allow arg to be a tuple...
>
> def foo(*(a, b)): ... # disallow keyword args.
> def foo(a, b, *(), x, y): ...
Guido van Rossum wrote:
> On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>Removing string %-formatting would be a backwards compatibility nightmare.
>> I doubt there's a Python program on the planet that would continue working if
>> it was removed (I know most of mine would break in verbo
Ian Bicking wrote:
> Guido van Rossum wrote:
>> This has been brought up many times before. The value of bin() is
>> really rather minimal except when you're just learning about binary
>> numbers; and then writing it yourself is a useful exercise.
>>
>> I'm not saying that bin() is useless -- but I
Michael Urman wrote:
> There's a lot of holes to this story, including at least how these
> functions are registered, and which additional arguments (if any) are
> necessary. Shall we try to fill these holes in?
Answering without checking the source (which is undoubtedly a bad idea), but
this sou
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> That (adding .format() in 2.6) occurred to me, but I dismissed it for some
> reason. It can't have been a very good reason though, since I sure can't
> remember what it was.
>
> In which case, Talin's PEP should probably suggest this as the impl
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Michael Urman wrote:
> > There's a lot of holes to this story, including at least how these
> > functions are registered, and which additional arguments (if any) are
> > necessary. Shall we try to fill these holes in?
>
> Answering without check
That makes more sense than a builtin. Note that oct() and hex() return
something that's a valid Python literal. There are no binary literals
(nor should there be IMO).
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Ian Bicking wrote:
> > Guido van Rossum wrote:
> >> This has been brought up
Guido van Rossum wrote:
> On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Michael Urman wrote:
>>> There's a lot of holes to this story, including at least how these
>>> functions are registered, and which additional arguments (if any) are
>>> necessary. Shall we try to fill these holes in?
On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> No matter what, permitting these kinds of hooks is going to require
> alterations to the process of compiling the AST to the bytecode - and
> subclassing is an excellent way of allowing some aspects of an implementation
> to be overridden while
Guido van Rossum wrote:
> It's an interesting idea; it's been brought up before but nobody AFAIK
> has ever implemented it. I like the scoping requirement.
can we add support for XML literals while we're at it?
http://effbot.org/zone/idea-xml-literal.htm
> can we add support for XML literals while we're at it?
>
> http://effbot.org/zone/idea-xml-literal.htm
The reason the literals aren't returned as ElementTree Elements is
because ElementTree didn't exist back then, right?
Because that particular integration would make a lot of sense.
Rega
On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > It's an interesting idea; it's been brought up before but nobody AFAIK
> > has ever implemented it. I like the scoping requirement.
>
> can we add support for XML literals while we're at it?
>
> http://effbot.o
On 4/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It's an interesting idea; it's been brought up before but nobody AFAIK
> has ever implemented it. I like the scoping requirement. I suggest you
> try to implement it and see how well it works.
I'll look into that now that I know it's not a
Le samedi 22 avril 2006 à 16:17 +0100, Guido van Rossum a écrit :
> Groovy has a different approach that doesn't blend the two syntaxes,
> but rather gives you more native syntax for constructing DOM trees (or
> event streams; it wasn't clear from the description I saw today). That
> makes perhaps
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> >
> > > It's an interesting idea; it's been brought up before but nobody AFAIK
> > > has ever implemented it. I like the scoping requirement.
> >
> > can we add sup
On 4/22/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Nevow.stan has a very similar method for generating *ML with
> (attribute='value')[content], but I've personally found that using only
> function-call semantics to create children and attributes for *ML in
> Python is much more convenient; all
Here's a condensed list of the open issues that have been raised by people
so far:
(Well, edited somewhat - I'm including 'major' issues, not minor nits -- we
can discuss those once the major issues are settled.)
1) Whether to drop the optional parts of the proposal:
-- support for field expre
Guido van Rossum wrote:
> Unfortunately, all of these schemes break down if you have
> non-identifier characters in attribute or element names, or if you
> want to use namespaces, or if you want to insert entity references,
> XML comments, or other funky stuff like DTDs or processing elements.
a
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote:
> 1) Whether to drop the optional parts of the proposal:
>-- support for field expressions (was: locals() support)
>-- support for direct access to current scope (was: locals() support)
I'd skip this. KISS etc.
> 2) Should this PEP be targeted
I realized that the "Keyword-Only Arguments" and the "Function Signature"
proposals could be written as two separate PEPs, since there is only minimal
interaction between the two.
However, I started writing some use case examples for the Function Signature
PEP, and ran into a slight snag. My use c
On 4/22/06, Talin <[EMAIL PROTECTED]> wrote:
> Well the problem is that decorator functions don't have access to the
> machinery
> that binds input arguments for formal parameters. So the wrapper function has
> a
> hard time knowing which input arguments will be bound to which formal params,
> wi
On 4/22/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 4/22/06, Talin <[EMAIL PROTECTED]> wrote:
> > Well the problem is that decorator functions don't have access to the
> > machinery
> > that binds input arguments for formal parameters. So the wrapper function
> > has a
> > hard time knowing wh
Talin wrote:
>> Thus you can't nest formatters, e.g., {0:pad(23):xmlquote}, unless the
>> underlying object understands that. Which is probably unlikely.
>
> At this point, I'm thinking not, although I could be convinced otherwise.
> Remember, that you can accomplish all of the same things by pr
On 4/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > > I'm afraid I disagree. PEP 302 actually has some tremendous advantages
> > > over a pure objects-on-sys.path approach:
> > >
> > > * Strings can be put in any configuration file, and used in .pth files
> > >
> >
[I am posting to python-3000 since this is where the parameter list
ideas are being discussed, but this is probably generic enough to
eventually make it into the 2.x line]
Here is a rough draft of a PEP I wrote last summer after I had Guido
come for lunch at Google when I was interning there (i.e.
A long-standing part of Py3K is removing 'old style slices' (meaning the __get/set/delslice__ methods and the sq_slice/sq_ass_slice sequence-struct functions, but not slice objects.) I started removing them, only to find out that it's damned inconvenient to make all slicing go through tp_as_mapping
Michael Urman wrote:
> For in-module effect, maybe some special import could pull in a
> compiler class instance used only for the current module, allowing its
> build_xyz methods be replaced.
>
> from __ast__ import compiler
> compiler.build_float = Decimal# on an instance, so no 'sel
Guido van Rossum wrote:
> On 4/22/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> No matter what, permitting these kinds of hooks is going to require
>> alterations to the process of compiling the AST to the bytecode - and
>> subclassing is an excellent way of allowing some aspects of an implementat
Thomas Wouters wrote:
>
> A long-standing part of Py3K is removing 'old style slices' (meaning the
> __get/set/delslice__ methods and the sq_slice/sq_ass_slice sequence-struct
> functions, but not slice objects.) I started removing them, only to find
> out that it's damned inconvenient to make al
Brett Cannon python.org> writes:
> [I am posting to python-3000 since this is where the parameter list
> ideas are being discussed, but this is probably generic enough to
> eventually make it into the 2.x line]
>
> Here is a rough draft of a PEP I wrote last summer after I had Guido
> come for l
44 matches
Mail list logo
