Re: [Python-Dev] Tix not included in 2.5 for Windows
On Sep 30, 2006, at 11:13 PM, Scott David Daniels wrote: Christos Georgiou wrote: Does anyone know why this happens? I can't find any information pointing to this being deliberate. I just upgraded to 2.5 on Windows (after making sure I can build extensions with the freeware VC++ Toolkit 2003) and some of my programs stopped operating. I saw in a French forum that someone else had the same problem, and what they did was to copy the relevant files from a 2.4.3 installation. I did the same, and it seems it works, with only a console message appearing as soon as a root window is created: Also note: the Os/X universal seems to include a Tix runtime for the non-Intel processor, but not for the Intel processor. This makes me think there is a build problem. The OSX universal binaries don't include Tcl/Tk at all but link to the system version of the Tcl/Tk frameworks. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] HAVE_UINTPTR_T test in configure.in
Hi, Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't defined in pyconfig.h while it should have been defined. I'm looking into this and am now wondering whether the configure snipped below is correct: AC_MSG_CHECKING(for uintptr_t support) have_uintptr_t=no AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [ AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type uintptr_t.]) have_uintptr_t=yes ]) AC_MSG_RESULT($have_uintptr_t) if test "$have_uintptr_t" = yes ; then AC_CHECK_SIZEOF(uintptr_t, 4) fi This seems to check for uintptr_t as a builtin type. Isn't one supposed to include to get this type? Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me, but I've only tested on OSX and don't know if this is the right fix for all supported platforms. AC_TRY_COMPILE([#include ], [uintptr_t x; x = (uintptr_t) 0;], [ Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] Caching float(0.0)
On Fri, Sep 29, 2006 at 12:03:03PM -0700, Guido van Rossum wrote: > I see some confusion in this thread. > > If a *LITERAL* 0.0 (or any other float literal) is used, you only get > one object, no matter how many times it is used. For some reason that doesn't happen in the interpreter which has been confusing the issue slightly... $ python2.5 Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=0.0 >>> b=0.0 >>> id(a), id(b) (134737756, 134737772) >>> $ python2.5 -c 'a=0.0; b=0.0; print id(a),id(b)' 134737796 134737796 > But if the result of a *COMPUTATION* returns 0.0, you get a new object > for each such result. If you have 70 MB worth of zeros, that's clearly > computation results, not literals. In my application I'm receiving all the zeros from a server over TCP as ASCII and these are being float()ed in python. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick ___ 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] Caching float(0.0)
On Sat, Sep 30, 2006 at 03:21:50PM -0700, Bob Ippolito wrote:
> On 9/30/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> > > I suspect the problem would typically stem from floating point
> > > values that are read in from a human-readable file rather than
> > > being the result of a 'calculation' as such:
Over a TCP socket in ASCII format for my application
> > For such situations, one could create a translation dict for both common
> > float values and for non-numeric missing value indicators. For instance,
> > flotran = {'*': None, '1.0':1.0, '2.0':2.0, '4.0':4.0}
> > The details, of course, depend on the specific case.
>
> But of course you have to know that common float values are never
> cached and that it may cause you problems. Some users may expect them
> to be because common strings and integers are cached.
I have to say I was surprised to find out how many copies of 0.0 there
were in my code and I guess I was subconsciously expecting the
immutable 0.0s to be cached even though I know consciously I've never
seen anything but int and str mentioned in the docs.
--
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
___
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] PEP 351 - do while
Nick Coghlan wrote: > Hans Polak wrote: >> Hi, >> >> >> >> Just an opinion, but many uses of the ‘while true loop’ are instances of >> a ‘do loop’. I appreciate the language layout question, so I’ll give you >> an alternative: >> >> >> >> do: >> >> >> >> >> >> while (I don't think this has been suggested yet.) while , : This would be a do-loop. while 1, : In situations where you want to enter a loop on one condition and exit on a second condition: if value1: value2 = True while value2: Would be ... while value1, value2: I've used that pattern on more than a few occasions. A single condition while would be the same as... while , :# same entry and exit condition So do just as we do now... while : # same entry and exit condition > As I recall, the main objection to this style was that it could hide the loop > termination condition, but that isn't actually mentioned in the PEP (and in > the typical do-while case, the loop condition will still be clearly visible > at > the end of the loop body). Putting both the entry and exit conditions at the top is easier to read. The end of the first loop is also the beginning of all the following loops, so having the exit_condition at the top doesn't really put anything out of order. If the exit_condition is not evaluated until the top of the second loop, the names it uses do not need to be pre defined, they can just be assigned in the loop. Ron ___ 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] PEP 351 - do while
On 10/1/06, Ron Adam <[EMAIL PROTECTED]> wrote: > (I don't think this has been suggested yet.) > > while , : > [snip] > Putting both the entry and exit conditions at the top is easier to read. I agree in principle, but I thought the proposed syntax already has meaning today (as it turns out, parentheses are required to make a tuple in a while condition, at least in 2.4 and 2.5). To help stave off similar confusion I'd rather see a pseudo-keyword added. However my first candidate "until" seems to apply a negation to the exit condition. while True until False: # run once? run forever? while True until True: # run forever? run once? It's still very different from any syntactical syntax I can think of in python. I'm not sure I like the idea. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ 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] PEP 351 - do while
> (I don't think this has been suggested yet.) > > while , : > This usage makes me uneasy, not the least because I don't understand why the comma isn't creating a tuple. That is, why whould while x, y: be any different from while (x, y): ? My other concern is that is evaluated out of sequence. ___ 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] Caching float(0.0)
"Nick Craig-Wood" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Fri, Sep 29, 2006 at 12:03:03PM -0700, Guido van Rossum wrote: >> I see some confusion in this thread. >> >> If a *LITERAL* 0.0 (or any other float literal) is used, you only get >> one object, no matter how many times it is used. > > For some reason that doesn't happen in the interpreter which has been > confusing the issue slightly... > > $ python2.5 a=0.0 b=0.0 id(a), id(b) > (134737756, 134737772) Guido said *a* literal (emphasis shifted), reused as in a loop or function recalled, while you used *a* literal, then *another* literal, without reuse. Try a=b=0.0 instead. Terry Jan Reedy ___ 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] PEP 351 - do while
At 12:58 PM 10/1/2006 -0400, Andrew Koenig wrote: > > (I don't think this has been suggested yet.) > > > > while , : > > > >This usage makes me uneasy, not the least because I don't understand why the >comma isn't creating a tuple. That is, why whould > > while x, y: > > >be any different from > > while (x, y): > > >? > >My other concern is that is evaluated out of sequence. This pattern: while entry_cond: ... and while not exit_cond: ... has been suggested before, and I believe that at least one of the times it was suggested, it had some support from Guido. Essentially, the "and while not exit" is equivalent to an "if exit: break" that's more visible due to not being indented. I'm not sure I like it, myself, but out of all the things that get suggested for this issue, I think it's the best. The fact that it's still not very good despite being the best, is probably the reason we don't have it yet. :) ___ 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] Caching float(0.0)
On Sun, 1 Oct 2006 13:54:31 -0400, Terry Reedy <[EMAIL PROTECTED]> wrote: > >"Nick Craig-Wood" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> On Fri, Sep 29, 2006 at 12:03:03PM -0700, Guido van Rossum wrote: >>> I see some confusion in this thread. >>> >>> If a *LITERAL* 0.0 (or any other float literal) is used, you only get >>> one object, no matter how many times it is used. >> >> For some reason that doesn't happen in the interpreter which has been >> confusing the issue slightly... >> >> $ python2.5 > a=0.0 > b=0.0 > id(a), id(b) >> (134737756, 134737772) > >Guido said *a* literal (emphasis shifted), reused as in a loop or function >recalled, while you used *a* literal, then *another* literal, without >reuse. Try a=b=0.0 instead. Actually this just has to do with, um, "compilation units", for lack of a better term: [EMAIL PROTECTED]:~$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = 0.0 >>> b = 0.0 >>> print a is b False >>> ^D [EMAIL PROTECTED]:~$ cat > test.py a = 0.0 b = 0.0 print a is b ^D [EMAIL PROTECTED]:~$ python test.py True [EMAIL PROTECTED]:~$ cat > test_a.py a = 0.0 ^D [EMAIL PROTECTED]:~$ cat > test_b.py b = 0.0 ^D [EMAIL PROTECTED]:~$ cat > test.py from test_a import a from test_b import b print a is b ^D [EMAIL PROTECTED]:~$ python test.py False [EMAIL PROTECTED]:~$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = 0.0; b = 0.0 >>> print a is b True >>> [EMAIL PROTECTED]:~$ Each line in an interactive session is compiled separately, like modules are compiled separately. With the current implementation, literals in a single compilation unit have a chance to be "cached" like this. Literals in different compilation units, even for the same value, don't. Jean-Paul ___ 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] HAVE_UINTPTR_T test in configure.in
On Oct 1, 2006, at 10:54 AM, Ronald Oussoren wrote: Hi, Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't defined in pyconfig.h while it should have been defined. I'm looking into this and am now wondering whether the configure snipped below is correct: AC_MSG_CHECKING(for uintptr_t support) have_uintptr_t=no AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [ AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type uintptr_t.]) have_uintptr_t=yes ]) AC_MSG_RESULT($have_uintptr_t) if test "$have_uintptr_t" = yes ; then AC_CHECK_SIZEOF(uintptr_t, 4) fi This seems to check for uintptr_t as a builtin type. Isn't one supposed to include to get this type? Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me, but I've only tested on OSX and don't know if this is the right fix for all supported platforms. AC_TRY_COMPILE([#include ], [uintptr_t x; x = (uintptr_t) 0;], [ The same problem exists on Linux, and is fixed by the same change. BTW. Python 2.4 suffers from the same problem and I've filed a bugreport for this (http://www.python.org/sf/1568842). Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] PEP 351 - do while
> This pattern: > > while entry_cond: > ... > and while not exit_cond: > ... > > has been suggested before, and I believe that at least one of the times it > was suggested, it had some support from Guido. Essentially, the "and > while not exit" is equivalent to an "if exit: break" that's more visible > due to not being indented. I like this suggestion. In fact it is possible that at one time I suggested something similar. It reminds me of something that Dijkstra suggested in his 1971 book "A Discipline of Programming." His ides looked somewhat like this: do condition 1 -> action 1 ... [] condition n -> action n od Here, the [] should be thought of as a delimiter; it was typeset as a tall narrow rectangle. The semantics are as follows: If all of the conditions are false, the statement does nothing. Otherwise, the implementation picks one of the true conditions, executes the corresponding action, and does it all again. There is no guarantee about which action is executed if more than one of the conditions is true. The general idea, then, is that each action should falsify its corresponding condition while bring the loop closer to termination; when all of the conditions are false, the loop is done. For example, he might write Euclid's algorithm this way: do x < y -> y := y mod x [] y < x -> x := x mod y od If we were to adopt "while ... and while" in Python, then Dijkstra's construct could be rendered this way: while x < y: y %= x or while y < x: x %= y I'm not suggesting this seriously as I don't have enough realistic use cases. Still, it's interesting to see that someone else has grappled with a similar problem. ___ 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] PEP 351 - do while
Michael Urman wrote: > On 10/1/06, Ron Adam <[EMAIL PROTECTED]> wrote: >> (I don't think this has been suggested yet.) >> >> while , : >> > > [snip] > >> Putting both the entry and exit conditions at the top is easier to read. > > I agree in principle, but I thought the proposed syntax already has > meaning today (as it turns out, parentheses are required to make a > tuple in a while condition, at least in 2.4 and 2.5). To help stave > off similar confusion I'd rather see a pseudo-keyword added. However > my first candidate "until" seems to apply a negation to the exit > condition. > > while True until False: # run once? run forever? > while True until True: # run forever? run once? > > It's still very different from any syntactical syntax I can think of > in python. I'm not sure I like the idea. > > Michael I thought the comma might be a sticking point. My first thought was to have a series of conditions evaluated on loops with the last condition repeated. while loop1_cond, loop2_cond, loop3_cond, ..., rest_condition: But I couldn't think of good uses past the first two that are obvious so I trimmed it down to just enter_condition and exit_condition which keeps it simple. But from this example you can see they are all really just top of the loop tests done in sequence. A do loop is just a matter of having the first one evaluate as True. The current while condition is an entry condition the first time it's evaluated and an exit condition on the rest. So by splitting it in two, we can specify an enter and exit test more explicitly. There's a certain consistency I like about this also. Is it just getting around or finding a nice alternative to the comma that is the biggest problem with this? Maybe just using "then" would work? while cond1 then cond2: Cheers, Ron ___ 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] PEP 355 status
On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > It would be terrific if you gave us some clue about what is wrong in PEP355, > so > that the next guy does not waste his time. For instance, I find PEP355 > incredibly good for my own path manipulation (much cleaner and concise than > the > awful os.path+os+shutil+stat mix), and I have trouble understanding what is > *so* wrong with it. > > You said "it's an amalgam of unrelated functionality", but you didn't say what > exactly is "unrelated" for you. Sorry, no time. But others in this thread clearly agreed with me, so they can guide you. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] difficulty of implementing phase 2 of PEP 302 in Python source
Hi Brett, On Wed, Sep 27, 2006 at 02:11:30PM -0700, Brett Cannon wrote: > is so bad that it is worth trying to re-implement the import semantics in > pure Python or if in the name of time to just work with the C code. In the name of time, sanity and usefulness, rewriting the expected semantics in Python would be a major good idea IMHO. I can cite many projects that have reimplemented half of the semantics in Python (runpy.py, the 'py' lib, PyPy...), but none that completed them. Having such a complete implementation available in the first place would be helpful. 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
[Python-Dev] OT: How many other people got this spam?
I was wondering: how many other people who maintain websites (well: "maintain" might be a bit of a misnomer in my case:-) related to Python have also got this spam? Begin forwarded message: > From: "Snake Tracks" <[EMAIL PROTECTED]> > Date: October 1, 2006 21:21:45 GMT+02:00 > To: Cwi <[EMAIL PROTECTED]> > Subject: Special Invitation for cwi.nl from Snake Tracks > > Fellow Website Owner/Operator; > > As of September 29th, 2006 we will be launching what is soon to be the > worlds largest snake enthusiast website. The website contains > valuable > information for all those interested in snakes including care sheets, > species information and identification, breeding information, and an > extensive list of snake specific forums. > > We welcome you to visit our website and join our community of snake > enthusiasts worldwide. Currently we are browsing through Google and > other major search engines looking for websites we feel would make > good > link partners. I have personally come across your site and think that > exchanging links could benefit both of our businesses. By linking > to us > you will receive a reciprocal link and be showcased in front of all > our > visitors. > > If you are interested in this partnership please add one of the > following text links or banners to a high traffic area on your > website: > > 1) Snake Tracks - The Worlds Largest Snake Enthusiast Website. Visit > our site for care sheets, species information, field herping > information, breeding, captive care, and our extensive list of snake > enthusiast forums. > > 2) Snake Tracks Forums - Visit the Worlds Largest Collection of Snake > Enthusiast forums including our field herping, captive care, habitat > design, and regional forums. > > 3) Snake Care Sheets - Visit the Worlds Largest Snake Enthusiast > Website. Forums, Care Sheets, Field Herping, Species information and > more. > > You may also visit our link page to choose from several banner images > and text links. Once you have linked to our website, fill out the > form > and we will add your site to our directory. > > http://www.snaketracks.com/linktous.html > > I look forward to hearing from you in regards to this email. Please > allow up to 24 hours for a response as we are currently receiving > extremely large amounts of email. > > Sincerely; > Blair Russell - Snaketracks.com > -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ 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] OT: How many other people got this spam?
Jack Jansen wrote: > I was wondering: how many other people who maintain websites (well: > "maintain" might be a bit of a misnomer in my case:-) related to > Python have also got this spam? I got it. I was rather amused that they claim to have been "looking for sites that would make good link partners" when obviously no human eye of theirs has actually seen my site. Addressing me as "Canterbury" in the To: line wasn't a good sign either. :-) I'm tempted to take them up on the offer and see whether they actually make a link to my site from theirs... -- 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
Re: [Python-Dev] OT: How many other people got this spam?
Jack Jansen wrote: > I was wondering: how many other people who maintain websites (well: > "maintain" might be a bit of a misnomer in my case:-) related to > Python have also got this spam? probably everyone. I've gotten two copies, this far. ___ 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
