Right now, test_py3kwarn only runs if the test suite is run using the
-3 command line flag to Python. So for most regrtest runs (e.g. the
buildbots) this test will never be run.
It would be nice to be able to turn the flag on from Python (e.g.
within test_py3kwarn). Is that possible? Here's
On Wed, Mar 19, 2008 at 5:51 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
This flag is exposed to python code as sys.flags.py3k_warning
So the hack added to some of the test code that I saw go by on
python-checkins isn't needed :)
Excellent. I asked around at the sprints and everyone thought
On Tue, Mar 4, 2008 at 5:10 PM, Steve Holden [EMAIL PROTECTED] wrote:
Christian Heimes wrote:
Bob Kline wrote:
Any possibility of revisiting this question (upgrading to a more recent
compiler for Windows builds of Python)?
The latest alphas of Python 2.6 and 3.0 are build with VS
On Jan 25, 2008 9:13 AM, Jameson Chema Quinn [EMAIL PROTECTED] wrote:
I'm writing a source code editor that translates identifiers and keywords
on-screen into a different natural language. This tool will do no
transformations except at the reversible word level. There is one simple,
avoidable
On Jan 22, 2008 5:40 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Daniel Stutzbach]
There are many places in the C implementation where a slot
returns an int rather than a PyObject. There other replies
in this thread seem to support altering the signature of the
slot to return a
On Jan 6, 2008 8:33 AM, Christian Heimes [EMAIL PROTECTED] wrote:
* PJE: Does pkg_resource have an easy way to overwrite a package in a
name space package? E.g. an user wants to overwrite Python's
databases.sqlite with a newer version of sqlite. Can he simply do it by
inserting a package into
On Jan 6, 2008 11:34 AM, Christian Heimes [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
Do we really want to encourage this? Wouldn't that just introduce
more pyxml-like nightmares? I've been bitten way too many times by
pyxml overwriting the regular xml package and causing version
On Jan 6, 2008 1:07 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote:
Maybe the situation is different here, but having someone installing a
different version of sqlite behind my back makes me nervous.
Er, someone who? Behind whose back? I'm quite
On Nov 30, 2007 4:40 PM, Oleg Broytmann [EMAIL PROTECTED] wrote:
On Fri, Nov 30, 2007 at 03:05:18PM -0800, Guido van Rossum wrote:
On Nov 30, 2007 2:17 PM, Nicko van Someren [EMAIL PROTECTED] wrote:
+1 for __universal__
It's almost as if nobody has seen my proposal to leave __builtins__
On Nov 28, 2007 2:23 PM, [EMAIL PROTECTED] wrote:
Sorry if this is a dumb question, but are there actually good reasons to
remove types?
IMHO the types module helps keeping code readable.
For example
if type(obj) == FloatType
is just more readable than
if type(obj) == type(1.0).
But you
On Nov 28, 2007 10:11 PM, Ron Adam [EMAIL PROTECTED] wrote:
Keeping __root__ relatively short has the benefit of being able to easily
use __root__.name in the case where name was/is used in the local
scope. I don't see any reason to make it harder. There might even be a
use case for using
On Nov 21, 2007 4:33 PM, Michael Foord [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I'm asking a Py3k question on python-dev because I'd like to have
opinions from people who haven't thought about Py3k much yet. Consider
the following example:
class C:
def foo(self): pass
On Nov 14, 2007 1:18 PM, Brett Cannon [EMAIL PROTECTED] wrote:
On Nov 14, 2007 10:30 AM, Isaac Morland [EMAIL PROTECTED] wrote:
So I wrote a Signature class. Instances of the class represent all the
information present between the parentheses of a procedure definition.
Properties are
On Nov 10, 2007 11:31 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
Unless I get negative feedback really soon I plan to submit this later
today. I've tweaked the patch slightly to be smarter about replacing
the setter and the deleter together if they are the same object.
Definitely +1 on the
On 10/31/07, Fred Drake [EMAIL PROTECTED] wrote:
If I had to choose built-in names, though, I'd prefer property,
propset, propdel. Another possibility that seems reasonable
(perhaps a bit better) would be:
class Thing(object):
@property
def attribute(self):
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the
same platform).
2. Intentially put there by a programmer. If s/he also chooses
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
On 9/29/07, Michael Foord [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
There are two normal ways for internal Python text to have \r\n:
1. Read from a file with \r\r\n. Then \r\r\n is correct output
On 9/20/07, Alexander Neundorf [EMAIL PROTECTED] wrote:
On Thursday 30 August 2007 16:28, Alexander Neundorf wrote:
...
The cmake files for building python are now in a cvs repository:
http://www.cmake.org/cgi-bin/viewcvs.cgi/Utilities/CMakeBuildForPython/?roo
t=ParaView3
Thanks for your
On 7/10/07, Christian Heimes [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Please help!
I've made a meta patch that makes debugging the bugs a lot easier. It
replaces assert_(foo == bar) and failUnless(foo == bar) with
failUnlessEqual(foo, bar). failUnlessEqual shows the value of foo and
On 7/8/07, Kevin Jacobs [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Also vaguely apropos:
def ilen(seq):
'Return the length of the hopefully finite sequence'
n = 0
for x in seq:
n += 1
return n
Also known as::
sum(1 for _ in iterable)
That's always been simple enough
On 6/9/07, Eyal Lotem [EMAIL PROTECTED] wrote:
I believe that this should be changed, so that Python first looks for
the attribute in the instance's dict and only then through the dict's
mro.
[snip]
What do you think?
Are you suggesting that the following code should print 43 instead of 42?
On 6/10/07, Steven Bethard [EMAIL PROTECTED] wrote:
On 6/9/07, Eyal Lotem [EMAIL PROTECTED] wrote:
I believe that this should be changed, so that Python first looks for
the attribute in the instance's dict and only then through the dict's
mro.
Are you suggesting that the following
On 6/4/07, BJörn Lindqvist [EMAIL PROTECTED] wrote:
The threading module contains buggy code:
class Thread(_Verbose):
...
def start(self):
assert self.__initialized, Thread.__init__() not called
assert not self.__started, thread already started
...
If you run
On 5/23/07, Georg Brandl [EMAIL PROTECTED] wrote:
Also, try
http://pydoc.gbrandl.de:3000/os.path.exists
Beautiful!
STeVe
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
On 5/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
One comment I have, I don't know if it's relevant - it perhaps
depends on whether the Global Module Index is auto-generated or
not. This is the page I visit the most out of all the Python
documentation, and it's far
On 5/19/07, Martin Blais [EMAIL PROTECTED] wrote:
I haven't looked at it in depth yet, but I have a question. One
concern from a long thread on Doc-Sig a long time ago, is that ReST
did not at the time possess the ability to nicely markup the objects
as LaTeX macros do. Is your
On 5/5/07, M.-A. Lemburg [EMAIL PROTECTED] wrote:
On 2007-05-04 19:51, Guido van Rossum wrote:
[-python-dev]
On 5/4/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Friday 04 May 2007, M.-A. Lemburg wrote:
I also suggest making all bytes literals immutable to avoid running
into
On 5/5/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
In general, I don't think it's a good idea to have literals
turn into mutable objects, since literals are normally perceived
as being constant.
Does that mean you want list literals to be immutable too?
lst = ['a', 'b', 'c']
On 5/2/07, Michael Foord [EMAIL PROTECTED] wrote:
Implicit string concatenation is massively useful for creating long
strings in a readable way though:
call_something(first part\n
second line\n
third line\n)
I find it an elegant
On 4/24/07, Calvin Spealman [EMAIL PROTECTED] wrote:
So, the question I pose is how would everyone like to see this
resolved? As I see it, there are two things I can do. I can either
summaries each list separately, and try to sort out the cross overs.
Or, I can start pulling in all three
A summary response to the issues raised so far...
On what the name should be:
* Adam Olsen - countunique(), countdistinct(), countduplicates()
* Greg Ewing - counteach(), countall()
* Kevin Jacobs - tally()
* Guido - counts() is fine
So I guess I'll stick with counts().
On whether the count of a
Alex Martelli wrote:
Steven Bethard [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
If we had a turn sequence into bag function somewhere
(and it might be worth having it for other reasons):
def bagit(seq):
import collections
d = collections.defaultdict(int)
for x
On 4/3/07, Christian Heimes [EMAIL PROTECTED] wrote:
I'd be willing to look at adding it, if the group thinks it's the right
thing to do.
I like the idea and I'm proposing to add two more methods to subprocess
Popen.
class Popen(...):
...
def signal(self, signal):
Send
On 3/23/07, Hrvoje Nikšić [EMAIL PROTECTED] wrote:
On Thu, 2007-03-22 at 13:38 -0700, Guido van Rossum wrote:
Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
the popen2 module at all, and do everything via the subprocess module.
I wonder if we should even get rid of
On 3/21/07, Facundo Batista [EMAIL PROTECTED] wrote:
So, as a resume of the choices we still need to settle:
a) Repeat the same functionality in 5 other libraries
b) Write the function in socket.py, public
c) Write the function in socket.py, non public
The fact that it's needed in 5
On 3/20/07, Facundo Batista [EMAIL PROTECTED] wrote:
So, I have two modifications to make to the patch:
- change the name to create_connection
- make timeout obligatory named
Is everybody ok with this?
FWLIW, +1. It was not immediately apparent to me that the third argument in::
On 3/10/07, Jon Ribbens [EMAIL PROTECTED] wrote:
I see you snipped without response my request to back up your claim
that assuming that a date() is a datetime() with a time of midnight
will clearly break that logic.
Am I to assume you cannot back it up?
I was trying to minimize the extent of
On 3/11/07, Christian Heimes [EMAIL PROTECTED] wrote:
Jon Ribbens schrieb:
I see you snipped without response my request to back up your claim
that assuming that a date() is a datetime() with a time of midnight
will clearly break that logic.
I've another idea. Date and datetime objects
On 3/11/07, BJörn Lindqvist [EMAIL PROTECTED] wrote:
I do not really understand proper temporal intervals. But I am
interested what temporal interval logic has to say about this
problem:
def get_most_recent_articles(articles, cutoff_date):
recent_articles = []
for article in
On 3/10/07, Jon Ribbens [EMAIL PROTECTED] wrote:
Steven Bethard [EMAIL PROTECTED] wrote:
Using the .date() is fine when the year/month/day doesn't match. So
the following are fine::
datetime.datetime(2005, 1, 1, 0, 0, 0) datetime.date(2006, 1, 1)
datetime.datetime(2007, 1, 1, 0
On 3/10/07, Jon Ribbens [EMAIL PROTECTED] wrote:
Steven Bethard [EMAIL PROTECTED] wrote:
I still don't see why my more careful comparison would be bad for any
of your code. Could you give an example where it would be bad for all
the following to be False::
date(2006, 1, 1) datetime
On 3/9/07, Collin Winter [EMAIL PROTECTED] wrote:
One solution that just occurred to me -- and that skirts the issue of
choosing an interpretation -- is that, when comparing date and
datetime objects, the datetime's .date() method is called and the
result of that call is compared to the
On 2/20/07, Steven Bethard [EMAIL PROTECTED] wrote:
Declare a simple class for your type and you're ready to go::
class Point(Record):
... __slots__ = 'x', 'y'
...
Point(3, 4)
Point(x=3, y=4)
Here's a brief comparison between Raymond's NamedTuple factory
(http
On 2/20/07, Larry Hastings [EMAIL PROTECTED] wrote:
# the easy way to define a subclass of record
def Point(x, y):
return record(x = x, y = y)
# you can use hack-y features to make your subclasses more swell
def Point(x, y):
x = record(x = x, y = y)
On 1/28/07, Michael Foord [EMAIL PROTECTED] wrote:
Mike Orr wrote:
I finally finished my path package (Unipath) and put it in the Cheeseshop.
http://sluggo.scrapping.cc/python/unipath/
Hello Mike,
Looking through the docs it looks like a great package. However, didn't
Guido (on this
On 1/12/07, Barry Warsaw [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 12, 2007, at 9:17 AM, Georg Brandl wrote:
Well, that is one of the cases in which that won't be possible ;)
I think there will be at least three areas that will make porting a
Here's the summary for the second half of November. As always,
corrections and comments are greatly appreciated. If you were
involved in the November portions of the LSB discussions, I'd
particularly appreciate your reviews of that section.
=
Announcements
=
It's been my pleasure to write the Python-Dev Summaries for the last
year and a half -- 40 summaries all told, 8 of those with Tim Lesher
and 23 with Tony Meyer. It's really been an incredible learning
experience, both in how the Python development process works, and in
how Python as a community
Here's the summary for the second half of October. Comments and
corrections welcome as always, especially on that extended buffer
protocol / binary format specifier discussion which was a little
overwhelming. ;-)
=
Announcements
=
--
Here's the summary for the first half of November. Try not to spend it
all in one place! ;-)
As always, corrections and comments are greatly appreciated.
=
Announcements
=
--
Python 2.5 malloc families
--
Just a reminder
Here's the summary for the first half of September. As always,
comments and corrections are greatly appreciated!
=
Announcements
=
QOTF: Quote of the Fortnight
Through a cross-posting slip-up, Jean-Paul
Thanks to all of those who have already given me feedback on the last
summary. Here's the next one (for the second half of September). I
found the OS X universal binaries and Finer-grained locking than
the GIL discussions particularly hard to follow, so I'd especially
appreciate corrections on
Here's the draft summary for the second half of August. As always,
comments and corrections are greatly appreciated!
=
Announcements
=
---
Python communnity buildbots
---
Want to make sure your package works with the
Sorry about the delay. Here's the summary for the first half of
August. As always, comments and corrections are greatly appreciated.
=
Summaries
=
Mixing str and unicode dict keys
Ralf Schmitt noted that in
Here's the summary for the second half of July. Thanks in advance for
your comments and corrections!
=
Announcements
=
---
Python 2.5 schedule
---
After inserting a third beta release to allow some more time for
testing the new features,
Here's the summary for the first half of July. Corrections and
comments are greatly apprecieated. Particularly for the section on
restricted execution (though my understanding is that the current
plans are somewhat different than what was discussed during the first
half of July).
=
On 7/14/06, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote:
(add PEP announcements and python-dev summary items to the mix, and you
have a high-quality development blog generated entirely from existing
content)
(hmm. maybe this could
Here's the summary for the first half of June. Thanks in advance for
your comments and corrections!
=
Announcements
=
---
Python 2.5 schedule
---
Python 2.5 is moving steadily towards its next release. See `PEP
356`_ for more details
[delurking in response to the first really decisive message in the thread] ;-)
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote:
(1) An expression of the form 'static' atom has the semantics of
evaluating the atom at the same time as the nearest surrounding
function definition.
FWIW, +1.
Ok, for the first time in a few months, you're getting this summary
before the next one is due. Woo-hoo! (Yes, I know I'm not even a day
ahead. Let me enjoy my temporary victory.) =)
Here's the draft summary for the second half of May. Let me know what
comments/corrections you have. Thanks!
Ok, here's the frist half or May. I'd almost feel like I was catching
up if there wasn't going to be another summary waiting for me in two
days. ;-)
As always, please look it over and let me know if you have any
corrections/comments.
Thanks!
=
Announcements
=
Ok, here's the summary for the second half of April. My brain is numb
from the setuptools ane PEP 343 discussions, so please have a look
over it and see what I messed up. ;-)
As always, if you have any corrections or comments, please let me know.
=
Announcements
=
[Steven Bethard]
I think that having a package level that exactly matches the divisions
in the Library Reference (http://docs.python.org/lib/lib.html) would
be great.
[Brett Cannon]
Makes sense to me.
[snip]
5. Miscellaneous Services
I don't think we necessarily want a misc package
-dev/2006-April/063488.html`__
---
PEP 359: The make statement
---
Steven Bethard introduced a PEP for the make statement which would
have made the statement::
make callable name tuple:
block
syntactic sugar for::
class name tuple
On 5/29/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Terry Reedy wrote:
.. _contributor agreement:
http://www.python.org/psf/contrib-form-python.html
By itself, this link is inadequate since there is a blank for 'Initial
License' with no choices indicated. So the summary needs a link to
Sorry I'm so far behind -- I'm aiming to get mostly caught up this
week. Please read through the summary if you have the time and send
me any comments or corrections.
Thanks!
=
Announcements
=
---
Python 2.5 schedule
---
Python 2.5 is
On 5/26/06, Facundo Batista [EMAIL PROTECTED] wrote:
All this different ways enforce my vote: we should get an error...
Perhaps you missed Tim's post, so here's a few lines of my own code
that I know would break:
padding = [None] * (self.width - len(leaves))
left_padding = [None] *
On 5/7/06, BJörn Lindqvist [EMAIL PROTECTED] wrote:
I do know enough about Python to know that the make_person function is
a really bad example.
Totally agreed. I've been ignoring most of that discussion because it
seemed really irrelevant.
would be nice to instead see some real examples of
On 5/7/06, Edward Loper [EMAIL PROTECTED] wrote:
Talin wrote:
Braces can be escaped using a backslash:
My name is {0} :-\{\}.format('Fred')
Which would produce:
My name is Fred :-{}
Do backslashes also need to be backslashed then? If not, then what is
On 5/6/06, Talin [EMAIL PROTECTED] wrote:
I've updated PEP 3101 based on the feedback collected so far.
[snip]
Compound names are a sequence of simple names seperated by
periods:
My name is {0.name} :-\{\}.format(dict(name='Fred'))
Compound names can be used to
On 4/29/06, Talin [EMAIL PROTECTED] wrote:
PEP: 3102
Title: Keyword-Only Arguments
Version: $Revision$
Last-Modified: $Date$
Author: Talin talin at acm.org
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 22-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
2006) $
Author: Steven Bethard [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006, 06-Apr-2006, 13-Apr-2006
Abstract
This PEP proposes a generalization of the class-declaration syntax,
the ``make
On 4/18/06, Steven Bethard [EMAIL PROTECTED] wrote:
I've updated PEP 359 with a bunch of the recent suggestions. The
patch is available at:
http://bugs.python.org/1472459
and I've pasted the full text below.
I've tried to be more explicit about the goals -- the make statement
is mostly
On 4/17/06, Russell E. Owen [EMAIL PROTECTED] wrote:
At some point folks were discussing use cases of make where it was
important to preserve the order in which items were added to the
namespace.
I'd like to suggest adding an implementation of an ordered dictionary to
standard python (e.g.
On 4/17/06, Ian Bicking [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
This PEP proposes a generalization of the class-declaration syntax,
the ``make`` statement. The proposed syntax and semantics parallel
the syntax for class definition, and so::
make callable name tuple
On 4/15/06, Greg Ewing [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
make callable name tuple:
block
I don't like the position of the name being defined.
It should be straight after the opening keyword, as
with 'def' and 'class'.
I see where you're coming from
Statement
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 07:36:24 -0600 (Thu, 13 Apr 2006) $
Author: Steven Bethard [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006, 06-Apr-2006
Abstract
On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I know 2.5's not out yet, but since I now have a PEP number, I'm going
to go ahead and post this for discussion. Currently, the target
version is Python 2.6. You can also see the PEP at:
http://www.python.org
On 4/13/06, Ian D. Bollinger [EMAIL PROTECTED] wrote:
I guess I fail to see how this syntax is a significant improvement over
metaclasses (though __metaclass__ = xyz may not be the most aesthetic
construct.)
It doesn't seem strange to you to have to use a *class* statement and
a
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote:
On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I know 2.5's not out yet, but since I now have a PEP number, I'm going
to go ahead and post
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
Sorry, I'm not clear on exactly what you're suggesting. Are you
suggesting I try to implement the make-statement using context
managers? Or that I use a context manager to address Martin's
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
[snip examples using class/__metaclass__ statements to create non-types]
The question is, is the intent still clear?
Depends on your use case. I'm just saying that the PEP would be tons
Sorry about the delay folks. Here's the summary for the first half of
February. I'm going to try to get the ones out for the second half of
February and first half of March shortly.
Please send me any comments/corrections!
=
Announcements
=
Ok, if I summarize any more of python-dev, my brain's going to explode. ;-)
Here's the summaries for the first half of March. Let me know what to fix!
=
Announcements
=
---
Webstats for python.org
---
Thomas Wouters set up
Georg Brandl wrote:
Nick Coghlan wrote:
Georg Brandl wrote:
some time ago, someone posted in python-list about icons using the Python
logo from the new site design [1]. IMO they are looking great and would
be a good replacement for the old non-scaling snakes on Windows in 2.5.
Those
On 3/12/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Nick Coghlan]
I agree it makes sense to have decorator, memoize, deprecated and
partial all being members of the same module, whether the name be
functools or functional (although I have a slight preference for
functools due to the
On 3/1/06, Nicolas Fleury [EMAIL PROTECTED] wrote:
Basically, should staticmethods be made callable so that the following
would not raise an exception:
class A:
@staticmethod
def foo(): pass
bar = foo()
There's workarounds, but it's really just about usability.
On 2/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Here's a crazy idea, that AFAIK has not been suggested before and could
work for both globals and closures: using a leading dot, ala the new
relative import feature. e.g.:
def incrementer(val):
def inc():
.val +=
Steven Bethard wrote:
And, as you mention, it's consistent with the relative import feature.
Greg Ewing wrote:
With imports, .foo is an abbreviation for myself.foo,
where myself is the absolute name for the current module,
and you could replace all instances of .foo with that.
Phillip J. Eby
Guido van Rossum wrote:
Alternative A: add a new method to the dict type with the semantics of
__getattr__ from the last proposal, using default_factory if not None
(except on_missing is inlined).
I'm not certain I understood this right but (after
s/__getattr__/__getitem__) this seems to
I wrote:
# I want to do ``dd[item] += 1``
Guido van Rossum wrote:
You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
is perfectly fine there and hard to improve upon.
Alex Martelli wrote:
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now
On 2/20/06, Dan Gass [EMAIL PROTECTED] wrote:
Why not have the factory function take the key being looked up as an
argument? Seems like there would be uses to customize the default based on
the key. It also forces you to handle list factory functions and constant
factory functions (amongst
Robert Brewer wrote:
Community consensus on syntax is a pipe dream.
+1 QOTF
And trust me, it'll be in there, since I'm one of the summary writers. ;-)
STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
Guido van Rossum wrote:
After so many attempts to come up with an alternative for lambda,
perhaps we should admit defeat. I've not had the time to follow the
most recent rounds, but I propose that we keep lambda, so as to stop
wasting everybody's talent and time on an impossible quest.
Raymond Hettinger wrote:
[Phillip J. Eby]
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
The PEP records that Tim argued for leaving the extra parentheses.
What
Here's the summary for the first half of November -- sorry for the bit
of a delay. As always, let me or Tony know if you have any
corrections!
=
Summary Announcements
=
--
Reminder: Python is now on Subversion!
On 12/12/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 12/11/05, Steven Bethard [EMAIL PROTECTED] wrote:
class Document(_cdm.Document):
...
# add convenience methods here
...
Personally, I find that naming convention a mistake. Call it
MyDocument or EnhancedDocument
Martin v. Löwis wrote:
Steven Bethard wrote:
I didn't really feel like the proposal was out of the blue. The
proposal has been brought up before, both on python-dev[1] and the
python-list[2]. ElementTree has a pretty large following - if you
look at XML-based questions on the python
Jim Fulton wrote:
Can we officially mark __private as a mistake. Perhaps:
- Strongly discourage it in the style guide
+1
- Mark it in the language reference as a deprecated feature
+1
- Generate deprecation warnings when it is used?
-0
I don't see that this gains us much. It will
On 12/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 12/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Keeping it for Py3K would be fine, if the mechanism was changed so that it
actually worked right. That is, the mechanics would be such that any two
concurrently existing classes would
101 - 200 of 270 matches
Mail list logo
