Re: [Python-Dev] How does this help? Re: [Python-checkins] r51366 - python/trunk/Lib/idlelib/NEWS.txt python/trunk/Lib/idlelib/idlever.py
On Saturday 19 August 2006 06:24, Jim Jewett wrote: > This makes things more consistent for today, but does it really ease > maintenance? > > Why not just change it to: > > from sys import version as IDLE_VERSION > > so that it can be ignored from now on? After the fuss about changing distutils' version number? :-) I'd very much like to do this, but I figured this was a good first step. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] One-line fix for urllib2 regression
On Saturday 19 August 2006 15:28, Georg Brandl wrote: > John J Lee wrote: > > Revision 50842 made a change to an undocumented interface of urllib2 that > > I'm sure will break real code. > > > > Patch 1542948 reverts the part of that commit that applied to urllib2, > > and adds a one-line fix in its place that addresses the problem that > > 50842 fixed. > > > > Details are on the patch tracker: > > > > http://python.org/sf/1542948 > > > > > > Can somebody commit this for 2.5? > > As the committer of the original patch, I have reviewed it and I'm for it. I agree with Neal's comment - this needs tests to make sure it doesn't break again. It's OK to apply it with the tests. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] ctypes and win64
[Steve Holden] >> Reasonable enough, but I suspect that Thomas' suggestion might save us >> from raising false hopes. I'd suggest that the final release >> announcement point out that this is the first release containing >> specific support for 64-bit architectures (if indeed it is) [Martin v. Löwis] > It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), > and was released for Win64 throughout Python 2.4. ActiveState has > been releasing an AMD64 package for some time now. Python has also been used on 64-bit Crays, and I actually did the first 64-bit port in 1993 (to a KSR Unix machine -- took less than a day to get it running fine! Guido's an excellent C coder.). Win64 is the first (and probably only forever more) where sizeof(long) < sizeof(void*), and that caused some Win64-unique pain, and may cause more. BTW, at least two of the people at the NFS sprint earlier this year were compiling and running Python on Win64 laptops. It's "solid enough", and surely nobody expects that Win64 users expect 100% perfection of anything they run <0.5 wink>. ___ 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] ctypes and win64
Tim Peters wrote: > [Steve Holden] > >>> Reasonable enough, but I suspect that Thomas' suggestion might save us >>> from raising false hopes. I'd suggest that the final release >>> announcement point out that this is the first release containing >>> specific support for 64-bit architectures (if indeed it is) > > > [Martin v. Löwis] > >> It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), >> and was released for Win64 throughout Python 2.4. ActiveState has >> been releasing an AMD64 package for some time now. > > > Python has also been used on 64-bit Crays, and I actually did the > first 64-bit port in 1993 (to a KSR Unix machine -- took less than a > day to get it running fine! Guido's an excellent C coder.). Win64 is > the first (and probably only forever more) where sizeof(long) < > sizeof(void*), and that caused some Win64-unique pain, and may cause > more. > > BTW, at least two of the people at the NFS sprint earlier this year > were compiling and running Python on Win64 laptops. It's "solid > enough", and surely nobody expects that Win64 users expect 100% > perfection of anything they run <0.5 wink>. > I suppose we should be grateful thirteen years experience has gone into 64-bit support. I agree that "some breakage may occur" is true of any release and architecture though in the eyes of this lurker, at least, python-dev does a more-than-averagely conscientious job. 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 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 ... :-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] [Python-checkins] How does this help? Re: r51366 - python/trunk/Lib/idlelib/NEWS.txt python/trunk/Lib/idlelib/idlever.py
Anthony Baxter <[EMAIL PROTECTED]> writes: > On Saturday 19 August 2006 06:24, Jim Jewett wrote: >> This makes things more consistent for today, but does it really ease >> maintenance? >> >> Why not just change it to: >> >> from sys import version as IDLE_VERSION >> >> so that it can be ignored from now on? > > After the fuss about changing distutils' version number? :-) > > I'd very much like to do this, but I figured this was a good first step. Jim Jewett's suggestion could actually be misleading, IMO. There are users, especially on Windows, who run IDLE out of svn or run their own version, but don't build Python. Here's my suggestion: we set IDLE_VERSION="" in idlever.py. If the IDLE hacker wants to set a specific version, he sets that string. I'll change the code so if the string is empty, IDLE will use the Python version, as Jim suggested; otherwise, the user supplied string. -- KBK ___ 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] os.spawnlp() missing on Windows in 2.4?
On Sat, Aug 19, 2006 at 04:34:16AM +0100, Steve Holden wrote: > Scott Dial wrote: > > Guido van Rossum wrote: > > > >>I just got a report from a Windows user that os.spawnlp() is missing > >>from Python 2.4, despite being mentioned in the docs. Can someone > >>confirm this? My Windows box is resting. :-) > >> > > > > > > "Availability: Unix, Windows. spawnlp(), spawnlpe(), spawnvp() and > > spawnvpe() are not available on Windows. New in version 1.6." > > > > One could argue that it presented poorly, but it reads completely > > correct. Alternatively one could says "The 'p' variants are unavailable > > on Windows." but that would be assuming someone understand there was a > > scheme to the names :-) > > > How about: > > "Availability: Unix; Windows PARTIAL (spawnlp(), spawnlpe(), spawnvp() > and spawnvpe() are not implemented). New in version 1.6" > Or *Availability: Unix: All, Windows: spawnl(), spawnle(), spawnv(), spawnve() only. New in version 1.6 Might as well positively list the half that is there instead of the half that isn't. -Jack ___ 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] ctypes and win64
On Sat, Aug 19, 2006 at 05:19:40AM -0400, Tim Peters wrote: > [Steve Holden] > >> Reasonable enough, but I suspect that Thomas' suggestion might save us > >> from raising false hopes. I'd suggest that the final release > >> announcement point out that this is the first release containing > >> specific support for 64-bit architectures (if indeed it is) > > [Martin v. L?wis] > > It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), > > and was released for Win64 throughout Python 2.4. ActiveState has > > been releasing an AMD64 package for some time now. > > Python has also been used on 64-bit Crays, and I actually did the > first 64-bit port in 1993 (to a KSR Unix machine -- took less than a > day to get it running fine! Guido's an excellent C coder.). Win64 is > the first (and probably only forever more) where sizeof(long) < > sizeof(void*), and that caused some Win64-unique pain, and may cause > more. > > BTW, at least two of the people at the NFS sprint earlier this year > were compiling and running Python on Win64 laptops. It's "solid > enough", and surely nobody expects that Win64 users expect 100% > perfection of anything they run <0.5 wink>. It has always "just worked" for me on Opterons + Debian. Python 2.4 (#1, May 31 2005, 10:19:45) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxint 9223372036854775807 Thanks to the Alphas for making AMD64 on *nix a no-brainer, -Jack ___ 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] Questions on unittest behaviour
On 8/19/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Alternatively, someone who prefers your style (with a tearDown() method that > can handle a partially executed call to the setUp() method), can just write > it as: > > def setUp(self) > try: > lock_file(testfile) # open_socket(), connect_to_database(), etc > something_that_may_raise_an_exception() > except: > self.tearDown() > raise > > def tearDown(self): > if file_is_locked(testfile): > unlock_file(testfile) > > Consider the parallel to PEP 343's __enter__ and __exit__ methods - __exit__ > is allowed to assume that it will only be called if __enter__ succeeded, > because that is part of the semantics of the with statement. I can accept that. Any thoughts on the other four items? Collin Winter ___ 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] os.spawnlp() missing on Windows in 2.4?
"Jack Diederich" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > *Availability: Unix: All, Windows: spawnl(), spawnle(), spawnv(), > spawnve() only. New in version 1.6 > > Might as well positively list the half that is there instead of the half > that isn't. Definitately. Succinct and clear. ___ 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] Questions on unittest behaviour
Collin Winter wrote: > Any thoughts on the other four items? Generally speaking, I'm not sure it's worth the effort to do the input validation. All of the cases you suggest ruling out do indeed seem to be insane, but someone may have defined a subclass that does something based on the current behaviour. Given the timing, I suggest just documenting and testing the current behaviour for Python 2.5, and then creating a tracker item targeting 2.6 to cover the lack of sanity checks (and whether or not more should be added). Some of the problems have multiple possible solutions (e.g., using inspect.getargspec() to check for zero-argument callables when searching for test methods, instead of trying to call everything unittest can lay its hands on) so we need more time to think about them. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] String formatting / unicode 2.5 bug?
Is this a bug?
# run with 2.4 and then with 2.5 (I'm running release25-maint:51410)
class a(object):
def __getattribute__(self, name):
print "accessing %r.%s" % (self, name)
return object.__getattribute__(self, name)
def __str__(self):
print "__str__"
return u'hi'
print repr(str(a()))
print
print repr("%s" % a())
John
___
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] SSH Key Added
Can I have this key added?-- Jackilyn Hoxworth jah_key.pub Description: Binary data ___ 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] String formatting / unicode 2.5 bug?
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'
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'
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] uuid module - byte order issue
On Fri, 4 Aug 2006, Oren Tirosh wrote: > Compatibility with Windows "GUIDs" may be one of the most important > use cases for the UUID module. It's important to resolve this or users > will have unpleasant surprises. I did. [...] > alternatives: > > 1. Default is big endian byte order. Little endian is explicit. > 2. Default is native byte order. Little endian and big endian are explicit. > 3. No default. Little endian and big endian are both explicit. I implemented and committed the first alternative above (as a new attribute, 'bytes_le'), shortly before the freeze. -- ?!ng ___ 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] ctypes and win64
On 8/19/06, Jack Diederich <[EMAIL PROTECTED]> wrote: It has always "just worked" for me on Opterons + Debian.Python 2.4 (#1, May 31 2005, 10:19:45)[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2Type "help", "copyright", "credits" or "license" for more information. >>> import sys>>> sys.maxint9223372036854775807While that's certainly useful behaviour, it isn't exactly the same thing as the 64-bit support in Python 2.5. 64-bit longs have always worked (as Tim said, CPython is good C), but large parts of CPython were using ints instead of longs -- and I'm fairly certain there are still quite a few bugs with container types and more than 31-bits worth of elements. (I say that because I found more than I hoped for, writing the bigmem tests a few months back. And those tests only consider bytestrings, lists and tuples.) So, while sys.maxint doesn't change, and any container with sane amounts of elements will almost certainly work (one would hope that's tested enough by now), real-world code that actually uses, say, more than 100Gb worth of memory in a single container may still break. Unless we write more bigmem tests :> Luxury-problem-anyone?'ly y'rs,-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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
