Re: [Python-Dev] memcmp performance
-On [20111024 09:22], Stefan Behnel (stefan...@behnel.de) wrote: I agree. Given that the analysis shows that the libc memcmp() is particularly fast on many Linux systems, it should be up to the Python package maintainers for these systems to set that option externally through the optimisation CFLAGS. In the same stretch, stuff like this needs to be documented. Package maintainers cannot be expected to follow each and every mailinglist's posts for nuggets of information like this. Been there, done that, it's impossible to keep track. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | GPG: 2EAC625B Only in sleep can one find salvation that resembles Death... ___ 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] Support the /usr/bin/python2 symlink upstream
-On [20110302 01:17], Martin v. Löwis (mar...@v.loewis.de) wrote: Matthias Klose represents Debian, Dave Malcolm represents Redhat, and Dirkjan Ochtman represents Gentoo. With FreeBSD's ports if you install a Python port it will install a pythonX.Y in /usr/local/bin, depending on what is specified with the make variable PYTHON_DEFAULT_VERSION python will point to that version. So it can refer to either 2.x or 3.x. NetBSD's pkgsrc does not have 3.x in the tree yet. But if no python exists yet, then pkg_alternatives will link it to the version of choice. Not sure what either OpenBSD or DragonFly BSD are doing, but it will be along these lines as well. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | GPG: 2EAC625B Ain't gonna spend the rest of my Life, quietly fading away... ___ 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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)
-On [20101107 12:52], Nick Coghlan (ncogh...@gmail.com) wrote: This sounds like a great place to start. Perhaps focus on one or two of the less common platforms first (e.g. FreeBSD 7 has been hitting a few semaphore issues lately). Nick, do you have some pointers for this? I am one of those BSD Python users/coders and would like to resolve any issues. By default FreeBSD 7, at least, has limits on semaphores and the likes, but those can be expanded. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Hypocrisy is the homage which vice pays to virtue... ___ 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] Too many open files errors on x86 FreeBSD 7.2 3.x buildbot
-On [20101108 00:36], David Bolen (db3l@gmail.com) wrote: Victor Stinner victor.stin...@haypocalc.com writes: Well, I think the SYSV semaphores are either less limited or at least more adjustable. They've certainly been around longer in FreeBSD. The POSIX semaphore support is not enabled by default in FreeBSD 7, so I added loader.conf stuff to load them (as part of issue7272). It is enabled by default on FreeBSD 8 at least. Looking through the repository it seems 7-STABLE has it enabled by default as well in the GENERIC kernel (the standard one it boots with after its first install). It seems this was added for 7.3 and onward. So 7.2 and before need an options P1003_1B_SEMAPHORES added to their kernel at least. The SYSV options are already present in the entire 7.x line. It looks like it is possible to tune semaphore limits on FreeBSD, without recompiling the kernel, by using boot loader option (kern.ipc.sem* options). But ask the FreeBSD user to tune its boot loader options to use the concurrent.futures module is not pratical :-) PostgreSQL installations via ports as well as its documentation instruct the FreeBSD user to tweak kern.ipc settings. Yeah, I guess the key question is if changing the limit is just needed to get around an artifact of the test process (which I'm willing to do for the buildbot), or if it would be needed to be able to use the regular modules in practice. If the latter, I doubt too many users are going to jump through such hoops, particularly if it needs a kernel rebuild, so we may need to make other choices in terms of support under FreeBSD. Almost every FreeBSD user I know of compiles a new kernel. It's just one of those BSD things that every user goes through. I'm also not entirely sure just what is the limiting factor. I think the kern.ipc.sem* options are for the SYSV semaphores, not POSIX, though some of them do have a similar limit. Some are adjustable by sysctl, others by loader.conf. kern.ipc is about System V IPC. As you indicate later on, p1003_1b is the POSIX related IPC sysctl tree. The three semaphore settings semmni, semmns, and semmnu are only tweakable via loader.conf. The references I found were talking about a limit set explicitly (#define SEM_MAX) in the kernel source (uipc_sem.c) which exports its value (at least in 7.2) via the sysctl p1003_1b.sem_nsems_max, which is read-only. I got the impression they weren't adjustable even in loader.conf, but haven't actually tried it yet myself. It may be different in 8.x, but one email thread I found indicated that the changes proposed to make the POSIX limits adjustable didn't make the 8.1 cut (current release), though might make it in the next 8.x release. After checking the repository I saw that there were MFCs (Merge From Current, backport) to 8-STABLE prior to the 8.1 release for dynamic tweaking. On my 8.1 machine: nexus% sudo sysctl -w p1003_1b.sem_nsems_max=31 p1003_1b.sem_nsems_max: 30 - 32 7.x is hardlocked at the moment unless someone manually edits the file to up the SEM_MAX define. The same goes for FreeBSD 8.0. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Nothing yet from nothing ever came... ___ 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] Stable build slaves authority
-On [20101014 00:55], Brian Curtin (brian.cur...@gmail.com) wrote: Correct. There are a few hacky ways to get Express to use the x64 SDK, or so I read. I think Martin meant that you wouldn't need VS Express if you install the Windows SDK, since it provides all the tools in the SDK to build Python. Sorry Martin, haven't had the time at work to test the latest trunks out with just the SDK. I'll see if I can free some time for that in the coming days. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Seize from every moment its unique novelty and do not prepare your joys... ___ 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.org going down?
-On [20101008 01:22], Martin v. Löwis (mar...@v.loewis.de) wrote: True. However, I really cannot see anything on the machines that indicates some outage. I'm still unsure what it is that was happening, so it's also difficult to analyse this further. It's hosted by XS4All, they had some network problems yesterday at least. I am not sure if it would explain this behaviour, might be one of the uplinks or peers had some issues. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Sleep tonight, sweet summer light, scattered yesterdays, the past is far away... ___ 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] Distutils2 scripts
-On [20101008 09:07], Tarek Ziadé (ziade.ta...@gmail.com) wrote: The feedback I received for this is pretty clear: people want a single script that can be called directly. e.g. $ distutils2 depgraph $ distutils2 install $ distutils2 run command +1 from me. I sincerely dislike the Perl-esque -m stuff. I just wanted to make sure that once distutils2 is back in the stdlib, it's OK for us to add that script in the distribution. No problem from my side, I do, however, not speak for the developers at large of course. ;) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Care-charmer Sleep, son of the sable Night, Brother to Death, in silent darkness born... ___ 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] Distutils2 scripts
-On [20101008 09:07], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
I just wanted to make sure that once distutils2 is back in the stdlib,
it's OK for us to add that script in the distribution.
Ah, one thing that came to mind:
is this script supposed to be installed in /usr{/local}/bin? If so, how
would it look like for multiple Python distributions that are installed?
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
To the dull mind nature is leaden. To the illumined mind the whole world
burns and sparkles with light...
___
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] issue 9807 - a glitch in coexisting builds of different types
-On [20101004 22:03], Barry Warsaw (ba...@python.org) wrote: We already have libpython3.2.so.1.0 which also doesn't end in .so. I suppose we could put the build flags before the .so. part, but I think Matthias had a problem with that (I don't remember the details). Using major and minor numbers after the .so designation is an old aout (de facto) standard. ELF settled on just major numbers. And typically you will find a symbolic link from libwhatever.so to libwhatever.so.1 Also, from FreeBSD's ldconfig manual page: Filenames must conform to the lib*.so.[0-9] pattern in order to be added to the hints file. So ending a shared object with the build flags will cause problems on FreeBSD and probably the other BSDs (DragonFly, NetBSD, OpenBSD) and most likely Mac OS X as well. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Time is merely a residue of Reality... ___ 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] issue 9807 - a glitch in coexisting builds of different types
-On [20101004 20:48], Barry Warsaw (ba...@python.org) wrote: On Oct 02, 2010, at 01:40 PM, Antoine Pitrou wrote: Besides, mingling different installations together makes uninstalling much more difficult. Not for a distro I think. It does. On BSD the ports and packages are referred to a specific location in the ports tree, e.g. ports/lang/python26, so any Python 2.6 compiled and installed from ports with specific options will *always* point to this location. So if you want to install 2 versions of Python 2.6 with different options, you are out of luck using the standard way. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Looking for the Sun that eclipsed behind black feathered wings... ___ 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] issue 9807 - a glitch in coexisting builds of different types
-On [20101005 16:21], Barry Warsaw (ba...@python.org) wrote: Do any BSD distros provide multiple different builds of Python to their users? For all I can tell, no. Assuming you are referring to different builds of the same version. How do they handle having a debug build or non-debug build? Install in the same place. So you either install a debug build or a stripped build. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The fragrance always stays in the hand that gives the rose... ___ 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: i18n
-On [20100825 20:03], Alcino Dall'Igna Jr (adi...@gmail.com) wrote: If (3) could enter the main trunk it would be a great help by itself. In this case access to international help is useless due the original difficulties with the language, remember I'm talking about kids mainly, and 1st stage to programming for youngsters. There are two main ways to do this, one is using codes as indicated, but I prefer using the more generally accepted and used, with messages catalogs using gettext and the like. Haven't been able to respond sooner, but maybe one thing was not so clear about what I wrote since you misrepresented it here. What I was referring to was this scenario: ImportError: No module named blah would become in nl_NL something like: ImportError: Geen module genaamd blah Now, if ImportError (or any other error) has only one text, then I could copy-paste that error message easily and people would understand contextually from the error which it is, despite the localization. However, if there's multiple possible messages, how is someone else supposed to figure out what my localized message means in order to help me out? In this case I think an approach with a number inventory system works out well, e.g.: ImportError (3): Geen module genaamd blah And the 3 would be a stable number for this particular message. More examples: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.sag1/html/sag1/sag1485.htm Oracle: en_US: ORA-00942: table or view does not exist ja_JP: ORA-00942: 表またはビューが存在しません。 -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B When you meet a master in the street, do not speak, do not be silent. Then how will you greet him? ___ 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] mingw support?
-On [20100808 02:23], Nick Coghlan (ncogh...@gmail.com) wrote: This used to be more of an issue because MS didn't provide a decent free compiler for their platform. These days (since the release of Visual Studio Express), we expect that people willing to use (or support) a closed OS can cope with also using the free-as-in-beer closed compiler provided by the vendor of that OS. You don't even need VS Express. Install Windows SDK 7.1 and the compilers are supplied with it. Less clutter if you prefer the command line. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Without a soul there can be no understanding between the heart and the mind. ___ 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] mingw support?
-On [20100808 18:29], Nick Coghlan (ncogh...@gmail.com) wrote: MS may have improved the tools they release with the SDK to the point where they can build a VS solution file (I haven't tried that in years). From my quick glance of what the current SDK installs that does to seem to be the case. I have not tried it myself (yet). -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B You yourself, as much as anybody in the entire universe, deserve your love and affection... ___ 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] Removing IDLE from the standard library
-On [20100712 08:26], Stephen Hansen (apt.shan...@gmail.com) wrote: But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module. Why would it be a significant loss if it went the way of a third party module? Clearly right now it's not being maintained as well as the rest of Python. Maybe that's a clear indicator that it's better maintained externally instead of in the main tree. And for what it is worth, I personally never used it beyond one time looking at it in disgust and neither do I know Pythonistas around me that use it. Bpython and ipython do get installed a lot though, even on Windows. And all these people, no matter their proficiency in programming, use an editor or IDE of some sort, but not IDLE. So I would not mourn to see IDLE get moved out of the main repository as I do not see the added value or benefit, not even for training (and since you're going to set up a training environment anyway, it can only be described as lazy if you are adamant on having it included in the base distribution). Just my EUR 0,02. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Born from the Dark, in the black Cloak of Night... ___ 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] Enhanced tracker privileges for dangerjim to do triage.
-On [20100426 10:21], Paul Moore (p.f.mo...@gmail.com) wrote: Would in not therefore be reasonable to question whether the *default* privileges be changed to allow outsiders to do these things, rather than asking for escalated privileges for one individual? (Or more likely, as well as doing so, as changing the default is likely to be a longer discussion...) Be careful. Trackers are often hit by spam bots which change random form field values. I cannot from memory recall whether or not we had this issue on either the tracker tracker or Python's tracker. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B A wise man that walks in the dark with a blindfold on, is not much of a wise man... ___ 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 376
-On [20100422 10:55], Tarek Ziadé (ziade.ta...@gmail.com) wrote: The next big piece is the FHS-compatible handling of resource files, which will worth a PEP on its own. You do realize, I hope, that FHS is only followed by Linux distributions and not even fully at that. BSD Unixes, for example, have quite some different hier(7) requirements, most notably that /usr/local is used. So is your intent to have a PEP solely for Linux systems? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B A wise man that walks in the dark with a blindfold on, is not much of a wise man... ___ 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] code.python.org - random 403 errors
-On [20100423 02:48], Sridhar Ratnakumar (sridh...@activestate.com) wrote: Ok, I setup a cron job to maintain an internal mirror of the above mentioned repositories in code.python.org. We'll do a hg pull -u (equivalent to svn up) every hour; no clones. Hopefully, that should reduce the amount of requests from our side. Let me know if in future this issue repeats. Dirk Jan can probably correct me (or some other heavy Hg user) but for all I know you should indeed simply clone once and subsequently hg pull and from your local copy clone as you like. (At least that's also how http://wiki.services.openoffice.org/wiki/Mercurial/Getting_Started seems to aim at explaining.) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B A wise man that walks in the dark with a blindfold on, is not much of a wise man... ___ 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] ffi junk messages
-On [20100407 15:29], Martin v. Löwis (mar...@v.loewis.de) wrote: Instead of submitting a bug report, it would be better to submit a patch, though. Can you try having the build process use freebsd.S instead of sysv.S? Mark and me are looking at it right now. I can compile ctypes using --with-system-ffi at least. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Grabbing at angels when I fall, for all my demons to applaud, I am free... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ffi junk messages
-On [20100407 16:17], Martin v. Löwis (mar...@v.loewis.de) wrote: I'm not so sure. It's a ctypes/libffi bug, so most likely, nobody will be able to fix it when reported. For platform-specific libffi bugs, the patch most likely will come from the submitter, as nobody else might have access to the platform, and the knowledge about the platform details. No it is not actually. Mark and me found the culprit in the Python tree. Commit incoming. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B I dream of Love as Time runs through my hand... ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
-On [20100220 13:04], Martin v. Löwis (mar...@v.loewis.de) wrote: The last commits by Fredrik to ElementTree in Python SVN that I can see are dated 2006-08-16. The last commits I can see to ElementTree at http://svn.effbot.python-hosting.com/ are dated 2006-07-05. And? [snip] # Since you've effectively hijacked the library, and have created your # own fork that's not fully compatible with any formal release of the # upstream library, and am not contributing any patches back to # upstream, I suggest renaming it instead. This may be politely phrased, but it seems that he is quite upset about these proposed changes. I'd rather drop ElementTree from the standard library than fork it. Maybe I am fully misunderstanding something here and I am also known for just bluntly stating things but: Isn't inclusion into the standard library under the assumption that maintenance will be performed on the code? With all due respect to Frederik, but if you add such a module to the base distribution and then ignore it for 3-4 years I personally have a hard time feeling your 'outrage' being justified for someone who is trying to fix outstanding issues in ElementTree. I also do not find your idea of dropping the module productive either Martin. Just dropping it for no other reason because someone cannot be bothered to act as a responsible maintainer just seems not useful for Python users at all. Especially since patches *are* available. If Frederik has problems with that he should have put a bit more effort into maintaining it in the first place. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B In this short time of promise, you're a memory... ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
-On [20100220 22:47], Martin v. Löwis (mar...@v.loewis.de) wrote: In general, that's the assumption, and Guido has stated that he dislikes exceptions. However, Fredrik's code was included only under the exception. ElementTree wouldn't be part of the standard library if an exception had not been made. I was not fully aware of that bit of history, my thanks for enlightening me on it. If users and co-developers think that these issues absolutely must be resolved now (rather than waiting some more), I see only two options: a) ElementTree is removed from the library b) we declare that we fork ElementTree, and designate a maintainer. Just fixing the bugs without designating a maintainer is *not* an option, because we absolutely need somebody to pronounce on changes. It will not be Guido, and if it is not Fredrik, somebody else must step forward. I would then ask that person, as the first thing, to rename the package when making incompatible changes. Call me a sceptic or pragmatist, but I don't see the situation change suddenly from what it has been for the past couple of years. I vaguely remember running into problems or limitations myself with ElementTree and switching to lxml at one point. It sort of has to escalate now in order to get the maintainer to look at it and I doubt that's how we want to keep operating in the future? So the choice of removal or forking may actually be quite imminent, but of course, that's my interpretation of things. Well, I promised that we will stick to the procedure when integrating ElementTree. I'm not willing to break this promise. Honourable and I can understand that. Although it doesn't make it flexible to work on. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The fragrance always stays in the hand that gives the rose... ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
-On [20100219 08:37], Simon Cross (hodgestar+python...@gmail.com) wrote: We need someone to maintain the copy of ElementTree in the Python repository. Ideally this means pulling upgrades and bugfixes from Fredrik's repository every now and then. Which will give you nothing as that tree hasn't been touched in over three years. I can understand giving special consideration to maintainers, but that would imply they actually maintain something, no? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Contentment that derives from knowing when to be content is eternal contentment... ___ 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] Add UTC to 2.7 (PyCon sprint idea)
-On [20100217 23:48], s...@pobox.com (s...@pobox.com) wrote: My guess is the data are updated several times per year, not the code. Can they not be separated? The bulk of the original timezone package is data for the timezones. Last year saw close to 26 releases for this. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B When you pass through, no one can pin you down, no one can call you back... ___ 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] Add UTC to 2.7 (PyCon sprint idea)
-On [20100217 03:19], Stuart Bishop (stu...@stuartbishop.net) wrote: The Debian, Ubuntu and I think Redhat packages all use the system zoneinfo database - there are hooks in there to support package maintainers that want to do this. This way the package can be included in the supported release but still receive timezone information updates via the OS (but no code updates, but these are rare and usually irrelevant unless you where the person who filed the bug ;) ). This can also work for all the BSDs since they include the Olson zoneinfo data in the base system as well. And that will probably mean Mac OS X as well, if they stuck to what FreeBSD had in place for that. Can anyone verify that? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Anything becomes possible, after you find the courage to admit that nothing is certain. ___ 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] PYTHON3PATH
-On [20100113 22:13], Ralf Schmitt (r...@brainbot.com) wrote: hehe. tab completion: With bpython and ipython available, why would you even want to stick to the 'plain old' interactive interpreter? (Sorry to derail the discussion, but maybe there's more people that have not heard of either or both.) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B For ever, brother, hail and farewell... ___ 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] Package install failures in 2.6.3
-On [20091005 17:45], Barry Warsaw (ba...@python.org) wrote: 2) PJE releases a new version of setuptools that fixes this problem. Will all due respect to PJE, but I sincerely doubt this will happen. There's still a bunch of outstanding patches over at the setuptools tracker, including SVN 1.x support, which have been open for more than a year. Personally I consider setuptools unmaintained and have started moving my projects over to Distribute. So, if you decide to wait, make sure to put a deadline on it. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The earth laughs in flowers... ___ 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] Fast Implementation for ZIP decryption
-On [20090831 06:29], Collin Winter (coll...@gmail.com) wrote: Are there any applications/frameworks which have zip files on their critical path, where this kind of (admittedly impressive) speedup would be beneficial? What was the motivation for writing the C version? Would zipped eggs count? For example, SQLAlchemy runs in the 5 MB range. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B All for one, one for all... ___ 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] Support for Encrypted Zip as python scripts
-On [20090823 22:10], Guido van Rossum (gu...@python.org) wrote: Also, I suppose there could be (US) export problems with the code, so it would have to be optional (and we might not be able to build it into binaries we distribute from python.org). For all I know the website and repository are both located @ the XS4All colocation, so how does US export problems apply? It would apply if the box would've been hosted in the USA, but they're not for all I know. It's one of the reasons FreeBSD had their ebones repository located in Zuid Afrika back in the day. Nowadays they can just include all the relevant bits in the repository. So I wonder how applicable the entire US export restriction still is nowadays. In short: I don't think we have much to worry about. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Wisdom is the difference between knowledge and experience... ___ 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] Setting up a buildbot
-On [20090822 21:30], Paul Moore (p.f.mo...@gmail.com) wrote: I've just had a look on python.org, but couldn't immediately see a pointer to instructions on what the process is to set up a buildbot. http://wiki.python.org/moin/BuildBot comes to mind. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Success is satisfaction with yourself... ___ 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 3144: IP Address Manipulation Library for the Python Standard Library
-On [20090820 20:19], Peter Moody (pe...@hda3.com) wrote: I've updated the pep with lots of examples; most of the stuff you're asking for is already supported, I just didn't do a good job explaining it. A few things are pending review. Thanks for that Peter! -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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 3144: IP Address Manipulation Library for the Python Standard Library
-On [20090818 22:15], Peter Moody (pe...@hda3.com) wrote: I have a first draft of a PEP for including an IP address manipulation library in the python stdlib. It seems like there are a lot of really smart folks with some, ahem, strong ideas about what an IP address module should and shouldn't be so I wanted to solicit your input on this pep. the pep can be found here: http://www.python.org/dev/peps/pep-3144/ No chance at the moment to test/look through the code, so please excuse any obvious ones, I'm basing my comments on the PEP. Some elaboration on handling ipv4 mapped addresses would be nice, e.g. :::c000:280 and/or :::192.168.0.128 Some IPv6 examples would also help the PEP I think. Especially on how 0 compression is handled in addresses. Maybe show ipv4 examples on non-class boundaries, e.g. /23 instead of /24, so people are more convinced it handles CIDR properly. Clarification on whether this library will support converting a sequence of networks into another sequence where the networks which comprise consecutive netblocks will be collapsed in a new entry. E.g. 2 /24s that are neighbours will be represented as one /23. I realise some might be answered by the last paragraph of your PEP, but it would be nice to know what you consider essential and what not. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B They have learned nothing, and forgotten nothing... ___ 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] ndPython: I NEED TO TALK WITH ONE OF THE PYTHON CORE
-On [20090626 22:29], Terry Reedy (tjre...@udel.edu) wrote: If you were running on a PC with what is now considered to be very small memory, I would hypothesize that you had filled memory so that the interpreter or parts thereof were being swapped in and out of memory from and to disk. Is any thing like that possible with the PSP? From what I know it has either 32 or 64 MB of RAM, depending on the model. The storage comes in the form of a Memory Stick PRO Duo, but I doubt it is used in any form as a paging or swap file. At least playing on my own it only accesses it when I want to save game data. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Friendship is love without wings... ___ 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 376 : Changing the .egg-info structure
-On [20090515 06:59], P.J. Eby (p...@telecommunity.com) wrote: I'd like to reiterate my suggestion that the uninstall record include size and checksum information, ala PEP 262's FILES section. This would allow the uninstall function to validate whether a file has been modified, and thus prevent uninstalling a locally-modified file, or a file installed in some other way. Agreed. Within FreeBSD's ports the installed package registration gets a MD5 hash per file recorded. Size is less interesting though, since essentially this information is encapsulated within the hash. Remove one byte from the file and your hash is already different. And the case of a collision for this kind of registration is sufficiently small to need the size information. And if you're worried about the MD5 collision space, which for this use case ought to be large enough, you could always settle for SHA1. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B What's one man's poison, is another's meat or drink... ___ 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] Switchover: mail.python.org
-On [20090512 18:41], Barry Warsaw (ba...@python.org) wrote: Somehow, personalization got turned off for python-checkins. This disables VERPing of the headers. I've turned it back on, so please let me know if that fixes the issue. This did not appear to happen site-wide, just for python-checkins AFAICT. Yes, the current batches are arriving with personilization again. I don't mind either way, just thought a heads up was warranted. ;) Thanks Barry, -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The Idea does not replace the work... ___ 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] Switchover: mail.python.org
-On [20090511 14:47], Aahz (a...@pythoncraft.com) wrote: On Monday 2009-05-11, mail.python.org will be switched to another machine starting roughly at 14:00 UTC. This should be invisible (expected downtime is less than ten minutes). The headers for the python checkins mails are apparently different now. So people might want to adjust any filtering. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The reverse side also has a reverse side... ___ 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 382: Namespace Packages
-On [20090501 20:59], Martin v. Löwis (mar...@v.loewis.de) wrote: Right: if all portions install into the same directory, you can have base packages already. Speaking as a user of packages, this use case is one I hardly ever encounter with the Python software/modules/packages I use. The only ones that spring to mind are the mx.* and ll.* packages. The rest simply create their own namespace as package.*, but there's nothing that uses that same namespace and installs separately from the base package that I know of. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Knowledge was inherent in all things. The world was a library... ___ 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 382: Namespace Packages
-On [20090509 13:40], Martin v. Löwis (mar...@v.loewis.de) wrote: There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*, plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*, xm.*, paste.*, Products.*, buildout.*, five.*, silva.*, tl.*, tw.*, themerubber.*, themetweaker.*, zc.*, z3c.*, zgeo.*, z3ext.*, etc. Can be fairly said, though, that the majority of those you just named are related to Zope? That would explain why I won't know of them as I avoid Zope like the plague. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Hope is a letter that never arrives, delivered by the postman of my fear... ___ 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 382: Namespace Packages
-On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) wrote: They're also all pure namespace packages rather than base + addons, which is what we've been discussing... But from Martin's email I understood it more as being base packages. Unless I misunderstood, of course. If correct, which is it? More fool you... Maybe, used/worked with it and don't care for it one iota. But that's a whole different discussion. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Naritai jibun wo surikaetemo egao wa itsudemo suteki desuka... ___ 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] a suggestion ... Re: PEP 383 (again)
-On [20090430 07:18], Martin v. Löwis (mar...@v.loewis.de) wrote: Suppose I create a new directory, and run the following script in 3.x: py open(x,w).close() py open(b\xff,w).close() py os.listdir(.) ['x'] That is actually a regression in 3.x: Python 2.6.1 (r261:67515, Mar 8 2009, 11:36:21) import os open(x,w).close() open(b\xff,w).close() os.listdir(.) ['x', '\xff'] [Apologies if that was completely clear through the entire discussion, but I've lost track at a given point.] -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Heart is the engine of your body, but Mind is the engine of Life... ___ 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] UTF-8 Decoder
-On [20090414 16:43], Antoine Pitrou (solip...@pitrou.net) wrote: If you have some time on your hands, you could try benchmarking it against Python 3.1's (py3k) decoder. There are two cases to consider: Bjoern actually did it himself already: http://bjoern.hoehrmann.de/utf-8/decoder/dfa/#performance (results are Large, Medium, Tiny) PyUnicode_DecodeUTF8Stateful (3.1a2), Visual C++ 7.1 -Ox -Ot -G7 4523ms 5686ms 3138ms Manually inlined transcoder (see above), Visual C++ 7.1 -Ox -Ot -G7 4277ms 4998ms 4640ms So on medium and large datasets the decoder of Bjoern is very interesting, but the tiny case (just Bjoern's name) is quite a tad bit slower. The other cases seems more typical of what the average use in Python would be. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Nobilitas sola est atque unica virtus... ___ 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 383: Non-decodable Bytes in System Character Interfaces
-On [20090425 11:01], Paul Moore (p.f.mo...@gmail.com) wrote: PS Unfortunately, I suspect that the biggest group of people likely to be hit badly by this is people using non-latin scripts. And arguing probabilities without real data is optimistic at best. But those people are also the *least* likely people to contribute on an English-speaking list, I guess :-( (Sincere apologies if everyone but me on this list happens to actually be fluent English-speaking Russians :-)) Even though I am Dutch I have to deal with a variety of scripts for my i18n and L10n efforts, which includes contributions to Unicode. Aside from that I also have the fair share of audio files which have the names/descriptions in the respective script (Thai, Korean, Chinese, Taiwanese, Japanese, and so on). -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Necessity relieves us of the ordeal of choice... ___ 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] Issue5434: datetime.monthdelta
-On [20090417 04:55], s...@pobox.com (s...@pobox.com) wrote: Again, I think it needs to bake a bit. I understand the desire and need for doing date arithmetic with months. Python is mature enough though that I don't think you can just toss this in. It should be available as a module outside of Python so people can beat on it, flush out bugs, make suggestions for enhancements, whatever. I think people should look at mx.DateTime a bit, including its documentation. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B To do injustice is more disgraceful than to suffer it... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] UTF-8 Decoder
[Note: I haven't looked thoroughly at our handling yet, so hence I raise the question.] This got posted on the Unicode list, does it seem interesting for Python itself, the UTF-8 to UTF-16 transcoding might be? http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Whenever you meet difficult situations dash forward bravely and joyfully... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] py3k build erroring out on fileio?
Just to make sure I am not doing something silly, with a configure line as such: ./configure --prefix=/home/asmodai/local --with-wide-unicode --with-pymalloc --with-threads --with-computed-gotos, would there be any reason why I am getting the following error with both BSD make and gmake: make: don't know how to make ./Modules/_fileio.c. Stop [Will log an issue if it turns out to, indeed, be a problem with the tree and not me.] -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Forgive us our trespasses, as we forgive those that trespass against us... ___ 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] py3k build erroring out on fileio?
-On [20090409 15:41], Benjamin Peterson (benja...@python.org) wrote: It seems your Makefile is outdated. We moved the _fileio.c module around a few days, so maybe you just need a make distclean. Yes, that was the cause. Thanks Benjamin. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B You yourself, as much as anybody in the entire universe, deserve your love and affection... ___ 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] http://bugs.python.org/issue2240
-On [20090408 05:24], Tennessee Leeuwenburg (tleeuwenb...@gmail.com) wrote: It seems like the bug relates only to an older version of a 'weird' operating system ducks and could perhaps be left unfixed without causing anyone any problems. Being one of the FreeBSD guys I'll throw peanuts at you. :P In any case, 6.3 is from early 2008 and 6.4 is from November 2008. The 6-STABLE branch is still open and a lot of users are still tracking this. However, the main focus is 7 and with 8 looming on the horizon. And FreeBSD 7 does away with libc_r and uses a whole different model for its threading. Are the tests going ok there? If so, then I shouldn't worry about the 6 branch. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Few are those who see with their own eyes and feel with their own hearts... ___ 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] Evaluated cmake as an autoconf replacement
-On [20090329 19:21], Jeffrey Yasskin (jyass...@gmail.com) wrote: However, Brett Cannon and I talked, and we think this is surmountable. First, nearly every desktop system comes with a Python interpreter, which would avoid the bootstrap for ordinary development. This is quite a major assumption. Most FreeBSD, NetBSD, and OpenBSD users tend to install a minimal binary OS (kernel plus system tools) and then proceed to install third party applications via either ports or pkgsrc. This means that Python gets built from scratch. So depending on Python to build Python seems a bad decision if you care for my opinion. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B I must be cruel, only to be kind... ___ 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] Formatting mini-language suggestion
-On [20090312 06:50], Lie Ryan (lie.1...@gmail.com) wrote: How about having a country code field, e.g. en-us would format according to US locale, in to India, ch to China, etc... that way the format string would become very simple (although the lib maintainer would need to know customs from all over the world). Then have a special country code that is a placeholder for whatever the locale the machine is set to. Then you are effectively duplicating what is already available via CLDR [1] and Babel [2]. [1] http://www.unicode.org/cldr/ [2] http://babel.edgewall.org/ -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Any road leads to the end of the world... ___ 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] A suggestion: Do proto-PEPs in Google Docs
-On [20090220 18:51], Guido van Rossum (gu...@python.org) wrote: I still don't like wikis for this purpose very much -- a person editing effectively grabs a lock on the whole file. Imagine a Wiki with a cross-polination of Etherpad [1], that would resolve that complaint. [1] http://etherpad.com/ -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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] Attention Bazaar mirror users
-On [20090221 21:30], Barry Warsaw (ba...@python.org) wrote: I think no matter what DVCS gets chosen Isn't that getting ahead of the game? I thought that the choice whether or not a DVCS gets chosen is part of that PEP? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pycon and Randall Munroe
Whoever thought this one up [1], thank you for making me almost choke on my meal due to laughing fits. :-) [1] http://pycon.blogspot.com/2009/02/randall-munroe.html -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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 3.0.1
-On [20090128 00:21], Raymond Hettinger (pyt...@rcn.com) wrote: Also, 3.0 is a special case because it is IMO a broken release. AFAICT, it is not in any distro yet. Hopefully, no one will keep it around and it will vanish silently. It is in FreeBSD's ports since December. Fairly good chance it is in pkgsrc also by now. Might even be that it is part of FreeBSD's 7.1-RELEASE. So I reckon with 'distro' you were speaking of Linux only? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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 3.0.1
-On [20090128 00:57], Barry Warsaw (ba...@python.org) wrote: I stand by my opinion about the right way to do this. I also think that a 3.1 release 6 months after 3.0 is perfectly fine and serves our users just as well. When API fixes were mentioned, does that mean changes in the API which influence the C extension? If so, then I think a minor number update (3.1) is more warranted than a revision number update (3.0.1). -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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] Support for the Haiku OS
-On [20090115 01:11], Guido van Rossum (gu...@python.org) wrote: I'm with Martin. In these days of distributed version control systems, I would think that the effort for the Haiku folks to maintain a branch of Python in their own version control would be minimal. It is likely that for each new Python version that comes out, initially it is broken on Haiku, and then they have to go in and fix it. Last time I looked at Haiku and dabbled with it there were some people actively working on POSIX compliance. My only guess right now is that this work is largely complete. In effect that would mean that Python would work out of the box, more or less. So the cost of adding and maintaining it in the main repository should not be a big overhaul or anything. Just as a FYI. :) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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] Support for the Haiku OS
-On [20090115 16:53], Guido van Rossum (gu...@python.org) wrote: Did you look at the patch they submitted? http://bugs.python.org/issue4933 I did now (python-2.5.4-haiku-2.diff). I am not sure what you are implying though, Guido. It doesn't look like a huge change and most of it is close to 'one time only'. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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] [Py3k] curses module and libncursesw library
-On [20090108 02:23], Victor Stinner (victor.stin...@haypocalc.com) wrote: It looks like libncursesw is available on Linux, *BSD, Mac OS X. On FreeBSD I know it is for 7.x, but I am not sure about 6.x. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Earth to earth, ashes to ashes, dust to dust... ___ 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.5.3: call for patches
-On [20081020 19:07], A.M. Kuchling ([EMAIL PROTECTED]) wrote: This fixes a memory leak in itertools.chain(), which was greatly changed between 2.5 and 2.6, and the patch was to code not present in 2.5. Are you sure this bug affected 2.5 at all? No, my mind was caught up between versions, so Raymond's closing the issue is the logical thing to do. Apologies for wasting those few minutes. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Nothing is more honorable than enlightenment, nothing is more beautiful than virtue... ___ 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.5.3: call for patches
Martin, -On [20081007 09:27], Martin v. Löwis ([EMAIL PROTECTED]) wrote: Within a few weeks, we will release Python 2.5.3. This will be the last bug fix release of Python 2.5, afterwards, future releases of 2.5 will only include security fixes, and no binaries (for Windows or OSX) will be provided anymore (from python.org). Since we tripped over these with Trac/Genshi we would appreciate if the following could be applied (if not already): http://bugs.python.org/issue2231 http://bugs.python.org/issue2246 (http://bugs.python.org/issue2321 seems to be in 2.5 already based on the last comment) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Ignorance is the opportunity to learn... ___ 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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)
-On [20080904 16:22], C. Titus Brown ([EMAIL PROTECTED]) wrote: I agree. I like bsddb for just this reason and I'd like to continue being able to use it! I think that there are many reasons why having such a thing in the stdlib is really useful and I also think it's worth exploring the ramifications of taking it out... And having to install bsddb from an external source disables your use, how? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Infinite Dreams, I can't deny them, Infinity is hard to comprehend... ___ 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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)
-On [20080905 12:34], Kevin Teague ([EMAIL PROTECTED]) wrote: However, all does not seem to be right with the bsddb module on the system Python 2.5 on Mac OS X 10.5: import bsddb [snip] ImportError: No module named _bsddb The bsddb module is built separately from Python within FreeBSD's ports. I think Apple did the same for Mac OS X. ports/databases/py-bsddb ports/databases/py-bsddb3 So for a fair number of systems the 'bsddb' module being an external package/dependency is already true. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Honesty is the first chapter of the book of wisdom... ___ 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: Consolidating names and classes in the `unittest` module (updated 2008-07-15)
-On [20080715 12:35], Ben Finney ([EMAIL PROTECTED]) wrote: That measured only usage of unittest *within the Python standard library*. Is that the only body of unittest-using code we need consider? Some greps on random Python projects give me a 4-10:1 ratio for assert* versus fail*. Personally I also find the assert* syntax preferable over fail*. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If I am telling you the Truth now, do you believe it..? ___ 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] urllib.quote and unquote - Unicode issues
-On [20080712 19:27], Matt Giuca ([EMAIL PROTECTED]) wrote: Basically, urllib.quote and unquote seem not to have been updated since Python 2.5, and because of this they implicitly perform Latin-1 encoding and decoding (with respect to percent-encoded characters). I think they should default to UTF-8 for a number of reasons, including that's what other software such as web browsers use. Very nice, I had this somewhere on my todo list to work on. I'm very much in favour, especially since it synchronizes us with the RFCs (for all I remember reading about it last time). -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Can your hear the Dolphin's cry..? ___ 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] UCS2/UCS4 default
My apologies for hammering on this, but I think it is quite important and
currently Python 3.0 seems confused about UCS-2 versus UTF-16.
-On [20080702 20:47], Guido van Rossum ([EMAIL PROTECTED]) wrote:
No, Python already is aware of surrogates. I meant applications
processing non-BMP text should beware of them.
Just to make sure people are fully aware of the distinctions:
UCS-2 uses 16 bits to encode Unicode data, does NOT support surrogate pairs
and therefore CANNOT represent data beyond U+ (thus only supporting the
Basic Multilingual Plane, BMP). It is a fixed-length character encoding.
UTF-16 also uses 16 bits to encode Unicode data, but DOES support surrogate
pairs and therefore CAN represent data beyond U+ by using said surrogate
pairs (thus supporting all planes). It is a variable-length character
encoding.
So a string representation in UCS-2 means every character occupies 16 bits.
A string representation in UTF-16 means characters can occupy 16 bits or
32-bits.
If one stays within the BMP than all is well, but when you move beyond the
BMP (U+1 - U+10) then Python needs to correctly check the string
for surrogate pairs and deal with them internally.
If you find places where the Python core or standard library is doing
Unicode processing that would break when surrogates are present you
should file a bug. However this does not mean that every bit of code
that slices a string at an arbitrary point (and hence risks slicing in
the middle of a surrogate) is incorrect -- it all depends on what is
done next with the slice.
Basically everything but string forming or string printing seems to be
broken for surrogate pairs, from what I can tell.
Also, I think you are confused about slicing in the middle of a surrogate
pair, from a UTF-16 perspective this is 1 codepoint! And as such Python
needs to treat it as one character/codepoint in a string, dealing with
slicing as appropriate. The way you currently describe it is that UTF-16
strings will be treated as UCS-2 when it comes to slicing and the likes.
From a UTF-16 point of view such slicing can NEVER occur unless you are bit
or byte slicing instead of character/codepoint slicing.
The documentation for len() says:
Return the length (the number of items) of an object.
I think it can be fairly said that an item in a string is a character or
codepoint. Take for example the following string:
a = '\U00020045\u942a' # Two hanzi/kanji/hanja
From a Unicode perspective we are looking at two characters/codepoints.
When we use a 4-byte Python 3.0 binary we get (as expected):
len(a)
2
When we use a 2-byte Python 3.0 binary (the default) we get (not as
expected):
len(a)
3
From a UTF-16 perspective a surrogate pair is one character/codepoint and
as such len() should have reported 2 as well. That the sequence is stored
internally as 0xd840 0xdc45 0x942a and occupies 3 bytes is not interesting.
But it seems as if len() is treating the string as being in UCS-2
(fixed-length), which is the only logical explanation for the number 3,
instead of treating it as UTF-16 (variable-length) and reporting the number
2.
Subsequently doing a: print a[1] to get the 0x942a (鐪) actually requires
a[2] on the 2-byte Python 3.0. As such the code you write for 2-byte and
4-byte Python 3.0 is *different* when you have to deal with the same Unicode
strings! This cannot be the desired situation, can it?
Two more examples:
a.find('鐪') # 4-byte
1
a.find('鐪') # 2-byte
2
import re # 4-byte
m = re.search('鐪', a)
m.start()
1
import re # 2-byte
m = re.search('鐪', a)
m.start()
2
This, in my opinion, has nothing to do with the application writers, but
more with Python's internals being confused about UCS-2 and UTF-16. We
accept full 32-bit codepoints with the \U escape in strings, and we may even
store it as UTF-16 internally, but we clearly do not deal with it properly
as UTF-16, but rather as UCS-2, when it comes to using said strings with
core functions and modules.
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
For wouldst thou not carve at my Soul with thine sword of Supreme Truth?
___
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] UCS2/UCS4 default
-On [20080703 15:00], M.-A. Lemburg ([EMAIL PROTECTED]) wrote: Unicode if full of combining code points - if you break such a sequence, the output will be just as wrong; regardless of UCS2 vs. UCS4. In my opinion you are confusing two related, but very separated things here. Combining characters have nothing to do with breaking up the encoding of a single codepoint. Sure enough, if you arbitrary slice up codepoints that consist of combining characters then your result is indeed odd looking. I never said that nor is that the point I am making. Guido points out that Python supports surrogate pairs and says that if Python is dealing wrongly with this in the core than it needs to be fixed. I am pointing out that given the fact we allow surrogate pairs we deal rather simplistic with it in the core. In fact, we do not consider them at all. In essence: though we may accept full 21-bit codepoints in the form of \U escape sequences and store them internally as UTF-16 (which I still need to verify) we subsequently deal with them programmatically as UCS-2, which is plain silly. You either commit yourself fully to UTF-16 and surrogate pairs or not. Not some form in-between, because that will ultimately lead to more confusion due to the difference in results when dealing with Unicode. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Believe in Angels... ___ 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] UCS2/UCS4 default
-On [20080703 15:58], Guido van Rossum ([EMAIL PROTECTED]) wrote: Your seem to be suggesting that len(u\U00012345) should return 1 on a system that internally uses UTF-16 and hence represents this string as a surrogate pair. From a Unicode and UTF-16 point of view that makes the most sense. So yes, I am suggesting that. This is not going to happen. You may as well complain to the authors of the Java standard about the corresponding problem there. Why would I need to complain to them? They already fixed it since 1.5.0. Java 1.5.0's release notes (http://java.sun.com/developer/technicalArticles/releases/j2se15/): Supplementary Character Support 32-bit supplementary character support has been carefully added to the platform as part of the transition to Unicode 4.0 support. Supplementary characters are encoded as a special pair of UTF16 values to generate a different character, or codepoint. A surrogate pair is a combination of a high UTF16 value and a following low UTF16 value. The high and low values are from a special range of UTF16 values. In general, when using a String or sequence of characters, the core API libraries will transparently handle the new supplementary characters for you. See also http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.html The methods that accept an int value support all Unicode characters, including supplementary characters. For example, Character.isLetter(0x2F81A) returns true because the code point value represents a letter (a CJK ideograph). -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Life can only be understood backwards, but it must be lived forwards... ___ 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] UCS2/UCS4 default
-On [20080703 17:32], Paul Moore ([EMAIL PROTECTED]) wrote: System.out.println(s.length()); I think you want to use codePointCount() to count the Unicode code points. length() returns Unicode code units. As http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.html explains: In the J2SE API documentation, Unicode code point is used for character values in the range between U+ and U+10, and Unicode code unit is used for 16-bit char values that are code units of the UTF-16 encoding. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Man is the measure of all things... ___ 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] UCS2/UCS4 default
-On [20080703 17:03], Guido van Rossum ([EMAIL PROTECTED]) wrote: I don't see an answer there to the question of whether the length() method of a Java String object containing a single surrogate pair returns 1 or 2; I suspect it returns 2. As http://java.sun.com/j2se/1.5.0/docs/api/java/lang/CharSequence.html#length() states: int length() Returns the length of this character sequence. The length is the number of 16-bit chars in the sequence. But since Java switched to full UTF-16 support in 1.5.0 they extended their API since the existing methods have probably come too ingrained. E.g. codePointCount() http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.html#codePointCount(char[],%20int,%20int) The one thing that may be missing from Python is things like interpretation of surrogates by functions like isalpha() and I'm okay with adding that (since those have to loop over the entire string anyway). Those would be welcome already, yes. I'll see if I can help out. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Fallen into ever-mourn, with these wings so torn, after your day my dawn... ___ 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] UCS2/UCS4 default
-On [20080703 18:45], James Y Knight ([EMAIL PROTECTED]) wrote: I think this is misguided. Only trying to at least correct the current situation, which I consider a bit of a mess, personally. (Although it seems others share my view.) I'd like to have 3 levels of access available: 1) byte-level. In a new implementation I'd probably choose to make all my strings stored in UTF-8, but UTF-16 is fine too. 2) codepoint-level. 3) grapheme-level. Sounds interesting as well and I can very much see the advantages of such levels and their methods. Especially in the i18n/l10n work I do. You should be able to iterate over the string at any of the levels, ask for the nearest codepoint/grapheme boundary to the left or right of an index at a different level, etc. [snip] Actually it seems Java already has a lot of similar methods. There are a few more desirable operations, to manipulate strings at the grapheme level (because unlike for UTF-8/UTF-16 codepoints, graphemes don't have the nice property of not containing prefixes which are themselves valid graphemes). So, you want a find (and everything else that implicitly does a find operation, like split, replace, strip, etc) which requires that both endpoints of its match are on a grapheme-boundary. [[Probably the easiest way to implement this would be in the regexp engine.]] Well, your ideas and seeing Java's stuff actually got me excited to work on these kind of ideas, next to my datetime revamp. What would the chances for inclusion in Python be if such a PEP + code would be presented Guido? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Beware of the fury of the patient man... ___ 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] UCS2/UCS4 default
-On [20080703 19:21], Adam Olsen ([EMAIL PROTECTED]) wrote: On Thu, Jul 3, 2008 at 7:57 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote: Please remember that lone surrogate pair code points are perfectly valid Unicode code points, nevertheless. Just as a lone combining code point is valid on its own. That is a big part of these problems. For all practical purposes, a surrogate is like a UTF-8 code unit, and must be handled the same way, so why the heck do they confuse everybody by saying oh, it's a code point too!? Because surrogate code points are not Unicode scalar values, isolated UTF-16 code units in the range 0xd800-0xdfff are ill-formed. (D91 from Unicode 5.0/5.1, section 3.9) So, no, it is not a code point too. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Als men blijft geloven kan de zwaarste steen niet zinken... ___ 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] UCS2/UCS4 default
-On [20080703 19:31], Martin v. Löwis ([EMAIL PROTECTED]) wrote: Yes, but it is two code units. Python's UTF-16 implementation operates on code units, not code points. Thank you, that is the single most important piece of information I got about this entire thing because it does change the entire approach. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Knowledge comes, but Wisdom lingers... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] UCS2/UCS4 default
Guido (and others of course), back in 2001 you pointed out that you wanted to move to UCS4 completely as the ideal situation (http://mail.python.org/pipermail/i18n-sig/2001-June/001107.html) over the current default UCS2. Given 3.0 will use Unicode strings as the default, would it also not make sense to make the switch at this point as well? The current situation with UCS2 is particularly bad now that the CJK ideographs Extension B. has been produced (and C is under ballot and D is under development). Personally I use nothing else but UCS4 compiled Python binaries for the past years. See also http://www.python.org/dev/peps/pep-0261/ for background for the 2001 options. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Expansion of happiness is the purpose of life... ___ 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] UCS2/UCS4 default
-On [20080702 19:08], Guido van Rossum ([EMAIL PROTECTED]) wrote: I think we should continue to leave this up to the distribution. AFAIK many Linux distros already use UCS4 for everything anyway. FreeBSD's ports makes it a configure option. For that reason I think it's also better that the configure script continues to default to UTF-16 -- this will give the UTF-16 support code the necessary exercise. (It is mostly a superset of the UCS-4 support code, so I'm less worried about the latter getting enough exercise.) I was under the impression that it was still UCS2 and thus limiting things to the BMP only. So you are saying it's UTF-16 nowadays? For both 2.6 and 3.0? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Nature does nothing uselessly... ___ 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] UCS2/UCS4 default
-On [20080702 19:42], Guido van Rossum ([EMAIL PROTECTED]) wrote:
Yes. At least in the sense that \U gets translated to a
surrogate pair, and that the UTF-8 codec supports surrogate pairs in
both directions. It's been like this for a long time. What else would
you expect from UTF-16 support?
Well, unless I misunderstand things, a Python 3 compiled with the default
Unicode option gives this:
len(\N{MUSICAL SYMBOL G CLEF})
2
Whereas a Python 3 with --with-wide-unicode gives:
len(\N{MUSICAL SYMBOL G CLEF})
1
This, of course, causes problems with splitting, finding, and so on. So that
means that a Python 3 with only 2 byte Unicode support is not to be
used/recommended for Unicode outside of the BMP.
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Tomorrow's battle is won during today's practice...
___
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] UCS2/UCS4 default
-On [20080702 20:27], Guido van Rossum ([EMAIL PROTECTED]) wrote: I disagree. Instead, I would say that such code needs to be aware of surrogates. Just to make sure I understood you: Python's code needs to be made aware of surrogates? If so, do you want me to log issues for the things encountered? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Learn from the past -- don't wear it like a yoke around your neck... ___ 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] Invitation to try out open source code review tool
-On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote: http://code.google.com/p/rietveld/source/browse Is it a reference to Gerrit Rietveld (Dutch architect and furniture designer)? I guess the architect part would make sense for a code review tool. :) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If Winter comes, can Spring be far behind..? ___ 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] urllib unicode handling
-On [20080507 04:06], Tom Pinckney ([EMAIL PROTECTED]) wrote: While in theory UTF-8 is not a standard, sites like Last.fm, Facebook and Wikipedia seem to have embraced it (as have pretty much all other major web sites). As with HTML, there is what the standard says and what the actual browsers have to accept in order to work in the real world. I agree with you. The dictionary project I am working on (Dutch Japanese) uses in the URLs UTF-8 characters and things just worked with reasonably new browsers (at least no problems with Opera 9, Firefox 2 and 3, Internet Explorer 7 and Safari 3). Then later Armin Ronacher warned me that you still have to URL-escape these things in order to not be in lala-land. Would people object if such functionality got added to urllib? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If Winter comes, can Spring be far behind..? ___ 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] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 08:26], Martin v. Löwis ([EMAIL PROTECTED]) wrote: It seems you don't want to identify whether the Windows installation is a Win64 one, but whether the Python installation is, right? I think we can say with a reasonably certainty that if the Python installation is 64-bits the OS is 64-bits too. So yes, if we can identify the Python installation is 64-bits that would be helpful. For this, you should use platform.architecture()[0] OK, thanks, that's useful, but please see my response to Mark about the why and why platform.architecture()[0] helps, but not fully though. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Tonight your soul sleeps, but one day you will feel real pain, maybe then you will see me as I am: a fragile wreck on a storm of emotion... ___ 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] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 07:57], Mark Hammond ([EMAIL PROTECTED]) wrote: The best way I can find for the win32 API to tell you this is a combination of the above and the IsWow64Process() (which returns True if you are a 32bit process on a 64bit platform) Support for IsWow64Process() is quite interesting in itself, so if you can add support for that, cool. :) I'd be interested to know why you care though - ie, how will the behavior of your programs depend on that? For Genshi I was mucking around with setuptools to create Windows eggs. My machine at home is an AMD64 box. I have Python 2.5 installed, which is 64 bits on Windows x64. On a normal Unix box an egg for a 32 bits system will result in something like Genshi-0.5dev_r847-py2.5-linux-i686.egg. On an 64-bits system we get Genshi-0.5dev_r847-py2.5-linux-x86_64.egg. This distinction is important since Genshi includes a _speedups.so which is compiled to either 32 or 64-bits. On a 64-bits Windows it will always create an egg with win32 in the name. So both a 32-bits and 64-bits Python will in the end create an egg with win32. So imagine creating a 64-bits egg with compiled _speedups and putting it on PyPI. Any 32-bits Python requesting Genshi will get the egg with 64-bits compiled binaries in it. I think it's obvious this is Not Good(tm). (I already raised the issue on distutils-sig, but it has remained unanswered thus far.) So from what I gather we have no unique way to refer to 32-bits or 64-bits Python aside from the semi-adequate platform.architecture()[0]. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Be yourself is all that you can do. ___ 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] Detecting 64bit Windows (was RE: Reminder: last alphas next Wednesday 07-May-2008)
-On [20080502 10:46], Mark Hammond ([EMAIL PROTECTED]) wrote: OK - I'll make a patch for this tomorrow (unless someone pipes up suggesting it's not a great idea, or that ctypes should be used, etc) Thanks. I am sure something like that might come in handy for our Python-using games developers. And other developers too. ;) From the above, it's not clear what problem you have other than arranging for setuptools to select the correct binaries and generate an egg with a distinction in the filename. Ie, why isn't platform.architecture() (or possibly distutils.util.get_platform) adequate to have setuptools do the right thing in your examples? Unfortunately though, I don't know enough about setuptools to suggest how this might happen. Sorry, my bad, yes, the platform.architecture() is helpful, the only problem is that I'd rather settle for a sort of standardized nomenclature for this. Both platforms use the win32 API, so would Windows XP be win32-32 and x64 be win32-64 or something like that? If you go this route, please followup on the distutils list (I must have missed your message there while I was on vacation) Will do, since there is another issue that makes using setuptools on 64-bits Windows non-working, at least where it concerns easy_install. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B The taller the bamboo grows, the lower it bends. - Chinese saying ___ 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] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 11:00], Christian Heimes ([EMAIL PROTECTED]) wrote:
Windows and Mac OS X have dedicated directories for application specific
libraries. That is ~/Library on Mac and Application Data on Windows. The
latter is i18n-ed and called Anwendungsdaten in German. Fortunately
Windows sets an environment var to the application data directory.
And Vista has C:\ProgramData\{vendor}\{application}, which is *not*
$APPDATA, but $ProgramData. $APPDATA points to
C:\Users\{user}\AppData\Roaming on Vista -- which is very different.
Windows uses the Roaming folder for application specific data, such as
custom dictionaries, which are machine independent and should roam with the
user profile. The AppData\Roaming folder in Windows Vista is the same as the
Documents and Settings\username\Application Data folder in Windows XP.
I think that's different from what you meant above though, since I doubt
you'd want this (the libraries) to roam with the user.
See
http://download.microsoft.com/download/3/b/a/3ba6d659-6e39-4cd7-b3a2-9c96482f5353/Managing%20Roaming%20User%20Data%20Deployment%20Guide.doc
for more background.
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Seek not death in the error of your life: and pull not upon yourselves
destruction with the works of your hands...
___
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] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: Groan. Then everyone else realizes what a great idea this is, and we see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a directory with a comment market in its name), ~/Lisp/ and the rest? I don't think people would thank us for that in the long term. I'm +1 on just using $HOME/.local, but otherwise $HOME/.python makes sense too. $HOME/.python.d doesn't do it for me, too clunky (and hardly used if I look at my .files in $HOME). But I agree with Steve that it should be a hidden directory. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae..? ___ 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] Reminder: last alphas next Wednesday 07-May-2008
-On [20080502 14:49], Richard Boulton ([EMAIL PROTECTED]) wrote:
So, on Ubuntu computers at least, it seems likely that a $HOME/.local/
directory will already exist, with the beginnings of a unix style layout
inside it.
On my Ubuntu 8 box:
[15:11] [EMAIL PROTECTED] (0) {0} % ls ~/.local
share
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
The only source of knowledge is experience...
___
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] Reminder: last alphas next Wednesday 07-May-2008
-On [20080501 22:27], Barry Warsaw ([EMAIL PROTECTED]) wrote: Time is running short to get any new features into Python 2.6 and 3.0. Is there a reliable way to identify 32-bits and 64-bits Windows from within Python? I have not found any yet, but it might be a mere oversight on my behalf. The reason I ask is that both return win32, which is most likely a reference to the API, even when having installed the 64 bits Python version. This, of course, by using win32 causes some issues with, for example, setuptools since it generate an egg with a win32 identifier. Now if you have Python C extension code it will be 64-bit compiled, thus not working on 32-bits Windows. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B All are lunatics, but he who can analyze his delusions is called a philosopher. ___ 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] Known doctest bug with unicode?
-On [20080418 18:05], Adam Olsen ([EMAIL PROTECTED]) wrote: 4. Make doctest smarter, so that it can grab the original module's encoding. 5. Wait until 3.0, where this is hopefully fixed by making doctests use unicode by default? Getting rid of the u in front of the strings as required made Python 3 indeed run the doctests as they should. So there's a difference in behaviour between 2.x and 3.0 when it comes to this part. I guess the better behaviour would be for doctest to honour the encoding specified in the file/module? If other people agree I can see what I can to make that work. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Confutatis maledictis, flammis acribus addictis... ___ 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] unscriptable?
-On [20080420 03:04], Nick Coghlan ([EMAIL PROTECTED]) wrote: To suggest yet another colour for the bikeshed, maybe we should ditch both unindexable and unsubscriptable and go with 'int' is not a sequence or mapping. Any object which supports subscript notation will be one or the other. Sounds even clearer to me. +1 -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B It is necessary to be noble, and yet take humility as a basis. It is necessary to be exalted, and yet take modesty as a foundation... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Known doctest bug with unicode?
Is it a known doctest bug that when you have a dict with Unicode key values that doctest dies with a KeyError? When I excute my code from the regular python interpreter it works as expected. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Whenever you meet difficult situations dash forward bravely and joyfully... ___ 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] Proposed unittest changes
-On [20080417 19:46], Terry Reedy ([EMAIL PROTECTED]) wrote: Have you or are you going to make these changes or should I open a separate tracker issue? You can always put it on my account in the tracker (asmodai) and I'll get to it in the coming days. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The administration of justice is the firmest pillar of government... ___ 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] mmap.flush [was: NeedsReview keyword]
-On [20080415 23:37], Ralf Schmitt ([EMAIL PROTECTED]) wrote: The documentation for mmap.flush does not even mention a return value. Fixed in revision 62359. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ With a nuclear fire of Love in our Hearts, rest easy baby, rest easy... ___ 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.6a2 execution times with various compilers
-On [20080413 00:47], Gregory P. Smith ([EMAIL PROTECTED]) wrote: With gcc 4.1.3 i'm finding that profile guided optimization when trained on pybench or regrtest does make a measurable difference (2-5% overall time with 10-20% on some pybench tests). I haven't run benchmarks enough times to be confident in my results yet, I'll report back with data once I have it. I'm testing both pybench and regrtest as profiling training runs. It seems GCC 4.2.4 yields worse code for Python with the same options as 4.2.1, I measured about ~7%-8% slowdown (~0,5 seconds) on my test. Granted, in general this might all be nitpicking, but for our friends in the calculating departments this might be quite useful to know. The differences are in general not concentrated in specific sections of pybench, but are uniformly distributed. I know my employer can use such additional free optimizations since our jobs spawn in many hours of execution. Next to optimizing the source code, of course, this will also shave off quite a lot of execution time. I will check in a special makefile target for easy gcc profile guided compiles shortly so that those who want faster builds easily produce them. That would be interesting I think. I went with -fprofile-generate and -fprofile-use in my small test. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Put your heart, mind, intellect and soul even to your smallest acts. This is the secret of success... ___ 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] Reserving an arg space for Jython
-On [20080413 19:59], Martin v. Löwis ([EMAIL PROTECTED]) wrote:
Making suggestions on the list, and then following up with patch,
is certainly encouraged, and happens all the time.
Here you go.
I just think that *this* specific proposed change is more effort to
talk about than it's worth.
So I wonder why it couldn't have been changed then instead of spending
another email on the subject. :P tongue firmly planted in cheek
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Without you, I am nothing...
Index: Python/getopt.c
===
--- Python/getopt.c (revision 62327)
+++ Python/getopt.c (working copy)
@@ -88,7 +88,7 @@
if (option == 'X') {
fprintf(stderr,
- -X is reserved for non-standard arguments\n);
+ -X is reserved for implementation-specific arguments\n);
return '_';
}
Index: Modules/main.c
===
--- Modules/main.c (revision 62327)
+++ Modules/main.c (working copy)
@@ -390,7 +390,7 @@
skipfirstline = 1;
break;
- /* case 'X': reserved for non-standard arguments */
+ /* case 'X': reserved for implementation-specific arguments */
case 'U':
Py_UnicodeFlag++;
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] configure on FreeBSD 7
I do not have this problem on FreeBSD 6.3-STABLE, but on my FreeBSD
7.0-STABLE I get this problem after running an identical ./configure:
[09:11] [EMAIL PROTECTED] (0) {0} % make
Makefile, line 1192: warning: duplicate script for target Modules/ ignored
Makefile, line 1194: warning: duplicate script for target Modules/ ignored
Makefile, line 1196: warning: duplicate script for target Modules/ ignored
Makefile, line 1198: warning: duplicate script for target Modules/ ignored
Makefile, line 1200: warning: duplicate script for target Modules/ ignored
Makefile, line 1202: warning: duplicate script for target Modules/ ignored
Makefile, line 1204: warning: duplicate script for target Modules/ ignored
Makefile, line 1206: warning: duplicate script for target Modules/ ignored
Makefile, line 1208: warning: duplicate script for target Modules/ ignored
Graph cycles through thread
make: don't know how to make threadmodule.c. Stop
line 1192 is:
Modules/ thread threadmodule.o: $(srcdir)/Modules/ thread threadmodule.c; $(CC)
$(PY_CFLAGS) -c $(srcdir)/Modules/ thread threadmodule.c -o Modules/ thread
threadmodule.o
On my 6.3 box it became:
Modules/threadmodule.o: $(srcdir)/Modules/threadmodule.c; $(CC) $(PY_CFLAGS)
-c $(srcdir)/Modules/threadmodule.c -o Modules/threadmodule.o
As you can see, some spurious 'thread' mentions got inserted.
Apparently this section is made by makedepend.
Has anyone else encountered this?
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
No man is good enough to govern another man without the other's consent...
___
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] configure on FreeBSD 7
-On [20080412 09:32], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote: Apparently this section is made by makedepend. I had no updates for makedepend or autotools, but somewhere along the full upgrade of all my ports makedepend suddenly started to behave, so some dependency must have caused the previous breakage. I wonder which though, since I forced a recompile of makedepend before emailing. Peculiar. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The only trust in this world is that of steel... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] weird configure (autotools) setup
Why is CFLAGS in Makefile.pre.in specified as CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) whereas that will negate any CFLAGS you pass to configure? A normal call to configure (as ./configure --help also explains) can contain a CFLAGS specification, e.g.: CFLAGS=-compiler_options ./configure --config_options Configure happily compiles and tests everything with the working CFLAGS (as evident in config.log), but when it comes to the output substitution it will, of course, not be overridden. Now, I realize that configure.in talks about BASECFLAGS and OPT, but neither of these are documented in the ./configure --help output, nor are they standard when it comes to autotooling. Passing CFLAGS is the defacto standard. Furthermore, when passing compiler options to OPT, these are NOT taken along in the configure tests, which means you might have passed faulty options but configure will not detect any problems with them. You will only encounter this when you start building. So is there any rationale for all this? -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Contentment that derives from knowing when to be content is eternal contentment... ___ 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.6a2 execution times with various compilers
I did some more tests concentrating on GCC, partly based on the feedback I got, results at http://www.in-nomine.org/2008/04/12/python-26-compiler-options-results/ Executive summary: Python needs to be compiled with -O2 or -O3. Not doing so, no optimization level, results with GCC 4.2.1 in a doubling of execution time. Using just -O1 is still ~15% slower than using -O2. Using -mtune=native -march=native can shave of 0,1/0,2 seconds, but otherwise I did not find much difference in using having march or mfpmath present. Profile-guided optimization did not help much, as might be expected, it pushed about the same kind of optimization as the mtune/march combination. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ All know that the drop merges into the ocean but few know that the ocean merges into the drop. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.6a2 execution times with various compilers
I did some performance comparisons with various compilers and the resulting Python 2.6a2 and pybench. I put the details on http://www.in-nomine.org/2008/04/11/python-26a2-execution-times-with-various-compilers/ Of course, take benchmark results with a grain of salt, but it seems ICC can provide people with an added performance edge when using Python. In short: I measured a speedup between ~21%-29% with ICC compared to GCC. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ I was searching through the Heavens and somehow I slipped... ___ 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] editing the docs
-On [20080329 17:13], Benjamin Peterson ([EMAIL PROTECTED]) wrote: Now that I'm starting to examine and do some edits on the docs, I'd like to ask some guidance. What editor(s) do you guys use? I'm not one to cling to an editor, so all suggestions are fair game. I personally use vim. But this question is really dependent on what you think works best. Some prefer command line tools, others graphical tools. Just try a few and see what you personally find to work nicely enough. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ To love someone deeply gives you strength. Being loved by someone deeply gives you courage... ___ 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] FreeBSD test suite failure - curses
-On [20080329 18:37], Martin v. Löwis ([EMAIL PROTECTED]) wrote:
Even if there is a bug in the test or in Python that causes newscr to
become NULL - why does that not show up in other releases, or on other
systems?
I have been breaking my head about that as well. But then again it is just
as strange that from a script run it does not coredump whereas running from
the interactive prompt or from the testsuite it does. That should, in
principle, not be much different either.
Can you debug this and confirm that this call indeed sets newscr to NULL?
Breakpoint 1, 0x283119f8 in setupterm () from /lib/libncursesw.so.6
(gdb) print newscr
$1 = 0
(gdb) cont
Continuing.
Breakpoint 1, 0x283119f8 in setupterm () from /lib/libncursesw.so.6
(gdb) print newscr
$2 = 0
(gdb) cont
Continuing.
Hardware access (read/write) watchpoint 2:
{data variable, no debug info} 674382472
Value = 0
0x2836e102 in PyCurses_getsyx (self=0x0)
at /usr/home/asmodai/projects/python/Modules/_cursesmodule.c:1770
1770 getsyx(y, x);
(gdb) print newscr
$3 = (WINDOW *) 0x0
If you have any specific debug guidance, please feel free to give so. :)
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
The superior person uses his mind like a mirror: it accepts all, it
reflects all. It receives, but it does not keep...
___
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] FreeBSD test suite failure - curses
-On [20080309 23:59], Martin v. Löwis ([EMAIL PROTECTED]) wrote:
So this now *is* a FreeBSD/ncurses expert's question.
Actually, given my recent results and discussion with Thomas Dickey I am not
so sure.
Some basic debugging I did with Georg Brandl led to this:
comment the requires('curses') line in test_curses.py.
Then start python in the build root with ./pyton; from the interactive
prompt I do import curses and import test.test_curses and python
subsequently coredumps after some screen manipulation. Setting an awatch
with gdb on newscr shows that at one point it gets set to 0.
When I put import curses and import test.test_curses in a file and
subsequently execute this with ./python the test passes without any
problems.
Thomas mentioned after seeing an ltrace:
Perhaps it's failing on that:
curses.setupterm(fd=sys.__stdout__.fileno())
That would have newscr null. The failure might be from closing stdout, e.g.,
if it was redirected.
--
Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
We've laid together in the sun before the mind-rape has begun...
___
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] Windows build bot failure
-On [20080328 10:44], Christian Heimes ([EMAIL PROTECTED]) wrote: Some Windows build bots can't compile openssl. The MS assembler fails to assemble a file. I *think* the issue can be fixed by using nasm32 instead of masm. A posting to the OpenSSL list on 2007-10-22: It's a problem with older versions of MASM. The following patch works around this issue: http://cvs.openssl.org/chngview?cn=16708 However MASM is being phased out in OpenSSL (it wont be supported at all in 0.9.9) so you are advised to switch to the free NASM instead which doesn't have such problems. (http://www.mail-archive.com/[EMAIL PROTECTED]/msg50725.html) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Atone me to my throes curtail... ___ 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
