From brad at allendev.com Sat Dec 1 03:37:48 2007 From: brad at allendev.com (Brad Allen) Date: Fri, 30 Nov 2007 21:37:48 -0500 Subject: [python-advocacy] Python vs Ruby on Apple site In-Reply-To: <1A079CEC-7915-429F-B72B-6D59EC7C4F9D@stabell.org> References: <5AE8861F-7F79-4EDA-A63F-F3A54AD1A687@exoweb.net> <807A3823-ABF3-4ECA-9C47-20800ABB6CD8@gmail.com> <12BDD61B-54EB-4F68-A237-7DD2397E1840@cwi.nl> <3C56A764-091B-4CFE-9CA5-DB215AFC7765@mac.com> <1A079CEC-7915-429F-B72B-6D59EC7C4F9D@stabell.org> Message-ID: At 11:20 AM +0800 11/29/07, Bj?rn Stabell wrote: > > Although their similarities are striking, these scripting languages >> do have some differences. While Python code can contain both objects >> and built-in types, in Ruby everything is an object. There are no >> primitive or built-in types, such as integers. Thus anything in Ruby >> code can accept messages. > > >I thought the type/class unification in 2.2 did away with the big >"built in types" issue? I don't know the history, but it's evident that Python's "primitive types" are objects. Just type dir(1) at the interactive prompt. Apple's statement here wrongly damage's Python's reputation, and it should probably be retracted. If they want to comment on object orientation, they should probably say that everything in both Ruby and Python are full fledged objects, but that Python does not force the developer to program in an object oriented style. From brad at allendev.com Sat Dec 1 03:37:48 2007 From: brad at allendev.com (Brad Allen) Date: Fri, 30 Nov 2007 21:37:48 -0500 Subject: [python-advocacy] Python vs Ruby on Apple site In-Reply-To: <1A079CEC-7915-429F-B72B-6D59EC7C4F9D@stabell.org> References: <5AE8861F-7F79-4EDA-A63F-F3A54AD1A687@exoweb.net> <807A3823-ABF3-4ECA-9C47-20800ABB6CD8@gmail.com> <12BDD61B-54EB-4F68-A237-7DD2397E1840@cwi.nl> <3C56A764-091B-4CFE-9CA5-DB215AFC7765@mac.com> <1A079CEC-7915-429F-B72B-6D59EC7C4F9D@stabell.org> Message-ID: At 11:20 AM +0800 11/29/07, Bj?rn Stabell wrote: > > Although their similarities are striking, these scripting languages >> do have some differences. While Python code can contain both objects >> and built-in types, in Ruby everything is an object. There are no >> primitive or built-in types, such as integers. Thus anything in Ruby >> code can accept messages. > > >I thought the type/class unification in 2.2 did away with the big >"built in types" issue? I don't know the history, but it's evident that Python's "primitive types" are objects. Just type dir(1) at the interactive prompt. Apple's statement here wrongly damage's Python's reputation, and it should probably be retracted. If they want to comment on object orientation, they should probably say that everything in both Ruby and Python are full fledged objects, but that Python does not force the developer to program in an object oriented style. From catherine.devlin at gmail.com Wed Dec 5 14:08:50 2007 From: catherine.devlin at gmail.com (Catherine Devlin) Date: Wed, 5 Dec 2007 08:08:50 -0500 Subject: [python-advocacy] xkcd Message-ID: <6523e39a0712050508r62277122mad66efc472167a6a@mail.gmail.com> xkcd today is a gift to us. http://xkcd.com/353/ You should, of course, read xkcd every day. I've been hooked since the "sudo" strip ( http://xkcd.com/353/ ) -- - Catherine http://catherinedevlin.blogspot.com/ From martin at martinthomas.net Wed Dec 5 17:03:17 2007 From: martin at martinthomas.net (martin at martinthomas.net) Date: Wed, 05 Dec 2007 10:03:17 -0600 Subject: [python-advocacy] xkcd In-Reply-To: <6523e39a0712050508r62277122mad66efc472167a6a@mail.gmail.com> References: <6523e39a0712050508r62277122mad66efc472167a6a@mail.gmail.com> Message-ID: <20071205100317.5k8h7pa2wvgkgo4s@64.40.144.195> The sudo strip was http://xkcd.com/149/ :-) //m Quoting Catherine Devlin : > xkcd today is a gift to us. > > http://xkcd.com/353/ > > You should, of course, read xkcd every day. I've been hooked since > the "sudo" strip ( http://xkcd.com/353/ ) > -- > - Catherine > http://catherinedevlin.blogspot.com/ > _______________________________________________ > Advocacy mailing list > Advocacy at python.org > http://mail.python.org/mailman/listinfo/advocacy > From facundobatista at gmail.com Wed Dec 5 17:10:24 2007 From: facundobatista at gmail.com (Facundo Batista) Date: Wed, 5 Dec 2007 13:10:24 -0300 Subject: [python-advocacy] xkcd In-Reply-To: <6523e39a0712050508r62277122mad66efc472167a6a@mail.gmail.com> References: <6523e39a0712050508r62277122mad66efc472167a6a@mail.gmail.com> Message-ID: 2007/12/5, Catherine Devlin : > You should, of course, read xkcd every day. I've been hooked since > the "sudo" strip ( http://xkcd.com/353/ ) The sudo one: http://xkcd.com/149/ Is fantastic, :) Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From mtobis at gmail.com Wed Dec 5 17:29:33 2007 From: mtobis at gmail.com (Michael Tobis) Date: Wed, 5 Dec 2007 10:29:33 -0600 Subject: [python-advocacy] [Chicago] xkcd on Python In-Reply-To: References: <5aaed53f0712042224w5b7b0d95u3d8ca6a5f571f125@mail.gmail.com> <6yd4tlrvk4.fsf@imagepc03.rd.imagescape.com> Message-ID: T - Shirt opportunity! Top panel on one side, bottom panel on the other... mt On Dec 5, 2007 10:24 AM, sheila miguez wrote: > he's got a comic for that too http://xkcd.com/352/ but I am not flying > cross country to Randal. Maybe we could fly him cross country to > PyCon. > > > On Dec 5, 2007 9:49 AM, Christopher Allan Webber wrote: > > Already printed out, taped to our cabinets. > > > > <3 xkcd > > > > > > "Jeff Hinrichs - DM&T" writes: > > > > > http://imgs.xkcd.com/comics/python.png > > > > > > "Better than everything in the medicine cabinet" > > > > > > --jeff > > > _______________________________________________ > > > Chicago mailing list > > > Chicago at python.org > > > http://mail.python.org/mailman/listinfo/chicago > > _______________________________________________ > > Chicago mailing list > > Chicago at python.org > > http://mail.python.org/mailman/listinfo/chicago > > > > > > -- > sheila > > _______________________________________________ > Chicago mailing list > Chicago at python.org > http://mail.python.org/mailman/listinfo/chicago > From Daniel at pageonepr.com Wed Dec 5 19:39:06 2007 From: Daniel at pageonepr.com (Daniel Schneider) Date: Wed, 5 Dec 2007 10:39:06 -0800 Subject: [python-advocacy] Python 3000 question for PR Message-ID: Hi, I am doing the PR for PyCon 2008 and wanted to get a little bit of background information on Python 3000. If you work with or are familiar with Python, please consider the following question: what are the advantages of Python 3000 over 2.x? I am trying to highlight a few key points. I can't see how breaking backward compatibility would qualify as one but maybe the change to strings and bytes would? I am interested in what the Python community has to say about this and think it will help me better understand it as well. So please let me know what you think are the top 3 benefits of 3.0 over 2.x and why. Thanks for your help in advance! Regards, Daniel Schneider Page One PR office: 415.321.2346 mobile: 818.903.0225 daniel at pageonepr.com www.pageonepr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/advocacy/attachments/20071205/5cdcba10/attachment.htm From catherine.devlin at gmail.com Wed Dec 5 20:13:28 2007 From: catherine.devlin at gmail.com (Catherine Devlin) Date: Wed, 5 Dec 2007 14:13:28 -0500 Subject: [python-advocacy] Python 3000 question for PR In-Reply-To: References: Message-ID: <6523e39a0712051113i4c9b6d41m76e2bc407362aaf8@mail.gmail.com> > So please let me know what > you think are the top 3 benefits of 3.0 over 2.x and why. So everybody understands... Daniel is crafting press releases for PyCon that will get scooped up by the press in general. He's finding ways to catch the eyes of editors etc. - people who may or may not know Python from PL/1. A "major new release" should sound like big, newsworthy news to them... except they'll want to know, "OK, new release, why is that important?" Thanks, Daniel, for pursuing this. He asked me first and I confess I drew a blank. "You upgrade things! It's just what you do, like building bypasses!" -- - Catherine http://catherinedevlin.blogspot.com/ From roy at panix.com Wed Dec 5 21:51:32 2007 From: roy at panix.com (Roy Smith) Date: Wed, 5 Dec 2007 15:51:32 -0500 (EST) Subject: [python-advocacy] Python 3000 question for PR In-Reply-To: <6523e39a0712051113i4c9b6d41m76e2bc407362aaf8@mail.gmail.com> References: <6523e39a0712051113i4c9b6d41m76e2bc407362aaf8@mail.gmail.com> Message-ID: <44149.128.222.37.21.1196887892.squirrel@mail.panix.com> > He's finding > ways to catch the eyes of editors etc. - people who may or may not > know Python from PL/1. Funny you should mention PL/1. The first time I got spammed by a recruiter looking for plone people, I had never heard of plone. I assumed he had just mis-spelled "PL/1" as "plone". From goodger at python.org Wed Dec 5 22:43:05 2007 From: goodger at python.org (David Goodger) Date: Wed, 5 Dec 2007 16:43:05 -0500 Subject: [python-advocacy] Python 3000 question for PR In-Reply-To: References: Message-ID: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> Hi Daniel, Sorry for not replying to your initial request. So much to do, so little time! It's hard to express what the top 3 benefits of Python 3000 are, because I think the main benefits are long-term infrastructure improvements that wouldn't easily be perceived as benefits by most people. But here goes: 1. Remove cruft (flaws, warts, deprecated features) accumulated since 1990, to build a strong foundation for future innovation. 2. Improve and streamline the language/syntax in subtle ways to improve usability and remove ambiguity. 3. Change text data to be Unicode throughout, elevating text to a distinct data type and allowing for easier and more universal internationalization and localization. (Others on-list: please feel free to correct any mistakes or omissions in the following.) Here's my attempt at explaining this in a way that tech journalists may understand: Python version 3 (a.k.a. Python 3000) is not a new language; it's a cleanup of Python 2.X, a renovation of Python's foundation. Along with incremental changes from Python 2.X, Python 3 will fix several long-standing "warts" or design flaws (many from the early days of 1990-1991) and get rid of deprecated features, as well as introduce some new features. Python 3 is not backwards-compatible with Python 2.X. Some incompatible changes are being introduced in order to improve the foundations of Python going forward, anticipating and facilitating future innovation. A conversion tool will be included in Python 2.6 to automatically convert most Python 2.X code to be compatible with 3, and it will warn about code that can't be converted. Python 2.6 will also have a Python 3.0 compatibility-warning mode. There will continue to be Python 2.X releases. Python 2.7 is already planned, and further 2.X releases will happen if there's enough demand (and a sufficient supply of interested developers). There is no danger of Python 2.X code becoming obsolete any time soon. Many of the features that will be introduced in Python 3.X will be back-ported to Python 2.X, however most innovation will take place in Python 3.X first. End-users (developers using Python) are not expected to start using Python 3.0 immediately, but should consider switching and migrating their code once Python 3 matures (probably by Python 3.1 or 3.2). Python 3 is a mix of innovation and conservatism. It's the right to do for the future of Python. Fixes lots of long-standing warts: - Dividing any two numbers (integer or float) returns a float if necessary. Previously, 3/4 returned 0; if you wanted 0.75, you'd have to say 3/4.0 or 4.0/2. If you want truncating integer division in Python 3, you say 3//4 (two slashes). - "print" and "exec" are now a functions, no longer statements. As statements, "print" and "exec" were always oddballs and didn't require syntax support. - Comparisons of types have been tightened up - The "input" function has been replaced with a simpler, safe implementation, formerly "raw_input". The old "input" function was dangerous, because it evaluated arbitrary user input, a potential security hole. - The old dichotomy of small integers ("int") and large integers ("long") has been removed. Values will transparently convert. - Module imports are now absolute by default, although relative imports can be specified. This allows - Remove support for "classic" (old-style) classes; new-style classes become the default. - Several syntax improvements to remove ambiguity: "except ... as ...", "raise Exception(...)", "repr(...)" instead of "`...`", "!=" instead of "<>", etc. New features: - All text strings ("str" type) are now Unicode, so text encodings have to be explicitly specified. There is no longer an 8-bit sometimes-text, sometimes-binary string data type. A new "bytes" array type has been added for raw binary data. This reduces some internationalization incompatibilities, where text characters (letters, digits, punctuation, etc.) and raw binary bytes could be mixed and mistaken for each other. - A new platform-independent low-level input/output (I/O) library is being added to support text strings and byte arrays. - The "dictionary" core data structure (used for data storage and lookups, indexed by arbitrary keys) will acquire "views", a mechanism for efficient access. - Function annotations will allow for (but do not require!) static type declarations, among other applications. Such applications will be implemented by 3rd-party packages, not part of core Python (at least at first). - Miscellaneous features: keyword-only parameters, set literals, set comprehensions, abstract base classes, improved text formatting. -- David Goodger From goodger at python.org Wed Dec 5 22:47:32 2007 From: goodger at python.org (David Goodger) Date: Wed, 5 Dec 2007 16:47:32 -0500 Subject: [python-advocacy] Python 3000 question for PR In-Reply-To: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> References: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> Message-ID: <4335d2c40712051347q486fb0fay307645ad975cccb3@mail.gmail.com> On 12/5/07, David Goodger wrote: > - Comparisons of types have been tightened up The above is incomplete. Should be: - Comparisons of incompatible types have been tightened up. Comparing a number and a string now raises a TypeError exception. -- David Goodger From goodger at python.org Wed Dec 5 22:57:49 2007 From: goodger at python.org (David Goodger) Date: Wed, 5 Dec 2007 16:57:49 -0500 Subject: [python-advocacy] Python 3000 question for PR In-Reply-To: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> References: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> Message-ID: <4335d2c40712051357s4212d001s935927777ce322f8@mail.gmail.com> On 12/5/07, David Goodger wrote: > - Module imports are now absolute by default, although relative > imports can be specified. This allows That too (incomplete). Should be: - Module imports are now absolute by default, although relative imports can be specified. This allows projects more freedom in naming their constituent modules: no the risk of conflicting with standard library modules with the same name. -- David Goodger From roy at panix.com Thu Dec 6 00:25:21 2007 From: roy at panix.com (Roy Smith) Date: Wed, 5 Dec 2007 18:25:21 -0500 (EST) Subject: [python-advocacy] Python 3000 question for PR In-Reply-To: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> References: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> Message-ID: <35920.128.221.197.21.1196897121.squirrel@mail.panix.com> > Here's my attempt at explaining this in a way that tech journalists > may understand: Most of this is very good. Excellent, in fact. Here's a few suggestions for minor changes. > Python 3 is not backwards-compatible with Python 2.X. Try something like, "Python 3 is not 100% backwards-compatable". Sounds less scary that way. > A conversion tool will be included in Python 2.6 to automatically > convert most Python 2.X code to be compatible with 3, and it will warn > about code that can't be converted. Python 2.6 will also have a > Python 3.0 compatibility-warning mode. Along the lines of the comment above, it would be good to give people some idea of how big the conversion effort will be. Will the conversion tool handle 90% of the job? 99%? 99.9%? Can it be said that, "Most Python 2.x programs will require no manual intervention to convert to 3.0"? If so, we should say it :-) > There will continue to be Python 2.X releases. Python 2.7 is already > planned, and further 2.X releases will happen if there's enough demand > (and a sufficient supply of interested developers). A pessimist would read the above as "Python development will fork, and there will be two increasingly divergent bodies of Python code". It would be good to say something which alays people's fear of that. > End-users (developers using Python) are not expected to start > using Python 3.0 immediately, but should consider switching and > migrating their code once Python 3 matures (probably by Python 3.1 or > 3.2). It might be good to give people a time-line (at least to whatever precision is currently visible in the crystal ball). If I know that 3.2 is likely to be out by the end of 2008, I might be more inclined to invest in learning it (and converting my existing code). On the other hand, if the timeline is more like 3.1 in 2008, and 3.2 in 2009 or maybe 2010 (I'm totally guessing on the dates, here), that would give me more confidence to start a project using 2.x, knowing that codeline will be supported for several years to come. What you don't want to do is scare new people away with FUD about whether they should go with 2.x or 3.x and end up going with Ruby instead :-) > Python 3 is a mix of innovation and conservatism. It's the right to > do for the future of Python. I think you're missing a word after "right". Did you mean, "It's the right thing to do"? > Fixes lots of long-standing warts: > > - Dividing any two numbers (integer or float) returns a float if > necessary. Previously, 3/4 returned 0; if you wanted 0.75, you'd > have to say 3/4.0 or 4.0/2. That's a confusing example -- 4.0/2 doesn't give you 0.75. Oddly enough, if you type "3/4.0 or 4.0/2" at the >>> prompt, you get back 0.75, but probably not for the reasons you intended :-) > If you want truncating integer division > in Python 3, you say 3//4 (two slashes). Might be better as, "If you want the traditional behavior or truncating integer division..." > - "print" and "exec" are now a functions, no longer statements. Typo -- should be, '... are now functions' > As > statements, "print" and "exec" were always oddballs and didn't > require syntax support. I'm not sure what you mean by "didn't require syntax support". From shekay at pobox.com Wed Dec 5 17:57:50 2007 From: shekay at pobox.com (sheila miguez) Date: Wed, 5 Dec 2007 10:57:50 -0600 Subject: [python-advocacy] [Chicago] xkcd on Python In-Reply-To: References: <5aaed53f0712042224w5b7b0d95u3d8ca6a5f571f125@mail.gmail.com> <6yd4tlrvk4.fsf@imagepc03.rd.imagescape.com> Message-ID: I like the from __future__ import antigravity suggestion. can we get permission for that? Ps. if he comes to chipy can we give him a group hug? On Dec 5, 2007 10:29 AM, Michael Tobis wrote: > T - Shirt opportunity! Top panel on one side, bottom panel on the other... > > mt > > > On Dec 5, 2007 10:24 AM, sheila miguez wrote: > > he's got a comic for that too http://xkcd.com/352/ but I am not flying > > cross country to Randal. Maybe we could fly him cross country to > > PyCon. > > > > > > On Dec 5, 2007 9:49 AM, Christopher Allan Webber wrote: > > > Already printed out, taped to our cabinets. > > > > > > <3 xkcd > > > > > > > > > "Jeff Hinrichs - DM&T" writes: > > > > > > > http://imgs.xkcd.com/comics/python.png > > > > > > > > "Better than everything in the medicine cabinet" > > > > > > > > --jeff > > > > _______________________________________________ > > > > Chicago mailing list > > > > Chicago at python.org > > > > http://mail.python.org/mailman/listinfo/chicago > > > _______________________________________________ > > > Chicago mailing list > > > Chicago at python.org > > > http://mail.python.org/mailman/listinfo/chicago > > > > > > > > > > > -- > > sheila > > > > _______________________________________________ > > Chicago mailing list > > Chicago at python.org > > http://mail.python.org/mailman/listinfo/chicago > > > _______________________________________________ > Chicago mailing list > Chicago at python.org > http://mail.python.org/mailman/listinfo/chicago > -- sheila From catherine.devlin at gmail.com Tue Dec 11 02:34:15 2007 From: catherine.devlin at gmail.com (Catherine Devlin) Date: Mon, 10 Dec 2007 20:34:15 -0500 Subject: [python-advocacy] Python 3000 question for PR In-Reply-To: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> References: <4335d2c40712051343g354e7847r91aaa486f6c7e594@mail.gmail.com> Message-ID: <6523e39a0712101734v2ce52899vf12a65c5089278c1@mail.gmail.com> On Dec 5, 2007 4:43 PM, David Goodger wrote: > 1. Remove cruft (flaws, warts, deprecated features) accumulated since > 1990, to build a strong foundation for future innovation. > > 2. Improve and streamline the language/syntax in subtle ways to improve > usability and remove ambiguity. Here's my attempt at putting politician-like spin on this. :) Right now, anybody who knows Python will likely say, "Python is a great language - so elegant, so beautiful, so well-constructed. Well, except for..." Python 3000 will pretty much wipe out those "except for"s. The result will be appealing for exactly the same reasons Python has always been appealing - only more so. The speed, the readability, the power to find elegant programming solutions - those are Python's advantages right now, and will be even more so for Python 3000. I predict that will increase its draw among serious programmers across the board, which should infuse the Python community with even more energy and accelerate the growth of the Python ecosystem. No big-news functionality is being added in Python 3000 itself; but Python developers everywhere are constantly generating amazingly functional open-source modules that any developer can incorporate into their own projects. That process will only speed up with Python 3000. Really, I don't think backwards-compatibility is an important part of the story. It's a detail of implementation, and not as radical as it sounds. > 3. Change text data to be Unicode throughout, elevating text to a > distinct data type and allowing for easier and more universal > internationalization and localization. And that's important for all sorts of legitimate (and buzzwordly) reasons. Globalization. Non-Latin alphabets. Computers aren't an American thing or even a Western thing anymore. Good Unicode handling, built right into the language, is going to be crucial for Python's worldwide spread. (In fact, with One Laptop Per Child, Python would probably be at the forefront of that anyway.) -- - Catherine http://catherinedevlin.blogspot.com/ From dan at langille.org Thu Dec 20 17:44:40 2007 From: dan at langille.org (Dan Langille) Date: Thu, 20 Dec 2007 11:44:40 -0500 Subject: [python-advocacy] PGCon 2008 - call for papers Message-ID: <476A9BF8.5020405@langille.org> Hello folks, PGCon 2008 will be held 22-23 May 2008, in Ottawa at the University of Ottawa. It will be preceded by two days of tutorials on 20-21 May 2008. We are now requesting proposals for presentations. If you are doing something interesting with PostgreSQL, please submit a proposal. You might be one of the backend hackers or work on a PostgreSQL related project and want to share your know-how with others. You might be developing an interesting system using PostgreSQL as the foundation. Perhaps you migrated from another database to PostgreSQL and would like to share details. These, and other stories are welcome. Both users and developers are encouraged to share their experiences. Here are a few ideas to jump start your proposal process: - novel, unique or complex ways in which PostgreSQL are used - migration of production systems to PostgreSQL - data warehousing with PostgreSQL - tuning PostgreSQL for different work loads - replicating data on top of PostgreSQL Both users and developers are encouraged to share their experiences. The schedule is: 19 Dec 2007 Proposal acceptance begins 19 Jan 2008 Proposal acceptance ends 19 Feb 2008 Confirmation of accepted proposals 19 Apr 2008 Final papers/slides must arrive no later than this date See also Instructions for submitting a proposal to PGCon 2008 are available from: -- Dan Langille - http://www.langille.org/ BSDCan - The Technical BSD Conference: http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/