Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
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 aware of issues #1202, #8650, #8651 and #10276 > >>> +class ChecksumBigBufferTestCase(unittest.TestCase): > >>> +int_max = 0x7FFF > >>> + > >>> [email protected](mmap, "mmap() is not available.") > >>> +def test_big_buffer(self): > >>> +if sys.platform[:3] == 'win' or sys.platform == 'darwin': > >>> +requires('largefile', > >>> + 'test requires %s bytes and a long time to run' % > >>> + str(self.int_max)) > >>> +try: > >>> +with open(TESTFN, "wb+") as f: > >>> +f.seek(self.int_max-4) > >>> +f.write("asdf") > >>> +f.flush() > >>> +try: > >>> +m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) > >>> +self.assertEqual(zlib.crc32(m), 0x709418e7) > >>> +self.assertEqual(zlib.adler32(m), -2072837729) > >>> +finally: > >>> +m.close() > >>> +except (IOError, OverflowError): > >>> +raise unittest.SkipTest("filesystem doesn't have largefile > >>> support") > >>> +finally: > >>> +unlink(TESTFN) > >>> + > >>> + > >> 0x7FFF is (2G-1) bytes. For a 2GB buffer, int_max should be > >> 0x8000. However, if you make this change, crc32() and adler32() > >> raise OverflowErrors (see changeset a0681e7a6ded). > > > > I don't want to check OverflowError: the test is supposed to compute the > > checksum of a buffer of 0x7FFF bytes > > 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 not understanding? 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 bytes. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
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 not understanding? > > 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 bytes. Ethan's point is that 0x7FFF is not 2GB - it is (2G-1) bytes. So the test and the preceding comment are inconsistent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
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 bytes. FWIW, on Windows you can create sparse files, using DeviceIoControl(FILE_SET_SPARSE). It's probably too messy to be worth it for this case, though... Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What if replacing items in a dictionary returns the new dictionary?
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 intended language feature for
> mutable types like dict or list.
In general nothing stops you to use a proxy object that returns itself
after each method call, something like
class using(object):
def __init__(self, obj):
self._wrappee = obj
def unwrap(self):
return self._wrappee
def __getattr__(self, attr):
def wrapper(*args, **kwargs):
getattr(self._wrappee, attr)(*args, **kwargs)
return self
return wrapper
d = dict()
print using(d).update(dict(a=1)).update(dict(b=2)).unwrap()
# prints {'a': 1, 'b': 2}
l = list()
print using(l).append(1).append(2).unwrap()
# prints [1, 2]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 the notion of borrowed or stolen references seems > to require knowledge of what the function does. > > For example, PyDict_SetItem has: > > PyDict_SetItem:PyObject*:p:0: > PyDict_SetItem:PyObject*:key:+1: > PyDict_SetItem:PyObject*:val:+1: > > All of these parameters take borrowed references, but the > key and val get incremented because they're being stored > in the dict. 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. > > So this file appears to be of limited usefulness. -- Amaury -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
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:
+f.seek(self.int_max-4)
+f.write("asdf")
+f.flush()
0x7FFF is (2G-1) bytes. For a 2GB buffer, int_max should be
0x8000. However, if you make this change, crc32() and adler32()
raise OverflowErrors (see changeset a0681e7a6ded).
>>>
I don't want to check OverflowError: the test is supposed to compute the
checksum of a buffer of 0x7FFF bytes
>>
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 not understanding?
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 bytes.
True, but that's not what's happening -- four bytes are being written at
int_max - 4, and int_max is one less that 2GB; hence the resulting file
is one less than 2GB.
~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
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_ssize_t in Python 3.3). So we are agreed that the file is not, in fact, 2GB in size... > On Tue, May 3, 2011 at 3:19 PM, victor.stinner > wrote: >> +# Issue #10276 - check that inputs of 2 GB are handled correctly. >> +# Be aware of issues #1202, #8650, #8651 and #10276 So why do the comments say we are testing a 2GB input? ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What if replacing items in a dictionary returns the new dictionary?
>> 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} # Original variable has changed
>>
>># Possible behavior
>>x = {'key1': 1}
>>x.replace(key1=3) == {'key1': 3}
>>x == {'key1': 1} # Original variable is unchanged
>>
> 2011/5/5 Giuseppe Ottaviano :
> In general nothing stops you to use a proxy object that returns itself
> after each method call, something like
>
> class using(object):
>def __init__(self, obj):
>self._wrappee = obj
>
>def unwrap(self):
>return self._wrappee
>
>def __getattr__(self, attr):
>def wrapper(*args, **kwargs):
>getattr(self._wrappee, attr)(*args, **kwargs)
>return self
>return wrapper
>
>
> d = dict()
> print using(d).update(dict(a=1)).update(dict(b=2)).unwrap()
> # prints {'a': 1, 'b': 2}
> l = list()
> print using(l).append(1).append(2).unwrap()
> # prints [1, 2]
Cool! I never thought of that. That's a great snippet.
I'll forward this to the python-ideas list. I don't think the
python-dev people want this discussion to continue on their mailing
list.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 lists the "refcount effect" on each parameter, but translating >> that into the notion of borrowed or stolen references seems >> to require knowledge of what the function does. >> >> For example, PyDict_SetItem has: >> >> PyDict_SetItem:PyObject*:p:0: >> PyDict_SetItem:PyObject*:key:+1: >> PyDict_SetItem:PyObject*:val:+1: >> >> All of these parameters take borrowed references, but the >> key and val get incremented because they're being stored >> in the dict. > > 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. > >> >> So this file appears to be of limited usefulness. 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 is an object) or not. I *think* you can tell the latter from the +1 for the return value; but the former (whether it steals a reference) is unclear from the data given. There's even an XXX comment about this in the file: # XXX NOTE: the 0/+1/-1 refcount information for arguments is # confusing! Much more useful would be to indicate whether the # function "steals" a reference to the argument or not. Take for # example PyList_SetItem(list, i, item). This lists as a 0 change for # both the list and the item arguments. However, in fact it steals a # reference to the item argument! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 is an > object) or not. I *think* you can tell the latter from the +1 for the > return value; but the former (whether it steals a reference) is > unclear from the data given. There's even an XXX comment about this in > the file: > > # XXX NOTE: the 0/+1/-1 refcount information for arguments is > # confusing! Much more useful would be to indicate whether the > # function "steals" a reference to the argument or not. Take for > # example PyList_SetItem(list, i, item). This lists as a 0 change for > # both the list and the item arguments. However, in fact it steals a > # reference to the item argument! Should we change this file then? And only list functions that don't follow the usual conventions. But I'm sure that there are external tools which already use refcounts.dat in its present format. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 know is >> whether the caller ends up owning the return value (if it is an >> object) or not. I *think* you can tell the latter from the +1 for the >> return value; but the former (whether it steals a reference) is >> unclear from the data given. There's even an XXX comment about this in >> the file: >> >> # XXX NOTE: the 0/+1/-1 refcount information for arguments is >> # confusing! Much more useful would be to indicate whether the >> # function "steals" a reference to the argument or not. Take for >> # example PyList_SetItem(list, i, item). This lists as a 0 change for >> # both the list and the item arguments. However, in fact it steals a >> # reference to the item argument! > > Should we change this file then? > And only list functions that don't follow the usual conventions. > > But I'm sure that there are external tools which already use refcounts.dat > in its present format. Maybe we can *add* a column with the desired information? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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, it doesn't seem to quite convey the same information. >>> It lists the "refcount effect" on each parameter, but translating >>> that into the notion of borrowed or stolen references seems >>> to require knowledge of what the function does. >>> >>> For example, PyDict_SetItem has: >>> >>> PyDict_SetItem:PyObject*:p:0: >>> PyDict_SetItem:PyObject*:key:+1: >>> PyDict_SetItem:PyObject*:val:+1: >>> >>> All of these parameters take borrowed references, but the >>> key and val get incremented because they're being stored >>> in the dict. >> >> 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. >> >>> >>> So this file appears to be of limited usefulness. > > 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 is an > object) or not. I *think* you can tell the latter from the +1 for the > return value; but the former (whether it steals a reference) is > unclear from the data given. There's even an XXX comment about this in > the file: > > # XXX NOTE: the 0/+1/-1 refcount information for arguments is > # confusing! Much more useful would be to indicate whether the > # function "steals" a reference to the argument or not. Take for > # example PyList_SetItem(list, i, item). This lists as a 0 change for > # both the list and the item arguments. However, in fact it steals a > # reference to the item argument! We're not using the information about arguments anyway in the doc build. So we're free to change the file to list only return types, and parameters in the event of stolen references. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 thing to know is > > whether the caller ends up owning the return value (if it is an > > object) or not. I *think* you can tell the latter from the +1 for the > > return value; but the former (whether it steals a reference) is > > unclear from the data given. There's even an XXX comment about this in > > the file: > > > > # XXX NOTE: the 0/+1/-1 refcount information for arguments is > > # confusing! Much more useful would be to indicate whether the > > # function "steals" a reference to the argument or not. Take for > > # example PyList_SetItem(list, i, item). This lists as a 0 change for > > # both the list and the item arguments. However, in fact it steals a > > # reference to the item argument! > > Should we change this file then? > And only list functions that don't follow the usual conventions. +1 Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 >>> function *steals* a reference. The other important thing to know is >>> whether the caller ends up owning the return value (if it is an >>> object) or not. I *think* you can tell the latter from the +1 for the >>> return value; but the former (whether it steals a reference) is >>> unclear from the data given. There's even an XXX comment about this in >>> the file: >>> >>> # XXX NOTE: the 0/+1/-1 refcount information for arguments is >>> # confusing! Much more useful would be to indicate whether the >>> # function "steals" a reference to the argument or not. Take for >>> # example PyList_SetItem(list, i, item). This lists as a 0 change for >>> # both the list and the item arguments. However, in fact it steals a >>> # reference to the item argument! >> >> Should we change this file then? >> And only list functions that don't follow the usual conventions. >> >> But I'm sure that there are external tools which already use refcounts.dat >> in its present format. > > Maybe we can *add* a column with the desired information? +1 Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Avoid codec spelling issues by just using the utf-8 default.
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 the utf-8 default.
Out of curiosity, what is the issue?
>
> files:
> Lib/random.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Lib/random.py b/Lib/random.py
> --- a/Lib/random.py
> +++ b/Lib/random.py
> @@ -114,7 +114,7 @@
> if version == 2:
> if isinstance(a, (str, bytes, bytearray)):
> if isinstance(a, str):
> - a = a.encode("utf8")
> + a = a.encode()
--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default.
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
> summary:
> Avoid codec spelling issues by just using the utf-8 default.
>
> files:
> Lib/random.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/Lib/random.py b/Lib/random.py
> --- a/Lib/random.py
> +++ b/Lib/random.py
> @@ -114,7 +114,7 @@
> if version == 2:
> if isinstance(a, (str, bytes, bytearray)):
> if isinstance(a, str):
> -a = a.encode("utf-8")
> +a = a.encode()
Isn't explicit better than implicit? By reading the new code it is not
obvious that any thought was given to the choice of a codec, while
stating "utf-8" explicitly hints that a decision was made.
(also, I don't understand the spelling issue: "utf-8" just works)
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default.
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 in python. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default.
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, some are short-circuited in C code while > others require codec lookup implemented in python. This sounds like a bug to fix (isn't it fixed it already, btw?) rather than add hackish workarounds for in stdlib code. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default.
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 while > others require codec lookup implemented in python. Isn't it cached after the first run? If this is the reasoning, I find it hard to believe that seed() is a large bottleneck in random. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 >> whether the caller ends up owning the return value (if it is an >> object) or not. I *think* you can tell the latter from the +1 for the >> return value; but the former (whether it steals a reference) is >> unclear from the data given. There's even an XXX comment about this in >> the file: >> >> # XXX NOTE: the 0/+1/-1 refcount information for arguments is >> # confusing! Much more useful would be to indicate whether the >> # function "steals" a reference to the argument or not. Take for >> # example PyList_SetItem(list, i, item). This lists as a 0 change for >> # both the list and the item arguments. However, in fact it steals a >> # reference to the item argument! > > Should we change this file then? > And only list functions that don't follow the usual conventions. > > But I'm sure that there are external tools which already use refcounts.dat > in its present format. I doubt it. And even if there are, the information in there is in parts highly outdated (because the docs don't use parameter info), and large numbers of functions are missing. Let's remove the cruft, and only keep interesting info. This will also make the file much more manageable. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Avoid codec spelling issues by just using the utf-8 default.
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 2011 -0700 >> summary: >> Avoid codec spelling issues by just using the utf-8 default. > > Out of curiosity, what is the issue? IIRC, the performance depended on how your spelled-it. I believe that is why the spelling got changed in Py3.3. Either way, the code is simpler by just using the default. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Avoid codec spelling issues by just using the utf-8 default.
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 >>> date:Thu May 05 11:35:50 2011 -0700 >>> summary: >>> Avoid codec spelling issues by just using the utf-8 default. >> >> Out of curiosity, what is the issue? > > IIRC, the performance depended on how your spelled-it. > I believe that is why the spelling got changed in Py3.3. Not really. It got changed because we have canonical names for the codecs which the stdlib should use rather than rely on aliases. Performance-wise it only makes a difference if you use it in tight loops. > Either way, the code is simpler by just using the default. ... as long as the casual reader knows what the default it :-) I think it's better to make the choice explicit, if the code relies on a particular non-ASCII encoding. If it doesn't, than the default is fine. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 06 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2011-06-20: EuroPython 2011, Florence, Italy 45 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Avoid codec spelling issues by just using the utf-8 default.
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 Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Avoid codec spelling issues by just using the utf-8 default.
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): Avoid codec spelling issues by just using the utf-8 default.
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 particular case, it hardly matters how random
> bits are encoded.
You don't get the same random number sequence if you use a different
encoding.
>>> r=random.Random()
>>> r.seed('\xe9'.encode('iso-8859-1')); r.randint(0, 1000)
639
>>> r.seed('\xe9'.encode('utf-8')); r.randint(0, 1000)
992
So it is useful to know how the seed was computed. The real question is
which encoding gives the most random numbers? :-)
Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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. When using a functon, what you need to know is whether it borrows or steals a reference. But this file *doesn't tell* you that -- rather it assigns either 0 or +1 to a borrowed reference, apparently based on some notion of what the function "usually" does with that parameter. There does not seem to be enough information in that file to work out the borrowed/stolen statuses, which makes it seem rather useless. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Borrowed and Stolen References in API
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 maintain it manually, it's going to get out-of-date. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
