>
> On Tue, Mar 2, 2010 at 15:55, Florent Xicluna
> wrote:
> Hello,
>
> I would like to open a discussion on the meaning of deprecation warnings in
> 2.7.
> I assume, but I may be wrong, that 2.7 will be the last version in the 2.x
> branch. With this assumption, we should not find many thin
es not make the comparison, it is okay to punt.
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
On Mar 16, 2010, at 3:16 PM, Greg Ewing wrote:
>
> Seems to me that this education would mostly consist of saying
> "don't compare floats and decimals", which is why I think that
> disallowing them in the first place would be better.
That makes sense.
I do worry that 2.x currently does make the
compare but give the right answer
3) refuse to compare.
Py3.x is already in the best position, it refuses to compare.
IOW, is already is as improved as it can get.
P2.6 is in the worst position. The proposal is to make
it better, but not as good as 3.
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 options from worst to best is
>> 1) compare but give the wrong answer
>> 2) compare but give the right answer
>> 3) refuse to com
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
re and would
be more clearly expressed with an explicit conversion using
Decimal.from_float().
Of course there is a precedent, I can compare "120" < 140 in AWK
and get an automatic implicit conversion ;-)
Just because we can compare, doesn't mean we should.
Raymond
_
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.
provide a warning rather than flat-out disallowing the transaction.
The whole point is to highlight accidental mixing.
If the mixed arithmetic were allowed, then the decimal constructor
should be changed to match (i.e. accept float inputs instead of
requiring Decimal
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
.
In terms of interoperability of concrete types, we're in the fortunate position
that any float can be exactly converted to a Decimal and any Decimal can be
exactly converted to a Fraction.
Raymond
___
Python-Dev mailing list
Pyth
>>
>> 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
floor division is used). If rounded is needed, it
can be controlled explicitly.
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
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
r error.
5) A warning is educational (it makes sure that you understand
what your program is doing)
6). A warning is easily silenced either through a) the warnings module,
b) setting a context flag in decimal, or c) by making the coercion explicit
using Decimal.from_float().
Raymond
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
s completely normal for Decimal so there
are no surprises).
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
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
odule, there is a fundamental notion
that numbers are exact and only the results of operations are
rounded. For example, it is possible in decimal to add together
two high precision numbers but do so in a low precision context.
Raymond
___
Python
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
int(some_float)
or
int(some_decimal)
or
str(some_float)
or
str(some_decimal)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
Fraction(7, 2)
Unlike typical binary floats which use full precision, it is not uncommon
to have decimal floats with only a few digits of precision where the
expression as a fraction is both useful and unsurprising.
Raymond
___
Python-Dev maili
rounding in:
float(Fraction.from_float(some_float) + some_fraction)
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
omparisons [1]
>
The decimal module is already drowning in complexity,
so it would be best to keep it simple: one boolean flag
that if set would warn about any implicit decimal/float
interaction.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
NaNs work great as a way to mark
missing values and to propagate through subsequent calculations.
IMO, their least useful feature is the property of being not equal
to themselves -- that causes more problems than it solves
because it impairs a programmer's ability to reaso
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
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
egration themes of PEP 3141. Any ideas?
Conceptually, it's a bug. The numeric tower treats non-complex
numbers as special cases of complex where the imaginary
component is zero (that's why the non-complex types all support
real/imag), and since complex numbers are not allowed to compa
ng else smells of a Douglas Hofstadter style
or Betrand Russell style logic bomb:
* this sentence is a lie
* this object isn't equal to itself
* this is a set containing sets that are not members of themselves
The property of NaN objects not being equal to themselves
is more harmful tha
> 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/pyt
.
>
> As stated above, such a change would allow us to restore reflexivity
> (eliminating a bunch of weirdness) while still honouring the idea of NaN
> being a set of values rather than a single value.
>
+1
Raymond
___
Python-Dev maili
>>
>> It does suggest a potential compromise, though: a single
>> NaN object compares equal to itself, but different NaN
>> objects are never equal (more or less what dict membership
>> testing does now, but extended to all == comparisons).
>>
>> Whether that'
turn True whenever x and y are
the same NaN object. This is attractive because it is a
minimal change that provides a little protection for
simple containers.
I support either of those options.
Raymond
___
Python-Dev mailing l
ream -- it is also copyable with copy.copy().
The itertools.count() function is also copyable.
Running copy.copy() on other itertools is currently undefined
(though I may add copy support to itertools.repeat() and
the combinatoric functions).
Also, I seems to me the copy.copy() is itself not ver
uses non-string keys) or by running
slower (so that every call can be checked to make sure it
didn't use string keys).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
> 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
ectly if possible,
> rather than going through the slower PyObject_ functions.
>
> Consequently, validating **kwds should be cheap.
>
Good thinking.
That would definitely be better than scanning the full dict on every call.
Raymond
___
Pytho
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
basic heapq approach to making a priority queue not longer works well.
Simply decorating with (priority_level, callable_or_object) fails with two
tasks at the
same priority if the callable or other objects aren't orderable.
Raymond
P.S. I do think it would be great if we could direct s
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 lis
oposals to make existing classes inherit from object.
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
.
Thanks Glyph. That is a nice summary of one kind of challenge facing
programmers.
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-de
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
g classes
as a MutableMapping.
"Fixing" that typo will break code that currently uses ABCs
with old-style classes.
I believe we are better-off leaving this as it was released in 2.6.
Raymond
___
Python-Dev mailing list
Python-
82155.
It is now the same as it was in Py2.6.
Nothing to see here.
Move along.
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
FWIW, I've run in on a Mac and Windows without problems.
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
t; ''
>
> I would have expected str(m) == 'abc'.
That is also my expectation.
A memoryview object is iterable, so str(memviewobj) should return
''.join(memviewobj).
In your example, that would be:
>>> list(m)
['a', 'b', 'c
ul.
I would oppose putting it in the collections module.
But, there's no harm in posting a recipe on ASPN
to see if it gains any traction.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
h generator
> frames, which pdb can't. It would be great to see some of these fixes folded
> back into the standard library version.
>
+1
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
nt decorators), and how to compute the memo
> key from the arguments to the function (the default could be the
> repr() of the argument tuple).
FWIW, this has been a popular caching/memoization recipe:
http://code.activestate.com/recipes/498245-lru-cache-decorator
Raymond
r of digits.
Am curious about your thoughts on the problem we're trying to
solve and the implications of changing the default.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
pr instead.
>
> As you say, it's just one less surprise, and one less thing to
> explain: a small shrinkage of the mental footprint of the language.
Thanks for listing the advantages.
Sounds like it is worth the cost.
It also really calls into question whether there are good
reasons fo
org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186
Nice work.
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
introspect is basic to Python's design.
Objects know their class, functions know their code objects,
bound methods know both their underlying function,
classes know their own class dictionary, etc.
Raymond
___
Python-Dev mailing list
Python
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
s your example shows, property() defeats this intent by actually executing
the code. A better behavior would not run the code at all. It would check
the dictionaries along the MRO but not execute any descriptors associated
with a given key.
IMO, this is a much better solution, more in line w
attr() would ever start raising exceptions.
> I can vouch that the reason hasattr() catches too many exceptions is
> that when I first added it (around 1990, I think :-) I wasn't very
> attuned yet to the problems it could cause.
Fire-up the time machine?
Raymond
P.S. The cu
#x27;s the danger of a dynamic language like Python. Even dir() can
> now trigger things like that.
That's not a honking good thing.
I suggest we don't do more of that.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
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@p
anguages (category killers), towards slow rates of language
evolution, and think about the long-term.
It is better to have one experienced developer decide than to have
a committee.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
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 alrea
simple that it will be trivial for folks to roll their
own variants if they have more exotic needs. After I'm
done with other work for the alpha, I'll take a further
look at the suggestions here.
Raymond
___
Python-Dev mailing list
Pytho
>>>
>>> Or we could use pseudo-namespacing: get_phone_number.cache_hits,
>>> get_phone_number.clear_cache()
>>
>> It looks better indeed.
>
> +1.
Those seem like reasonable names.
Raymond
___
Python-Dev mailing
long time is unlikely to change. Elsewhere, we've made
efforts to document sort stability (i.e. sorted(), heapq.nlargest(),
heapq.nsmallest, merge(), etc).
It is nice that min(it) parallels sorted(it)[0] and nsmallest(1, it).
The same goes for max(it) paralleling sorted(it,reverse=Tru
don't think it's fair to use it as a measurement of overall quality.
Any chance you're going to have time to do work on multiprocessing?
There are a huge number of bugs reports open for that module.
Raymond
___
Python-Dev mai
tunately, he responded with drama and another dev shut-off
his tracker access entirely.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
s to Python and have been our most active
contributors in the last year. They read almost every tracker post,
read every check-in, and continuously monitor the IRC channel.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
27;m not sure and would like additional input so I can get this bug closed
for 3.2. Any thoughts on the subject would be appreciated.
Thanks,
Raymond
P.S. I also encountered a small difficulty in implementing #2 that would still
need to be resolved if that option is chosen.
+= 'abc'
>>> s
[0, 1, 2, 3, 4, 'a', 'b', '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
out the Py_AnySet checks in set_or, set_xor, etc
led to a segfault in TestOnlySetsInBinaryOps in Lib/test/test_set.py.
There was something subtle going on and I haven't had time
to trace though it yet. Somewhere a guard is probably missing.
Raymond
___
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
mpares per item.
my-two-cents,
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
n it does kick-in though
(around 2**32 entries), the degradation is not small, it
is close to catastrophic, making dicts/set unusable
where O(1) lookups become O(n) with a *very* large n.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http:
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
at would be a *huge* improvement.
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
at we all understand that it was not cost free. My hope is
that the splitting modules unnecessarily does not become a trend.
Packages should be the last tool we reach for, not the first.
In many cases, flat is better than nested.
Raymond
P.S. I liked your qualifier, "
eading since they are implemented in terms of
re.search(), not re.match().
Raymond
P.S. I also looked ar assertDictContainsSubset(a,b). It is a bit
over-specialized, but at least it is crystal clear what is does
and it beats the awkward alternative using dict
that the reader understand exactly what is being tested. It's an API fail if a
reader guesses that assertElementsEqual(a,b) means list(a)==list(b); the test
will pass unintentionally.
See:
http://www.phpunit.de/manual/3.4/en/api.html
http://kentbeck.github.com/junit/javadoc/latest/
Raymon
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
e new structure so that the public API matches the file structure
>> when the need arises).
>
> Something to note in PEP 8, perhaps?
I'll propose some PEP 8 wording in the bug tracker
(essentially advice on when and how to use packaging),
an
In the logging module, packaging was done well. The files
fell along natural lines in the API, some of the components
we usable separately and testable separately. Likewise
with the xml packages. In contrast, the unittest module
is full of cross-imports and tightly coupled pieces (like
oved between those files -- once in
unittest.utils, alway in unittest.utils).
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
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
when
there is some clear benefit beyond "turning one big file into lots of smaller
files".
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
pe, or list a package on PyPI.
If you need it to be more visible, we can always give it a mention
in the docs. Though we might want to mention more full featured
tools like Hudson.
Remember, the standard library is where code goes to die ;-)
Raymond
___
e old will be left in-place so that tons of existing code won't
break). Likewise, with the unittest clean-ups, I'm expecting that Michael will
introduce aliases when fixing-up mis-named methods, rather than break code that
uses the existing names.
my-two-cents,
Raymond
___
of Guido's email was that it is a situation dependent
judgment call and not readily boiled down to a set of rules for PEP 8.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
significant feature.
I'll update the whatsnew document before the beta goes out.
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
significant feature.
I'll update the whatsnew document before the beta goes out.
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
401 - 500 of 1495 matches
Mail list logo
