Greg Ewing, 07.05.2011 02:26:
Stefan Behnel wrote:
After all, the described crash case indicates that the Document
destructor was called before all of the Element destructors had been
called, although all Elements reference their Document, but the Document
does not refer to any of the Elements
Eli Bendersky, 09.05.2011 14:56:
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
On the usage of 'x' in the *first* print. Recently, whi
[forwarded to the python-ideas list]
Stefan
___
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
Greg Ewing, 19.05.2011 00:02:
Georg Brandl wrote:
We do have
bytes.fromhex('deadbeef')
But again, there is a run-time overhead to this.
Well, yes, but it's negligible if you assign it to a suitable variable first.
Stefan
___
Python-Dev mailing
Xavier Morel, 19.05.2011 09:41:
On 2011-05-19, at 07:28 , Georg Brandl wrote:
On 19.05.2011 00:39, Greg Ewing wrote:
If someone sees that
some_var[3] == b'd'
is true, and that
some_var[3] == 100
is also true, they might expect to be able to do things
like
n = b'd' + 1
and get
Łukasz Langa, 19.05.2011 11:25:
Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37:
But why wouldn't "they" expect `b'de' + 1` to work as well in this case? If a
1-byte bytes is equivalent to an integer, why not an arbitrary one as well?
Hi,
since May 19, I get the exception below in the latest py3k site.py when
trying to run a distutils build with it (building Cython). The changelog
since the previous (working) CPython build is here:
https://sage.math.washington.edu:8091/hudson/job/py3k-hg/374/
The failing build is here:
h
Maciej Fijalkowski, 24.05.2011 13:31:
CPython was not designed for CPU cache usage as far as I'm aware.
That's a pretty bold statement to make on this list. Even if it wasn't
originally "designed" for (efficient?) CPU cache usage, it's certainly been
around for long enough to have received nu
Antoine Pitrou, 24.05.2011 14:32:
On Tue, 24 May 2011 14:05:26 +0200Stefan Behnel wrote:
I doubt that efficient CPU cache usage was a major design goal of PyPy
right from the start. IMHO, the project has changed its objectives way too
many times to claim something like that, especially at the l
Tom Whittock, 27.06.2011 12:48:
I'm writing a module to proxy C++ objects into Python for a large C++
application. There are hundreds of thousands of C++ objects, some of
which are temporary while others are very long lived.
Currently every time one of these objects is accessed from Python, a
ne
Victor Stinner, 28.06.2011 15:43:
In Python 2, open() opens the file in binary mode (e.g. file.readline()
returns a byte string). codecs.open() opens the file in binary mode by
default, you have to specify an encoding name to open it in text mode.
In Python 3, open() opens the file in text mode
Georg Brandl, 06.07.2011 07:35:
Well, it was stated that even non-joking use of such words can offend
(the example given was "your argument is blind to (these facts)").
I consider use in jokes to be more serious, since it's careless use.
Sorry if I overreacted here.
There's a common saying that
Georg Brandl, 06.07.2011 09:08:
Am 06.07.2011 08:51, schrieb Stefan Behnel:
Georg Brandl, 06.07.2011 07:35:
Well, it was stated that even non-joking use of such words can offend
(the example given was "your argument is blind to (these facts)").
I consider use in jokes to be more seri
Brett Cannon, 28.07.2011 23:49:
On Thu, Jul 28, 2011 at 11:25, Matt wrote:
- What policies are in place for keeping parity with other HTML
parsers (such as those in web browsers)?
There aren't any beyond "it would be nice".
[...]
It's more of an issue of someone caring enough to do the coding
Joao S. O. Bueno, 29.07.2011 13:22:
On Fri, Jul 29, 2011 at 1:37 AM, Stefan Behnel wrote:
Brett Cannon, 28.07.2011 23:49:
On Thu, Jul 28, 2011 at 11:25, Matt wrote:
- What policies are in place for keeping parity with other HTML
parsers (such as those in web browsers)?
There aren'
Hi all,
I would like to know how stable the C-API of Python 3 is, or what the expected
release level (beta?) would be at which I can expect it to stabilise. What is
the plan here?
The background is Cython, which will need to support Python 3 one day or
another, so I wanted to know from which poin
Christian Heimes wrote:
> Stefan Behnel wrote:
>> I would like to know how stable the C-API of Python 3 is, or what the
>> expected
>> release level (beta?) would be at which I can expect it to stabilise. What is
>> the plan here?
The release schedule in PEP 3000 says
Barry Warsaw wrote:
> On behalf of the Python development team and the Python community, I'm
> happy to announce the first alpha release of Python 2.6, and the third
> alpha release of Python 3.0.
Cool! :)
But how comes the release notes for Python 3a3 on the download site are the
same as for 3a2
(weird places these threads come up at, but now that it's here...)
Mike Meyer wrote:
> On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>,
>> Mike Meyer <[EMAIL PROTECTED]> wrote:
>>> On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed
>>>
Mike Meyer wrote:
> On Wed, 05 Mar 2008 13:01:14 +1300 Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>> Mike Meyer wrote:
>>> Trying to install it from the repository is a PITA, because
>>> it uses both the easyinstall and Pyrex
>> It shouldn't depend on Pyrex as long as it's distributed
>> with the gen
Martin v. Löwis wrote:
>> I think the best lesson here is Tcl. Because it uses stubs mechanism,
>> you don't need to depend on tclXX.dll, you don't deal with really
>> direct implementation details, you don't care about runtimes,
>> everything is much easier. Maybe it's possible (and not too late)
Mike Meyer wrote:
> On Tue, 11 Mar 2008 14:55:04 +0100 Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> (weird places these threads come up at, but now that it's here...)
>> Mike Meyer wrote:
>>> On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]>
Guido van Rossum wrote:
> It should be able to download a Python-only module or package and
> install it into site-packages (or perhaps elsewhere if so directed via
> another optional command line flag). It should support zip, tar and
> tar.gz/tgz files (and perhaps tar.bz2). It should simply unpac
Neal Norwitz wrote:
> Iteration with the dict methods (e.g., keys -> iterkeys()),
> map/zip/filter returning iterator rather than list.
That's only an optimisation, it's not functionally required. A list behaves
like an iterator in most use cases, so it's rather unlikely that Py3 code will
break i
Neal Norwitz wrote:
> I haven't seen any action on 3to2 (although I'm very behind on email).
> Stefan, could you try to implement some of these and report back how
> it works?
No, sorry, that's too low a priority for me currently.
Stefan
___
Python-De
Guido van Rossum wrote:
> What I'm announcing now is the next best thing: an code review tool
> for use with Subversion, inspired by Mondrian and (soon to be)
> released as open source. Some of the code is even directly derived
> from Mondrian. Most of the code is new though, written using Django
>
Hi,
Guido van Rossum wrote:
> On Sat, May 3, 2008 at 11:46 AM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> and IF someone adapts it to work on a different
>> platform (Django with regular DB backend) and then hosts it elsewhere.
>
> No, that won't be necessary. If someone contributes an alternate
Guido van Rossum wrote:
> On Thu, May 1, 2008 at 4:37 PM, Neal Becker <[EMAIL PROTECTED]> wrote:
>> It would be really nice to see support for some other backends, such as Hg
>> or bzr (which are both written in python), in addition to svn.
>
> Once it's open source feel free to add those!
trac
Guido van Rossum wrote:
> On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Personally, I would consider the following sufficient:
>>
>> 1) people who have authenticated themselves against the underlying VCS (i.e.
>> project memb
Isaac Morland wrote:
> On Thu, 22 May 2008, Christian Heimes wrote:
>
>> The buffer interface was designed for the slice-as-copy use case:
>>
> a = "abcdefg"
> b = buffer(a, 2, 3)
> b
>>
> str(b)
>> 'cde'
> []
>
> This answers my musing about shared slices. But it points me
Hi,
Christian Heimes wrote:
> Stefan Behnel wrote:
>> Even worse, it's gone in Py3:
>
> No, it has been replaced by a better system.
>
> Try "memoryview"
I know. We are already discussing the buffer protocol on the Cython list.
http://comments.gmane.org
Gregory P. Smith wrote:
> Of particular interest to bsddb is the pep3118 buffer API. I updated
> the existing bsddb module found in the py3k branch to use it last
> fall; you may want to use the changes made to it as an example.
>
> I agree, a single C code base is the only sane way forward for b
Hi,
Guido van Rossum wrote:
> On Tue, May 27, 2008 at 9:47 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Could this function get a public interface? I do not think Cython is the only
>> case where C code wants to modify a type after its creation, and copying the
>>
Stefan Behnel wrote:
> Straight forward patch is attached (against 3.0a5).
[...]
> BTW, I noticed that the code in typeobject.c uses "DECREF before set" two
> times.
Filed on the bug tracker as issues 2989 and 2990.
http://bugs.python.org/issue2989
http://bugs.python.or
Antoine Pitrou wrote:
> Stefan Behnel behnel.de> writes:
>> BTW, I noticed that the code in typeobject.c uses "DECREF before set" two
>> times, like this:
>>
>> method_cache[h].version = type->tp_version_tag;
>>
Christian Heimes wrote:
> Stefan Behnel schrieb:
>> Christian Heimes wrote:
>>> * add a new file stringobject.h which contains the aliases PyString_ ->
>>> PyBytes_
>> Just a quick note that that file is still missing from SVN, so it's kind of
>> ha
Nick Coghlan wrote:
> Stefan Behnel wrote:
>> Besides, how likely is it that users set a breakpoint on the
>> PyBytes/PyString functions?
>
> Not very likely at all - but it would still be nice if the PyBytes_*
> symbols were visible to the linker as well as the prepro
Hi Guido,
glad to hear you're recovering.
Guido van Rossum wrote:
> anything someone really needs me to look at ASAP (e.g. a BDFL decision
> affecting the impending beta release) please send me an email
This seems to require a BDFL decision:
http://bugs.python.org/issue2997
Executive Summary:
Armin Ronacher wrote:
> - in XML/HTML processing it's often desired to keep the attributes of
> an tag ordered during processing. So that input ordering is the
> same as the output ordering.
>
> - [...]
> XML libraries such as etree could add support for it when creating
> ele
Hi,
I get a crash in one of lxml's doctests in 3.0b2, and it looks like it's
coming from plain Python code (as opposed to Cython code). Just a quick check
before I start digging into this, has anyone seen this before?
Stefan
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching t
Greg Ewing wrote:
> [EMAIL PROTECTED] wrote:
>
>> Is there any reason this should be a separate project rather than just
>> be rolled in to the core?
>
> Always keep in mind that one of the important characteristics
> of CPython is that its implementation is very straightforward
> and easy to fol
Greg Ewing wrote:
> A.M. Kuchling wrote:
>
>> A stray thought: does using a generator for the VM make life easier
>> for the Stackless Python developers in any way? Does it make it
>> possible for stock CPython to become stackless?
>
> I doubt it. A major barrier to stacklessness is that
> a lot
Michael Foord wrote:
> Moving more C extensions to an implementation based on ctypes would be
> enormously useful for PyPy, IronPython and Jython, but ctypes is not yet
> as portable as Python itself which could be an issue (although one worth
> resolving).
In the same line, moving more extensions
Gerhard Häring wrote:
> Cython is still being worked on (intensively, it seems). Bundling it
> with Python means deciding on a particular version probably for an
> entire major release lifecycle (use Cython x.y.{newest} for Python 2.7,
> for example).
Yes, that is definitely an issue. Cython is he
[EMAIL PROTECTED] wrote:
> >>> - Option 2: only distribute generated source files
> >>> -- developers still need to have Cython installed
> >>> -- you have to trust Cython; who will really review the generated
> code?
> >>
> >> Who reviews the machine code from gcc?
>
> G
Terry Reedy wrote:
> Stefan Behnel wrote:
>> I think the main advantage for stdlib modules is actually the maintenance
>> cost. Having a single, easy-to-read code base for extension modules that
>> compiles without modification in Py2.6/7 and Py3.0/3.1 (and 2.3, 2.4 and
>
Terry Reedy wrote:
> Stefan Behnel wrote:
>> One really neat feature is that you can put a .pxd file next to your .py
>> file and let it override the function signatures and classes. So you do
>> not even need Py3 annotations, which have the obvious disadvantage of
>>
Steven D'Aprano wrote:
> On Sat, 15 Nov 2008 01:27:54 am Daniel Furrer wrote:
> [snip]
>> We're looking for:
>> - Hints as to which python compiler would be best to work on. (The
>> official Python compiler package seems very nice to work with
>> actually...) - If there are any requests in the area
Daniel Furrer wrote:
> As part of an advanced compiler design course at our university (ETH
> Zurich), we have to implement an optimization (or various thereof).
> I've spoken with a couple of people who are, like me, very fascinated by
> Python.
> So I would just like to ask if somebody has any id
Hi,
replying to the topic only: because many C libraries support threading and
Python extension modules can integrate them in a way that allows
concurrency in a safe way (although 'safe' is definitely something that is
paid for in developer days).
Stefan
_
Марк Коренберг, 09.08.2011 11:31:
In a summary: Please say clearly why, actually, my variant is not
still implemented.
This question comes up on the different Python lists every once in a while.
In general, if you want something to be implemented in a specific way, feel
free to provide the im
Guido van Rossum, 12.08.2011 23:38:
On Fri, Aug 12, 2011 at 12:57 PM, Rene Nejsum wrote:
I think I understand the background and need for GIL. Without it Python
programs would have been cluttered with lock/synchronized statements and
C-extensions would be harder to write.
No, sorry, the first
Nick Coghlan, 15.08.2011 14:35:
On Mon, Aug 15, 2011 at 10:17 PM, Antoine Pitrou wrote:
AFAICT, often with True and False:
x = (some condition) ? Py_True : Py_False;
Py_INCREF(x);
return x;
And that's an idiom that works better with a Py_RETURN macro than it
would separate macros
Torsten Becker, 22.08.2011 20:58:
I have implemented an initial version of PEP 393 -- "Flexible String
Representation" as part of my Google Summer of Code project. My patch
is hosted as a repository on bitbucket [1] and I created a related
issue on the bug tracker [2]. I posted documentation fo
"Martin v. Löwis", 23.08.2011 10:55:
- “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 useful for mostly-ASCII strings, which
are extremely common (unless UTF-8 has become a no-op?
Torsten Becker, 22.08.2011 20:58:
I have implemented an initial version of PEP 393 -- "Flexible String
Representation" as part of my Google Summer of Code project. My patch
is hosted as a repository on bitbucket [1] and I created a related
issue on the bug tracker [2]. I posted documentation fo
"Martin v. Löwis", 23.08.2011 15:17:
Has this been considered before? Was there a reason to decide against it?
I think we simply didn't consider it. An early version of the PEP used
the lower bits for the pointer to encode the kind, in which case it even
stopped being a pointer. Modules are not
Antoine Pitrou, 23.08.2011 16:08:
On Tue, 23 Aug 2011 16:02:54 +0200
Stefan Behnel wrote:
"Martin v. Löwis", 23.08.2011 15:17:
Has this been considered before? Was there a reason to decide against it?
I think we simply didn't consider it. An early version of the PEP used
the
Torsten Becker, 24.08.2011 04:41:
Also, common, now simple, checks for "unicode->str == NULL" would look
more ambiguous with a union ("unicode->str.latin1 == NULL").
You could just add yet another field "any", i.e.
union {
unsigned char* latin1;
Py_UCS2* ucs2;
Py_UCS4*
Nick Coghlan, 24.08.2011 15:06:
On Wed, Aug 24, 2011 at 10:46 AM, Terry Reedy wrote:
In utf16.py, attached to http://bugs.python.org/issue12729
I propose for consideration a prototype of different solution to the 'mostly
BMP chars, few non-BMP chars' case. Rather than expand every character from
Victor Stinner, 25.08.2011 00:29:
With this PEP, the unicode object overhead grows to 10 pointer-sized
words (including PyObject_HEAD), that's 80 bytes on a 64-bit machine.
Does it have any adverse effects?
For pure ASCII, it might be possible to use a shorter struct:
typedef struct {
PyO
"Martin v. Löwis", 24.08.2011 20:15:
Guido has agreed to eventually pronounce on PEP 393. Before that can
happen, I'd like to collect feedback on it. There have been a number
of voice supporting the PEP in principle
Absolutely.
- conditions you would like to pose on the implementation before
"Martin v. Löwis", 24.08.2011 20:15:
- issues to be considered (unclarities, bugs, limitations, ...)
A problem of the current implementation is the need for calling
PyUnicode_(FAST_)READY(), and the fact that it can fail (e.g. due to
insufficient memory). Basically, this means that even somet
Stefan Behnel, 25.08.2011 20:47:
"Martin v. Löwis", 24.08.2011 20:15:
- issues to be considered (unclarities, bugs, limitations, ...)
A problem of the current implementation is the need for calling
PyUnicode_(FAST_)READY(), and the fact that it can fail (e.g. due to
insuffici
Isaac Morland, 26.08.2011 04:28:
On Thu, 25 Aug 2011, Guido van Rossum wrote:
I'm not sure what should happen with UTF-8 when it (in flagrant
violation of the standard, I presume) contains two separately-encoded
surrogates forming a valid surrogate pair; probably whatever the UTF-8
codec does on
Stefan Behnel, 25.08.2011 23:30:
Stefan Behnel, 25.08.2011 20:47:
"Martin v. Löwis", 24.08.2011 20:15:
- issues to be considered (unclarities, bugs, limitations, ...)
A problem of the current implementation is the need for calling
PyUnicode_(FAST_)READY(), and the fact that it can
"Martin v. Löwis", 26.08.2011 11:29:
You seem to assume it is ok for Jython/IronPython to provide indexing in
O(n). It is not.
I think we can leave this discussion aside. Jython and IronPython have
their own platform specific constraints to which they need to adapt their
implementation. For a
Antoine Pitrou, 26.08.2011 12:51:
Why would PEP 393 apply to other implementations than CPython?
Not the PEP itself, just the implications of the result.
The question was whether the language specification in a post PEP-393 can
(and if so, should) be changed into requiring unicode objects to
Stefan Behnel, 25.08.2011 23:30:
Sadly, a quick look at a couple of recent commits in the pep-393 branch
suggested that it is not even always obvious to you as the authors which
macros can be called safely and which cannot. I immediately spotted a bug
in one of the updated core functions
Guido van Rossum, 26.08.2011 19:02:
On Fri, Aug 26, 2011 at 3:29 AM, Stefan Behnel wrote:
Besides, what if these implementations provided indexing in, say, O(log N)
instead of O(1) or O(N), e.g. by building a tree index into each string? You
could have an index that simply marks runs of
"Martin v. Löwis", 26.08.2011 18:56:
I agree with your observation that somebody should be done about error
handling, and will update the PEP shortly. I propose that
PyUnicode_Ready should be explicitly called on input where raising an
exception is feasible. In contexts where it is not feasible (
Stefan Behnel, 26.08.2011 20:28:
"Martin v. Löwis", 26.08.2011 18:56:
I agree with your observation that somebody should be done about error
handling, and will update the PEP shortly. I propose that
PyUnicode_Ready should be explicitly called on input where raising an
exception is fe
Dan Stromberg, 27.08.2011 21:58:
On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan wrote:
On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda wrote:
On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan wrote:
It's acceptable for the Python version to use ctypes in the case of
wrapping an existing library, but
Hi,
sorry for hooking in here with my usual Cython bias and promotion. When the
question comes up what a good FFI for Python should look like, it's an
obvious reaction from my part to throw Cython into the game.
Terry Reedy, 28.08.2011 06:58:
Dan, I once had the more or less the same opinion
Guido van Rossum, 29.08.2011 04:27:
On Sun, Aug 28, 2011 at 11:23 AM, Stefan Behnel wrote:
Terry Reedy, 28.08.2011 06:58:
I think it needs a SWIG-like
companion script that can write at least first-pass ctypes code from the .h
header files. Or maybe it could/should use header info at runtime
2011 10:39, Stefan Behnel wrote:
In the CPython backend, the header files are normally #included by the
generated C code, so they are used at C compilation time.
Cython has its own view on the header files in separate declaration files
(.pxd). Basically looks like this:
# file "mymath.pxd
Barry Warsaw, 29.08.2011 18:24:
On Aug 29, 2011, at 11:03 AM, Dirkjan Ochtman wrote:
Also, this PEP makes me wonder if there should be a way to distinguish
between language PEPs and (CPython) implementation PEPs, by adding a
tag or using the PEP number ranges somehow.
I've thought about this,
Nick Coghlan, 30.08.2011 02:00:
On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou wrote:
On Mon, 29 Aug 2011 11:33:14 -0700 stefan brunthaler wrote:
* The optimized dispatch routine has a changed instruction format
(word-sized instead of bytecodes) that allows for regular instruction
decoding (wi
"Martin v. Löwis", 30.08.2011 10:46:
You might be reading more into that statement than I meant.
You have to supply Pyrex/Cython versions of the C declarations,
either hand-written or generated by a tool. But you write them
based on the advertised C API -- you don't have to manually
expand macros
Guido van Rossum, 30.08.2011 19:05:
On Tue, Aug 30, 2011 at 9:49 AM, "Martin v. Löwis" wrote:
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 there?
I had written a b
stefan brunthaler, 30.08.2011 22:41:
Ok, there there's something else you haven't told us. Are you saying
that the original (old) bytecode is still used (and hence written to
and read from .pyc files)?
Short answer: yes.
Long answer: I added an invocation counter to the code object and keep
int
Guido van Rossum, 01.09.2011 18:31:
On Thu, Sep 1, 2011 at 9:03 AM, Antoine Pitrou wrote:
Le jeudi 01 septembre 2011 à 08:45 -0700, Guido van Rossum a écrit :
This is definitely thought of as a separate
mark added to the e; ë is not a new letter. I have a feeling it's the
same way for the Frenc
Antoine Pitrou, 01.09.2011 18:46:
AFAIR, road signs also keep the accents, but I'm no driver
Right, I noticed that, too. That's certainly not uncommon. I think it's
mostly because of local pride (after all, the road signs are all that many
drivers ever see of a city), but sometimes also becau
Dan Stromberg, 01.09.2011 19:56:
On Tue, Aug 30, 2011 at 10:05 AM, Guido van Rossum wrote:
The problem lies with the PyPy backend -- there it generates ctypes
code, which means that the signature you declare to Cython/Pyrex must
match the *linker* level API, not the C compiler level API. Thus,
Greg Ewing, 02.09.2011 02:36:
Guido van Rossum wrote:
But in a word like "coëxistentie" (coexistence) the o
and e do not form the oe-sound, and to emphasize this to Dutch readers
(who believe their spelling is very logical :-), the official spelling
puts the umlaut on the e.
Sometimes this is
stefan brunthaler, 02.09.2011 06:37:
as promised, I created a publicly available preview of an
implementation with my optimizations, which is available under the
following location:
https://bitbucket.org/py3_pio/preview/wiki/Home
I followed Nick's advice and added some valuable advice and
overvi
stefan brunthaler, 02.09.2011 17:55:
4) Regarding inlined object references, I would expect that it's much more
worthwhile to speed up LOAD_GLOBAL and LOAD_NAME than LOAD_CONST. I guess
that this would be best helped by watching the module dict and the builtin
dict internally and invalidating the
Maciej Fijalkowski, 02.09.2011 20:42:
For a comparative real world benchmark I tested Martin von Loewis'
django port (there are not that many meaningful Python 3 real world
benchmarks) and got a speedup of 1.3 (without IIS). This is reasonably
well, US got a speedup of 1.35 on this benchmark. I j
"Martin v. Löwis", 08.10.2011 16:54:
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already have been optimized
to cache a string object, however, PyObject_CallMethod remains
unoptimi
Asif Jamadar, 20.10.2011 20:51:
So I'm trying to generate dynamic choices for django form.[...]
Note that this is the CPython core developers mailing list. The right list
for general Python programming related questions is either
python-l...@python.org, or the newsgroup comp.lang.python.
S
Antoine Pitrou, 20.10.2011 23:08:
I have been doing some performance experiments with memcmp, and I was
surprised that memcmp wasn't faster than it was in Python. I did a whole,
long analysis and came up with some very simple results.
Thanks for the analysis. Non-bugfix work now happens on Pyt
Richard Saunders, 21.10.2011 20:23:
As long as the two strings are the same unicode "kind", you can use a
memcmp to compare. In that case, I would almost argue some memcmp
optimization is even more important: unicode strings are potentially 2
to 4 times larger, so the amount of time spent in memc
tealing it?
Stefan
# HG changeset patch
# User Stefan Behnel
# Date 1319258140 -7200
# Node ID bbd4261e770df456ce35784343a4f7426ce2a642
# Parent c1effa2cdd20897bcda6a501a022b3b800a69a11
fix use-after-decref crash bug in setup code for unicode subtypes in pydebug mode
diff -r c1effa2cdd20 -r bb
"Martin v. Löwis", 23.10.2011 23:44:
I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ...
(after we put memcmp in unicode_compare)
-1. We shouldn't do anything about this. Python has the tradition of not
working around platform bugs, except if the work-arounds are necessary
Richard Saunders, 25.10.2011 01:17:
-On [20111024 09:22], Stefan Behnel wrote:
>>I agree. Given that the analysis shows that the libc memcmp() is
>>particularly fast on many Linux systems, it should be up to the Python
>>package maintainers for these systems to set that
Brian Curtin, 03.11.2011 15:59:
On Sat, Oct 22, 2011 at 14:30, Andrea Crotti wrote:
On 10/21/2011 10:08 PM, Antoine Pitrou wrote:
Hello,
There are currently a bunch of various buildbot failures on all 3
branches. I would remind committers to regularly take a look at the
buildbots, so that the
"Martin v. Löwis", 04.11.2011 08:39:
Is it worth the hassle? We can just port our existing error handlers,
and I guess the few third-party error handlers written in C (if any)
can bear the transition.
That was my question exactly. As the author of PEP 393, I was leaning
towards full backwards c
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user:Philip Jenvey
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Python/bltinmodule.c b/Pyt
Stefan Behnel, 07.11.2011 18:46:
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user: Philip Jenvey
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Python
Stefan Krah, 13.11.2011 13:05:
Nick Coghlan wrote:
With slices or the new casts (See: http://bugs.python.org/issue5231,
implemented in http://hg.python.org/features/pep-3118#memoryview ),
it is possible to have different hashes for equal objects:
Note that Antoine isn't suggesting that the und
401 - 500 of 633 matches
Mail list logo
