[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
[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
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 patc
[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
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 patc
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).
>
[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
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
extensi
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 be
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
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 b
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,
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")
> s
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')
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 packag
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 us
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 t
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 sp
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 sa
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
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 be
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
> tr
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
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 a
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 sql
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 wa
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
> > incompatibi
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 versi
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
> p
[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 nominall
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 se
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
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 w
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.
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
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__() m
-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. conte
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
38 matches
Mail list logo
