There seems to be an unconditional PyErr_Clear() in
_PyObject_LengthHint(). I think that could and should be much more
careful; it probably should only ignore AttributeErrors (though there
may be unittests to the contrary).
On Tue, Jan 13, 2009 at 8:24 PM, Dino Viehland wrote:
> We had a bug repo
We had a bug reported that effectively boils down to we’re not swallowing
exceptions when list calls __len__
(http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=20598).
We can obviously make the change to catch exceptions here in IronPython even if
it seems like a bad
> Perhaps it would be useful to provide generic support for integer types
> that might have different widths on different platforms? e.g.:
>
> uid_t uid = PyNumber_AS_INT_BY_SIZE(number_ob, uid_t);
>
> That way, the core does not need to know about every blah_t type used by
> POSIX and extension
On Tue, Jan 13, 2009 at 2:33 PM, "Martin v. Löwis" wrote:
> If we start with that, we end up with ParseTuple formats for
> uid_t, gid_t, pid_t, and the other dozen integral types that
> POSIX has invented.
>
Perhaps it would be useful to provide generic support for integer types that
might have d
Le Tuesday 13 January 2009 22:47:52 Victor Stinner, vous avez écrit :
> Le Tuesday 13 January 2009 21:33:28 Martin v. Löwis, vous avez écrit :
> > I would do this through a converter function (O&), but yes,
> > making it private to the io library sounds about right. Who
> > else would benefit from
Le Tuesday 13 January 2009 21:33:28 Martin v. Löwis, vous avez écrit :
> I would do this through a converter function (O&), but yes,
> making it private to the io library sounds about right. Who
> else would benefit from it?
On Linux, mmap() prototype is:
void *mmap(void *start, size_t len
Nick Coghlan gmail.com> writes:
>
> I'd say start with the private version in IO lib, and then if there is
> demand consider moving it to abstract.h (but, like Martin, I don't
> expect such demand to ever develop).
Ok, I'm gonna do this.
Thanks
Antoine.
__
>> For argument parsing, you should use "long long" if SIZEOF_OFF_T is 8
>> and long long is supported, and then assign to off_t as appropriate.
>
> It's wrong, because floats would be accepted as argument to the seek() method.
I see.
> Hence the need for (at least) PyNumber_AsOff_t.
> (of cours
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> -1. How many functions actually require that type?
>
> Functions in the IO lib. I can't tell you how many, let's say a dozen.
>
>>> (the motivation is systems where Py_ssize_t is 32-bits wide, but large file
>>> support makes off_t
Now that Python has turned 19, I've started blogging about Python's
history. I hope to keep it up at one article per week. So far, I've
written an intro to the series
(http://neopythonic.blogspot.com/2009/01/history-of-python-introduction.html)
and posted two chapters to the history blog itself
(ht
Martin v. Löwis v.loewis.de> writes:
>
> -1. How many functions actually require that type?
Functions in the IO lib. I can't tell you how many, let's say a dozen.
> > (the motivation is systems where Py_ssize_t is 32-bits wide, but large file
> > support makes off_t 64 bits wide)
>
> For argum
> Is it ok to add the following:
> * a Py_off_t type which is typedef'd to either Py_LONG_LONG (Windows) or
> off_t
> (others)
> * three C API functions: PyNumber_AsOff_t, PyLong_AsOff_t, PyLong_FromOff_t
> * an additional type code for PyArg_ParseTuple and friends; I suggest 'N'
> since
> 'n'
On Tue, Jan 13, 2009 at 06:09, Kristján Valur Jónsson
wrote:
> By accident i had a dir called @test in my PCBuild directory when I was
> running the testsuite.
>
> This caused the test_support to define TESTFN as tmp/@test.
>
>
>
> This again caused a number of tests to fail. One issue I have alr
Hello,
Python currently has an API to deal with size_t-like numbers (Py_ssize_t,
PyNumber_AsSsize_t), but it doesn't have similar facilities for off_t.
Is it ok to add the following:
* a Py_off_t type which is typedef'd to either Py_LONG_LONG (Windows) or off_t
(others)
* three C API functions:
By accident i had a dir called @test in my PCBuild directory when I was running
the testsuite.
This caused the test_support to define TESTFN as tmp/@test.
This again caused a number of tests to fail. One issue I have already covered
in http://bugs.python.org/issue4927
Another issue is test_impo
Martin v. Löwis wrote:
>> Do we need to recruit community support
>> to get this stuff moving? Experience suggests that "if we build it" they
>> will not come unless and until they are led by the nose.
>
> There is
>
> http://pypi.python.org/pypi?:action=browse&c=533
> (Programming Language :: Py
> Do we need to recruit community support
> to get this stuff moving? Experience suggests that "if we build it" they
> will not come unless and until they are led by the nose.
There is
http://pypi.python.org/pypi?:action=browse&c=533
(Programming Language :: Python :: 3)
It currently lists some
17 matches
Mail list logo
