So, apart from compatibility purposes, what is the
point currently of *not* directly subclassing str?
To provide your own storage format, such as a views into existing data.
Whether or not this is actually practical is a different question;
plenty C code tends to assume it can use the
Greg Ewing schrieb:
Nick Coghlan wrote:
Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
{num} occurs {num} times in this format string.format(dict(num=2))
If named arguments were to become mandatory, I'd want
to
On 06/06/2008, Georg Brandl [EMAIL PROTECTED] wrote:
Greg Ewing schrieb:
Paul Moore wrote:
Because the second breaks if value is a tuple:
However, changing it now is going to break a huge
amount of existing code that uses %-formatting,
and in ways that 2to3 can't reliably fix.
Hi,
PEP 361 lists the following modules for possible inclusion in 2.6 (next
to pyprocessing, which is now accepted):
- winerror
http://python.org/sf/1505257
(Owner: MAL)
This patch has been marked as rejected, so I'll remove the entry from
the PEP.
- setuptools
BDFL pronouncement for
Greg Ewing schrieb:
Paul Moore wrote:
Because the second breaks if value is a tuple:
However, changing it now is going to break a huge
amount of existing code that uses %-formatting,
and in ways that 2to3 can't reliably fix.
Keeping %-formatting but breaking a large
proportion of its uses
On 2008-06-03 01:29, Gregory P. Smith wrote:
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
...
Should we read this as a
On 2008-06-06 13:27, Georg Brandl wrote:
Hi,
PEP 361 lists the following modules for possible inclusion in 2.6 (next
to pyprocessing, which is now accepted):
- winerror
http://python.org/sf/1505257
(Owner: MAL)
This patch has been marked as rejected, so I'll remove the entry from
the PEP.
Nick Coghlan wrote:
Greg Ewing wrote:
Nick Coghlan wrote:
- remove support for passing a single value to a format string
without wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
Note the part of the
2008/6/6 Georg Brandl [EMAIL PROTECTED]:
Hi,
PEP 361 lists the following modules for possible inclusion in 2.6 (next
to pyprocessing, which is now accepted):
- winerror
http://python.org/sf/1505257
(Owner: MAL)
This patch has been marked as rejected, so I'll remove the entry from
the
On Thu, Jun 5, 2008 at 10:08 PM, Jesse Noller [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 10:06 PM, Nick Coghlan [EMAIL PROTECTED] wrote:
Jesse Noller wrote:
I meant a cleaned version of the PEP - I still have docs and tests to redo
It would also be good if you could check Benjamin's
+1
On 6/6/08, Steve Holden [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Greg Ewing wrote:
Nick Coghlan wrote:
- remove support for passing a single value to a format string
without wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you
ACTIVITY SUMMARY (05/30/08 - 06/06/08)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1895 open (+28) / 12981 closed (+15) / 14876 total (+43)
Open issues with patches: 575
On Thu, Jun 5, 2008 at 8:19 PM, Jim Jewett [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I consider multiprocessing a new API -- while it bears
a superficial resemblance with the threading API the
similarities are just that, and it should not be
constrained by mistakes in that API.
The
On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Does anyone actually need an int lookalike with binary methods but
cannot just inherit from int?
Does anyone actually need an int lookalike with operations like +, -
etc. but cannot just inherit from int? If the answer
2008/6/6 Guido van Rossum [EMAIL PROTECTED]:
On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Does anyone actually need an int lookalike with binary methods but
cannot just inherit from int?
Does anyone actually need an int lookalike with operations like +, -
etc.
On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Does anyone actually need an int lookalike with binary methods but
cannot just inherit from int?
Does anyone actually need an int lookalike
On Thu, 5 Jun 2008, Benjamin Peterson wrote:
- reorganizing the tests into separate directories
Why this one?
John
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Fri, Jun 6, 2008 at 2:12 PM, John J Lee [EMAIL PROTECTED] wrote:
On Thu, 5 Jun 2008, Benjamin Peterson wrote:
- reorganizing the tests into separate directories
Why this one?
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping
Hi all,
PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the
fourth clause of the proposed resolutions to concerns:
The reflexivity rules *are* assumed by Python. Thus, the interpreter
may swap yx with xy, y=x with x=y, and may swap the arguments of
x==y and x!=y.
However,
On Fri, Jun 6, 2008 at 11:40 AM, Alex Martelli [EMAIL PROTECTED] wrote:
On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Does anyone actually need an int lookalike with binary methods but
On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow [EMAIL PROTECTED] wrote:
PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the fourth
clause of the proposed resolutions to concerns:
The reflexivity rules *are* assumed by Python. Thus, the interpreter may
swap yx with xy, y=x with
In data 06 giugno 2008 alle ore 20:40:01, Alex Martelli [EMAIL PROTECTED] ha
scritto:
On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Does anyone actually need an int lookalike with binary
New idea! I missed an obvious solution. Let the binary methods in Integral be mixins instead of abstract methods. That minimizes
the burden on the class implementer while providing maximum support for clients.
class Integral(Rational):
...
def __lshift__(self, other):
self other
On Jun 6, 2008, at 3:24 PM, Guido van Rossum wrote:
On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow
[EMAIL PROTECTED] wrote:
PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the
fourth
clause of the proposed resolutions to concerns:
The reflexivity rules *are* assumed by Python.
Make that int() instead of long() and I'm okay with it.
On Fri, Jun 6, 2008 at 1:33 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
New idea! I missed an obvious solution. Let the binary methods in Integral
be mixins instead of abstract methods. That minimizes the burden on the
class
From: Guido van Rossum [EMAIL PROTECTED]
Make that int() instead of long() and I'm okay with it.
Does anyone know why Integral says that __long__ is a required abstract method,
but not __int__?
Likewise, why is index() defined as long(self) instead of int(self)?
There may be some design
I created an issue 1 week ago (http://bugs.python.org/issue2983)
suggesting the addition of the ttk module to lib-tk, and to the new
tkinter package. Is there any chance to this be accepted for Python
2.6 ?
Is it complete? In principle, it's for the mentor to decide (who
would need to decide
- reorganizing the tests into separate directories
Why this one?
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping tests by function will
hopefully help reduce duplication and it more intuitive.
Still, I don't think this
2008/6/6 Martin v. Löwis [EMAIL PROTECTED]:
I created an issue 1 week ago (http://bugs.python.org/issue2983)
suggesting the addition of the ttk module to lib-tk, and to the new
tkinter package. Is there any chance to this be accepted for Python
2.6 ?
Is it complete? In principle, it's for
Hi All,
I'm a new developer with Python. I have a solid knowledge of both Python and C.
Are there any tasks that would be suitable for a beginner to the Python
codebase? I haven't been able to find a list of such tasks on python.org or
bugs.python.org.
Thanks,
James Thomas
--- On Fri, 6/6/08,
2008/6/6 James Thomas [EMAIL PROTECTED]:
Hi All,
I'm a new developer with Python. I have a solid knowledge of both Python and
C. Are there any tasks that would be suitable for a beginner to the Python
codebase? I haven't been able to find a list of such tasks on python.org or
Both of these seem 2.6-specific quirks. Those lines wereJeffrey's;
maybe he remembers? I'm guessing that adding __long__ was done since
2.6 supports it, and the removal of __int__ was an oversight. I also
think that there's no reason to change __index__ to call long(); int()
will automatically
Martin v. Löwis wrote:
- reorganizing the tests into separate directories
Why this one?
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping tests by function will
hopefully help reduce duplication and it more intuitive.
Still, I
On Fri, Jun 6, 2008 at 5:51 PM, Eric Smith
[EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping tests by function will
hopefully help reduce duplication and it more intuitive.
Still,
Benjamin Peterson wrote:
On Fri, Jun 6, 2008 at 5:51 PM, Eric Smith
[EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping tests by function will
hopefully help reduce duplication and it
2008/6/6 Benjamin Peterson [EMAIL PROTECTED]:
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping tests by function will
hopefully help reduce duplication and it more intuitive.
Intuitive to who taking into account which grouping?
On Jun 6, 2008, at 6:52 PM, Benjamin Peterson [EMAIL PROTECTED]
wrote:
On Fri, Jun 6, 2008 at 5:51 PM, Eric Smith
[EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
I always find it hard to find a test I'm looking for in a directory
with 365 different tests in it. Also grouping tests by
How does 1 directory scale when one day you have possibly thousands of
tests?
On Jun 6, 2008, at 6:58 PM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/6/6 Benjamin Peterson [EMAIL PROTECTED]:
I always find it hard to find a test I'm looking for in a directory
with 365 different tests
Really? Given the choice between core_language (divided into syntax
and builtins) and stdlib you wouldn't know where to look?
Exactly so. I would not normally guess that the builtins belong to
the core language - they belong to the stdlib, IMO. core language
is just syntax to me, perhaps plus
How does 1 directory scale when one day you have possibly thousands of
tests?
I find this a theoretical question. It took 18 years to arrive at 500
test files. Assuming a linear growth, we get 1000 tests in 2025, and
2000 tests in 2060. People can worry about reorganizing them then.
Regards,
Martin v. Löwis wrote:
How does 1 directory scale when one day you have possibly thousands of
tests?
I find this a theoretical question. It took 18 years to arrive at 500
test files. Assuming a linear growth, we get 1000 tests in 2025, and
2000 tests in 2060. People can worry about
2008/6/6 Ron Adam [EMAIL PROTECTED]:
Martin v. Löwis wrote:
How does 1 directory scale when one day you have possibly thousands of
tests?
I find this a theoretical question. It took 18 years to arrive at 500
test files. Assuming a linear growth, we get 1000 tests in 2025, and
2000 tests
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
___
On Sat, 7 Jun 2008 07:32:40 am Martin v. Löwis wrote:
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).
Do you have a filing cabinet with everything filed under F for File?
*wink*
Well, it seems like Integral instances should be able to be passed to
either int() or long(), so __long__ should probably stay. I have no
idea why I didn't include __int__, but its absence was probably the
only reason __index__ calls long() instead of int().
On Fri, Jun 6, 2008 at 3:23 PM, Guido
On Sat, 7 Jun 2008 08:58:06 am Eric Smith wrote:
Really? Given the choice between core_language (divided into syntax
and builtins) and stdlib you wouldn't know where to look?
Really. I wouldn't bother thinking about it. I'd just grep.
Since you'll do the same thing regardless of whether
On 07Jun2008 13:24, Steven D'Aprano [EMAIL PROTECTED] wrote:
| On Sat, 7 Jun 2008 07:32:40 am Martin v. Löwis wrote:
| 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).
|
| Do you
Can anyone give me an idea as to where the function uname is located in os? I
am unable to find it explicitly defined within the os.py file in the current
svn repository. I also need to know how a call to os.uname() interacts with
platform.uname(). I apologize if there is an obvious answer to
48 matches
Mail list logo
