Re: [Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?
Martin v. Löwis schrieb: > b) IIRC, upx was used to compress these executables. I don't think the >the current build process covers this, yet (but then, the current >binaries might not be compressed with upx anymore, either - not >sure whether that would be a bug). Of course, upx would probably >not currently apply to Win64-amd64. The 9.0 binary hasn't been compressed with upx (yet). Christian ___ 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] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows)
On Sat, Apr 5, 2008 at 1:22 PM, Trent Nelson <[EMAIL PROTECTED]> wrote: > Nod, if SO_EXCLUSIVEADDRUSE is used instead in the code I posted, Windows > raises EADDRINUSE on the second bind(). I don't have access to any Linux > boxes at the moment, so I can't test what sort of error is raised with the > example I posted if listen() and accept() are called on the two sockets bound > to identical addresses. Can anyone else shed some light on this? I'd be > interested in knowing if the process wedges on Linux as badly as it does on > Windows (to the point where it's not respecting ctrl-c or sigkill). When I call sock1.listen(5) after sock1.bind(), the test passes for me on SuSE Linux 10.1 Thanks, Raghu ___ 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] New project : Spyke python-to-C compiler
"Rahul Garg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Note this message has been posted to numpy-discussion and python-dev. | Sorry for the multiple posting but I thought both python devs and | numpy users will be interested. If you believe your list should not | receive this email, let me know. Also I just wanted to introduce | myself since I may ask doubts about Python and Numpy internals from | time to time :) Pydev is for discussion about development of future versions of Python (ie, 2.6 and some of 3.0). I think this would have been better posted on comp.lang.python (or gmane.comp.python.general or the corresponding mailing list). You can get answers about current Python internals there. ___ 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] configure error: "rm: conftest.dSYM: is a directory"
[EMAIL PROTECTED] wrote: > >> Note the "rm: conftest.dSYM: is a directory". This occurred a few > >> times during the configure process. Didn't cause it to conk out, but > >> is annoying. > > Brett> I am assuming this is on your OS X machine, Skip? > > Yes, sorry. I forgot to mention that. As long as someone else sees it and > feels fine to ignore it, I'm fine with it. I suspect it's a configure > problem anyway, not a Python problem. I've seen it with just about every ./configure script on OS X 10.5. It's not specific to Python, and I haven't seen it cause any actual problems. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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 3000: Special type for object attributes & map keys
Without an implementation and supporting profile data nobody is going to believe that you can do name lookup faster than with the built-in dict type in CPython. Note that names seen by the parser are already interned, so most of what you seem to be proposing is already implemented... On Wed, Mar 5, 2008 at 2:27 PM, Henrik Vendelbo <[EMAIL PROTECTED]> wrote: > It appears to me that if you can make mapping mechanisms faster in > Python you can make significant > overall speed improvements. I also think the proposed concept could > add flexibility to persistence formats > and RMI interfaces. > > My basic idea is to have a constant string type with an interpreter > globally unique hash. If the original constant > is created in a manner different from string constants, it can be > tracked and handled differently by the interpreter. > > Obviously most object attribute references are done with the dot > operator, so I guess the interpreter already has > an efficient mapping mechanism. But there must be a crossover with > __getattr__ etc, where a map of some sort is > used. I imagine that having a global namespace to translate attribute > names into integers could be used for several > purposes by the interpreter as well as an application exchanging > objects with other applications. > > I imagine these expressions to be supported: > * attrname(string) - creates an attrname value from the string > * int(attrname) - gets the hash value > * string(attrname) - gets the string value > > Hope this makes sense > > Henrik > > P.S. I originally thought of this in a JavaScript context so forgive > me if this would make little difference in Python. > ___ > 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/guido%40python.org > -- --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] [Distutils] Remove "current" Windows executables from Lib/distutils/command in svn?
On 06/04/2008, at 2:15 AM, Martin v. Löwis wrote: > a) how does the binary get into the release tarball? You might argue >that it doesn't have to, as it is sufficient when it is included in >the Windows installer, however, as currently implemented, >bdist_wininst also runs on Unix, and people use it that way. It would be a shame to lose this ability. It's very handy. d ___ 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] python source code
I am interested in understanding the python source code. Can someone direct me to resources (documentation,book,archive of mailling lists,etc) that will assist me ? Thank you, Avi -- Avi Kohn ___ 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] [Numpy-discussion] New project : Spyke python-to-C compiler
> (Though as the saying goes, little duplication is normal (and perhaps > wanted) for open source software.) Sorry! I meant "a little", completely reversing the meaning of my sentence. Dag Sverre ___ 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] [Numpy-discussion] New project : Spyke python-to-C compiler
> What is Spyke? > In many performance critical projects, it is often necessary to > rewrite parts of the application in C. However writing C wrappers can > be time consuming. Spyke offers an alternative approach. You add > annotations to your Python code as strings. These strings are > discarded by the Python > interpreter but these are interpreted as types by Spyke compiler to > convert to C. Have you had a look at Cython? http://cython.org. >From seeing what you write, it looks like we have almost exactly the same long-term goals; one could almost say that the two pieces of software will be complete duplicates in functionality. (Cython isn't "there" just yet though.) (Though as the saying goes, little duplication is normal (and perhaps wanted) for open source software.) Dag Sverre ___ 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] New project : Spyke python-to-C compiler
[snip] > > > > c) Strings as type declarations : Do you think I should use decorators > instead at least for function type declarations? You might be interested in 3.0's (and maybe 2.6's) function annotations. See PEP 3107. > > > thanks for patiently reading this, > comments and inquiries sought. > rahul > ___ > 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/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson ___ 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 representation of range in 3.0
Hi, I use Python in my CS1 and CS2 curriculum and I have a question. As I've been using the Python 3.0 alphas one of the things that I am bothered by is that I cannot see the sequence produced by range without introducing students to the list() function. I typically introduce range on day 1 of class and show students what it produces without making a big deal out of the fact that it creates a list. They all accept this and things work out nicely when I introduce lists for real in a week or two. My question is why couldn't the __str__ method for the range object be more friendly and show a representation of the sequence? I understand why __repr__ should return range(0,10) for an object created using range(10) but couldn't print(range(10)) produce [0, 1, 2, ... 9] The ... could even be used if the sequence were excessively wrong. If this is acceptable, I would be happy to accept the challenge of providing a patch. Thanks, Brad ___ 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 representation of range in 3.0
I'd object to it returning something that resembles a list too closely, but I could live with str(range(3)) return <0, 1, 2>. We should probably have a cutoff so that if there are more than 6 values it'll show the first 3 values, then dots, then the last 2 values. (The cutoff would be computed so that '...' always represents at least 2 values. On Mon, Apr 7, 2008 at 4:14 PM, Brad Miller <[EMAIL PROTECTED]> wrote: > Hi, > > I use Python in my CS1 and CS2 curriculum and I have a question. > As I've been using the Python 3.0 alphas one of the things that I am > bothered by is that I cannot see the sequence produced by range > without introducing students to the list() function. > > I typically introduce range on day 1 of class and show students what > it produces without making a big deal out of the fact that it creates > a list. They all accept this and things work out nicely when I > introduce lists for real in a week or two. > > My question is why couldn't the __str__ method for the range object be > more friendly and show a representation of the sequence? I understand > why __repr__ should return range(0,10) for an object created using > range(10) but couldn't print(range(10)) produce [0, 1, 2, ... 9] > The ... could even be used if the sequence were excessively wrong. > > If this is acceptable, I would be happy to accept the challenge of > providing a patch. > > Thanks, > > Brad > > > ___ > 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/guido%40python.org > -- --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] python source code
On Sun, Apr 6, 2008 at 11:58 PM, Avi Kohn <[EMAIL PROTECTED]> wrote: > I am interested in understanding the python source code. Can someone > direct me to resources (documentation,book,archive of mailling lists,etc) > that will assist me ? > What part(s) do you want to learn about? The CPython interpreter is quite huge. I recommend you ask the comp.lang.python mailing list for further advice. > Thank you, > Avi > > -- > Avi Kohn > > ___ > 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/musiccomposition%40gmail.com > > -- Cheers, Benjamin Peterson ___ 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] unittest's redundant assertions: asserts vs. failIf/Unlesses
On Wed, Mar 19, 2008 at 5:16 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On Wed, Mar 19, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote: > > > > On 02:21 pm, [EMAIL PROTECTED] wrote: > > >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine > > >>with me. > > > > > >This strikes me as a gratuitous API change of the kind Guido was > > >warning about in his recent post: "Don't change your APIs incompatibly > > >when porting to Py3k" > > > > I agree emphatically. Actually I think this is the most extreme case. > > The unit test stuff should be as stable as humanly possible between 2 > > and 3, moreso than any other library. > > This is convincing for me. Move my +1 back to 3.1. Same here; let's tread carefully here and not change this with 3.0. Starting to deprecate in 3.1 and killing in 3.3 would be soon enough. I like using only the assertKeyword variants, removing assert_, fail*, and assertEquals. However I don't like changing assertTrue and assertFalse to insist that the value is exactly True or False -- if you really care that much, let's add assertIs(x, y) which asserts that x and y are the same object. I also think that all tests should use the operator their name implies, e.g. assertEqual(x, y) should do something like if x == y: pass else: raise AssertionError(...) rather than if x != y: raise AssertionError(...) Someone please open a bug for this task. -- --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] unittest's redundant assertions: asserts vs. failIf/Unlesses
On Mon, Apr 7, 2008 at 7:37 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Wed, Mar 19, 2008 at 5:16 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 19, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote: > > > > > > On 02:21 pm, [EMAIL PROTECTED] wrote: > > > >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine > > > >>with me. > > > > > > > >This strikes me as a gratuitous API change of the kind Guido was > > > >warning about in his recent post: "Don't change your APIs incompatibly > > > >when porting to Py3k" > > > > > > I agree emphatically. Actually I think this is the most extreme case. > > > The unit test stuff should be as stable as humanly possible between 2 > > > and 3, moreso than any other library. > > > > This is convincing for me. Move my +1 back to 3.1. > > Same here; let's tread carefully here and not change this with 3.0. > Starting to deprecate in 3.1 and killing in 3.3 would be soon enough. > I like using only the assertKeyword variants, removing assert_, fail*, > and assertEquals. However I don't like changing assertTrue and > assertFalse to insist that the value is exactly True or False -- if > you really care that much, let's add assertIs(x, y) which asserts that > x and y are the same object. I also think that all tests should use > the operator their name implies, e.g. assertEqual(x, y) should do > something like > > if x == y: > pass > else: > raise AssertionError(...) > > rather than > > if x != y: > raise AssertionError(...) > > Someone please open a bug for this task. See 2578. > > -- > --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/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson ___ 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
