Jump to page: 1 24  
Page
Thread overview
bigint <-> python long
Sep 05, 2012
Ellery Newcomer
Sep 05, 2012
Paul D. Anderson
Sep 05, 2012
Paul D. Anderson
Sep 06, 2012
Don Clugston
Sep 06, 2012
bearophile
Sep 06, 2012
Ellery Newcomer
Sep 06, 2012
bearophile
Sep 06, 2012
Ellery Newcomer
Sep 06, 2012
Russel Winder
Sep 07, 2012
Ellery Newcomer
Sep 07, 2012
bearophile
Sep 08, 2012
Russel Winder
Sep 08, 2012
Russel Winder
Sep 08, 2012
Ellery Newcomer
Re: D and SCons [ was Re: bigint <-> python long ]
Sep 08, 2012
Russel Winder
Sep 09, 2012
Johannes Pfau
Sep 09, 2012
Russel Winder
Re: D and SCons
Sep 09, 2012
bearophile
Sep 09, 2012
Johannes Pfau
Sep 09, 2012
bearophile
Sep 09, 2012
Adam D. Ruppe
Sep 09, 2012
Ali Çehreli
Sep 09, 2012
Russel Winder
Sep 09, 2012
Ali Çehreli
Sep 09, 2012
Brad Roberts
Sep 10, 2012
Johannes Pfau
Sep 10, 2012
Johannes Pfau
Sep 06, 2012
bearophile
Sep 06, 2012
Ellery Newcomer
Sep 06, 2012
Jacob Carlborg
Sep 06, 2012
Ellery Newcomer
Sep 07, 2012
Ellery Newcomer
Sep 10, 2012
Ellery Newcomer
Sep 10, 2012
bearophile
Sep 10, 2012
Ellery Newcomer
Sep 11, 2012
Russel Winder
Sep 11, 2012
Ellery Newcomer
Sep 12, 2012
Ellery Newcomer
September 05, 2012
Hey.

Investigating the possibility of providing this conversion in pyd.

Python provides an api for accessing the underlying bytes.

std.bigint seemingly doesn't. Am I missing anything?
September 05, 2012
On Wednesday, 5 September 2012 at 18:13:40 UTC, Ellery Newcomer wrote:
> Hey.
>
> Investigating the possibility of providing this conversion in pyd.
>
> Python provides an api for accessing the underlying bytes.
>
> std.bigint seemingly doesn't. Am I missing anything?

No, I don't believe so. AFAIK there is no public access to the underlying array, but I think it is a good idea.

I suspect the reason for not disclosing the details is to disallow anyone putting the data into an invalid state. But read-only access would be safe.
September 05, 2012
On Wednesday, 5 September 2012 at 19:23:11 UTC, Paul D. Anderson wrote:

> No, I don't believe so. AFAIK there is no public access to the underlying array, but I think it is a good idea.

I meant to say I think that access to the array is a good idea, not the lack of access. Words are hard!


September 06, 2012
Ellery Newcomer:

> Investigating the possibility of providing this conversion in pyd.

Are you updating Pyd? :-)

Bye,
bearophile
September 06, 2012
On 09/05/2012 05:02 PM, bearophile wrote:
> Ellery Newcomer:
>
>> Investigating the possibility of providing this conversion in pyd.
>
> Are you updating Pyd? :-)
>
> Bye,
> bearophile

Yep. Have any suggestions for supported conversion out of the box? From the standard library, I already have Complex, Tuple, and now BigInt. Was thinking maybe the datetime stuff..

Also, which of the following looks more appealing to you?


wrap_class!(Foo, Def!(Foo.bar, PyName!"__len__"))();

wrap_class!(Foo, Len!(Foo.bar))();


they wrap Foo and give it an overriden __len__; the latter is how it is done at the moment (with similar templates for the other operators), but boost::python does something akin to the former. PyName is in the former because Def takes too many optional string arguments.
September 06, 2012
Ellery Newcomer:

> Yep.

Oh, good.


> Have any suggestions for supported conversion out of the box?

There are several important cases, like:

Some D lazy ranges <==> Python lazy iterators/generators

array.array <==> D arrays

NumPy arrays <==> D arrays


> Also, which of the following looks more appealing to you?

I don't know.

Bye,
bearophile
September 06, 2012
On 09/05/2012 07:10 PM, bearophile wrote:
>
> Some D lazy ranges <==> Python lazy iterators/generators
>

I'll look into this one.

> array.array <==> D arrays

just checked, looks like we have it:

PyStmts(q"{from array import array; a = array('i', [44,33,22,11]);}", "testing");
assert(PyEval!(int[])("a", "testing") == [44,33,22,11]);

I think if the python object is iterable, it can be converted to array.

Matrices might pose a problem. But user can define custom conversions if need be.

>
> NumPy arrays <==> D arrays
>

I have never used NumPy. Are its arrays special?

>
>> Also, which of the following looks more appealing to you?
>
> I don't know.
>

ok, I'll be lazy then.

September 06, 2012
On 2012-09-06 04:10, bearophile wrote:

> There are several important cases, like:
>
> Some D lazy ranges <==> Python lazy iterators/generators
>
> array.array <==> D arrays
>
> NumPy arrays <==> D arrays

Associative arrays?

-- 
/Jacob Carlborg
September 06, 2012
Sorry, I missed earlier bits of this thread…

On Wed, 2012-09-05 at 19:37 -0700, Ellery Newcomer wrote:
> On 09/05/2012 07:10 PM, bearophile wrote:
> >
> > Some D lazy ranges <==> Python lazy iterators/generators
> >
> 
> I'll look into this one.
> 
> > array.array <==> D arrays
> 
> just checked, looks like we have it:
> 
> PyStmts(q"{from array import array; a = array('i', [44,33,22,11]);}",
> "testing");
> assert(PyEval!(int[])("a", "testing") == [44,33,22,11]);
> 
> I think if the python object is iterable, it can be converted to array.

I am guessing this is interfacing to CPython, remember there is also PyPy and ActiveState, they have different ways of doing things.  Well the ActiveState C API will be very close to the CPython C API, but PyPy (which is the best Python 2.7 just now) doesn't have a C API since it is written in RPython.

> Matrices might pose a problem. But user can define custom conversions if need be.
> 
> >
> > NumPy arrays <==> D arrays
> >
> 
> I have never used NumPy. Are its arrays special?

Oh yes.

NumPy is basically a subsystem that Python applications make calls into. Although the data structure can be accessed and amended, algorithms on the data structures should never be written in Python, they should always be function calls into the NumPy framework.

> >
> >> Also, which of the following looks more appealing to you?
> >
> > I don't know.
> >
> 
> ok, I'll be lazy then.
> 

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


September 06, 2012
On 05/09/12 21:23, Paul D. Anderson wrote:
> On Wednesday, 5 September 2012 at 18:13:40 UTC, Ellery Newcomer wrote:
>> Hey.
>>
>> Investigating the possibility of providing this conversion in pyd.
>>
>> Python provides an api for accessing the underlying bytes.
>>
>> std.bigint seemingly doesn't. Am I missing anything?
>
> No, I don't believe so. AFAIK there is no public access to the
> underlying array, but I think it is a good idea.
>
> I suspect the reason for not disclosing the details is to disallow
> anyone putting the data into an invalid state. But read-only access
> would be safe.

No, it's just not disclosed because I didn't know the best way to do it.
I didn't want to put something in unless I was sure it was correct.
(And a key part of that, is what is required to implement BigFloat).

« First   ‹ Prev
1 2 3 4