Georg> Let's remove the cruft, and only keep interesting info. This
Georg> will also make the file much more manageable.
If I was to do this from scratch I'd think hard about annotating the source
code. No matter how hard you try, if you keep this information separate
from the code and
Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
This is not always true, for example when the item is already present
in the dict.
It's not important to know what the function does to the object,
Only the action on the reference is relevant.
Yes, that's the whole point
Le jeudi 05 mai 2011 à 18:54 -0400, Alexander Belopolsky a écrit :
> On Thu, May 5, 2011 at 6:32 PM, M.-A. Lemburg wrote:
> ..
> >> Either way, the code is simpler by just using the default.
> >
> > ... as long as the casual reader knows what the default it :-)
> >
>
> .. or cares. I this partic
On Thu, May 5, 2011 at 6:32 PM, M.-A. Lemburg wrote:
..
>> Either way, the code is simpler by just using the default.
>
> ... as long as the casual reader knows what the default it :-)
>
.. or cares. I this particular case, it hardly matters how random
bits are encoded.
_
On 5/5/2011 4:55 PM, Raymond Hettinger wrote:
Either way, the code is simpler by just using the default.
I thought about this and decided that the purpose of having defaults is
so one does not have to always spell it out. So use it. Readers can
always look it up and learn.
--
Terry Jan Ree
Raymond Hettinger wrote:
>
> On May 5, 2011, at 11:41 AM, Benjamin Peterson wrote:
>
>> 2011/5/5 raymond.hettinger :
>>> http://hg.python.org/cpython/rev/1a56775c6e54
>>> changeset: 69857:1a56775c6e54
>>> branch: 3.2
>>> parent: 69855:97a4855202b8
>>> user:Raymond Hettinger
>
On May 5, 2011, at 11:41 AM, Benjamin Peterson wrote:
> 2011/5/5 raymond.hettinger :
>> http://hg.python.org/cpython/rev/1a56775c6e54
>> changeset: 69857:1a56775c6e54
>> branch: 3.2
>> parent: 69855:97a4855202b8
>> user:Raymond Hettinger
>> date:Thu May 05 11:35:50 20
On 05.05.2011 19:17, Amaury Forgeot d'Arc wrote:
> 2011/5/5 Guido van Rossum :
>> Seems you're in agreement with this. IMO when references are borrowed
>> it is not very interesting. The interesting thing is when calling a
>> function *steals* a reference. The other important thing to know is
>> wh
2011/5/5 Alexander Belopolsky :
> On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou wrote:
> ..
>> (also, I don't understand the spelling issue: "utf-8" just works)
>
> This is probably referring to the fact that while encode() accepts
> many spelling variants, some are short-circuited in C code whil
Le jeudi 05 mai 2011 à 15:01 -0400, Alexander Belopolsky a écrit :
> On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou wrote:
> ..
> > (also, I don't understand the spelling issue: "utf-8" just works)
>
> This is probably referring to the fact that while encode() accepts
> many spelling variants, so
On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou wrote:
..
> (also, I don't understand the spelling issue: "utf-8" just works)
This is probably referring to the fact that while encode() accepts
many spelling variants, some are short-circuited in C code while
others require codec lookup implemented
On Thu, 05 May 2011 20:38:27 +0200
raymond.hettinger wrote:
> http://hg.python.org/cpython/rev/2bc784057226
> changeset: 69858:2bc784057226
> parent: 69856:b06ad8458b32
> parent: 69857:1a56775c6e54
> user:Raymond Hettinger
> date:Thu May 05 11:38:06 2011 -0700
> summar
2011/5/5 raymond.hettinger :
> http://hg.python.org/cpython/rev/1a56775c6e54
> changeset: 69857:1a56775c6e54
> branch: 3.2
> parent: 69855:97a4855202b8
> user: Raymond Hettinger
> date: Thu May 05 11:35:50 2011 -0700
> summary:
> Avoid codec spelling issues by just using
On May 5, 2011, at 10:18 AM, Guido van Rossum wrote:
> On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc
> wrote:
>> 2011/5/5 Guido van Rossum :
>>> Seems you're in agreement with this. IMO when references are borrowed
>>> it is not very interesting. The interesting thing is when calling a
>
On Thu, 5 May 2011 19:17:30 +0200
"Amaury Forgeot d'Arc" wrote:
> 2011/5/5 Guido van Rossum :
> > Seems you're in agreement with this. IMO when references are borrowed
> > it is not very interesting. The interesting thing is when calling a
> > function *steals* a reference. The other important th
On 05.05.2011 19:00, Guido van Rossum wrote:
> On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc
> wrote:
>> Hi,
>>
>> Le jeudi 5 mai 2011, Greg Ewing a écrit :
>>> Amaury Forgeot d'Arc wrote:
>>>
>>>
>>> It's in the file Doc/data/refcounts.dat
>>> in some custom format.
>>>
>>>
>>> However,
On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc
wrote:
> 2011/5/5 Guido van Rossum :
>> Seems you're in agreement with this. IMO when references are borrowed
>> it is not very interesting. The interesting thing is when calling a
>> function *steals* a reference. The other important thing to
2011/5/5 Guido van Rossum :
> Seems you're in agreement with this. IMO when references are borrowed
> it is not very interesting. The interesting thing is when calling a
> function *steals* a reference. The other important thing to know is
> whether the caller ends up owning the return value (if it
On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc wrote:
> Hi,
>
> Le jeudi 5 mai 2011, Greg Ewing a écrit :
>> Amaury Forgeot d'Arc wrote:
>>
>>
>> It's in the file Doc/data/refcounts.dat
>> in some custom format.
>>
>>
>> However, it doesn't seem to quite convey the same information.
>> It l
>> 2011/4/29 Roy Hyunjin Han :
>> It would be convenient if replacing items in a dictionary returns the
>> new dictionary, in a manner analogous to str.replace(). What do you
>> think?
>>
>># Current behavior
>>x = {'key1': 1}
>>x.update(key1=3) == None
>>x == {'key1': 3} # Origina
Victor Stinner wrote:
Le jeudi 05 mai 2011 à 05:07 -0700, Ethan Furman a écrit :
>>
... hence the resulting file is one less than 2GB.
Yep, it's 0x7FFF because it's INT_MAX, the biggest value storable in
an int. The zlib module stores the buffer size into an int in Python 2.7
(and Py_ssiz
Le jeudi 05 mai 2011 à 05:07 -0700, Ethan Furman a écrit :
> ... hence the resulting file is one less than 2GB.
Yep, it's 0x7FFF because it's INT_MAX, the biggest value storable in
an int. The zlib module stores the buffer size into an int in Python 2.7
(and Py_ssize_t in Python 3.3).
Victor
Victor Stinner wrote:
Le mercredi 04 mai 2011 à 15:40 -0700, Ethan Furman a écrit :
Victor Stinner wrote:
Le mardi 03 mai 2011 à 16:22 +0200, Nadeem Vawda a écrit :
On Tue, May 3, 2011 at 3:19 PM, victor.stinner
wrote:
+int_max = 0x7FFF
+with open(TESTFN, "wb+") as f:
+
Hi,
Le jeudi 5 mai 2011, Greg Ewing a écrit :
> Amaury Forgeot d'Arc wrote:
>
>
> It's in the file Doc/data/refcounts.dat
> in some custom format.
>
>
> However, it doesn't seem to quite convey the same information.
> It lists the "refcount effect" on each parameter, but translating
> that into t
On Fri, Apr 29, 2011 at 4:05 PM, Roy Hyunjin Han
wrote:
>> You can implement this in your own subclass of dict, no?
>
> Yes, I just thought it would be convenient to have in the language
> itself, but the responses to my post seem to indicate that [not
> returning the updated object] is an inten
On 5 May 2011 10:33, Victor Stinner wrote:
> If you write a byte after 2 GB of zeros, the file size is 2 GB+the few
> bytes. This trick is to create quickly a large file: some OSes support
> sparse files, zeros are not written on disk. But on Mac OS X and
> Windows, you really write 2 GB+some byte
On Thu, May 5, 2011 at 11:33 AM, Victor Stinner
wrote:
> Le mercredi 04 mai 2011 à 15:40 -0700, Ethan Furman a écrit :
>> The comment says 'check that inputs of 2 GB are handled correctly' but
>> the file created is 1 byte short of 2Gb. Is the test wrong, or just
>> wrongly commented? Or am I no
Le mercredi 04 mai 2011 à 15:40 -0700, Ethan Furman a écrit :
> Victor Stinner wrote:
> > Le mardi 03 mai 2011 à 16:22 +0200, Nadeem Vawda a écrit :
> >> On Tue, May 3, 2011 at 3:19 PM, victor.stinner
> >> wrote:
> >>> +# Issue #10276 - check that inputs of 2 GB are handled correctly.
> >>> +# Be
28 matches
Mail list logo
