Dino Viehland wrote:
> What about instead defining __argspec__ for built-in functions/method
> objects and allowing all the implementations to implement it? We could
> all agree to return:
>
> [
> (return_type, (arg_types,...)),
> (return_type, (arg_types,...)),
> ]
>
> Then inspect
Michael Foord wrote:
> I have IronPython specific versions of several of these functions which
> use .NET reflection and inspect could fallback to if sys.platform ==
> 'cli'. Would it be ok for me to add these to the inspect module?
> Obviously the tests would only run on IronPython... The behaviou
2009/5/19 Maciej Fijalkowski :
> From my observation (mostly according to jython), such changes easily get out
> of
> sync. The net result is that you have one, outdated, version in stdlib
> and other implementation, like IronPython is maintaining it's own
> anyway. IMO it's easy enough
> to maint
On Tue, May 19, 2009 at 9:26 PM, Benjamin Peterson wrote:
> 2009/5/19 Michael Foord :
>> I have IronPython specific versions of several of these functions which use
>> .NET reflection and inspect could fallback to if sys.platform == 'cli'.
>> Would it be ok for me to add these to the inspect modul
On Tue, May 19, 2009 at 7:26 PM, Benjamin Peterson wrote:
> 2009/5/19 Michael Foord :
>> I have IronPython specific versions of several of these functions which use
>> .NET reflection and inspect could fallback to if sys.platform == 'cli'.
>> Would it be ok for me to add these to the inspect modul
2009/5/19 Michael Foord :
> I have IronPython specific versions of several of these functions which use
> .NET reflection and inspect could fallback to if sys.platform == 'cli'.
> Would it be ok for me to add these to the inspect module? Obviously the
> tests would only run on IronPython... The beh
Hello all,
The inspect module (inspect.get_argspec etc) work fine for Python
functions and classes in IronPython, but they don't work on .NET types
which don't have the Python function attributes like im_func etc.
I have IronPython specific versions of several of these functions which
use .N
At 04:04 PM 5/19/2009 +0200, Tarek Ziadé wrote:
On Sat, May 16, 2009 at 6:55 PM, P.J. Eby wrote:
>
> 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a
> valid character in filenames?
I am changing this into a . for now.
What about Antoine's idea about doing a quote() o
2009/5/19 Tarek Ziadé :
> On Sat, May 16, 2009 at 6:55 PM, P.J. Eby wrote:
>>
>> 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a
>> valid character in filenames?
>
> I am changing this into a . for now.
I'm not following this thread at all, but can I put a strong vote
*
Tarek Ziadé wrote:
On Sat, May 16, 2009 at 6:55 PM, P.J. Eby wrote:
1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a
valid character in filenames?
I am changing this into a . for now.
What about Antoine's idea about doing a quote() on the names ?
From my point of
On Tue, May 19, 2009 at 4:03 PM, Antoine Pitrou wrote:
> Ronald Oussoren mac.com> writes:
>>
>> Wouldn't it be possible to use a CSV file for this? That way we
>> wouldn't have to invent yet another escaping mechanism and there's
>> already good suppport for reading and writing CSV files in the
>
On Sat, May 16, 2009 at 6:55 PM, P.J. Eby wrote:
>
> 1. Why ';' separation, instead of tabs as in PEP 262? Aren't semicolons a
> valid character in filenames?
I am changing this into a . for now.
What about Antoine's idea about doing a quote() on the names ?
>From my point of view seems more
Ronald Oussoren mac.com> writes:
>
> Wouldn't it be possible to use a CSV file for this? That way we
> wouldn't have to invent yet another escaping mechanism and there's
> already good suppport for reading and writing CSV files in the
> standard library.
+1
We can even customize the delim
On 17 May, 2009, at 15:04, MRAB wrote:
Alexander Shigin wrote:
В Сбт, 16/05/2009 в 23:15 +0100, MRAB пишет:
FYI, on RISC OS '/' is a valid filename character and '.' is used as
the directory separator.
I'd probably say that TAB is s reasonable character to use, even
though it's OK in POSIX;
My perspective is as follows:
1) If PEP-384 had always been in place, my life would now be a lot easier.
2) Since it hasn't always been in place, its introduction won't help me
in the short term: there are an awful lot of extension modules that use
excluded functions (for example, all(?) PyCxx
15 matches
Mail list logo
