Re: [Python-Dev] Remove "unit test needed"

On Thu, Aug 12, 2010 at 9:18 AM, Mark Dickinson wrote: > On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou wrote: .. >> I would like to see “unit test needed” removed from the workflow menu in >> the bug tracker. .. > Is that stage supposed to (at least partly) capture the idea > 'reproducible tes

Re: [Python-Dev] Remove "unit test needed"

On Thu, Aug 12, 2010 at 1:31 PM, Fred Drake wrote: > On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky > wrote: >> I remember there was an idea somewhere to replace "patch" tag with a >> check-list with boxes for code, tests, and docs.  I think that would >>

Re: [Python-Dev] hg conversion: tags

On Mon, Sep 27, 2010 at 11:28 AM, Barry Warsaw wrote: .. > If so, then I say in hg, nuke the tags we don't care about and sanitize the > release tags to something that obvious and can't collide (e.g. r311 is 3.1.1 > or 3.11? - yes despite Guido's Rule of Version Numbering).  I'd personally be > fi

Re: [Python-Dev] We should be using a tool for code reviews

On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote: .. > But maybe with Hg it's less of a burden to ask people to use a checkout. > I thought with Hg it would be more of a burden for casual contributors to use a checkout simply because the checkout is many times bigger. _

Re: [Python-Dev] We should be using a tool for code reviews

On Wed, Sep 29, 2010 at 4:56 PM, Brett Cannon wrote: > On Wed, Sep 29, 2010 at 13:31, Alexander Belopolsky > wrote: >> On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum wrote: >> .. >>> But maybe with Hg it's less of a burden to ask people to use a checkout. >

Re: [Python-Dev] Rietveld integration into Roundup

I followed the review link from issue5109 to arrive at http://bugs.python.org/review/5109/patch/179/325 . On the review page I clicked on Modules/arraymodule.c > View for side-by-side diff and got Error fetching None/Modules/arraymodule.c?rev=83179: InvalidURLError: Protocol '%s' is not supported

Re: [Python-Dev] Rietveld integration into Roundup

On Tue, Oct 5, 2010 at 3:25 PM, "Martin v. Löwis" wrote: .. >> >> Error fetching None/Modules/arraymodule.c?rev=83179: InvalidURLError: >> Protocol '%s' is not supported. > > That currently happens for a lot of patches. It can't figure out what > the base branch is, and goes to the Rietveld Issue

Re: [Python-Dev] Add aware local time support to datetime module

It looks like this response has slipped under my radar. Sorry. On Sun, Aug 8, 2010 at 4:37 AM, Lennart Regebro wrote: [skipped description of two alternative solutions] .. > For all of the reasons you give above, I think it's a bad idea. :-) > I did not give any reason for not having access to t

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger wrote: .. > Packaging is not always wrong.  Maybe it was the right thing to do for > unittest, maybe not. This is an example that I personally find ill-justified. Particularly annoying is the fact that opening __init__.py gives you a list of rel

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Tue, Oct 26, 2010 at 5:37 PM, Fred Drake wrote: > On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord > wrote: >> I find the big-ball-of-mud style development, where everything lives inside >> huge monolithic modules, very painful. I also think that it is an extremely >> bad example for new develop

Re: [Python-Dev] Continuing 2.x

On Thu, Oct 28, 2010 at 12:07 PM, wrote: .. > Has anyone here analyzed download stats on py.org lately? > Please feel free to prove me wrong, but by my reckoning, > and at least for Windows MSI installer files, people are > still downloading Python 2.X roughly 3 to 4 times more often > than Pytho

[Python-Dev] A sad state of doctests in the python manual

I have just discovered that sphinx supports running doctests embedded in ReST documentation. It looks like it is as simple as "cd Doc; make doctest". The result, however is not encouraging: $ make doctest ... Doctest summary === 1162 tests 262 failures in tests 0 failures in

Re: [Python-Dev] A sad state of doctests in the python manual

On the second look, the problem may not be that bad - "make doctest" picks up system python instead of the one from the source tree. I'll try to figure out how to rerun the doctests properly. On Thu, Oct 28, 2010 at 4:48 PM, Alexander Belopolsky wrote: > I have just disc

Re: [Python-Dev] A sad state of doctests in the python manual

On Thu, Oct 28, 2010 at 4:52 PM, Alexander Belopolsky wrote: > On the second look, the problem may not be that bad ... Nope, the problem is even worse. It looks like Sphinx in py3k requires 2.x python: $ ../python.exe tools/sphinx-build.py -b doctest -d build/doctrees -D latex_paper_s

Re: [Python-Dev] A sad state of doctests in the python manual

On Thu, Oct 28, 2010 at 5:18 PM, Barry Warsaw wrote: .. > > It would be really cool if you fixed this! > Working on it. Stay tuned. :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: h

Re: [Python-Dev] A sad state of doctests in the python manual

On Thu, Oct 28, 2010 at 5:30 PM, Alexander Belopolsky wrote: > On Thu, Oct 28, 2010 at 5:18 PM, Barry Warsaw wrote: > .. >> >> It would be really cool if you fixed this! >> > Working on it.  Stay tuned. :-) > See htt

Re: [Python-Dev] [Python-checkins] r86066 - python/branches/py3k/Doc/library/functions.rst

On Sun, Oct 31, 2010 at 5:23 PM, raymond.hettinger wrote: .. > +   For some use cases, there a good alternatives to :func:`sum`. This sentence is missing a verb. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/p

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Tue, Nov 2, 2010 at 6:58 PM, Guido van Rossum wrote: .. > To spout a somewhat contrarian opinion, I just browsed the new > unittest package, and the structure seems reasonable to me, even if > its submodules are not particularly reusable. I've used this kind of > style for development myself. W

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Wed, Nov 3, 2010 at 4:59 PM, Glyph Lefkowitz wrote: .. >  Maybe ship with a command that says "hey, somewhere on sys.path, > there is a class with .  Please run '$EDITOR file +line' (or the > current OS's equivalent) so I can look at the source code". > Well, we already have inspect.findsource

Re: [Python-Dev] Pickle alternative in stdlib (Was: On breaking modules into packages)

On Thu, Nov 4, 2010 at 10:51 AM, Guido van Rossum wrote: .. >>> Twisted actually tried to preserve pickle compatibility in the bad old days, >>> but it was impossible.  Pickles should never really be saved to disk unless >>> they contain nothing but lists, ints, strings, and dicts. > > But *that*

[Python-Dev] Breaking undocumented API

Was: [issue2001] Pydoc interactive browsing enhancement On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan wrote: .. > > I'd actually started typing out the command to commit this before it finally > clicked that the patch changes public > APIs of the pydoc module in incompatible ways. Sure, they aren

Re: [Python-Dev] Breaking undocumented API

On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord wrote: .. > If you deprecate it then you don't *have* to fix bugs in it. If we know it > is used then we can't remove it without deprecation. > What about the maintenance branch? ___ Python-Dev mailing list

Re: [Python-Dev] Breaking undocumented API

On Mon, Nov 8, 2010 at 1:39 PM, Michael Foord wrote: .. > So you have a bug in the module that can only be fixed in a function you > want to deprecate? > No, I have a bug in a function that I want to deprecate. You said I don't need to fix it if I add a deprecation warning. However, as far as I

Re: [Python-Dev] GUI test runner tool

On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord wrote: .. > I'd like to propose adding [unittestgui] to Python in Tools/ and am > volunteering to > maintain it. Why not adding it under Lib/unittest/? I think Tools/ is a less attractive location for most users than say PyPI or some other package

Re: [Python-Dev] Breaking undocumented API

On Mon, Nov 8, 2010 at 2:58 PM, Brett Cannon wrote: .. > But that doesn't mean we can't go through, fix up our names, and > deprecate the old public names; that's fair game in my book. > +1 See http://bugs.python.org/issue10371 ___ Python-Dev mailing l

Re: [Python-Dev] [Python-checkins] r86355 - python/branches/py3k/Modules/_pickle.c

On Tue, Nov 9, 2010 at 4:39 AM, victor.stinner wrote: .. > Log: > Issue #10359: Remove useless comma, invalid in ISO C C99 allows it. Which compiler is giving you trouble? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman

Re: [Python-Dev] r86355 - python/branches/py3k/Modules/_pickle.c

On Tue, Nov 9, 2010 at 11:36 AM, Antoine Pitrou wrote: .. >> C99 allows it.  Which compiler is giving you trouble? > > One part of the answer is that we generally try to enforce C89 > compatibility. I don't know if any modern compiler would mind, though. I know, but if we ever start making except

Re: [Python-Dev] [Python-checkins] r86355 - python/branches/py3k/Modules/_pickle.c

On Wed, Nov 10, 2010 at 7:28 AM, Victor Stinner wrote: .. > I don't know, but the commit is trivial and cheap. If it improves the support > on uncommon compiler, I agree to commit such change. > But it does it at the cost of invalidating the "svn blame" for the last enum entry now and for future

Re: [Python-Dev] [Python-checkins] r86355 - python/branches/py3k/Modules/_pickle.c

On Wed, Nov 10, 2010 at 10:04 PM, Stephen J. Turnbull wrote: > ...  On the original question, I > think it's preferable to keep compilers happy unless you're willing to > *require* C99. Hmm, maybe I should take another look at http://bugs.python.org/issue4805 . Note that issue #10359 was not abo

Re: [Python-Dev] Breaking undocumented API

On Wed, Nov 10, 2010 at 6:10 PM, Ron Adam wrote: .. >> On Nov 10, 2010, at 5:47 AM, Michael Foord wrote: >>> >>> So it is obvious that we don't have a clearly stated policy for what >>> defines the public API of standard library modules. >>> >>> How about making this explicit (either pep 8 or our

Re: [Python-Dev] Breaking undocumented API

On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord wrote: .. >> Is it OK to add __all__ to such modules that does not include all >> names not starting with an underscore?  Is it OK to then remove names >> that clearly were not intended to be public? > > Given the rules I suggested, which are basicall

Re: [Python-Dev] Breaking undocumented API

On Thu, Nov 11, 2010 at 8:43 AM, Fred Drake wrote: .. > Since trace is documented and rx_blank isn't covered, I think it's > pretty clear it was never intended as API.  I'd be fine with changing > the visibility of rx_blank, and see no need to change its name. While I obviously agree with your co

Re: [Python-Dev] Breaking undocumented API

2010/11/11 Michael Foord : .. >> You mean runtime automation, e.g. creating __all__ on the fly omitting >> underscored names? >> > Writing code to generate a __all__ that duplicates the default behaviour > seems redundant to me. > FWIW, I like having __all__ at the top of the module. It feels lik

Re: [Python-Dev] Breaking undocumented API

On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord wrote: .. >> I don't understand why everyone seem to have accepted Michael's >> premise that "we don't have a clearly stated policy for what defines >> the public API of standard library modules."  We do have such a policy >> and it is well known (whi

Re: [Python-Dev] Breaking undocumented API

Py_UNICODE_strncpy Py_UNICODE_strcmp Py_UNICODE_strncmp Py_UNICODE_strchr Py_UNICODE_strrchr On Sat, Nov 13, 2010 at 7:12 AM, Giampaolo Rodolà wrote: > +1 on everything. > > 2010/11/11 Alexander Belopolsky : >> 2010/11/11 Michael Foord : >> .. >>>> You mean runtime automation,

Re: [Python-Dev] Breaking undocumented API

On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote: .. > One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat > obscure and given that we already have PyUnicode_Concat(), I think > it should be made private and eventually dropped. > What about PyUnicode_GetMax()? Isn't that s

Re: [Python-Dev] Breaking undocumented API

On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote: .. > Now, we can't use a macro for [PyUnicode_GetMax()], since the information has > to be available as callable in order to applications or extensions > to use it (without recompile). > .. but it *is* a macro resolving to either PyUnicodeUCS2

Re: [Python-Dev] Breaking undocumented API

On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote: .. > BTW: I'm not really happy about the Py_UNICODE_ prefix for functions > in unicodeobject.h, but I guess it's too late to change those. > It would be better to stick to one prefix for Unicode related > APIs, i.e. "PyUnicode_". I don't have

Re: [Python-Dev] Breaking undocumented API

On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote: .. >> Note that we can have both a macro and a function >> version.  This is fairly standard practice in Python C-API. > > Sure, but what for ? > Mostly just for consistency with the other macros: http://docs.python.org/dev/py3k/c-api/unicode

[Python-Dev] PyUnicode_GetMax() and PyUnicode_FromOrdinal() Was: Breaking undocumented API

On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote: > Alexander Belopolsky wrote: >> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote: >> .. >>> Now, we can't use a macro for [PyUnicode_GetMax()], since the information >>> has >>> to be av

Re: [Python-Dev] PyUnicode_GetMax() and PyUnicode_FromOrdinal() Was: Breaking undocumented API

On Tue, Nov 16, 2010 at 3:06 PM, M.-A. Lemburg wrote: .. > len(chr(0x10)) >> 2 >> >> (on a USC2 build.) > > Yes, it's a documentation bug. I guess someone forgot to update > the comment in unicodeobject.h after the change to have chr()/unichr() > return a 2-char string instead of a 1-char

Re: [Python-Dev] Breaking undocumented API

On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney wrote: .. > I don't know about Guido, but I'd be -1 on suggestions to add more > normative information to PEP 7, PEP 8, PEP 257, or any other established > style guide PEP. I certainly don't want to have to keep going back to > the same documents frequen

Re: [Python-Dev] Breaking undocumented API

I created http://bugs.python.org/issue10435 to follow up on unicode C API issues. On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote: > Alexander Belopolsky wrote: >> What this thread has shown is that there is no consensus on what >> public names are and what rules should b

Re: [Python-Dev] Breaking undocumented API

On Wed, Nov 17, 2010 at 9:19 AM, Nick Coghlan wrote: .. > The standard library documentation should say that the public API is > what the documentation says it is. Officially, anyone going outside > those documented APIs should not be surprised if things get removed or > changed arbitrarily withou

Re: [Python-Dev] Breaking undocumented API

On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote: .. > The library documentation is *not* the right place for quibbling about > what constitutes a public API when using other means than the library > documentation to find APIs to call. > +1 People who bother to read the Library Reference most

[Python-Dev] len(chr(i)) = 2?

I was recently surprised to learn that chr(i) can produce a string of length 2 in python 3.x. I suspect that I am not alone finding this behavior non-obvious given that a mistake in Python manual stating the contrary survived several releases. [1] Note that I am not arguing that the change was

Re: [Python-Dev] len(chr(i)) = 2?

On Sat, Nov 20, 2010 at 4:05 AM, "Martin v. Löwis" wrote: .. > A technical correct description would be to say that Python uses either > 16-bit code units or 32-bit code units; for brevity, these can be called > narrow and wide code units. +1 PEP 261 introduced terms "wide Py_UNICODE" and "narro

Re: [Python-Dev] len(chr(i)) = 2?

On Fri, Nov 19, 2010 at 4:43 PM, "Martin v. Löwis" wrote: >> In my opinion, the question is more what was it not fixed in Python2. I >> suppose >> that the answer is something ugly like "backward compatibility" or >> "historical >> reasons" :-) > > No, there was a deliberate decision to not supp

Re: [Python-Dev] len(chr(i)) = 2?

On Mon, Nov 22, 2010 at 10:37 AM, Nick Coghlan wrote: .. > *(The first Google hit for "ucs2" is the UTF-16/UCS-2 article on > Wikipedia, the first hit for "ucs4" is the UTF-32/UCS-4 article) > Do you think these articles are helpful for someone learning how to use chr() and ord() in Python for th

Re: [Python-Dev] len(chr(i)) = 2?

On Mon, Nov 22, 2010 at 11:13 AM, Nick Coghlan wrote: .. >> Do you think these articles are helpful for someone learning how to >> use chr() and ord() in Python for the first time? > > No, that's what the documentation of chr() and ord() is for. For that > use case, it doesn't matter *what* the te

Re: [Python-Dev] len(chr(i)) = 2?

On Mon, Nov 22, 2010 at 12:30 PM, R. David Murray wrote: .. > For reference, a grep in py3k/Doc reveals that there are currently exactly > 23 lines mentioning UCS2 or UCS4 in the docs. Did you grep for USC-2 and USC-4 as well? I have to admit that my aversion to these terms is mostly due to the

Re: [Python-Dev] len(chr(i)) = 2?

On Mon, Nov 22, 2010 at 12:41 PM, Terry Reedy wrote: .. > What Python does might be called USC-2+ or UCS-2e (xtended). > Wow! I am not the only one who can't get the order of letters right in these acronyms. (I am usually consistent within one sentence, though.) :-) I-can't-spell-three-letter-

Re: [Python-Dev] len(chr(i)) = 2?

On Mon, Nov 22, 2010 at 1:13 PM, Raymond Hettinger wrote: .. > Any explanation we give users needs to let them know two things: > * that we cover the entire range of unicode not just BMP > * that sometimes len(chr(i)) is one and sometimes two This discussion motivated me to start looking into how

Re: [Python-Dev] len(chr(i)) = 2?

On Tue, Nov 23, 2010 at 2:18 PM, Amaury Forgeot d'Arc wrote: .. >> Given the apparent difficulty of writing even basic text processing >> algorithms in presence of surrogate pairs, I wonder how wise it is to >> expose Python users to them. > > This was already discussed two years ago: > > http://m

Re: [Python-Dev] len(chr(i)) = 2?

On Wed, Nov 24, 2010 at 1:50 PM, M.-A. Lemburg wrote: .. >> add an option for decoders that currently produce surrogate pairs to >> treat non-BMP characters as errors and handle them according to user's >> choice. > > But what do you gain by doing this ? You'd lose the round-trip > safety of those

Re: [Python-Dev] len(chr(i)) = 2?

On Wed, Nov 24, 2010 at 9:17 PM, Stephen J. Turnbull wrote: .. >  > I note that an opinion has been raised on this thread that >  > if we want compressed internal representation for strings, we should >  > use UTF-8.  I tend to agree, but UTF-8 has been repeatedly rejected as >  > too hard to impl

[Python-Dev] Python and the Unicode Character Database

Two recently reported issues brought into light the fact that Python language definition is closely tied to character properties maintained by the Unicode Consortium. [1,2] For example, when Python switches to Unicode 6.0.0 (planned for the upcoming 3.2 release), we will gain two additional charac

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

On Sun, Nov 28, 2010 at 3:43 PM, Antoine Pitrou wrote: .. >> For example, >> I don't think that supporting >> >> >>> float('١٢٣٤.٥٦') >> 1234.56 >> >> is more important than to assure users that once their program >> accepted some text as a number, they can assume that the text is >> ASCII. > > Wh

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

On Sun, Nov 28, 2010 at 4:12 PM, Joao S. O. Bueno wrote: .. > Let novice C programmers in English speaking countries deal with the > fact that 1 character is not 1 byte anymore. We are past this point. If you are, please contribute your expertise here: http://bugs.python.org/issue2382 __

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

On Sun, Nov 28, 2010 at 5:17 PM, "Martin v. Löwis" wrote: >> float('١٢٣٤.٥٦') >>> 1234.56 > > I think it's a bug that this works. The definition of the float builtin says > > Convert a string or a number to floating point. If the argument is a > string, it must contain a possibly signed decima

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

On Sun, Nov 28, 2010 at 5:42 PM, M.-A. Lemburg wrote: .. > I don't see why the language spec should limit the wealth of number > formats supported by float(). > The Language Spec (whatever it is) should not, but hopefully the Library Reference should. If you follow http://docs.python.org/dev/py3

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

On Sun, Nov 28, 2010 at 5:56 PM, "Martin v. Löwis" wrote: .. >> This definition fails long before we get beyond 127-th code point: >> > float('infinity') >> inf > > What do infer from that? That the definition is wrong, or the code is wrong? The development version of the reference manual is

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

+1 on all point below. On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" wrote: >>> Now, one may wonder what precisely a "possibly signed floating point >>> number" is, but most likely, this refers to >>> >>> floatnumber   ::=  pointfloat | exponentfloat >>> pointfloat    ::=  [intpart] fraction

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

On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" wrote: .. >> Note that the support in float() (and the other numeric constructors) >> to work with Unicode code points was explicitly added when Unicode >> support was added to Python and has been available since Python 1.6. > > That doesn't neces

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

On Sun, Nov 28, 2010 at 6:08 PM, "Martin v. Löwis" wrote: > Am 29.11.2010 00:01, schrieb Alexander Belopolsky: >> On Sun, Nov 28, 2010 at 5:56 PM, "Martin v. Löwis" >> wrote: >> .. >>>> This definition fails long before we get beyond 127-t

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

On Sun, Nov 28, 2010 at 6:19 PM, "Martin v. Löwis" wrote: .. > You can see the Unicode Consortium's stability policy at > > http://unicode.org/policies/stability_policy.html > >From the link above: """ As more experience is gathered in implementing the characters, adjustments in the properties ma

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

On Sun, Nov 28, 2010 at 6:03 PM, "Martin v. Löwis" wrote: .. > No no no. Addition of Unicode identifiers has a well-designed, > deliberate specification, with a PEP and all. The support for > non-ASCII digits in float appears to be ad-hoc, and not founded > on actual needs of actual users. > I wo

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

On Sun, Nov 28, 2010 at 6:59 PM, "Martin v. Löwis" wrote: .. > The next question then is if it supports indo-arabic digits in any > locale (or more specifically in an arabic locale). And once you answered that question, does it support Devanagari or Bengali digits? And if so, an arbitrary mix of

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

On Sun, Nov 28, 2010 at 7:01 PM, Antoine Pitrou wrote: .. >> That's different. Python doesn't assign any semantic meaning to the >> characters in identifiers. The non-latin support for numerals, though, >> could change the meaning of a program dramatically and needs to be >> well-specified. Whethe

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

On Sun, Nov 28, 2010 at 7:55 PM, Ben Finney wrote: .. >> Of course it is fun that Python can process Bengali numerals, but so >> would be allowing Roman numerals. There is a reason why after careful >> consideration, PEP 313 was ultimately rejected. > > Rejecting a proposed *new* capability is a d

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

On Sun, Nov 28, 2010 at 6:43 PM, Steven D'Aprano wrote: .. >> is more important than to assure users that once their program >> accepted some text as a number, they can assume that the text is >> ASCII. > > Seems like a pretty foolish assumption, if you ask me, pretty much akin to > assuming that

Re: [Python-Dev] [Preview] Comments and change proposals on documentation

On Mon, Nov 29, 2010 at 3:52 AM, Georg Brandl wrote: .. >> Yes, I failed to fully read the instructions you sent, or understand >> them. That's what users do -- they don't read your instructions, and >> they misunderstand them. If your UI isn't easily discoverable, users >> will not be able to use

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

On Mon, Nov 29, 2010 at 2:22 AM, "Martin v. Löwis" wrote: >> The former ensures that literals in code are always readable; the later >> allows users to enter numbers in their own number system. How could that >> be a bad thing? > > It's YAGNI, feature bloat. It gives the illusion of supporting som

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

On Mon, Nov 29, 2010 at 1:33 PM, Antoine Pitrou wrote: > On Mon, 29 Nov 2010 08:22:46 +0100 > "Martin v. Löwis" wrote: >> > The former ensures that literals in code are always readable; the later >> > allows users to enter numbers in their own number system. How could that >> > be a bad thing? >>

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

On Mon, Nov 29, 2010 at 2:23 PM, Terry Reedy wrote: .. > Since you are the knowledgable advocate of the current behavior, perhaps you > could open an issue and propose a doc patch, even if not .rst formatted. > I am not an advocate of the current behavior, but an issue for doc patches is at

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

On Mon, Nov 29, 2010 at 5:09 PM, Steven D'Aprano wrote: .. > But in any case, please don't conflate the question of whether Python should > accept j and/or i for complex numbers with the question of supporting > non-arabic numerals. The two issues are unrelated. The two issues are related because

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

On Tue, Nov 30, 2010 at 7:59 AM, Steven D'Aprano wrote: .. > But you should be able to write: > > text = input("Enter a number using your preferred digits: ") > num = float(text) > > without caring whether the user enters 一.一 or 1.1 or something else. > I find it ironic that people who argue for

Re: [Python-Dev] Module size

On Tue, Nov 30, 2010 at 8:38 AM, Antoine Pitrou wrote: > On Mon, 29 Nov 2010 22:46:33 -0500 > Alexander Belopolsky wrote: >> >> In practical terms, UCD comes at a price.  The unicodedata module size >> is over 700K on my machine.  This is almost half the size of the >

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

On Mon, Nov 29, 2010 at 4:13 PM, "Martin v. Löwis" wrote: >> - Should Python documentation refer to the specific version of Unicode >> that it supports? > > You mean, mention it somewhere? Sure (although it would be nice if the > documentation generator would automatically extract it from the sour

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

On Tue, Nov 30, 2010 at 9:56 AM, haiyang kang wrote: >> But you should be able to write: >> >> text = input("Enter a number using your preferred digits: ") >> num = float(text) >> >> without caring whether the user enters 一.一 or 1.1 or something else. > > yes. from logical point of view, this can

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

On Mon, Nov 29, 2010 at 2:38 PM, Alexander Belopolsky wrote: .. >> Still, if it's not detrimental and it it's not difficult to support, >> then why do you care? > > It is difficult to support.  A fix for issue10557 would be much > simpler if we did not support non-

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

On Tue, Nov 30, 2010 at 12:40 PM, Michael Foord wrote: .. >> If you think non-ASCII digits are not difficult to support, please >> contribute to the following tracker issues: >> > > Would moving this functionality to the locale module make the issues any > easier to fix? > Sure, if we code it in

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

On Tue, Nov 30, 2010 at 1:29 PM, Antoine Pitrou wrote: .. >> I am not sure this belongs to the locale module, however.  It seems to >> me, something like 'unicodealgo' for unicode algorithms would be more >> appropriate. > > It could simply be in unicodedata if you split the implementation into a

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

On Sun, Nov 28, 2010 at 5:48 PM, M.-A. Lemburg wrote: .. >> With Python 3.1: >> > exec('\u0CF1 = 1') >> Traceback (most recent call last): >>  File "", line 1, in >>  File "", line 1 >>    ೱ = 1 >>      ^ >> SyntaxError: invalid character in identifier >> >> but with Python 3.2a4: >> > ex

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

On Wed, Dec 1, 2010 at 5:36 PM, "Martin v. Löwis" wrote: .. >> Note that I'm not saying this is common. Nor am I saying it's a >> desirable situation. I'm saying it is a feasible use case, to be >> dismissed only if there is strong evidence that it's not used by >> existing Python code. > > And in

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

On Wed, Dec 1, 2010 at 7:17 PM, Steven D'Aprano wrote: .. > we should continue to support the existing behaviour. None of the arguments > against it seem convincing to me, particularly since the opponents of the > current behaviour admit that there is a use-case for it, but they just want > it to

Re: [Python-Dev] Porting Ideas

On Wed, Dec 1, 2010 at 9:53 PM, Terry Reedy wrote: .. > Does Sphinx run on PY3 yet? It does, but see issue10224 for details. http://bugs.python.org/issue10224 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/py

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

On Wed, Dec 1, 2010 at 10:11 PM, Terry Reedy wrote: > On 12/1/2010 7:44 PM, Alexander Belopolsky wrote: > >> it.  The argument was that if there was a use case for parsing Eastern >> Arabic numerals, it would be better served by a module written by >> someone who

Re: [Python-Dev] ICU

On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou wrote: > > Oh, about ICU: > >> > Actually, I remember you saying that locale should ideally be replaced >> > with a wrapper around the ICU library. >> >> By that, I stand - however, I have given up the hope that this will >> happen anytime soon. > >

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

On Thu, Dec 2, 2010 at 8:36 AM, Antoine Pitrou wrote: > On Wed, 1 Dec 2010 22:28:49 -0500 > Alexander Belopolsky wrote: .. >> This matches my limited research on this topic as well.  However, I am >> not sure that when these codes are embedded in Arabic text, their >&

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

On Thu, Dec 2, 2010 at 11:56 AM, Antoine Pitrou wrote: > Le jeudi 02 décembre 2010 à 11:41 -0500, Alexander Belopolsky a écrit : >> >> Note that my point is not to find the correct answer here, but to >> demonstrate that we as a group don't have the expertise to get

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

On Thu, Dec 2, 2010 at 1:55 PM, Antoine Pitrou wrote: .. > I don't think so.  str.split() and str.splitlines() are also defined in > conformance to the SPEC, AFAIK.  They certainly try to. You are joking, right? Where exactly does Unicode specify something like this: >>> ''.join('𐌀𐌁𐌂'.split('\u

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

On Thu, Dec 2, 2010 at 4:14 PM, M.-A. Lemburg wrote: .. > Have you tried Google ? > I tried google at I could not find any plain text or HTML file that would use Arabic-Indic numerals. What was interesting, though that a search for "quran unicode" (without quotes). Brought me to http://www.sacr

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

On Thu, Dec 2, 2010 at 5:58 PM, M.-A. Lemburg wrote: .. >> I will change my mind on this issue when you present a >> machine-readable file with Arabic-Indic numerals and a program capable >> of reading it and show that this program uses the same number parsing >> algorithm as Python's int() or flo

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

On Thu, Dec 2, 2010 at 4:14 PM, M.-A. Lemburg wrote: .. > Some examples: > > http://www.bdl.gov.lb/circ/intpdf/int123.pdf I looked at this one more closely. While I cannot understand what it says, It appears that Arabic numerals are used in dates. It looks like Python want be able to deal with

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

On Thu, Dec 2, 2010 at 4:57 PM, Mark Dickinson wrote: .. > (the decimal spec requires that non-European digits be accepted). Mark, I think *requires* is too strong of a word to describe what the spec says. The decimal module documentation refers to two authorities: 1. IBM’s General Decimal Ar

Re: [Python-Dev] "Missing" 2.5 feature

see the current state of the program (which is trivial in environments like the JVM for example). Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.pyth

Re: [Python-Dev] Doctest and Footnotes

Benji York zope.com> writes: > > Here's the idea: when a footnote is referenced in prose, execute the > code associated with the footnote at that point. For example: > Another natural place for the referenced code is the __test__ dictionary. Using that has an advantage of not clobbering the

Re: [Python-Dev] Doctest and Footnotes

On 7/11/06, Benji York <[EMAIL PROTECTED]> wrote: [snip] > I'm not quite sure what you're suggesting. A guess: put the code that > isn't to be seen in the __test__ dict with a string key being the name > of the footnote? That's right. > I don't think a ReST processor would like that much. > It

Re: [Python-Dev] Doctest and Footnotes

On 7/11/06, Fred Drake <[EMAIL PROTECTED]> wrote: > On Tuesday 11 July 2006 14:12, Alexander Belopolsky wrote: > > Also __new__ and __init__ method docstrings is the natural place to > > put set-up code. > > Maybe, if all the tests required the same setup code.

<    1   2   3   4   5   6   7   8   >