Re: [Python-Dev] Python and the Unicode Character Database

> Maybe all past, present and future whatsnew maintainers can agree on these > rules, which I copied directly from whatsnew/3.2.rst? I don't think all past maintainers can (I'm pretty certain that AMK would disagree), but if that's the current policy, I can certainly try following it (I didn't kno

Re: [Python-Dev] Porting Ideas

> Aside: how does one log into the Cheeseshop with your Launchpad OpenID? When > I try to do it I end up on a "Manual user registration" page. I fill out the > username with what I think my PyPI user name is, and add my python.org email > address, but then it tells me 'barry' is already taken. D

Re: [Python-Dev] Python and the Unicode Character Database

>> Then these users should speak up and indicate their need, or somebody >> should speak up and confirm that there are users who actually want >> '١٢٣٤.٥٦' to denote 1234.56. To my knowledge, there is no writing >> system in which '١٢٣٤.٥٦e4' means 12345600.0. > > I'm not sure what you're after he

Re: [Python-Dev] PEP 384 accepted

> Since discussion has trailed off without any blocking objections, I'm > accepting PEP 384. Martin, you may mark the PEP accepted and proceed > with merging the implementation for the beta on Saturday. Thanks! will do (I'll also take into consideration the proposed changes). Regards, Martin

Re: [Python-Dev] PEP 384 accepted

Am 02.12.2010 21:48, schrieb Tarek Ziadé: > On Thu, Dec 2, 2010 at 9:24 PM, "Martin v. Löwis" wrote: >>> Since discussion has trailed off without any blocking objections, I'm >>> accepting PEP 384. Martin, you may mark the PEP accepted and proceed >>>

Re: [Python-Dev] PEP 384 accepted

> So the question still stands: "Why not implementing this in Distutils2 ?" Because it then wouldn't be available in Python 3.2, which is the target release of the PEP. If that really causes too much pain, I'll refrain from making any changes to distutils; PEP 384 doesn't specify any changes, an

Re: [Python-Dev] Python and the Unicode Character Database

> Arabic numerals are being used a lot nowadays in Asian countries, > but that doesn't mean that the native script versions are not > being used anymore. I never claimed that people are not using their local scripts to enter numbers. However, none of your examples is about Chinese numerals using a

Re: [Python-Dev] PEP 384 accepted

> I was told not to touch to Distutils code to avoid any regression > since it's patched to the bones in third party products. So we decided > to freeze distutils and add all new features in Distutils2, which is > at alpha stage now. So this move seems contradictory to me. I think it was a bad de

Re: [Python-Dev] Python and the Unicode Character Database

Am 02.12.2010 22:30, schrieb Steven D'Aprano: > Martin v. Löwis wrote: >>>> Then these users should speak up and indicate their need, or somebody >>>> should speak up and confirm that there are users who actually want >>>> '١٢٣٤.٥٦' t

Re: [Python-Dev] PEP 384 accepted

>> This freeze made the situation worse. > > Can you extend on this and explains why it makes it worse ? Before the freeze, distutils was unmaintained (i.e. before you started maintaining it), but people who want to improve it gradually atleast could. Now gradual improvements are also banned, so

Re: [Python-Dev] PEP 384 accepted

Am 02.12.2010 22:54, schrieb Michael Foord: > On 02/12/2010 21:39, "Martin v. Löwis" wrote: >>> I was told not to touch to Distutils code to avoid any regression >>> since it's patched to the bones in third party products. So we decided >>> to

Re: [Python-Dev] PEP 384 accepted

>> The "distutils is unmaintained" situation. It's not only unmaintained >> now, but proposed improvements are rejected without consideration, on >> the grounds that they are changes. > > I welcome those changes in Distutils2. That's the whole point. That would be useful if there was a clear visi

Re: [Python-Dev] PEP 384 accepted

>> No, only the ones that didn't cause backwards incompatibilities, >> and broke existing packages. > > This is impossible. I can point you to some third party project that > can break if you touch some distutils internals, like setuptools. > Setuptools also uses some privates global variables in

Re: [Python-Dev] PEP 384 accepted

> I think distutils is simply a bugfix branch for distutils2. Similarly > as how we don't commit improvements in e.g. 2.7 or 3.1, neither do we > commit improvements to distutils. It's different, though, in the sense that Python has a release schedule and multiple committers working on it, and tha

Re: [Python-Dev] Python and the Unicode Character Database

Am 02.12.2010 23:43, schrieb M.-A. Lemburg: > Eric Smith wrote: >>> The current behavior should go nowhere; it is not useful. Something very >>> similar to the current behavior (but done correctly) should go into the >>> locale module. >> >> I agree with everything Martin says here. I think the bas

Re: [Python-Dev] Python and the Unicode Character Database

> The point is that we support all of Unicode in Python, not just a fragment, > and therefore the numeric constructors support all of Unicode. That conclusion is as false today as it was in Python 1.6, but only now people start caring about that. a) we don't support all of Unicode in numeric cons

Re: [Python-Dev] PEP 384 accepted

> From my point of view, the PEP 3149 text is just a proposal. It leaves the > final decision to PEP 384, but tries to address some of the issues raised > during the PEP 3149 discussion. I think it is within PEP 384's scope to make > the final decisions about it. Ok, then it looks like there jus

Re: [Python-Dev] PEP 384 accepted

> An alpha is already released. A beta will be released for Pycon (I > need it for my talk :) ) Then hopefully the final before 3.2 Ok, that's promising. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/

Re: [Python-Dev] PEP 384 accepted

> Python’s setup.py has an example in Martin’s branch: > > ext = Extension('xxlimited', ['xxlimited.c'], > define_macros=[('Py_LIMITED_API', 1)]) > > > > This is possible with today’s distutils. I don’t know if it’s enough t

Re: [Python-Dev] PEP 384 accepted

> I wonder what your definition of “unmaintained” is. In this specific case: doesn't get feature requests acted upon. I'm well aware that you are fixing bugs, and that is appreciated. > Sure, distutils is not as well-maintained as other modules, but a dozen > bugs have been fixed by five or six o

Re: [Python-Dev] Porting Ideas

> It would be nice if the UI told users that, and offered an opportunity > to log in. > > Better yet would be a option for an OpenID to claim a user name by > giving the password for it (ie, automatically on a successful login > from that page). So many projects, so little time. Contributions are

Re: [Python-Dev] xml issue in 2.5

Neal Norwitz wrote: > http://python.org/sf/1513611 > xml.sax.ParseException weirdness in python 2.5b1. The following code > doesn't work: > > from xml.sax import make_parser, SAXParseException > > parser = make_parser() > try: >parser.parse(StringIO('invalid')) > except SAXParseException: >

Re: [Python-Dev] Klocwork analysis of source if we want it

Brett Cannon wrote: > http://www.klocwork.com/company/releases/06_26_06.asp > > Looks like Klocowork is doing the same thing as Coverity and providing > free static analysis of source for open source projects. Doubt we want > this *and* Coverity, but figured wouldn't hurt to let people know about

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

Stefan Rank wrote: > I suggest to add (after 2.5 I assume) one of the following to the > beginning of urllib.quote to either fail early and consistently on > unicode arguments and improve the error message:: > >if isinstance(s, unicode): >raise TypeError("quote needs a byte string ar

Re: [Python-Dev] Minor: Unix icons for 2.5?

Georg Brandl wrote: > In case we add a Python .desktop file (as proposed in patch #1353344), > we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in > is attached. Independent of whether this should be done at all, I have a comment on the patch. Instead of invoking sed, I would use

Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt

Anthony Baxter wrote: >> The right thing to do is IRIs. > > For 2.5, should we at least detect that it's unicode and raise a > useful error? That can certainly be done, sure. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python

Re: [Python-Dev] User's complaints

[EMAIL PROTECTED] wrote: > The way I used to format dates using time.strftime does indeed no longer > work. > > Python 2.3: > > >>> import time > >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6) > '2005-06-04' Is there any specific reason you couldn't write "%d-%02d-%02d" % (200

Re: [Python-Dev] Community buildbots

Christopher Armstrong wrote: > python -U is a failure for obvious reasons and a > __future__ import is clearly better. I disagree. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsub

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

Christopher Armstrong wrote: > I'm at least willing to set up the buildbots for projects I care about > (Twisted, pydoctor, whatever), and perhaps help out with the setting > up the buildmaster. If you need trigger calls from subversion's post-commit hooks, please let me know, and I can set them u

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

Terry Reedy wrote: > That is the goal, but when I watched the buildbot results last spring, the > degree of stability (greenness) appeared to vary. Is it possible to tag > particular versions as a 'green' version, or the 'most recent green > version' worth playing with? Don't get confused by t

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

Jeroen Ruigrok van der Werven wrote: > This is what Xenofarm for Pike has done for a long time now. See for > example: http://pike.ida.liu.se/development/pikefarm/7.7.xml > > This is also what Bitten (http://bitten.cmlenz.net/) has implemented > for Trac (which is one of the bug/incident trackers

Re: [Python-Dev] Community buildbots

[EMAIL PROTECTED] wrote: >>> python -U is a failure for obvious reasons and a >>> __future__ import is clearly better. >> I disagree. > > I am surprised that you do, since I thought that Chris's conclusion was > pretty obvious. Python -U doesn't work, even on the standard library. Sure, it does

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

Jeroen Ruigrok van der Werven wrote: >> Are you aware of http://www.python.org/dev/buildbot/ ? > > Yes. And it does not seem to be open for all Ah, ok. It indeed isn't open for anonymous participation; the test results are open for all, though. > >> We are not just talking about buildbots here

Re: [Python-Dev] Community buildbots

[EMAIL PROTECTED] wrote: > A module with the given __future__ import could be written to expect that > literals are unicode instances instead of str, and encode them appropriately > when passing to modules that expect str. Such changes might have to be reverted in Python 3, since the module might

Re: [Python-Dev] I have submitted a patch that implement IrDA socket support .

Yingbo Qiu wrote: > Will anyone have interest in the patch? This patch comes to late for Python 2.5. It might be considered for 2.6, if anybody has time to review it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.o

Re: [Python-Dev] Pickling objects that return string from reduce

Bruce Christensen wrote: > Is something like the following close? Close, yes. > if type(result) == tuple: > ... (do appropriate things here) > elif isinstance(result, basestring): > name = result > module = "" > try: > module = obj.__module__ >

Re: [Python-Dev] new guy

matt westerburg wrote: > Hi my name is Matt Westerburg, I am a student and have only recently > gotten into Python. But have fallen in love with the language thus > far. Fantastic language and thank you very much for making it what it > is today. I am looking into getting into working on Python.

Re: [Python-Dev] logging module broken because of locale

Mihai Ibanescu wrote: > To follow up on my own email: it looks like, even though in some locale > "INFO".lower() != "info" > > u"INFO".lower() == "info" (at least in the Turkish locale). > > Is that guaranteed, at least for now (for the current versions of python)? It's guaranteed for now; unico

Re: [Python-Dev] logging module broken because of locale

James Y Knight wrote: > That seems backwards of how it should be ideally: the byte-string upper > and lower should always do ascii uppering-and-lowering, and the unicode > ones should do it according to locale. Perhaps that can be cleaned up in > py3k? Cleaned-up, yes. But it is currently not back

Re: [Python-Dev] logging module broken because of locale

M.-A. Lemburg wrote: > The Unicode database OTOH *defines* the upper/lower case mapping in > a locale independent way, so the mappings are guaranteed > to always produce the same results on all platforms. Actually, that isn't the full truth; see UAX#21, which is now official part of Unicode 4. It

Re: [Python-Dev] logging module broken because of locale

M.-A. Lemburg wrote: > Right. In fact, some case mappings are not available in the Unicode > database, since that only contains mappings which don't increase or > decrease the length of the Unicode string. A typical example is the > German u'ß'. u'ß'.upper() would have to give u'SS', but instead >

Re: [Python-Dev] Pickling objects that return string from reduce

Bruce Christensen wrote: >> If obj has no __module__ attribute (or if it is None), pickle >> (didn't check cPickle) also does >> >> for n, module in sys.module.items(): >> if "module-ignored": continue >> if getattr(module, result, None) is obj: >> break # use n as module name > > What i

Re: [Python-Dev] logging module broken because of locale

Mihai Ibanescu wrote: > It's up to Vinay to decide if we want to drop support for 1.5.2 in the module > included in newer pythons, or the attached patch would make it work for 1.5.2 > as well (as in "it's not more broken than before"). That still wouldn't work with Python 1.5.2, as that version d

Re: [Python-Dev] logging module broken because of locale

Mihai Ibanescu wrote: > Yes, as I said, it won't be more broken than before applying the patch (my > first patch was breaking 1.5.2 completely). Ah, I didn't notice that it deals with unicode() not being a builtin. That's fine then. Regards, Martin ___

Re: [Python-Dev] Document performance requirements?

Jason Orendorff wrote: > On 7/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> However, I'm also struggling to think of a case other than list vs deque >> where >> the choice of a builtin or standard library data structure would be dictated >> by big-O() concerns. > > OK, but that doesn't mean t

Re: [Python-Dev] Community buildbots -- reprise

Grig Gheorghiu wrote: > Please let me know if you're interested. As I said earlier: If you need some kind of post-commit trigger on the python repository to trigger a build, just let me know. We currently use a more-or-less plain svn_buildbot.py to trigger our own builds. Regards, Martin

Re: [Python-Dev] Community buildbots -- reprise

Grig Gheorghiu wrote: > As I said earlier: If you need some kind of post-commit > trigger on the python repository to trigger a build, just > let me know. We currently use a more-or-less plain > svn_buildbot.py to trigger our own builds. > > Wouldn't that put too much of a burden o

Re: [Python-Dev] Python 2.4, VS 2005 & Profile Guided Optmization

Joe Smith wrote: > Microsoft as a general rule, does not go after people distributing > products that Microsoft has labeled free, even after Microsoft no > longer distributes that product. So the express editions will > continue to be available long into the future if 2005+1 does not have > a free

Re: [Python-Dev] setup.py and cross-compiling

Ed Swierk wrote: > I decided to hack up setup.py so that an optional root directory (passed via > an > environment variable) is prepended to all the hardcoded paths like > "/usr/include", "/lib", "/lib64", and so on. I doubt this solves the problem. Distutils just doesn't support cross-compilatio

Re: [Python-Dev] setup.py and cross-compiling

Ed Swierk wrote: > Well, it seems buildroot solves this main problem by building another > version of python and pygen that run on the build machine, and hacks > the Makefile to run setup.py with these instead of whatever happens to > be sitting in /usr/bin. If you think its useful, please submit

Re: [Python-Dev] outstanding bugs to fix for 2.5

Neal Norwitz wrote: > http://python.org/sf/1513611 - XML: xml.sax.expatreader missing > > It would be great to fix *all* of these. In this list, at least 3 > (4?) can cause segfaults, and #1521947 can cause incorrect results. IMO, 1513611 should block the release, since it's a regression

Re: [Python-Dev] remaining issues from Klocwork static analysis

Neal Norwitz wrote: > # 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check Not quite sure what it is complaining about, but else if (PyTuple_Check(closure)) { Py_XINCREF(closure); } looks indeed suspicious: Why do we check for NULL (XINCREF) w

[Python-Dev] More tracker demos online

Currently, we have two running tracker demos online: Roundup: http://efod.se/python-tracker/ Jira: http://jira.python.atlassian.com/secure/Dashboard.jspa These installation are in various forms of demo mode and "pre-release" (meaning that the configuration is still not complete). They both use t

Re: [Python-Dev] remaining issues from Klocwork static analysis

Neal Norwitz wrote: >> Not quite sure what it is complaining about, but >> >> else if (PyTuple_Check(closure)) { >> Py_XINCREF(closure); >> } >> >> looks indeed suspicious: Why do we check for NULL (XINCREF) when >> we know closure can't be NULL (Tuple_Check). Drop t

Re: [Python-Dev] More tracker demos online

Neil Hodgson wrote: > Its disappointing that Jira and Launchpad use > different bug IDs as continuity should be maintained with the SF bug > IDs which will be referred to in other areas such as commit messages. My plan is to keep the SF redirector alive, so python.org/sf/ should continue to direct

Re: [Python-Dev] More tracker demos online

Terry Reedy wrote: > ""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Currently, we have two running tracker demos online: >> >> Roundup: >> http://efod.se/python-tracker/ >> >> Jira: >>

Re: [Python-Dev] remaining issues from Klocwork static analysis

Neal Norwitz wrote: > We never really did address this issue did? A while back we talked > about whether to assert vs check and do PyErr_BadInternalCall(). I > don't remember a clear resolution (though my memory). I vaguely > remember a preference towards asserting, but I don't know if that was

Re: [Python-Dev] [Windows, buildbot] kill_python.c mystery

Tim Peters wrote: > Today I noticed this happened when the buildbot started to run tests, > and I'm 100% sure it's due to this code in > Tools/buildbot/kill_python.c Didn't you know that you signed in to run arbitrary viruses, worms, and trojan horses when you added your machine to the buildbot i

Re: [Python-Dev] Which version of distutils to ship with Python 2.5?

Collin Winter wrote: > Is it intentional that Python 2.5 is (currently) shipping with > distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3) > shipped with distutils 2.4.1? Judging from my own tests, distutils > 2.4.1 fixed several bugs that some of my test suites depend on (the > fi

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

Phillip J. Eby wrote: > I'm willing to write code that makes it PEP 302 compliant, if the release > manager will bless such an addition. But if that's not acceptable, then > somebody needs to produce the necessary documentation updates or revert the > patch. It absolutely should not be allowed

Re: [Python-Dev] Py2.5 release schedule

Neal Norwitz wrote: > Anthony and I talked about still having b3 on Aug 1. rc1 around Aug > 17-18 (just before the Google sprint which Martin, Jeremy and I will > be attending). Final around 24-29. We didn't discuss with Martin > yet, so these dates are quite tentative. That doesn't work for me

Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix

Phillip J. Eby wrote: > The issue is that a proper fix that caches existence requires adding new > types to import.c and thus might appear to be more of a feature. I was > therefore reluctant to embark upon the work without some assurance that it > wouldn't be rejected as adding a last-minute f

Re: [Python-Dev] Bad interaction of __index__ and sequence repeat

Travis Oliphant wrote: > I say it's a bug that should be fixed. Don't clear the error, raise it. Several people have said this, but I don't think it can work. If you raise an OverflowError in __index__, the slicing code cannot know whether this meant as overflow or underflow (in a signed sense).

Re: [Python-Dev] Testing Socket Timeouts patch 1519025

Tony Nelson schrieb: > Hmm, OK, darn, thanks. MSWindows does allow users to press Ctl-C to send a > KeyboardInterrupt, so it's just too bad if I can't find a way to test it > from a script. You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling

Re: [Python-Dev] Which version of distutils to ship with Python 2.5?

Anthony Baxter schrieb: >> In any case, I bumped the version number to 2.5, according to the >> policy discussed in >> > > Could this not simply use the Python version number directly, instead? See the prior discussion at http://mail.python.org/pipermail/distutils-sig/2005-January/004366.html S

Re: [Python-Dev] Py2.5 release schedule

Fred L. Drake, Jr. schrieb: > On Sunday 30 July 2006 15:44, Barry Warsaw wrote: > > if isinstance(obj, ClassType) or isinstance(obj, type(type)) > > Looks like you've got a possible name clash in the second isinstance. ;-) Nah, that's rather an entry to the obfuscated Python contest. The two oc

Re: [Python-Dev] Testing Socket Timeouts patch 1519025

Tony Nelson schrieb: >> You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes >> that share the console of the calling process. [...] > Martin, your advice is usually spot-on, but I don't always understand it. > Maybe using it here is just complicated. This was really just in resp

Re: [Python-Dev] Testing Socket Timeouts patch 1519025

Tony Nelson schrieb: > Hmm. Well, it would make the test possible on MSWindows as well as on OS's > implementing alarm(2). If I figure out how to build Python on MSWindows, I > might give it a try. I tried to get MSVC 7.1 via the .Net SDK, but it > installed VS 8 instead, so I'm not quite sure h

Re: [Python-Dev] Patch submitted, now what?

Chad Whitacre schrieb: [I notice that my message comes across pretty negative. In a single sentence: We are all volunteers with limited time, and we contribute to Python because its fun and because it helps us solve our own problems.] > Last week I submitted a patch (my first), and now I'm wond

Re: [Python-Dev] segmentation fault in Python 2.5b3 (trunk:51066)

Ralf Schmitt schrieb: > I've been trying to port our software to python 2.5. > unfortunately I'm getting constantly hit by segfaults. I understand it's unfortunate for you, but it is fortunate for us that you have been trying to port your application before 2.5 was released, and reported the bug w

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

M.-A. Lemburg schrieb: >> There's no disputing that an exception should be raised >> if the string *must* be interpretable as characters in >> order to continue. But that's not true here if you allow >> for the interpretation that they're simply objects of >> different (duck) type and therefore une

Re: [Python-Dev] Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys

M.-A. Lemburg schrieb: > Python just doesn't know the encoding of the 8-bit string, so can't > make any assumptions on it. As result, it raises an exception to inform > the programmer. Oh, Python does make an assumption what the encoding is: it assumes it is the system encoding (i.e. "ascii"). The

Re: [Python-Dev] Python 2.5b3 and AIX 4.3 - It Works

Michael Kent schrieb: > Because of a requirement to remain compatible with AIX 4.3, I have been forced > to stay with Python 2.3, because while 2.4 would compile under AIX 4.3, it > would > segfault immediately when run. > > I'm happy to report that Python 2.5b3 compiles and runs fine under AIX 4

Re: [Python-Dev] windows 2.5 build: use OpenSSL for hashlib [bug 1535502]

Gregory P. Smith schrieb: > Whoever knows how the windows build process works and controls the > python 2.5 windows release builds could you please make sure the > hashlib module gets built + linked with OpenSSL rather than falling > back to its much slower builtin implementations. If the project

Re: [Python-Dev] 2.5 status

[EMAIL PROTECTED] schrieb: > The code (exception handler added to demonstrate and work around > the problem): > > try : > h = hash(p) > except OverflowError, e: > print type(p), p, id(p), e > h = id

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

David Hopwood schrieb: > I disagree. Unicode strings should always be considered distinct from > non-ASCII byte strings. Implicitly encoding or decoding in order to > perform a comparison is a bad idea; it is expensive and will often do > the wrong thing. That's a pretty irrelevant position at thi

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

David Hopwood schrieb: > Michael Foord wrote: >> David Hopwood wrote:[snip..] >> > we should, of course, continue to use the one we always used (for > "ascii", there is no difference between the two). +1 This seems the most (only ?) logical solution. >>> No; always considerin

Re: [Python-Dev] windows 2.5 build: use OpenSSL for hashlib [bug 1535502]

Gregory P. Smith schrieb: > hashlib's OpenSSL implementation on windows comes in the form of a > 300k _hashlib.pyd library. What do you mean by "comes"? I can't find any _hashlib.vcproj file inside the PCbuild directory. >> I believe that the performance of the OpenSSL routines depends on >> the

Re: [Python-Dev] windows 2.5 build: use OpenSSL for hashlib [bug 1535502]

Gregory P. Smith schrieb: > Sigh. Half the reason I did the hashlib work was to get much faster > optimized versions of the hash algorithms into python. I'll be > disappointed if that doesn't happen. Sad as it sounds, it appears you just did half of the work, then (omitting the Windows build pro

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

Armin Rigo schrieb: > I also seem to remember that TypeErrors should only signal ordering > non-sense, not equality. In this case, I'm on the opinion that unicode > objects and completely-unrelated strings of random bytes should > successfully compare as unequal, but I'm not enough of a unicode us

Re: [Python-Dev] windows 2.5 build: use OpenSSL for hashlib [bug 1535502]

Gregory P. Smith schrieb: > So is it worth my time doing this in a hurry for 2.5 or do other > people really just not care if python for windows uses a slow OpenSSL? As I said: I would accept patches. If you arrange for a separate _hashlib.pyd file, most of my concerns would go away. So please do

Re: [Python-Dev] Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys

M.-A. Lemburg schrieb: > Hiding programmer errors is not making life easier in the > long run, so I'm -1 on having the equality comparison return > False. There is no error to hide here. The objects are inequal, period. > Instead we should generate a warning in Python 2.5 and introduce > the exce

Re: [Python-Dev] Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys

M.-A. Lemburg schrieb: > If the programmer writes: > > x = 'äöü' > y = u'äöü' > ... > if x == y: > do_something() > > then he clearly has had the intention to compare two character > strings. Programmers make all kinds of mistakes when comparing objects, assuming that things ought to be equa

Re: [Python-Dev] returning longs from __hash__()

Armin Rigo schrieb: > Maybe the user should just be able to return any integer value from a > custom __hash__() without having to worry about not exceeding > sys.maxint. > > After all the returned value has no real meaning. If a long is returned > we could take its hash again, and use that number

Re: [Python-Dev] openSSL and windows binaries - license

Jim Jewett schrieb: > The OpenSSL library implements some algorithms that are patented. The > source code should be fine to (re)distribute, but but there may be a > slight legal risk with distributing a binary. I don't want to change the build process in that way (i.e. dropping a feature) just be

Re: [Python-Dev] Releasemanager, please approve #1532975

Thomas Heller schrieb: > Thomas Heller schrieb: >> Approval requested for patch: >> http://python.org/sf/1532975 >> > > What does the silence mean? Should I go ahead and commit this patch? If it's not there already, you should add it to the PEP. If you think it is "release-critical" (i.e. it wou

Re: [Python-Dev] returning longs from __hash__()

Tim Peters schrieb: > It sounds fine to me, except I'm not immediately clear on which code > needs to be changed. My change would essentially be the code below, in instance_hash and slot_tp_hash; I have yet to add test cases and check for documentation changes. Regards, Martin Index: Objects/typ

Re: [Python-Dev] openSSL and windows binaries - license

Greg Ewing schrieb: > If distributing the source doesn't violate the patent, > and distributing a binary doesn't violate the patent, > then what *would* constitute a violation of a software > patent? IANAL, but AFAICT, the rights controlled by patent law are the right to make, to use, to sell, to

Re: [Python-Dev] openSSL and windows binaries - license

Gregory P. Smith schrieb: > disabling/enabling a cipher in openssl that isn't commonly used and > isn't even directly exposed via any API to a python user hardly sounds > like dropping a feature to me. Strictly speaking, it is dropping a feature: a connection that can get established with 2.5b3 mi

Re: [Python-Dev] openSSL and windows binaries - license

Greg Ewing schrieb: >> In the context of an encryption algorithm, the right to >> use would be the most prominent one; you wouldn't be >> allowed to use the algorithm unless you have a patent >> license. > > But what does "use" *mean* in relation to an > algorithm? Perform it: do the steps that t

Re: [Python-Dev] SyntaxError: can't assign to function call

Neal Becker schrieb: > 1) Should assignment to a temporary object be allowed? Unlike Michael, I think the question does make sense, and the answer is "no", for the reason Michael gave: you assign to names, not to objects. > 2) Should the syntax for creation of a temporary object be a constructor

Re: [Python-Dev] Unicode Data in Python2.5 is missing a ucd_4_1_0 object

Armin Ronacher schrieb: > I discovered that unicodedata in python2.5 implements unicode 4.1. While > this is ok it's possible enforce unicode 3.2 by using the ucd_3_2_0 object. > But it's not possible to enforce a ucd_4_1_0 standard because that object > does not exist by now. Not sure what you me

Re: [Python-Dev] SimpleXMLWriter missing from elementtree

Ralf Schmitt schrieb: > any chance to get SimpleXMLWriter (and other modules maybe??) getting > included into xml.etree? Not in Python 2.5, no. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/p

Re: [Python-Dev] Dict suppressing exceptions

Guido van Rossum schrieb: > Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to > issue a warning (and return False) instead of raising > UnicodeException? I'm in favour of having this __eq__ just return False. I don't think the warning is necessary, and believe that people will

Re: [Python-Dev] returning longs from __hash__()

Armin Rigo schrieb: > This bug will keep showing up forever :-) It's unsafe against a user > subclassing 'long' and overriding __hash__ of that subclass to return > the object itself -- it would cause an infinite C recursion. I see you've fixed it - thanks. Martin ___

Re: [Python-Dev] openSSL and windows binaries - license

Greg Ewing schrieb: > That can't be right, because it would mean that > anyone who runs a program that contains a > patented algorithm, even one bought or otherwise > obtained from someone else, would need to > individually negotiate a licence with the > patent owner. That clearly doesn't happen.

Re: [Python-Dev] Dict suppressing exceptions

Guido van Rossum schrieb: > Me too, and that's what we'll do in py3k. But in 2.5, we're bound by > the decisions we made in 1999-2000 about unicode. (Unless Martin has a > convincing reason not to have a warning?) Only the general anti-warning argument: it's not the developer which will see the wa

Re: [Python-Dev] Dict suppressing exceptions

Michael Chermside schrieb: > I don't *strongly* object to this consensus, but if you haven't > glanced at my original example, take a look - it might convince you. > The proposed solution will not help with my example. I ignored your example the first time because it was too complicated to underst

Re: [Python-Dev] Elementtree and Namespaces in 2.5

Chris S schrieb: > I'm happy to see Elementtree being considered for inclusion with 2.5. > However, before committing to this decision, there's an issue > regarding it's namespace parsing that should be addressed. Although > Elmenttree is in most respects an excellent XML parser, a huge gotcha > th

Re: [Python-Dev] SyntaxError: can't assign to function call

Michael Urman schrieb: > On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote: >> The question doesn't make sense: in Python, you assign to a name, >> an attribute or a subscript, and that's it. > > Just to play devil's advocate here, why not to a function call via a > new __setcall__? Just try s

<    11   12   13   14   15   16   17   18   19   20   >