Mike Krell schrieb:
>> Based on the behaviour of str and the fact that overriding unicode.__repr__
>> works just fine, I'd say file a bug on SF.
>
> Done. This is item 1583863.
Of course, it would be even better if you could also include a
odules might be more
appropriate, as might be the introduction of another module.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ich inherently cannot work for universal
binaries (i.e. you should look at the running interpreter, not
at pyconfig.h).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
of an
array? And then, it's not the size, but the number of elements?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ible to implement that. To do so, one would have to
modify the source of the buildbot master.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
d.
As I unification mechanism, I think it is insufficient. I doubt it
can express all the concepts that ctypes supports.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
upported, what are the use cases?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
code anything. Users of the
> data-format object could decide what they wanted to do with that
> information. We just need a standard way to communicate it through the
> buffer protocol.
This was actually a different sub-thread: why do you need to support
the 'U'
. They
> both want to describe that the memory they are sharing has some
> underlying binary structure.
Can you please give an example of such two packages, and an application
that needs them share data?
Regards,
Martin
___
Python-Dev mailing li
wonder whether it should be done, and whether
NumArray can then support this extended data model.
Regards,
Martin
(*) perhaps with the exception of incomplete types: C needs forward
references in its own syntax.
___
Python-Dev mailing list
Python-Dev@pyt
quot;green" on
the buildbot page, and you'd have to look into the log file to find
out which of the expected failures actually happened. This all could
work without changes to buildbot at all.
Regards,
Martin
___
Python-Dev mailing list
P
rs to
> co-operate needs an independent standard, which is what I assume this
> PEP is intended to provide.
Ok, I now understand the goal, although I still like to understand
this usecase better.
Regards,
Martin
___
Python-Dev mailing list
Pyt
wever, the PEP won't allow "understanding" the format. If I know I
have an array of 4-byte values: which of them is R, G, B, and A?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
is will give you dynamically-sized
objects (objects in C cannot really be "variable-sized", since the
size of a memory block has to be defined at allocation time, and
can't really change afterwards).
> String syntax is not needed to support all of these things.
Ok. That&
ght to have
the same type", then this is (nearly) the case: they are instances
of type (rather then datatype, as in your PEP).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Travis E. Oliphant schrieb:
> But, there are distinct disadvantages to this approach compared to what
> I'm trying to allow. Martin claims that the ctypes approach is
> *basically* equivalent but this is just not true.
I may claim that, but primarily, my goal was to demons
as the one in the
PEP. Which of these is "better" for what the PEP wants to achieve,
I can't say, because I still don't quite understand what the PEP
wants to achieve.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python
tastrophic (i.e. interpreter
crashes).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
nt data
> internally.
Ok. I understood you differently earlier.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
pulation (and why would I use NumPy for it if I could just
write a for loop that does that in pure Python, given PIL's
getpixel/setdata)?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
when the URI contains
unreserved characters?
- Should this library support RFC 3987 also?
- Why does the code still name things "URL"? The RFC
avoids this name throughout (except for explaining
that the fact that the URI is a locator is really
irrelevant)
Regards,
Martin
__
With the PEP, you can get access to the 'r' field from C code.
Performing this access is quite tedious; as I'm uncertain whether you
actually wanted to see C code, I refrain from trying to formulate it.
Regards,
Martin
___
gued
> that case effectively.
I think there are two ways in which one option could be "better" than
the other: it might be more expressive, and it might be easier to use.
For the second aspect (ease of use), there are two subways: it might
be easier
guess not, because apparently, it is a dictionary, not
a datatype object.
> But, I still don't see how that is relevant to the question of how to
> represent the data-format to share that information across two extensions.
Well, if NumPy gets the data from a different module,
It is actually vice versa:
IEEE-754 4-byte and 8-byte is not supported in ctypes.
Same for Unicode: the platform's wchar_t is supported (as you said),
but not a platform-independent (say) 4-byte little-endian.
Regards,
Martin
___
Python-Dev mailing lis
y for code already written) would be to
> just convert the data-format specification into it's own internal
> representation.
Ok, so your assumption is that consumers already have their own
machinery, in which case ease-of-use would be the question how
difficult it is to convert datatype objects
nfo?
Also, how does the memory management work for the results?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
se interface for primitive types?
Notice that those type codes imply sizes, namely the platform sizes
(where "platform" always means "what the C compiler does"). So if
you want to have platform-independent codes as well, you shouldn't
use the T_ codes.
Regards,
Marti
specified, by an IETF RFC. If somebody finds that non-intuitive,
that's likely because their mental model of relative URIs
deviate's from the RFC's model.
Of course, there is also the chance that the implementation
deviates from the RFC; that would be a bug.
Regards,
Martin
__
aving to concatenate into one big
> string, but python's re module would not take a multi-segment buffer.
If you are curious, try adding such a feature to re some time. I
expect that implementing it would be quite involved. I wonder what
Fredrik Lundh thinks about p
eapq module?
Anyway, the immediate author of this code is Dan Stutzbach (as
Raymond Hettinger's checkin message says); you probably should
contact him to find out whether the project is still alive.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev
ionaries shared between interpreters. How would you deal with these?
Also, the current thread state is a global variable, currently
(_PyThreadState_Current). How would you provide access to the current
thread state if there are multiple simultaneous threads?
Regards,
Martin
_
instead.
However, I find the proposed behaviour reasonable: Python already
automatically imports the .pyc file if .py is not given and vice
versa. So why not look for .pyo if the .pyc file is not present?
What do you think?
Regards,
Martin
___
Python-Dev
ve.
So I guess that zipimport should stop importing .pyo files if
OptimizeFlag is false, then?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
as an independent library, and be listed in the Cheeseshop for a
few years. If then there's wide interest in including it into Python,
it should be reconsidered. At that point, the then-authors of the
package will have to sign a contributor form.
Regards,
Martin
aps be
> faster to read the contents of all the directories
> along sys.path into memory and then go searching
> through that?
That should never be better: the system will cache the directory
blocks, also, and it will do a better job than Python will.
Regards,
Martin
__
../../../.."
O = ""
2. A (does not apply)
B (does not apply)
C (does not apply)
D (does not apply)
E O="/a" I="/b/../../../.."
2. E O="/a/b" I="/../../../.."
2. C O="/a" I="/../../..
.
That works both ways, of course: whoever implements such a patch should
also provide profiling information.
Last time I changed the importing code to reduce the number of stat
calls, I could hardly demonstrate a speedup.
Regards,
Martin
___
Python-Dev maili
t; on that specific topic.
Thanks. It always helps to be more specific; being less specific often
hurts. I find there is a difference between "urllib behaves
non-intuitively" and "urllib gives result A for parameters B and C,
but should give result D instead". Can you please add speci
y block structure; not sure whether
it uses linear search still.
For a small directory, the difference is likely negligible. For
a large directory, the cost of reading in the entire directory
might be higher than the savings gained from not having to
search it. Also, if we do our own dire
ndex.php?func=detail&aid=1462525&group_id=5470&atid=305470
> which I didn't find in my earlier searching.
So do you think this patch meets your requirements?
This topic (URL parsing) is not only inherently difficult to
implement, it is just as tedious to review. Without anybody
lems in the long run. OTOH, if the 4Suite
people would contribute the library, integrating it would be an option.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
s quo - it's just that you need a
well-designed specification before you start, a serious,
all-singing-all-dancing implementation, and a lot of test cases.
I believe it is these constraints which have prevented any progress
here.
Regards,
Martin
outcome, if urljoin is meant
to implement section 5 of that RFC.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
er?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
implementation
(and not only IDEs).
It still might be worthwhile to make such a change,
but I'd like to see practical advantages demonstrated
first.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Herman Geza schrieb:
> Here python reads from an already-freed memory area, right?
It looks like it, yes. Of course, it could be a flaw in valgrind, too.
To find out, one would have to understand what the memory block is,
and what part of PyObject_Free accesses it.
Regards,
Mar
being 256kiB, and 4Gi arena indices being available).
> I also ran this on x86. There were 32 errors and all of their
> addresses were 0x4...010.
That's because we round down to the beginning of the page.
Regards,
Martin
___
Python-Dev
EGVs from that part of the code.
> Note that Misc/valgrind-python.supp contains suppressions "Invalid read"'s
> at Py_ADDRESS_IN_RANGE.
Right. This is to tell valgrind that these reads are known to work
as designed.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
n't think so. The files differed only in the version: field, and
remainderNear.decTest is the same as the Python trunk, so I removed
remaindernear.decTest as bogus.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
ither doesn't have virtual memory, or, if it does, whether obmalloc's
guess of the page size is either right or an underestimation.
If some constraints fail, you can't use obmalloc (you could still
port Python, to not use obmalloc).
Notice that on a system with limited memory, you pro
ly fail.
How can the interpreter determine which of these it
is?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rg/dev/buildbot/community/all/x86%20Ubuntu%20Edgy%20trunk/builds/145/step-test/0
So either the compiler or some library has been updated in a strange
way, or there is a hardware problem. One would need access to the
machine to find out (and analyzing it is likely time-consuming).
Regards,
Greg Ewing schrieb:
> Martin v. Löwis wrote:
>
>> a) the directory cache is out of date, and you should
>>re-read the directory
>> b) the module still isn't there, but is available in
>>a later directory on sys.path (which hasn't yet
>>bee
Patch #841454 takes a stab at cross-compilation
(for MingW32 on a Linux system, in this case),
and proposes to use SCons instead of setup.py
to compile extension modules. Usage of SCons
would be restricted to cross-compilation (for
the moment).
What do you think?
Regards,
Martin
atch being contributed uses SCons. If people
think this is unmaintainable, this is a reason to reject the
patch.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
ot; is one that
might be available to many people), and try to make it work.
I believe it wouldn't work out of the box because distutils issues
the wrong commands with the wrong command line options. But I don't
know for sure; I haven&#
sf/841454
was contributed by Andreas Ames. I performed triage on it (as it is
about to reach its 3rd anniversary), and view SCons usage as the biggest
obstacle.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
t.
In particular, to run SCons, they need a host python. The just-built
python is unsuitable, as it only runs on the target.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
error. My version of the patch uses the index API, this
will automatically give an error.
Two questions:
a) should floats be supported as parameters to file.seek
b) if not, should Python 2.6 just deprecate such usage,
or outright reject it?
Regards,
Martin
rary.
b) no code to provide such functionality has been contributed.
Normally, b) would be the bigger issue. In this case, I think
there might also be resistance to including a large database
(as usual when inclusion of some database is proposed).
Regards,
Martin
__
o about this: it's already
mentioned in "Porting to 2.5" of whatsnew25. It would be good
if people were aware of this issue (and the other changes to
the C API); thus I hope that this message/thread makes it to
the python-dev summary :-)
Regards,
Martin
___
etter
chance to estimate since they learn about
short reads.
What do you think?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
Nick Coghlan schrieb:
> Martin v. Löwis wrote:
>> I personally consider it "good style" to rely on implementation details
>> of CPython;
>
> Is there a 'do not' missing somewhere in there?
No - I really mean it. I can find nothing wrong with people rel
e
_POWER for backwards-compatibility (back to RS/6000 times).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ed because people keep requesting the feature, and not
accepted because it's not implementable in general (i.e. it is difficult
to implement on platforms where the double type is not IEEE-754).
Regards,
Martin
___
Python-Dev mailing list
ns in Python.
I wrote to Ian that I would be interested; participating in the meeting
in Berlin is quite convenient. I can try to keep python-dev updated.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
art reading source
code.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
LSB would
only specify what a confirming distribution should do, not what
confirming applications need to do. But we will see.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
executed directly by users or shell scripts.
In any case, changing Python is certainly out of the scope of
the LSB committee: they might put requirements on Python installations,
but it's not their job to "fix" Python.
Regards,
Martin
___
such a statement if they
are not accompanied with concrete proposals what specifically to
change. It also gets me upset because it suggests that all prior
contributors weren't serious.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
gives you something working, no matter where
httplib.py comes from (or whether it comes from httplib.py at all).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rches vendor-package.
> (-S would almost do it but probably suppresses too much.)
Patch #1298835 implements such a vendor-packages directory. I have
reopened the patch to reconsider it. I take your message as a +1
for that feature.
Regards,
Martin
___
with informative error
> messages becomes much more viable.
Again: none of the vendors modifies Python in a way that what
you get is "not a standard Python runtime". They *all*
are "standard Python runtimes".
Regards,
Martin
_
I don't think the current packaging tools can solve this newbie
problem. It might be solvable if installation of X11 libraries
would imply installation of Tcl, Tk, and Tkinter: people running
X (i.e. most desktop users) would see Tkinter installed, yet
it would be p
s.html
Depending on what precisely "this" is you want to use it for,
there are other lists as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
d deletion is attempted.
Even if the deletion was added to the iterator protocol
(which would require a PEP, IMO), I don't think the
syntax should be changed. If you want access to the
iterator in the loop, you should explicitly assign it
to a variable befo
quot;true" slices (e.g. m[1:5])
- how should you deal with negative indices?
- should len(m) be supported?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
want
to index, just as the .group() method indexes groups.
The typical equivalences should hold, of course, e.g.
m[1:5][1] == m[2] etc.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
> - how should you deal with negative indices?
>> - should len(m) be supported?
>
> what about m['named_group_1'] etc?
That should also be taken into consideration; I suggest to support it.
Regards,
Martin
___
Python-Dev mailing list
cal patch.
I disagree. So far, nobody has spoken against the proposed feature. It's
really a small addition of a new method to an existing type. Entire
classes have been added to the standard library without a PEP. People
can still criticize the patch when its posted (and it's not
ader files, and you may need header files for the libraries
your package depends on.
So if you use distutils to install a package, it's IMO reasonable to
require that the -dev package is installed.
People use distutils for other purposes today as well, and these
purposes might be supported now
oup() method indexes groups.
>
> so what should len(m) do?
That's a question: should len be supported at all? If so, it's clear
that len(m) == len(m[:]).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
27;
>> py> m.group(1)
>> 'b'
>
> 0 isn't a group, it's an alias for the full match.
So what is the proper term for the things that the .group() method
returns? According to
http://docs.python.org/lib/match-objects.html
it return
pecial cases, but in this case the rules
> were apparently broken with impunity.
Well, the proposal was to interpret m[i] as m.group(i), for all values
of i. I can't see anything confusing with that.
Regards,
Martin
___
Python-Dev mailin
Fredrik Lundh schrieb:
> it can quickly become rather confusing if you also interpret m[:] as
> m.groups(), not to mention if you add len() and arbitrary slicing to
> the mix. what about m[] and m[i,j,k], btw?
I take it that you are objecting to that feature, then?
Regard
hat, but the
> worst case there is far more behaved, a temp trade of space vs
> runtime.
Also true.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
x27;s difficult to fix: deleting an item may cause a resizing/rehashing
of the entire dictionary, hence the dictionary is looked while being
iterated over. I *think* that one could support deletion (but not
addition); this would need further investigation.
Regards,
Martin
__
Hasan Diwan schrieb:
> The attached patch ensures that the $(DESTDIR) exists before
> installing the built binaries. It has been tested on Mac OS X. The
> patch is attached.
Please post patches to sf.net/projects/python
Thanks,
Martin
___
P
gards,
Martin
[1] http://www.freestandards.org/en/LSB_face-to-face_(December_2006)
[2]http://www.freestandards.org/images/6/66/Lsb-f2f-200612-python.pdf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
technically possible; somebody would have to implement it.
What do you think?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
ly)
will not be included in the next RHEL release (which apparently
is coming soon).
So it looks like LSB will standardize on Python 2.4 (which will also
be the default version in the next Debian release).
Regards,
Martin
___
Python-Dev mailing list
Python
truct becomes an
incomplete type).
All in all, I think providing binary compatibility would
be feasible, and should be attempted. What do you think?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
only distribution of their
code necessary for protection.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
m across
>> distributions
>
> Was this duplication of last two points cut'n'paste error or what?
Oops, yes, it should have read
- Optional: Allow installation of binary foreign Python add-on
packages
Thanks,
Martin
___
P
ovide that for
dict iterators. It wouldn't be necessary to support any other updates;
it wouldn't even be necessary to support del d[k], even if k is
the key returned from the iterator's .next().
Regards,
Martin
___
Python-Dev mailing list
Pytho
urity patches *only*)
would be a good thing - independent of the LSB, actually.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
ing to provide the old definition (*) - but for API
evolution, that wouldn't work, of course.
It would mean that extension writers need the old header files
to build extensions. The LSB people would be fine with that -
they provide a complete set of header files to build LSB-compatible
binar
sion that
only has security bugfixes.
I believe this guarantee works in two ways: we should guarantee
that we will accept security bugfixes, but we should also guarantee
that we *only* accept security bugfixes (and perhaps critical
crashers - although they overlap i
d, that would put Python into a unique position in that
field (perhaps along with Perl, which is also targetted for
LSB 3.2 - this wasn't discussed yesterday, basically because
nobody from the Perl community was present).
Regards,
Martin
___
Python-Dev
2201 - 2300 of 5755 matches
Mail list logo
