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
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
[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 for
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
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 proposal that
[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, when
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 else's
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 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 not so sure.
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, the
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,
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
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
[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 can lead
[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.
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
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 the
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 your first.last
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: SHA1Brett 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, do we need accounts on
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 that
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
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_
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 unpythonic
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 communicate about
Travis E. Oliphant oliphant.travis at 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
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 PEP. The
Martin v. Löwis martin at 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 datatype
Martin v. Löwis martin at 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
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 as
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 Travis'
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 why Python
On 08:14 pm, [EMAIL PROTECTED] wrote:Argh, it's difficult to respond to one topic that's now spiraling intotwo conversations on two lists.[EMAIL PROTECTED] wrote:(...) people have had to spend five years putting hard-to-reados.path functions in the code, or reinventing the wheel with their
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 common. It is
Travis Oliphant oliphant.travis at 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
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 why Python
Alexander Belopolsky wrote:
Travis Oliphant oliphant.travis at 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:
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 data
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. All the more
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 to use
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. "Wemade this class but we don't know how it works." Actually, it'sdownright alarming coming from someone who knows Twisted inside andout yet
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
downright
Travis Oliphant oliphant.travis at 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
Travis E. Oliphant oliphant.travis at 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
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
bitsize? That's
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
52 matches
Mail list logo
