On Sun, Jan 23, 2011 at 03:08, Brett Cannon wrote:
> http://docs.python.org/devguide/
>
> If you are a core developer and have a correction you want to make you
> can simply check out the devguide yourself (link is in the Resources
> section of the devguide) and make the corrections yourself. Othe
"Martin v. Löwis", 28.01.2011 01:02:
Am 27.01.2011 23:53, schrieb Stefan Behnel:
"Martin v. Löwis", 24.01.2011 21:17:
If the string is created directly with the canonical representation
(see below), this representation doesn't take a separate memory block,
but is allocated right after the PyUni
I'm working on improving the .rst documentation of test.support (Issue
11015), and came upon the undocumented "fcmp" function that's being
exported from test.support, along with a "FUZZ"constant.
As I search through the tests (py3k trunk), I see fcmp() is being used
only in two places in a fairly
Am 27.01.2011 23:53, schrieb Stefan Behnel:
> "Martin v. Löwis", 24.01.2011 21:17:
>> If the string is created directly with the canonical representation
>> (see below), this representation doesn't take a separate memory block,
>> but is allocated right after the PyUnicodeObject struct.
>
> Does t
> Works for me! Short and elegant.
Done!
http://www.python.org/2.6.x
http://www.python.org/2.x
http://www.python.org/3.1.x
http://www.python.org/3.x
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
"Martin v. Löwis", 24.01.2011 21:17:
If the string is created directly with the canonical representation
(see below), this representation doesn't take a separate memory block,
but is allocated right after the PyUnicodeObject struct.
Does this mean it's supposed to become a PyVarObject? Antoine
On Thu, Jan 27, 2011 at 5:40 PM, "Martin v. Löwis" wrote:
>> Whatever we do, let's use this opportunity to unify redirect rules
>> for http://www.python.org/X.Y and http://docs.python.org/X.Y. For a
>> related discussion, see http://bugs.python.org/issue10446.
>
> TLDR; somebody should summarize
> Whatever we do, let's use this opportunity to unify redirect rules
> for http://www.python.org/X.Y and http://docs.python.org/X.Y. For a
> related discussion, see http://bugs.python.org/issue10446.
TLDR; somebody should summarize it and specify what exactly needs to
be changed.
I'm only going
> > Incidentally, to slightly reduce the overhead the unicode objects,
> > there's this proposal: http://bugs.python.org/issue1943
>
> I wonder what aspects of this patch and discussion should be integrated
> into the PEP. The notion of allocating the memory in the same block is
> already conside
On Thu, Jan 27, 2011 at 4:54 PM, "Martin v. Löwis" wrote:
..
> How about http://www.python.org/2.7.x redirecting to the latest 2.7.x
> release? Likewise 2.x and 3.x.
Whatever we do, let's use this opportunity to unify redirect rules
for http://www.python.org/X.Y and http://docs.python.org/X.Y.
On Thu, Jan 27, 2011 at 13:54, "Martin v. Löwis" wrote:
> Am 27.01.2011 21:38, schrieb Brett Cannon:
>> Because of all the writing I have been doing lately, I have been
>> pulling up a lot of URLs pointing to various Python releases based
>> around minor versions (e.g., Python 2.7, not specificall
BTW, has anyone looked at what other languages with a native unicode
type do for their implementations if any of them attempt to conserve
ram?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
> I agree. After all, CPython is lucky to have it available. It wouldn't
> be the first time that we duplicate looping code based on the input
> type. However, like the looping code, it will also complicate all
> indexing code at runtime as it always needs to test which of the
> representations is
On Thu, Jan 27, 2011 at 13:21, wrote:
> Brett> Bonus points if we extend this to major versions, too. =)
>
> I know you added a smiley, but just wanted to point out that since Python 2
> and 3 are really different languages, referring 2.4 users to 3.3 might be a
> bad idea. (I imagine it woul
Am 27.01.2011 21:38, schrieb Brett Cannon:
> Because of all the writing I have been doing lately, I have been
> pulling up a lot of URLs pointing to various Python releases based
> around minor versions (e.g., Python 2.7, not specifically 2.7.1). What
> has been somewhat annoying is that there are
Am 27.01.2011 20:06, schrieb Stefan Behnel:
> "Martin v. Löwis", 24.01.2011 21:17:
>> The Py_UNICODE type is still supported but deprecated. It is always
>> defined as a typedef for wchar_t, so the wstr representation can double
>> as Py_UNICODE representation.
>
> It's too bad this isn't initiali
>>From my first impression, I'm
> not too thrilled by the prospect of making the Unicode implementation
> more complicated by having three different representations on each
> object.
Thanks, added as a concern.
> I also don't see how this could save a lot of memory. As an example
> take a French
Am 25.01.2011 12:08, schrieb Nick Coghlan:
> On Tue, Jan 25, 2011 at 6:17 AM, "Martin v. Löwis" wrote:
>> A new function PyUnicode_AsUTF8 is provided to access the UTF-8
>> representation. It is thus identical to the existing
>> _PyUnicode_AsString, which is removed. The function will compute the
James Y Knight, 27.01.2011 21:26:
On Jan 27, 2011, at 2:06 PM, Stefan Behnel wrote:
"Martin v. Löwis", 24.01.2011 21:17:
The Py_UNICODE type is still supported but deprecated. It is always
defined as a typedef for wchar_t, so the wstr representation can
double as Py_UNICODE representation.
It
Brett> Bonus points if we extend this to major versions, too. =)
I know you added a smiley, but just wanted to point out that since Python 2
and 3 are really different languages, referring 2.4 users to 3.3 might be a
bad idea. (I imagine it wouldn't be hard to generalize from micro to minor
t
On Thu, Jan 27, 2011 at 3:38 PM, Brett Cannon wrote:
> Linking to the 2.7.0 release page seems off since it is
> out of date, but linking to 2.7.1 also seems silly as that will become
> out of date as the newest release of Python 2.7 at some point as well.
I'd love to see something like this as w
> Repetition of "11"; I'm guessing that the 2byte/UCS-2 should read "10",
> so that they give the width of the char representation.
Thanks, fixed.
>> 00 => null pointer
>
> Naturally this assumes that all pointers are at least 4-byte aligned (so
> that they can be masked off). I assume that t
On 1/27/2011 12:26 PM, James Y Knight wrote:
On Jan 27, 2011, at 2:06 PM, Stefan Behnel wrote:
"Martin v. Löwis", 24.01.2011 21:17:
The Py_UNICODE type is still supported but deprecated. It is always
defined as a typedef for wchar_t, so the wstr representation can double
as Py_UNICODE represent
> I believe the intent this pep is aiming at is for the existing in
> memory structure to be compatible with already compiled binary
> extension modules without having to recompile them or change the APIs
> they are using.
No, binary compatibility is not achieved. ABI-conforming modules will
conti
> So, the only criticism I have, intuitively, is that the unicode
> structure seems to become a bit too large. For example, I'm not sure you
> need a generic (pointer, size) pair in addition to the
> representation-specific ones.
It's not really a generic pointer, but rather a variable-sized point
Because of all the writing I have been doing lately, I have been
pulling up a lot of URLs pointing to various Python releases based
around minor versions (e.g., Python 2.7, not specifically 2.7.1). What
has been somewhat annoying is that there are no URLs which act as a
redirect to the latest relea
On Jan 27, 2011, at 2:06 PM, Stefan Behnel wrote:
> "Martin v. Löwis", 24.01.2011 21:17:
>> The Py_UNICODE type is still supported but deprecated. It is always
>> defined as a typedef for wchar_t, so the wstr representation can double
>> as Py_UNICODE representation.
>
> It's too bad this isn't in
>When switching to a UTF-8 locale, they can also change the file
> names of their modules to be encoded in UTF-8. It would be fairly easy
> to write a script that identifies non-ASCII file names in a directory
> and offers to transcode their names from their current encoding to
> UTF-8.
In fac
"Martin v. Löwis", 24.01.2011 21:17:
The Py_UNICODE type is still supported but deprecated. It is always
defined as a typedef for wchar_t, so the wstr representation can double
as Py_UNICODE representation.
It's too bad this isn't initialised by default, though. Py_UNICODE is the
only represen
2011/1/27 Łukasz Langa :
>
> W dniu 2011-01-24 23:13, Benjamin Peterson pisze:
>>
>> I prefer lib2to3 tests to stay in lib2to3/.
>
> On a related note, I had trouble myself with using outdated 2to3 and
> heard complaints about that at least a couple of times. What do we gain
> from bundling 2to3 w
Le mercredi 26 janvier 2011 à 21:50 -0800, Gregory P. Smith a écrit :
> >
> > Incidentally, to slightly reduce the overhead the unicode objects,
> > there's this proposal: http://bugs.python.org/issue1943
>
> Interesting. But that aims more at cpu performance than memory
> overhead. What I see i
W dniu 2011-01-24 23:13, Benjamin Peterson pisze:
I prefer lib2to3 tests to stay in lib2to3/.
On a related note, I had trouble myself with using outdated 2to3 and
heard complaints about that at least a couple of times. What do we gain
from bundling 2to3 with Python?
--
Best regards,
Łukasz L
32 matches
Mail list logo
