James Y Knight wrote:
On Dec 3, 2010, at 10:50 PM, Terry Reedy wrote:
On 12/3/2010 7:46 PM, James Y Knight wrote:
Sure they are. This is what Java provides you, for example. If you
have fixed, but potentially non-unique ids (in Java you get this
using "identityHashCode()"), you can still make
On Sat, Dec 4, 2010 at 6:34 AM, James Y Knight wrote:
> On Dec 3, 2010, at 10:50 PM, Terry Reedy wrote:
>> On 12/3/2010 7:46 PM, James Y Knight wrote:
>>
>>> Sure they are. This is what Java provides you, for example. If you
>>> have fixed, but potentially non-unique ids (in Java you get this
>>>
On 3 December 2010 16:45, "Martin v. Löwis" wrote:
>> Oh my bad, I must've confused python with some research paper.
>> Unique id is not so hard to make without an address.
>>
>> While on this topic, what is the real need for unique ids?
>
> They are absolutely needed for mutable objects. For immu
On 12/3/2010 11:06 PM, Cameron Simpson wrote:
On 03Dec2010 18:15, James Y Knight wrote:
| On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote:
|> gc is implementation specific. CPython uses ref counting + cycle
|> gc. A constraint on all implementations is that objects have a fixed,
|> unique id du
On Dec 3, 2010, at 10:50 PM, Terry Reedy wrote:
> On 12/3/2010 7:46 PM, James Y Knight wrote:
>
>> Sure they are. This is what Java provides you, for example. If you
>> have fixed, but potentially non-unique ids (in Java you get this
>> using "identityHashCode()"), you can still make an identity
>
On 03Dec2010 18:15, James Y Knight wrote:
| On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote:
| > gc is implementation specific. CPython uses ref counting + cycle
| > gc. A constraint on all implementations is that objects have a fixed,
| > unique id during their lifetime. CPython uses the address as
On 12/3/2010 7:46 PM, James Y Knight wrote:
Sure they are. This is what Java provides you, for example. If you
have fixed, but potentially non-unique ids (in Java you get this
using "identityHashCode()"), you can still make an identity
I do not see the point of calling a (non-unique) hash valu
On Dec 3, 2010, at 7:05 PM, Terry Reedy wrote:
> I left out that the id must be an int.
>
>> It's somewhat unfortuante that python has this constraint, instead of
>> the looser: "objects have a fixed id during their lifetime", which is
>> much easier to implement, and practically as useful.
>
> G
Am 04.12.2010 01:00, schrieb Terry Reedy:
> On 12/3/2010 6:46 PM, "Martin v. Löwis" wrote:
>
>>> and stable as D1. I do not know what Martin means by 'integrate' (other
>>> than that he be able to use it to build Python)
>>
>> That the master copy of the source code is in the Python source
>> repo
On 12/3/2010 6:15 PM, James Y Knight wrote:
On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote:
gc is implementation specific. CPython uses ref counting + cycle
gc. A constraint on all implementations is that objects have a
fixed, unique id during their lifetime. CPython uses the address as
the id, s
On 12/3/2010 6:46 PM, "Martin v. Löwis" wrote:
and stable as D1. I do not know what Martin means by 'integrate' (other
than that he be able to use it to build Python)
That the master copy of the source code is in the Python source repository.
Is a separate branch acceptible, as long as you c
Am 04.12.2010 00:35, schrieb Terry Reedy:
> On 12/3/2010 5:52 PM, "Martin v. Löwis" wrote:
>> Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
>>> You can’
> Oh my bad, I must've confused python with some research paper.
> Unique id is not so hard to make without an address.
>
> While on this topic, what is the real need for unique ids?
They are absolutely needed for mutable objects. For immutable ones,
it would be ok to claim that they are identica
On 12/3/2010 5:52 PM, "Martin v. Löwis" wrote:
Am 03.12.2010 23:48, schrieb Éric Araujo:
But I'm not interested at all in having it in distutils2. I want the
Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in 3.1, or any previous
> q1 are generations placed in separate memory regions, or are all
> generations in one memory regions and there is a pointer that
> signifies the boundary between generations?
You should really start reading the source code. See Modules/gcmodule.c.
To answer your question: neither, nor. All obje
Oh my bad, I must've confused python with some research paper.
Unique id is not so hard to make without an address.
While on this topic, what is the real need for unique ids?
Also I reckon not all objects need a unique id like this, e.g.
interned strings, simple data types and hashable and compara
Am 03.12.2010 23:55, schrieb Dima Tisnek:
> How hard or reasonable would it be to free memory pages on OS level?
Very easy. Python already does that.
> [pcmiiw] Gabage collection within a generation involves moving live
> objects to compact the generation storage. This separates the memory
> regi
On Dec 3, 2010, at 6:04 PM, Terry Reedy wrote:
> gc is implementation specific. CPython uses ref counting + cycle gc. A
> constraint on all implementations is that objects have a fixed, unique id
> during their lifetime. CPython uses the address as the id, so it cannot move
> objects. Other impl
Python organizes objects into 3 generations, ephemeral, short- and long-lived.
When object is created it is place in ephemeral, if it lives long
enough, it is move to short-lived and so on.
q1 are generations placed in separate memory regions, or are all
generations in one memory regions and ther
On Dec 3, 2010, at 5:52 PM, Martin v. Löwis wrote:
> Am 03.12.2010 23:48, schrieb Éric Araujo:
>>> But I'm not interested at all in having it in distutils2. I want the
>>> Python build itself to use it, and alas, I can't because of the freeze.
>> You can’t in 3.2, true. Neither can you in 3.1, or
Wiadomość napisana przez Éric Araujo w dniu 2010-12-03, o godz. 19:35:
> Hello,
>
>> Author: lukasz.langa
>> New Revision: 86976
>> Log: Issue 10499: Modular interpolation in configparser
>>
>> Modified: python/branches/py3k/Doc/library/configparser.rst
> Is the module still backward compatible
On 12/3/2010 5:55 PM, Dima Tisnek wrote:
How hard or reasonable would it be to free memory pages on OS level?
[pcmiiw] Gabage collection within a generation involves moving live
objects to compact the generation storage. This separates the memory
region into 2 parts "live" and "cleared", the poi
How hard or reasonable would it be to free memory pages on OS level?
[pcmiiw] Gabage collection within a generation involves moving live
objects to compact the generation storage. This separates the memory
region into 2 parts "live" and "cleared", the pointer to the beginning
of the "cleared" part
Am 03.12.2010 23:48, schrieb Éric Araujo:
>> But I'm not interested at all in having it in distutils2. I want the
>> Python build itself to use it, and alas, I can't because of the freeze.
> You can’t in 3.2, true. Neither can you in 3.1, or any previous
> version. If you implement it in distutil
> But I'm not interested at all in having it in distutils2. I want the
> Python build itself to use it, and alas, I can't because of the freeze.
You can’t in 3.2, true. Neither can you in 3.1, or any previous
version. If you implement it in distutils2, you have very good chances
to get it for 3.3
>> For example, I keep running into the issue that distutils doesn't
>> currently support parallel builds. I have been pondering supporting
>> "-j" for building extensions, using both unbounded "-j" and the GNU make
>> style -jN build server. However, I know that the patch will be rejected,
>> so I
I just want to say thanks for doing this, Michael. __main__.py is IMO
woefully underused and it's great to see Python dogfooding the feature
along with making it easier to explain how to run our unit tests.
On Thu, Dec 2, 2010 at 17:34, michael.foord wrote:
> Author: michael.foord
> Date: Fri Dec
On Fri, Dec 3, 2010 at 4:16 AM, Victor Stinner
wrote:
..
> I don't like transform() and untransform() because I think that we should not
> add too much operations to the base types (bytes and str), and they do
> implicit module import. I prefer explicit module import (eg. import binascii;
> binasc
On 12/3/10, Éric Araujo wrote:
> Hi Prashant,
>
> Python 3 support in distutils2 is not entirely finished, it’s an
> interesting and challenging task.
>
> Another idea: convert the python.org internal scripts to use Python 3,
> for example starting with patches for http://code.python.org/hg/peps/
On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray wrote:
> On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
> wrote:
>> On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray
>> wrote:
>> ..
>> > Please also recall that transform/untransform was discussed before
>> > the release of Python 3.0
On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
wrote:
> On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray
> wrote:
> ..
> > Please also recall that transform/untransform was discussed before
> > the release of Python 3.0 and was approved at the time, but it just
> > did not get impleme
Am 03.12.2010 18:29, schrieb Antoine Pitrou:
> On Fri, 03 Dec 2010 18:09:39 +0100
> Georg Brandl wrote:
>> Am 03.12.2010 17:57, schrieb Antoine Pitrou:
>> > On Sat, 4 Dec 2010 02:45:42 +1000
>> > Nick Coghlan wrote:
>> >> On Sat, Dec 4, 2010 at 2:28 AM, Antoine Pitrou
>> >> wrote:
>> >> > On Fr
On Fri, 03 Dec 2010 18:09:39 +0100
Georg Brandl wrote:
> Am 03.12.2010 17:57, schrieb Antoine Pitrou:
> > On Sat, 4 Dec 2010 02:45:42 +1000
> > Nick Coghlan wrote:
> >> On Sat, Dec 4, 2010 at 2:28 AM, Antoine Pitrou wrote:
> >> > On Fri, 03 Dec 2010 10:11:29 -0500
> >> > "R. David Murray" wrote
Am 03.12.2010 17:57, schrieb Antoine Pitrou:
> On Sat, 4 Dec 2010 02:45:42 +1000
> Nick Coghlan wrote:
>> On Sat, Dec 4, 2010 at 2:28 AM, Antoine Pitrou wrote:
>> > On Fri, 03 Dec 2010 10:11:29 -0500
>> > "R. David Murray" wrote:
>> >> >
>> >> > >>> 'abc'.transform('hex')
>> >> > TypeError: 'str
ACTIVITY SUMMARY (2010-11-26 - 2010-12-03)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2537 ( +4)
closed 19861 (+69)
total 22398 (+73)
Open issues wit
On Sat, Dec 4, 2010 at 2:57 AM, Antoine Pitrou wrote:
> On Sat, 4 Dec 2010 02:45:42 +1000
> Nick Coghlan wrote:
>> On Sat, Dec 4, 2010 at 2:28 AM, Antoine Pitrou wrote:
>> > On Fri, 03 Dec 2010 10:11:29 -0500
>> > "R. David Murray" wrote:
>> >> >
>> >> > >>> 'abc'.transform('hex')
>> >> > TypeE
On Sat, 4 Dec 2010 02:45:42 +1000
Nick Coghlan wrote:
> On Sat, Dec 4, 2010 at 2:28 AM, Antoine Pitrou wrote:
> > On Fri, 03 Dec 2010 10:11:29 -0500
> > "R. David Murray" wrote:
> >> >
> >> > >>> 'abc'.transform('hex')
> >> > TypeError: 'str' does not support the buffer interface
> >> > >>> b'ab
On Sat, Dec 4, 2010 at 2:28 AM, Antoine Pitrou wrote:
> On Fri, 03 Dec 2010 10:11:29 -0500
> "R. David Murray" wrote:
>> >
>> > >>> 'abc'.transform('hex')
>> > TypeError: 'str' does not support the buffer interface
>> > >>> b'abc'.transform('rot13')
>> > TypeError: expected an object with the buf
On Friday 03 December 2010 16:11:29 R. David Murray wrote:
> > >>> 'abc'.transform('hex')
> > TypeError: 'str' does not support the buffer interface
> >
> > >>> b'abc'.transform('rot13')
> > TypeError: expected an object with the buffer interface
>
> I find these 'buffer interface' error messages
On Sat, Dec 4, 2010 at 12:00 AM, Antoine Pitrou wrote:
> On Fri, 3 Dec 2010 10:29:12 +0100 (CET)
> nick.coghlan wrote:
>> Author: nick.coghlan
>> Date: Fri Dec 3 10:29:11 2010
>> New Revision: 86962
>>
>> Log:
>> Improve Pydoc interactive browsing (#2001). Patch by Ron Adam.
>
> Tests seem to
On Fri, 03 Dec 2010 10:11:29 -0500
"R. David Murray" wrote:
> >
> > >>> 'abc'.transform('hex')
> > TypeError: 'str' does not support the buffer interface
> > >>> b'abc'.transform('rot13')
> > TypeError: expected an object with the buffer interface
>
> I find these 'buffer interface' error messag
On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray wrote:
..
> Please also recall that transform/untransform was discussed before
> the release of Python 3.0 and was approved at the time, but it just
> did not get implemented before the 3.0 release.
>
Can you provide a link? My search for transfor
On Fri, 03 Dec 2010 10:16:04 +0100, Victor Stinner
wrote:
> On Thursday 02 December 2010 19:06:51 georg.brandl wrote:
> > Author: georg.brandl
> > Date: Thu Dec 2 19:06:51 2010
> > New Revision: 86934
> >
> > Log:
> > #7475: add (un)transform method to bytes/bytearray and str, add back codecs
>
On Fri, 3 Dec 2010 10:29:12 +0100 (CET)
nick.coghlan wrote:
> Author: nick.coghlan
> Date: Fri Dec 3 10:29:11 2010
> New Revision: 86962
>
> Log:
> Improve Pydoc interactive browsing (#2001). Patch by Ron Adam.
Tests seem to fail under Windows:
===
Le vendredi 03 décembre 2010 à 13:58 +0900, Stephen J. Turnbull a
écrit :
> Antoine Pitrou writes:
>
> > The legacy format argument looks like a red herring to me. When
> > converting from a format to another it is the programmer's job to
> > his/her job right.
>
> Uhmm, the argument *for*
Le 03/12/2010 08:31, Martin v. Löwis a écrit :
>> I wonder what your definition of “unmaintained” is.
> In this specific case: doesn't get feature requests acted upon.
Thanks for clarifying. I think that’s a stretch, but I see your meaning
now.
>> Sure, distutils is not as well-maintained as oth
On 03/12/2010 10:53, Nick Coghlan wrote:
On Fri, Dec 3, 2010 at 8:42 PM, michael.foord
wrote:
+# When tests are run from the Python build directory, it is best practice
+# to keep the test files in a subfolder. It eases the cleanup of leftover
+# files using command "make distclean".
+if sysc
On Fri, Dec 3, 2010 at 8:42 PM, michael.foord
wrote:
> +# When tests are run from the Python build directory, it is best practice
> +# to keep the test files in a subfolder. It eases the cleanup of leftover
> +# files using command "make distclean".
> +if sysconfig.is_python_build():
> + TEMPD
Alexander Belopolsky wrote:
> On Thu, Dec 2, 2010 at 5:58 PM, M.-A. Lemburg wrote:
> ..
>>> I will change my mind on this issue when you present a
>>> machine-readable file with Arabic-Indic numerals and a program capable
>>> of reading it and show that this program uses the same number parsing
>>
Stephen J. Turnbull:
> Will it accept Arabic on input? (Han might be too much to ask for
> since Unicode considers Han digits to be "impure".)
I couldn't find a direct way to input Arabic digits into OO Calc,
the normal use of Alt+number didn't work in Calc although it did in
WordPad where Al
On Thursday 02 December 2010 19:06:51 georg.brandl wrote:
> Author: georg.brandl
> Date: Thu Dec 2 19:06:51 2010
> New Revision: 86934
>
> Log:
> #7475: add (un)transform method to bytes/bytearray and str, add back codecs
> that can be used with them from Python 2.
Oh no, someone did it. Was it
51 matches
Mail list logo
