Re: [Python-Dev] Contributing to Python
Christian Heimes schrieb: > Mike Klaas wrote: >> Question: should patches include edits to whatsnew.rst, or is the >> committer responsible for adding a note? > > A patch should contain edits for Misc/NEWS. And documentation changes should include proper "versionchanged" or "versionadded" tags if it's not just a bug fix. > Patches without > documentation and NEWS updates costs the committer more time and reduces > the likelihood of a commit. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Extend reST spec to allow automatic recognition of identifiers in comments?
-On [20080105 22:44], Jameson Chema Quinn ([EMAIL PROTECTED]) wrote:
>The "syntax" of what goes inside these is very loose.
>identifier_list ::= []
>{ }
>, with no whitespace after initial_word, and where separator_symbol is the set
>of symbols ".,<>{}[]+-*^%=|/()[]{}" MINUS closing_symbol. content_word could
>maybe be a quoted string, too.
>In the "function name", no whitespace
>is allowed, but the symbols ".,*^=><-" are. Thus::
Given the fact Python 3k will use unicode natively for strings and, IIRC,
UTF-8 as standard encoding for Python files, have you thought about the
half-width and full-width characters like the ones you describe above? 「」
are, for example, very common in Japanese where English would use quotes.
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Possession is nine points of the law...
___
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] Rounding Decimals
On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > I think pep 3141's round(x, ndigits) does (1). The only thing it > > doesn't support yet is specifying the rounding mode. Perhaps the pep > > should say that round() passes any extra named arguments on to the > > __round__() method so that users can specify a rounding mode for types > > that support it? > > That would clutter the interface. Just specify a universal rounding mode for > __round__ and have Decimal's implementation of that > method comply. Yeah, thinking about this more, a .round() method on Context objects seems like a better way to handle the part of Mark's request that the round builtin doesn't cover. Of course, there may be even better alternatives that I haven't thought of. I'll post a patch to http://bugs.python.org/issue1623 tomorrow so we have something concrete to talk about. -- Namasté, Jeffrey Yasskin ___ 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] Return type of round, floor, and ceil in 2.6
On Jan 5, 2008 4:20 PM, Tim Peters <[EMAIL PROTECTED]> wrote: > [Guido] > > Wow. Do you have an opinion as to whether we should adopt > > round-to-even at all (as a default)? > > Yes: yes :-) Thanks for the suggestion, Tim. Here's a new proposed patch to the pep. It still allows type-defined half-rounding behavior so that Decimal can follow the current context. I'll submit it tomorrow unless there are significant objections. Index: pep-3141.txt === --- pep-3141.txt(revision 59739) +++ pep-3141.txt(working copy) @@ -205,8 +205,12 @@ def __round__(self, ndigits:Integral=None): """Rounds self to ndigits decimal places, defaulting to 0. -If ndigits is omitted or None, returns an Integral, otherwise -returns a Real. Rounds half toward even. +If ndigits is omitted or None, returns an Integral, +otherwise returns a Real, preferably of the same type as +self. Types may choose which direction to round half. For +example, float rounds half toward even, and Decimal rounds +it according to the current context. + """ raise NotImplementedError @@ -428,10 +432,14 @@ least Integral ``>= x``. 4. ``__round__(self)``, called from ``round(x)``, which returns the - Integral closest to ``x``, rounding half toward even. There is also - a 2-argument version, ``__round__(self, other)``, called from - ``round(x, y)``, which should return a Real. + Integral closest to ``x``, rounding half as the type chooses. + ``float`` will change in 3.0 to round half toward even. There is + also a 2-argument version, ``__round__(self, ndigits)``, called + from ``round(x, ndigits)``, which should return a Real. +In 2.6, ``math.floor``, ``math.ceil``, and ``round`` will continue to +return floats. + Because the ``int()`` conversion implemented by ``float`` (and by ``decimal.Decimal``) is equivalent to but less explicit than ``trunc()``, let's remove it. (Or, if that breaks too much, just add a -- Namasté, Jeffrey Yasskin ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Hello! We are discussing name space packages on the stdlib reorg list. For Python 3.0 we plan to organize the packages by purpose, e.g. put all database related packages like sqlite and shelve in a 'databases' name space. Of course we want to have the name spaces extensible by 3rd party software. The Python world as currently two ways to create extensible name space packages: pkgutil and pkg_resource. pkgutil is part of Python 2.5. pkg_resource is scheduled for Python 2.6 and 3.0 in PEP 365 [1]. The PEP hasn't been accepted yet. Questions: * PJE: Is pkg_resource ready for Python 2.6 and 3.0? * GvR: Are you going to accept Phillip's PEP? * PJE: Does pkg_resource have an easy way to overwrite a package in a name space package? E.g. an user wants to overwrite Python's databases.sqlite with a newer version of sqlite. Can he simply do it by inserting a package into sys.path before Lib/ ? Christian [1] http://www.python.org/dev/peps/pep-0365/ ___ 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] Do we need both Trac and Roundup?
A ticket I opened on Roundup about a website issue some time ago was closed today. It was related to a different topic, but in the discussion I wrote: Is there some reason at this point that we need to maintain two separate trackers? A ton of work went into making our Roundup instance what the key players wanted. Why not use it to track website issues as well? With them separate you have two communities of maintainers and triage folks who are mostly disjoint. I assume there would be some trac-to-roundup conversion necessary. Perhaps something like that already exists. Do people think it would be worthwhile to merge the Trac tracker content (the issue tracker that holds tickets related to the python.org website) into the Roundup tracker (the issue tracker that holds tickets related to Python the language)? While they are nominally distinct activities, it seems to me that we must waste some precious resources (mostly people) maintaining two mostly disjoint trackers. There is also some functionality overlap, mostly in the documentation area. Skip ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 8:33 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > * PJE: Does pkg_resource have an easy way to overwrite a package in a > name space package? E.g. an user wants to overwrite Python's > databases.sqlite with a newer version of sqlite. Can he simply do it by > inserting a package into sys.path before Lib/ ? Do we really want to encourage this? Wouldn't that just introduce more pyxml-like nightmares? I've been bitten way too many times by pyxml overwriting the regular xml package and causing version incompatibilities. I'd hate for this kind of thing to become common practice. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Contributing to Python
Guido van Rossum wrote: > On Jan 5, 2008 2:36 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: >> A patch should contain edits for Misc/NEWS. Patches without >> documentation and NEWS updates costs the committer more time >> and reduces the likelihood of a commit. >> >> Even a perfect patch costs several minutes of our life time. >> The patch must be reviewed, applied, compiled, the entire unit >> test suite must pass and finally it must be committed and the >> issues needs to be closed, too. > > Several minutes?! The average "perfect" patch costs me more like > between half an hour and an hour. > QOTW. I think this excerpt should show up in the new developer area. --Scott David Daniels [EMAIL PROTECTED] ___ 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] Do we need both Trac and Roundup?
[EMAIL PROTECTED] wrote: > Do people think it would be worthwhile to merge the Trac tracker content > (the issue tracker that holds tickets related to the python.org website) > into the Roundup tracker (the issue tracker that holds tickets related to > Python the language)? While they are nominally distinct activities, it > seems to me that we must waste some precious resources (mostly people) > maintaining two mostly disjoint trackers. I think it would be a great idea. As I try to get back up on a new, "privacy=paranoid" machine, I went to mention that somewhere in the logging in process, there should be an indication of how much your box must be opened up before you can "log on," at least in the screen you get to when you log on. However, each time I went to enter such a note, I needed to "log on." I just gave up. -Scott David Daniels [EMAIL PROTECTED] ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Steven Bethard wrote: > Do we really want to encourage this? Wouldn't that just introduce > more pyxml-like nightmares? I've been bitten way too many times by > pyxml overwriting the regular xml package and causing version > incompatibilities. I'd hate for this kind of thing to become common > practice. I like to give 3rd party software a chance to *extend* a name space package like xml rather then to overwrite it. As far as I understand your problem pyxml is overwriting the name space and claiming it for itself rather than extending it. Christian ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 11:34 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Steven Bethard wrote: > > Do we really want to encourage this? Wouldn't that just introduce > > more pyxml-like nightmares? I've been bitten way too many times by > > pyxml overwriting the regular xml package and causing version > > incompatibilities. I'd hate for this kind of thing to become common > > practice. > > I like to give 3rd party software a chance to *extend* a name space > package like xml rather then to overwrite it. As far as I understand > your problem pyxml is overwriting the name space and claiming it for > itself rather than extending it. The most recent problem was that pyxml installs a different version of pyexpat so that ``xml.parsers.pyexpat`` != ``pyexpat``. This causes problems with mod_python: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash What concerned me was your comment: E.g. an user wants to overwrite Python's databases.sqlite with a newer version of sqlite Maybe the situation is different here, but having someone installing a different version of sqlite behind my back makes me nervous. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
At 07:34 PM 1/6/2008 +0100, Christian Heimes wrote: >Steven Bethard wrote: > > Do we really want to encourage this? Wouldn't that just introduce > > more pyxml-like nightmares? I've been bitten way too many times by > > pyxml overwriting the regular xml package and causing version > > incompatibilities. I'd hate for this kind of thing to become common > > practice. > >I like to give 3rd party software a chance to *extend* a name space >package like xml rather then to overwrite it. As far as I understand >your problem pyxml is overwriting the name space and claiming it for >itself rather than extending it. Indeed. It should also be noted that namespace packages are actually a very mature technology at this point. Before setuptools, pkgutil already supported them, from the time of 2.3's release. ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
At 04:33 PM 1/6/2008 +0100, Christian Heimes wrote: >Hello! > >We are discussing name space packages on the stdlib reorg list. For >Python 3.0 we plan to organize the packages by purpose, e.g. put all >database related packages like sqlite and shelve in a 'databases' name >space. > >Of course we want to have the name spaces extensible by 3rd party >software. The Python world as currently two ways to create extensible >name space packages: pkgutil and pkg_resource. > >pkgutil is part of Python 2.5. pkg_resource is scheduled for Python 2.6 >and 3.0 in PEP 365 [1]. The PEP hasn't been accepted yet. > >Questions: > >* PJE: Is pkg_resource ready for Python 2.6 and 3.0? The extra feature proposed in PEP 365 isn't done yet. Without the PEP acceptance, I didn't feel the need to rush on finishing it. Apart from that, the pkg_resources module has been pretty darn stable. >* GvR: Are you going to accept Phillip's PEP? > >* PJE: Does pkg_resource have an easy way to overwrite a package in a >name space package? OverRIDE, yes; overWRITE, no. >E.g. an user wants to overwrite Python's >databases.sqlite with a newer version of sqlite. Can he simply do it by >inserting a package into sys.path before Lib/ ? As long as the 'databases' package hasn't been imported or had its namespace declared yet, yes. (I'm making the assumption, of course, that all of the namespace package requirements have been met: i.e., each package has a database/__init__.py that contains a namespace declaration and nothing else.) ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On 06/01/2008, Steven Bethard <[EMAIL PROTECTED]> wrote: > What concerned me was your comment: > > E.g. an user wants to overwrite Python's > databases.sqlite with a newer version of sqlite > > Maybe the situation is different here, but having someone installing a > different version of sqlite behind my back makes me nervous. Yes, that concerned me. Whether possible or not, I see this as bad practice in general. On the other hand, allowing cx_Oracle to register itself as databases.cx_Oracle - which is the basic "namespace" functionality - is something I feel is important. (I have no idea if the cx_Oracle author would want to do this, but I think the option should be available). Paul. ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote: >Maybe the situation is different here, but having someone installing a >different version of sqlite behind my back makes me nervous. Er, someone who? Behind whose back? I'm quite confused by what it is that's making you nervous. Do you worry about people bundling newer versions of say, the optparse module or wsgiref with their applications? If so, why? Or if not, what's different? ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 1:07 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote: > >Maybe the situation is different here, but having someone installing a > >different version of sqlite behind my back makes me nervous. > > Er, someone who? Behind whose back? I'm quite confused by what it > is that's making you nervous. > > Do you worry about people bundling newer versions of say, the > optparse module or wsgiref with their applications? If so, why? Or > if not, what's different? I worry about exactly the pyxml problem. Someone installs pyxml on my system, pyxml replaces xml.parsers.expat with a different version of pyexpat than the rest of Python, and then programs like mod_python crash because the two components were compiled against different versions of a common library. Here's the link again that I posted earlier: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash Note that this all happens "behind my back" because I didn't know that pyxml would be replacing pyexpat in such a way that would cause this crash. In fact, I didn't even know that pyxml was installing pyexpat. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] [Pydotorg] Do we need both Trac and Roundup?
On Jan 6, 2008 8:57 AM, <[EMAIL PROTECTED]> wrote: > > A ticket I opened on Roundup about a website issue some time ago was closed > today. It was related to a different topic, but in the discussion I wrote: > > Is there some reason at this point that we need to maintain two separate > trackers? A ton of work went into making our Roundup instance what the > key players wanted. Why not use it to track website issues as well? > With them separate you have two communities of maintainers and triage > folks who are mostly disjoint. > > I assume there would be some trac-to-roundup conversion necessary. > Perhaps something like that already exists. > > Do people think it would be worthwhile to merge the Trac tracker content > (the issue tracker that holds tickets related to the python.org website) > into the Roundup tracker (the issue tracker that holds tickets related to > Python the language)? While they are nominally distinct activities, it > seems to me that we must waste some precious resources (mostly people) > maintaining two mostly disjoint trackers. There is also some functionality > overlap, mostly in the documentation area. Yes, we should consolidate. But first we need more manpower to manage the tracker as it is now. Some time this month I will be sending out an announcement asking for more volunteers to help maintain the tracker. If we can get enough people to come forward to also help out we can include moving the web site tracker over as well. -Brett ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 2:01 PM, Steven Bethard <[EMAIL PROTECTED]> wrote: > On Jan 6, 2008 1:07 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote: > > >Maybe the situation is different here, but having someone installing a > > >different version of sqlite behind my back makes me nervous. > > > > Er, someone who? Behind whose back? I'm quite confused by what it > > is that's making you nervous. > > > > Do you worry about people bundling newer versions of say, the > > optparse module or wsgiref with their applications? If so, why? Or > > if not, what's different? > > I worry about exactly the pyxml problem. Someone installs pyxml on my > system, pyxml replaces xml.parsers.expat with a different version of > pyexpat than the rest of Python, and then programs like mod_python > crash because the two components were compiled against different > versions of a common library. Here's the link again that I posted > earlier: > > http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash > > Note that this all happens "behind my back" because I didn't know that > pyxml would be replacing pyexpat in such a way that would cause this > crash. In fact, I didn't even know that pyxml was installing pyexpat. This is my worry as well (and why I was going to phrase the situation in a more "should this be considered" tone than the way Christian stated it. =) . But then again none of this is impossible even if we do leave out extending the namespace. Tweaking a package's __path__ value after the fact is not exactly hard. So even if we don't do this we are not preventing anyone from extending the namespace, just discouraging. My question becomes whether we want to allow something like this even if we explicitly state people should not use this mechanism to override pre-existing modules. Do we want people tossing stuff into the 'databases' package, or should the packages in the stdlib be considered sacred? I am leaning towards not, but that's because I personally like knowing that if I import something from a stdlib namespace it is from the stdlib. I don't want some bug report from a naive user of cx_Oracle ending up in the stdlib because the import came from the 'databases' package. And I would guess that if you don't consider this a stdlib thing but for any third-party package that other third-party packages would not love other packages mucking with their namespace. -Brett ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On 06/01/2008, Brett Cannon <[EMAIL PROTECTED]> wrote: > My question becomes whether we want to allow something like this even > if we explicitly state people should not use this mechanism to > override pre-existing modules. Do we want people tossing stuff into > the 'databases' package, or should the packages in the stdlib be > considered sacred? I am leaning towards not, but that's because I > personally like knowing that if I import something from a stdlib > namespace it is from the stdlib. I don't want some bug report from a > naive user of cx_Oracle ending up in the stdlib because the import > came from the 'databases' package. And I would guess that if you don't > consider this a stdlib thing but for any third-party package that > other third-party packages would not love other packages mucking with > their namespace. I see the point, but I'm against reserving generic package names like "databases" for the stdlib, unless 3rd parties can add modules in there. Another example might be "gui.tkinter" - why shouldn't "gui.wx" be allowed? If we want a "guaranteed-stdlib" package form, we should probably have a top-level package, "std" or whatever. That notion has, I believe, been shot down before (no time to look up references now). Paul. ___ 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] Rounding Decimals
On Jan 6, 2008 1:21 AM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > I think pep 3141's round(x, ndigits) does (1). The only thing it > > > doesn't support yet is specifying the rounding mode. Perhaps the pep > > > should say that round() passes any extra named arguments on to the > > > __round__() method so that users can specify a rounding mode for types > > > that support it? > > > > That would clutter the interface. Just specify a universal rounding mode > > for __round__ and have Decimal's implementation of that > > method comply. > > Yeah, thinking about this more, a .round() method on Context objects > seems like a better way to handle the part of Mark's request that the > round builtin doesn't cover. Of course, there may be even better > alternatives that I haven't thought of. I'll post a patch to > http://bugs.python.org/issue1623 tomorrow so we have something > concrete to talk about. The new patch is posted: http://bugs.python.org/file9080/decimal-3141.patch I'll implement Context.round() in a separate patch. Comment away. :) -- Namasté, Jeffrey Yasskin ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Sun, Jan 06, 2008 at 11:12:43PM +, Paul Moore wrote: > If we want a "guaranteed-stdlib" package form, we should probably have > a top-level package, "std" or whatever. py. > That notion has, I believe, > been shot down before (no time to look up references now). Mr Van Rossum has spoken against it many times. Now I think - if we don't want a separate Python's top-level namespace may be we should think about a separate top-level non-Python's (3rd parties') namespace? With it we could have database.sqlite (Python's sqlite) and user.database.sqlite (a newer version); and by doing import database.sqlite you know exactly what version you are importing. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
At 03:01 PM 1/6/2008 -0700, Steven Bethard wrote: >Note that this all happens "behind my back" because I didn't know that >pyxml would be replacing pyexpat in such a way that would cause this >crash. In fact, I didn't even know that pyxml was installing pyexpat. Ah -- so this is 100% orthogonal to namespace packages, since this is something that can happen even without __path__ munging. Namespace packages don't actually make this any easier, either, so I don't see how this reflects on the proposal. Without a namespace package, packages earlier on sys.path *completely* override those that are installed later. With a namespace package, only the specific submodules/subpackages that exist can override the ones that appear later. IOW, without namespace packages, if you have two 'foo' packages, one containing 'bar' and the other both 'bar' and 'baz', then with namespace packages you'll always see a foo.bar and a foo.baz, with the contents of foo.bar depending on path order. *Without* namespace packages, the exact same thing is true of foo.bar, but foo.baz will also be either visible or invisible depending on the path order. In other words, the status quo actually has *more* variability of what happens. So, while it might be a good idea to advise people against replacing packages they don't "own" or at least making it prominently visible that a package replaces something in the stdlib, it doesn't (so far as I can tell) have anything to do with the merits of namespace packages one way or the ohter. Unless there is something else I'm missing? ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 3:28 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: >Now I think - if we don't want a separate Python's top-level namespace > may be we should think about a separate top-level non-Python's (3rd > parties') namespace? With it we could have database.sqlite (Python's > sqlite) and user.database.sqlite (a newer version); and by doing import > database.sqlite you know exactly what version you are importing. Bleh. I'm +1 on allowing third-party additions to the same 'database' namespace that the stdlib puts packages in. People will just have to get used to the package, and not the namespace, determining who to complain to. In theory, it might make sense to allow libraries to "close" some namespaces to deal with Brett's worry, but I think the consenting adults rule says not to bother. -- Namasté, Jeffrey Yasskin ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
At 02:10 PM 1/6/2008 -0800, Brett Cannon wrote: >My question becomes whether we want to allow something like this even >if we explicitly state people should not use this mechanism to >override pre-existing modules. Do we want people tossing stuff into >the 'databases' package, or should the packages in the stdlib be >considered sacred? This is actually an excellent point, given that the actual intended use of namespace packages is to allow an *organization* to control a namespace: e.g. zope.* and zc.* packages, osaf.* packages, etc. Using names that have meaning (like "email" or "databases") sort of goes against the whole point of namespace packages in the first place. For some reason, I wasn't thinking about that when the original post came through. So, now that I've thought about it, I'm -1 on the stdlib using *top-level* namespace packages to sort out its contents (e.g. "databases" as a top-level package name) If we want to allow separately-distributed *upgrades* or bugfix releases of projects (such as an updated sqlite module), then using 2nd-level namespace packages like "std.databases.*" would allow that. Note, by the way, that this implies that somebody creating their own Oracle driver would *not* be expected to put it into std.databases. Again, the whole point of a namespace package is to reserve that namespace for packages produced by a particular organization, similar to the way e.g. the 'org.apache.projectname' packages in Java 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 3:35 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On Jan 6, 2008 3:28 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > >Now I think - if we don't want a separate Python's top-level namespace > > may be we should think about a separate top-level non-Python's (3rd > > parties') namespace? With it we could have database.sqlite (Python's > > sqlite) and user.database.sqlite (a newer version); and by doing import > > database.sqlite you know exactly what version you are importing. > > Bleh. > > I'm +1 on allowing third-party additions to the same 'database' > namespace that the stdlib puts packages in. People will just have to > get used to the package, and not the namespace, determining who to > complain to. > > In theory, it might make sense to allow libraries to "close" some > namespaces to deal with Brett's worry, but I think the consenting > adults rule says not to bother. There seems to be a misunderstanding. This is *not* going to happen for standard library package names. I'm fine with inventing mechanisms to allow 3rd party packages to beo cobbled together from multiple contributions (it would seem to make sense for e.g. Twisted or Zope). But I am absolutely squarely against 3rd party installs adding to (or worse, overriding) standard library package names. This is (to me) simple common sense, the reason being "knowing who to blame". We get enough bug reports in the Python tracker about 3rd party software as it is. (In general I'm not keen on attempts to create a single unified ontology for library modules. It's like expecting all doctors in town to live on the same street. But my feelings on keeping a clean demarcation between standard and 3rd party are much stronger.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
Phillip J. Eby wrote: > This is actually an excellent point, given that the actual intended > use of namespace packages is to allow an *organization* to control a > namespace: e.g. zope.* and zc.* packages, osaf.* packages, > etc. Using names that have meaning (like "email" or "databases") > sort of goes against the whole point of namespace packages in the first place. > > For some reason, I wasn't thinking about that when the original post > came through. > > So, now that I've thought about it, I'm -1 on the stdlib using > *top-level* namespace packages to sort out its contents (e.g. > "databases" as a top-level package name) I don't have a strong opinion as PJE but tend to agree with his point of view. We must not reserve a complete set of top level names and close them for 3rd party software. *Either* we create subject area packages (e.g. databases, web) and open them for 3rd party software *or* we create a top level name space for Python's stdlib and reserve it for our own purpose. For the initial example of "databases.sqlite" I think py.db.sqlite has a nice ring to it. > If we want to allow separately-distributed *upgrades* or bugfix > releases of projects (such as an updated sqlite module), then using > 2nd-level namespace packages like "std.databases.*" would allow that. I like to see a possibility to easily upgrade, bugfix or extend a stdlib package with 3rd party extensions. PEP 297 (http://www.python.org/dev/peps/pep-0297/) contains some useful ideas. > Note, by the way, that this implies that somebody creating their own > Oracle driver would *not* be expected to put it into > std.databases. Again, the whole point of a namespace package is to > reserve that namespace for packages produced by a particular > organization, similar to the way e.g. the 'org.apache.projectname' > packages in Java work. The initial idea behind the new packages for Python 3.0 weren't really based on name space packages. It was more about grouping related modules by subject. Christian ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 4:10 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > This is actually an excellent point, given that the actual intended > > use of namespace packages is to allow an *organization* to control a > > namespace: e.g. zope.* and zc.* packages, osaf.* packages, > > etc. Using names that have meaning (like "email" or "databases") > > sort of goes against the whole point of namespace packages in the first > > place. > > > > For some reason, I wasn't thinking about that when the original post > > came through. > > > > So, now that I've thought about it, I'm -1 on the stdlib using > > *top-level* namespace packages to sort out its contents (e.g. > > "databases" as a top-level package name) > > I don't have a strong opinion as PJE but tend to agree with his point of > view. We must not reserve a complete set of top level names and close > them for 3rd party software. Why not? 3rd party software can copy the same hierarchy under its own toplevel package, e.g. zope.db, zope.net, etc. Regarding using common words, either the stdlib grabs these, or *nobody* gets to use them (for fear of conflicting with some other 3rd party package grabbing the same). > *Either* we create subject area packages (e.g. databases, web) and open > them for 3rd party software *or* we create a top level name space for > Python's stdlib and reserve it for our own purpose. > > For the initial example of "databases.sqlite" I think py.db.sqlite has a > nice ring to it. Java's example notwithstanding, I don't want "py" or "python" to be part of the stdlib package namespace. *If* (part of) the stdlib has to live under a single distinguished name, pick something like "std" or "core". When I'm using Python I already know I'm using Python, I don't want to be reminded of that fact on every import line. > > If we want to allow separately-distributed *upgrades* or bugfix > > releases of projects (such as an updated sqlite module), then using > > 2nd-level namespace packages like "std.databases.*" would allow that. > > I like to see a possibility to easily upgrade, bugfix or extend a stdlib > package with 3rd party extensions. PEP 297 > (http://www.python.org/dev/peps/pep-0297/) contains some useful ideas. I see mostly possibilities for abuse here. Linux vendors can install bugfixes or using their own packaging system. > > Note, by the way, that this implies that somebody creating their own > > Oracle driver would *not* be expected to put it into > > std.databases. Again, the whole point of a namespace package is to > > reserve that namespace for packages produced by a particular > > organization, similar to the way e.g. the 'org.apache.projectname' > > packages in Java work. Right. > The initial idea behind the new packages for Python 3.0 weren't really > based on name space packages. It was more about grouping related modules > by subject. See my previous post. This is only mildly useful. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Rounding Decimals
FWIW, I don't think all of these patches are helpful. The implementations are so easy and the effects are so obvious, that it is simply better to decide what to do first, then do it afterwards. My own preference is to leave the decimal module alone (except for a __round__ method to be called by builtin.round). Adding more methods to that module does not make it easier to use -- there are already a mind-numbing range of choices in the current, minimal implementation of the spec. I would support having a separate module of convenience functions or a separate module that uses a subset, but growth of the core module will only make it harder to use and more difficult to maintain. Another idea for simplifcation is to write-up a good tutorial to the basics of using the module. Please show restraint when proposing API changes to decimal -- I think it would be easy to do more harm than good. Raymond - Original Message - From: "Jeffrey Yasskin" <[EMAIL PROTECTED]> To: "Raymond Hettinger" <[EMAIL PROTECTED]> Cc: "Mark Dickinson" <[EMAIL PROTECTED]>; "Python 3000" <[EMAIL PROTECTED]>; Sent: Sunday, January 06, 2008 3:26 PM Subject: Re: [Python-Dev] Rounding Decimals > On Jan 6, 2008 1:21 AM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: >> On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> > > I think pep 3141's round(x, ndigits) does (1). The only thing it >> > > doesn't support yet is specifying the rounding mode. Perhaps the pep >> > > should say that round() passes any extra named arguments on to the >> > > __round__() method so that users can specify a rounding mode for types >> > > that support it? >> > >> > That would clutter the interface. Just specify a universal rounding mode >> > for __round__ and have Decimal's implementation of >> > that >> > method comply. >> >> Yeah, thinking about this more, a .round() method on Context objects >> seems like a better way to handle the part of Mark's request that the >> round builtin doesn't cover. Of course, there may be even better >> alternatives that I haven't thought of. I'll post a patch to >> http://bugs.python.org/issue1623 tomorrow so we have something >> concrete to talk about. > > The new patch is posted: http://bugs.python.org/file9080/decimal-3141.patch > I'll implement Context.round() in a separate patch. Comment away. :) > > -- > Namasté, > Jeffrey Yasskin > ___ 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] Rounding Decimals
On Jan 6, 2008 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > FWIW, I don't think all of these patches are helpful. The implementations > are so easy and the effects are so obvious, that it is > simply better to decide what to do first, then do it afterwards. > > My own preference is to leave the decimal module alone (except for a > __round__ method to be called by builtin.round). You must mean __trunc__ to support builtin.trunc(), since builtin.round no longer calls __round__ in 2.6. The other 3 methods specified by PEP 3141 aren't strictly necessary for 2.6, but they will be needed for 3.0. I'd rather not make the two versions of Decimal gratuitously different, so this patch puts them in the 2.6 version too. That's basically all of the changes in this patch, so I'm not sure exactly what you're objecting to. Could you be more precise? -- Namasté, Jeffrey Yasskin ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008, at 6:28 PM, Oleg Broytmann wrote: > On Sun, Jan 06, 2008 at 11:12:43PM +, Paul Moore wrote: >> If we want a "guaranteed-stdlib" package form, we should probably >> have >> a top-level package, "std" or whatever. > >py. > >> That notion has, I believe, >> been shot down before (no time to look up references now). > >Mr Van Rossum has spoken against it many times. > >Now I think - if we don't want a separate Python's top-level > namespace > may be we should think about a separate top-level non-Python's (3rd > parties') namespace? I think some things make sense to move some things into a common namespace: hashlib, email, xml et al... I also think there are probably other candidates for similar grouping and cleanup, but I don't have a well thought out set. (db, url??, zip??); and I think it is happening, albeit slowly. > With it we could have database.sqlite (Python's > sqlite) and user.database.sqlite (a newer version); and by doing > import > database.sqlite you know exactly what version you are importing. At first blush I am +1 for a third party or non stdlib namespace; user is already a module though. Other ideas: sitepkg, addon, extra, ext But then what of packages that are already namespaced? It would be tedious to; from sitepkg.zope.app.interface import SomeThing So while I like the idea, I think I am against wedging everything into namespaces just for the sake of it; at the end of the day I think I am -1 on *requiring* it. Additionally, I have only been reading this list for a week or so and feel a little like I may be injecting a novice and poorly formed opinion into a discussion that has been ongoing for years. Please pardon my ignorance if this is the case. ~ro > Oleg. > -- > Oleg Broytmannhttp://phd.pp.ru/ > [EMAIL PROTECTED] >Programmers don't die, they just GOSUB without RETURN. > ___ > 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/reed% > 40reedobrien.com ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: >Regarding using common words, either the stdlib grabs these, or >*nobody* gets to use them (for fear of conflicting with some other 3rd >party package grabbing the same). This isn't quite true; a standalone Python application that isn't extensible doesn't need to worry about this. And it's standalone apps that are most likely to claim these common words. (For example, until recently, Chandler's database library packages were in 'repository.*'.) But of course this is still a pretty minor point overall. If the stdlib does go for deeper nestings, I have a slight preference for seeing them under std.* or some such rather than top level. But I don't really see a whole lot of point to doing a major re-org of the stdlib space to begin with, for the simple reason that package names are not really categories -- they're *names*. IMO 'from databases import sqlite' doesn't add any value over 'import pysqlite3' to begin with. Worse, it will likely be an attractive nuisance for people saying "why don't we have databases.Oracle?" and suchlike. And you still have to remember the names, only now they're longer. And was it database or databases? Greater uniqueness of names is just another reason flat is better than nested. :) ___ 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] Rounding Decimals
[Jeffrey Yasskin] > The other 3 methods > specified by PEP 3141 aren't strictly necessary for 2.6, but they will > be needed for 3.0. I'd rather not make the two versions of Decimal > gratuitously different, so this patch puts them in the 2.6 version > too. If I understand you correctly, then the patch backports magic methods that do not have corresponding invocation methods in Py2.6. So, they are basically useless. If that's true, then the patch is clutter -- it makes 2.6 less desirable. It is not obvious to me how this will help someone transition to Py3.0. I'm curious to hear how Guido makes the call on this. Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds with previous discussions where I believe we said that that is *not* the goal and will likely not even be possible in many cases. Besides, if the invocation of the magic methods is different in 3.0, how are you going to keep the test suite code the same across versions? There should probably be a PEP sets clearer guidelines about what should be backported from Py3.0. Perhaps something like this: * If there is a new feature that can be implemented in both and will make both more attractive, then it should be in both. * If something is going away or changing in 3.0, then the 2.6 conversion tool mode should warn about it if possible. * If neither of the above apply, then leave 2.6 alone. > I'm not > sure exactly what you're objecting to. Could you be more precise? You note said: "I'll implement Context.round() in a separate patch. Comment away." Unless I misread what you're trying to do, that is a gratuitous API build-out (whether talking about Py2.6 or Py3.0) which adds a second-way-to-do-it to a module that already has a huge number of methods. Our goal is to keep that module as a minimal implementation of the spec. Fattening the API will make the module harder to use, not simpler. Raymond ___ 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] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 7:23 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: > >Regarding using common words, either the stdlib grabs these, or > >*nobody* gets to use them (for fear of conflicting with some other 3rd > >party package grabbing the same). > > This isn't quite true; a standalone Python application that isn't > extensible doesn't need to worry about this. And it's standalone > apps that are most likely to claim these common words. (For example, > until recently, Chandler's database library packages were in 'repository.*'.) > > But of course this is still a pretty minor point overall. If the > stdlib does go for deeper nestings, I have a slight preference for > seeing them under std.* or some such rather than top level. But I > don't really see a whole lot of point to doing a major re-org of the > stdlib space to begin with, for the simple reason that package names > are not really categories -- they're *names*. IMO 'from databases > import sqlite' doesn't add any value over 'import pysqlite3' to begin with. > > Worse, it will likely be an attractive nuisance for people saying > "why don't we have databases.Oracle?" and suchlike. And you still > have to remember the names, only now they're longer. And was it > database or databases? Greater uniqueness of names is just another > reason flat is better than nested. :) Right. Packages are useful if it helps make the sub-names shorter. The email package is a good example: it uses lots of generic names like errors, charset, encoders, message, parser, utils, iterators. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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-3000] Rounding Decimals
On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Jeffrey Yasskin] > > The other 3 methods > > specified by PEP 3141 aren't strictly necessary for 2.6, but they will > > be needed for 3.0. I'd rather not make the two versions of Decimal > > gratuitously different, so this patch puts them in the 2.6 version > > too. > > If I understand you correctly, then the patch backports magic methods that do > not have corresponding invocation methods in Py2.6. > So, they are basically useless. If that's true, then the patch is clutter -- > it makes 2.6 less desirable. It is not obvious to me > how this will help someone transition to Py3.0. I'm curious to hear how > Guido makes the call on this. > > Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds > with previous discussions where I believe we said that > that is *not* the goal and will likely not even be possible in many cases. > Besides, if the invocation of the magic methods is > different in 3.0, how are you going to keep the test suite code the same > across versions? I tend to agree. 2.6 and 3.0 decimal already differ plenty. > There should probably be a PEP sets clearer guidelines about what should be > backported from Py3.0. Can you volunteer a draft? It could be PEP 3003. I'm probably too close to 3.0 to be able to objectively write this, which really represents end users' desire for stability in 2.6. > Perhaps something like this: > * If there is a new feature that can be implemented in both and will make > both more attractive, then it should be in both. > * If something is going away or changing in 3.0, then the 2.6 conversion tool > mode should warn about it if possible. > * If neither of the above apply, then leave 2.6 alone. > > > I'm not > > sure exactly what you're objecting to. Could you be more precise? > > You note said: "I'll implement Context.round() in a separate patch. Comment > away." > > Unless I misread what you're trying to do, that is a gratuitous API build-out > (whether talking about Py2.6 or Py3.0) which adds a > second-way-to-do-it to a module that already has a huge number of methods. > Our goal is to keep that module as a minimal > implementation of the spec. Fattening the API will make the module harder to > use, not simpler. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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-3000] Rounding Decimals
[Raymond] >> There should probably be a PEP sets clearer guidelines about what should be >> backported from Py3.0. >> >> Perhaps something like this: >> * If there is a new feature that can be implemented in both and will make >> both more attractive, then it should be in both. >> * If something is going away or changing in 3.0, then the 2.6 conversion >> tool mode should warn about it if possible. >> * If neither of the above apply, then leave 2.6 alone. [Guido van Rossum] > Can you volunteer a draft? It could be PEP 3003. I'm probably too > close to 3.0 to be able to objectively write this, which really > represents end users' desire for stability in 2.6. Yes. Will do. Raymond ___ 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] Rounding Decimals
On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Jeffrey Yasskin] > > The other 3 methods > > specified by PEP 3141 aren't strictly necessary for 2.6, but they will > > be needed for 3.0. I'd rather not make the two versions of Decimal > > gratuitously different, so this patch puts them in the 2.6 version > > too. > > If I understand you correctly, then the patch backports magic methods that do > not have corresponding invocation methods in Py2.6. > So, they are basically useless. If that's true, then the patch is clutter -- > it makes 2.6 less desirable. It is not obvious to me > how this will help someone transition to Py3.0. I'm curious to hear how > Guido makes the call on this. > > Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds > with previous discussions where I believe we said that > that is *not* the goal and will likely not even be possible in many cases. > Besides, if the invocation of the magic methods is > different in 3.0, how are you going to keep the test suite code the same > across versions? Given Guido's agreement, expect another version of this patch with only __trunc__. > There should probably be a PEP sets clearer guidelines about what should be > backported from Py3.0. Perhaps something like this: > * If there is a new feature that can be implemented in both and will make > both more attractive, then it should be in both. > * If something is going away or changing in 3.0, then the 2.6 conversion tool > mode should warn about it if possible. > * If neither of the above apply, then leave 2.6 alone. > > > I'm not > > sure exactly what you're objecting to. Could you be more precise? > > You note said: "I'll implement Context.round() in a separate patch. Comment > away." Oh, sorry for not being clear then. I don't intend to write or discuss that separate patch until this one's approved and submitted. I think it's worth discussing eventually, but this change is more important. I mentioned this sentiment at http://bugs.python.org/msg59417 too, but clearly wasn't explicit enough in either case. -- Namasté, Jeffrey Yasskin ___ 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] Rounding Decimals
[Jeffrey Yasskin] >> > I'm not >> > sure exactly what you're objecting to. Could you be more precise? >> >> You note said: "I'll implement Context.round() in a separate patch. Comment >> away." > > Oh, sorry for not being clear then. I don't intend to write or discuss > that separate patch until this one's approved and submitted. I think > it's worth discussing eventually, but this change is more important. I > mentioned this sentiment at http://bugs.python.org/msg59417 too, but > clearly wasn't explicit enough in either case. It's hard to keep up with all of these patches and I'm growing concerned that some will sneak by. In the case of complex proposals, it is often helpful to have a patch that we can discuss concretely, but in the case of simple ones like this, they just clutter to patch tracker. There's no need to create the patch until the idea has been discussed. In the case of Context.round(), I've already advised against it. So, I'm not sure why you still intend write a separate patch and bring it back up for discussion. Ideally, it should die right now. The sentiment is unchanged -- please do not build-out the API for the decimal module. It is intended to be minimal and needs to stay that way. Further additions will only make it harder to use, harder to maintain, and will complicate efforts to rewrite the module in C. Raymond ___ 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] Rounding Decimals
[Jeffrey Yasskin] > Given Guido's agreement, expect another version of this patch with > only __trunc__. Why is __trunc__ being backported? Is a trunc() builtin being backported? What is the point for a synonym for int() and __int__ in Py2.6. Unless I'm missing something, this doesn't improve Py2.6 in the least. Raymond ___ 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
