On Mar 17, 2010, at 5:02 PM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> Python 3 doesn't need it because it is possible to not give a result
>> at all. Python 2 does need it because we have to give *some*
>> result.
>
> That's not true -- it&
On Mar 18, 2010, at 5:23 AM, Steven D'Aprano wrote:
> On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
>> On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
>>> On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
>>>> The spectrum of optio
On Mar 19, 2010, at 4:50 AM, Antoine Pitrou wrote:
> Glenn Linderman nevcal.com> writes:
>>
>> On the other hand, if the default behavior is to do an implicit
>> conversion, I don't know of any way that that could be turned into an
>> exception for those coders that don't want or don't like t
On Mar 19, 2010, at 11:11 AM, Antoine Pitrou wrote:
> Raymond Hettinger gmail.com> writes:
>>
>> The reason to prefer an exception is that decimal/float comparisons
>> are more likely to be a programmer error than an intended behavior.
>
> Not more so than float/
On Mar 19, 2010, at 11:42 AM, Glenn Linderman wrote:
>>
>
> The whole point of providing Decimal is for applications for which float is
> inappropriate. I didn't think I needed to reproduce PEP 327 in my email.
>
> So when a coder choose to use Decimal, it is because float is inappropriate.
On Mar 19, 2010, at 2:50 PM, Guido van Rossum wrote:
> I'd like to reboot this thread. I've been spinning this topic in my
> head for most of the morning, and I think we should seriously
> reconsider allowing mixed arithmetic involving Decimal, not just mixed
> comparisons. [Quick summary: embed
On Mar 20, 2010, at 6:54 PM, Nick Coghlan wrote:
>
> I suggest a 'linearised' numeric tower that looks like:
>
> int -> Decimal -> Fraction -> float -> complex
Is that a typo? Shouldn't Decimal and float go between Fraction and complex?
The abstract numeric tower is:
Number Complex R
On Mar 20, 2010, at 4:27 PM, Jeffrey Yasskin wrote:
>
> When designing it, I tried to include a notion of exact/inexact types,
> but we couldn't find anything practical to do with them, so we took
> them out.
The were also other reasons that they were taken out. The notion of
inexactness is a
>>
>> Note that this would involve adding mixed Fraction/Decimal arithmetic as
>> well as Decimal/float arithmetic.
>
> Yes, that was my intention too.
+1
>
>> I placed Decimal to the left of
>> Fraction to keep Decimal's dependencies clear and because Decimal ->
>> Fraction conversions appe
On Mar 20, 2010, at 9:40 PM, Greg Ewing wrote:
> Mark Dickinson wrote:
>
>> Except that float is fixed-width (typically 53 bits of precision),
>> while Decimal allows a user-specified, arbitrarily large, precision;
>
> Yes, but it still has *some* fixed limit at any given
> moment, so the resul
On Mar 21, 2010, at 10:02 AM, Guido van Rossum wrote:
> On Sun, Mar 21, 2010 at 9:53 AM, Guido van Rossum wrote:
>> Which I still have to review. (Mark, if you're there, could you make a
>> brief post here on the mathematical definition of the new hash you're
>> proposing, and why it is both eff
On Mar 21, 2010, at 11:50 AM, R. David Murray wrote:
> On Sun, 21 Mar 2010 11:25:34 -0700, Raymond Hettinger
> wrote:
>> It seems to me that Decimals and floats should be considered at
>> the same level (i.e. both implement Real).
>>
>> Mixed Decimal and float sh
On Mar 21, 2010, at 3:35 PM, Guido van Rossum wrote:
>
>> It seems to me that Decimals and floats should be considered at
>> the same level (i.e. both implement Real).
>
> Agreed, but doesn't help. (Except against the idea that Decimal goes
> on the "integer" side of Fraction, which is just wron
On Mar 21, 2010, at 3:50 PM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> Since decimal also allows arbitrary sizes, all long ints can be
>> exactly represented (this was even one of the design goals
>> for the decimal module).
>
> There may be something we n
On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote:
> On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote:
>> I really like Guido's idea of a context flag to control whether
>> mixing of decimal and binary floats will issue a warning.
>> The default should b
On Mar 21, 2010, at 6:24 PM, Guido van Rossum wrote:
> On Sun, Mar 21, 2010 at 4:16 PM, Raymond Hettinger
> wrote:
>>
>> On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote:
>>
>>> On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote:
>>>&g
On Mar 22, 2010, at 2:23 AM, Mark Dickinson wrote:
> Note that comparisons are a separate issue: those always need to be
> done exactly (at least for equality, and once you're doing it for
> equality it makes sense to make the other comaprisons exact as well),
> else the rule that x == y implies
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>
>> Decimal + float --> Decimal
>
> If everybody associated with the Decimal implementation wants this I
> won't stop you; as I repeatedly said my intuition about this one (as
> opposed to the other two above) is very weak.
That's my vote
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
> wrote:
>>
>> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>>
>> Decimal + float --> Decimal
>>
>> If everybody associated
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
>
> Just for the record, I'd also prefer Decimal + Fraction -> Decimal.
Guido was persuasive on why float + Fraction --> float,
so this makes sense for the same reasons.
For the implementation, is there a way to avoid the double rounding
in
On Mar 22, 2010, at 11:54 AM, Guido van Rossum wrote:
>
> So now we have a second-order decision to make -- whether
> Decimal+float should convert the float to Decimal using the current
> context's precision, or do it exactly. I think we should just follow
> Decimal.from_float() here, which AFAIK
One other thought.
The Decimal constructor should now accept floats as a possible input type.
Formerly, we separated that out to Decimal.from_float() because
decimals weren't interoperable with floats.
This will put decimal and float back on equal footing so that we have both:
float(some_deci
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This corresponds to common schoolbook problems and simple client requests:
"Express 3.5 as a fraction".
>>> Fraction(Decimal('3.5'))
Fraction(7, 2)
Unlike typical binary
For the record, I thought I would take a stab at making a single post
that recaps the trade-offs and reasoning behind the decision
to have Fraction + decimal/float --> decimal/float.
Pros:
* While we know that both decimal and binary floats have a
fixed internal precision and can be converted los
On Mar 23, 2010, at 5:09 AM, Stefan Krah wrote:
>
> I like the simplicity of having a single signal (e.g. CoercionError), but
> a strictness context flag could offer greater control for people who only
> want pure decimal/integer operations.
>
>
> For example:
>
> strictness 0: completely pro
On Mar 24, 2010, at 9:22 AM, Mark Dickinson wrote:
>
> The obvious way to do this nan interning for floats would be to put
> the interning code into PyFloat_FromDouble. I'm not sure whether this
> would be worth the cost in terms of added code (and possibly reduced
> performance, since the nan c
On Mar 24, 2010, at 12:51 PM, Alexander Belopolsky wrote:
>
> - "Reflexivity, and other pillars of civilization" by Bertrand Meyer
> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
Excellent link.
Thanks for the research.
Raymond
___
ter already ;-)
Adding a FAQ entry is simpler than building-out
Context object circuitry and documenting it in an
understandable way.
Raymond
On Mar 24, 2010, at 12:36 PM, Stefan Krah wrote:
> Nick Coghlan wrote:
>> Raymond Hettinger wrote:
>>> The decimal module is already drow
On Mar 24, 2010, at 2:09 PM, Mark Dickinson wrote:
> Slight change of topic. I've been implementing the extra comparisons
> required for the Decimal type and found an anomaly while testing.
> Currently in py3k, order comparisons (but not ==, !=) between a
> complex number and another complex, fl
On Mar 24, 2010, at 2:31 PM, Alexander Belopolsky wrote:
> """
> In this context it doesn't particularly shock me that operations on
> NaN should cause invariant violations. After all, isn't NaN supposed
> to mean "not a number"? If it's not a number, it doesn't have to
> satisfy the properties o
> Even unordered collections are affected:
s/unordered/unhashed, equality-based/
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-d
On Mar 25, 2010, at 4:22 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Here's an interesting recent blog post on this subject, from the
>> creator of Eiffel:
>>
>> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
>
> Interesting. So the natural tweak that
On Mar 25, 2010, at 4:21 PM, Georg Brandl wrote:
> Am 25.03.2010 22:45, schrieb Greg Ewing:
>> Georg Brandl wrote:
>>> Thinking of each value created by float('nan') as
>>> a different nan makes sense to my naive mind, and it also explains
>>> nicely the behavior present right now.
>>
>> Not ent
On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>>
> How about raising an exception instead of creating nans in the first place,
> except maybe within specific contexts (so that the IEEE-754 minded can get
> their nans working as they currently do)?
-1
The numeric community uses NaNs as pl
On Apr 1, 2010, at 4:20 PM, Andrew Svetlov wrote:
> using of copy.copy for simple iterators is forbidden
>
import copy
copy.copy(iter([1, 2, 3]))
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/andrew/projects/py3k/Lib/copy.py", line 96, in copy
>return
>> Guido van Rossum, 16.04.2010 16:33:
>>>
>>> I am fine with
>>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>>> the ** mechanism.
ISTM that making it illegal costs cycles with giving any real benefit.
It is reasonably common to accept **kwds and then pass it down
to ano
> On Fri, Apr 16, 2010 at 2:11 PM, Raymond Hettinger
> wrote:
>>
>>>> Guido van Rossum, 16.04.2010 16:33:
>>>>>
>>>>> I am fine with
>>>>> declaring dict({}, **{1:3}) illegal, since after all it is abuse of
>>>>&g
On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote:
>
> IIRC, there's a performance hack in dictobject.c that keeps track of whether
> all of the keys are strings or not. The hack is designed so that lookup
> operations can call the string compare/hash functions directly if possible,
> rathe
On Jun 8, 2010, at 9:13 PM, Benjamin Peterson wrote:
> 2010/6/8 Alexandre Vassalotti :
>> Is there is any plan for a 2.8 release? If not, I will go through the
>> tracker and close outstanding backport requests of 3.x features to
>> 2.x.
>
> Not from the core development team.
The current plan
On Jun 18, 2010, at 3:08 PM, Michael Foord wrote:
> I'm still baffled as to how a bug in the cgi module (along with the
> acknowledged email problems) is such a big deal. Was it reported and then
> languished in the bug tracker? That would be bad ion its own but if it was
> only recently disco
On Jun 18, 2010, at 7:39 PM, Terry Reedy wrote:
> On 6/18/2010 6:51 PM, Raymond Hettinger wrote:
>> There has been a disappointing
>> lack of bug reports across the board for 3.x.
>
> Here is one from this week involving the interaction of array and bytearray.
> It need
On Jun 19, 2010, at 5:39 PM, geremy condra wrote:
> Bottom line, what I'd really like to do is kick them all off of #python,
This is so profoundly wrong on so many levels it is hard to know how to respond.
Raymond
___
Python-Dev mailing list
Python-De
There's an entry in whatsnew for 2.7 to the effect of "The UserDict class is
now a new-style class".
I had thought there was a conscious decision to not change any existing classes
from old-style to new-style. IIRC, Martin had championed this idea and had
rejected all of proposals to make exis
On Jun 21, 2010, at 10:31 PM, Glyph Lefkowitz wrote:
> This is a common pain-point for porting software to 3.x - you had a string,
> it kinda worked most of the time before, but now you need to keep track of
> text too and the functions which seemed to work on bytes no longer do.
Thanks Glyph
On Jun 22, 2010, at 5:48 AM, Benjamin Peterson wrote:
> 2010/6/22 Raymond Hettinger :
>> There's an entry in whatsnew for 2.7 to the effect of "The UserDict class is
>> now a new-style class".
>> I had thought there was a conscious decision to not change any e
On Jun 22, 2010, at 10:08 AM, Benjamin Peterson wrote:
> . There was a typo in
> abc.py which prevented it from raising errors when non new-style class
> objects were passed in.
For 2.x, that was probably a good thing, a happy accident
that made it possible to register existing mapping classes
as
On Jun 22, 2010, at 3:59 PM, Michael Foord wrote:
> On 23/06/2010 00:03, Greg Ewing wrote:
>> Benjamin Peterson wrote:
>>
>>> IIRC this was because UserDict tries to be a MutableMapping but abcs
>>> require new style classes.
>>
>> Are there any use cases for UserList and UserDict in new
>> cod
On Jul 10, 2010, at 9:23 PM, Guilherme Polo wrote:
> 2010/7/10 Miki Tebeka :
>> Hello Tal,
>>
>>> I would like to propose removing IDLE from the standard library.
>> -1.
-1 from me too.
IDLE is the tool I almost always used to introduce people to Python.
FWIW, I've run in on a Mac and Windows
On Jul 14, 2010, at 3:43 PM, M.-A. Lemburg wrote:
> Is this intended or should I open a bug report for it:
>
m = memoryview('abc')
m == 'abc'
> True
str(m) == 'abc'
> False
str(m)
> ''
>
> I would have expected str(m) == 'abc'.
That is also my expectation.
A memoryview obj
On May 20, 2010, at 10:35 AM, Martin v. Löwis wrote:
>> I think it'd be useful enough to go in the standard library. Now that
>> there's a sample implementation, should I still try to demonstrate why I
>> believe it's worth adding to the stdlib and get support?
>
> Most definitely. Just in case
On Jul 25, 2010, at 11:38 AM, Michael Foord wrote:
> On 25/07/2010 19:34, Alexander Belopolsky wrote:
>> [snip...]
>>> On the other hand, posting actual patches that fix actual bugs can
>>> make a lot of a difference. Also, having a maintainer who is willing
>>> to look into these patches and acc
On Jul 28, 2010, at 7:31 AM, Guido van Rossum wrote:
> On Tue, Jul 27, 2010 at 10:29 PM, Stefan Behnel wrote:
>> What about actually putting it visibly into the stdlib? Except for files, I
>> didn't see much about caching there, which seems like a missing battery to
>> me. Why not do it as with
On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote:
> Now that we've got the short float repr in Python, there's less value
> in having float.__str__ truncate to 12 significant digits (as it
> currently does). For Python 3.2, I propose making float.__str__ use
> the same algorithm as float.__rep
>> When you proposed the idea at EuroPython, it seemed reasonable
>> but we didn't go into the pros and cons. The downsides include
>> breaking tests, changing the output of report generating scripts
>> that aren't using string formatting, and it introduces another
>> inter-version incompatibilit
On Jul 30, 2010, at 6:23 AM, Michael Foord wrote:
> For those of you who found this document perhaps just a little bit too long,
> I've written up a *much* shorter intro to the plugin system (including how to
> get the prototype) on my blog:
>
> http://www.voidspace.org.uk/python/weblog/ar
On Aug 11, 2010, at 6:00 AM, Steven D'Aprano wrote:
> @wraps(f)
> def func(*args):
>do_something()
>return f(*args)
>
> then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h,
> then you have:
>
> func.__wrapped__ => f
> func.__wrapped__.__wrapped__ => g
> func.__wrapp
On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:
> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>
>> The ability to introspect is basic to Python's design.
>> Objects know their class, functions know their code objects,
>> bound methods know both their underly
On Aug 11, 2010, at 3:28 PM, Benjamin Peterson wrote:
> 2010/8/11 Raymond Hettinger :
>>
>> On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:
>>
>>> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>>>
>>>> The ability to introspect is basi
+1 from me too.
When you start, olease do leave me as the primary maintainer
for issues relating to sets and set ABCs.
Raymond
On Aug 20, 2010, at 8:53 PM, Guido van Rossum wrote:
> +1
>
> On Fri, Aug 20, 2010 at 7:23 PM, Daniel Stutzbach
> wrote:
>> Several issues that I'm involved with (
On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
> I know the issue has been discussed several times already, however I couldn't
> find any reasonable explanation of its strange behaviour. The main problem
> with 'hasattr' function is that is swallows all exceptions derived from
> Exception
On Aug 23, 2010, at 1:03 PM, Guido van Rossum wrote:
>> But hasattr() has a far different set of use cases, so we should explore
>> an alternate solution to the problem. The usual reason that people use
>> hasattr() instead of getattr() is that they want to check for the presence of
>> of a meth
On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
> 2010/8/23 Michael Foord :
>> To me hasattr *looks* like a passive introspection function, and the fact
>> that it can trigger arbitrary code execution is unfortunate - especially
>> because a full workaround is pretty arcane.
Well said. Th
On Aug 23, 2010, at 1:45 PM, Benjamin Peterson wrote:
> 2010/8/23 Raymond Hettinger :
>>
>> P.S. The current behavior seems to be deeply embedded:
>
> Well, that's what happens when a behavior is added in 1990. :)
More generally: it is an API code smell whene
On Aug 24, 2010, at 12:31 PM, Barry Warsaw wrote:
> Hello fellow Pythoneers and Pythonistas,
>
> I'm very happy to announce the release of Python 2.6.6.
Thanks Barry :-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote:
> Without a BDFL, I think we need a committee to make decisions, e.g. by
> majority vote amongst committers.
I like Guido's idea. Just appoint have one of the experienced developers
who is independent of the proposal and have them be the final
On Sep 3, 2010, at 3:52 PM, Georg Brandl wrote:
> Hi,
>
> I'm not sure what the arrangement for the What's New in Python 3.2 document
> is; especially if either Andrew or Raymond still feel in charge for it.
I'm already working on it.
Raymond
___
P
On Sep 4, 2010, at 11:20 AM, Antoine Pitrou wrote:
> Well, perhaps lru_cache() would have deserved a review before
> committing?
Not everything needs to be designed by committee.
This API is based on one that was published as a recipe
several years ago and has been used in a number of
companies.
On Sep 4, 2010, at 3:15 AM, Georg Brandl wrote:
> Am 04.09.2010 12:06, schrieb Antoine Pitrou:
>> On Sat, 04 Sep 2010 11:42:08 +0200
>> Éric Araujo wrote:
It's just a little more overhead, but I think it reads quite a bit better.
>>>
>>> Or we could use pseudo-namespacing: get_phone_
On Sep 7, 2010, at 12:34 PM, Matthew Woodcraft wrote:
> In CPython, the builtin max() and min() have the property that if there
> are items with equal keys, the first item is returned. From a quick look
> at their source, I think this is true for Jython and IronPython too.
>
> However, this isn'
On Sep 15, 2010, at 7:50 AM, Jesse Noller wrote:
>
> +0.5
>
> The one area I have concerns about is the state of WSGI and other
> web-oriented modules. These issues have been brought up by Armin and
> others, but given a lack of a clear path forward (bugs, peps, etc), I
> don't think it's fair t
On Sep 22, 2010, at 7:17 AM, Guido van Rossum wrote:
>
> Where was the decision to revoke privileges discussed? Not on any
> mailing list that I am subscribed to.
It was on IRC.
> Was Mark given an ultimatum?
I sent him a nicely worded email. The tracker privs were set back
to the normal leve
On Sep 22, 2010, at 6:24 PM, R. David Murray wrote:
> On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy wrote:
>
>> deputed tracker authority/ies. Not everyone has the same idea about how
>> to handle the various fields and processes. Who decides in cases of
>> disagreement?
>
> We discussed t
I would like to solicit this group's thoughts on how to reconcile the Set
abstract base class with the API for built-in set objects (see
http://bugs.python.org/issue8743 ). I've been thinking about this issue for a
good while and the RightThingToDo(tm) isn't clear.
Here's the situation:
Binar
On Sep 29, 2010, at 11:29 PM, Terry Reedy wrote:
> I do not understand this. List.__add__ is currently *more* restrictive than
> set ops in that it will not even accept a 'frozenlist' (aka tuple).
Sorry, that should have been __iadd__().
>>> s = range(5)
>>> s += 'abc'
>>> s
[0, 1, 2, 3, 4, 'a'
On Sep 29, 2010, at 11:11 PM, geremy condra wrote:
>>
>> P.S. I also encountered a small difficulty in implementing #2 that would
>> still need to be resolved if that option is chosen.
>
> What's the issue, if you don't mind me asking?
IIRC, just commenting-out the Py_AnySet checks in set_or, s
After rereading http://bugs.python.org/issue9778 , I'm growing concerned
about an impending ABI freeze before the core devs find time to fix the
32-bit hash limitation.
ISTM, the use of 64-bit builds is growing in popularity. It was be a bummer
to have a locked-in an effective size limit for dic
Hello guys. If you don't mind, I would like to hijack your thread :-)
ISTM, that the minmax() idea is really just an optimization request.
A single-pass minmax() is easily coded in simple, pure-python,
so really the discussion is about how to remove the loop overhead
(there isn't much you can do
On Oct 15, 2010, at 10:40 AM, Benjamin Peterson wrote:
> I think the panic is a bit of an overreaction. PEP 384 has still not
> been accepted, and I haven't seen a final decision about freezing the
> ABI in 3.2.
Not sure where the "panic" seems to be.
I just want to make sure the ABI doesn't get
On Oct 26, 2010, at 9:31 AM, Guido van Rossum wrote:
> I would like Gregor Lingl's approval of turning turtle.py into a package. It
> might make some things harder for novices, e.g. trackebacks and just browsing
> the source code.
>
> Also many people don't expect to find any code in a file na
On Oct 26, 2010, at 12:18 PM, Benjamin Peterson wrote:
> 2010/10/26 Alexander Belopolsky :
>> 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, mayb
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
> I've worked on pydoc to make it much nicer to use in a browser.
While you're at it. Can you please modernize the html
and create a style sheet? Right now, all of formatting
is deeply intertwined with content generation.
Fixing that would be a *
On Oct 26, 2010, at 8:37 PM, Barry Warsaw wrote:
> If done well, a split can help improve the readability and discoverability of
> the code.
No doubt that is true. The problem is that splitting can also impair
discoverability.
When unittest was in one file, you knew the filename was unittest
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book).
I think we can improve learnability by focusing on the most
important parts of the API.
I would like to simplify and clean-up the API for the unittest module
by de-doc
On Oct 29, 2010, at 9:11 PM, Michael Foord wrote:
>> Just to clarify. The following fails in Python 3:
>>
>> sorted([3, 1, 2, None])
>>
>> If you want to compare that two iterables containing heterogeneous types
>> have the same members then it is tricky to implement correctly and
>> asser
On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:
>
> I think the issue here is that the file structure of the code no
> longer matches the public API documented by unittest. Personally I,
> like most people it seems, prefer source files to be structured in a
> way to match the public API. In the ca
On Nov 2, 2010, at 3:33 PM, Nick Coghlan wrote:
> On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon wrote:
>> So basically it seems like we have learned a lesson: we prefer to have
>> our code structured in files that match the public API. I think that
>> is a legitimate design rule for the stdlib t
On Nov 2, 2010, at 3: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. What is
On Nov 2, 2010, at 4:00 PM, Brett Cannon wrote:
>> Are we permanently locked into the exact ten filenames
>> that are currently used: utils, suite, loader, case, result, main, signals,
>> etc?
>> Is the file structure now frozen?
>
> Somewhat, yes.
That's a bummer.
Sounds like a decision to sp
Brett, Does the import mechanism for importing packages preserve enough
information to be able to figure-out where all the components are defined? I'm
wondering if it is possible for the class browser to be built-out to
scan/navigate class structure across a module that has been split into a
On Nov 2, 2010, at 4:43 PM, Guido van Rossum wrote:
> The remaining thrust of the thread seems
> to be whether PEP 8 should advise against breaking code up into many
> little modules.
I was thinking of PEP 8 wording that listed the forces for and against.
For example, ply.yacc and ply.lex was
On Nov 8, 2010, at 11:28 AM, Alexander Belopolsky wrote:
> 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/?
Michael's instinct to
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
> I think we need to, as a group, decide how to handle undocumented APIs
> that don't have a leading underscore: they get treated just the same
> as the documented APIs, or are they private regardless and thus we can
> change them at our whim?
To
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 developer docs):
I believe the point of Guido's email was th
On Nov 16, 2010, at 7:05 AM, Paul Moore wrote:
>
> PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also
> seems to be in the release.
>
> Should it not be added to the "What's new in 3.2" document and the
> release announcements? It's a fairly significant feature.
I'll update the w
On Nov 16, 2010, at 7:05 AM, Paul Moore wrote:
>
> PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also
> seems to be in the release.
>
> Should it not be added to the "What's new in 3.2" document and the
> release announcements? It's a fairly significant feature.
I'll update the w
On Nov 21, 2010, at 9:38 AM, R. David Murray wrote:
>
> I'm sorry, but I have to disagree. As a relative unicode ignoramus,
> "UCS-2" and "UCS-4" convey almost no information to me, and the bits I
> have heard about them on this list have only confused me.
>From the users point of view, it doe
On Nov 22, 2010, at 2:48 AM, Stephen J. Turnbull wrote:
> Raymond Hettinger writes:
>
>> Neither UTF-16 nor UCS-2 is exactly correct anyway.
>
> From a standards lawyer point of view, UCS-2 is exactly correct,
You're twisting yourself into definitional knots.
Any ex
On Nov 22, 2010, at 9:41 AM, Terry Reedy wrote:
> On 11/22/2010 5:48 AM, Stephen J. Turnbull wrote:
>
>> I disagree. I do see a problem with "UCS-2", because it fails to tell
>> us that Python implements a large number of features that make it easy
>> to do a very good job of working with non-B
On Nov 23, 2010, at 3:41 PM, Greg Ewing wrote:
> While it may be possible to work around these things with
> sufficient levels of metaclass hackery and black magic, at
> some point one has to consider whether new syntax might
> be the least worst option.
The least worst option is to do nothing a
On Nov 27, 2010, at 12:56 PM, Glenn Linderman wrote:
> On 11/27/2010 2:51 AM, Nick Coghlan wrote:
>>
>> Not quite. I'm suggesting a factory function that works for any value,
>> and derives the parent class from the type of the supplied value.
>
> Nick, thanks for the much better implementation
401 - 500 of 1487 matches
Mail list logo
