On 11/2/06, Mike Orr <[EMAIL PROTECTED]> wrote:
> Given the widely-diverging views on what, if anything, should be done
> to os.path, how about we make a PEP and a standalone implementation of
> (1) for now, and leave (2) and everything else for a later PEP.
Why write a PEP at this stage? Just rel
On 11/2/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> What do you mean by "manipulate the data." The proposal for a
> data-format object would help you describe that data in a standard way
> and therefore share that data between several library that would be able
> to understand the data (becau
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>>2. Should primitive type codes be characters or integers (from an enum) at
>>>C level?
>>>- I prefer integers
>>
>>>3. Should size be expressed in bits or bytes?
>>>- I prefer bits
>>>
>>
>>So, you want an integer enum for the "kind
Travis E. Oliphant schrieb:
> Travis E. Oliphant wrote:
>> Thanks for all the comments that have been given on the data-type
>> (data-format) PEP. I'd like opinions on an idea for revising the PEP I
>> have.
>
>>
>> 1) We could define a special string-syntax (or list syntax) that covers
>> ev
Ronald Oussoren schrieb:
> On Oct 31, 2006, at 6:38 PM, Thomas Heller wrote:
>
>>
>> This mechanism is probably a hack because it'n not possible to add
>> C accessible
>> fields to type objects, on the other hand it is extensible (in
>> principle, at least).
>
> I better start rewriting PyObj
On Nov 2, 2006, at 9:35 PM, Thomas Heller wrote:
Ronald Oussoren schrieb:
On Oct 31, 2006, at 6:38 PM, Thomas Heller wrote:
This mechanism is probably a hack because it'n not possible to add
C accessible
fields to type objects, on the other hand it is extensible (in
principle, at least).
T
>
> IIUC, so far the 'data-object' carries information about the structure
> of the data it describes.
>
> Couldn't it go a step further and have also some functionality?
> Converting the data into a Python object and back?
>
Yes, I had considered it to do that. That's why the setfunc and get
Alexander Belopolsky wrote:
> In ctypes arrays of different
> shapes are represented using different types. As a result, if the object
> exporting its buffer is resized, the datatype object cannot be reused, it
> has to be replaced.
I was thinking about that myself the other day.
I was thinking t
Fredrik Lundh wrote:
> the "right solution" for things like this is an *API* that lets you do
> things like:
>
> view = object.acquire_view(region, supported formats)
And how do you describe the "supported formats"?
That's where Travis's proposal comes in, as far
as I can see.
--
Greg
__
Mike Orr wrote:
>> * This is confusing as heck:
>> >>> os.path.join("hello", "/world")
>> '/world'
It's only confusing if you're not thinking of
pathnames as abstract entities.
There's a reason for this behaviour -- it's
so you can do things like
full_path = os.path.join(default_dir, fil
Travis Oliphant wrote:
> or just
>
> numpy.array(array.array('d',[1,2,3]))
>
> and leave-out the buffer object all together.
I think the buffer object in his example was just a
placeholder for "some arbitrary object that supports
the buffer interface", not necessarily another NumPy
array.
--
Gr
Alexander Belopolsky wrote:
> That's a question for Travis, but I would think that they would be
> immutable at the Python level, but mutable at the C level.
Well, anything's mutable at the C level -- the
question is whether you *should* be mutating it.
I think the datatype object should almost
[EMAIL PROTECTED] wrote:
>>>> os.path.join("hello", "slash/world")
>'hello/slash/world'
>>>> os.path.join("hello", "slash//world")
>'hello/slash//world'
>Trying to formulate a general rule for what the arguments to
> os.path.join are supposed to be is really hard.
If you're s
Mike Orr wrote:
> I have no idea why Microsoft thought it was a good idea to
> put the seven-odd device files in every directory. Why not force
> people to type the colon ("CON:").
Yes, this is a particularly stupid piece of braindamage
on the part of the designers of MS-DOS. As far as I
remember,
[EMAIL PROTECTED] wrote:
> Relative
> paths, if they should exist at all, should have to be explicitly linked
> as relative to something *else* (e.g. made absolute) before they can be
> used.
If paths were opaque objects, this could be enforced
by not having any way of constructing a path that
Travis E. Oliphant wrote:
> We have T_UBYTE and T_BYTE, etc. defined
> in structmember.h already. Should we just re-use those #defines while
> adding to them to make an easy to use interface for primitive types?
They're mixed up with size information, though,
which we don't want to do.
--
Greg
On 01:04 am, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>If you're serious about writing platform-agnostic>pathname code, you don't put slashes in the arguments>at all. Instead you do>> os.path.join("hello", "slash", "world")>>Many of the other things you mention are also a>result of not tr
On Nov 2, 2006, at 8:04 PM, Greg Ewing wrote:
>
> I think the datatype object should almost certainly
> be immutable. Since it's separated from the data
> it's describing, it's possible for one datatype
> object to describe multiple chunks of data. So
> you wouldn't want to mutate one in case it'
Alexander Belopolsky wrote:
> My main concern was that in ctypes the size of an array is a part of
> the datatype object and this seems to be redundant if used for the
> buffer protocol. Buffer protocol already reports the size of the
> buffer as a return value of bf_get*buffer methods.
I
Greg Ewing wrote:
> Mike Orr wrote:
>
>
>>>* This is confusing as heck:
>>> >>> os.path.join("hello", "/world")
>>> '/world'
>
>
> It's only confusing if you're not thinking of
> pathnames as abstract entities.
>
> There's a reason for this behaviour -- it's
> so you can do things like
>
>
Paul Moore gmail.com> writes:
> Somewhat. My understanding is that the python-level buffer object is
> frowned upon as not good practice, and is scheduled for removal at
> some point (Py3K, quite possibly?) Hence, any code that uses buffer()
> feels like it "needs" to be replaced by something "mo
On Nov 2, 2006, at 9:25 PM, Greg Ewing wrote:
>
> I think what would happen if you were interoperating with
> ctypes is that you would get a datatype describing one
> element of the array, together with the shape information,
> and construct a ctypes array type from that. And going
> the other wa
Steve Holden wrote:
> Greg Ewing wrote:
>
>>Having said that, I can see there could be an
>>element of confusion in calling it "join".
>>
>
> Good point. "relativise" might be appropriate,
Sounds like something to make my computer go at
warp speed, which would be nice, but I won't
be expecting a
Steve Holden wrote:
> Greg Ewing wrote:
>> Mike Orr wrote:
>> Having said that, I can see there could be an
>> element of confusion in calling it "join".
>>
> Good point. "relativise" might be appropriate, though something shorter
> would be better.
>
> regards
> Steve
The term used in many la
24 matches
Mail list logo
