M.-A. Lemburg wrote:
> I find the implementation of the buffer protocol way too complicated.
> One of the reasons why the buffer protocol in Python 2 never caught
> on was the fact that it was too complicated and the Python 3 is
> even worse in this respect.
>
> In practice you do want to have the
Stefan Behnel wrote:
> Antoine Pitrou wrote:
>> Stefan Behnel behnel.de> writes:
>>> From a Cython perspective, I find the lack of efficient subclassing after
>>> such a change particularly striking.
>> what do you call "efficient subclassing"? i
Stefan Behnel wrote:
> (s + s->tp_basicsize)
I (obviously) meant
(s + Py_TYPE(s)->tp_basicsize)
so the impact is another bit bigger.
Stefan
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listin
Greg Ewing canterbury.ac.nz> writes:
> > We create a new struct for the type that contains the parent-struct
> > as first field, and then we add the new attributes of the new type behind
> > that.
>
> I seem to remember there's a field in the type called tp_basicsize
> that's meant to indicate ho
Martin v. Löwis wrote:
>> I wouldn't mind letting Cython special case subtypes of str (or unicode in
>> Py3) *somehow*, as long as this "somewhow" proves to be a viable solution
>> that
>> only applies to exactly those types *and* can be done realiably for subtypes
>> of subtypes. I'm just not awa
Martin v. Löwis wrote:
>>> Can you explain this a bit more? I presume you're talking about
>>> subclassing in C
>> Yes, I mentioned Cython above.
>
> Can you please still elaborate? I have never used Cython before
Should have been clearer, sorry. C-level subtyping in Cython/Pyrex works as
follows
Hi,
Guido van Rossum wrote:
> On Sun, Sep 7, 2008 at 12:15 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>> Antoine Pitrou wrote:
>>> Also note that Marc-André Lemburg (one of the authors of the unicode
>>> implementation) is opposed to that change. See the d
Antoine Pitrou wrote:
> Stefan Behnel behnel.de> writes:
>> From a Cython perspective, I find the lack of efficient subclassing after
>> such
>> a change particularly striking. That seriously bit me in Py2 when I tried
>> making XML text content a bit more int
Antoine Pitrou wrote:
> Also note that Marc-André Lemburg (one of the authors of the unicode
> implementation) is opposed to that change. See the discussion in the bug
> tracker
> issue for the details.
From a Cython perspective, I find the lack of efficient subclassing after such
a change partic
Greg Ewing wrote:
> Stefan Behnel wrote:
>
>> In the absence of information provided by an external transport
>> protocol (e.g.
>> HTTP or MIME), it is a fatal error for an entity including an encoding
>> declaration to be presented to the XML processor in an encodi
Guido van Rossum wrote:
> 2008/8/24 "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> Parsing Unicode XML strings isn't quite that meaningful.
>
> Maybe not according to the XML standard, but I can see lots of
> practical situations where the encoding is always known and applied by
> some other layer, i.e
Antoine Pitrou wrote:
> I took a look at test_sax and it seems sax.parser expects all (XML) input as
> unicode rather than bytes. Apparently ElementTree does the same. Is there any
> rationale for this decision?
There can't be. Serialised XML is about bytes, not characters.
Taking lxml as a refer
Martin v. Löwis wrote:
>> Given the fact that most packages that depend on ET already use more than one
>> try-except import for these modules anyway (and likely a separate module that
>> cares for the right import), I don't see the situation becoming any worse by
>> making them PEP8 compliant.
>
Hi,
I wonder why the ElementTree modules in Py3k's xml.etree still do not follow
PEP8 naming (ok, besides the obvious explanation that no-one renamed them so
far). Was there a decision that they should keep their name despite the
general push towards a uniformly named standard library? Or would it
Greg Ewing wrote:
> Martin v. Löwis wrote:
>
>> However, _sre relied on the module already being in
>> sys.modules, as it runs Python code in the init function that already
>> imports the module being initialized.
>
> This issue also potentially affects all Pyrex and Cython
> generated modu
Nick Coghlan wrote:
> I recently spent an hour reverting a mistaken CVS checkin (meant to
> check in one file, checked in the whole working tree instead) that could
> have been reverted with a single command in SVN.
:) I know what that feels like ...
That's where Mercurial's "hg rollback" comes i
Raymond Hettinger wrote:
> I know this group doesn't care about Psyco, but it was
> nice that psyco could handle listcomps just like it could with
> regular for-loops. Turning it into a genexp stops psyco in its tracks.
> Likewise, Cython won't be able to handle the semantics.
Regarding Cython, I
Adam Olsen wrote:
> On Fri, Jul 11, 2008 at 6:11 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Stefan Behnel wrote:
>>
>>> While I agree with this being bad design, I do think that the above is a
>>> bug.
>>> It's a different thing if the iterab
Greg Ewing wrote:
> Antoine Pitrou wrote:
>
>> That is, in your example:
>>
>> >>> def f(x):
>> ... if x > 5: raise StopIteration
>> ...
>> >>> list(x for x in range(100) if not f(x))
>> [0, 1, 2, 3, 4, 5]
>>
>> f() certainly shouldn't raise a StopIteration. There's no reason for
>> doing
>> th
Hi Martin,
Stefan Behnel wrote:
>> Martin v. Löwis wrote:
>>> I just finished a PEP 3121 implementation
>
> what's the migration path to write portable code, then?
Looking through your complete commit, I realised that it's actually not that
hard to work arou
Stefan Behnel wrote:
> Martin v. Löwis wrote:
>> I just finished a PEP 3121 implementation
>
> Maybe a bit late for this question, but:
>
> Was it necessary to remove Py_InitModule4() for this change? We use that in
> Cython, so this breaks building extension module i
Martin v. Löwis wrote:
> I just finished a PEP 3121 implementation
Maybe a bit late for this question, but:
Was it necessary to remove Py_InitModule4() for this change? We use that in
Cython, so this breaks building extension module in current Py3.
Stefan
___
Hi,
this is a request for a decision based on this bug report:
http://bugs.python.org/issue2997
In the current py3k branch, the nb_divide field (position 4) in the
PyNumberMethods has been removed, but three other fields further on were left
in for compatibility. Since the fourth field of that s
Anand Balachandran Pillai wrote:
> After commenting out the code which catches the ImportError,
> this is the trace.
>
> [EMAIL PROTECTED] ~]$ python3
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
> File "/usr/local/lib/python3.0/
Stefan Behnel wrote:
> So that means it's fine to remove all locking related functionality from the
> new buffer protocol and leave everything to application space, right?
>
> Here is a patch for the PEP that reflects this.
I filed this as bug #3046.
http://bugs.python.org/
Greg Ewing wrote:
> Stefan Behnel wrote:
>> So that means it's fine to remove all locking related functionality
>> from the
>> new buffer protocol and leave everything to application space, right?
>
> Not quite all of it -- the buffer needs to be considered
&g
Alexandre Vassalotti wrote:
> Is there a way to specify keyword-only arguments using the C API. I
> searched through the mailing list archive, read PEP 3102 and grep-ed
> the codebase, but I found nothing looking like a C API. So I am
> wondering, is this a Python-only feature?
Cython also has it.
Nick Coghlan wrote:
> Stefan Behnel wrote:
>> One question: what does that mean for the mutable bytearray class? How
>> would that handle locking?
>
> No need to confuse the question of memory access with the question of
> thread synchronisation.
Fair enough. Single-th
Greg Ewing wrote:
> Stefan Behnel wrote:
>> So you'd always have to release your own read buffer before acquiring a
>> write buffer
>
> Yes, you really want to be able to upgrade your own lock
> from a read lock to a write lock, which means the provider
> has to k
Greg Ewing canterbury.ac.nz> writes:
> The way I thought this was supposed to work is that the
> buffer is *always* locked while the client is accessing
> it, the only choice being whether it's a read-only or
> read-write lock.
Thinking about this some more while updating the PEP:
This scheme ha
Hi Greg,
Greg Ewing canterbury.ac.nz> writes:
> The way I thought this was supposed to work is that the
> buffer is *always* locked while the client is accessing
> it, the only choice being whether it's a read-only or
> read-write lock.
I don't think there should always be a lock in the sense th
Travis Oliphant ieee.org> writes:
> This should be clarified in the PEP. Can you take a stab at it?
Here's a patch for what I think the locking protocol part should look like. It
changes the "passing NULL as Py_buffer" bit into a requirement to always pass a
Py_buffer structure, and distinguishe
Travis Oliphant wrote:
> This should be clarified in the PEP. Can you take a stab at it?
Would this work?
Stefan
Index: pep-3118.txt
===
--- pep-3118.txt (Revision 63861)
+++ pep-3118.txt (Arbeitskopie)
@@ -153,10 +153,8 @@
This
Guido van Rossum wrote:
> I really don't like the idea of having Py3k code with doctests written
> in a dialect of Py2k...
BTW, this argument might hold for code that was written for Py3, of which
there currently is close to nothing.
Stefan
___
Python-
Stefan Behnel wrote:
> It would be
> really nice if the doctest module had a simple option that specified if the
> doctests of a test suite are in Py2 or Py3 syntax, and then just did the right
> thing under Py3 (and maybe also 2.6).
I filed a feature request on this fo
Hi,
Nick Coghlan wrote:
> Doctest just uses 'exec' under the covers though - the only way for it
> to run code using non-native syntax would be for it to be able to invoke
> a non-native parser and then run the resulting AST directly, or for it
> to invoke 2to3 on the docstring.
I think it should
Hi again,
sorry, mail editing disorder. I meant to say this:
Stefan Behnel wrote:
> BTW, last time I checked, options were passed into lib2to3 as attributes of
> an object. I find that very inconvenient. A dict or keyword arguments would
> work much better.
And just to give a hint
Guido van Rossum wrote:
> 2to3 lets you specify exactly which fixers to run with the -f command line
> flag.
Nice, one problem solved then. I assume that's also available in the library
version?
object. I find that very inconvenient.BTW, last time I checked, options were
passed into lib2to3 as
Georg Brandl wrote:
> Stefan Behnel schrieb:
>> I know, I could use the lib2to3 package, but it a) is a one-way tool
>> in the
>> wrong direction if you have to distinguish bytes/str literals, b) lacks
>> configurability stating exactly what changes need to be done an
Hi,
I currently use a bunch of work-arounds for doctests in lxml's test suite to
make them work in Py3. I converted most tests to a mix of Py2 and Py3 syntax
(e.g. using both u'' and b'' literals), and most of the runtime work is done
using regular expressions that convert the except-as syntax, st
Christian Heimes wrote:
> Stefan Behnel schrieb:
>> M.-A. Lemburg wrote:
>>> If you use PyBytes APIs, you expect to find PyBytes functions in
>>> the libs and also set breakpoints on these.
>> AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no pro
[EMAIL PROTECTED] wrote:
> I just looked through the official tutorial and Dive into Python, and
> didn't find anything about it in either of those places.
Tutorial section on "tuples and sequences", not quite the most hidden place in
the universe.
http://docs.python.org/tut/node7.html#SECTION007
M.-A. Lemburg wrote:
> If you use PyBytes APIs, you expect to find PyBytes functions in
> the libs and also set breakpoints on these.
AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
here.
Besides, how likely is it that users set a breakpoint on the PyBytes/PyString
f
Lisandro Dalcin wrote:
> Chistian, I've posted some weeks ago some observation about the status
> of PyNumberMethods API. The thread link is below, I t did not received
> much atention.
>
> http://mail.python.org/pipermail/python-3000/2008-May/013594.html
>
> Now I sumarize that post
>
> * 'nb_n
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
hard to compile existing code against the current branch state...
Stefan
_
Travis Oliphant wrote:
> Stefan Behnel wrote:
>> Anyway, my point is that this part of the protocol actually implies
>> setting a
>> lock on the buffer *provider* rather than the buffer itself, as the
>> buffer
>> provider cannot distinguish between different b
Hi,
Christian Heimes wrote:
> * add a new file stringobject.h which contains the aliases PyString_ ->
> PyBytes_
will that be included by Python.h by default?
Stefan
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/l
Hi,
while implementing Py_buffer support in Cython, I noticed (the hard way,
throught a segfault), that the buffer pointer passed into getbuffer() can be
NULL, e.g. when calling memoryview.tobytes(). According to PEP 3118 (first
paragraph below the getbuffer() signature), this implies setting a lo
Hi,
just a quick announcement that I finished the port of the Cython compiler to
Py3. While you cannot currently run Cython itself in Py3, you can build the
generated C sources unchanged under Py2.3 through 3.0a5.
http://cython.org/
There isn't a release yet (though there will hopefully be o
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
Steven Bethard schrieb:
> On 11/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> But the >>> prompt is Python's trademark! I always get a warm fuzzy
>> feeling when I see it, e.g. in a corner of a slide in a NASA
>> presentation.
>
> I was using ``py>`` for a while. That still gave me a wa
Hi,
George Sakkis wrote:
> On 11/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Are you going to propose similar
>> changes for all standard de-facto interfaces, like sequences,
>> mappings, files etc.?
>
> No, I won't (at least not for now ;-)). Notice however that most
> user-defined seq
Hi,
Fred L. Drake, Jr. wrote:
> On Tuesday 17 October 2006 05:00, Nick Coghlan wrote:
> > I must say I was surprised people found potential confusion between PyPy
> > and PyPI, though. I'd always pronounced the latter as Py-Pea-Eye (and it
> > was a tool for finding useful Python packages, so t
Stefan Behnel wrote:
> Collin Winter wrote:
>> def compile(source: "something compilable",
>> filename: "where the compilable thing comes from",
>> mode: "is this a single statement or a suite?"
Paul Prescod wrote:
> 2. If not, will Python 3000's build or runtime system use some kind of
> optimization technique such as static compilation ( e.g. extcompiler[1])
> or JIT compilation to allow parts of its library (especially new parts)
> to be written using ctypes instead of C?
What's the
Hi,
Collin Winter wrote:
> def compile(source: "something compilable",
> filename: "where the compilable thing comes from",
> mode: "is this a single statement or a suite?"):
> ...
>
> def sum(*vargs: Number) -> Number:
>
Marcin 'Qrczak' Kowalczyk wrote:
> Stefan Behnel <[EMAIL PROTECTED]> writes:
>
>> It just says: I support the protocol, so it makes sense to apply the
>> protocol operations to me if you need to.
>>
>> I think that's perfectly reasonable semanti
Steven Bethard wrote:
> On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> So how about we change callable() and add hashable(), iterable() and
>>> whatever else makes sense so that these all become like this:
>>>
>>> def callable(x):
>>> return getattr(x, "__c
Collin Winter wrote:
> On 7/25/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
>>> With your CD example, you need an external resource (the CD itself) in
>>> order to calculate the hash - in that case, you can't safely defer
>>> the hash calculation until the first time you know you need it,
>>> sinc
Guido van Rossum wrote:
> def __iter__(self):
> for i in itertools.count():
> yield self[i]
Note that this likely raises IndexError, not StopIteration.
Stefan
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/lis
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> But I'm not proposing to use hasattr(obj, '__call__'). I'm basically
>> saying that the callable test has very little to do with whether the
>> later call will succeed, because we have no way to test the signature.
>
> I don't think that's needed
Hi,
Greg Ewing wrote:
> Andrew Koenig wrote:
>> I note in PEP 3000 the proposal to remove callable(), with the comment "just
>> call the object and catch the exception."
>
> I think that should be amended to "just use hasattr(obj. '__call__')
> instead". That's what callable() will become equival
62 matches
Mail list logo
