If anyone wants a small, but interesting C project, let me know. The
project does not require much familiarity with the CPython
implementation; all that is needed are basic C coding skills and a
puzzle solving mentality.
The goal is to determine whether the setobject.c implementation would be
i
[Steve Holden]
> The collective brainpower that's been exercised on this one
enhancement
> already must be phenomenal, but the proposal still isn't perfect.
Sure it is :-)
It was never intended to replace all string parsing functions, existing
or contemplated. We still have str.index() so peop
> Do we really need writef()? It seems to be not much better than its %-
> formatting
> equivalent.
Actually, formatting needs to become a function. The overloading of the
arithmetic mod operator has proven to be unfortunate (if only because of
precedence issues).
Also, the format coding schem
> > Actually, formatting needs to become a function. The overloading of
the
> > arithmetic mod operator has proven to be unfortunate (if only
because of
> > precedence issues).
>
> For me, it's not so much the precedence, but the fact that "%s" % x
> doesn't work as expected if x is a tuple; you'
[Paolino]
> >>Well this happened after I tried instinctively
> >>itertools.chain(child.method() for child in self).
As Jack's note points out, your proposed signature is incompatible with
the one we have now. I recommend creating your own version:
def paolino_chain(iterables):
for
[Barry Warsaw]
> I think it's best to have two builtins:
>
> print(*args, **kws)
> printf(fmt, *args, **kws)
>
> I would also /require/ that any behavior changing keyword arguments
> /not/ be magically inferred from the positional arguments. So you'd
> have to explicitly spell 'nl=False' or "str
[Jonny Reichwald]
> I would like to suggest a small enhancement to str.strip().
> By expanding its current form, where it only takes a char list, to
> taking any list containing either char lists or string lists, it is
> possible to remove entire words from the stripped string.
. . .
> Would this
> > Even if an example or two is found, it is worth complicating the
API.
> > Keep in mind the difficulties that plague str.split() -- that is
what
> > happens when a function grows beyond a single, clear, unified,
> > cohesive
> > concept.
>
> I am not aware of these difficulties, any pointers?
[Barry]
> Actually, we probably only /need/ printf(), and certainly for C
> programmers (are there any of us left? ;), I think that would be a
small
> conceptual leap. The motivation for keeping a non-formatting version
is
> for simple cases, and beginners -- both of which use cases should not
be
>Print["One", "Two", ...]
>Print["Buckle my shoe"]
The ellipsis was a nice touch.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
> some time ago, I proposed a string method "dedent" (which currently is
in
> the
> textwrap module). The RFE is at http://python.org/sf/1237680.
>
> Any opinions? If I don't get positive comments, I'll reject it.
-1
Let it continue to live in textwrap where the existing pure python code
adequat
[Reinhold Birkenfeld]
> This last patch includes a new exception, are you sure that this can
be
> safely backported?
Not too worried about it. Better to have the exception reported than
the silent failure that confused the heck out of everyone who tried to
figure-out what caused the OP's problem.
[Neal Norwitz]
> That shows the magic number changing. You will need to read CVS logs
> to figure out why. It's possible the numbers don't really *need* to
> change.
The new LIST_APPEND opcode won't run on Py2.3.
Raymond
___
Python-Dev mailing li
[Neal Becker]
> >>I don't know to what extent these kind of optimizations are
available to
> >>cpython. For example, are constant calculations removed from loops?
[Brett Cannon]
> > If you mean ``2+3``, then yes.
[Greg Ewing]
> Actually, no. Constant folding *could* be done, but it currently
i
> -Original Message-
> From: Andrew Durdin [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 16, 2005 8:25 AM
> To: [EMAIL PROTECTED]
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] C coding experiment
>
> On 9/1/05, Raymond Hettinger <[EMAIL PROTECT
[Brett]
> Is anyone truly attached to nested tuple function parameters; ``def
> fxn((a,b)): print a,b``?
I am.
> ditching them thanks to the pain they caused in the AST branch.
Changing the grammar for the convenience of a particular AST
implementation carries zero weight with me -- that is t
[Fred L. Drake]
> Indeed, "star unpacking" has been brought up many times; I think it
would
> be
> really cool myself.
It might have a chance of acceptance this time if the proponents stick
with unpacking at the end: a,b,*c=sometup instead of a,*b,c=sometup.
The latter has usually gotten shot
I propose that in Py3.0, the "and" and "or" operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got bitten in published code
that had
> > 3) Even when it isn't being used, the possibility of non-boolean
return
> > value complicates the bytecode and parser. To allow for "and/or",
the
> > conditional opcodes leave the tested value on the stack. In most
cases
> > both branches go directly to a POP_TOP instruction. Since the
POP_T
> > 2) When going back and forth between languages, it is easy to forget
> > that only Python returns something other than a boolean.
>
> As others point out, this isn't true.
In C, C++, C#, Java, and JavaScript, what do you get when you print the
result of 3 || 10?
Raymond
__
[Guido van Rossum]
> > In fact, I think Raymond's example is more properly considered an
> > argument for adding a conditional expression than for removing the
> > current behavior of the and/or shortcut operators; had we had a
> > conditional expression, he wouldn't have tried to use the "x and y
[Guido]
> I just finished debugging some code that broke after upgrading to
> Python 2.4 (from 2.3). Turns out the code was testing list iterators
> for their boolean value (to distinguish them from None). In 2.3, a
> list iterator (like any iterator) is always true. In 2.4, an exhausted
> list ite
[Guido van Rossum]
> Could you at least admit that this was an oversight and not try to
> pretend it was intentional breakage?
Absolutely. I completely missed this one.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
[Guido]
> I strongly feel that this needs to be corrected in 2.5. Iterators
> should have neither __len__ nor __nonzero__.
Right. I'll get it fixed-up.
[Terry Reedy]
> I presume there were two reasons: internal efficiency of
> preallocations
> (list(some_it) for example)
[Guido]
> This coul
[Aahz]
> I'm also opposed to elif in conditional expressions -- let's keep this
a
> simple Pythonic rewrite of C's ternary.
>
> I'm +0 on requiring parentheses precisely because they're annoying.
I'm
> still expecting simple boolean expressions to be the primary use case,
> and my hunch is that ov
> > It only takes about five minutes to try out a given syntax proposal
on
> > all the fragments listed below. That short exercise provides an
> > excellent insight into the look and feel of each proposal in real
world
> > code.
>
> I did this for my favorite proposal, and ended up with the list
> How about this:
> Can someone update the PEP on conditional expressions to point to
> this email and update the status, etc?
Already done.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
[Guido van Rossum]
> __len__ is for sequences and mappings specifically -- everything that
> supports __getitem__ should have __len__ and everything that has
> __len__ should have __getitem__.
That's going a bit far. Unordered collections (like sets and bags) are
a good counter-example.
Raymon
> Unless I'm missing something, we would need to merge HEAD to the AST
> branch once more to pick up the changes in MAIN since the last merge,
> and then make sure everything in the AST branch is passing the test
> suite. Otherwise we risk having MAIN broken for awhile following a
> merge.
IMO, m
> Neil and I have been working on the AST branch for the last week.
> We're nearly ready to merge the changes to the head.
Nice work.
> I don't think the current test suite covers all of the possible syntax
> errors that can be raised.
Do the AST branch generate a syntax error for:
foo(a
> >> > Even better if the lines for a particular piece of code don't
have
> >> > to all come from the same file.
> >>
> >>This seems _fairly_ esoteric to me. Why do you need it?
> >
> > Compilers that inline function calls, but want the code to still be
> > debuggable. AOP tools that weave byteco
FWIW, a few months ago, I reported that File New or File Open in IDLE
would crash Python as a result of the check-in implementing PEP 342.
Now, with AST checked-in, IDLE has started working again. Given the
reconfirmation, I recommend that the 342 patch be regarded as suspect
and not be restored u
[Phillip J. Eby]
> your observation actually means that the bug, if any, was somewhere
> else, or was inadvertently fixed or hidden by the AST branch merge.
What a nice side benefit :-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://
[Barry Warsaw]
> I've had this PEP laying around for quite a few months. It was
inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects.
* FWIW, the _as_immutable() protocol was dropped from sets.py for a
reason. User reports indicated that
I don't follow why the PEP deprecates catching a category of exceptions
in a different release than it deprecates raising them. Why would a
release allow catching something that cannot be raised? I must be
missing something here.
Raymond
___
Python-D
> > Why would a
> > release allow catching something that cannot be raised? I must be
> > missing something here.
>
> So conforming code can catch exceptions raised by not-yet conforming
code.
That makes sense.
What was the rationale for pushing the deprecation of __getitem__ and
args back to P
[Nick Coghlan]
> Another point in PEP 352's favour, is that it makes it far more
feasible
> to
> implement something like PEP 344 by providing "__traceback__" and
> "__prev_exc__" attributes on BaseException.
>
> The 'raise' statement could then take care of setting them
appropriately
> if it
> wa
[Martin Blais]
> > I'm always--literally every time-- looking for a more functional
form,
> > something that would be like this:
> >
> ># apply dirname() 3 times on its results, initializing with p
> >... = repapply(dirname, 3, p)
[Greg Ewing]
> Maybe ** should be defined for functions so
> The motivation
> is to be able to write multilined strings easily without damaging the
> visual indentation of the source code
That is somewhat misleading. We already have that ability. What is
being proposed is moving existing code to a different namespace. So the
motivation is really someth
[Guido van Rossum]
> > I hope there isn't anyone here who believes this patch would be a
bad
> idea?
[Nick Coglan]
> Not me, but the Iterator protocol docs may need a minor tweak.
Currently
> they
> say this:
>
> "The intention of the protocol is that once an iterator's next()
method
> raises
> S
[Matthew F. Barnes] Perhaps it would be a useful addition to the
itertools
> module then?
>
> itertools.interruptable(iterable)
Any real-world use cases or compelling contrived examples?
ISTM, that the code calling it.stop() would already be in position to
break-out of the iteration dir
[Matthew F. Barnes]
> > > Perhaps it would be a useful addition to the itertools
> > > module then?
> > >
> > > itertools.interruptable(iterable)
[Raymond Hettinger]
> > Any real-world use cases or compelling contrived examples?
[Simon W
[Skip]
> I then proposed the
> even wackier idea to simply allow all currently unsupported iterables
> (sets
> and arrays seem the most obvious candidates to me) to be marshalled as
> lists
Doesn't the appropriate conversion depend on the contract between the
sender and receiver (i.e. an array of
[Matthew F. Barnes]
> The ability to remotely terminate a for-loop also struck me as
somewhat
> interesting:
>
> def estimate(item, iterable):
> . . .
> if good_enough:
> iterable.stop()
> return result
>
> for x in iterable:
> . . .
>
> Do not use accessor methods, like ``obj.getFoo()`` and
> ``obj.setFoo(v)``, instead just expose a public attribute
(``obj.foo``).
This advice is, of course, not appropriate for all users (properties are
not typically in a Python beginner's skill set) or all use cases. It is
closer to one person
> The single nomination actually triggered a (admittedly
> fast) process, where multiple people spoke in favour, not just a
single
> one. It also followed a discussion on python-list.
Also, there were silent +1 votes from people like me who followed all
the posts and saw no need to alter the direc
unt(start), someslice)
Raymond Hettinger
___
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
[Martin Blais]
> Now, it's not all about storage space. What about front-insertion?
> Everytime I have to type L.insert(0, bli), somewhere that I know runs
> "often" I cringe. If I had lists I would be able to express my
> thoughts more clearly in the computer program. Right now, I cringe,
> and
> The setentry typedef clearly violates the principles of the API, so
> it should be renamed.
In my next update, will rename it to match the Py or _Py convention.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
> > > I think it should be ok because it's never used
> > > really as a PyObject. Am I missing something? (Ok, I now thought
that
> > > maybe it's because some parts don't treat dummy elements
specially.
> > > But it seems to me that most parts do treat them specially, so
perhaps
> > > it would be
> > It's very difficult to do something useful about it. Even if
> > you manage to determine how much memory you want to release,
> > it's nearly impossible to actually release the memory to the
> > operating system, because of the many layers of memory
> > management software that all need to agre
[Noam]
> For example, iteration over a set which once had
> 1,000,000 members and now has 2 can take 1,000,000 operations every
> time you traverse all the (2) elements.
Do you find that to be a common or plausible use case?
Was Guido's suggestion of s=set(s) unworkable for some reason? dicts
an
> > > [Noam]
> > > > For example, iteration over a set which once had
> > > > 1,000,000 members and now has 2 can take 1,000,000 operations
every
> > > > time you traverse all the (2) elements.
> > >
> > > Do you find that to be a common or plausible use case?
> >
> > I don't have a concrete exampl
[Fernando Perez]
> Note that this is not a comment on the current discussion per se, but
> rather a
> small request/idea in the docs department: I think it would be a
really
> useful
> thing to have a summary page/table indicating the complexities of the
> various
> operations on all the builtin ty
> And while we're at it, could you remove the "commit of" too? IMHO it
> just obscures the real content of the subject.
+1
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
[Guido]
> I'm not saying it's uncrashable. I'm saying that if you crash it, it's
> a bug unless proven harebrained.
+1 QOTW
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
> Is there any objection to this patch? Any support?
It is assigned to me. When I have time, will go through it in detail
(the given use cases, more detailed timings, and a close reading of the
code).
If accepted, it will be for Py2.5, as it is a new feature. There is
nothing broken about the e
> Because isinstance is faster and handier than testing with try/except
> around (say) "x+0".
Are you sure? The former has two builtin lookups (which also entail two
failed global lookups), a function call, and a test/jump for the result.
The latter approach has no lookups (just a load constant),
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',2)
> gives 5?
+1
The only downside is that like list.reverse(), it will deprive students
of being assigned to write the roll-your-own version.
Raymond
_
[Me]
> Even if there were a performance edge, I suppose that the type
checking
> is the time critical part of most scripts.
That should be: RARELY the time critical part of most scripts.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
> I wish you had an argument better than "every bright beginner assumes
> it exists". :-)
>
> But (unlike for some other things that bright beginners might assume)
> I don't think there's a deep reason why this couldn't exist.
>
> The only reasons I can come up with is "because input and output a
[Jeremy Hylton]
> The concept of base is closely related to ints, and the base argument
> is useful for a large percentage of the types that int accepts. It is
> not related to strings, in general, and applies to only one of the
> types it accepts. In one case "not a float, etc." applies to a ver
> > I'd propose bin() to stay in line with the short abbreviated names.
>
> There has been some previous discussion about removing hex()/oct()
from
> builtins for Python 3.0, IIRC. I sure don't think bin() belongs
there.
Perhaps introduce a single function, base(val, radix=10, prefix=''), as
a u
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-dev-
> [EMAIL PROTECTED] On Behalf Of Martin v. Löwis
> Sent: Wednesday, January 18, 2006 3:36 PM
> To: Jason Orendorff
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] basenumber redux
>
> Jason Orendorff wrote:
> > Re
Guido, we may be converging on a consensus for my proposal:
base(value, radix=2)
So far no one has shot at it, and it has gathered +1's from Steven,
Alex, Brett, and Nick.
To keep it simple, the proposal is for the value to be any int or long.
With an underlying __base__ method call, it woul
[Greg Wilson]
> I have a student who may be interested in adding syntactic support for
> sets to Python, so that:
>
>x = {1, 2, 3, 4, 5}
>
> and:
>
>y = {z for z in x if (z % 2)}
>
> would be legal. There are of course issues (what's the syntax for a
> frozen set? for the empty set?),
[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 would you do with {'title'} -- cr
[Greg Wilson]
> This is a moderately-fertile source of bugs for newcomers: judging from
> the number of students who come into my office with code that they think
> ought to work, but doesn't, most people believe that:
>
>set(1, 2, 3)
Like many things in Python where people pre-emptively beli
>>So I was wondering if module math (and
>> perhaps by symmetry module cmath, too) shouldn't grow a function
>> 'areclose' (calling it just 'close' seems likely to engender
>> confusion, since 'close' is more often used as a verb than as an
>> adjective; maybe some other name would work better, e.g
[Bob Ipppolito]
> For those of us that already know what we're doing with floating
> point, areclose would be very convenient to have.
Do you agree that the original proposed use (helping newbs ignore floating
point realities) is misguided and error-prone?
Just curious, for your needs, do you w
> 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.
+1 -- trying to cover all t
You don't have to keep writing notes to python-dev on this patch.
It is assigned to me and when I get a chance to go through it in detail,
it has a good likelihood of going in (if no issues arise).
Raymond
- Original Message -
From: "Crutcher Dunnavant" <[EMAIL PROTECTED]>
To: "Martin v.
[Chris Smith]
> Does it help to spell it like this?
>
> def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8):
> diff = abs(x - y)
> ave = (abs(x) + abs(y))/2
> return diff < absolute_err or diff/ave < relative_err
There is a certain beauty and clarity to this presentation; howe
[Smith]
>I just ran into a curious behavior with small floating points, trying to
>find the limits of them on my machine (XP). Does anyone know why the '0.0'
>is showing up for one case below but not for the other? According to my
>tests, the smallest representable float on my machine is much sm
> How about (lambda x,y: x**y)?
The purpose of this thread was to conserve brain-power by bringing the issue
to a close. Instead, it is turning into syntax/renaming fest. May I
suggest that this be moved to comp.lang.python and return only if a
community consensus emerges from the thousands o
[Armin Rigo]
> It was replaced by an optional undocumented method called _length_cue(),
> which would be used to guess the number of remaining items in an
> iterator, for performance reasons.
>
> I'm worried about the name. There are now exactly two names that behave
> like a special method withou
[Joao Macaiba]
> 1. For a newbie in the Python core development, what is the best PEP to
> begin with ?
I recommend, PEP 308: Conditional Expressions
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
[Armin Rigo]
> Hi Raymond,
. . .
> This means that _length_cue() is at the moment a special method, in the
> sense that Python can invoke it implicitely.
Okay, that makes sense. Go ahead and make the swap.
> This said, do we vote for __length_hint__ or __length_cue__? :-)
I prefer __length_cu
> Hint seems like the standard terminology in the field. I don't think
> it makes sense to invent our own terminology without some compelling
> reason.
Okay, I give, hint wins.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Die thread, die!
___
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
[Giovanni]
>> I was really attracted to the idea of having more informative iterator
>> representations but learned that even when it could be done, it wasn't
>> especially useful. When someone creates an iterator at the
>> interactive
>> prompt, they almost always either wrap it in a consumer fun
[Armin]
> It would be nicer if all these
> iterators I'm not familiar with would give me a hint about what they
> actually return, instead of:
>
itertools.count(17)
> count(17) # yes, thank you, not very helpful
I prefer that the repr() of count() be left alone. It follows t
[Guido van Rossum]
> PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of
> freezing arbitrary mutable data structures. Are there champions who
> want to argue this?
It has at least one anti-champion. I think it is a horrible idea and would
like to see it rejected in a way that
[Barry Warsaw"]like to put email 3.1 in Python 2.5
> with the new module naming scheme. The old names will still work,
> and all the unit tests pass. Do we need a PEP for that?
+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
Just do it.
- Original Message -
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc: "Barry Warsaw" <[EMAIL PROTECTED]>;
Sent: Friday, February 10, 2006 5:47 PM
Subject: Re: [Python-Dev] releas
- Original Message -
From: "Alex Martelli" <[EMAIL PROTECTED]>
To: "Raymond Hettinger" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, February 11, 2006 3:55 PM
Subject: PEP 351
>
> On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote:
>
>> [
[Noam]
> I just wanted to say this: you can reject PEP 351, please don't reject
> the idea of frozen objects completely. I'm working on an idea similar
> to that of the PEP,
. . .
> I think these concerns can only be judged given a real suggestion,
> along with an implementation. I have already im
1401 - 1487 of 1487 matches
Mail list logo
