Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
On Tue, 2017-11-07 at 16:39 +1000, Nick Coghlan wrote: > And this is the key point for me: "choosing not to choose" is > effectively the same as standardising the feature, as enough Python > code will come to rely on CPython's behaviour that most alternative > implementations will feel obliged to start behaving the same way > CPython does (with MicroPython being the potential exception due to > memory usage constraints always winning over algorithmic efficiency > concerns in that context). Maybe an UnorderedDict could be added which Python implementations _can_ implement as an optimized (less memory use, faster, ...) version without ordering guarantees if they have a need for it. In other implementations it could just be a synonym for a regular dict. That way it would be explicit that the programmer doesn't care about the ordered behaviour. It would also avoid current mistakes some (especially those new to the language and occasional users) make, because of assumptions from default dict behaviour. (Maybe a commandline switch or other mechanisms to explicitly use that UnorderedDict as the default could also be useful. It would be a no-op in implementations which don't have differing implementations.) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python possible vulnerabilities in concurrency
On Tue, 2017-11-14 at 13:15 +0100, Antoine Pitrou wrote: > On Mon, 13 Nov 2017 15:55:03 -0500 > Stephen Michell wrote: > > I am looking for one or two experts to discuss with me how Python > > concurrency features fit together, and possible vulnerabilities > > associated with that. > > > > TR 24772 lists 5 vulnerabilities associated with > > Can you explain what "TR 24772" is? (and/or give a link to a > publicly-available resource) Sounds like https://www.iso.org/standard/71094.html which is updating https://www.iso.org/standard/61457.html (which you can download from there if you search a bit; clearly either ISO doesn't have a UI/UX "standard" or they aren't following it...) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The history of PyXML
On Thu, 2018-05-17 at 15:18 +0300, Serhiy Storchaka wrote: > Does anyone has the full copy of the PyXML repository, with the > complete history? > > This library was included in Python 2.1 as the xml package and is > not maintained as a separate project since 2004. It's home on > SourceForge was removed. I have found sources of the last PyXML > version (0.8.4), but without history. > Did you try asking SourceForge if they still have a backup copy? -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The history of PyXML
On Thu, 2018-05-31 at 09:23 -0600, Jeremy Kloth wrote: > I had also contacted SourceForge prior to me uploading a Github repo. > They have just restored the project files for PyXML as well (CVS, > downloads, ...). So I was right thinking they might have a backup? :-) I have to say it seems like the new owners of SourceForge are doing their best to make it a good place for project hosting again. (Not always as fast as one would wish, but I understand it's big, and the previous owners did a lot of damage to the brand...) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ext4 data loss
Op vrijdag 13-03-2009 om 12:28 uur [tijdzone +0300], schreef Oleg Broytmann: >Ext4 is not the only FS with delayed allocation. Of course not, even ext3 has delayed allocation (even if 5 sec vs. 2 min makes the disaster window a bit smaller). The real problem seems to be that ext4 re-orders the rename (which it does almost instantly) before the write (which waits for 2-15 minutes or so). There are other modern filesystems that take care such reordering doesn't happen... -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: installation with ubuntu 8.04
Op vrijdag 13-03-2009 om 04:13 uur [tijdzone -0700], schreef John Wagner: > I am sorry to bother about this but I've asked for help from Canonical > with no reply. > They seem reluctant to update Python beyond version 2.5; I'm trying to > install 3.0.1. If you can wait until April 23rd then you will be able to use python 2.6 (as the default) or python 3.0.1 (as an option for your apps) on the next release of Ubuntu (9.04). Maybe Ubuntu will provide a package of python 3.0.1 in the 8.04 backports too, if there is enough demand for it. And if not, somebody can make a backport for Ubuntu 8.04 in a PPA on launchpad. -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
Op dinsdag 24-03-2009 om 20:51 uur [tijdzone +0100], schreef "Martin v. Löwis": > The Windows story is indeed sad, as none of the Windows packaging > formats provides support for dependencies That's not entirely true; Cygwin comes with a package management tool that probably could be used to set up a repository of python packages for native Windows: <http://sources.redhat.com/cygwin-apps/setup.html> This package manager is in no way dependent on Cygwin, supports (basic) dependencies, etc. Of course some people would have to take care of the packaging work (just like happens for most open source OS distros and for Mac OS X already). It seems like XEmacs is already using a fork of that installer for the same purpose. -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] And the winner is...
Op maandag 30-03-2009 om 21:54 uur [tijdzone -0500], schreef Guido van Rossum: > But is his humility enough to cancel out Linus's attitude? I hope not, or the /.-crowd would become desperate... ;-) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Op woensdag 29-11-2006 om 12:23 uur [tijdzone +0100], schreef Armin Rigo: > I could not agree more. Nowadays, whenever I get an account on a new > Linux machine, the first thing I have to do is reinstall Python > correctly in my home dir because the system Python lacks distutils. > Wasteful. (There are some applications and libraries that use > distutils at run-time to compile things, and I'm using such > applications and libraries on a daily basis.) I think you should blame the sysadmins, and kick them to install python properly for use by a developer, because every distro I know provides distutils... ;-) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Op donderdag 30-11-2006 om 21:48 uur [tijdzone +], schreef Steve Holden: > I think the point is that some distros (Debian is the one that springs > to mind most readily, but I'm not a distro archivist) require a separate > install for distutils even though it's been a part of the standard > *Python* distro since 2.3 (2.2?) > > So, it isn't that you can't get distutils, it's that you have to take an > extra step over and above installing Python. No, it just means that several parts of the python.org source package are spread over several binary packages, just like happens with hundreds or thousands of other packages, and any Debian (or Ubuntu or other distro doing this) administrator worth his or her money should be aware of that, and be able to find those packages. E.g. on a debian "sarge" system: $ apt-cache showsrc python2.4 | grep Binary Binary: python2.4-doc, python2.4, python2.4-examples, python2.4-tk, python2.4-dev, idle-python2.4, python2.4-dbg, python2.4-gdbm Or on an Ubuntu "edgy" system: $ apt-cache showsrc python2.4 | grep Binary Binary: python2.4-dbg, python2.4-dev, python2.4, python2.4-doc, idle-python2.4, python2.4-minimal, python2.4-examples Probably the Debian maintainers could have named packages differently to make things less confusing for newbies (e.g. by having the 'pythonX.Y' packages being meta-packages that depend on all binary packages built from the upstream source package), but that doesn't mean splitting "python" (or other projects) up in several packages is wrong. E.g. when installing on an flash drive, people are probably quite happy to leave the 20 MiB of Python documentation out... Maybe python.org can include several logical "divisions" in the python.org distribution and make it easy for OS distro packagers to make separate packages if they want to, as most of them are quite happy to have less work to do, provided the upstream "divisions" do more or less what they want. ;-) (Oh, and such a division should IMHO also include a "minimal python" for embedded/low-resource hardware use, where things like distutils, GUI toolkits, a colelction of 20 XML libraries and documentation are most likely not needed.) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Op vrijdag 01-12-2006 om 12:44 uur [tijdzone +1300], schreef Greg Ewing: > With ~/.local, you're hiding the fact that the applications > or libraries or whatever are even there in the first > place. You've got all this disk space being used up, > but no way of seeing where or by what, and no > obvious way of freeing it up. I think that's bad HCI. AFAIK fd.o's use of ~/.local is mainly for things like *.desktop files (e.g. menu items added or changed by the user). -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Op vrijdag 01-12-2006 om 00:16 uur [tijdzone +], schreef Steve Holden: > Jan Claeys wrote: > [...] > > Probably the Debian maintainers could have named packages differently to > > make things less confusing for newbies (e.g. by having the 'pythonX.Y' > > packages being meta-packages that depend on all binary packages built > > from the upstream source package), but that doesn't mean splitting > > "python" (or other projects) up in several packages is wrong. E.g. when > > installing on an flash drive, people are probably quite happy to leave > > the 20 MiB of Python documentation out... > > > Right, who cares about newbies, they're only the future of the language, > after all. I take your point that some flexibility is advantageous once > you get past the newbie stage, but I think that here we are talking > about trying to avoid mis-steps that will potentially put people off > making that transition. Like I said, it's possible to split Python without making things complicated for newbies. The fact that Debian didn't do so in the past might be a considered a packaging bug, but the problem isn't in the practice of splitting upstream projects in several binary packages itself. > > Maybe python.org can include several logical "divisions" in the > > python.org distribution and make it easy for OS distro packagers to make > > separate packages if they want to, as most of them are quite happy to > > have less work to do, provided the upstream "divisions" do more or less > > what they want. ;-) (Oh, and such a division should IMHO also include > > a "minimal python" for embedded/low-resource hardware use, where things > > like distutils, GUI toolkits, a colelction of 20 XML libraries and > > documentation are most likely not needed.) > If only there were some guarantee that the distros would respect any > project partitioning imposed by python-deb we might stand a chance of > resolving these issues. There will never be a guarantee, as some distros might have very special targets, but I'm pretty sure that most distros would follow any _sensible_ proposition (and looking at current practice might give a good clue about what they want). -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for new 2to23 tool
Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett Cannon: > On Nov 11, 2007 4:00 PM, Graham Horler <[EMAIL PROTECTED]> wrote: > > I have been developing in Python since 1.5, and now have to support 2.1 > > as a minimum version. I do like to keep my code runnable on newer > > versions however, and am considering the feasability of forward > > compatibility with Python 3.0. > > > > I also notice the Leo[1] project could use some assistance with forward > > compatibility. > > > > So I was wondering if anyone else had a need for a 2to23.py tool to help > > make code compatible with 3.0 but not break it for 2.x. > > What exactly are you proposing? We already have 2to3 > (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source > translation from 2.x to 3.0. Graham wants to convert his code such that it works on both Python 2.x (probably even early versions of it?) & Python 3.x. Not 2 instances of code, but one source that works on both 2.x and 3.x... -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).
Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean Reifschneider: > I would say that this is an optimization that helps a specific set of > platforms, including one that I think we really care about, the OLPC > which needs it for decreased battery use. Almost every laptop user would benefit from it, and even some desktop or server users might save on their electric power bill... -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).
Op dinsdag 11-12-2007 om 17:03 uur [tijdzone -0800], schreef Guido van Rossum: > On Dec 11, 2007 4:54 PM, Jan Claeys <[EMAIL PROTECTED]> wrote: > > Op vrijdag 07-12-2007 om 07:26 uur [tijdzone -0700], schreef Sean > > Reifschneider: > > > I would say that this is an optimization that helps a specific set of > > > platforms, including one that I think we really care about, the OLPC > > > which needs it for decreased battery use. > > > > Almost every laptop user would benefit from it, and even some desktop or > > server users might save on their electric power bill... > > Do you have data to support this claim? Not PyGTK-specific data, but you can see power-saving by reducing wakeups by playing with Intel's 'powertop' utility on linux (also see the "lesswatts" site mentioned earlier). One example was the interaction between PulseAudio & ALSA that caused a lot of "wakeups", and thus prevented laptops from going into the more "agressive" power saving modes; if PyGTK has a similar issue, that would make it less useful on laptops... -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: per user site-packages directory
Op zondag 13-01-2008 om 10:45 uur [tijdzone +0100], schreef Christian Heimes: > Gregory P. Smith wrote: > > My main suggestion was going to be the ability to turn it off as you already > > mentioned. However, please consider leaving it off by default to avoid > > problems for installed python scripts importing user supplied code. For > > shared hosting environments where this becomes really useful users can > > easily add the -s (or whatever flag is chosen) to their programs > > themselves. I don't know what that'd mean on windows where #! lines don't > > exist. Yet another file extension to imply the flag (yuck)? A .cmd wrapper > > script to run python with the flag (ugh)? > > So you prefer to make the per use site-package directory an opt-in > option? I prefer it as an opt-out option. It's enabled by default, > unless the user disables the feature with -s. One possible issue with enabling it by default could be that less-experienced users can accidentally break the system configuration tools written in python used by several linux distros (Ubuntu, Gentoo, Fedora/Red Hat, ...). There should be a way for distro developers to make sure the users local 'site-packages' is *not* used when running those tools. I'd rather have to set/uncomment an environment variable on my system than having 100 "normal" users break their systems accidentally... ;-) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: per user site-packages directory
Op zaterdag 12-01-2008 om 00:27 uur [tijdzone +0100], schreef Christian Heimes: > Specification > = [...] > user configuration directory > >Usually the parent directory of the user site directory. It's meant >for Python version specific data like config files. > >Windows: %APPDATA%/Python/Python26 >Mac: ~/Library/Python/2.6 >Unix: ~/.local/lib/python2.6 What do you mean by "configuration directory"? IMHO configuration files on linux/unix should go into ~/.python2.6 or ~/.config/python2.6 or something like that? (I would never look in a directory named 'lib' for configuration files.) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 54, Issue 57
Op woensdag 16-01-2008 om 02:33 uur [tijdzone +0100], schreef Christian Heimes: > Bill Janssen wrote: > > Good point, but I prefer ~/Library/Python to either of these. > > ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems. There is (at least) one linux distro using it, but it's not very well-known. > I *could* add yet another environment variable PYTHONUSERHOME to set the > base path but I prefer not. A solution might be a way for python distributors to set the default location , and then provide PYTHONUSERHOME for stubborn users to override that. ;) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: per user site-packages directory
Op zondag 20-01-2008 om 18:01 uur [tijdzone +0100], schreef Christian Heimes: > Jan Claeys wrote: > > What do you mean by "configuration directory"? IMHO configuration files > > on linux/unix should go into ~/.python2.6 or ~/.config/python2.6 or > > something like that? > > It's already renamed in the PEP: > http://www.python.org/dev/peps/pep-0370/#specification So this is stuff that should never be changed by the user? -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 54, Issue 57
Op zondag 20-01-2008 om 20:46 uur [tijdzone +0300], schreef Oleg Broytmann: > On Sun, Jan 20, 2008 at 06:46:31PM +0100, Jan Claeys wrote: > > Op woensdag 16-01-2008 om 02:33 uur [tijdzone +0100], schreef Christian > > Heimes: > > > ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems. > > > > There is (at least) one linux distro using it, but it's not very > > well-known. > >Gobo Linux? Now that I think about it, I'm not sure they use it under $HOME too, but I was thinking about that distro, yes, as they use such a scheme for the rest of their system (and it seems natural to do so throughout then). -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bdist_* to stdlib?
Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing: > I'm disappointed that the various Linux distributions > still don't seem to have caught onto the very simple > idea of *not* scattering files all over the place when > installing something. > > MacOSX seems to be the only system so far that has got > this right -- organising the system so that everything > related to a given application or library can be kept > under a single directory, clearly labelled with a > version number. Those directories might be mounted on entirely different hardware (even over a network), often with different characteristics (access speed, writeability, etc.). -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bdist_* to stdlib?
Op wo, 15-02-2006 te 11:23 -0800, schreef Bob Ippolito: > On Feb 15, 2006, at 4:49 AM, Jan Claeys wrote: > > > Op wo, 15-02-2006 te 14:00 +1300, schreef Greg Ewing: > >> I'm disappointed that the various Linux distributions > >> still don't seem to have caught onto the very simple > >> idea of *not* scattering files all over the place when > >> installing something. > > Those directories might be mounted on entirely different hardware > > (even over a network), often with different characteristics (access speed, > > writeability, etc.). > > Huh? What does that have to do with anything? I've never seen a > system where /usr/include, /usr/lib, /usr/bin, etc. are not all on > the same mount. It's not really any different with OS X either. Paths like /etc, /var, /srv, /usr/include and /usr/share are good candidates to be on another mount than the bin & lib directories... BTW, Mac-style packages do exist for Linux too, if you prefer that. Look e.g. at Klik: <http://klik.atekon.de/> -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bdist_* to stdlib?
Op vr, 17-02-2006 te 23:22 +0100, schreef "Martin v. Löwis": > That, in turn, is because nobody is so short of disk space that > you really *have* to share /usr/share across architectures, I can see diskless thin clients that boot from flash memory doing things like that? (E.g. having documentation and header files and other less-important stuff on an nfs mount?) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Topic suggestions from the PyCon feedback
Op ma, 13-03-2006 te 19:52 -0800, schreef Alex Martelli: > The *ONE* thing I dislike about working in the US is vacations -- I > get about half of what I would expect in Europe, and that's with my > employer being reasonably generous... in practice, given I NEED some > time to go visit family and friends back in Italy, this means I can't > really take vacations to do conferences, but rather I must convince > my boss that conference X is worth my time [...]. Well, I'm sure (from a previous c.l.py encounter) that you know enough about (European) civilisation to explain history to an American savage (~= employer)? ;-) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigned abug/patch
Op di, 28-03-2006 te 09:23 -0600, schreef [EMAIL PROTECTED]: > Based on my brief experience as a Bugzilla user (just trying to be a good > citizen and report Mozilla bugs a few years ago), I would vote -1. I'd hate > to think the bug reporting interface was *so* bad that it alone would > discourage people from reporting bugs. Still, I gave up reporting Mozilla > bugs because of it. GNOME uses a Bugzilla "fork" that's more user-friendly... (But other people say Bugzilla is also difficult for admins, so that's probably not the only important thing.) -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
Op di, 13-06-2006 te 10:27 +0200, schreef Alexander Schremmer: > Bazaar-NG seems to reach limits already when working on > it's own code/repository. Canonical uses bzr to develop launchpad.net, which is a "little bit" larger dan bzr itself, I suspect...? -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Op za, 17-06-2006 te 10:25 +0200, schreef "Martin v. Löwis": > Another reason is that I consider VS 2005 buggy, I hope that some > of the breakage that Microsoft has done to the C library is reverted > in a future release. VS2005 managed to break compatibility with > C89 and C99 in a way that made Python fail to start up, also, it > was possible to have the CRT abort just by calling the builtin open > with the wrong arguments. There is now a work-around for that breakage, > but still, I don't trust that VS 2005 is a good product. Why should a C++ compiler be able to compile C89 and/or C99 code? -- Jan Claeys ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
