Re: [Python-Dev] status of development documentation
Fredrik Lundh wrote: > or is it time to move away from the current "odd-format-with-extensive- > semantic-markup-that-nobody-uses-and-only-a-few-people-fully-under- > stand" approach to something quicker and dirtier [1] ? If you just want to know what your changes look like: type "make html" in the Doc directory, and wait a moment for it to complete. I get xml.etree as section 13.13. 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] Sets are mappings?
Aahz wrote: > On Tue, Dec 20, 2005, M.-A. Lemburg wrote: >> Josiah Carlson wrote: >>> New superclasses for all built-in types (except for string and unicode, >>> which already subclass from basestring). >>> >>> int, float, complex (long) : subclass from basenumber >>> tuple, list, set : subclass from basesequence >>> dict : subclass from basemapping >> set should be under basemapping. > > Are you sure? Sets are not actually a mapping; they consist only of > keys. You're right, sets should really have a separate base class. However, in reality they behave mostly like dictionaries using (and hiding) a common value of all keys. > The Python docs do not include sets under maps, and sets do not > support some of the standard mapping methods (notably keys()). Raymond > Hettinger has also talked about switching to a different internal > structure for sets. basestring is an abstract class in the sense that it doesn't provide any interface on its own. I guess the others should use the same approach. They are usually only used for quickly checking for an interface or "type property". Note that unicode and strings don't share a common implementation either - they just happen to expose a rather similar interface. > (Should this discussion move to c.l.py? Normally I'd think so, but I > think it's critical that the core developers agree about this. It's > also critical for me to know because I'm writing a book, but that's not > reason enough to stick with python-dev. ;-) Not sure about others. I rarely read c.l.p. Even pydev has enough traffic these days to require filtering. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 21 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Sets are mappings?
On Tue, Dec 20, 2005, M.-A. Lemburg wrote: > Josiah Carlson wrote: >> >> New superclasses for all built-in types (except for string and unicode, >> which already subclass from basestring). >> >> int, float, complex (long) : subclass from basenumber >> tuple, list, set : subclass from basesequence >> dict : subclass from basemapping > > set should be under basemapping. Are you sure? Sets are not actually a mapping; they consist only of keys. The Python docs do not include sets under maps, and sets do not support some of the standard mapping methods (notably keys()). Raymond Hettinger has also talked about switching to a different internal structure for sets. (Should this discussion move to c.l.py? Normally I'd think so, but I think it's critical that the core developers agree about this. It's also critical for me to know because I'm writing a book, but that's not reason enough to stick with python-dev. ;-) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck." --USENET schmuck (aka Robert Kern) ___ 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] Keep default comparisons - or add a second set?
Josiah Carlson wrote: > Jim Fulton <[EMAIL PROTECTED]> wrote: >> Jim Jewett wrote: >>> PEP 3000 now suggests that dropping default comparison has become more >>> than an idle what-if. >>> >>> Unfortunately, one very common use case of comparisons is to get a >>> canonical order. If the order is sensible, all the better, but that >>> is not strictly required. One of Python's selling points (especially >>> compared to Java) is that getting a canonical order "just works", even >>> if the objects being sorted are not carefully homogenized by hand. >>> Python itself relies on this when comparing same-length dictionaries. >>> >>> There are times when a specific comparison doesn't make sense (date vs >>> a datetime that it includes), but these are corner cases best handled >>> by the specific class that understands the specific requirements -- >>> classes that already have to override the comparison operators anyhow. >>> >>> Even the recently posted "get rid of default comparisons" use case is >>> really just an argument to make the canonical ordering work better. >>> The problem Jim Fulton describes is that the (current default) >>> canonical order will change if objects are saved to a database and >>> then imported to a different session. Removing default comparisons >>> wouldn't really help much; the errors would (sometimes) show up at >>> saving instead of (maybe) at loading, but the solution would still be >>> to handcode a default comparison for every single class individually. >> I think you need to do a much better job of defining canonical ordering. >> >> You've given two properties: >> >> - It need not make sense. :) >> >> - It must be consistent accross sessions >> >>Does this also mean accross different versions of Python? >> >>How about different operating systems and hardware? >> >>If I create and pickle a BTree with a bunch of object keys >>and reload that pickle in a different session, with a >>later version of Python on a different OS and Hardware >>architecture, will the keys still have the same order? >> >>I consider (obviously) this second property to be crucial. >> >> Do you have any proposal for how to achieve these properties? > > New superclasses for all built-in types (except for string and unicode, > which already subclass from basestring). > > int, float, complex (long) : subclass from basenumber > tuple, list, set : subclass from basesequence > dict : subclass from basemapping set should be under basemapping. > The idea is that each of the above classes define a group in which items > are comparable. If you end up in a situation in which the base classes > of the compared object differ (and hence are not comparable directly by > value), you compare their base class name. Because their base classes > differ, you always get a reliable differentiation between groups. Python already uses this "trick" based on the type name. If that still doesn't help, id(object) is used which is what JimF is criticizing (I presume). > What about comparisons between user-defined classes (classic or subclass > of object)? Presumably if a user wanted something to be compared > against integers, floats, or complex, the user would subclass from > basenumber, etc. ... and get all kinds of weird side-effects. A user probably doesn't want these :-) > If the user only wanted their objects to compare > against objects of its own type, they compose their own __cmp__ or > related methods on their class, and they get this behavior 'for free'. > > The only thing necessary for canonical ordering persistancy is that the > content of an object define its behavior in comparison operators, and > that pickle knows how to save and restore this content reliably. Actually, the only thing necessary for *persisting* order is making sure that the persistence logic maintains order across pickling. Note that this is a completely different requirement than making sure that the outcome of list.sort() is the same across platforms and sessions. > Note that one can remove the superclass requirement with a smart cmp() > builtin to automatically choose the comparable group. > > > This is not perfect, but it is an idea, and it would allow a reliable > canonical ordering. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 20 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Keep default comparisons - or add a second set?
Jim Fulton <[EMAIL PROTECTED]> wrote: > > Jim Jewett wrote: > > PEP 3000 now suggests that dropping default comparison has become more > > than an idle what-if. > > > > Unfortunately, one very common use case of comparisons is to get a > > canonical order. If the order is sensible, all the better, but that > > is not strictly required. One of Python's selling points (especially > > compared to Java) is that getting a canonical order "just works", even > > if the objects being sorted are not carefully homogenized by hand. > > Python itself relies on this when comparing same-length dictionaries. > > > > There are times when a specific comparison doesn't make sense (date vs > > a datetime that it includes), but these are corner cases best handled > > by the specific class that understands the specific requirements -- > > classes that already have to override the comparison operators anyhow. > > > > Even the recently posted "get rid of default comparisons" use case is > > really just an argument to make the canonical ordering work better. > > The problem Jim Fulton describes is that the (current default) > > canonical order will change if objects are saved to a database and > > then imported to a different session. Removing default comparisons > > wouldn't really help much; the errors would (sometimes) show up at > > saving instead of (maybe) at loading, but the solution would still be > > to handcode a default comparison for every single class individually. > > I think you need to do a much better job of defining canonical ordering. > > You've given two properties: > > - It need not make sense. :) > > - It must be consistent accross sessions > >Does this also mean accross different versions of Python? > >How about different operating systems and hardware? > >If I create and pickle a BTree with a bunch of object keys >and reload that pickle in a different session, with a >later version of Python on a different OS and Hardware >architecture, will the keys still have the same order? > >I consider (obviously) this second property to be crucial. > > Do you have any proposal for how to achieve these properties? New superclasses for all built-in types (except for string and unicode, which already subclass from basestring). int, float, complex (long) : subclass from basenumber tuple, list, set : subclass from basesequence dict : subclass from basemapping The idea is that each of the above classes define a group in which items are comparable. If you end up in a situation in which the base classes of the compared object differ (and hence are not comparable directly by value), you compare their base class name. Because their base classes differ, you always get a reliable differentiation between groups. What about comparisons between user-defined classes (classic or subclass of object)? Presumably if a user wanted something to be compared against integers, floats, or complex, the user would subclass from basenumber, etc. If the user only wanted their objects to compare against objects of its own type, they compose their own __cmp__ or related methods on their class, and they get this behavior 'for free'. The only thing necessary for canonical ordering persistancy is that the content of an object define its behavior in comparison operators, and that pickle knows how to save and restore this content reliably. Note that one can remove the superclass requirement with a smart cmp() builtin to automatically choose the comparable group. This is not perfect, but it is an idea, and it would allow a reliable canonical ordering. - Josiah ___ 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] Fwd: a new python port: iPod
I know this is OT, but I thought y'all might find this interesting. -- n -- Forwarded message -- From: jack <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hi, I saw in http://www.python.org/download/download_other.html that people notify python ports to other platforms/devices. I ported python to iPod, and would be great that this port will appear in this section too. For more info about python port to Apple iPod see: http://www.ciberjacobo.com/en/linux_on_ipod.html Thanks. -- Jacobo Avariento Gimeno http://ciberjacobo.com OpenPGP key: http://ciberjacobo.com/key.pem ___ 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] os.startfile with optional second parameter
Would a patch be accepted that implemented an optional second parameter
for the os.startfile function on Windows?
Sometimes I missed the possibility to write
os.startfile("mydocs.pdf", "print")
Thomas
___
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] Build failure and problem on Windows
Building the svn trunk on Windows fails because Python\pyarena.c is missing in the pythoncore.vcproj file (I'm not yet up to speed with svn, otherwise I would have checked in a fix for this myself). Worse, when running the built exe it segfaults in Py_GetBuildInfo(), because it is picking up somehow a definition of #define BUILD 'b' (from cPickle.c? Could that be?) Thomas ___ 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] Build failure and problem on Windows
Thomas Heller <[EMAIL PROTECTED]> writes: > Building the svn trunk on Windows fails because Python\pyarena.c is > missing in the pythoncore.vcproj file (I'm not yet up to speed with svn, > otherwise I would have checked in a fix for this myself). > > Worse, when running the built exe it segfaults in Py_GetBuildInfo(), > because it is picking up somehow a definition of #define BUILD 'b' (from > cPickle.c? Could that be?) I should have known better, but BUILD is defined in the MSVC project file as BUILD=60. Thomas ___ 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] (no subject)
sir i have taken softwer from icashline.com that is mass mailing softwere is worldcast that is not running it is showing that I/O PROBLEM OR MEDIA PRO BLEM. PLEASE HELP ME.Send instant messages to your online friends http://in.messenger.yahoo.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] Keep default comparisons - or add a second set?
On 12/19/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Michael Urman <[EMAIL PROTECTED]> wrote: > > Such as sorted(stuff, key=id)? > > I believe that ideally, canonical orderings would be persistant across > sessions. Erm, yes, I totally missed that in Jim's original preferred requirements. And I nearly wrote another response ignoring Jim's use case of persistence, as I'm having trouble thinking of any (others) where order matters yet comparability doesn't. 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] fixing log messages
Fredrik Lundh wrote: > Steve Holden wrote: > > >>>I'd say that any spelling with more than 500,000 google hits is perfectly >>>valid... >>> >> >>Anything you say, Frederick ... >> >>thirteen-million-google-hits-can't-possibly-be-wrong-ly y'rs - steve > > > oh, frederick is a perfectly valid english spelling of the germanic name > "Friedrich", > but only ~200 google hits use that name to refer to me. > > (but alright, as long as you don't call me "Fred"...) > Did I *ever* do that? That would have been an embarrassing slip ;-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] fixing log messages
Steve Holden wrote: >> I'd say that any spelling with more than 500,000 google hits is perfectly >> valid... >> > Anything you say, Frederick ... > > thirteen-million-google-hits-can't-possibly-be-wrong-ly y'rs - steve oh, frederick is a perfectly valid english spelling of the germanic name "Friedrich", but only ~200 google hits use that name to refer to me. (but alright, as long as you don't call me "Fred"...) ___ 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] Keep default comparisons - or add a second set?
Jim Jewett wrote: > PEP 3000 now suggests that dropping default comparison has become more > than an idle what-if. > > Unfortunately, one very common use case of comparisons is to get a > canonical order. If the order is sensible, all the better, but that > is not strictly required. One of Python's selling points (especially > compared to Java) is that getting a canonical order "just works", even > if the objects being sorted are not carefully homogenized by hand. > Python itself relies on this when comparing same-length dictionaries. > > There are times when a specific comparison doesn't make sense (date vs > a datetime that it includes), but these are corner cases best handled > by the specific class that understands the specific requirements -- > classes that already have to override the comparison operators anyhow. > > Even the recently posted "get rid of default comparisons" use case is > really just an argument to make the canonical ordering work better. > The problem Jim Fulton describes is that the (current default) > canonical order will change if objects are saved to a database and > then imported to a different session. Removing default comparisons > wouldn't really help much; the errors would (sometimes) show up at > saving instead of (maybe) at loading, but the solution would still be > to handcode a default comparison for every single class individually. I think you need to do a much better job of defining canonical ordering. You've given two properties: - It need not make sense. :) - It must be consistent accross sessions Does this also mean accross different versions of Python? How about different operating systems and hardware? If I create and pickle a BTree with a bunch of object keys and reload that pickle in a different session, with a later version of Python on a different OS and Hardware architecture, will the keys still have the same order? I consider (obviously) this second property to be crucial. Do you have any proposal for how to achieve these properties? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.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] fixing log messages
Fredrik Lundh wrote: > Steve Holden wrote: > > >>That's "embarrassing", by the way. You're obviously having a bad >>spelling day :-) > > > I'd say that any spelling with more than 500,000 google hits is perfectly > valid... > Anything you say, Frederick ... thirteen-million-google-hits-can't-possibly-be-wrong-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] status of development documentation
the "Documentation Development" page at http://www.python.org/dev/doc/ contains a link to a "SVN trunk" version which was last updated nearly four months ago. what would it take to automatically update the trunk docs, say, once a day or so ? or is it time to move away from the current "odd-format-with-extensive- semantic-markup-that-nobody-uses-and-only-a-few-people-fully-under- stand" approach to something quicker and dirtier [1] ? 1) http://microformats.org/wiki/microformats ___ 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] fixing log messages
Steve Holden wrote: > That's "embarrassing", by the way. You're obviously having a bad > spelling day :-) I'd say that any spelling with more than 500,000 google hits is perfectly valid... ___ 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] Expose Subversion revision number to Python
"LD 'Gus' Landis" <[EMAIL PROTECTED]> writes: > Hi, > > So, what does one get when built on a system not connected to > the net? say from a tarball? Um, the two things you mention are unrelated. svnversion doesn't access the network, so the first thing is moot. For the second, we've talked about that already, though I'm not entirely sure what the conclusion was... > It can happen, ya know. Yes, we know! Cheers, mwh -- Windows installation day one. Getting rid of the old windows was easy - they fell apart quite happily, and certainly wont be re-installable anywhere else. -- http://www.linux.org.uk/diary/ (not *that* sort of windows...) ___ 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] Expose Subversion revision number to Python
Hi, So, what does one get when built on a system not connected to the net? say from a tarball? It can happen, ya know. Cheers, --ldl On 12/18/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Barry Warsaw wrote: > > Yes, here's my thought: I have a mod to Makefile.pre.in and > > getbuildinfo.c so that when we don't find .svn directory, we don't > > define the BUILD macro when we compile getbuildinfo.c. Then, in that > > file we have something like: > > > > #ifndef BUILD > > #define BUILD "$Revision$" > > #endif > > What does that achieve? It will give you the latest revision at which > getbuildinfo was changed (currently 41744). > > 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/ldlandis%40gmail.com > -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ 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
