Re: [Python-Dev] ctypes and win64
Martin v. Löwis wrote: > It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess) make that "over a decade". the first Python system I built was on tru64, back in 1995 (portions of the the initial prototype was written on a 286 box under MS-DOS, but the bulk was developed on tru64 and deployed on tru64...) ___ 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] String formatting / unicode 2.5 bug?
On Sun, 20 Aug 2006, Nick Coghlan wrote:
> John J Lee wrote:
>> Is this a bug?
>
> I don't believe so - the string formatting documentation states that the
> result will be unicode if either the format string is unicode or any of the
> objects passed to a %s format code is unicode.
>
> That latter part has just been extended to include any object that returns
> Unicode from __str__, instead of being restricted to actual Unicode
> instances.
>
> Note that the following behaves the same way regardless of whether you use
> 2.4 or 2.5:
> "%s" % 'hi'
> "%s" % u'hi'
Given that, the following wording should be changed:
http://docs.python.org/lib/typesseq-strings.html
Conversion Meaning Notes
...
s String (converts any python object using str()). (4)
...
(4) If the object or format provided is a unicode string, the resulting
string will also be unicode.
The note (4) says that the result will be unicode, but it doesn't say how,
in this case, that comes about. This case is confusing because the docs
claim string formatting with %s "converts ... using str()", and yet
str(a()) returns a bytestring. Does it *really* use str, or just __str__?
Surely the latter? (given the observed behaviour, and not reading the C
source)
FWIW, this change broke epydoc (fails with an AssertionError -- so perhaps
without the assert it would still "work", dunno).
> And once the result has been promoted to unicode, __unicode__ is used
> directly:
>
>> > > print repr("%s%s" % (a(), a()))
> __str__
> accessing <__main__.a object at 0x00AF66F0>.__unicode__
> __str__
> accessing <__main__.a object at 0x00AF6390>.__unicode__
> __str__
> u'hihi'
I don't understand this part. Why is __unicode__ called? Your example
doesn't appear to show this happening "once [i.e., because?] the result
has been promoted to unicode" -- if that were true, it would "stand to
reason" that the interpreter would then conclude it should call
__unicode__ for all remaining %s, and not bother with __str__. If OTOH
__unicode__ is called because __str__ returned a unicode object, it makes
(very slightly) more sense that it goes through the same
__str__-then-__unicode__ rigmarole for each object on the RHS of the %.
But none of that seems to make a huge amount of sense. I've now found the
September 2004 discussion of this, and I'm none the wiser.
John
___
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
[Python-Dev] What should the focus for 2.6 be?
I've been thinking a bit about a focus for the 2.6 release. We are now officially starting parallel development of 2.6 and 3.0. I really don't expect that we'll be able to merge the easily into the 3.0 branch much longer, so effectively 3.0 will be a fork of 2.5. I wonder if it would make sense to focus in 2.6 on making porting of 2.6 code to 3.0 easier, rather than trying to introduce new features in 2.6. We've done releases without new language features before; notable 2.3 didn't add anything new (except making a few __future__ imports redundant) and concentrated on bugfixes, performance, and library additions. Some projects that could be undertaken in 2.6: - add warnings when apply() is used - add warnings when string exceptions or non-BaseException-derived exceptions are used (this is already planned in PEP 252, which has a very specific roll-out plan) - add warnings when has_key() is used - add warnings when the result of dict.keys(), .values(), .items() is used for anything else than iterating over it - a warning if a class defines has_key() but not __contains__(). - add __contains__ to dbm and gdbm - add warnings to modules and built-ins that will die in 3.0 Some of these warnings should be suppressed by default, but enabled by a command line option. We should also do the work on the standard library to avoid the warnings: get rid of apply(), use 'x in d' instead of 'd.has_key(x)', etc. I've recently done some of this work in the 3.0 branch (e.g. dbm/gdbm are fresh in my memory). Another area that could use a lot of work (and from which 3.0 could also benefit directly) is converting all unit tests to using either unittest.py or doctest.py. There are still at least 40 tests written in the old "compare the output with one we prepared earlier" style. Of course, if people are chomping at the bit to implement certain new features (and those features are generally approved of) then I don't want to stop them; but I would recommend that our effort may better be focused on smoothing the 2.6/3.0 transition rather than looking for new features to add to 2.6. I am often approached by people who object against this or that feature proposal not because they dislike the proposed feature in particular, but because they believe Python is already large enough, and they worry that if we keep adding features at the current pace, it will soon become too unwieldy, and hence harder to learn or to keep in one's brain. I am very sympathetic to this concern (and you should be too!). This is one of the reasons that so much of the Python 3000 work is about ripping out old stuff and simplifying / unifiying things. Dropping two common data types (long and unicode -- of course they will really be merged into their simpler counterparts int and str, but it means much less to learn/remember) is one example. Ripping out classic classes and string exceptions another. Removing dead library modules a third. -- --Guido van Rossum (home page: http://www.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] What should the focus for 2.6 be?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 20, 2006, at 11:24 AM, Guido van Rossum wrote: > I wonder if it would make sense to focus in 2.6 on making porting of > 2.6 code to 3.0 easier, rather than trying to introduce new features > in 2.6. We've done releases without new language features before; > notable 2.3 didn't add anything new (except making a few __future__ > imports redundant) and concentrated on bugfixes, performance, and > library additions. +1, and there are other benefits to this approach too. First, the pace of change appears to slow, which addresses another source of complaints. Because instead of a slew of new features every 18 months, we really see that slew only every three years, with a stabilizing and bug fixing release in between. Another benefit is that with a de-emphasis on new features, we can spend more time improving the library and documentation. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBROiAk3EjvBPtnXfVAQKeMQP/QBfHJexDveKoj/nfjRjic3+HBvTupkoA bga7GmLV7Rn14AoHf+L6n3IhKkE1sIVXwzUmEoOeVN74h3trJSAeEYPjCF7Vt3// 3fZ4SgAlEy3nsOwRYufUtyYU9r36H7Fn7dKTtj+hJCVAzZdAOERy8ZMAEoSOw+Q4 vNfudLPznDQ= =7D1V -END PGP SIGNATURE- ___ 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] ctypes and win64
> Fredrik Lundh <[EMAIL PROTECTED]> writes: > Martin v. Löwis wrote: >> It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess) > make that "over a decade". the first Python system I built was on > tru64, back in 1995 (portions of the the initial prototype was written > on a 286 box under MS-DOS, but the bulk was developed on tru64 and > deployed on tru64...) Well, there's 64-bit support and then there's 64-bit support. While all Unix or Unix like OSs follow LP64 model, I believe Win64 follows a P64 model. So it's a whole new ball game. Ganesan -- Ganesan Rajagopal ___ 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] String formatting / unicode 2.5 bug?
John J Lee <[EMAIL PROTECTED]> wrote: > The note (4) says that the result will be unicode, but it doesn't say how, > in this case, that comes about. This case is confusing because the docs > claim string formatting with %s "converts ... using str()", and yet > str(a()) returns a bytestring. Does it *really* use str, or just __str__? > Surely the latter? (given the observed behaviour, and not reading the C > source) It uses __str__ and confirms that the returned object is a 'str' or 'unicode'. The docs are not precise but they were not for 2.4 either. Note the following case: '%s' % u'Hello!' The operand is not forced to be a str. Neil ___ 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] String formatting / unicode 2.5 bug?
On Sun, 20 Aug 2006, Neil Schemenauer wrote: > John J Lee <[EMAIL PROTECTED]> wrote: >> The note (4) says that the result will be unicode, but it doesn't say how, >> in this case, that comes about. This case is confusing because the docs >> claim string formatting with %s "converts ... using str()", and yet >> str(a()) returns a bytestring. Does it *really* use str, or just __str__? >> Surely the latter? (given the observed behaviour, and not reading the C >> source) > > It uses __str__ and confirms that the returned object is a 'str' or > 'unicode'. The docs are not precise but they were not for 2.4 > either. Note the following case: [...] OK, but I assume you're not saying that the fact that the docs were broken in 2.4 implies they shouldn't be fixed now? I would suggest revised wording, but I'm clearly confused about what actually goes on under the hood... John ___ 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] ctypes and win64
On Aug 19, 2006, at 3:28 AM, Steve Holden wrote: ... > It's going to be very interesting to see what comes out of the Google > sprints. I am sure the 64-bitters will be out in force, so there'll be Hmmm, we'll be working on our laptops, as is typical of sprints, so I'm not sure how many 64-bit machines will in fact be around -- we'll see. > useful data about any such problems. 64 bits is, > I am > sure, as much as anyone is ever going to need, so the pain will > finally > be over. > > It's good to see the idea of industry support for open source sprints > taking off. Tomorrow, the world ... :-) Sprints are indeed a fascinating idea and have proven they work, in an open-source context -- I do wonder if they could be made to work in other contexts, and I'm sure many others are wondering similarly. Alex ___ 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] ctypes and win64
On 8/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote: On Aug 19, 2006, at 3:28 AM, Steve Holden wrote:...> It's going to be very interesting to see what comes out of the Google> sprints. I am sure the 64-bitters will be out in force, so there'll be Hmmm, we'll be working on our laptops, as is typical of sprints, soI'm not sure how many 64-bit machines will in fact be around -- we'llsee.FWIW, I have access to a pair of AMD64 machines with 16Gb RAM and several hundred Gb swap. I can't give anyone else access, but I can run tests and debug. Sprints are indeed a fascinating idea and have proven they work, inan open-source context -- I do wonder if they could be made to work in other contexts, and I'm sure many others are wondering similarly. We've had commercial, private "sprints" at XS4ALL for years, every 6 months or so, until last year. We didn't call them sprints and they obviously weren't as freeform as the Python sprints, but the concept was the same (as well as the atmosphere.) We stopped having them because the number of concurrent projects was consistently larger than the number of programmers, which makes the sprinting setup somewhat useless. -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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
[Python-Dev] A cast from Py_ssize_t to long
On Aug 15, 2006, at 3:16 AM, Martin v. Löwis wrote:
>
> Where does it assume that it is safe to case ssize_t -> long?
> That would be a bug.
Is this a bug?
file_readinto(PyFileObject *f, PyObject *args)
{
...
Py_ssize_t ndone, nnow;
...
return PyInt_FromLong((long)ndone);
}
See Objects/fileobject.c (revision 51420).
___
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] ctypes and win64
Alex Martelli wrote: > Sprints are indeed a fascinating idea and have proven they work, in > an open-source context -- I do wonder if they could be made to work > in other contexts, and I'm sure many others are wondering similarly. "war room" development and other colocation approaches are nothing new, and works very well in many contexts. ___ 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 should the focus for 2.6 be?
Guido van Rossum wrote: > I've been thinking a bit about a focus for the 2.6 release. > > We are now officially starting parallel development of 2.6 and 3.0. I > really don't expect that we'll be able to merge the easily into the > 3.0 branch much longer, so effectively 3.0 will be a fork of 2.5. > > I wonder if it would make sense to focus in 2.6 on making porting of > 2.6 code to 3.0 easier, rather than trying to introduce new features > in 2.6. We've done releases without new language features before; > notable 2.3 didn't add anything new (except making a few __future__ > imports redundant) and concentrated on bugfixes, performance, and > library additions. I've been thinking about the transition to unicode strings, and I want to put forward a notion that might allow the transition to be done gradually instead of all at once. The idea would be to temporarily introduce a new name for 8-bit strings - let's call it "ascii". An "ascii" object would be exactly the same as today's 8-bit strings. The 'str' builtin symbol would be assigned to 'ascii' by default, but you could assign it to 'unicode' if you wanted to default to wide strings: str = ascii # Selects 8-bit strings by default str = unicode # Selects unicode strings by default In order to make the transition, what you would do is to temporarily undefine the 'str' symbol from the code base - in other words, remove 'str' from the builtin namespace, and then migrate all of the code -- replacing any library reference to 'str' with a reference to 'ascii' *or* updating that function to deal with unicode strings. Once you get all of the unit tests running again, you can re-introduce 'str', but now you know that since none of the libraries refer to 'str' directly, you can safely change its definition. All of this could be done while retaining compatibility with existing 3rd party code - as long as 'str = ascii' is defined. So you turn it on to run your Python programs, and turn it off when you want to work on 3.0 migration. The next step (which would not be backwards compatible) would be to gradually remove 'ascii' from the code base -- wherever that name occurs, it would be a signal that the function needs to be updated to use 'unicode' instead. Finally, once the last occurance of 'ascii' is removed, the final step is to do a search and replace of all occurances of 'unicode' with 'str'. I know this seems round-about, and is more work than doing it all in one shot. However, I know from past experience that the trickiest part of doing a pervasive change to a code base like this is just keeping track of what parts have been migrated and what parts have not. Many times in the past I've changed the definition of a ubiquitous type by temporarily renaming it, thus vacating the old name so that it can be defined anew, without conflict. -- Talin ___ 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
