Re: [Python-3000] Pronouncement on parameter lists

"Brett Cannon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> Oh, other standard function attributes probably all ought to be >> renamed from func_whatever to __whatever__. That applies to >> 'func_closure', 'func_code', 'f

Re: [Python-3000] New built-in function: bin()

Or a new string formatting character bin() == "%b" % (i), but perhaps not, here is no precedent for this not even in C. Like you say a new method in a lib somewhere is more reasonable. Mike Talin wrote: Mike Traynar credence.com> writes: I've always wondered why there isn't a

Re: [Python-3000] PEP - string.format

Ian Bicking colorstudy.com> writes: > ...A lot of good ideas, and I haven't had a chance to consider them all. Let me respond to what I can. > Brace characters ('curly braces') are used to indicate a > replacement field within the string: > > "My name is {0}".format( 'Fred'

Re: [Python-3000] p3yk branch and merging (wasRe:[Python-3000-checkins] r45619-python/branches/p3yk/Modules/cjkcodecs/multibytecodec.c)

Thomas Wouters <[EMAIL PROTECTED]> wrote: >> Ah. Does it require a particular version of the server or client? I >> can't seem to find that information anywhere. No, it doesn't. I have been using it with SVN 1.1, for instance. Though you'll get speedups using newer clients as they implement more

Re: [Python-3000] Type Comparisons with Godel Numbers

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 with typechecks on modification operations. We could have > > li

Re: [Python-3000] Futures in Python 3000

Jim Jewett wrote: > There, a Future is a proxy object, whose actual characteristics will > (or may) be filled in later. If you need it, you wait for it, but if > you don't need it yet, it can be created in the background. > > How to make this cleaner than the existing concrete implementations > (

Re: [Python-3000] Type Comparisons with Godel Numbers

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 with typechecks on modification operations. We could have > list[int|float]() to construct a list which can hold

Re: [Python-3000] Signature API

Jim Jewett wrote: > On the other hand, it would be pretty easy to miss that x needed a > value, particularly if x were the third or fourth of a dozen keywords. That could be addressed by requiring that all mandatory keyword-only args are listed before the optional ones in the def. Of course, you

Re: [Python-3000] Type Comparisons with Godel Numbers

Giovanni> One way would be to keep boolean flags like "is this a list of Giovanni> integers". It could be updated after each list modification, Giovanni> so that typechecks come for (almost) free. Where would that be done? If it's in the untyped function in Guido's example, how does

Re: [Python-3000] Pronouncement on parameter lists

Talin wrote: > Jim Jewett gmail.com> writes: > >> It has not yet been specified what would happen to additional >> positional arguments that get passed in anyway. (Swallow or raise an >> Exception?) > > Additional positional arguments would be treated exactly as if you attempted > to pass too

[Python-3000] Brainstorming: literal construction hooks

This idea isn't fully fleshed out, but I wanted to air it to see if it took wind or fell flat. Please forgive inaccuracies between lexing and parsing. It's about being able to override what a given literal is turned into. It would only take effect in a limited scope, either per module, per compile

Re: [Python-3000] Type Expressions

On 4/21/06, Talin <[EMAIL PROTECTED]> wrote: > Guido van Rossum python.org> writes: > >> To prevent more abominations like this, let me pronounce that I now >> like the single-star syntax: >> >> def foo(a, b, *, x=1, y=2): ... > > Thank you :) It was getting pretty strange there. > > The variati

Re: [Python-3000] parameter lists [was: Type Expressions]

Guido van Rossum wrote: > (since that can easily be seen as "*args without the > args"). Waitress: Args, star, star, args, star and args without the args? Eeeuuuggh! -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.pyth

Re: [Python-3000] Pronouncement on parameter lists

Guido van Rossum python.org> writes: > FWIW Talin, if you're writing up a PEP for this, could I ask you to > also specify a new introspection API? A function foo should have a > magic attribute foo.__signature__ which provides access to the > argument names and defaults (and types if in the futur

Re: [Python-3000] Pronouncement on parameter lists

Jim Jewett wrote: > It has not yet been specified what would happen to additional > positional arguments that get passed in anyway. (Swallow or raise an > Exception?) I've always intended that there would be an exception. -- Greg ___ Python-3000 maili

Re: [Python-3000] Type Expressions

Alex Martelli wrote: >> def foo(a, b, *, x=1, y=2): ... > > So, what will this syntax signify? This particular example means "a and b are required positional arguments, no other positional arguments are allowed, and x and y are optional keyword-only arguments". > If the single-star stands for

Re: [Python-3000] Changing the import machinery

Phillip J. Eby wrote: > So, what I'd suggest is that the expanded import mechanism would provide a > registry of extensions and handlers, Urg, global registries again. I'd like this better if the scope of a particular extension and its handler could be restricted to some chosen part of the pack

Re: [Python-3000] Changing the import machinery

Ian Bicking wrote: > No, I haven't; I assume you mean: > > from string import Template or from mypackage.backports.string24 > import Template No, I mean from string or mypackage.backports.string24 import Template which seems to be about the least ugly it can get given that you need to ex

Re: [Python-3000] Signature API

Jim, Can you try to produce strawman answers for all those questions? It may be a while before I'll get to answering them... --Guido On 4/21/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wr

Re: [Python-3000] Type Comparisons with Godel Numbers

Guido van Rossum <[EMAIL PROTECTED]> wrote: > But let me point out that the key concern I have about the expense of > type checking is what would be done when unchecked code calls a > function with type-checked arguments. If I have some utterly dynamic > code that comes up with a list of a million

Re: [Python-3000] PEP - string.format

On Fri, 2006-04-21 at 14:39 -0700, Raymond Hettinger wrote: > >- I like having an operator for string formatting. I'm -0 on dropping it for > >a .format() method. > IMO, a named method solves all of these > issues. +1 for a method to replace the operator. -Barry signature.asc Description: Th

Re: [Python-3000] PEP - string.format

>- I like having an operator for string formatting. I'm -0 on dropping it for >a .format() method. > > I'm +1 on some sort of change from the current %-operator which has issues distinguishing between scalar and collection arguments. Also, there are precedence issues (the current precedence

Re: [Python-3000] Pronouncement on parameter lists

On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/21/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > On 4/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > > > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > > > To prevent more abominations like this, let me pronounce tha

Re: [Python-3000] p3yk branch and merging (was Re:[Python-3000-checkins] r45619 -python/branches/p3yk/Modules/cjkcodecs/multibytecodec.c)

On 4/21/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: Thomas Wouters wrote:>> And just so everyone knows: done right, merging isn't hard. It's not>> as easy as it could be, but 'svn merge' makes it a lot easier than>> it used to be in CVS. Here's how you do it: >> [...]It can be much much easier tha

[Python-3000] Signature API

On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >... pronounce that I now like the single-star syntax: > def foo(a, b, *, x=1, y=2): ... [Alex asked for clarification] I wrote: > It has not yet been specified whether the keywor

Re: [Python-3000] PEP - string.format

Giovanni Bajo develer.com> writes: > Talin wrote: > > > http://viridia.org/python/doc/PEP_AdvancedStringFormatting.txt > > Some comments: Excellent feedback. I won't address everything at once - instead I'd like to collect feedback from various people and address the issues all at once. Howe

Re: [Python-3000] Type Expressions

Guido> def foo(a, b, *, x=1, y=2): ... skip> Sorry, I haven't been following this thread. What exactly does skip> the naked star mean? Sorry, should have finished reading my mail first. S ___ Python-3000 mailing list Python-3000@python.or

Re: [Python-3000] Type Expressions

Guido> To prevent more abominations like this, let me pronounce that I Guido> now like the single-star syntax: Guido> def foo(a, b, *, x=1, y=2): ... Sorry, I haven't been following this thread. What exactly does the naked star mean? Skip _

Re: [Python-3000] PEP - string.format

On Fri, 2006-04-21 at 13:25 -0500, Ian Bicking wrote: > While I've argued in an earlier thread that $var is more conventional, > honestly I don't care (except that %(var)s is not very nice). A couple > other people also preferred $var, but I don't know if they have > particularly strong opinio

Re: [Python-3000] parameter lists [was: Type Expressions]

[Ron Adam] > def f(a, b, c=?, d=x): Another problem with this is that it uses punctuation in a manner that's neither similar to how it is used in written English (or Dutch, or any other Latin language) nor resembling of other areas in Python. I know this is a very strict constraint, and someti

Re: [Python-3000] Type Expressions

On 4/21/06, Paul Moore <[EMAIL PROTECTED]> wrote: > I'm not sure I follow the priority argument (except in a purely > parser-technical sense, I guess). I meant that everywhere else in Python, ';' inside parentheses is illegal; ';' terminates a statement (and an error-correcting parser could use a

Re: [Python-3000] parameter lists [was: Type Expressions]

Greg Ewing wrote: > Ron Adam wrote: > >> Or just ... >> >> def f(a, b, c=?, d=x): > > But there's nothing about this that particularly > suggests that c *must* be specified with a keyword. > It looks like just another positional arg with a > rather strange-looking default. The strange defaul

Re: [Python-3000] Pronouncement on parameter lists

Jim Jewett gmail.com> writes: > It has not yet been specified what would happen to additional > positional arguments that get passed in anyway. (Swallow or raise an > Exception?) Additional positional arguments would be treated exactly as if you attempted to pass too many positional arguments

Re: [Python-3000] PEP - string.format

Talin wrote: > Talin acm.org> writes: > > >>I decided to take some of the ideas discussed in the string formatting >>thread, add a few touches of my own, and write up a PEP. >> >>http://viridia.org/python/doc/PEP_AdvancedStringFormatting.txt >> >>(I've also submitted the PEP via the normal chann

Re: [Python-3000] Type Expressions

On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/21/06, Talin <[EMAIL PROTECTED]> wrote: > > The variation that I was thinking of was a little shorter, but not > > necessarily better: > > > >def foo( a, b; x=1, y=2 ): ... > > That cropped up in my head too long ago. I think I've s

Re: [Python-3000] Pronouncement on parameter lists

On 4/21/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > To prevent more abominations like this, let me pronounce that I now > > > like the single-star syntax: > > > > def foo(a, b,

[Python-3000] Pronouncement on parameter lists

On 4/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > To prevent more abominations like this, let me pronounce that I now > > like the single-star syntax: > > def foo(a, b, *, x=1, y=2): ... > So, what will this syntax signify? If t

Re: [Python-3000] Type Expressions

On 4/21/06, Talin <[EMAIL PROTECTED]> wrote: > Guido van Rossum python.org> writes: > > > To prevent more abominations like this, let me pronounce that I now > > like the single-star syntax: > > > > def foo(a, b, *, x=1, y=2): ... > > Thank you :) It was getting pretty strange there. > > The var

Re: [Python-3000] parameter lists [was: Type Expressions]

Guido van Rossum wrote: > On 4/21/06, Ron Adam <[EMAIL PROTECTED]> wrote: >> Recently I found a case where I wanted to return something that was more >> literally *nothing* than a None is. So maybe a null symbol of some sort >> might be useful in other cases as well? > > You're not gonna get some

Re: [Python-3000] PEP - string.format

Talin wrote: > http://viridia.org/python/doc/PEP_AdvancedStringFormatting.txt Some comments: - Could this be implemented as a "preview" in Python 2.x? Do we want to? - I like having an operator for string formatting. I'm -0 on dropping it for a .format() method. - string.Template becomes obsolet

Re: [Python-3000] Type Expressions

On Fri, Apr 21, 2006, Guido van Rossum wrote: > On 4/21/06, Mark Russell <[EMAIL PROTECTED]> wrote: >> >> Another wild thought: >> >> def foo(a, b, @keyword_only c, d): >>pass >> >> Actually that one could go in 2.X - it's currently a syntax error. > > To prevent more abomination

Re: [Python-3000] parameter lists [was: Type Expressions]

Giovanni Bajo wrote: > Ron Adam <[EMAIL PROTECTED]> wrote: > >> This *may* relate to None being an object which isn't the same as >> "not a value". There currently isn't a way (that I know of) to >> specify a generally null object outside of sequences. >> >> def f(a, b, c=Null, d=x): # Us

Re: [Python-3000] Type Comparisons with Godel Numbers

Guido van Rossum wrote: > This seems a good idea to remember when we get to that point. > > But let me point out that the key concern I have about the expense of > type checking is what would be done when unchecked code calls a > function with type-checked arguments. If I have some utterly dynamic

Re: [Python-3000] p3yk branch and merging (was Re:[Python-3000-checkins] r45619 -python/branches/p3yk/Modules/cjkcodecs/multibytecodec.c)

Thomas Wouters wrote: >> And just so everyone knows: done right, merging isn't hard. It's not >> as easy as it could be, but 'svn merge' makes it a lot easier than >> it used to be in CVS. Here's how you do it: >> [...] It can be much much easier than this: SVN 1.3 ships with a client-side tool c

Re: [Python-3000] Changing the import machinery

Hi, I've another subject related to import machinery to add in this thread. We've discussed about this at py-dev when I found an inconsistent import/zipimport behavior with .pyc/.pyo compiled modules: http://mail.python.org/pipermail/python-dev/2005-November/057959.html http://mail.python.org/pip

Re: [Python-3000] Type Expressions

Talin wrote: > I know you want implementations rather than PEPs at this point, > but if there is a consensus on both the "keywords after *args" and > "keyword only" arguments, I can write up a PEP for that, if that > would be useful. Would a doctest be a good middle ground? Helps you write the i

Re: [Python-3000] PEP - string.format

Talin acm.org> writes: > I decided to take some of the ideas discussed in the string formatting > thread, add a few touches of my own, and write up a PEP. > > http://viridia.org/python/doc/PEP_AdvancedStringFormatting.txt > > (I've also submitted the PEP via the normal channels.) No responses?

Re: [Python-3000] Type Expressions

On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: ... > To prevent more abominations like this, let me pronounce that I now > like the single-star syntax: > > def foo(a, b, *, x=1, y=2): ... So, what will this syntax signify? If the single-star stands for "arbitrary positional argument

Re: [Python-3000] Type Expressions

Guido van Rossum python.org> writes: > To prevent more abominations like this, let me pronounce that I now > like the single-star syntax: > > def foo(a, b, *, x=1, y=2): ... Thank you :) It was getting pretty strange there. The variation that I was thinking of was a little shorter, but not n

Re: [Python-3000] Type Comparisons with Godel Numbers

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 should be faster. If you're assuming that, then just checki

Re: [Python-3000] Changing the import machinery

At 11:37 AM 4/21/2006 -0500, Ian Bicking wrote: >Phillip J. Eby wrote: >>The second is that PEP 302 only covers "location" importers, not "format" >>importers. That is, if you want to do something like make Kid or Cheetah >>templates importable, you have to replace things with new >>machinery.

Re: [Python-3000] New built-in function: bin()

Mike Traynar credence.com> writes: > I've always wondered why there isn't a bin() built-in in Python. > Built-in functions already exist for converting ints to hexadecimal and > octal strings and vice versa i.e. Perhaps a "format_base" function in the strings library, that takes an int and a n

[Python-3000] p3yk branch and merging (was Re: [Python-3000-checkins] r45619 - python/branches/p3yk/Modules/cjkcodecs/multibytecodec.c)

On 4/21/06, hyeshik.chang wrote: Author: hyeshik.changDate: Fri Apr 21 18:21:44 2006New Revision: 45619Modified:   python/branches/p3yk/Modules/cjkcodecs/multibytecodec.cLog:Add empty __init__ methods for stateful multibytecodec instances. This resolves a problem f

Re: [Python-3000] Type Comparisons with Godel Numbers

On Apr 21, 2006, at 8:36 AM, Greg Ewing wrote: > 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 th

Re: [Python-3000] New built-in function: bin()

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 IMO its (small) value > do

Re: [Python-3000] Changing the import machinery

Phillip J. Eby wrote: > The second is that PEP 302 only covers "location" importers, not "format" > importers. That is, if you want to do something like make Kid or Cheetah > templates importable, you have to replace things with new machinery. This > is a more important problem to solve, IMO,

Re: [Python-3000] Changing the import machinery

At 10:05 PM 4/21/2006 +1000, Nick Coghlan wrote: >Phillip J. Eby wrote: >>There are only two things wrong with PEP 302 IMO, and neither is its "fault". >>The first is that the "classic" import machinery isn't on sys.meta_path, >>and the 'imp' API isn't defined in terms of PEP 302. Those two thing

Re: [Python-3000] Changing the import machinery

On 4/21/06, Ian Bicking <[EMAIL PROTECTED]> wrote: Greg Ewing wrote:> Have you seen my proposal for "or" in import statements?> Would you consider that elegant enough?No, I haven't; I assume you mean:   from string import Template or from mypackage.backports.string24import Template... that (realis

Re: [Python-3000] Changing the import machinery

At 10:42 AM 4/21/2006 +0100, Guido van Rossum wrote: >I think I like this. I wonder if there's a parallel with my preference >for strings as paths instead of path objects... PEP 302 still has things analagous to path objects, it's just that you're allowed to define the mapping between strings and

Re: [Python-3000] Changing the import machinery

Greg Ewing wrote: > Ian Bicking wrote: >>try: >> from string import Template >>except ImportError: >> from mypackage.backports.string24 import Template >> >>Doing this in a more elegent or formalized fashion might be nice. > > > Have you seen my proposal for "or" in import statements? >

Re: [Python-3000] Type Expressions

On 4/21/06, Mark Russell <[EMAIL PROTECTED]> wrote: > On 20 Apr 2006, at 10:23, Guido van Rossum wrote: > > IMO anything using any kind of nested brackets inside the argument > > list is doomed. > > Another wild thought: > > def foo(a, b, @keyword_only c, d): >pass > > Actually th

Re: [Python-3000] Type Expressions

On 20 Apr 2006, at 10:23, Guido van Rossum wrote: > IMO anything using any kind of nested brackets inside the argument > list is doomed. Another wild thought: def foo(a, b, @keyword_only c, d): pass Actually that one could go in 2.X - it's currently a syntax error. Mark Russell

Re: [Python-3000] Type Comparisons with Godel Numbers

Building from Aahz's example, what you really want is a mechanism for typechecking that any accessed elements are ints when dynamic code generates a list of a million elements and passes it to a function declared to take a parameter of type "list[int]". And then make sure the following two examples

Re: [Python-3000] Futures in Python 3000

On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Andy Sy wrote: > > 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 to comprehend. > Isn't a future jus

Re: [Python-3000] Type Comparisons with Godel Numbers

On Sat, Apr 22, 2006, Greg Ewing wrote: > 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 ele

Re: [Python-3000] Chaning the import machinery; was: Re: [Python-Dev] setuptools in 2.5.

Guido van Rossum wrote: > 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 imp

Re: [Python-3000] Cleaning up argument list parsing

For fancy argument list parsing, perhaps we need a module "argsparse" that is analogous to "optparse". ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/op

Re: [Python-3000] Type Comparisons with Godel Numbers

On 4/21/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > 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 t

Re: [Python-3000] Type Comparisons with Godel Numbers

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 them. It'll still

Re: [Python-3000] parameter lists [was: Type Expressions]

Ron Adam wrote: > Or just ... > > def f(a, b, c=?, d=x): But there's nothing about this that particularly suggests that c *must* be specified with a keyword. It looks like just another positional arg with a rather strange-looking default. Keep in mind that there's really no connection betwe

Re: [Python-3000] Is reference counting still needed?

Neil Schemenauer wrote: > I believe that's correct. A state of the art generational GC would > outperform reference counting, even given Python's enormous > allocation rate. Another thing to consider is that Python's current scheme tends to be more fail-safe when interacting with other systems t

Re: [Python-3000] Changing the import machinery

Phillip J. Eby wrote: > There are only two things wrong with PEP 302 IMO, and neither is its "fault". > > The first is that the "classic" import machinery isn't on sys.meta_path, > and the 'imp' API isn't defined in terms of PEP 302. Those two things > can't change without introducing backward

Re: [Python-3000] Type Comparisons with Godel Numbers

This seems a good idea to remember when we get to that point. But let me point out that the key concern I have about the expense of type checking is what would be done when unchecked code calls a function with type-checked arguments. If I have some utterly dynamic code that comes up with a list of

Re: [Python-3000] parameter lists [was: Type Expressions]

On 4/21/06, Ron Adam <[EMAIL PROTECTED]> wrote: > Recently I found a case where I wanted to return something that was more > literally *nothing* than a None is. So maybe a null symbol of some sort > might be useful in other cases as well? You're not gonna get something that's a valid expression *

Re: [Python-3000] Futures in Python 3000

Michael Chermside wrote: > > Andy writes: > > > I still have a hard time understanding continuations 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 fi

Re: [Python-3000] New built-in function: bin()

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 IMO its (small) value doesn't warrant making, maintaining an

[Python-3000] Type Comparisons with Godel Numbers

With reference to the last Gfdl blog on type checking (http://www.artima.com/weblogs/viewpost.jsp?thread=87182). There is concern that type comparison at runtime using objects will be quite expensive, so this posting is about optimisation. An idea is to compute a single canonical string which su

Re: [Python-3000] Changing the import machinery

Greg Ewing <[EMAIL PROTECTED]> wrote: >> 2) Totally disallow recursive imports (!). > > That would be extremely undesirable. I've used languages > in which mutual imports weren't possible, and it's a > massive pain in the posterior. You end up having to > modularise things in awkward and unnatural

Re: [Python-3000] parameter lists [was: Type Expressions]

Ron Adam <[EMAIL PROTECTED]> wrote: > This *may* relate to None being an object which isn't the same as > "not a value". There currently isn't a way (that I know of) to > specify a generally null object outside of sequences. > > def f(a, b, c=Null, d=x): # Using None here wouldn't work.

Re: [Python-3000] Cleaning up argument list parsing (was Re: More wishful thinking)

Jim Jewett wrote: > On 4/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Some legal combinations: >> >>f(1, 2, 3, d=1) # Positional args a, b and c >>f(1, 2, 3, 4, 5, 6, d=1) # Positional args a, b and c and (4, 5, 6) as >> args >>f(2, a=1, d=1) # Provide a as a keyword arg instead >

[Python-3000] New built-in function: bin()

I've always wondered why there isn't a bin() built-in in Python. Built-in functions already exist for converting ints to hexadecimal and octal strings and vice versa i.e. s = hex() and int(s, 16) s = oct() and int(s, 8) but no bin() function for binary strings s = ??? and int(s, 2)

Re: [Python-3000] Futures in Python 3000

Tim Peters wrote: > Asynch programming wasn't at all a goal of generators, and Twisted is > well worth looking into for those who want slicker asynch programming > tools. There might possibly be room for an alternative way of presenting the generator machinery that makes it look like less of an a

Re: [Python-3000] Changing the import machinery

On 4/20/06, Phillip J. Eby <[EMAIL PROTECTED]> 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 (l

Re: [Python-3000] Futures in Python 3000

Andy Sy wrote: > 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 to comprehend. Isn't a future just a coroutine, or something equivalent? Sometimes there's a

Re: [Python-3000] Changing the import machinery

Ian Bicking wrote: > try: > from string import Template > except ImportError: > from mypackage.backports.string24 import Template > > Doing this in a more elegent or formalized fashion might be nice. Have you seen my proposal for "or" in import statements? Would you consider that eleg

Re: [Python-3000] Changing the import machinery

Giovanni Bajo wrote: > 2) Totally disallow recursive imports (!). That would be extremely undesirable. I've used languages in which mutual imports weren't possible, and it's a massive pain in the posterior. You end up having to modularise things in awkward and unnatural ways to get around the res

Re: [Python-3000] Futures in Python 3000

Aurélien Campéas wrote: > 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 interes

Re: [Python-3000] Changing the import machinery

Phillip J. Eby wrote: > There are only two things wrong with PEP 302 IMO, and neither is its > "fault". > > The first is that the "classic" import machinery isn't on > sys.meta_path, and the 'imp' API isn't defined in terms of PEP 302. > Those two things can't change without introducing backward