Re: [Python-Dev] PEP submission broken?
Bryan Olson wrote: > From what I can tell, We need to address fixing the > PEP process before there is any point in working on PEP's, I think this is a somewhat fair point (although perhaps a bit overstated) - David and Barry can be busy IRL, which can certainly slow down the process of PEP submission. PEP 328 hung in limbo for a while on that basis (I'm going to have to look into if and how PEP 328 relates to Python eggs one of these days. . .). Would it be worth having a PEP category on the RFE tracker, rather than submitting pre-PEP's directly to the PEP editors? The process still wouldn't be perfect, but it would widen the pool of people that can bring a pre-PEP to the attention of python-dev. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Should the default equality operator compare values instead of identities?
How would the value equality operator deal with recursive objects? class Foo: def __init__(self): self.foo = self Seems to me that it would take atleast some special-casing to get Foo() == Foo() to evalute to True in this case... -- mvh Björn ___ 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] For Python 3k, drop default/implicit hash, and comparison
Two more thoughts in this thread. (1) The "key" idiom is a great pattern but I don't think it would work well to make it a standard language API. (2) I'm changing my mind about the default hash(). The original default hash() (which would raise TypeError if __eq__ was overridden but __hash__ was not) is actually quite useful in some situations. Basically, simplifying a bit, there are two types of objects: those that represent *values* and those that do not. For value-ish objects, overriding __eq__ is common and then __hash__ needs to be overridden in order to get the proper dict and set behavior. In a sense, __eq__ defines an "equivalence class" in the mathematical sense. But in many applications I've used objects for which object identity is important. Let me construct a hypothetical example: suppose we represent a car and its parts as objects. Let's say each wheel is an object. Each wheel is unique and we don't have equivalency classes for them. However, it would be useful to construct sets of wheels (e.g. the set of wheels currently on my car that have never had a flat tire). Python sets use hashing just like dicts. The original hash() and __eq__ implementation would work exactly right for this purpose, and it seems silly to have to add it to every object type that could possibly be used as a set member (especially since this means that if a third party library creates objects for you that don't implement __hash__ you'd have a hard time of adding it). In short, I agree something's broken, but the fix should not be to remove the default __hash__ and __eq__ altogether. Instead, the default __hash__ should be made smarter (and perhaps the only way to do this is to build the smarts into hash() again). I do agree that __cmp__, __gt__ etc. should be left undefined by default. All of this is Python 3000 only. -- --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
[Python-Dev] cross-compiling
We've been having some issues and discussions at work about cross compiling. There are various people that have tried (are) cross compiling python. Right now the support kinda sucks due to a couple of reasons. First, distutils is required to build all the modules. This means that python must be built twice. Once for the target machine and once for the host machine. The host machine is really not desired since it's only purpose is to run distutils. I don't know the history of why distutils is used. I haven't had much of an issue with it since I've never needed to cross compile. What are the issues with not requiring python to be built on the host machine (ie, not using distutils)? Second, in configure we try to run little programs (AC_TRY_RUN) to determine what to set. I don't know of any good alternative but to force those to be defined manually for cross-compiled environments. Any suggestions here? I'm thinking we can skip the the AC_TRY_RUNs if host != target and we pickup the answers to those from a user supplied file. I'm *not* suggesting that normal builds see any change in behaviour. Nothing will change for most developers. ie, ./configure ; make ; ./python will continue to work the same. I only want to make it possible to cross compile python by building it only on the target platform. n PS. I would be interested to hear from others who are doing cross compiling and know more about it than me. ___ 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] cross-compiling
I know some folks have successfully used cross-compilation before. But this was in a distant past. There was some support for it in the configure script; surely you're using that? I believe it lets you specify defaults for the TRY_RUN macros. But it's probably very primitive. About using distutils to build the extensions, this is because some extensions require quite a bit of logic to determine the build commands (e.g. look at BSDDB or Tkinter). There was a pre-distutils way of building extensions using Modules/Setup* but this required extensive manual editing if tools weren't in the place where they were expected, and they never were. I don't have time to look into this further right now, but I hope I will in the future. Keep me posted! --Guido On 11/7/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > We've been having some issues and discussions at work about cross > compiling. There are various people that have tried (are) cross > compiling python. Right now the support kinda sucks due to a couple > of reasons. > > First, distutils is required to build all the modules. This means > that python must be built twice. Once for the target machine and once > for the host machine. The host machine is really not desired since > it's only purpose is to run distutils. I don't know the history of > why distutils is used. I haven't had much of an issue with it since > I've never needed to cross compile. What are the issues with not > requiring python to be built on the host machine (ie, not using > distutils)? > > Second, in configure we try to run little programs (AC_TRY_RUN) to > determine what to set. I don't know of any good alternative but to > force those to be defined manually for cross-compiled environments. > Any suggestions here? I'm thinking we can skip the the AC_TRY_RUNs > if host != target and we pickup the answers to those from a user > supplied file. > > I'm *not* suggesting that normal builds see any change in behaviour. > Nothing will change for most developers. ie, ./configure ; make ; > ./python will continue to work the same. I only want to make it > possible to cross compile python by building it only on the target > platform. > > n > > PS. I would be interested to hear from others who are doing cross > compiling and know more about it than me. > ___ > 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
[Python-Dev] [OTAnn] Feedback
I was interested in getting feedback from current mail group users.We have mirrored your mail list in a new application that provides a more aggregated and safe environment which utilizes the power of broadband.Roomity.com v 1.5 is a web 2.01 community webapp. Our newest version adds broadcast video and social networking such as favorite authors and an html editor.It?s free to join and any feedback would be appreciated.S.--Broadband interface (RIA) + mail box saftey = Python_Core_Developers_List.roomity.com*Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131397871425~~--___ 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] cross-compiling
On 11/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > About using distutils to build the extensions, this is because some > extensions require quite a bit of logic to determine the build > commands (e.g. look at BSDDB or Tkinter). There was a pre-distutils > way of building extensions using Modules/Setup* but this required > extensive manual editing if tools weren't in the place where they were > expected, and they never were. I think part of the problem is that setup.py has a bunch of heuristics that are intended to do the right thing without user intervention. If, on the other hand, the user wants to intervene, because "the right thing" is wrong for cross-compiling, you are kind of stuck. I don't think there is an obvious way to select the extension modules to build and the C libraries for them to link against. Jeremy ___ 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] cross-compiling
On 11/7/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > We've been having some issues and discussions at work about cross > compiling. There are various people that have tried (are) cross > compiling python. Right now the support kinda sucks due to a couple > of reasons. This might make a good sprint topic. Maybe your employer might be willing to get some people to come to hack on this? I know I wouldn't mind seeing the whole build process cleaned up. It works well enough, but I think some things could stand to be updated (speaking from experience of adding EXTRA_CFLAGS to the build process), such as setup.py being made more modular. -Brett ___ 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] cross-compiling
On Mon, 2005-11-07 at 16:38, Jeremy Hylton wrote: > I think part of the problem is that setup.py has a bunch of heuristics > that are intended to do the right thing without user intervention. > If, on the other hand, the user wants to intervene, because "the right > thing" is wrong for cross-compiling, you are kind of stuck. I don't > think there is an obvious way to select the extension modules to build > and the C libraries for them to link against. This relates to an issue we've had to workaround with the distutils based module builds in Python. For some of the modules, we want the auto-detection code to find versions of dependent libraries in locations other than the "standard" system locations. I don't think there's a good way to convince the various setup.py scripts to look elsewhere for things, short of modifying the code. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Should the default equality operator compare values instead of identities?
BJörn Lindqvist wrote: > How would the value equality operator deal with recursive objects? > > class Foo: > def __init__(self): > self.foo = self > > Seems to me that it would take atleast some special-casing to get > Foo() == Foo() to evalute to True in this case... This is sort-of supported today: >>> a=[] >>> a.append(a) >>> b=[] >>> b.append(b) >>> a == b True 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] cross-compiling
Neal Norwitz wrote: > First, distutils is required to build all the modules. As Guido already suggests, this assertion is false. In a cross-compilation environment, I would try to avoid distutils, and indeed, the build process to do so is still supported. > Second, in configure we try to run little programs (AC_TRY_RUN) to > determine what to set. I don't know of any good alternative but to > force those to be defined manually for cross-compiled environments. > Any suggestions here? I'm thinking we can skip the the AC_TRY_RUNs > if host != target and we pickup the answers to those from a user > supplied file. You shouldn't be required to do that. Instead, just edit pyconfig.h manually, to match the target. autoconf is designed to support that. It would help if Makefile was target-independent (only host-dependent). Not sure whether this is the case. 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] cross-compiling
Jeremy Hylton wrote: > I think part of the problem is that setup.py has a bunch of heuristics > that are intended to do the right thing without user intervention. > If, on the other hand, the user wants to intervene, because "the right > thing" is wrong for cross-compiling, you are kind of stuck. I don't > think there is an obvious way to select the extension modules to build > and the C libraries for them to link against. Of course there is: Modules/Setup. 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] Should the default equality operator compare values instead of identities?
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > BJörn Lindqvist wrote: >> How would the value equality operator deal with recursive objects? >> >> class Foo: >> def __init__(self): >> self.foo = self >> >> Seems to me that it would take atleast some special-casing to get >> Foo() == Foo() to evalute to True in this case... > > This is sort-of supported today: > > >>> a=[] > >>> a.append(a) > >>> b=[] > >>> b.append(b) > >>> a == b > True Uh, I think this changed in Python 2.4: >>> a = [] >>> a.append(a) >>> b = [] >>> b.append(b) >>> a == b Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion depth exceeded in cmp Cheers, mwh -- First of all, email me your AOL password as a security measure. You may find that won't be able to connect to the 'net for a while. This is normal. The next thing to do is turn your computer upside down and shake it to reboot it. -- Darren Tucker, asr ___ 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 : 365 open ( +5) / 2961 closed ( +5) / 3326 total (+10) Bugs: 904 open (+11) / 5367 closed (+14) / 6271 total (+25) RFE : 200 open ( +1) / 189 closed ( +0) / 389 total ( +1) New / Reopened Patches __ new function: os.path.relpath (2005-10-27) http://python.org/sf/1339796 opened by Richard Barran commands.getstatusoutput() (2005-11-02) http://python.org/sf/1346211 opened by Dawa Lama Better dead code elimination for the AST compiler (2005-11-02) http://python.org/sf/1346214 opened by Rune Holm A constant folding optimization pass for the AST (2005-11-02) http://python.org/sf/1346238 opened by Rune Holm Remove inconsistent behavior between import and zipimport (2005-11-03) http://python.org/sf/1346572 opened by Osvaldo Santana Neto Patch f. bug 495682 cannot handle http_proxy with user:pass@ (2005-11-05) CLOSED http://python.org/sf/1349117 opened by Johannes Nicolai Patch f. bug 495682 cannot handle http_proxy with user:pass@ (2005-11-05) http://python.org/sf/1349118 opened by Johannes Nicolai [PATCH] 100x optimization for ngettext (2005-11-06) http://python.org/sf/1349274 opened by Joe Wreschnig Fix for signal related abort in Visual Studio 2005 (2005-11-07) http://python.org/sf/1350409 opened by Adal Chiriliuc Redundant connect() call in logging.handlers.SysLogHandler (2005-11-07) http://python.org/sf/1350658 opened by Ken Lalonde Patches Closed __ tarfile.py: fix for bug #1336623 (2005-10-26) http://python.org/sf/1338314 closed by nnorwitz Python 2.4.2 doesn't build with "--without-threads" (2005-10-22) http://python.org/sf/1335054 closed by nnorwitz Speedup PyUnicode_DecodeCharmap (2005-10-05) http://python.org/sf/1313939 closed by lemburg Allow use of non-latin1 chars in interactive shell (2005-10-21) http://python.org/sf/1333679 closed by loewis Patch f. bug 495682 cannot handle http_proxy with user:pass@ (2005-11-05) http://python.org/sf/1349117 closed by birkenfeld New / Reopened Bugs ___ CVS webbrowser.py (1.40) bugs (2005-10-27) CLOSED http://python.org/sf/1339806 opened by Greg Couch TAB SETTINGS DONT WORK (win) (2005-10-27) http://python.org/sf/1339883 opened by reson5 time.strptime() with bad % code throws bad exception (2005-10-27) CLOSED http://python.org/sf/1340337 opened by Steve R. Hastings mmap does not accept length as 0 (2005-10-28) http://python.org/sf/1341031 opened by liturgist "\n" is incorrectly represented (2005-10-30) CLOSED http://python.org/sf/1341934 opened by Pavel Tkinter.Menu.delete doesn't delete command of entry (2005-10-30) http://python.org/sf/1342811 opened by Sverker Nilsson Broken docs for os.removedirs (2005-10-31) http://python.org/sf/1343671 opened by David Kågedal UNIX mmap leaks file descriptors (2005-11-01) CLOSED http://python.org/sf/1344508 opened by Erwin S. Andreasen colorsys tests, bug in frange (2005-11-01) CLOSED http://python.org/sf/1345263 opened by Rune Holm Python 2.4 and 2.3.5 won't build on OpenBSD 3.7 (2005-11-01) http://python.org/sf/1345313 opened by Dan doc typo (2005-11-02) CLOSED http://python.org/sf/1346026 opened by Keith Briggs Segfaults from unaligned loads in floatobject.c (2005-11-02) http://python.org/sf/1346144 opened by Rune Holm Missing import in documentation (2005-11-03) CLOSED http://python.org/sf/1346395 opened by Aggelos Orfanakos selectmodule.c calls PyInt_AsLong without error checking (2005-11-03) CLOSED http://python.org/sf/1346533 opened by Luke _subprocess.c calls PyInt_AsLong without error checking (2005-11-03) http://python.org/sf/1346547 opened by Luke httplib simply ignores CONTINUE (2005-11-03) http://python.org/sf/1346874 opened by Mike Looijmans FeedParser does not comply with RFC2822 (2005-11-04) http://python.org/sf/1347874 opened by Julian Phillips pydoc seems to run some scripts! (2005-11-04) http://python.org/sf/1348477 opened by Olly Betts email.Generators does not separates headers with "\r\n" (2005-11-05) http://python.org/sf/1349106 opened by Manlio Perillo xmlrpclib does not use http proxy (2005-11-06) http://python.org/sf/1349316 opened by greatred urllib.urlencode provides two features in one param (2005-11-06) http://python.org/sf/1349732 opened by Ori Avtalion urllib2 blocked from news.google.com (2005-11-07) CLOSED http://python.org/sf/1349977 opened by Michael Hoisie built-in method .__cmp__ (2005-11-07) http://python.org/sf/1350060 opened by Armin Rigo "setdlopenflags" leads to crash upon "import" (2005-11-07) http://python.org/sf/1350188 opened by John Pye CVS migration not in www.python.org docs (2005-11-07) http://pyth
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
On 7-nov-2005, at 23:34, Martin v. Löwis wrote:
> BJörn Lindqvist wrote:
>> How would the value equality operator deal with recursive objects?
>>
>> class Foo:
>> def __init__(self):
>> self.foo = self
>>
>> Seems to me that it would take atleast some special-casing to get
>> Foo() == Foo() to evalute to True in this case...
>
> This is sort-of supported today:
But only for lists ;-)
>>> a = {}
>>> a[1] = a
>>>
>>> b = {}
>>> b[1] = b
>>>
>>> a == b
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: maximum recursion depth exceeded in cmp
>>>
>
a=[]
a.append(a)
b=[]
b.append(b)
a == b
> True
>
> 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/
> ronaldoussoren%40mac.com
___
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
