ort everything without regard to whether it makes Py2.6 better.
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
[Barry]
> I'd also like for us to consider doing regular monthly releases.
+1
___
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%40
ut the end of a function).
What do our style mavens think?
-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
[Facundo]
I think that including in the stdlib a threading-like-API module is a
clear win.
I also think this is vital and should not wait for Py2.7.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
ng doesn't benefit a 2.6 user. All it does is add confusion
and it may break code where users or third-party libraries are
already using the new name.
I say leave the new names in 3.0 and let the 2-to-3 tool do its job.
Why confuse the 2.6 landscape with double naming clu
kage.
>
> AFAIR, the discussion on the stdlib-sig also didn't include the
> plan to backport such changes to 2.6. Otherwise, we would have
> hashed them out there.
I think MAL is 100% correct here (and I expect Raymond will chime in to
support him at some point as well).
And until then, a
really
nice incentive to update from Py2.5. It would be a sad
lost opportunity if this module had to wait another couple years.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
ng the API will just make them further apart.
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
happened to the effort to put the 3.0 dict in future_builtins?
That would nicely sync-up the ABC with a concrete implementation
and bring 2.6 a little closer to 3.0.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
se its internals and insist
on objects being registered as one of several supported
abstract types. I suppose this is better than insisting on one
of several concrete types, but it still smells like an anti-pattern.
Raymond
___
Python-Dev mailing list
know in general
whether a flattener wants to split it or not. That is an application
dependent decision. A better answer is be able to tell the
flattener what should be considered atomic in a given circumstance.
Raymond
___
Python-Dev mailing
, then it is the recipe that needs fixing,
not the language.
Raymond
P.S. You're on the right track by factoring the decision
away from the internals of flatten(); however, the atomic()
predicate needs to be user definable for a given application
not hardwired int
e a complex specification.
Including them may make it hard to write a compliant class.
From what's been discussed so far, I don't see any advantage
of isinstance(o, String) over hasattr(o, 'encode') or somesuch.
Raymond
___
Python-D
sing" is just too much of a common word).
This will provide a good short-term answer to those who still clamor
for dropping the GIL.
I'm very happy this is going forward. It's a big win.
Raymond
___
Python-Dev mailing list
Python-Dev@p
If we don't do this, then String won't be the last request. People will want Datetime for example. Pretty much any concrete type
could have a look-a-like that wanted its own ABC and for all client code to switch from testing concrete types.
Raymond
__
ring Integral class is required to implement a number
of arcana including: __rxor__, __rrshift__, __pow__, __invert__,
__index__, and __long__.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
[Raymond]
I propose the following empty abstract classes: String, Datetime, Deque,
and Socket.
[GvR]
Sounds like a mini-PEP is in place. It should focus on the code to
actually define these and the intended ways to use them.
Okay, will run a Google code search to see if real code exists
Target: Py2.6 and Py3.0
Author: Raymond Hettinger
Date: May 31, 2008
Motivation
--
The principal purpose of an abstract base class is to support multiple
implementations of an API; thereby allowing one concrete class to be
substitutable for another. This purpose is defeated when useful
Mini-Pep: An Empty String ABC
Target: Py2.6 and Py3.0
Author: Raymond Hettinger
Proposal
Add a new collections ABC specified as:
class String(Sequence):
pass
Motivation
--
Having an ABC for strings allows string look-alike classes to declare
themselves as
t as what is included are the methods intentionally left out. I'm trying to avoid insisting on abstractmethods like
encode(), split(), join(), and other methods that place an undue burden on a class being registered as a String.
Raymond
_
d the same applies to __contains__().
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
* The API will become PEP 8 compliant
Doesn't that kill the intent that it's a drop-in replacement for
threading?
IMO, it is essential that the API match the theading module, PEP 8 be damned.
Raymond
___
Python-Dev mailing list
almost parallel but spelled
differently is at odds with that goal.
Moving both modules to PEP 8 compliance makes more
sense, but I would hope that gets left for Py3.0. There's
too much existing code, too many existing tutorials, and
too many hardcopy books already in Py2.x.
Raymond
- Ori
2.6 that façade the
2.6 API with the PEP 8 API.
+0
PEP 8 is nice but it's not that important.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
The only comment so far was to keep the __index__ method.
Other than that, is this good to go?
Raymond
- Original Message -
Target: Py2.6 and Py3.0
Author: Raymond Hettinger
Date: May 31, 2008
Motivation
--
The principal purpose of an abstract base class is to support
except that numpy is t
he only known use case.
Hopefully, some discussion gets generated. But if no one cares,
I'll happily drop it.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
me too. But, it may be one of those things that you
quickly get used to.
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
s to go forward with a Binary subclass of Integral,
then I would like to withdraw this simplification mini-pep. Better
to stick with what we have now than to addcomplexity to a module
that is already use case challenged.
Raymond
___
Python-Dev mailing
numbers.py:
@property
def imag(self):
"""Real numbers have no imaginary component."""
return 0
@property
def denominator(self):
"""Integers have a denominator of 1."""
return 1
Raymond
-
re may be some design nuance that I'm not seeing.
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
Still, I don't think this should be done. Flat is better than nested,
and adding hierarchy will make it *more* difficult to find anything
(except perhaps for the one person who did the rearrangement).
Yes. Grep is your friend.
Raymond
___
P
difficult to remember
what is returned by locals() or globals().
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/arch
setdefault->set_default, popitem->pop_item,
splitlines->split_lines etc.)
Perhaps underscores should only be used when the contracted form lacks clarity.
Food for thought,
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Nick> def getName(self):
Nick> assert self.__initialized, "Thread.__init__() not called"
Nick> return self.__name
Why is __name private to begin with? Any reason for the getters and setters?
Why isn't this just
of Integral. So, when evaluating r&s, Integral.__and__()
only checks that r is not an instance of S, int or long, and it
erroneously returns NotImplemented , leaving s.__rand__() to take over.
What do you guys think?
Raymond
___
Python-D
ecific semantics of the API.
This would no doubt be compounded by attempts to emulate
dict views. Regardless, there should probably be a PEP and
alternate pure python versions should be posted on ASPN so people
can try them out.
post
Raymond
___
y the matches everyone's intuition, use cases,
and expectations.
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
was proposed on python-dev
and improved again based on feedback received there. Upon writing
the docs and creating examples, more refinements ensued. Upon applying
it to the standard library, more was learned. After the alpha, we started
getting user feedback and it got refined even fu
azardous undertaking.
Dynamic analysis takes into account which codes tend to
occur more often inside loops but it is *very* sensitive
to who wrote the app and their coding style. These results
always have to be taken with a grain of salt.
Raymond
___
Py
We're still working on the implementation details for math.sum().
When it's finished, the cmath equilvalent will be added.
Raymond
- Original Message -
From: "A.M. Kuchling" <[EMAIL PROTECTED]>
To:
Sent: Thursday, June 19, 2008 7:16 PM
Subject: [Python-Dev
el free to change the implementation details however you like as long as the basic functionality stays the same. To support
non-float floating point types, replace the float check with isinstance(v, real). The rest of PyNumber_ToBase looks fine to me
since it supports anything with an __inde
Issue 3008 has been re-opened for more commentary.
Raymond
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
Since it's (potentially) a pretty small feature I might be convinced
to accept it in beta2, but I don't want the fact that it was c
d __hex__.
Done.
* Guido requested that the docs be updated. Done.
* Guido requested that the globally visible C API function name be prefixed
with _Py. Done.
* Mark Dickinson requested normalizing output to start with a 1 so that nearby
values have similar reprs. Done.
Raymond
have struct.pack for machine-parseable output.
This is supposed to be human readable as well as providing
an exact, platform indepent way of specifying a particular
float value (something that's useful in testing algorithms like that in
math.sum()).
Raymond
ions in the math module. To convert a number to binary, it makes sense to use the bin() function. I
don't understand this notion that bin() is a sacred cow of intergerdom and would philosophically corrupt if it handled floats also.
Raymond
__
From: "Guido van Rossum" <[EMAIL PROTECTED]>
So as far as the feature design goes, I offer some suggestions: a new
module; or a new function in math; or a new method on float. Since
Raymond is the champion for the feature let him choose the API from
those alternatives.
I ch
l
notation -- i.e. bin(125E-100) would have a heckofa lot
of leading zeroes. Terry and Mark also pointed-out that
the hex with exponential notation was the normal notation
used in papers on floating point arithmetic. Lastly, once I
changed over to the new way, it dramatically simplified t
[Mark Dickinson]
I have to admit that I can't see much use for octal floats.
Neither do I. They look weird to me.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ISTM, that the currently proposed output format gives
us this benefit for free (no changes to the parser).
The format is already close to the C99 notation
but replaces the 'p' with '* 2.0 **' which I find to
be both readable and se
r, and
- the exponent doesn't vary with changes to the least significant bits
of the float.
Is everyone agreed on a tohex/fromhex pair using the C99 notation as
recommended in 754R?
Are you thinking of math module functions or as a method and classme
allow the code to be more thoroughly exercised.
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
From: "Mark Dickinson" <[EMAIL PROTECTED]>
Does anyone have time to review the patch
http://bugs.python.org/file10876/hex_float5.patch
for issue 3008 (float <-> hexadecimal string conversion):
I'll look at it to
ffort needs to be extended to our own unittest suite. But the rest of the library could likely
benefit from a good -3 cleanup.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
changes in 2.6 and 3.0, I would think
that it is dangerous to make any changes at all to the unittest API.
That module is the one anchor in a sea of change.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
asily this could be done:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/572194
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 being said, I think there are less magical, much simpler
ways to implement it. I think Holger is working on it as we speak.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
tests need to be absolutely stable if they are to serve as a transition tool
(providing a baseline the 3.0/3.1 is expected to match).
Also, are there any expected benefits from making this change in 2.7? What
will the module do differently?
It seems like a risky change for zero-benefit.
Raymo
It looks like Benjamin Peterson is right, in Python 2.5 TestCase already
appears to be a new style class:
Yep. I stand corrected. It looks like that changed five years ago (rev 28064). Not sure how that slipped through but it doesn't
seem to have caused any problems.
Ra
nd almost
never comes up in the context of solving a real problem that
hasn't already be addressed in some other way.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
125
And: http://bugs.python.org/issue2156
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 methods that
improve my life. Don't give me thirty ways to spell something I can
already 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
hat's more like it.Propose more cool stuff like this and
the module really will be improved.
assertIs / assertIsNot also sounds good, but is not something I would
miss if they weren't added.
Doh! We're back to replacing clean expressions using pure python syn
h
(unless the camel's nose refers to camelcase).
You could always just fork the unittest module and see if
the masses flock to your version. That way at least people
will have a choice about whether to accept these new design proclivities.
Raymond
_
doing it after the release. It's unlikely to be exercised
much by the beta users so there's no real advantage. If you wait
until afterwards, then there is time to let the buildbots have a go
at it and reveal any cross-platform issues.
Besides, Barry said something
ter fix is to amend to doctests to not rely on the __repr__ format.
Instead of:
>>> Decimal('7.1')
Decimal("7.1")
use:
>>> print Decimal('7.1')
7.1
Raymond
___
Python-Dev mailing list
Python-Dev
'b' : '1011',
'c' : '1100', 'd' : '1101', 'e' : '1110', 'f' : ''}
hex_pattern = '(\-)?0x([0-9a-f]+)\.([0-9a-f]*)(.*)'
sign, intpart, fracpart, exp = re.search(hex_pat
conversations
that were held for PEP 225:
http://www.python.org/dev/peps/pep-0225/
That PEP is marked as deferred. Maybe it's time to
bring it back to life.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
ne another
(no overlapping method names).
Lest I sound negative, let me thank you again for the blog entries
and for compiling the most complete discussion of it in one place.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
[Raymond]
Cooperative multiple inheritance is *not* about mixing two unrelated
parents that just happen to use the same method name but have
different semantics and were not designed to cooperate with each other.
The A-B-C-D diagrams and foo/bar methods in the examples are
deceptive because
ld change as the
iterator got consumed. Later, it was decided
that iterators should not report length and should
instead report a length hint. It looks like listreversediterator
got missed when this was changed.
Raymond
___
Python-Dev mailing list
Python-Dev
al, so that when people *do*
run in to difficulties there is a very clear, central explanation of
what it's supposed to do.
Am working on a doc patch, will post this weekend.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
-lifing it" which I took to mean deprecate rather than
remove during a release candidate.
Raymond
- Original Message -
From: "Benjamin Peterson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 03, 2008 4:32 PM
Subject: [issue376
[Barry]
I'm not going to release rc1 tonight.
Can I go ahead with some bug fixes and doc improvements
or should I wait until after Friday?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
Not credible, not widely discussed, not tested in a beta ...
No alternative provided, no deprecation period before it disappears ...
The usual deliberative process has been completely bypassed.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http:
ss on Windows builds.
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
then automatically porting updates
to the Py3Pi website.
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
urity release for 2.5, it will be clean and easy.
The 2.6/3.0 development process was so disruptive that I doubt
that 2.5 received adequate attention for bug fixes. Why not wait
two or three months for the dust to settle?
Raymond
___
Python-Dev ma
[A.M. Kuchling]
Can you please clarify your meaning? Do you mean that
* we haven't been backporting fixes to 2.5?
Unsure. I surely have given zero attention to 2.5.
* we should wait to see if any horrible problems are reported in 2.6?
Yes. That would be a great idea.
* we need to look
user will stress
it in new ways and perhaps reveal a bunch of little integration issues
and documentation issues. Those little fixups way go a long way toward
establishing a good first impression and reputation for 3.0 from the outset.
Raymond
___
Background
--
In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those
equivalents are only approximate but they seem to have greatly enhanced the docs. Something similar is in the builtin docs for
any() and all(). The ne
cable string in a more natural way (it bites to write C style docstrings using \n
and trailing backslashes). The best part is that people without C compilers can still submit patches to the text files.
Raymond
___
Python-Dev mailing list
Python-Dev@pytho
Yes, I'm looking a couple of different approaches to loading the strings.
For now though, I want to focus on the idea itself, not the implementation.
The important thing is to gather widespread support before getting into
the details of how the strings get loaded.
Raymond
- Ori
Raymond Hettinger wrote:
* It will assist pypy style projects and other python implementations
when they have to build equivalents to CPython.
* Will eliminate confusion about what functions were exactly intended to
do.
* Will confer benefits similar to test driven development where the
is one difference; since the new attribute is guaranteed to be
executable, it can be reliably run through doctest. The same is *not* true
for arbitrary docstrings.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
h just two inputs.
We don't want to slow that down in order to provide negligible
improvements to min/max for long sequences.
Raymond
- Original Message -
From: "Kristján Valur Jónsson" <[EMAIL PROTECTED]>
To: "Antoine Pitrou" <[EMAIL PROTECTED]>;
Se
From: "Guido van Rossum" <[EMAIL PROTECTED]>
The right thing to do with XXX comments is to read them when you're in
their vicinity, and to act when the urge becomes too strong to deal
with any one in particular. Dealing with them en masse is just asking
for a migraine.
In concur that it is not a regression (esp for Py2.6).
OTOH, it would be nice to have -m run as expected.
It seems reasonable to me to get this working for 3.0.
Raymond
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To: "Lisandro Dalcin&qu
t;. Is that what we want?
ISTM, 3.0 is in pretty good shape. There is nothing intrinsically wrong
with it. The number one adoption issue is external, i.e. how quickly
key third-party modules get converted.
Raymond
___
Python-Dev mailing
From: "A.M. Kuchling" <[EMAIL PROTECTED]>
Perhaps the statement could say something like "we do not expect
most Python packages will be ported to the 3.x series until
around the time 3.1 is released in X months." (where X=12? 6?)
I would leave out any discussion of 3.1. Its content and rele
2008/12/4 Raymond Hettinger <[EMAIL PROTECTED]>:
Also, we don't know the timing of the third-party updates.
Some may never get converted. Some may convert quickly
and easily. Someone (perhaps me) may organize a series of
funded sprints to get many of the major packages converted.
BTW, 3.0 went out the door with test_binascii failing on windows.
Was surprised that some buildbot wasn't complaining.
- Original Message -
From: "Antoine Pitrou" <[EMAIL PROTECTED]>
To:
Sent: Saturday, December 06, 2008 3:15 PM
Subject: [Python-Dev] Buildbots for 2.6 and 3.0
Hello
Strong +1
Are the RMs on board?
- Original Message -
From: "Benjamin Peterson" <[EMAIL PROTECTED]>
To:
Sent: Saturday, December 06, 2008 3:18 PM
Subject: [Python-Dev] 3.0.1 possibilities
Since the release of 3.0, several critical issues have come to our
attention. Namely, the built
using the svn.
Based on the work I've seen so far, my preference is that you continue to use
the
tracker instead of directly committing patches.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
Does anyone here have access to Mathematica?
I would like to know what it returns for:
In[1]:= Permutations({a, b, c}, {5})
Knowing this will help resolve a feature request
for itertools.permutations() and friends.
Thanks,
Raymond
___
Python-Dev
From: "M.-A. Lemburg"
The question to put up against this is: How often do you get
irritated by lines not being correctly indented ?
Basically never.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
that we have
simpler, faster calling code at the expense of being able
to raise a SystemError in every possible piece of code.
Raymond
From: "Guido van Rossum"
There seems to be an unconditional PyErr_Clear() in
_PyObject_LengthHint(). I think that could and should be much m
t has the potential of masking errors, and thus I'd like to see it fixed.
No problem. I'll take care of this one. Since it's an internal API,
it should be easy.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
choice to make their disadvantage a self-fulfilling prophecy.
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
dules)?
Does the copyright concept even apply to an
abstract base class (I thought APIs were not
subject to copyright, just like database layouts
and language definitions)?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
From: "Brett Cannon"
1. Why is three space indents the preferred indentation level?
I've also wondered about this. It is somewhat incovenient
when bringing in code samples from files with four space indents.
Raymond
___
Python-D
801 - 900 of 1495 matches
Mail list logo
