anatoly techtonik, 05.07.2012 21:41:
On Thu, Jul 5, 2012 at 7:50 PM, Stefan Behnel wrote:
anatoly techtonik, 05.07.2012 15:36:
On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote:
From Raymond's first message on http://bugs.python.org/issue6021 , add
grouper:
This has been rejected before
anatoly techtonik, 04.07.2012 11:57:
On Fri, Jun 29, 2012 at 11:32 PM, Georg Brandl wrote:
On 26.06.2012 10:03, anatoly techtonik wrote:
Now that Python 3 is all about iterators (which is a user killer
feature for Python according to StackOverflow -
Hi Raymond,
Raymond Hettinger, 01.07.2012 09:07:
On Jun 30, 2012, at 10:44 PM, Stefan Behnel wrote:
Another addition could be a new subsection on grouping (chunking) that
would discuss post-processing of grouper (as discussed above), as well as
other recipes, including ones specific
Paul Boddie, 01.07.2012 02:22:
Is there any reason why the compiler-sig mailing list wasn't chosen as a
venue
Even I didn't know that this list even existed. And looking at the archives
now, it's hard to see any relevant discussion in all the spam it received
until it apparently died away in
Armin Rigo, 18.06.2012 23:29:
On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski wrote:
Make cffi less buggy (check the tracker for new test cases ;-), faster
(closer to swig type wrappers), and easier to use than ctypes, and I am sure
there will be interest.
I would say it's already
Mark Shannon, 17.05.2012 12:38:
Dag Sverre Seljebotn wrote:
On 05/16/2012 10:24 PM, Robert Bradshaw wrote:
On Wed, May 16, 2012 at 11:33 AM, Martin v. Löwismar...@v.loewis.de
wrote:
Does this use case make sense to everyone?
The reason why we are discussing this on python-dev is that we
Martin v. Löwis, 16.05.2012 10:36:
And, we want this to somehow work with existing Python; we still
support users on Python 2.4.
This makes the question out-of-scope for python-dev - we only discuss
new versions of Python here. Old versions cannot be developed anymore
(as they are released
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, Martin v. Löwis wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling into
the C-API multiple times may be substantially more costly than,
Stefan Behnel, 16.05.2012 13:13:
Dag Sverre Seljebotn, 16.05.2012 12:48:
On 05/16/2012 11:50 AM, Martin v. Löwis wrote:
Agreed in general, but in this case, it's really not that easy. A C
function call involves a certain overhead all by itself, so calling into
the C-API multiple times may
Matt Joiner, 02.05.2012 15:37:
On May 2, 2012 6:00 PM, Antoine Pitrou wrote:
On Wed, 02 May 2012 01:43:32 -0700
Larry Hastings la...@hastings.org wrote:
I realize we can't jump to C99 because of A Certain Compiler. (Its name
rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even
Hi,
I noticed that there is a PEP (3154) and a GSoC proposal about improving
Pickle. Given the recent discussion on this list about using Cython for the
import module, I wonder if it wouldn't make even more sense to switch from
a C (accelerator) implementation to Cython for _pickle.
The
Matt Joiner, 19.04.2012 16:13:
Personally I find the unholy product of C and Python that is Cython to be
more complex than the sum of the complexities of its parts. Is it really
wise to be learning Cython without already knowing C, Python, and the
CPython object model?
The main obstacle that
Brian Curtin, 19.04.2012 23:19:
On Thu, Apr 19, 2012 at 16:08, Stefan Behnel
While code generation alleviates the burden of tedious languages, it's also
infinitely more complex, makes debugging very difficult and adds to
prerequisite knowledge, among other drawbacks.
You can use gdb
Brett Cannon, 14.04.2012 20:12:
My multi-year project -- started in 2006 according to my blog -- to rewrite
import in pure Python and then bootstrap it into CPython as *the*
implementation of __import__() is finally over (mostly)! Hopefully I didn't
break too much code in the process. =)
Antoine Pitrou, 16.04.2012 13:13:
On Mon, 16 Apr 2012 09:54:41 +0200
Stefan Behnel wrote:
The new import cache broke Cython's load of on-the-fly compiled extension
modules, which naively used __import__(module_name) after building them.
I could fix that by moving to imp.load_dynamic() (we
Martin v. Löwis, 16.04.2012 16:07:
We have other instances of this (e.g. the Objects/typeslots.inc file
is generated and checked in), but in the case of importlib, we have
to use the ./python binary for freezing to avoid bytecode
incompatibilities, which obviously is a problem if ./python
Amaury Forgeot d'Arc, 16.04.2012 22:43:
2012/4/16 Stefan Behnel
On the down side, we would depend on Cython for evolving .
Right, although not as a strict dependency. The code would still work just
fine in plain Python.
Not quite, we are talking of the imp module here...
Hmm, right, after
Antoine Pitrou, 17.04.2012 02:27:
On Tue, 17 Apr 2012 01:11:14 +0200
Georg Brandl wrote:
No, it's not just an existing Python, it is (at least currently) the same
version of Python being built. Therefore I wrote about the bootstrapping
problems when bytecode changes.
Depending on Cython is
Armin Rigo, 11.04.2012 13:47:
This is an update on the (so far PyPy-only) project of adding Automatic
Mutual Exclusion to Python, via STM (Software Transactional Memory).
[...]
Moreover the performance hit is well below 2x, more like 20%.
Hmm, those 20% refer to STM, right? Without hardware
Armin Rigo, 11.04.2012 14:51:
On Wed, Apr 11, 2012 at 14:29, Stefan Behnel wrote:
Moreover the performance hit is well below 2x, more like 20%.
Hmm, those 20% refer to STM, right? Without hardware support? Then hardware
support could be expected to drop that even further?
Yes, that's using
Stefan Behnel, 11.04.2012 15:31:
Armin Rigo, 11.04.2012 14:51:
On Wed, Apr 11, 2012 at 14:29, Stefan Behnel wrote:
Did you do any experiments with running parallel code so far, to see if
that scales as expected?
Yes, it scales very nicely on small non-conflicting examples. I
believe
Antoine Pitrou, 02.04.2012 13:50:
On Sun, 1 Apr 2012 19:44:00 -0500
Brian Curtin wrote:
On Sun, Apr 1, 2012 at 17:31, Matěj Cepl wrote:
On 1.4.2012 23:46, Brian Curtin wrote:
For what reason? Are the git or bzr files causing issues on HG?
No, but wrong .gitignore causes issues with git
Hannu Krosing, 31.03.2012 14:22:
Has anyone used Cython for developing a module to be used from
postgreSQL/pl/python.
Something that calls back to PostgreSQL internals.
Note that this is the CPython core developers mailing list, for which your
question is off-topic. Please ask on the
Etienne Robillard, 30.03.2012 17:45:
Sorry also if this is OT... :)
Yes, it is. Please do as Nick told you.
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Etienne Robillard, 30.03.2012 18:08:
are you also truth allergic or irritated by the consequences of
free speech ?
Please note that free speech is a concept that is different from asking
beginner's computer science questions on the core developer mailing list of
a software development project.
R. David Murray, 29.03.2012 22:31:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray wrote:
Some of us have expressed uneasiness about the consequences of dict
raising an error on lookup if the dict has been modified, the fix Victor
Guido van Rossum, 17.03.2012 00:57:
OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ?
In lxml, there was an encoding=unicode option that would let the
XML/HTML/text serialisation function return a Unicode string. This was
eventually deprecated in favour of
Merlijn van Deen, 17.03.2012 15:20:
On 17 March 2012 10:43, Stefan Behnel wrote:
In lxml, there was an encoding=unicode option that would let the
XML/HTML/text serialisation function return a Unicode string. This was
eventually deprecated in favour of encoding='unicode' when ElementTree
Eli Bendersky, 16.03.2012 08:38:
The Element class in ElementTree
(http://docs.python.org/py3k/library/xml.etree.elementtree.html) has
some methods for adding new children: append, insert and extend.
Currently the documentation states that extend raises AssertionError
when something that's
Antoine Pitrou, 08.03.2012 21:36:
On Thu, 8 Mar 2012 14:36:06 -0600
Benjamin Peterson wrote:
2012/3/8 Stefan Behnel:
Would that be acceptable for CPython as well or would you prefer full
fledged normalisation?
I think we have to normalize for correctness. Consider that it may be
some
Stefan Behnel, 07.03.2012 21:40:
I found a problem in the current yield from implementation
... and here's another one, also in genobject.c:
int
PyGen_FetchStopIterationValue(PyObject **pvalue) {
PyObject *et, *ev, *tb;
PyObject *value = NULL;
if (PyErr_ExceptionMatches
Hi,
I found a problem in the current yield from implementation that I think
is worth discussing:
http://bugs.python.org/issue14220
Test code:
def g1():
yield y1
yield from g2()
yield y4
def g2():
yield y2
try:
yield from gi
Maciej Fijalkowski, 06.03.2012 00:08:
For a comparison, PyPy sandbox is a compiled from higher-level
language program that by design does not have all sorts of problems
described. The amount of code you need to carefully review is very
minimal (as compared to the entire CPython interpreter).
Nick Coghlan, 06.03.2012 12:19:
On Tue, Mar 6, 2012 at 8:34 PM, Stefan Krah wrote:
The obvious question is: Will anyone need view==NULL in the future or
can we remove the special case?
The public API will still need a guard (to report an error), but +1
for otherwise eliminating the
Jim J. Jewett, 06.03.2012 20:43:
Hash Randomization (issue 13703) is now on by default. Unfortunately,
this does break some tests; it can be temporarily turned off by setting
the environment variable PYTHONHASHSEED to 0 before launching python.
I don't think that makes it clear enough that
Stefan Krah, 04.03.2012 12:33:
Thomas Wouters wrote:
Do you test against pydebug builds of Python, or otherwise a build that
actually enables asserts?
Yes, I do (and much more than that):
Nick Coghlan, 03.03.2012 00:49:
On Sat, Mar 3, 2012 at 3:14 AM, Stefan Behnel wrote:
Stefan Krah, 02.03.2012 17:42:
The reason why this scheme was not chosen for a chain of memoryviews
was that 'exporter' (in theory) could implement a slideshow of buffers,
which means that in the face
Eli Bendersky, 03.03.2012 09:36:
I find a strange discrepancy in Python with regards to slice
subscripting of objects, at the C API level. I mean things like
obj[start:end:step].
I'd expect slice subscripts to be part of the sequence interface, and
yet they are not. In fact, they are part
Thomas Wouters, 03.03.2012 21:59:
Why even have separate tp_as_sequence and tp_as_mapping anymore? That
particular distinction never existed for Python types, so why should it
exist for C types at all? I forget if there was ever a real point to it,
but all it seems to do now is create
Hi,
I just stumbled over this assertion in _PyManagedBuffer_FromObject() in the
latest Py3.3 branch:
static PyObject *
_PyManagedBuffer_FromObject(PyObject *base)
{
_PyManagedBufferObject *mbuf;
mbuf = mbuf_alloc();
if (mbuf == NULL)
return NULL;
if
Stefan Krah, 02.03.2012 12:53:
Stefan Behnel wrote:
if (PyObject_GetBuffer(base, mbuf-master, PyBUF_FULL_RO) 0) {
/* mbuf-master.obj must be NULL. */
Py_DECREF(mbuf);
return NULL;
}
/* Assume that master.obj is a new reference to base. */
assert
of the module. Now, if
the module does not have unit tests or they don't test against a
new Python version is that really our problem?
Crashing out with a C assert when we can easily give them a nice
Python traceback instead is unnecessarily unfriendly. As Stefan Behnel
pointed out
= memoryview(nd)
nd.obj
b'123'
m.obj
ndarray object at 0x7fbef33677d8
Stefan (Behnel), do you have an existing example object that does
what you described? If I understand correctly, in the above example
the ndarray would redirect the buffer request to 'exporter' and
set m.obj
Stefan Behnel, 23.02.2012 09:01:
Martin v. Löwis, 19.02.2012 23:24:
When compiling for PyPy, Cython therefore needs a way to tell PyPy about
any changes. For the tstate-curexc_* fields, there are the two functions
PyErr_Fetch() and PyErr_Restore(). Could we have two similar official
functions
Martin v. Löwis, 19.02.2012 23:24:
When compiling for PyPy, Cython therefore needs a way to tell PyPy about
any changes. For the tstate-curexc_* fields, there are the two functions
PyErr_Fetch() and PyErr_Restore(). Could we have two similar official
functions for the exc_* fields? Maybe
Hi,
the Cython and PyPy projects are currently working on getting Cython
implemented extensions to build and run in PyPy, interfacing at the C-API
level for now.
One problem we encountered was that there is currently no abstract way to
access tstate-exc_type and friends, i.e. the last exception
Nick Coghlan, 19.02.2012 15:31:
On Mon, Feb 20, 2012 at 12:18 AM, Paul Moore wrote:
Of course, you could always go through the Python API, getting the sys
module, extracting the relevant functions and calling them using the
abstract API. That's what I'd recommend if this were purely a CPython
Nick Coghlan, 14.02.2012 05:44:
On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote:
With the deprecation warning being silent, is there much to lose, though?
Yes, it creates problems for anyone that deliberately converts all
warnings to errors when running their test suites. This forces
Eli Bendersky, 13.02.2012 12:35:
Since there appeared to be an overall positive response for making
this change in Python 3.3, and since there isn't longer any doubt
about the ownership of the package *in Python's stdlib* (see
Eli Bendersky, 10.02.2012 10:06:
On Fri, Feb 10, 2012 at 10:32, Florent wrote:
2012/2/10 Eli Bendersky
Thanks for the input, Florent. So, to paraphrase, there already are
code changes in the stdlib version of ET/cET which are not upstream.
You made it explicit about the tests, so the
Martin v. Löwis, 10.02.2012 10:37:
Given that it was two months ago that I started the Fixing the XML
batteries thread (and years since I brought up the topic for the first
time), it seems to be hard enough already to get anyone on python-dev
actually do something for Python's XML support,
Martin v. Löwis, 10.02.2012 11:32:
What happens now? Do we give up on touching it until Fredrik Lundh
decides on a come-back or some person who is willing to commit 5 years
is found? Or do we just *keep* maintaining it in the stdlib as we do
with other modules, fixing bugs, tests,
Eli Bendersky, 08.02.2012 07:07:
On Wed, Feb 8, 2012 at 07:10, Fred Drake wrote:
On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky wrote:
The initial proposal of changing *the stdlib
import facade* for xml.etree.ElementTree to use the C accelerator
(_elementtree) by default.
I guess this is
Fred Drake, 08.02.2012 05:41:
On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky wrote:
Besides, in
http://mail.python.org/pipermail/python-dev/2011-December/114812.html
Stefan Behnel said [...] Today, ET is *only* being maintained in the
stdlib by Florent Xicluna [...]. Is this not true?
I
Nick Coghlan, 31.01.2012 12:11:
On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner wrote:
I think this is definitely worth elaborating in a PEP (to recap the
long discussion in #11457 if nothing else).
The discussion in issues #13882 and #11457 already lists many
alternatives with their costs
stefan brunthaler, 31.01.2012 22:17:
Well, nobody wants to review generated code.
I agree. The code generator basically uses templates that contain the
information and a dump of the C-structure of several types to traverse
and see which one of them implements which functions. There is really
stefan brunthaler, 30.01.2012 20:18:
Well, you're aware that Python already uses threaded code where
available? Or are you testing against Python 2?
Yes, and I am building on that.
I assume yes here means yes, I'm aware and not yes, I'm using Python
2, right? And you're building on top of the
Glenn Linderman, 27.01.2012 07:47:
Can we have a tree type in 3.3, independent of dict?
I'd be happy to see that happen, but I guess the usual requirements on
stdlib extensions would apply here. I.e., someone has to write the code,
make sure people actually use it to prove that it's worth being
mar...@v.loewis.de, 27.01.2012 09:55:
So I found Ian Piumarta's AVL tree 1.0 from 2006. I trust Ian Piumarta
to get it right (plus I reviewed the code a little). There are some
API glitches (such as assuming a single comparison function, whereas
it would better be rewritten to directly invoke
Terry Reedy, 14.01.2012 06:43:
On 1/13/2012 8:58 PM, Gregory P. Smith wrote:
It is perfectly okay to break existing users who had anything depending
on ordering of internal hash tables. Their code was already broken.
Given that the doc says Return the hash value of the object, I do not
Guido van Rossum, 15.01.2012 17:10:
On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel wrote:
Terry Reedy, 14.01.2012 06:43:
On 1/13/2012 8:58 PM, Gregory P. Smith wrote:
It is perfectly okay to break existing users who had anything depending
on ordering of internal hash tables. Their code
Hi,
sorry for hooking into this off-topic thread.
Amaury Forgeot d'Arc, 09.01.2012 19:09:
2012/1/9 paspa...@noos.fr
I am trying to send a tuple to a method of a python class and I got a Run
failed from netbeans compiler
when I want to send a tuple to a simple method in a module it works,when
Matt Joiner, 10.01.2012 09:40:
Perhaps the python-dev mailing list should be renamed to python-core.
Well, there *is* a rather visible warning on the list subscription page
that tells people that it's most likely not the list they actually want to
use. If they manage to ignore that, I doubt that
Jim Jewett, 08.01.2012 23:33:
Stefan Behnel wrote:
Admittedly, this may require some adaptation for the PEP393 unicode memory
layout in order to produce identical hashes for all three representations
if they represent the same content.
They SHOULD NOT represent the same content; comparing
Christian Heimes, 31.12.2011 04:59:
Am 31.12.2011 03:22, schrieb Victor Stinner:
The unique structure of CPython's dict implementation makes it harder to
get the number of values with equal hash. The academic hash map (the one
I learnt about at university) uses a bucket to store all elements
Mark Shannon, 23.12.2011 12:21:
Martin v. Löwis wrote:
- it would be useful to have a specialized representation for
all-keys-are-strings. In that case, me_hash could be dropped
from the representation. You would get savings compared to
the status quo even in the non-shared case.
It might
Antoine Pitrou, 22.12.2011 10:56:
On Thu, 22 Dec 2011 09:44:32 +
Tim Wintle wrote:
2.5 apps are the speed-critical ones. Our tests showed the performance
was different enough between 2.5 and 2.6 for me to not update.
Really? Where's the regression?
That's not unexpected at least, and
Stefan Behnel, 14.12.2011 20:41:
It's clear from the
discussion that there are still users and that new code is still being
written that uses MiniDOM. However, I would argue that this cannot possibly
be performance critical code and that it only deals with somewhat small
documents. I say
Stefan Behnel, 09.12.2011 09:02:
I think Py3.3 would be a good milestone for cleaning up the stdlib support
for XML.
[...]
I still think it is, so let me sum up the current discussion here.
What should change?
a) The stdlib documentation should help users to choose the right tool
right
Martin v. Löwis, 14.12.2011 18:23:
overhead of running 2to3 every time 'setup.py develop' etc. runs dooms
the effort.
How so? Running 2to3 after every change is very fast. I never use
setup.py develop, though.
I think the problem starts with the fact that it needs to be run in the
first
Martin v. Löwis, 14.12.2011 19:14:
Am 12.12.2011 10:04, schrieb Stefan Behnel:
Martin v. Löwis, 11.12.2011 23:39:
I can't recall anyone working on any substantial improvements during the
last six years or so, and the reason for that seems obvious to me.
What do you think is the reason? It's
Xavier Morel, 14.12.2011 20:54:
On 2011-12-14, at 20:41 , Stefan Behnel wrote:
I meant: lack of interest in improving them. It's clear from the
discussion that there are still users and that new code is still being
written that uses MiniDOM. However, I would argue that this cannot
possibly
Martin v. Löwis, 14.12.2011 22:20:
Am 14.12.2011 20:41, schrieb Stefan Behnel:
Martin v. Löwis, 14.12.2011 19:14:
Am 12.12.2011 10:04, schrieb Stefan Behnel:
Martin v. Löwis, 11.12.2011 23:39:
I can't recall anyone working on any substantial improvements
during the
last six years or so
Martin v. Löwis, 11.12.2011 23:39:
I can't recall anyone working on any substantial improvements during the
last six years or so, and the reason for that seems obvious to me.
What do you think is the reason? It's not at all obvious to me.
Just to repeat myself for the third time here: lack
Martin v. Löwis, 11.12.2011 23:03:
Am 09.12.2011 10:09, schrieb Xavier Morel:
On 2011-12-09, at 09:41 , Martin v. Löwis wrote:
a) The stdlib documentation should help users to choose the right
tool right from the start. Instead of using the totally
misleading wording that it uses now, it
Stefan Behnel, 12.12.2011 10:59:
Just look through the xml-sig page
Hmm, I meant xml-sig mailing list archive here ...
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
Hi everyone,
I think Py3.3 would be a good milestone for cleaning up the stdlib support
for XML. Note upfront: you may or may not know me as the maintainer of
lxml, the de-facto non-stdlib standard Python XML tool. This (lengthy) post
was triggered by the following kind of conversation that I
Martin v. Löwis, 09.12.2011 09:41:
a) The stdlib documentation should help users to choose the right tool
right from the start. Instead of using the totally misleading wording
that it uses now, it should be honest about the performance
characteristics of MiniDOM and should actively suggest that
Bill Janssen, 09.12.2011 19:15:
I think another thing that might go into refreshing the batteries is a
feature comparison of BeautifulSoup and HTML5lib against the stdlib
competition, to see what needs to be added/revised. Having to switch to
an outside package for parsing possibly invalid HTML
Giampaolo Rodolà, 22.11.2011 10:21:
2011/11/21 Terry Reedy:
I strongly recommend that where it makes a difference, the pypy python3
project target 3.3. In particular, don't reproduce the buggy narrow-build
behavior of 3.2 and before (perhaps pypy avoids this already). Do include
the new unicode
Maciej Fijalkowski, 22.11.2011 15:46:
On Tue, Nov 22, 2011 at 3:15 PM, Stefan Behnel wrote:
Giampaolo Rodolà, 22.11.2011 10:21:
2011/11/21 Terry Reedy:
I strongly recommend that where it makes a difference, the pypy python3
project target 3.3. In particular, don't reproduce the buggy narrow
Hi,
I recently got some patches accepted for inclusion in 3.3, and each time,
the patch metadata (such as my name and my commit comment) were stripped by
applying the patch manually, instead of hg importing it. This makes it
clear in the history who eventually reviewed and applied the patch,
Stefan Behnel, 15.11.2011 09:01:
Martin v. Löwis, 15.11.2011 01:33:
An approach similar to _Py_PackageContext should be possible.
Yes, and a _Py_ModuleImportContext would be rather trivial to do.
Could that go into 3.3?
If somebody contributes a patch: sure.
Ok, cool.
Patch(es) uploaded
Stefan Behnel, 13.11.2011 19:48:
I noticed that _PyImport_FindExtensionObject() in Python/import.c does not
set _Py_PackageContext when it calls the module init function for module
reinitialisation. However, PyModule_Create2() still uses that variable to
figure out the fully qualified module
Martin v. Löwis, 15.11.2011 01:33:
Currently, for Cython? I don't think that can work.
Hmm, it might work to put an empty module next to the 'real' extension
and to import it to figure out the common directory of both. As long as
it's still there after installation and the right one gets
Martin v. Löwis, 13.11.2011 21:46:
I'm asking specifically because I'd like to properly implement __file__
in Cython modules at module init time.
Why do you need to implement __file__? Python will set it eventually to
its correct value, no?
Well, yes, eventually. However, almost all real
mark florisson, 14.11.2011 12:55:
On 14 November 2011 08:18, Stefan Behnel wrote:
Martin v. Löwis, 13.11.2011 21:46:
I'm asking specifically because I'd like to properly implement __file__
in Cython modules at module init time.
Why do you need to implement __file__? Python will set
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
Hi,
I noticed that _PyImport_FindExtensionObject() in Python/import.c does not
set _Py_PackageContext when it calls the module init function for module
reinitialisation. However, PyModule_Create2() still uses that variable to
figure out the fully qualified module name. Was this intentionally
Hi,
in Python modules, the __file__ attribute is provided by the runtime
before executing the module body. For extension modules, it is set only
after executing the init function. I wonder if there's any way to figure
out where an extension module is currently being loaded from. The
Stefan Behnel, 07.11.2011 18:46:
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user: Philip Jenveypjen...@underboss.org
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions
Éric Araujo, 07.11.2011 18:24:
http://hg.python.org/cpython/rev/bbc929bc2224
user:Philip Jenveypjen...@underboss.org
summary:
quote the type name for improved readability
files:
Python/bltinmodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
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
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
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 option externally through
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
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
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
it?
Stefan
# HG changeset patch
# User Stefan Behnel stefan...@behnel.de
# 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
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.
301 - 400 of 622 matches
Mail list logo
