Posted to python-dev and python-3000. Follow-ups to python-dev only please.
On 10/31/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> here's mine; it's fully backwards compatible, can go right into 2.6,
> and can be incrementally improved in future releases:
>
> 1) add a pathname wrapper to "
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" and an integer for the
> b
Travis E. Oliphant ieee.org> writes:
>
> Alexander Belopolsky wrote:
> > ...
> > 1. Should primitive types be associated with simple type codes
(short,
int, long,
> > float, double) or type/size pairs [(int,16), (int, 32), (int, 64),
(float, 32),
> > (float, 64)]?
> > - I prefer pairs
>
Alexander Belopolsky wrote:
> Travis Oliphant ieee.org> writes:
>> Don't lump those ideas together. Shapes and strides are necessary for
>> N-dimensional array's (it's essentially what *defines* the N-dimensional
>> array). I really don't want to sacrifice those in the extended buffer
>> pro
Travis Oliphant ieee.org> writes:
>
> Don't lump those ideas together. Shapes and strides are necessary for
> N-dimensional array's (it's essentially what *defines* the N-dimensional
> array). I really don't want to sacrifice those in the extended buffer
> protocol. If you want to separate
On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 01:46 am, [EMAIL PROTECTED] wrote:
> >On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >This is ironic coming from one of Python's celebrity geniuses. "We
> >made this class but we don't know how it works." Actually, it's
>
On 01:46 am, [EMAIL PROTECTED] wrote:>On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:>This is ironic coming from one of Python's celebrity geniuses. "We>made this class but we don't know how it works." Actually, it's>downright alarming coming from someone who knows Twisted inside and>out
On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 08:14 pm, [EMAIL PROTECTED] wrote:
> >(...) people have had to spend five years putting hard-to-read
> >os.path functions in the code, or reinventing the wheel with their own
> >libraries that they're not sure they can trust. I started
On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On 06:14 pm, [EMAIL PROTECTED] wrote:
> >[EMAIL PROTECTED] wrote:
> >
> >> I assert that it needs a better[1] interface because the current
> >> interface can lead to a variety of bugs through idiomatic, apparently
> >> correct usage. Al
Paul Moore wrote:
>
>
> Enough of the abstract. As a concrete example, suppose I have a (byte)
> string in my program containing some binary data - an ID3 header, or a
> TCP packet, or whatever. It doesn't really matter. Does your proposal
> offer anything to me in how I might manipulate that dat
Alexander Belopolsky wrote:
> Travis Oliphant ieee.org> writes:
>
>
b = buffer(array('d', [1,2,3]))
>
>
> there is not much that I can do with b. For example, if I want to pass it to
> numpy, I will have to provide the type and shape information myself:
>
>
numpy.ndarray(shape=(3,),
Fredrik Lundh wrote:
> Chris Barker wrote:
>
>
>>While /F suggested we get off the PIL bandwagon
>
>
> I suggest we drop the obsession with pointers to memory areas that are
> supposed to have a specific format; modern data access API:s don't work
> that way for good reasons, so I don't see w
On 11/1/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote:
> Let's just start with that. The way I see the problem is that buffer protocol
> is fine as long as your data is an array of bytes, but if it is an array of
> doubles, you are out of luck. So, while I can do
>
> >>> b = buffer(array('d',
Travis Oliphant ieee.org> writes:
> Frankly, I'd be happy enough to start with
> "typecodes" in the extended buffer protocol (that's where the array
> module is now) and then move up to something more complete later.
>
Let's just start with that. The way I see the problem is that buffer proto
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>2) complex-valued types (you might argue that it's just a 2-array of
>>floats, but you could say the same thing about int as an array of
>>bytes). The point is how do people interpret the data. Complex-valued
>>data-types are very commo
On 08:14 pm, [EMAIL PROTECTED] wrote:>Argh, it's difficult to respond to one topic that's now spiraling into>two conversations on two lists.>[EMAIL PROTECTED] wrote:>(...) people have had to spend five years putting hard-to-read>os.path functions in the code, or reinventing the wheel with their own
Fredrik Lundh wrote:
> Chris Barker wrote:
>
>
>>While /F suggested we get off the PIL bandwagon
>
>
> I suggest we drop the obsession with pointers to memory areas that are
> supposed to have a specific format; modern data access API:s don't work
> that way for good reasons, so I don't see w
On 11/1/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> That's also an interesting issue for the datatypes PEP: are datatype
> objects meant to be immutable?
>
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. In Travi
On 06:14 pm, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>>> I assert that it needs a better[1] interface because the current>> interface can lead to a variety of bugs through idiomatic, apparently>> correct usage. All the more because many of those bugs are related to>> critical errors such
Chris Barker wrote:
> While /F suggested we get off the PIL bandwagon
I suggest we drop the obsession with pointers to memory areas that are
supposed to have a specific format; modern data access API:s don't work
that way for good reasons, so I don't see why Python should grow a
standard based
Martin v. Löwis v.loewis.de> writes:
> Can you please give examples for real-world applications of this
> interface, preferably examples involving multiple
> independently-developed libraries?
OK -- here's one I haven't seen in this thread yet:
wxPython has a lot code to translate between vario
Alexander Belopolsky schrieb:
> I would also like to mention one more difference between NumPy datatypes
> and ctypes that I did not see discussed. In ctypes arrays of different
> shapes are represented using different types. As a result, if the object
> exporting its buffer is resized, the datat
Martin v. Löwis v.loewis.de> writes:
>
> I'm afraid of "dead" specifications, things whose only motivation is
> that they look nice. They are just clutter. There are a few examples
> of this already in Python, like the character buffer interface or
> the multi-segment buffers.
>
Multi-segment
Travis Oliphant schrieb:
>>> r_field = PyDict_GetItemString(dtype,'r');
>>>
> Actually it should read PyDict_GetItemString(dtype->fields).The
> r_field is a tuple (data-type object, offset). The fields attribute is
> (currently) a Python dictionary.
Ok. This seems to be missing in the PE
Travis E. Oliphant ieee.org> writes:
> What if we look at this from the angle of trying to communicate
> data-formats between different libraries (not change the way anybody
> internally deals with data-formats).
>
> For example, ctypes has one way to internally deal with data-formats
> (usi
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>> Or, if it does have uses independent of the buffer extension: what
>>> are those uses?
>>>
>> So that NumPy and ctypes and audio libraries and video libraries and
>> database libraries and image-file format libraries can communic
Argh, it's difficult to respond to one topic that's now spiraling into
two conversations on two lists.
[EMAIL PROTECTED] wrote:
> On 03:14 am, [EMAIL PROTECTED] wrote:
>
> >One thing is sure -- we urgently need something better than os.path.
> >It functions well but it makes hard-to-read and unpyt
Travis E. Oliphant schrieb:
> I was too hasty. There are some things actually missing from ctypes:
I think Thomas can correct me if I'm wrong: I think endianness is
supported (although this support seems undocumented). There seems
to be code that checks for the presence of a _byteswapped_ attribu
Travis E. Oliphant schrieb:
>> Or, if it does have uses independent of the buffer extension: what
>> are those uses?
>
> So that NumPy and ctypes and audio libraries and video libraries and
> database libraries and image-file format libraries can communicate about
> data-formats using the same e
Jim Jewett wrote:
> I'm still not sure exactly what is missing from ctypes. To make this
> concrete:
I was too hasty. There are some things actually missing from ctypes:
1) long double (this is not the same across platforms, but it is a
data-type).
2) complex-valued types (you might argue tha
On 11/1/06, Erik Forsberg <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-Hash: SHA1"Brett Cannon" <[EMAIL PROTECTED]> writes:> On 11/1/06, Stefan Seefeld <
[EMAIL PROTECTED]> wrote: Brett Cannon wrote:>> > On 11/1/06, Stefan Seefeld <[EMAIL PROTECTED]> wrote: >> Right. Brett,
On 10:06 am, g.brandl at gmx.net wrote:
>> What a successor to os.path needs is not security, it's a better
(more pythonic,
>> if you like) interface to the old functionality.
Glyph:
> Why?
> Rushing ... could exacerbate a very real problem, e.g.
> the security and data-integrity implications of
Jim Jewett wrote:
> I'm still not sure exactly what is missing from ctypes. To make this
> concrete:
I think the only thing missing from ctypes "expressiveness" as far as I
can tell in terms of what you "can" do is the byte-order representation.
What is missing is ease-of use for producers and
On 11/1/06, Stefan Seefeld <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 11/1/06, Stefan Seefeld <[EMAIL PROTECTED]> wrote:>> Right. Brett, do we need accounts on python.org
for this ?>>> Yep. It just requires SSH 2 keys from each of you. You can then email> python-dev with those keys and y
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> What if we look at this from the angle of trying to communicate
>> data-formats between different libraries (not change the way anybody
>> internally deals with data-formats).
>
> ISTM that this is not the right approach. If the purpose of
I'm still not sure exactly what is missing from ctypes. To make this concrete:
You have an array of 500 elements meeting
struct {
int simple;
struct nested {
char name[30];
char addr[45];
int amount;
}
ctypes can describe this as
class n
[EMAIL PROTECTED] wrote:
> I assert that it needs a better[1] interface because the current
> interface can lead to a variety of bugs through idiomatic, apparently
> correct usage. All the more because many of those bugs are related to
> critical errors such as security and data integrity.
in
[EMAIL PROTECTED] wrote:
> On 10:06 am, [EMAIL PROTECTED] wrote:
> >What a successor to os.path needs is not security, it's a better (more
> pythonic,
> >if you like) interface to the old functionality.
>
> Why?
>
> I assert that it needs a better[1] interface because the current
> interface
Travis E. Oliphant schrieb:
> What if we look at this from the angle of trying to communicate
> data-formats between different libraries (not change the way anybody
> internally deals with data-formats).
ISTM that this is not the right approach. If the purpose of the datatype
object is just to c
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
> every special case. The array interface
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.
What if we look at this from the angle of trying to communicate
data-formats between different libraries (not change the way anybody
internally deals
On 10:06 am, [EMAIL PROTECTED] wrote:>What a successor to os.path needs is not security, it's a better (more pythonic,>if you like) interface to the old functionality.Why?I assert that it needs a better[1] interface because the current interface can lead to a variety of bugs through idiomatic, appa
Fredrik Lundh wrote:
> Terry Reedy wrote:
>
>> I believe that at present PyGame can only work with external images that it
>> is programmed to know how to import. My guess is that if image source
>> program X (such as PIL) described its data layout in a way that NumPy could
>> read and act on,
Martin v. Löwis v.loewis.de> writes:
>
> Bill Baxter schrieb:
> > Basically in my code I want to be able to take the binary data descriptor
> > and
> > say "give me the 'r' field of this pixel as an integer".
> >
> > Is either one (the PEP or c-types) clearly easier to use in this case?
> > W
On Wed, 01 Nov 2006 11:06:14 +0100, Georg Brandl <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> On 03:14 am, [EMAIL PROTECTED] wrote:
>>
>> >One thing is sure -- we urgently need something better than os.path.
>> >It functions well but it makes hard-to-read and unpythonic code.
>>
>> I'm
Jonathan Lange wrote:
> Then let us discuss that.
Glyph's references to bike sheds went right over your head, right?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
On 11/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > On 03:14 am, [EMAIL PROTECTED] wrote:
> >
> > >One thing is sure -- we urgently need something better than os.path.
> > >It functions well but it makes hard-to-read and unpythonic code.
> >
> > I'm not so sure. Th
On behalf of the Python development team and the Python
community, I'm happy to announce the release of Python 2.3.6
(FINAL).
Python 2.3.6 is a security bug-fix release. While Python 2.5
is the latest version of Python, we're making this release for
people who are still running Python 2.3. Unlike
Paul Jimenez wrote:
> I submitted patch 1462525 awhile back to
> solve the problem described even longer ago in
> http://mail.python.org/pipermail/python-dev/2005-November/058301.html
> and I'm wondering what my appropriate next steps are. Honestly, I don't
> care if you take my patch or someone el
[EMAIL PROTECTED] wrote:
> On 03:14 am, [EMAIL PROTECTED] wrote:
>
> >One thing is sure -- we urgently need something better than os.path.
> >It functions well but it makes hard-to-read and unpythonic code.
>
> I'm not so sure. The need is not any more "urgent" today than it was 5
> years ago
Fredrik Lundh wrote:
> Talin wrote:
>
>> I'm right in the middle of typing up a largish post to go on the
>> Python-3000 mailing list about this issue. Maybe we should move it over
>> there, since its likely that any path reform will have to be targeted at
>> Py3K...?
>
> I'd say that any prop
Travis Oliphant wrote:
> Nick Coghlan wrote:
>> In fact, it may make sense to just use the lists/strings directly as the
>> data
>> exchange format definitions, and let the various libraries do their own
>> translation into their private format descriptions instead of creating a new
>> one-type
[EMAIL PROTECTED] wrote:
> I am not addressing this message to the py3k list because its general
> message of extreme conservatism on new features is more applicable to
> python-dev. However, py3k designers might also take note: if py3k is
> going to do something in this area and drop support
On 03:14 am, [EMAIL PROTECTED] wrote:>One thing is sure -- we urgently need something better than os.path.>It functions well but it makes hard-to-read and unpythonic code.I'm not so sure. The need is not any more "urgent" today than it was 5 years ago, when os.path was equally "unpythonic" and unr
Bill Baxter schrieb:
> Basically in my code I want to be able to take the binary data descriptor and
> say "give me the 'r' field of this pixel as an integer".
>
> Is either one (the PEP or c-types) clearly easier to use in this case? What
> would the code look like for handling both formats gene
Paul Jimenez schrieb:
> I submitted patch 1462525 awhile back to
> solve the problem described even longer ago in
> http://mail.python.org/pipermail/python-dev/2005-November/058301.html
> and I'm wondering what my appropriate next steps are. Honestly, I don't
> care if you take my patch or someone
56 matches
Mail list logo
