> I hope this saves someone else a bit of time. :)
Please submit the parts that you consider of general use
to the bug tracker, so we can include it in future releases.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
h
ailable) what the
rationale for this partial change was.
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
> Is that documentation maintained in some way?
I don't think so. It isn't in the pydotorg repository, and the
files were last touched in 2005.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
espond, or indicated that they can't bring the slaves up anytime
soon.
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
question is then whether we would drop svnmerge, in favour of
the 1.5 merge tracking. IIUC, that would require all committers to
use 1.5 - I'm not sure whether this poses a challenge to any committer.
Regards,
Martin
___
Python-Dev mailing list
Pytho
rise - some programs
are not suitable for automated operation at all, because they bring
up windows, and communicate with their environment by means other than
stdin and stdout (or, if you want to operate them automatically, you
have to use AppleScrip
ompact).
On unpickling, support the new code to intern the result strings;
subsequent references to it will go to the standard backreferencing
algorithm.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
e processor will trap on misaligned accesses, but
the operating system might silently fix the access.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
s that appear as dictionary keys. Whether this is good enough,
I don't know. In particular, it might intern very large strings that
aren't identifiers at all.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
the
> expected benefit though, so perhaps just a size test would be better.
Ok. So, Jake, it's back to my original request - please submit this
to the tracker (preferably along with test cases).
Regards,
Martin
___
Python-Dev mailing l
asing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
> I may have misunderstood how unpickling works
Perhaps I have misunderstood your patch. Posting it to Rietveld might
also be useful.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
eptable policy, then those changes would fall under
the policy. If the policy is *not* acceptable, a lot of changes to
3.0.1 need to be rolled back (e.g. the ongoing removal of __cmp__
fragments)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev
e paint.
I would fear that than 3.1 gets the same fate as 3.0. In May, we will
all think "what piece of junk was that 3.1 release, let's put it to
history", and replace it with 3.2. By then, users will wonder if there
is ever a 3.x release th
> The IO-in-C branch cannot be reasonably pulled in release30-maint, but it will
> be ready for 3.1.
Even if 3.1 is released in February?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
> PS Can anyone comment on why Python defaults to utf-8 on Windows?
Don't panic. It doesn't, and you are misinterpreting what you are
seeing.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
all platforms, just
as it was "ascii" in 2.x, on all platforms. The default encoding isn't
used for I/O; check f.encoding to find out what encoding is used to
read the file you are reading.
Regards,
Martin
___
Python-Dev ma
", line 19, in encode
> return codecs.charmap_encode(input,self.errors,encoding_map)[0]
> UnicodeEncodeError: 'charmap' codec can't encode character '\u0153' in
> position 1: character maps to
Looks right to me.
Martin
___
sed. Network IO is
always binary.
- for file names, yet different algorithms apply. On Windows, it
uses the Unicode API, so no need for an encoding. On Unix, it
(again) uses the locale encoding. On OSX, it uses UTF-8
(just to be clear: this applies to the first argume
Paul Moore wrote:
> 2009/1/28 "Martin v. Löwis" :
>>>>>> print(open("a1").read())
>>> Traceback (most recent call last):
>>> File "", line 1, in
>>> File "D:\Apps\Python30\lib\io.py", line 1491, in write
> This a very helpful explanation. Is it in the docs somewhere, or if it
> isn't, could it be?
I actually don't know.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
ersion that newbies should be using.
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
on a 3.1
> release in 6 months.
+1
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
uldn't break the Python build, and,
preferably, the build process should suggest the user what might
have happened when it failed.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
up, svn commit - and clearly, you shouldn't do that. If, on commit,
you get a conflict, you should revert all your changes, svn up, and
start all over with the merge.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
, which was an
addition, not a removal.
> I think that the important question is "can the 3.0.x series be made
> 'viable' in less than the time frame for 3.1?" If not, I really have
> to think it's DOA from the point of view of folks who consider 3.0.0
> non-viab
Brett Cannon wrote:
> On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" wrote:
>>> There are potential problems with doing it that way [1]. The safer
>>> option is to do:
>>>
>>> svn revert .
>>> svnmerge merge -M -F
>> I still
> svn up
> svnmerge
> ... conflicts
> svn revert -R .
> svn up
> svnmerge
> ... same conflicts
Ah. In the 3.0 branch, always do "svn revert ." after svnmerge.
It's ok (Nick says it isn't exactly ok, but I don't understand why)
Martin
> 1. Barry, who is the release manager for 3.0.1, does not like the idea
> of the cruft that is being proposed removed from 3.0.1.
I don't think he actually said that (in fact, I think he said the
opposite). It would be good if he clarified, though.
Rega
> Just so I'm clear. Are you thinking that 3.0.x will never have
> fast shelves
As Guido said, shelves are *already* fast in 3.0, if you are
using the right operating system.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
;d be happy to
> adopt one of them (since they *are* faster than my current approach).
> But until someone pokes a hole in my logic, I'll stick with the
> slower-but-always-correct methodology (and continue advocating that
> approach to everyone else doing updates that affect all fou
p) are fairly
> hard to clean up, so I prefer the safe approach (despite the extra
> minute or two it takes for svnmerge to recalculate the metadata changes).
If I find that it conflicts on commit, I rather restart all over.
Regards,
Martin
__
t see many packages until 3.0.1 is released.
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
he
> metadata changes unless svnmerge is told to modify the properties again
> after they have been reverted. Or am I misunderstanding SVN, and the
> revert command doesn't actually revert property changes?
Oops, I meant "svn resolved ." all the time.
> Can you point me at specifics (bug reports or test cases)? I could see
> if I can help in fixing things.
See r69098.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
I have now upgraded subversion to 1.5.1 on svn.python.org.
Please let me know if you encounter problems.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
> How about Friday February 13?
Fine with me (although next Friday (Feb 6) would work slightly better)
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
> on your brand-new bright yellow Hummer H3. Or not.
Well, there is also PY_SSIZE_T_CLEAN. I asked before 3.0, and was told
that it was too late to remove it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
> Are all modules PY_SSIZE_T_CLEAN? Last I looked, _ssl.c still used int or long
> in various places instead of Py_ssize_t.
That's probably still the case.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
> any ideas?
Assuming you reported this right after it happened - sorry, no.
I can't find anything relevant in the log files (although a
precise time of failure would have helped).
Does a plain "ssh python...@svn.python.org" still work?
What path did you try to check into
er.
> Weird. regardless, this is presumably not related to your subversion
> upgrade. I don't think I've done any commits from these hosts since I
> got IPv6 connectivity, only updates.
That alone can't be the problem. I tried to commit something over IPv6,
and i
rnel: IPv6: sending pkt_too_big to self
Jan 31 23:55:36 dinsdale kernel: IPv6: sending pkt_too_big to self
Feb 1 00:02:57 dinsdale kernel: IPv6: sending pkt_too_big to self
Of course, it is five minutes off your connect attempt (IIUC), so
it also might be irrelevan
bility mode); if you think you then need to truncate to 32 bits,
there should be explicit code that tests for truncation and raises a
Python exception if appropriate.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
Mark Dickinson wrote:
> On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote:
>
>> tp_reserved sounds fine. In 3.0.1, filling it with a function pointer
>> should give no error, since that would be a binary-incompatible change.
>
> I'm not sure I under
>> Fine with me (although next Friday (Feb 6) would work slightly better)
>
> Feb 6 won't work for me. Would the 20th be better for you Martin?
No, they are both busy days - Feb 13 is then slightly better than Feb
20. I have about an hour in the morning (around 8:00 UTC), and
ymore. So
Campbell's surprise would be gone - he wouldn't have been able to still
invoke tp_compare through the cmp() builtin.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
ld arrange to exempt them, by
introducing a "Core" type flag, to be included in the default type
flags when the core is compiled (and not even declared otherwise).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
memory models (66%) have same-sized data and
function pointers, only few of them (33%) have them
differently-sized.
In any case, I don't think Python supports 8086 segmented mode
in any reasonable way today.
Regards,
Martin
___
Python-Dev maili
ess it is no arguments that you want to pass).
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
> How are we going to handle str subclasses and unicode?
"Are we going to"? You mean, the current code is not good enough? Why not?
> Should we allow
> all subclasses of basestring? Or just str and unicode? Or str only?
In 2.x, str only, in 3.x, unicode onl
to be seen;
I would expect some opposition if a PEP was written.
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/
nges in 3.2, see
http://docs.python.org/3.2/whatsnew/3.2.html
To download Python 3.2 visit:
http://www.python.org/download/releases/3.2/
Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:
http://bugs.python.org/
Enjoy!
--
Martin v. Löwis
(
ly extremely common to have strings that are mostly-ASCII but
not completely ASCII? I would agree that pure ASCII strings are
extremely common.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Am 23.08.2011 11:46, schrieb Xavier Morel:
> On 2011-08-23, at 10:55 , Martin v. Löwis wrote:
>>> - “The UTF-8 decoding fast path for ASCII only characters was removed
>>> and replaced with a memcpy if the entire string is ASCII.”
>>> The fast path would still be u
e for yourself.
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
ity
reasons, unless significant improvements can be demonstrated. Torsten
had a version that used macros for that, and it was a pain to debug.
So we put correctness and readability first.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
pointer except through the macros, so it may not matter that much.
OTOH, it's certainly not too late to change it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
or the different 3.3 representations,
plus one for 3.2 and 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
need nor a means to consider these.
> e) 16-bit codepoints
These are in PEP 393.
> f) UTF-16 with clever indexing/caching to be efficient
Again, -1.
> g) 32-bit codepoints
This is in PEP 393.
> h) UTF-32
What's that, as opposed to g)?
I'm not open to revise PE
returns no error hand
> maxchar=127: memcpy() is used. You mean that memcpy() is too slow? :-)
No: the pure-ASCII case is already optimized with memcpy. It's the
mostly-ASCII case that is not optimized anymore in this PEP 393
implementation (the one with "ASCII runs" instead of &qu
ith all cases defined, 0 a
>>> first item
>>> and contiguous values. We may need an enum.
>>
>> During the Summer of Code, Martin and I did a experiment with GCC and
>> it did not seem to produce a jump table as an optimization for three
>> cases but gener
c. would be free to do things differently
(and I understand that there are plans to do PEP-393 style Unicode
objects in PyPy).
> Martin has long claimed that the fact that I/O is done in terms of
> UTF-16 means that the internal representation is UTF-16, so I could be
> wrong. But when
t;UTF-16 aware" (in some places, but not in
others).
With Python's I/O architecture, it is of course not *actually* the I/O
which considers UTF-16, but the codec.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
h
e PEP.
- issues to be considered (unclarities, bugs, limitations, ...)
- conditions you would like to pose on the implementation before
acceptance. I'll see which of these can be resolved, and list
the ones that remain open.
Regards,
Martin
__
ch memory usage halves on Windows.
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
thon could certainly improve, e.g. by caching whether
a string had been determined to be in normal form, so that applications
can more reasonably apply normalization to all strings they ever
want to compare.
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
a
process that treats s1 and s2 differently shall not assume that others
will do the same, i.e. that it is ok to treat them the same even though
they have different code points. Treating them differently is also
conforming.
Regards,
Martin
___
Python-Dev mail
code them (notice that surrogateescape is an error
handler, not a codec).
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-d
would like to pose on the implementation before
>> acceptance. I'll see which of these can be resolved, and list
>> the ones that remain open.
>
> That it doesn't significantly slow down benchmarks such as stringbench
> and iobench.
Can you please quanti
Am 25.08.2011 11:39, schrieb Stephen J. Turnbull:
> "Martin v. Löwis" writes:
>
> > No, that's explicitly *not* what C6 says. Instead, it says that a
> > process that treats s1 and s2 differently shall not assume that others
> > will do the same, i.e. th
ent if there was one. For BMP strings,
they conform fine, and it may well be that Jython eithers either don't
have non-BMP strings, or don't care whether len() or indexing of their
non-BMP strings is "correct".
Regards,
Martin
___
Pytho
in size; very short strings increase
on 16-bit-wchar_t systems and 64-bit systems. Short strings
keep there size, and long strings save.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
le. In contexts where it is not feasible (such
as reading a character, or reading the length or the kind), failing to
ready the string should cause a fatal error.
What do you think?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:
us, some are more "regex gurus" than others; you know
who you are. I guess the PSF would pay for the review, if that
is what it would take.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
> I'm not sure it's worth doing an extensive review of the code, a better
> approach might be to require extensive test coverage (and a review of
> tests).
I think it's worth. It's really bad if only one developer fully
understands the regex imp
f there is doubt whether they should be added, they shouldn't be added.
If they do get added, we have to live with it (until, say, Python 4,
where bad features can be removed again).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
o realistically, the module should be ported, which has the challenge
that matching needs to operate on three different representations. The
modules already support two representations (unsigned char and
Py_UNICODE), but probably switching on type, not on state.
Regards,
Martin
__
sort of
>> C libraries.
>
> A nice story, but Quicksort's worst case is O(n*n) too.
In addition, timsort is O(n log n), which also makes it a real good
O(n*n) sort :-)
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
articular file formats) are done in Python.
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
ither directly nor
indirectly (through liblzma). The approach of gzip.py (doing IO
and file formats in pure Python) is exactly right.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
until actual code is to review.
Not sure whether you already have this: supporting the tarfile module
would be nice.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
ibrary as a plausible reason.
> It's acceptable for the Python version to use ctypes
Hmm. To me, *that's* unacceptable. In the specific case, having a
pure-Python implementation would be acceptable to me, but I'm skeptical
that anybody is willing to produce one.
Regards,
Martin
Am 27.08.2011 12:10, schrieb Antoine Pitrou:
> On Sat, 27 Aug 2011 08:02:31 +0200
> "Martin v. Löwis" wrote:
>>> I'm not sure it's worth doing an extensive review of the code, a better
>>> approach might be to require extensive test coverage (and a re
use it (now or in the future), just don't."
> And if people do complain, what are python-dev's options?
That will depend on the complaint. If it's "I don't like the new
feature", then the obvious response is "don't use it, then".
Regards,
Martin
ctypes.
So does it work on Sparc/Solaris? On OpenBSD? On ARM-Linux? Does it
work if the xz library is installed into /opt/sfw/xz?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
> Why -can't- we expect the user to have liblzma headers installed?
> Couldn't it just be a dependency in the package management system?
Please give it up. You just won't convince that list that ctypes
is a viable approach for the standard libr
> I just want to talk about it - for now.
python-ideas is a better place to just talk than python-dev.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
Am 26.08.2011 16:56, schrieb Guido van Rossum:
> Also, please add the table (and the reasoning that led to it) to the PEP.
Done!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
at least some of the
> test_bigmem tests, according to your system's available RAM.
Running only StrTest with 4.5G allows me to run 2 tests
(test_encode_raw_unicode_escape and test_encode_utf7); this sees
a slowdown of 37% in Linux user time.
Regards,
Martin
__
the UTF-8 decoder because I see an even larger
> slowdown with simpler encodings (e.g. "-E latin1" or "-E utf-16le").
But those aren't used in iobench, are they?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.
change, I get 610 MB/s. The trunk gives me 488 MB/s, so this
is a 25% speedup for PEP 393.
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
Am 29.08.2011 11:03, schrieb Dirkjan Ochtman:
> On Sun, Aug 28, 2011 at 21:47, "Martin v. Löwis" wrote:
>> result strings. In PEP 393, a buffer must be scanned for the
>> highest code point, which means that each byte must be inspected
>> twice (a seco
obench uses Latin-1, including non-ASCII, but not
non-Latin-1.
> Or, better, different Unicode ranges in different tests?
That's why I asked for a list of benchmarks to perform. I cannot
run an infinite number of benchmarks prior to adoption of the PEP.
Regards,
Martin
_
tion;
this would be possible by rounding up each string size to the next
multiple of 8 (given that it's all allocated through the object
allocator).
It should be possible to squeeze a little bit out of the 190kB,
by finding objects for which the wchar_t or UTF-8 representations
are created u
ous whether your techniques help or hinder a potential
integration of a JIT generator.
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
ails to detect pure-ASCII strings.
See below for the actual diff. It should be obvious why the 393 version
is faster: 3.3 currently needs to widen each char (to 16 or 32 bits).
Regards,
Martin
@@ -5569,41 +5569,8 @@
Py_ssize_t size,
const char *error
.
> (is it with your own port of Django to py3k, or is there an official
> branch for it?)
It's https://bitbucket.org/loewis/django-3k
Regards,
Martin
3.3.0a0 (default:45b63a8a76c9, Aug 30 2011, 09:30:21)
[GCC 4.6.1]
Strings: 36070
Chars: 1306295
Bytes: 3694690
Other objects: 1085060
with
PEP-393, where I do believe that some of the changes that had been
made over the last year become redundant.
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
rk out the low-level layout of structs, or
> anything like that (as you often have to do when using ctypes).
I can understand how that works when building a CPython extension.
But what about creating Jython/IronPython modules with Cython?
At what point get the header files considered
was causing this - apparently, somebody was throwing odd queries at it.
Restarting Apache reduced the load. If they continue to do so, I
investigate further.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
4001 - 4100 of 5764 matches
Mail list logo
