Re: [Python-Dev] PyInt_AsSsize_t on x64
Hi Kristján,
On Thu, May 03, 2007 at 03:57:26PM +, Kristján Valur Jónsson wrote:
> if (nb->nb_long != 0) {
> io = (PyIntObject*) (*nb->nb_long) (op);
> } else {
> io = (PyIntObject*) (*nb->nb_int) (op);
> }
> Now, how to fix this? Should the code in intobject.c catch the
> AttributeError, maybe, and continue to the nb_int?
The problem is specific to old-style classes: in principle, only them
have all slots non-null even if they don't really define the
corresponding special methods. With anything else than old-style
classes you don't get an AttributeError if a special method doesn't
exist, which makes checking for AttributeError in PyInt_AsSsize_t()
strange.
Given that the __long__ vs __int__ difference doesn't really make sense
any more nowadays, I'd think it would be saner to change the nb_long
slot of old-style instances instead of PyInt_AsSsize_t(). The logic
would be that if the nb_long slot implementation finds no "__long__"
attribute on the instance it tries with "__int__" instead.
A bientot,
Armin.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x64 and the testsuite
Hi Kristján, On Thu, May 03, 2007 at 07:38:04PM +0200, ?iga Seilnacht wrote: > Those tests should be fixed to use test.test_support.MAX_Py_ssize_t instead > of sys.maxint. See also the bigmemtest() and bigaddrspacetest() decorators in test_support. A bientot, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyInt_AsSsize_t on x64
> -Original Message- > From: Armin Rigo [mailto:[EMAIL PROTECTED] > Given that the __long__ vs __int__ difference doesn't really make sense > any more nowadays, I'd think it would be saner to change the nb_long > slot of old-style instances instead of PyInt_AsSsize_t(). The logic > would be that if the nb_long slot implementation finds no "__long__" > attribute on the instance it tries with "__int__" instead. > That sounds fine to me. I'll be happy to make the change (and revert the change to intobject.c) if everyone concurs. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
On 2007-05-04 19:51, Guido van Rossum wrote: > [-python-dev] > > On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: >> On Friday 04 May 2007, M.-A. Lemburg wrote: >> > I also suggest making all bytes literals immutable to avoid running >> > into any issues like the above. >> >> +1 from me. > > Rather than adding immutability to bytes objects (which has big > implementation and type checking implications), consider using > buffer(b"123") as an immutable bytes literal. You can freely > concatenate and compare buffer objects with bytes objects. I like Georg's idea of having an immutable bytes subclass. b"abc" could then be a shortcut constructor for this subclass. In general, I don't think it's a good idea to have literals turn into mutable objects, since literals are normally perceived as being constant. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 05 2007) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))
On Fri, May 04, 2007, Guido van Rossum wrote: > > [-python-dev] > > On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: >> On Friday 04 May 2007, M.-A. Lemburg wrote: >>> >>> I also suggest making all bytes literals immutable to avoid running >>> into any issues like the above. >> >> +1 from me. > > Rather than adding immutability to bytes objects (which has big > implementation and type checking implications), consider using > buffer(b"123") as an immutable bytes literal. You can freely > concatenate and compare buffer objects with bytes objects. I'm with MAL and Fred on making literals immutable -- that's safe and lots of newbies will need to use byte literals early in their Python experience if they pick up Python to operate on network data. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
On 5/5/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2007-05-04 19:51, Guido van Rossum wrote:
> > [-python-dev]
> >
> > On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> >> On Friday 04 May 2007, M.-A. Lemburg wrote:
> >> > I also suggest making all bytes literals immutable to avoid running
> >> > into any issues like the above.
> >>
> >> +1 from me.
> >
> > Rather than adding immutability to bytes objects (which has big
> > implementation and type checking implications), consider using
> > buffer(b"123") as an immutable bytes literal. You can freely
> > concatenate and compare buffer objects with bytes objects.
>
> I like Georg's idea of having an immutable bytes subclass.
> b"abc" could then be a shortcut constructor for this subclass.
>
> In general, I don't think it's a good idea to have literals
> turn into mutable objects, since literals are normally perceived
> as being constant.
Does that mean you want list literals to be immutable too?
lst = ['a', 'b', 'c']
lst.append('d') # raises an error?
STeVe
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))
On Saturday 05 May 2007, Aahz wrote: > I'm with MAL and Fred on making literals immutable -- that's safe and > lots of newbies will need to use byte literals early in their Python > experience if they pick up Python to operate on network data. Yes; there are lots of places where bytes literals will be used the way str literals are today. buffer(b'...') might be good enough, but it seems more than a little idiomatic, and doesn't seem particularly readable. I'm not suggesting that /all/ literals result in constants, but bytes literals seem like a case where what's wanted is the value. If b'...' results in a new object on every reference, that's a lot of overhead for a network protocol implementation, where the data is just going to be written to a socket or concatenated with other data. An immutable bytes type would be very useful as a dictionary key as well, and more space-efficient than tuple(b'...'). Whether there should be one type with a flag indicating mutability, or two separate types (as with set and frozenset), I'm not sure. The later offers some small performance benefits, but I don't expect there's enough to really matter there. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
On 2007-05-05 18:11, Steven Bethard wrote:
> On 5/5/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2007-05-04 19:51, Guido van Rossum wrote:
>> > [-python-dev]
>> >
>> > On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>> >> On Friday 04 May 2007, M.-A. Lemburg wrote:
>> >> > I also suggest making all bytes literals immutable to avoid running
>> >> > into any issues like the above.
>> >>
>> >> +1 from me.
>> >
>> > Rather than adding immutability to bytes objects (which has big
>> > implementation and type checking implications), consider using
>> > buffer(b"123") as an immutable bytes literal. You can freely
>> > concatenate and compare buffer objects with bytes objects.
>>
>> I like Georg's idea of having an immutable bytes subclass.
>> b"abc" could then be a shortcut constructor for this subclass.
>>
>> In general, I don't think it's a good idea to have literals
>> turn into mutable objects, since literals are normally perceived
>> as being constant.
>
> Does that mean you want list literals to be immutable too?
>
>lst = ['a', 'b', 'c']
>lst.append('d') # raises an error?
Sorry, I was referring to Python literals:
http://docs.python.org/ref/literals.html
ie. strings and numeric constant values defined in a Python program.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 05 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote:
>
> On Saturday 05 May 2007, Aahz wrote:
> > I'm with MAL and Fred on making literals immutable -- that's safe and
> > lots of newbies will need to use byte literals early in their Python
> > experience if they pick up Python to operate on network data.
>
> Yes; there are lots of places where bytes literals will be used the way str
> literals are today. buffer(b'...') might be good enough, but it seems more
> than a little idiomatic, and doesn't seem particularly readable.
>
> I'm not suggesting that /all/ literals result in constants, but bytes
> literals
> seem like a case where what's wanted is the value. If b'...' results in a
> new object on every reference, that's a lot of overhead for a network
> protocol implementation, where the data is just going to be written to a
> socket or concatenated with other data. An immutable bytes type would be
> very useful as a dictionary key as well, and more space-efficient than
> tuple(b'...').
I was saying the exact same thing last summer. See my discussion with
Martin about parsing/unmarshaling. What I expect will happen with bytes
as dictionary keys is that people will end up subclassing dictionaries
(with varying amounts of success and correctness) to do something like
the following...
class bytesKeys(dict):
...
def __setitem__(self, key, value):
if isinstance(key, bytes):
key = key.decode('latin-1')
else:
raise KeyError("only bytes can be used as keys")
dict.__setitem__(self, key, value)
...
Is it optimal? No. Would it be nice to have immtable bytes? Yes. Do
I think it will really be a problem in parsing/unmarshaling? I don't
know, but the fact that there now exists a reasonable literal syntax b'...'
rather than the previous bytes([1, 2, 3, ...]) means that we are coming
much closer to having what really is about the best way to handle this;
Python 2.x str.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
>> In general, I don't think it's a good idea to have literals
>> turn into mutable objects, since literals are normally perceived
>> as being constant.
>
> Does that mean you want list literals to be immutable too?
>
> lst = ['a', 'b', 'c']
> lst.append('d') # raises an error?
That's not a literal, it's a display. The difference is that
a literal denotes the same object every time it is executed.
A display creates a new object every time it is executed.
(another difference is that a display is a constructed thing
which may contain runtime-computed components, unlike a
literal).
So if bytes are mutable and also have source-level
representation, they should be displays, not literals.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
Steven Bethard wrote:
> On 5/5/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2007-05-04 19:51, Guido van Rossum wrote:
>>> [-python-dev]
>>>
>>> On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
On Friday 04 May 2007, M.-A. Lemburg wrote:
> I also suggest making all bytes literals immutable to avoid running
> into any issues like the above.
+1 from me.
>>> Rather than adding immutability to bytes objects (which has big
>>> implementation and type checking implications), consider using
>>> buffer(b"123") as an immutable bytes literal. You can freely
>>> concatenate and compare buffer objects with bytes objects.
>> I like Georg's idea of having an immutable bytes subclass.
>> b"abc" could then be a shortcut constructor for this subclass.
>>
>> In general, I don't think it's a good idea to have literals
>> turn into mutable objects, since literals are normally perceived
>> as being constant.
>
> Does that mean you want list literals to be immutable too?
>
> lst = ['a', 'b', 'c']
> lst.append('d') # raises an error?
>
> STeVe
I think the point is rather that changes to the list linked by lst after
the initial assignment shouldn't result in the assignemtn of a different
value to lst if the statement is executed again (as part of a function
body or in a loop, for example).
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
-- Asciimercial -
Get on the web: Blog, lens and tag your way to fame!!
holdenweb.blogspot.comsquidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-- Thank You for Reading
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
On 5/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> In general, I don't think it's a good idea to have literals
> >> turn into mutable objects, since literals are normally perceived
> >> as being constant.
> >
> > Does that mean you want list literals to be immutable too?
> >
> > lst = ['a', 'b', 'c']
> > lst.append('d') # raises an error?
>
> That's not a literal, it's a display. The difference is that
> a literal denotes the same object every time it is executed.
> A display creates a new object every time it is executed.
> (another difference is that a display is a constructed thing
> which may contain runtime-computed components, unlike a
> literal).
>
> So if bytes are mutable and also have source-level
> representation, they should be displays, not literals.
So is having mutable bytes just a matter of calling them "byte
displays" instead of "byte literals" or does that also require
changing something in the back end?
STeVe
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
Steven Bethard wrote: > Does that mean you want list literals to be immutable too? There are no "list literals" in Python, only expressions that construct lists. You might argue that b"abc" is not a literal either, but an expression that constructs a bytes object. However, it *looks* so much like a string literal that this would be a difficult distinction to keep in mind, and very likely to trip people up. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (04/29/07 - 05/06/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1650 open ( +1) / 8584 closed ( +0) / 10234 total ( +1) Average duration of open issues: 784 days. Median duration of open issues: 736 days. Open Issues Breakdown open 1650 ( +1) pending 0 ( +0) Issues Created Or Reopened (1) __ yahoo05/02/07 http://bugs.python.org/issue1030created step ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 360 open ( +4) / 3760 closed ( +4) / 4120 total ( +8) Bugs: 971 open ( +3) / 6683 closed (+10) / 7654 total (+13) RFE : 257 open ( +3) / 282 closed ( +0) / 539 total ( +3) New / Reopened Patches __ test_1686475 of test_os & pagefile.sys (2007-04-28) http://python.org/sf/1709112 opened by A.B., Khalid run test_1565150(test_os.py) only on NTFS (2007-04-29) http://python.org/sf/1709599 opened by Hirokazu Yamamoto Update locale.__all__ (2007-04-30) CLOSED http://python.org/sf/1710352 opened by Humberto Diógenes PEP 318 -- add resolution and XRef (2007-05-01) CLOSED http://python.org/sf/1710853 opened by Jim Jewett PEP 3132: extended unpacking (2007-05-02) http://python.org/sf/1711529 opened by Georg Brandl syslog syscall support for SysLogLogger (2007-05-02) http://python.org/sf/1711603 opened by Luke-Jr fix for bug 1712742 (2007-05-04) http://python.org/sf/1713041 opened by Raghuram Devarakonda Fix warnings related to PyLong_FromVoidPtr (2007-05-05) http://python.org/sf/1713234 opened by Hirokazu Yamamoto Patches Closed __ Picky floats (2006-04-28) http://python.org/sf/1478364 closed by loewis Update locale.__all__ (2007-05-01) http://python.org/sf/1710352 closed by gbrandl Use MoveFileEx() to implement os.rename() on windows (2007-04-20) http://python.org/sf/1704547 closed by loewis PEP 318 -- add resolution and XRef (2007-05-01) http://python.org/sf/1710853 closed by gbrandl New / Reopened Bugs ___ test_1686475 fails when pagefile.sys does not exist (2007-04-28) CLOSED http://python.org/sf/1709282 opened by Calvin Spealman test_1686475 fails because pagefile.sys does not exist (2007-04-28) http://python.org/sf/1709284 opened by Calvin Spealman struct.calcsize() incorrect (2007-04-29) CLOSED http://python.org/sf/1709506 opened by JoelBondurant Tutorial - Section 8.3 - (2007-04-30) CLOSED http://python.org/sf/1710295 opened by elrond79 zipfile.ZipFile behavior inconsistent. (2007-05-01) http://python.org/sf/1710703 opened by Mark Flacy Ctrl+Shift block marking by words (2007-05-01) http://python.org/sf/1710718 opened by zorkin subprocess must escape redirection characters under win32 (2007-05-01) CLOSED http://python.org/sf/1710802 opened by Patrick Mézard CGIHttpServer leaves traces of previous requests in env (2007-05-03) http://python.org/sf/1711605 opened by Steve Cassidy CGIHttpServer fails if python exe has spaces (2007-05-03) http://python.org/sf/1711608 opened by Steve Cassidy SequenceMatcher bug with insert/delete block after "replace" (2007-05-03) http://python.org/sf/1711800 opened by Christian Hammond __getslice__ changes integer arguments (2007-05-03) http://python.org/sf/1712236 opened by Imri Goldberg Cannot use dict with unicode keys as keyword arguments (2007-05-04) http://python.org/sf/1712419 opened by Viktor Ferenczi urllib.quote throws exception on Unicode URL (2007-05-04) http://python.org/sf/1712522 opened by John Nagle pprint handles depth argument incorrectly (2007-05-04) http://python.org/sf/1712742 opened by Dmitrii Tisnek character set in Japanese on Ubuntu distribution (2007-05-04) http://python.org/sf/1713252 opened by Christopher Grell Error inside logging module's documentation (2007-05-05) CLOSED http://python.org/sf/1713535 opened by billiejoex Bugs Closed ___ TimedRotatingFileHandler's doRollover opens file in "w" mode (2007-04-27) http://python.org/sf/1708538 closed by vsajip test_1686475 fails when pagefile.sys does not exist (2007-04-28) http://python.org/sf/1709282 deleted by ironfroggy struct.calcsize() incorrect (2007-04-29) http://python.org/sf/1709506 closed by loewis Tutorial - Section 8.3 - (2007-04-30) http://python.org/sf/1710295 closed by gbrandl Portability issue: os.rename behaves differently on win32 (2007-04-03) http://python.org/sf/1693753 closed by loewis subprocess must escape redirection characters under win32 (2007-05-01) http://python.org/sf/1710802 closed by astrand Bypassing __dict__ readonlyness (2005-09-24) http://python.org/sf/1303614 closed by arigo subclassing ModuleType and another built-in type (2005-04-01) http://python.org/sf/1174712 closed by arigo Error inside logging module documentation (2007-05-05) http://python.org/sf/1713535 closed by gbrandl New / Reopened RFE __ commands module (2007-05-05) http://python.org/sf/1713624 opened by Joseph Armbruster ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.o
Re: [Python-Dev] Changing string constants to byte arrays in Py3k
>> That's not a literal, it's a display. The difference is that >> a literal denotes the same object every time it is executed. >> A display creates a new object every time it is executed. >> (another difference is that a display is a constructed thing >> which may contain runtime-computed components, unlike a >> literal). >> >> So if bytes are mutable and also have source-level >> representation, they should be displays, not literals. > > So is having mutable bytes just a matter of calling them "byte > displays" instead of "byte literals" or does that also require > changing something in the back end? It's certainly also an issue of language semantics (i.e. changes to interpreter code). There are a number of options: 1. don't support creation of byte values through syntax. Instead, create bytes through a constructor function. 2. if there is syntax support, make it a display: every time you execute a bytes display, create a new value, which can then be mutated. 3. if you want it to be a literal, make it immutable: change the type, or add a flag so that it is immutable. Then put it into the co_consts array of the code object. The original complaint was that it shouldn't be in co_consts if it is mutable. In case these three options aren't clear yet, some examples: 1. def foo(): return bytes([1,2,3]) print foo() is foo() # False x = foo() x[0] = 5 # supported 2. def foo(): return b"\x01\x02\x03" print foo() is foo() # False x = foo() x[0] = 5 # supported 3. def foo(): return b"\x01\x02\x03" print foo() is foo() # True x = foo() x[0] = 5 # TypeError HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
