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
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
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
[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
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
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
[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
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
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
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
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 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
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
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,
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
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
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
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
[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
[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
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
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
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
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 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
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,
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
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
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
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
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
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
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
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
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:
> 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
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
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
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
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 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
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
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
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',
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
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,),
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
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
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 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 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
>
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
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 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
>
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
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 "
56 matches
Mail list logo
