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
python-check...@python.org wrote:
+# Issue #10276 - check that inputs of 2 GB are handled
On Thu, May 5, 2011 at 11:33 AM, Victor Stinner
victor.stin...@haypocalc.com 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
On 5 May 2011 10:33, Victor Stinner victor.stin...@haypocalc.com 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
On Fri, Apr 29, 2011 at 4:05 PM, Roy Hyunjin Han
starsareblueandfara...@gmail.com 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
Hi,
Le jeudi 5 mai 2011, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
python-check...@python.org wrote:
+int_max = 0x7FFF
+with
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 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
2011/4/29 Roy Hyunjin Han starsareblueandfara...@gmail.com:
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 ==
On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc amaur...@gmail.com wrote:
Hi,
Le jeudi 5 mai 2011, Greg Ewing greg.ew...@canterbury.ac.nz 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
2011/5/5 Guido van Rossum gu...@python.org:
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
On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2011/5/5 Guido van Rossum gu...@python.org:
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.
On 05.05.2011 19:00, Guido van Rossum wrote:
On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc amaur...@gmail.com
wrote:
Hi,
Le jeudi 5 mai 2011, Greg Ewing greg.ew...@canterbury.ac.nz a écrit :
Amaury Forgeot d'Arc wrote:
It's in the file Doc/data/refcounts.dat
in some custom
On Thu, 5 May 2011 19:17:30 +0200
Amaury Forgeot d'Arc amaur...@gmail.com wrote:
2011/5/5 Guido van Rossum gu...@python.org:
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
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
amaur...@gmail.com wrote:
2011/5/5 Guido van Rossum gu...@python.org:
Seems you're in agreement with this. IMO when references are borrowed
it is not very interesting. The interesting
2011/5/5 raymond.hettinger python-check...@python.org:
http://hg.python.org/cpython/rev/1a56775c6e54
changeset: 69857:1a56775c6e54
branch: 3.2
parent: 69855:97a4855202b8
user: Raymond Hettinger pyt...@rcn.com
date: Thu May 05 11:35:50 2011 -0700
summary:
Avoid
On Thu, 05 May 2011 20:38:27 +0200
raymond.hettinger python-check...@python.org wrote:
http://hg.python.org/cpython/rev/2bc784057226
changeset: 69858:2bc784057226
parent: 69856:b06ad8458b32
parent: 69857:1a56775c6e54
user:Raymond Hettinger pyt...@rcn.com
date:Thu
On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou solip...@pitrou.net 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
Le jeudi 05 mai 2011 à 15:01 -0400, Alexander Belopolsky a écrit :
On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou solip...@pitrou.net 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
2011/5/5 Alexander Belopolsky alexander.belopol...@gmail.com:
On Thu, May 5, 2011 at 2:44 PM, Antoine Pitrou solip...@pitrou.net 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
On 05.05.2011 19:17, Amaury Forgeot d'Arc wrote:
2011/5/5 Guido van Rossum gu...@python.org:
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
On May 5, 2011, at 11:41 AM, Benjamin Peterson wrote:
2011/5/5 raymond.hettinger python-check...@python.org:
http://hg.python.org/cpython/rev/1a56775c6e54
changeset: 69857:1a56775c6e54
branch: 3.2
parent: 69855:97a4855202b8
user:Raymond Hettinger pyt...@rcn.com
date:
Raymond Hettinger wrote:
On May 5, 2011, at 11:41 AM, Benjamin Peterson wrote:
2011/5/5 raymond.hettinger python-check...@python.org:
http://hg.python.org/cpython/rev/1a56775c6e54
changeset: 69857:1a56775c6e54
branch: 3.2
parent: 69855:97a4855202b8
user:Raymond
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
On Thu, May 5, 2011 at 6:32 PM, M.-A. Lemburg m...@egenix.com 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.
Le jeudi 05 mai 2011 à 18:54 -0400, Alexander Belopolsky a écrit :
On Thu, May 5, 2011 at 6:32 PM, M.-A. Lemburg m...@egenix.com 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
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
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
28 matches
Mail list logo
