TODAY April 4 -Guido Python 3000 @ Global FSW Voice Meeting BerkeleyTIP -Linus,Guido,Shuttleworth...
Guido - Python 3000 video. 5PM Python hour Anyone: Please email me or the BTIP list if you know of any recent (past 12 months) Python videos. Thanks. :) Join with the friendly, productive, Global FSW community, in the _TWICE_ monthly, Voice over internet meeting, BerkeleyTIP-Global. GNU(Linux) BSD, Free SW, HW FreeCulture, Talks Installfest Project/ProgrammingParty http://sites.google.com/site/berkeleytip/ NEW- _TWO_ monthly day long meetings- 10AM-6PM Pacific (GMT -8H) time, = 1P - 9P Eastern = 6PM - 2AM (Sat to Sunday) GMT Join in as short or long as you like. 1st Saturday - April 4* TODAY * 3rd Sunday - April 20 = LOCATION - ONLINE, IN YOUR AREA, OR AT U. California Berkeley http://sites.google.com/site/berkeleytip/remote-attendance http://sites.google.com/site/berkeleytip/directions = NEW VIDEOS: Linux Torvalds- GIT Mark Shuttleworth - Debian Ubuntu - Debian Derived Distros Krafft Shuttleworth Levsen - Debian Derivers Roundtable Fabricio Cannini - Debian High Performance clusters and supercomputers Guido Van Rossum - Python 3000 BestTech LAMPR- Get Started with Ruby on Rails in 5 minutes Culture - Professor Wikipedia - The funniest video of the year. [Citation needed.] [Thanks to all the speakers, videographers, organizations. :) Please excuse if I mistyped names. 8-0 I hereby invite the speakers to attend BTIP for QA discussion. Please notify the speakers if you know how to contact them, thanks. :) ] Download the videos watch them before or during the meeting. Join online during the relevant topic hour to discuss each video. [See below for longer talk descriptions.] http://sites.google.com/site/berkeleytip/talk-videos = YOU GIVE A 5 MINUTE LIGHTNING TALK 4 PM. Let us know in advance what you'd like to talk about. :) = NEW MEETING COMPONENTS FREE CULTURE - Wikipedia, Creative Commons, etc COLLEGE MAJORS Business, Medicine, Law, Engineering, Art/Lit/Science/Social/Psych/Humanities/LiberalArts, etc SOFTWARE: Games = SCHEDULE / AGENDA 10AM - 6PM Pacific time (= GMT - 8 Hours) TIMETOPIC / ACTIVITY 10 ASet up. Get on IRC VOIP 11 AInstallfest; Ekiga3 12 NAsterisk, OLPC, Games; PROGRAMMING PARTY: VOIP Conference client server 1 P Xen, Virtualbox; LAMPR - Database; Law; GNU 2 P KDE GNOME; Macintosh; FreeCulture: Wikipedia,CreativeCommons 3 P Debian; BSD; College University groups; Business 4 P LIGHTNING TALKS; Ubuntu Hardware- Ex: OpenMoko Phone; Medicine 5 P Art/Literature/Music; Python; INetWebDev; Local simultaneous meetings arrangements for next meeting = Voice/VOIP CONFERENCE MEETING TECHNOLOGY Join in on IRC, we'll help you get on VOIP. :) IRC: #BerkeleyTIP, irc.freenode.net Hardware: VOIP Headset- (USB recommended for echo cancellation?) Software: Ekiga(GnomeMeeting) recommended. SIP VOIP server: Ekiga.net http://sites.google.com/site/berkeleytip/remote-attendance = LOCATION GROWTH: GREAT PROGRESS In March we QUADRUPLED our international attendance. :) Welcome :) GLOBAL: Germany, England, Iran, India US: So far: Hawaii, California, Washington, Michigan, Virgina, NCarolina When will your state or country 1st join in??? = PROJECT / PROGRAMMING PARTY Work on your own project, or the group project. Share details of your project on IRC, VOIP the mailing list. Invite others to join in your project. Or, work on the group project - Learning about Improving Ekiga, Asterisk, our VOIP conference system/technology. = Join the Global BerkeleyTIP mailing list http://groups.google.com/group/BerkTIPGlobal = THANKS, HOPE YOU JOIN; FOR FORWARDING I hope you join in the meeting. :) Join by yourself, or invite your friends over have a party. Have a party at your home, or at a local to you location - a WiFi cafe, or at a college or university is a great place for a meeting. :) You are invited to forward this message wherever appropriate - Ex: perhaps your local meeting group (LUG, etc), or whatever, if you see this on a global mailing list. === = VIDEOS - MORE DETAILED DESCRIPTIONS: 3 from DebConf08: 1) Fabricio Cannini - Debian High Performance clusters and supercomputers, 1hr 2) Mark Shuttleworth on Debian and Ubuntu - Keynote current state of collaboration between Debian and Ubuntu, progress made, and new opportunities for collaboration and development. 3) Debian Derivers Roundtable discussion - prominent developers of Debian-derived works, including Martin (Debian Edu). 1hr Linus Torvalds on Git - Git is a rewrite from scratch concurrent versioning system that Linus wrote to replace cvs, subversion (svn) and other versioning systems used in large collaborative software development. Benefits, drawbacks and insufficiencies of other versioning systems in common use. Google Tech Talks Guido Van Rossum, Python 3000, Google, 1h
Re: Python 3000
On Nov 24, 5:47 pm, Dokorek [EMAIL PROTECTED] wrote: Python 3000 (a.k.a. Py3k, and released as Python 3.0) is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places. This isn't stackoverflow. Posting items here that everyone is already fully aware of doesn't do anything positive for your reputation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000
alex23 wrote: On Nov 24, 5:47 pm, Dokorek [EMAIL PROTECTED] wrote: Python 3000 (a.k.a. Py3k, and released as Python 3.0) is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places. This isn't stackoverflow. Posting items here that everyone is already fully aware of doesn't do anything positive for your reputation. But it get's the OP low rates on spam filters, and thus hopes to attract visitors to the crappy site mentioned in the signature. Let's hope this doesn't catch on, or we suffer additionally to the more than repetitive subjects such as default function arguments, the removal of self as first parameter and not to forget how to kill a thread. Diez -- http://mail.python.org/mailman/listinfo/python-list
Python 3000
Python 3000 (a.k.a. Py3k, and released as Python 3.0) is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places. released alphas in 2007, betas in 2008, and are planning a few release candidates, with a final release in December 2008. While not quite ready for production, we highly encourage you to grab the release candidates and test them against your code. At this point, only highly critical bugs will be fixed before the final release. Dokorek ___ Join the Fastest Growing Bio Community - you know Facebook, Xing or MySpace, LinkedIn. It exists for emigrants as well: build contacts, find jobs, friends http://www.emicountry.com -- http://mail.python.org/mailman/listinfo/python-list
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Barry A. Warsaw [EMAIL PROTECTED] added the comment: r66948 -- nosy: +barry resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Henry Precheur [EMAIL PROTECTED] added the comment: I just tested the patch and it fixes the problem. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- priority: release blocker - deferred blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- priority: deferred blocker - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- priority: release blocker - deferred blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Henry Precheur [EMAIL PROTECTED] added the comment: Here is a better patch which use the workaround only if wcschr is broken. I was able to build the python interpreter and to run regrtest.py with it (some tests fail but it is very likely to be bugs in the modules) Added file: http://bugs.python.org/file11369/fix_wcschr_generic.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Henry Precheur [EMAIL PROTECTED] added the comment: Looks like my other issue is unrelated. It is caused by a buggy mbstowcs. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
New submission from Henry Precheur [EMAIL PROTECTED]:
I tried to compile Python 3000 under OpenBSD and the compilation fails
because of a 'MemoryError':
Fatal Python error: can't create sys.path
object : MemoryError()
type: MemoryError
refcount: 4
address : 0x20abfbd08
lost sys.stderr
Abort trap (core dumped)
*** Error code 134
Stop in /home/henry/compile/py3k (line 410 of Makefile).
The command which fail is:
CC='gcc -pthread' LDSHARED='gcc -pthread -shared -fPIC ' OPT='-DNDEBUG
-g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build
Here is the backtrace:
(gdb) r -E ./setup.py build
Starting program: /home/henry/compile/py3k/python -E ./setup.py build
Fatal Python error: can't create sys.path
object : MemoryError()
type: MemoryError
refcount: 4
address : 0x2042d3d08
lost sys.stderr
Program received signal SIGABRT, Aborted.
[Switching to process 20134, thread 0x2015d4800]
0x00020dc4432a in kill () from /usr/lib/libc.so.48.0
(gdb) bt full
#0 0x00020dc4432a in kill () from /usr/lib/libc.so.48.0
No symbol table info available.
#1 0x00020dc8b105 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
p = (struct atexit *) 0x2064fd000
cleanup_called = 1
mask = 4294967263
#2 0x00468a59 in Py_FatalError (msg=0x4ea6 Address 0x4ea6 out
of bounds)
at Python/pythonrun.c:1880
No locals.
#3 0x0046e06c in PySys_SetPath (path=0x4ea6) at
Python/sysmodule.c:1390
v = (PyObject *) 0x0
#4 0x00466b8c in Py_InitializeEx (install_sigs=1) at
Python/pythonrun.c:213
interp = (PyInterpreterState *) 0x20f8af900
tstate = (PyThreadState *) 0x20adeda00
bimod = (PyObject *) 0x2042dc128
sysmod = (PyObject *) 0x2042dc128
pstderr = (PyObject *) 0x2042dc128
p = 0x0
codeset = 0x2042dc128 \034
#5 0x00474136 in Py_Main (argc=4, argv=0x20f0331a0) at
Modules/main.c:497
r1 = 0
r2 = 0
c = 0
sts = 4
command = 0x0
filename = (wchar_t *) 0x0
module = 0x0
fp = (FILE *) 0x964e70
p = 0x6c05 Address 0x6c05 out of bounds
unbuffered = 0
skipfirstline = 0
stdin_is_interactive = 1
help = 0
version = 0
saw_unbuffered_flag = 0
cf = {cf_flags = 0}
#6 0x00412866 in main (argc=4, argv=0x7f7c7920) at
Modules/python.c:57
argsize = 140187732310304
argv_copy = (wchar_t **) 0x20f0331a0
argv_copy2 = (wchar_t **) 0x20f033140
i = 0
res = -231136
oldloc = 0x20e0c1b00 C
I also have core file. If you are interested mail me.
--
messages: 71968
nosy: henry.precheur
severity: normal
status: open
title: Crash while compiling Python 3000 in OpenBSD 4.4
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3685
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Henry Precheur [EMAIL PROTECTED] added the comment: I forgot to mention, I made to following modification to configure.in so I could compile Python 3000 on OpenBSD 4.4 --- configure.in(revision 66037) +++ configure.in(working copy) @@ -250,7 +250,7 @@ # On OpenBSD, select(2) is not available if _XOPEN_SOURCE is defined, # even though select is a POSIX function. Reported by J. Ribbens. # Reconfirmed for OpenBSD 3.3 by Zachary Hamm, for 3.4 by Jason Ish. - OpenBSD/2.* | OpenBSD/3.@:@0123456789@:@ | OpenBSD/4.@:@0123@:@) + OpenBSD*) define_xopen_source=no # OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is # also defined. This can be overridden by defining _BSD_SOURCE ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- components: +Interpreter Core priority: - release blocker type: - crash ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3685] Crash while compiling Python 3000 in OpenBSD 4.4
Henry Precheur [EMAIL PROTECTED] added the comment: Indeed it looks like it is the source of the problem. I created a patch to fix it. But it looks like there is another problem, instead of crashing the Python interpreter goes into interactive mode instead of executing the 'setup.py' script ... I don't think it is related, I have checked the result of ws = ws + wcslen(ws) and it seems to be correct. I will investigate the problem and create another entry if it is unrelated. -- keywords: +patch Added file: http://bugs.python.org/file11265/fix_wcschr_openbsd.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Python 3000 C API Changes
I am trying to find out what Python C APIs are changing from Python 2.5 to Python 3.0 but there does not seem to be a single list of changes (or at least google is not finding one). If someone knows about where I should look, please let me know. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 C API Changes
On Sat, Aug 23, 2008 at 11:34 AM, rahul [EMAIL PROTECTED] wrote: I am trying to find out what Python C APIs are changing from Python 2.5 to Python 3.0 but there does not seem to be a single list of changes (or at least google is not finding one). If someone knows about where I should look, please let me know. -- http://docs.python.org/dev/3.0/whatsnew/3.0.html#build-and-c-api-changes http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 C API Changes
On Aug 23, 10:34 am, rahul [EMAIL PROTECTED] wrote: I am trying to find out what Python C APIs are changing from Python 2.5 to Python 3.0 but there does not seem to be a single list of changes (or at least google is not finding one). If someone knows about where I should look, please let me know. Yes, this is a bit of a problem at the moment. You could look at the 3.0 NEWS file: http://svn.python.org/view/python/branches/py3k/Misc/NEWS?view=markup. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 C API Changes
rahul wrote: I am trying to find out what Python C APIs are changing from Python 2.5 to Python 3.0 but there does not seem to be a single list of changes (or at least google is not finding one). If someone knows about where I should look, please let me know. Check out what Cython does in its module header, method generate_module_preamble. It has an (obviously incomplete) list of the most important adaptations to write portable code for Py2.3 to 3.0. http://hg.cython.org/cython-devel/file/tip/Cython/Compiler/ModuleNode.py Stefan -- http://mail.python.org/mailman/listinfo/python-list
Python 3000 vs Perl 6
If Perl 6 ever does get on its feet and get released, how does it compare to Python 3000? Is Perl 6 more like Java now with Parrot? I just want to make sure that Python is staying competitive. If this is the wrong mailing list, just let me know. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
On Jun 24, 8:20 am, Corey G. [EMAIL PROTECTED] wrote: If Perl 6 ever does get on its feet and get released, how does it compare to Python 3000? Is Perl 6 more like Java now with Parrot? I just want to make sure that Python is staying competitive. If this is the wrong mailing list, just let me know. Thanks! Do you mean in terms of speed (parrot is a JIT?). I believe Python 3k will (when out of beta) will have a speed similar to what it has currently in 2.5, possibly with speed ups in some locations. But competitive-wise I think the point is Python 3k tries to remove warts from the Python Language to make it even more friendly to readers and writers alike. In that way it should/will stay competitive. However towards overall usage, the general advice is to stay with the 2.x series for now, trying to ensure your code style is moving towards the Py3k style, and then make the jump to the 3.x series when it is finialised. Another point, is Perl 6 ever going to get released :P -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
What I meant, in terms of dealing with accurate or non-accurate rumors is with speed, yes. There are plenty of comparisons where Perl is 4-15x faster then Python for 'some' operations regarding regular expressions, etc. For me personally, this means absolutely nothing because if I spend 50x more time comprehending spaghetti, obfuscated Perl code it's irrelevant. The main concern (my concern) is whether or not Perl 6 is more like Java with pre-compiled byte code (did I say that right) and whether or not individuals without the ability to see past the surface will begin to migrate towards Perl 6 for its seemingly faster capabilities. With Perl 6 taking 10+ years, if/when it actually gets released, will it be technically ahead of Python 3000? Is Parrot worth the extra wait the Perl 6 project is enduring? My own answer would be a resounding no, but I am curious as to what others think. :) -Thanks! On Jun 24, 2008, at 2:52 AM, [EMAIL PROTECTED] wrote: On Jun 24, 8:20 am, Corey G. [EMAIL PROTECTED] wrote: If Perl 6 ever does get on its feet and get released, how does it compare to Python 3000? Is Perl 6 more like Java now with Parrot? I just want to make sure that Python is staying competitive. If this is the wrong mailing list, just let me know. Thanks! Do you mean in terms of speed (parrot is a JIT?). I believe Python 3k will (when out of beta) will have a speed similar to what it has currently in 2.5, possibly with speed ups in some locations. But competitive-wise I think the point is Python 3k tries to remove warts from the Python Language to make it even more friendly to readers and writers alike. In that way it should/will stay competitive. However towards overall usage, the general advice is to stay with the 2.x series for now, trying to ensure your code style is moving towards the Py3k style, and then make the jump to the 3.x series when it is finialised. Another point, is Perl 6 ever going to get released :P -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
On Jun 24, 10:36 am, Corey G. [EMAIL PROTECTED] wrote: What I meant, in terms of dealing with accurate or non-accurate rumors is with speed, yes. There are plenty of comparisons where Perl is 4-15x faster then Python for 'some' operations regarding regular expressions, etc. For me personally, this means absolutely nothing because if I spend 50x more time comprehending spaghetti, obfuscated Perl code it's irrelevant. The main concern (my concern) is whether or not Perl 6 is more like Java with pre-compiled byte code (did I say that right) and whether or not individuals without the ability to see past the surface will begin to migrate towards Perl 6 for its seemingly faster capabilities. With Perl 6 taking 10+ years, if/when it actually gets released, will it be technically ahead of Python 3000? Is Parrot worth the extra wait the Perl 6 project is enduring? My own answer would be a resounding no, but I am curious as to what others think. :) -Thanks! From a quick read of the Parrot Wiki page it would appear they hope to one day allow the compilation of BOTH Perl 6 and Python, which could be interesting. Towards the speed, http://shootout.alioth.debian.org/debian/benchmark.php?test=alllang=all puts Python ahead of perl, and Python Psyco ahead of Parrot PIR. Though I haven't looked at each benchmark comparison so it is hard to tell. Towards what Perl 6 offers, the Wiki on it seems to indicate it will be a clean up of Perl 5 as well as adding of many features from other languages. It seems like Lary has gone for the TAKE IT ALL approach which could work out well in providing practically any format for creating Perl scripts. Or it could cause huge confusion as users ask for help and received a 1001 different approaches... Towards it being more advanced than Python 3k, time will tell. Both are still active and getting updated. So while I personally will stay with Python, others may move, or use both. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
On Jun 24, 11:16 am, [EMAIL PROTECTED] wrote: Towards it being more advanced than Python 3k, time will tell. It is worth reminding that, in more than one sense, the most advanced language is the one with less features ... Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
[EMAIL PROTECTED]: I believe Python 3k will (when out of beta) will have a speed similar to what it has currently in 2.5, possibly with speed ups in some locations. Python 3 uses by default unicode strings and multiprecision integers, so a little slowdown is possible. Michele Simionato: It is worth reminding that, in more than one sense, the most advanced language is the one with less features ... I don't agree, Scheme or Brainfuck may have less features, but this doesn't make them more advanced, it just makes programming with them slower and more difficult. An advanced language is one that already contains the most useful abstractions. For example Python has generators and other things that are possible if you use Assembly too, but having them pre-built in Python avoids me to use my limited brain power to re-implement them from scratch, and I can focus on the complex algorithm I am trying to implement. Once the Python program works, I am then able to translate it to D/C too. If you want to see an advanced language, you may take a look at PyMeta, that's a bit of the future of the computer science: http://washort.twistedmatrix.com/ Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
Corey G. [EMAIL PROTECTED] wrote: The main concern (my concern) is whether or not Perl 6 is more like Java with pre-compiled byte code (did I say that right) See below for some python VM comments and whether or not individuals without the ability to see past the surface will begin to migrate towards Perl 6 for its seemingly faster capabilities. I doubt it but you never know! With Perl 6 taking 10+ years, if/when it actually gets released, will it be technically ahead of Python 3000? Perl 6 was a major reason for me to switch to using python. To make that radical a change in the language seemed reckless. The fact that it still hasn't been released after 8 years of development (Larry announced it in his State of the Onion speech in 2000 I think) makes me think that I made the right choice. Python 3.0 is a very gentle change to python in comparison. You won't have to change much of your code and when you do you'll think - that looks better! Is Parrot worth the extra wait the Perl 6 project is enduring? My own answer would be a resounding no, but I am curious as to what others think. :) Another VM to run python would be nice of course, but we already have jython, ironpython and pypy. Both jython and ironpython use JIT, pypy can compile to native code and you can use psyco for JIT code also in normal python. -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
In article [EMAIL PROTECTED], Nick Craig-Wood [EMAIL PROTECTED] wrote: The fact that it still hasn't been released after 8 years of development (Larry announced it in his State of the Onion speech in 2000 I think) makes me think that I made the right choice. Sometimes you gotta be patient. Wine took 15 years (http://www.winehq.org/?announce=1.0). Not that I'm supporting Perl 6, just saying that gestation time is not always an indicator of value :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
On Jun 24, 1:19 pm, [EMAIL PROTECTED] wrote: Michele Simionato: It is worth reminding that, in more than one sense, the most advanced language is the one with less features ... I don't agree, Scheme or Brainfuck may have less features, but this doesn't make them more advanced, it just makes programming with them slower and more difficult. An advanced language is one that already contains the most useful abstractions. For example Python has generators and other things that are possible if you use Assembly too, but having them pre-built in Python avoids me to use my limited brain power to re-implement them from scratch, and I can focus on the complex algorithm I am trying to implement. Oh, you are taking my words too literally, relax and take them in the context of the thread. Also consider the famous Clinger's maxim “Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.” Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
Michele Simionato: Also consider the famous Clinger's maxim “Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.” I'm relaxed, don't worry :-) I know that maxim, but after learning Python, Scheme (and lot of other things) I think it's often wrong. Well chosen restrictions sometimes are very useful, they may act like a scaffolding, you can build higher constructions on them (Python has no macros, this is a restriction. But this restriction has some advantages. One of the main advantages is that it makes the Python code more uniform across different programmers, this is one of the thinks that makes the Python world so full of pre-made modules to do most of the things you may want to do). Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
On 24 Jun., 13:19, [EMAIL PROTECTED] wrote: If you want to see an advanced language, you may take a look at PyMeta, that's a bit of the future of the computer science:http://washort.twistedmatrix.com/ Er, no. The future of CS is also its past i.e. EBNF ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
On 24 Jun., 13:19, [EMAIL PROTECTED] wrote: If you want to see an advanced language, you may take a look at PyMeta, that's a bit of the future of the computer science:http://washort.twistedmatrix.com/ Er, no. The future of CS is also its past i.e. EBNF ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
Flaming Thunder FTW!!! thank you, I'm here all week. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs Perl 6
On Jun 24, 5:11 pm, [EMAIL PROTECTED] wrote: Well chosen restrictions sometimes are very useful, they may act like a scaffolding, you can build higher constructions on them (Python has no macros, this is a restriction. But this restriction has some advantages. One of the main advantages is that it makes the Python code more uniform across different programmers, this is one of the thinks that makes the Python world so full of pre-made modules to do most of the things you may want to do). I am all in favor of *well chosen* restrictions. However the meaning of well chosen depends on the context. For instance, just today I was reading this very interesting paper on PLT Scheme object system: http://www.cs.utah.edu/plt/publications/aplas06-fff.pdf The interesting thing is that the whole system is built in pure Scheme on top of macros, and still it has an acceptable performance. In Python I could never do the same, I would need to resort to C. So, while I agree that for the common use cases of the enterprise programmer Python is much more productive than Scheme, a computer scientists experimenting with object systems will probably find Scheme more suitable then Python. But I am digressing. The point is that a language with very few well chosen features (say Scheme) allows you to build everything else on top of it (say an object system) without needing to resort to a different implementation language. I program in Python much more than in Scheme for many reasons, but not because I think that Clinger's maxin is wrong. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
On 19/06/2008, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team and the Python community, I am happy to announce the first beta releases of Python 2.6 and Python 3.0. Any ETA for Windows builds? The web pages still point to the alphas. (I'd like to see the Windows builds more closely integrated with the releases now we're in beta stage...) Paul. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-3000] RELEASED Python 2.6b1 and 3.0b1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 19, 2008, at 4:43 AM, Paul Moore wrote: On 19/06/2008, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team and the Python community, I am happy to announce the first beta releases of Python 2.6 and Python 3.0. Any ETA for Windows builds? The web pages still point to the alphas. (I'd like to see the Windows builds more closely integrated with the releases now we're in beta stage...) Martin usually fills these in pretty quickly. I think the current situation works fine for the betas but we'll make sure the final release (and candidates) are better coordinated. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFpIpnEjvBPtnXfVAQJyWQP9FSH8Ipg93UDM3nmH3UtN+i61YGsQPd0O ypHlnz4yHpxeRkJm1zkppHHI0hKMou6JOeUf05QCnPzrAdsG/mkuv5aoBrBt3dDd UncHLoQOvXEhGrrPzexmHKv3ehxUXPQOzkiWBWVv9e69GYH4e4HcqV6s2Ya2733T zC/EyOgkyMg= =5wM5 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Python 3000 vs. Python 2.x
As a new comer to Python I was wondering which is the best to start learning. I've read that a number of significant features have changed between the two versions. Yet, the majority of Python programs out in the world are 2.x and it would be nice to understand those as well. Thanks for all the help. Creosote, -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs. Python 2.x
On Jun 13, 4:04 pm, [EMAIL PROTECTED] wrote: As a new comer to Python I was wondering which is the best to start learning. I've read that a number of significant features have changed between the two versions. Yet, the majority of Python programs out in the world are 2.x and it would be nice to understand those as well. Thanks for all the help. Creosote, What 3rd party modules are you planning to use? You won't be able to use them until their developers release Python 3000 versions. In my research, I heavily depend on the gmpy module for fast, number theoretic functions. Last time I checked, it was only available for v2.5. So, I could install v2.6 or v3.0, but I wouldn't be able to run any of my programs, so what would be the point? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs. Python 2.x
On Jun 13, 4:13 pm, Mensanator [EMAIL PROTECTED] wrote: On Jun 13, 4:04 pm, [EMAIL PROTECTED] wrote: As a new comer to Python I was wondering which is the best to start learning. I've read that a number of significant features have changed between the two versions. Yet, the majority of Python programs out in the world are 2.x and it would be nice to understand those as well. Thanks for all the help. Creosote, What 3rd party modules are you planning to use? You won't be able to use them until their developers release Python 3000 versions. In my research, I heavily depend on the gmpy module for fast, number theoretic functions. Last time I checked, it was only available for v2.5. So, I could install v2.6 or v3.0, but I wouldn't be able to run any of my programs, so what would be the point? Thanks for the advice. I guess I don't really know about what kind of modules I'm going to be using as I'm new to this whole style of programming. The only other languages I've used are Fortran, C, and Lisp. I venture to say that I'd probably be using math, and graphics modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs. Python 2.x
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | As a new comer to Python I was wondering which is the best to start | learning. I've read that a number of significant features have | changed between the two versions. Yet, the majority of Python | programs out in the world are 2.x and it would be nice to understand | those as well. Thanks for all the help. The core language is pretty much the same. If you forget about the new advanced features, a major difference is the removal of old stuff not needed any more. So basic 3.0 should be a bit easier to learn. So my advice (probably minority yet) would be to start with 3.0 (once the first beta is out next week) and move back when you have a need to. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs. Python 2.x
[EMAIL PROTECTED] wrote: As a new comer to Python I was wondering which is the best to start learning. I've read that a number of significant features have changed between the two versions. Yet, the majority of Python programs out in the world are 2.x and it would be nice to understand those as well. Thanks for all the help. Creosote, You should learn Python 2. Python 3 is only in alpha/beta, and it won't be very relevant for several years. Python 3 isn't a whole new language; it just breaks backwards compatibility to clean up old warts and make other improvements. It won't be too hard to transition to it when you decide to. -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs. Python 2.x
On Jun 13, 5:04 pm, [EMAIL PROTECTED] wrote: As a new comer to Python I was wondering which is the best to start learning. I've read that a number of significant features have changed between the two versions. Yet, the majority of Python programs out in the world are 2.x and it would be nice to understand those as well. Thanks for all the help. Learn 2.5. When (or if) Python 3 becomes relevant in a few years down the road, you'll be able to pick up the differences and new features in a week or so. George -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 vs. Python 2.x
[EMAIL PROTECTED] wrote: As a new comer to Python I was wondering which is the best to start learning. I've read that a number of significant features have changed between the two versions. Yet, the majority of Python programs out in the world are 2.x and it would be nice to understand those as well. Thanks for all the help. My advice from the perspective of a Python core developer: Stick to the 2.x series. It's going to take a couple of years until third party extensions and books have adopted to Python 3.x. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
Nick Stinemates [EMAIL PROTECTED] writes on Thu, 24 Apr 2008 08:26:57 -0700: On Tue, Apr 22, 2008 at 04:07:01AM -0700, GD wrote: Please remove ability to multiple inheritance in Python 3000. I hope your request will not be followed. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Multiple inheritance is very productive by supporting mixin classes. I use it extensively and get clean code quickly developped. I hate Java because it does not support multiple inheritance and forces me to write lots of tedious error prone delegations to work around this limitation. Dieter -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
sturlamolden wrote: On Apr 22, 1:07 pm, GD [EMAIL PROTECTED] wrote: Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. That's how the Java designers were thinking as well: If MI is allowed, programmers will suddenly get an irresistible urge to use MI to write unmaintainable spaghetti code. So let's disallow MI for the sake of common good. Argumenting like that, *all* programming languages had to be outlawed. 8) Regards, Björn -- BOFH excuse #391: We already sent around a notice about that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
On Apr 25, 2:03 pm, Bjoern Schliessmann usenet- [EMAIL PROTECTED] wrote: That's how the Java designers were thinking as well: If MI is allowed, programmers will suddenly get an irresistible urge to use MI to write unmaintainable spaghetti code. So let's disallow MI for the sake of common good. Argumenting like that, *all* programming languages had to be outlawed. 8) James Gosling, grossed by C++ iostreams, also used this argument to disallow operator overloading in Java (except for the String class). That is why Python has NumPy and Java does not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
On Tue, Apr 22, 2008 at 04:07:01AM -0700, GD wrote: Please remove ability to multiple inheritance in Python 3000. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. I also published this request at http://bugs.python.org/issue2667 -- http://mail.python.org/mailman/listinfo/python-list You make strong, compelling arguments -- Nick Stinemates ([EMAIL PROTECTED]) http://nick.stinemates.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
On Apr 22, 1:07 pm, GD [EMAIL PROTECTED] wrote: Please remove ability to multiple inheritance in Python 3000. Too late for that, PEPs are closed. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. That's how the Java designers were thinking as well: If MI is allowed, programmers will suddenly get an irresistible urge to use MI to write unmaintainable spaghetti code. So let's disallow MI for the sake of common good. Fortunately, Python is not designed to be fool proof against fools. If you cannot use MI properly, then don't use that. I also published this request athttp://bugs.python.org/issue2667 You reported MI as a bug??? -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
sturlamolden wrote: On Apr 22, 1:07 pm, GD [EMAIL PROTECTED] wrote: Please remove ability to multiple inheritance in Python 3000. Too late for that, PEPs are closed. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. That's how the Java designers were thinking as well: If MI is allowed, programmers will suddenly get an irresistible urge to use MI to write unmaintainable spaghetti code. So let's disallow MI for the sake of common good. Fortunately, Python is not designed to be fool proof against fools. If you cannot use MI properly, then don't use that. I also published this request athttp://bugs.python.org/issue2667 You reported MI as a bug??? The eventual disposition was closed, invalid. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 21, 7:04 am, Terry Reedy [EMAIL PROTECTED] wrote:
Off the top of my head: copy C and use {} to demarcate blocks and ';' to
end statements, so that '\n' is not needed and is just whitespace when
present. So, repeatedly scan for the next one of '{};'.
try this:
from __future__ import braces
:)
--
http://mail.python.org/mailman/listinfo/python-list
Remove multiple inheritance in Python 3000
Please remove ability to multiple inheritance in Python 3000. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. I also published this request at http://bugs.python.org/issue2667 -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
GD wrote: Please remove ability to multiple inheritance in Python 3000. I'm so happy *that's* a dead parrot, all right. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
GD schrieb: Please remove ability to multiple inheritance in Python 3000. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. Yes, sure. And that's why Java grew interfaces it's class-diagrams are hilariously complex. Because using single inheritance is so much better. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
GD wrote: Please remove ability to multiple inheritance in Python 3000. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Ah, one more: doctor, when I do this, it hurts! - then don't do that! Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
Dnia Tue, 22 Apr 2008 04:07:01 -0700, GD napisał(a): Please remove ability to multiple inheritance in Python 3000. Please send me 1 mln $. I've always wanted to be rich and furthermore, I've got a lot of plans and ideas how to spend that cash. I also published this request at http://bugs.python.org/issue2667 I'll be not publishing the bug, as I don't want to leave trace, so that I don't have to pay taxes. With regards, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
GD a écrit : Please remove ability to multiple inheritance in Python 3000. Please dont. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Don't blame the tool for your unability to use it properly. Every program can be designed only with single inheritance. Every program can be implemented in machine code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
On Apr 22, 7:30 am, Diez B. Roggisch [EMAIL PROTECTED] wrote: GD schrieb: Please remove ability to multiple inheritance in Python 3000. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. Yes, sure. And that's why Java grew interfaces it's class-diagrams are hilariously complex. Because using single inheritance is so much better. I have a couple issues with this, though I wholeheartedly agree with the sentiment: 1. Java didn't grow interfaces, they were there from the start. 2. Java interfaces solve a different problem than MI (used properly) does: interfaces are there to make types polymorphic, whereas inheritance's main use is to share behavior. Too many people believe polymorphism is the only noble goal of OO. If that were true, there'd be no reason for multiple inheritance, or single inheritance for that matter. But in my opinion, minimizing code redundancy by allowing classes to share behaviors is far more useful and important. That's why I wholeheartedly favor MI: it allows classes to share behavior with restraints. Java (for example) allows a class to share behavior with only one other class, and that *severely* limits the opportunities to minimize redundancy. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
On Apr 22, 10:22 am, Carl Banks [EMAIL PROTECTED] wrote: Java (for example) allows a class to share behavior with only one other class, and that *severely* limits the opportunities to minimize redundancy. Not really; composition is usually a better way to share functionality and reduce redundancy than inheritance. George -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
On Apr 22, 10:36 am, George Sakkis [EMAIL PROTECTED] wrote: On Apr 22, 10:22 am, Carl Banks [EMAIL PROTECTED] wrote: Java (for example) allows a class to share behavior with only one other class, and that *severely* limits the opportunities to minimize redundancy. Not really; composition is usually a better way to share functionality and reduce redundancy than inheritance. I should have known this was coming. I disagree: inheritance is a much better way to share behavior. Use inheritance by default, composition if you have to. (Or composition when it actually reflects a composition relationship, and not mere behavior sharing.) With composition you're burdening the user with having to learn the shared relationships that ought to be implementation details of the class. E.g., obj.action_style.perform_action() With inheritance, the user doesn't have to worry about these relationships. obj.perform_action() It's better to isolate complexity (which inheritance does) than to spread it out (which composition does). Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
I have a couple issues with this, though I wholeheartedly agree with the sentiment: 1. Java didn't grow interfaces, they were there from the start. I might have expressed myself wrong here - I should have written needed to introduce interfaces (right from the start) 2. Java interfaces solve a different problem than MI (used properly) does: interfaces are there to make types polymorphic, whereas inheritance's main use is to share behavior. But the *goal* of the polymorphy is mainly to have shared behavior. And matter of factly e.g. in swing, you use inner classes that implement most of the behavior you want, and override the few points where you want differences - and then clumsily delegate to that inner class all your interface-methods. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
Carl Banks a écrit : On Apr 22, 10:36 am, George Sakkis [EMAIL PROTECTED] wrote: On Apr 22, 10:22 am, Carl Banks [EMAIL PROTECTED] wrote: Java (for example) allows a class to share behavior with only one other class, and that *severely* limits the opportunities to minimize redundancy. Not really; composition is usually a better way to share functionality and reduce redundancy than inheritance. I should have known this was coming. I disagree: inheritance is a much better way to share behavior. (snip) With composition you're burdening the user with having to learn the shared relationships that ought to be implementation details of the class. E.g., obj.action_style.perform_action() With inheritance, the user doesn't have to worry about these relationships. obj.perform_action() (snip) Unless you use composition + delegation (which is a PITA in Java and close to a no-brainer in Python). In which case this is mostly transparent to the user code. Anyway, in Python, inheritence is kind of a special case of composition+delegation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
On Apr 22, 11:10 am, Diez B. Roggisch [EMAIL PROTECTED] wrote: 2. Java interfaces solve a different problem than MI (used properly) does: interfaces are there to make types polymorphic, whereas inheritance's main use is to share behavior. But the *goal* of the polymorphy is mainly to have shared behavior. Not at all. The goal of polymorphism is to have objects of different types usable in the same situation. Two such classes might share some behavior, but they don't have to. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Remove multiple inheritance in Python 3000
Carl Banks schrieb: On Apr 22, 11:10 am, Diez B. Roggisch [EMAIL PROTECTED] wrote: 2. Java interfaces solve a different problem than MI (used properly) does: interfaces are there to make types polymorphic, whereas inheritance's main use is to share behavior. But the *goal* of the polymorphy is mainly to have shared behavior. Not at all. The goal of polymorphism is to have objects of different types usable in the same situation. Two such classes might share some behavior, but they don't have to. Of course they don't *have* to. Yet very often they do. But I should have (again) worded that more cautiously. When doing Java, using interfaces like the ones found in the collection packages or e.g. HttpServletRequest and such usually leads to the delegation-pattern I described. The same for swing. Generally, a lot of code is written that declares first an interface then some Impl-classes of that - for the sole purpose of working around the SI-caveats. This shaped my viewpoint of interfaces - while on their own useful - as a necessary crutch to create a MI-like features, that I wanted to emphasize in this discussion. Diez -- http://mail.python.org/mailman/listinfo/python-list
[issue2667] Remove multiple inheritance in Python 3000
New submission from gmarketer [EMAIL PROTECTED]: Please remove ability to multiple inheritance in Python 3000. Multiple inheritance is bad for design, rarely used and contains many problems for usual users. Every program can be designed only with single inheritance. -- components: None messages: 65671 nosy: gmarketer severity: normal status: open title: Remove multiple inheritance in Python 3000 type: feature request versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2667 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2667] Remove multiple inheritance in Python 3000
Raghuram Devarakonda [EMAIL PROTECTED] added the comment: I don't think this request is appropriate for bug tracker. If you are really keen, bring it up on perhaps python-ideas mailing list. -- nosy: +draghuram resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2667 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2667] Remove multiple inheritance in Python 3000
Christian Heimes [EMAIL PROTECTED] added the comment: You are too late for Python 3000. You next change will be in about 10 years for Python 4000. -- nosy: +tiran __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2667 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2667] Remove multiple inheritance in Python 3000
gmarketer [EMAIL PROTECTED] added the comment: I'm also think so. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2667 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Alternate indent proposal for python 3000
On 21 Apr, 00:54, Dan Bishop [EMAIL PROTECTED] wrote: We wouldn't even need that. Just a new source encoding. Then we could write: # -*- coding: end-block -*- [...] Someone at EuroPython 2007 did a lightning talk showing working code which provided C-style block structuring using this mechanism. My brother then jokingly suggested to Martijn Faassen that if someone plugged the 2to3 converter in as a source file encoding handler, his worries about migrating to Python 3 would disappear. I'm waiting to see if anyone actually bothered to make that happen, albeit for amusement purposes only. Paul P.S. EuroPython 2008 is now accepting talks, especially ones on the language, Python 3000, and other implementations. See http://www.europython.org/ for details! -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Terry Reedy [EMAIL PROTECTED] wrote:
Off the top of my head: copy C and use {} to demarcate blocks and ';' to
end statements, so that '\n' is not needed and is just whitespace when
present. So, repeatedly scan for the next one of '{};'.
That would break if those characters appear in string literals or
comments. That's why it's nicer if you can do the transformation after
tokenising.
(Also, '{' and '}' have rather useful meanings in Python already.)
-M-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 21, 4:01 am, Paul Boddie [EMAIL PROTECTED] wrote: On 21 Apr, 00:54, Dan Bishop [EMAIL PROTECTED] wrote: We wouldn't even need that. Just a new source encoding. Then we could write: # -*- coding: end-block -*- [...] Someone at EuroPython 2007 did a lightning talk showing working code which provided C-style block structuring using this mechanism. Yes, I saw an example of that: It's what inspired my post. -- http://mail.python.org/mailman/listinfo/python-list
Alternate indent proposal for python 3000
I was considering putting together a proposal for an alternate block syntax for python, and I figured I'd post it here and see what the general reactions are. I did some searching, and while I found a lot of tab vs space debates, I didn't see anything like what I'm thinking of, so forgive me if this is a very dead horse. Generally speaking, I like the current block scheme just fine. I use python on a daily basis for system administration and text parsing tasks, and it works great for me. From time to time, though, I find myself needing a language for server- side includes in web pages. Because of the need to indent (and terminate indents), python seems an awkward choice for this, and it's easy for me to see why php and perl are more popular choices for this kind of task. Perhaps this is just my perception though. I feel that including some optional means to block code would be a big step in getting wider adoption of the language in web development and in general. I do understand though, that the current strict indenting is part of the core of the language, so... thoughts? -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Eric Wertman schrieb: I was considering putting together a proposal for an alternate block syntax for python, and I figured I'd post it here and see what the general reactions are. I did some searching, and while I found a lot of tab vs space debates, I didn't see anything like what I'm thinking of, so forgive me if this is a very dead horse. You are definitely too late to propose a change for py3k. I feel that including some optional means to block code would be a big step in getting wider adoption of the language in web development and in general. I do understand though, that the current strict indenting is part of the core of the language, so... thoughts? Why should Python repeat the mistakes other languages did with SSI or ?php ? inline code? Python favors the MVC separation of code and layout. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 20, 11:35 am, Eric Wertman [EMAIL PROTECTED] wrote: I was considering putting together a proposal for an alternate block syntax for python, and I figured I'd post it here and see what the general reactions are. I did some searching, and while I found a lot of tab vs space debates, I didn't see anything like what I'm thinking of, so forgive me if this is a very dead horse. [with apologies to Monty Python] This horse is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! THIS IS AN EX-HORSE!! :) Generally speaking, I like the current block scheme just fine. I use python on a daily basis for system administration and text parsing tasks, and it works great for me. From time to time, though, I find myself needing a language for server- side includes in web pages. Because of the need to indent (and terminate indents), python seems an awkward choice for this, and it's easy for me to see why php and perl are more popular choices for this kind of task. Perhaps this is just my perception though. Look into any of the dozen Python-based template engines that are typically used for such tasks; they offer many more features than a way to indent blocks. George -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Look into any of the dozen Python-based template engines that are typically used for such tasks; they offer many more features than a way to indent blocks. George I definitely will.. could you throw out some examples though? Thanks! Eric -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Christian Heimes [EMAIL PROTECTED] wrote: I feel that including some optional means to block code would be a big step in getting wider adoption of the language in web development and in general. I do understand though, that the current strict indenting is part of the core of the language, so... thoughts? Why should Python repeat the mistakes other languages did with SSI or ?php ? inline code? Python favors the MVC separation of code and layout. An alternative scheme for describing the block structure could be useful in other cases, though. For example, if you wanted to support putting snippets of Python in configuration files, or spreadsheet cells. There's no need to support the new scheme in .py files, so it seems to me that this doesn't have to be done in the core language. All that's needed is a variant of 'eval' which expects the alternate scheme, and that could be prototyped just using text manipulation and the normal 'eval'. If someone wrote a library for this and it proved popular, I expect it would be considered for the standard library. -M- -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 20, 5:42 pm, Matthew Woodcraft [EMAIL PROTECTED] wrote: Christian Heimes [EMAIL PROTECTED] wrote: I feel that including some optional means to block code would be a big step in getting wider adoption of the language in web development and in general. I do understand though, that the current strict indenting is part of the core of the language, so... thoughts? Why should Python repeat the mistakes other languages did with SSI or ?php ? inline code? Python favors the MVC separation of code and layout. An alternative scheme for describing the block structure could be useful in other cases, though. For example, if you wanted to support putting snippets of Python in configuration files, or spreadsheet cells. There's no need to support the new scheme in .py files, so it seems to me that this doesn't have to be done in the core language. All that's needed is a variant of 'eval' which expects the alternate scheme, and that could be prototyped just using text manipulation and the normal 'eval'. By 'eval', I guess you mean 'exec' :) -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Arnaud Delobelle [EMAIL PROTECTED] wrote: By 'eval', I guess you mean 'exec' :) Yes. Shows how often I use either. -M- -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Matthew Woodcraft [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | There's no need to support the new scheme in .py files, so it seems to | me that this doesn't have to be done in the core language. All that's | needed is a variant of 'eval' which expects the alternate scheme, and | that could be prototyped just using text manipulation and the normal | 'eval'. Eval() is for expressions, exec() is for general code. But you do not really need a variant. Just define a preprocessor function 'blockify' which converts code in an alternate syntax to regular indented block syntax. Then exec(blockify(alt_code_string)) I presume that this is more or less what the templating engines do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
En Sun, 20 Apr 2008 13:42:05 -0300, Matthew Woodcraft [EMAIL PROTECTED] escribió: An alternative scheme for describing the block structure could be useful in other cases, though. For example, if you wanted to support putting snippets of Python in configuration files, or spreadsheet cells. [...] If someone wrote a library for this and it proved popular, I expect it would be considered for the standard library. There is pindent.py in the Tools/scripts directory: # ... When called as pindent -r it assumes its input is a # Python program with block-closing comments but with its indentation # messed up, and outputs a properly indented version. # A block-closing comment is a comment of the form '# end keyword' # where keyword is the keyword that opened the block ... def foobar(a, b): if a == b: a = a+1 elif a b: b = b-1 if b a: a = a-1 # end if else: print 'oops!' # end if # end def foobar -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Terry Reedy [EMAIL PROTECTED] wrote: But you do not really need a variant. Just define a preprocessor function 'blockify' which converts code in an alternate syntax to regular indented block syntax. Then exec(blockify(alt_code_string)) You can do it like that, but if it were to become part of the standard distribution it would be nice to avoid having to tokenise the code twice. (You could define the new block scheme in such a way that 'blockify' doesn't need to tokenise, but I think it would end up a bit ugly.) -M- -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 20, 1:29 pm, Gabriel Genellina [EMAIL PROTECTED] wrote: En Sun, 20 Apr 2008 13:42:05 -0300, Matthew Woodcraft [EMAIL PROTECTED] escribió: An alternative scheme for describing the block structure could be useful in other cases, though. For example, if you wanted to support putting snippets of Python in configuration files, or spreadsheet cells. [...] If someone wrote a library for this and it proved popular, I expect it would be considered for the standard library. There is pindent.py in the Tools/scripts directory: # ... When called as pindent -r it assumes its input is a # Python program with block-closing comments but with its indentation # messed up, and outputs a properly indented version. # A block-closing comment is a comment of the form '# end keyword' # where keyword is the keyword that opened the block ... def foobar(a, b): if a == b: a = a+1 elif a b: b = b-1 if b a: a = a-1 # end if else: print 'oops!' # end if # end def foobar -- Gabriel Genellina That's actually not a lot different than what you have to do now in a web page.. It still seems overcomplicated though. I'm not sure why this is worse: def foobar(a, b): if a == b: a = a+1; elif a b: b = b-1; if b a: a = a-1; else: print 'oops!';; It's just ultimately whitespace insensitive. Whether that's a good or bad design is a debate that can be argued either way, but other languages do it, and it's handy sometimes. I agree that it makes it much easier to produce illegible code. Developing for a browser is arguably annoying and hackish enough, without having to stick in comments and such to enforce indenting. -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On 20 avr, 17:35, Eric Wertman [EMAIL PROTECTED] wrote: I was considering putting together a proposal for an alternate block syntax for python, and I figured I'd post it here and see what the general reactions are. I did some searching, and while I found a lot of tab vs space debates, I didn't see anything like what I'm thinking of, so forgive me if this is a very dead horse. Generally speaking, I like the current block scheme just fine. I use python on a daily basis for system administration and text parsing tasks, and it works great for me. From time to time, though, I find myself needing a language for server- side includes in web pages. Because of the need to indent (and terminate indents), python seems an awkward choice for this, and it's easy for me to see why php and perl are more popular choices for this kind of task. Perhaps this is just my perception though. The server-page scheme has long shown it's limitations and quirks - mostly, you end up mixing application logic and presentation logic. Even PHP programmers are slowly taking the MVC route. I feel that including some optional means to block code would be a big step in getting wider adoption of the language in web development and in general. I do understand though, that the current strict indenting is part of the core of the language, so... thoughts? Python Server Page packages are nothing new, and didn't help making Python more popular for web developpement. MVC frameworks like Django, Pylons, Turbogears or web.py seems to draw way more attention, and we start to see PHP coders switching to Django - which is the one with the IMHO weakest templating language. If you're looking for a templating system with Python syntax support, you may want to take a look at Cheetah and (my favourite one) Mako. Mako is the default template system for Pylons, and IIRC web.py supports Cheetah (warning: never used web.py, and haven't followed recent dev, so you'd better check by yourself). HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 20, 12:34 pm, Eric Wertman [EMAIL PROTECTED] wrote: Look into any of the dozen Python-based template engines that are typically used for such tasks; they offer many more features than a way to indent blocks. George I definitely will.. could you throw out some examples though? Thanks! Eric Start out here: http://wiki.python.org/moin/Templating As you can see there is no shortage of alternatives, which can be overwhelming. Cheetah used to be the most popular and it's still widely used, but these days Django templates, Genshi and Mako seem more prominent for web development. HTH, George -- http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 20, 11:42 am, Matthew Woodcraft
[EMAIL PROTECTED] wrote:
Christian Heimes [EMAIL PROTECTED] wrote:
I feel that including some optional means to block code would be a big
step in getting wider adoption of the language in web development and
in general. I do understand though, that the current strict indenting
is part of the core of the language, so... thoughts?
Why should Python repeat the mistakes other languages did with SSI or
?php ? inline code? Python favors the MVC separation of code and layout.
An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.
There's no need to support the new scheme in .py files, so it seems to
me that this doesn't have to be done in the core language. All that's
needed is a variant of 'eval' which expects the alternate scheme, and
that could be prototyped just using text manipulation and the normal
'eval'.
We wouldn't even need that. Just a new source encoding. Then we
could write:
# -*- coding: end-block -*-
def _itoa(num, base):
Return the string representation of a number in the given base.
if num == 0:
return DIGITS[0]
end if
negative = num 0
if negative:
num = -num
end if
digits = []
while num:
num, last_digit = divmod(num, base)
digits.append(DIGITS[last_digit])
end while
if negative:
digits.append('-')
end if
return ''.join(reversed(digits))
end def
--
http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
On Apr 20, 6:54 pm, Dan Bishop [EMAIL PROTECTED] wrote:
On Apr 20, 11:42 am, Matthew Woodcraft
[EMAIL PROTECTED] wrote:
Christian Heimes [EMAIL PROTECTED] wrote:
I feel that including some optional means to block code would be a big
step in getting wider adoption of the language in web development and
in general. I do understand though, that the current strict indenting
is part of the core of the language, so... thoughts?
Why should Python repeat the mistakes other languages did with SSI or
?php ? inline code? Python favors the MVC separation of code and layout.
An alternative scheme for describing the block structure could be
useful in other cases, though. For example, if you wanted to support
putting snippets of Python in configuration files, or spreadsheet
cells.
There's no need to support the new scheme in .py files, so it seems to
me that this doesn't have to be done in the core language. All that's
needed is a variant of 'eval' which expects the alternate scheme, and
that could be prototyped just using text manipulation and the normal
'eval'.
We wouldn't even need that. Just a new source encoding. Then we
could write:
# -*- coding: end-block -*-
def _itoa(num, base):
Return the string representation of a number in the given base.
if num == 0:
return DIGITS[0]
end if
negative = num 0
if negative:
num = -num
end if
digits = []
while num:
num, last_digit = divmod(num, base)
digits.append(DIGITS[last_digit])
end while
if negative:
digits.append('-')
end if
return ''.join(reversed(digits))
end def
A great example of why something like this would never fly in standard
Python.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Matthew Woodcraft [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy [EMAIL PROTECTED] wrote:
|
| But you do not really need a variant. Just define a preprocessor
| function 'blockify' which converts code in an alternate syntax to
| regular indented block syntax. Then
|
| exec(blockify(alt_code_string))
|
| You can do it like that, but if it were to become part of the standard
| distribution it would be nice to avoid having to tokenise the code
| twice.
For the motivating example I was responding to -- short snippets of code in
html/xml/etc, that is completely a non-issue.
Any such scheme is very unlikely to become part of the stdlib and if it
were, it would have to first be tested and beat out competitors. A
preprocessor written in Python is the obvious way to test and gain
acceptance.
| (You could define the new block scheme in such a way that
| 'blockify' doesn't need to tokenise,
Off the top of my head: copy C and use {} to demarcate blocks and ';' to
end statements, so that '\n' is not needed and is just whitespace when
present. So, repeatedly scan for the next one of '{};'.
| but I think it would end up a bit ugly.)
For beautiful, stick with standard Python.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Alternate indent proposal for python 3000
Dan Bishop [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | We wouldn't even need that. Just a new source encoding. Then we | could write: | | # -*- coding: end-block -*- Ummm.. source encoding refers to how unicode chars/codepoints are represented as bytes. This syntax is copied from emacs and uses standard terms. What would you expect an encoding aware editor to do with something like the above? -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
As of 4:50 PM EST, the links to Windows installers give 404 File Not Found. I gather that they are still in process, and notice that there is no public c.l.p. announcement. I just fixed that. The files were there; just the links were wrong. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a1 and 3.0a3
On 01/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote: As of 4:50 PM EST, the links to Windows installers give 404 File Not Found. I gather that they are still in process, and notice that there is no public c.l.p. announcement. I just fixed that. The files were there; just the links were wrong. The 2.6a1 x86 MSI is there, but the 3.0a3 x86 MSI is still giving a 404. Paul. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a1 and 3.0a3
The 2.6a1 x86 MSI is there, but the 3.0a3 x86 MSI is still giving a 404. Please try again - *those* files weren't actually there when I sent my last message; I just built them. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-3000] RELEASED Python 2.6a1 and 3.0a3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 1, 2008, at 5:26 PM, Martin v. Löwis wrote: As of 4:50 PM EST, the links to Windows installers give 404 File Not Found. I gather that they are still in process, and notice that there is no public c.l.p. announcement. I just fixed that. The files were there; just the links were wrong. Thanks for fixing these Martin! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8nY1HEjvBPtnXfVAQJ3YgP/TYr0X5vRqvVDEMgsHxHuiSuYZCIr8y36 ibAh3RAGeLLK7C7NiOyAfxkesf91HCbL1in0TcnD06QZy52O8elBa927JOomP3mc Y6K4Y49JhxonBrmGcmasnc9PFjbhXtGdWLREinuzpB5itLpRv+SevMhxP27Fp8qr df173TV4hpk= =nf32 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Python 3000 and import __hello__
Just playing around with Python3000 a2 release on Windows XP 32-bit x86. import __hello__ doesn't print 'hello world...' as it does on 2.5 The import doesn't fail or generate errors... just no output. Perhaps this is by design? Brad -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 and import __hello__
Brad wrote: Just playing around with Python3000 a2 release on Windows XP 32-bit x86. import __hello__ doesn't print 'hello world...' as it does on 2.5 The import doesn't fail or generate errors... just no output. Perhaps this is by design? I changed the __hello__ frozen module a while ago. The print was unreliable for some new unit tests. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000 and import __hello__
On Jan 19, 7:54 pm, Brad [EMAIL PROTECTED] wrote: Just playing around with Python3000 a2 release on Windows XP 32-bit x86. import __hello__ doesn't print 'hello world...' as it does on 2.5 Thanks for spoiling this easter egg for me! ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: [Python-3000] Possible Duck Typing Problem in Python 2.5?
2007/12/9, hashcollision [EMAIL PROTECTED]: From http://ivory.idyll.org/blog/dec-07/conversions.html: class X: internal = [5,6,7,8] def __getitem__(self, i): return self.internal[i] x = X() l = [1,2,3] print l + x fails withTypeError: can only concatenate list (not instance) to list I tried: class X(list): internal = [5, 6, 7, 8] def __getitem__(self, i): return self.internal[i] def __len__(self): return internal def __iter__(self): return internal.__iter__() but this fails also. Try this: class X(list): internal = [5, 6, 7, 8] def __init__(self): list.__init__(self, self.internal) x = X() l = [1,2,3] print l + x IMHO, this is a problem. Is it? If so, I suggest that it be fixed in python 3000. ___ Python-3000 mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/ggpolo%40gmail.com -- -- Guilherme H. Polo Goncalves -- http://mail.python.org/mailman/listinfo/python-list
It works! Was: Installing Python 3000 on Leopard (Mac OS) fails...
On Nov 26, 9:59 pm, André [EMAIL PROTECTED] wrote: While I made some progress in trying to install Py3k from source (for the first time), it has failed... Here are the steps I went through (not necessarily in that order - except for those that matter). 1. After installing Leopard, install Xcode tools from the dvd - even if you had done so with a previous version (they need to be updated - trust me :-) 2. Download Python 3.0a1 3. Unpack the archive. 4. Go to /usr/local and make a directory sudo mkdir py3k (This is probably not needed, but that's what I did). 5. From the directory where the Python 3.0a1 was unpacked run ./configure --prefix=/usr/local/py3k 6. run make This last step failed with the following error message: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include - DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function 'posix_setpgrp': ./Modules/posixmodule.c:3769: error: too few arguments to function 'setpgrp' make: *** [Modules/posixmodule.o] Error 1 Any suggestions? André Following Martin v Löwis's suggestion, I looked at http://bugs.python.org/issue1358 and added the line #define SETPGRP_HAVE_ARG by hand to pyconfig.h (after it was created by configure). Then 6. run make 7. run make test (one test failed; this step likely unnecessary) 8. sudo make altinstall 9. sudo ln /usr/local/bin/py3k/python3.0 /usr/bin/python3.0 10. type python 11. print(Hello world!) 12. Be happy! André, hoping this report might help some other newbie. -- http://mail.python.org/mailman/listinfo/python-list
Re: It works! Was: Installing Python 3000
On Tuesday 27 November 2007 07:20, André wrote: On Nov 26, 9:59 pm, André [EMAIL PROTECTED] wrote: While I made some progress in trying to install Py3k from source (for the first time), it has failed... Here are the steps I went through (not necessarily in that order - except for those that matter). 1. After installing Leopard, install Xcode tools from the dvd - even if you had done so with a previous version (they need to be updated - trust me :-) 2. Download Python 3.0a1 3. Unpack the archive. 4. Go to /usr/local and make a directory sudo mkdir py3k (This is probably not needed, but that's what I did). 5. From the directory where the Python 3.0a1 was unpacked run ./configure --prefix=/usr/local/py3k 6. run make This last step failed with the following error message: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include - DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function 'posix_setpgrp': ./Modules/posixmodule.c:3769: error: too few arguments to function 'setpgrp' make: *** [Modules/posixmodule.o] Error 1 Any suggestions? André Following Martin v Löwis's suggestion, I looked at http://bugs.python.org/issue1358 and added the line #define SETPGRP_HAVE_ARG by hand to pyconfig.h (after it was created by configure). Then 6. run make 7. run make test (one test failed; this step likely unnecessary) 8. sudo make altinstall 9. sudo ln /usr/local/bin/py3k/python3.0 /usr/bin/python3.0 10. type python 11. print(Hello world!) 12. Be happy! André, hoping this report might help some other newbie. Bug fix excluded, After unpacking the compressed version of Python, look for a file named README. Open README and look for Installing. Make install and Make altinstall is explained. I don't like to read instructions but in the long run, it saves time. jim-on-linux http://www.inqvista.com -- http://mail.python.org/mailman/listinfo/python-list
Re: It works! Was: Installing Python 3000
On Nov 27, 11:17 am, jim-on-linux [EMAIL PROTECTED] wrote: On Tuesday 27 November 2007 07:20, André wrote: On Nov 26, 9:59 pm, André [EMAIL PROTECTED] wrote: While I made some progress in trying to install Py3k from source (for the first time), it has failed... Here are the steps I went through (not necessarily in that order - except for those that matter). 1. After installing Leopard, install Xcode tools from the dvd - even if you had done so with a previous version (they need to be updated - trust me :-) 2. Download Python 3.0a1 3. Unpack the archive. 4. Go to /usr/local and make a directory sudo mkdir py3k (This is probably not needed, but that's what I did). 5. From the directory where the Python 3.0a1 was unpacked run ./configure --prefix=/usr/local/py3k 6. run make This last step failed with the following error message: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include - DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function 'posix_setpgrp': ./Modules/posixmodule.c:3769: error: too few arguments to function 'setpgrp' make: *** [Modules/posixmodule.o] Error 1 Any suggestions? André Following Martin v Löwis's suggestion, I looked at http://bugs.python.org/issue1358 and added the line #defineSETPGRP_HAVE_ARG by hand to pyconfig.h (after it was created by configure). Then 6. run make 7. run make test (one test failed; this step likely unnecessary) 8. sudo make altinstall 9. sudo ln /usr/local/bin/py3k/python3.0 /usr/bin/python3.0 10. type python Should have been python3.0 11. print(Hello world!) 12. Be happy! André, hoping this report might help some other newbie. Bug fix excluded, After unpacking the compressed version of Python, look for a file named README. Did that. Open README and look for Installing. Make install and Make altinstall is explained. make altinstall is mentioned (not explained) in very brief comment. This series of post followed from a previous one where I queried about how to install py3k without it becoming the default. Many useful suggestions were offered by others which I found very useful as I had *never* installed/configured/made something from source before (I always used .msi on Windows and, more recently, .dmg on Mac). Once you know what/why things like --prefix or --enable-framework or altinstall are for, the README file content becomes extremely clear. I don't like to read instructions but in the long run, it saves time. Actually, I do try and read instructions first usually. But sometimes the instructions use terms that are not clear for newbies. And, if I may, the normal way to create an alias/link for unsophisticated Mac users (like me) is to use the GUI (Finder) and ctrl-click on the file. However, /usr is hidden ... and using ln is not something that can be found in the README ... So that is why, to save time for others, I thought of writing this summary of what I did, so that it could be found by people searching this newsgroup (which is one of the other things I did first...) André jim-on-linuxhttp://www.inqvista.com -- http://mail.python.org/mailman/listinfo/python-list
Installing Python 3000
Sorry about the simple question ... I'd like to install Python 3000 on my computers (Mac, and possibly Windows), without messing up the existing versions. So far, I've always relied on using .msi on Windows and .dmg on the Mac. From the Python site, I read (different version, but still...): Unpack the archive with tar -zxvf Python-2.4.4.tgz ... Change to the Python-2.4.4 directory and run the ./configure, make, make install commands to compile and install Python. The step that gets me worried is the make install one... I don't want it to take over as default. I would like to be able to invoke it by typing python3k ... from anywhere and have it work - while still having python invoke the default 2.5 version. André -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 3000
André wrote: The step that gets me worried is the make install one... I don't want it to take over as default. I would like to be able to invoke it by typing python3k ... from anywhere and have it work - while still having python invoke the default 2.5 version. You want make altinstall Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python 3000
I'd like to install Python 3000 on my computers (Mac, and possibly Windows), without messing up the existing versions. So far, I've always relied on using .msi on Windows and .dmg on the Mac. From the Python site, I read (different version, but still...): Unpack the archive with tar -zxvf Python-2.4.4.tgz ... Change to the Python-2.4.4 directory and run the ./configure, make, make install commands to compile and install Python. The step that gets me worried is the make install one... I don't want it to take over as default. I would like to be able to invoke it by typing python3k ... from anywhere and have it work - while still having python invoke the default 2.5 version. I recommend that you then do use the prebuilt binaries, at least where available, i.e. http://www.python.org/download/releases/3.0/ For OSX, I recommend to use a different --prefix for installing, e.g. /usr/local/py3k. All files then go into that directory, and nothing else lives in it. To invoke it, you give /usr/local/py3k/bin/python; if you want to make a python3k link someone in your path - that would be your choice. HTH, Martin -- http://mail.python.org/mailman/listinfo/python-list
