Guido van Rossum wrote:
> Nevertheless, I kind of like this, and would like someone to produce a
> patch for this approach. It is my opinion that without working code it
> is too easy to overlook design flaws. Since you are keen to have this
> in 2.6, the solution would have to be backwards compat
no, because i use the remote isinstance. the code i gave was just a
"how to". the real code would be more like:
def __isinstance__(self, types):
return self.sync_request("isinstance", types)
and then
isinstance(conn.modules.sys.path, conn.modules.__builtin__.list) # True
(of course that's in
Guido van Rossum wrote:
> Any volunteers? Without code this proposal is dead in the water.
given that nobody's even bothered to look at Larry's patch for 2.X, it
seems to take a bit more than just code to get something into Py3K.
Talin obviously suffers from a serious case of NIH, but does that
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> - Can't we require a C99 compiler and use C99 struct initialization?
> Then the table lines could look like
>
> tp_new = Noddy_new,
> tp_init = Noddy_init,
The C99 syntax is:
.tp_new = Noddy_new,
.tp_init = Noddy_init,
GCC also suppor
Marcin 'Qrczak' Kowalczyk wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> writes:
>
>> - Can't we require a C99 compiler and use C99 struct initialization?
>> Then the table lines could look like
>>
>> tp_new = Noddy_new,
>> tp_init = Noddy_init,
>
> The C99 syntax is:
>
> .tp_n
I'd love to see this idea explored; it sounds like it might well be
the right solution. (It's also an extension of the "separate tool for
conversion" idea that I floated earlier.)
One requirement: it should be possible to resume development and the
preprocessor at any time. I don't like tools that
I was reading the PEP regarding the Switch/Case statement (http://
www.python.org/dev/peps/pep-3103/), and have a few thoughts about it.
1) Proposed layout
Here is how I propose the 'switch' statement to be constructed.
Further on I will give the reasoning behind the syntax. As you can
see,
On 12/2/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I'd love to see this idea explored; it sounds like it might well be
the right solution. (It's also an extension of the "separate tool for
conversion" idea that I floated earlier.)
One requirement: it should be possible to resume developmen
Fredrik Lundh wrote:
> Guido van Rossum wrote:
>
>> Any volunteers? Without code this proposal is dead in the water.
>
> given that nobody's even bothered to look at Larry's patch for 2.X, it
> seems to take a bit more than just code to get something into Py3K.
> Talin obviously suffers from a
Thomas Dixon wrote:
> I hope I explained myself well enough, and that I haven't taken up too
> much of your time.
Thomas,
As you know from reading the PEP, there are some deep unsolved
controversies regarding the design of the switch statement, which your
suggestion does not address. Syntactic
Talin wrote:
> So I don't think it's the case that nobody's even bothered to look at
> Larry's patch
so are you basing your patch on his work?
> People have looked at the patch and suggested taking a different
> approach.
really? I haven't seen much of a consensus for the string-literals
i
Brett Cannon wrote:
> So you are basically saying you want the preprocessor step to be
> lightweight enough that you always develop with the file before the
> preprocessor is run instead of with some generated file, right?
exactly. the developer should *never* edit generated data (whether
tha
Fredrik Lundh wrote:
> Brett Cannon wrote:
>
>
>> So you are basically saying you want the preprocessor step to be
>> lightweight enough that you always develop with the file before the
>> preprocessor is run instead of with some generated file, right?
>>
>
> exactly. the developer shoul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 2, 2006, at 3:58 PM, Neil Toronto wrote:
> One potential problem with this idea is that you can't drop into C
> code
> without calling an external C function, which may not be acceptable in
> some instances. Another is that if you want to ana
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Dec 2, 2006, at 3:58 PM, Neil Toronto wrote:
>
>
>> One potential problem with this idea is that you can't drop into C
>> code
>> without calling an external C function, which may not be acceptable in
>> some instance
Le samedi 02 décembre 2006 à 13:58 -0700, Neil Toronto a écrit :
> One potential problem with this idea is that you can't drop into C code
> without calling an external C function, which may not be acceptable in
> some instances.
Are you sure ?
I think you could declare a C macro as an "externa
My preference is for a table-based version over a "lots-of-calls"
approach. I think the idea of using predefined (integer) constants
instead of string constants fits fine into the table-based approach.
However I'm not sure that a string-based approach is necessarily bad
-- we use that now for every
On 12/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:
> So you are basically saying you want the preprocessor step to be
> lightweight enough that you always develop with the file before the
> preprocessor is run instead of with some generated file, right?
exactly. the deve
On 12/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Regardless, one could take a Pyrex bent on this and having Python-like
> > method declarations but have C as the code body::
>
> (some days, I wonder if we shouldn't just include Pyrex and tell every-
> one to use that for *all* their extens
On 12/2/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 2, 2006, at 3:58 PM, Neil Toronto wrote:
> One potential problem with this idea is that you can't drop into C
> code
> without calling an external C function, which may not be acceptable in
Talin <[EMAIL PROTECTED]> wrote:
> Thomas Dixon wrote:
> > I hope I explained myself well enough, and that I haven't taken up too
> > much of your time.
>
> As you know from reading the PEP, there are some deep unsolved
> controversies regarding the design of the switch statement, which your
>
Guido van Rossum wrote:
> The deficiencies of email shouldn't be dictating the language.
The interpreter prompt is hardly part of the language,
and I don't think it would be unreasonable to make a
small change here to avoid unnecessarily conflicting
with a well-established convention (I wouldn't c
Bill Janssen wrote:
> Where would the standalone function live? How would it be associated
> with whatever open() returns?
Three possibilities come to mind:
a) builtin
b) imported from a module
c) static function of the file type
Since there will probably be a number of such functions
(readlin
Mike Klaas wrote:
> Reducing the pyrex magic and adding more detailed errors to the code
> generator should eliminate much of the "code-peering" that is
> currently necessary (at least, by me) when writing extensions.
Can you expand on that? What magic would you like to
have removed, and what new
Antoine Pitrou wrote:
> I think you could declare a C macro as an "external function" in the
> Pyrex code and Pyrex would probably be happy with that.
Yes, that works as long as you can declare it as having
parameter and return types that make sense to Pyrex.
There are a few things that can't be
Fredrik Lundh wrote:
> (some days, I wonder if we shouldn't just include Pyrex and tell every-
> one to use that for *all* their extension work. Greg? how much work
> would it be to equip Pyrex with a "retargetable" backend?)
If you're talking about making it generate code for languages
that
Guido van Rossum wrote:
> My preference is for a table-based version over a "lots-of-calls"
> approach. I think the idea of using predefined (integer) constants
> instead of string constants fits fine into the table-based approach.
> However I'm not sure that a string-based approach is necessarily
Greg Ewing wrote:
> Guido van Rossum wrote:
>> The deficiencies of email shouldn't be dictating the language.
>
> The interpreter prompt is hardly part of the language,
Except that the doctest module and the prevalence of interactive prompt
snippets in the documentation mean that it *is* effecti
On 12/2/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > My preference is for a table-based version over a "lots-of-calls"
> > approach. I think the idea of using predefined (integer) constants
> > instead of string constants fits fine into the table-based approach.
> > However I'
Guido van Rossum wrote:
> The ordering argument is also handled by using C99 initializers.
Not being able to compile extension modules under Visual Studio seems
like a show stopper to me.
-- Talin
___
Python-3000 mailing list
[email protected]
ht
30 matches
Mail list logo
