> (1) Why is PyObject_HEAD used instead of PyObject_VAR_HEAD? It is
> because of the names (.length vs .size), or a holdover from when
> unicode (as opposed to str) did not expect to be compact, or is there
> a deeper reason?
The unicode object is not a var object. In a var object, tp_itemsize
(see http://www.python.org/dev/peps/pep-0393/ and
http://hg.python.org/cpython/file/6f097ff9ac04/Include/unicodeobject.h
)
typedef struct {
PyObject_HEAD
Py_ssize_t length;
Py_hash_t hash;
struct {
unsigned int interned:2;
Hi,
I'm hoping to get some kind of consensus about the divergences between
the implementation and documentation of str.format
(http://mail.python.org/pipermail/python-dev/2011-June/111860.html and
the linked bug report contain examples of the divergences). These
pertain to the arg_name, attribute_
On Tue, Dec 13, 2011 at 12:50 AM, PJ Eby wrote:
> Unfortunately, AFAIR, nobody in the PEP discussions brought up either
> the unicode_literals import OR the strategy of using a common codebase, so
> 2to3 on plain code and writing new Python3 code were the only porting
> scenarios discussed.
IEEE/ISO are working on a draft document about Python vulunerabilities:
http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf
(in the context of a larger effort to classify vulnerabilities in all
languages: ISO/IEC TR 24772:2010, available from ISO at no cost a
The authors are definitely interested in feedback! Best probably to
post it to my G+ thread.
On Mon, Dec 12, 2011 at 1:44 PM, Eric Snow wrote:
> Guido posted this on Google+:
>
>> IEEE/ISO are working on a draft document about Python vulunerabilities:
>> http://grouper.ieee.org/groups/plv/DocLog
re-sending with subject :)
On Mon, Dec 12, 2011 at 2:44 PM, Eric Snow wrote:
> Guido posted this on Google+:
>
>> IEEE/ISO are working on a draft document about Python vulunerabilities:
>> http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf
>> (in the context
Guido posted this on Google+:
> IEEE/ISO are working on a draft document about Python vulunerabilities:
> http://grouper.ieee.org/groups/plv/DocLog/300-399/360-thru-379/22-WG23-N-0372/n0372.pdf
> (in the context of a larger effort to classify vulnerabilities in all
> languages: ISO/IEC TR 24772
On Mon, 2011-12-12 at 09:50 -0500, PJ Eby wrote:
> As someone who ported WebOb and other stuff built on top of it
> to Python
> 3 without using "from __future__ import unicode_literals", I'm
> kinda sad
> that to be using best practice I'll have to go back
On Mon, Dec 12, 2011 at 3:40 AM, Chris McDonough wrote:
> Truth be told, in the vast majority of WSGI apps only high-level WSGI
> libraries (like WebOb and Werkzeug) and standalone middleware really
> needs to work with native strings. And the middleware really should be
> using the high-level l
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:/
"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 shou
On Sun, Dec 11, 2011 at 11:45:06PM +0100, Antoine Pitrou wrote:
> On Sat, 10 Dec 2011 20:40:17 +0100
> lars.gustaebel wrote:
> >
> > The :mod:`tarfile` module makes it possible to read and write tar
> > -archives, including those using gzip or bz2 compression.
> > +archives, including those usi
"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
On Sat, 2011-12-10 at 15:55 +1000, Nick Coghlan wrote:
> So I'm back to being -1 on the idea of adding back u'' literals for
> 3.3. Instead, people should explicitly call str() on any literals that
> they want to be actual str instances both in 3.x and in 2.x when the
> unicode literals future imp
15 matches
Mail list logo
