Re: [Python-Dev] os.access and Unicode

[Martin v. Löwis]

Skip Montanaro wrote:
 > I say backport.  If people were trying to call os.access with unicode
filenames it would have been failing and they were either avoiding unicode
filenames as a result or working around it some other way.  I can't see how
making os.access work with unicode filenames is going to break existing
code.
The question is whether it would encourage conditional work-arounds. If
people will put into their code
if sys.version_info < (2,4,2):
   import os, sys
   def new_access(name, mode, old_access = os.access):
   try:
   return old_access(name, mode)
   except UnicodeError:
   return old_access(name.encode(
sys.getfilesystemencoding()), mode)
   os.access = new_access
then backporting does not improve anything. OTOH, if people are likely
to say "yes, this was a bug in 2.4.0 and 2.4.1, you need atleast 2.4.2",
backporting will help.
Regards,
Martin
___
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

Re: [Python-Dev] os.access and Unicode

[M.-A. Lemburg]

Martin v. Löwis wrote:
Skip Montanaro wrote:
 > I say backport.  If people were trying to call os.access with unicode
filenames it would have been failing and they were either avoiding 
unicode
filenames as a result or working around it some other way.  I can't 
see how
making os.access work with unicode filenames is going to break existing
code.

The question is whether it would encourage conditional work-arounds. 
-1. That only makes the code more complicated.
If
people will put into their code
if sys.version_info < (2,4,2):
   import os, sys
   def new_access(name, mode, old_access = os.access):
   try:
   return old_access(name, mode)
   except UnicodeError:
   return old_access(name.encode(
sys.getfilesystemencoding()), mode)
   os.access = new_access
then backporting does not improve anything. OTOH, if people are likely
to say "yes, this was a bug in 2.4.0 and 2.4.1, you need atleast 2.4.2",
backporting will help.
+1. Application writers can add tests for the correct version
of Python to their application and give a warning to the user
in case the version doesn't match.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Mar 11 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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

Re: [Python-Dev] Adding any() and all()

[BJörn Lindqvist]

Not sure this is pertinent but anyway: "any" and "all" are often used
as variable names. "all" especially often and then almost always as a
list of something. It would not be good to add "all" to the list of
words to watch out for. Also, "all" is usually thought of as a list of
(all) things. In my mind it doesn't make sense (yet) that all(seq)
returns true if all elements of seq is true and false otherwise, I
would have expected "all" to return a list. "any" is better because it
is very obvious it can only return one thing.


-- 
mvh Björn
___
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

Re: [Python-Dev] os.access and Unicode

[Martin v. Löwis]

M.-A. Lemburg wrote:
The question is whether it would encourage conditional work-arounds. 

-1. That only makes the code more complicated.
You misunderstand. I'm not proposing that the work-around is added
to Python. I'm saying that Python *users* might introduce such
work-arounds to their code.
+1. Application writers can add tests for the correct version
of Python to their application and give a warning to the user
in case the version doesn't match.
Application writers typically don't do that if they can find
a work-around, because that means less hassle for their users.
They accept that the code will get more complicated because
of the work-around, and blame Python for having this bug in the
first place.
In any case, I can't backport the os.access change without explicit
permission from Anthony.
Regards,
Martin
___
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

Re: [Python-Dev] Adding any() and all()

[Paul Moore]

On Fri, 11 Mar 2005 11:30:38 +0100, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> Not sure this is pertinent but anyway: "any" and "all" are often used
> as variable names. "all" especially often and then almost always as a
> list of something. It would not be good to add "all" to the list of
> words to watch out for. Also, "all" is usually thought of as a list of
> (all) things. In my mind it doesn't make sense (yet) that all(seq)
> returns true if all elements of seq is true and false otherwise, I
> would have expected "all" to return a list. "any" is better because it
> is very obvious it can only return one thing.

Using "any" and "all" as variables hides the builtins, but doesn't
disallow their use elsewhere. Personally, though, I wouldn't use "any"
or "all" as variable names, so that's a style issue.

As far as the names making sense is concerned, they are perfect in context:

if all(i > 0 for i in int_list):

if any(invalid(s) for s in input_values):

While you may think that use in any other context looks a little less
natural (something I'm not convinced of), in the intended context, the
names seem ideal to me.

Paul.
___
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

Re: [Python-Dev] os.access and Unicode

[M.-A. Lemburg]

Martin v. Löwis wrote:
M.-A. Lemburg wrote:
The question is whether it would encourage conditional work-arounds. 

-1. That only makes the code more complicated.

You misunderstand. I'm not proposing that the work-around is added
to Python. I'm saying that Python *users* might introduce such
work-arounds to their code.
Ah, ok.
Either way, the code get's more complicated :-)
+1. Application writers can add tests for the correct version
of Python to their application and give a warning to the user
in case the version doesn't match.

Application writers typically don't do that if they can find
a work-around, because that means less hassle for their users.
They accept that the code will get more complicated because
of the work-around, and blame Python for having this bug in the
first place.
Hmm, eGenix always suggests to people to use the latest
patch level release, esp. for production systems, not only
for Python itself, but also for the products. Zope Corp.
does the same, as do many other application writers.
The only time where we do add work-arounds is for changes
between minor Python versions in order to make the same
code base work for multiple Python versions, but that's
rare.
In any case, I can't backport the os.access change without explicit
permission from Anthony.
Agreed.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Mar 11 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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

Re: [Python-Dev] Adding any() and all()

[Peter Astrand]

On Fri, 11 Mar 2005, Paul Moore wrote:

> > Not sure this is pertinent but anyway: "any" and "all" are often used
> > as variable names. "all" especially often and then almost always as a
> > list of something. It would not be good to add "all" to the list of
> > words to watch out for. Also, "all" is usually thought of as a list of

> Using "any" and "all" as variables hides the builtins, but doesn't
> disallow their use elsewhere. Personally, though, I wouldn't use "any"
> or "all" as variable names, so that's a style issue.

Even though you can use them as variables (and shadow the builtins), you
will still get warnings from "pychecker". The code will also be harder to
read: When you see "all" in the middle of some code, you don't know if
it's referring to the builtin or a variable.

Personally, I think Python has too many builtins already.


/Peter Åstrand <[EMAIL PROTECTED]>

___
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

Re: [Python-Dev] Adding any() and all()

[Samuele Pedroni]

Peter Astrand wrote:
On Fri, 11 Mar 2005, Paul Moore wrote:
 

Not sure this is pertinent but anyway: "any" and "all" are often used
as variable names. "all" especially often and then almost always as a
list of something. It would not be good to add "all" to the list of
words to watch out for. Also, "all" is usually thought of as a list of
 

 

Using "any" and "all" as variables hides the builtins, but doesn't
disallow their use elsewhere. Personally, though, I wouldn't use "any"
or "all" as variable names, so that's a style issue.
   

Even though you can use them as variables (and shadow the builtins), you
will still get warnings from "pychecker". The code will also be harder to
read: When you see "all" in the middle of some code, you don't know if
it's referring to the builtin or a variable.
Personally, I think Python has too many builtins already.
 

to extend the naming pool, FWIW CL calls similar things EVERY and SOME.

___
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

Re: [Python-Dev] Adding any() and all()

[Pierre Barbier de Reuille]

And why not use the names already in use in numarray/Numeric ?
They are called "sometrue" and "alltrue" ... IMHO, it explicits more 
what it means :

  alltrue(i<5 for i in l)
  sometrue(i<5 for i in l)
Another point is: as I agree there is already a huge lot of builtins, 
shouldn't it be in some module ? Perhaps in itertools ?

Pierre
PS: It's my first post on the list, even if I'm reading it for a few 
months now ^_^

Peter Astrand a écrit :
On Fri, 11 Mar 2005, Paul Moore wrote:

Not sure this is pertinent but anyway: "any" and "all" are often used
as variable names. "all" especially often and then almost always as a
list of something. It would not be good to add "all" to the list of
words to watch out for. Also, "all" is usually thought of as a list of

Using "any" and "all" as variables hides the builtins, but doesn't
disallow their use elsewhere. Personally, though, I wouldn't use "any"
or "all" as variable names, so that's a style issue.

Even though you can use them as variables (and shadow the builtins), you
will still get warnings from "pychecker". The code will also be harder to
read: When you see "all" in the middle of some code, you don't know if
it's referring to the builtin or a variable.
Personally, I think Python has too many builtins already.
/Peter Åstrand <[EMAIL PROTECTED]>
___
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/pierre.barbier%40cirad.fr
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France
tel   : (33) 4 67 61 65 77fax   : (33) 4 67 61 56 68
___
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

Re: [Python-Dev] RELEASED Python 2.4.1, release candidate 1

[Michael Chermside]

[Martin v. Löwis]
> I'd like to encourage feedback on whether the Windows installer works
> for people. It replaces the VBScript part in the MSI package with native
> code, which ought to drop the dependency on VBScript, but might
> introduce new incompatibilities.

[Tim Peters]
> Worked fine here.  Did an all-default "all users" install, WinXP Pro
> SP2, from local disk, and under an account with Admin rights.  I
> uninstalled 2.4 first.  I suppose that's the least stressful set of
> choices I could possibly have made, but at least it confirms a happy
> baseline.

I tried several stranger things, like installing over 2.4.0 but in a
different directory. Everything worked like clockwork. I did NOT try
anything that would have involved a system with various things missing
(like lack of VBScript), but I did play around with alternate install
locations, repairs, uninstalls, single-user and all-user installs, and
I found no problems anywhere. Nice work!

-- Michael Chermside

___
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

Re: [Python-Dev] Adding any() and all()

[Nick Coghlan]

Peter Astrand wrote:
Personally, I think Python has too many builtins already.
A suggestion was made on c.l.p a while back to have a specific module dedicated 
to reductive operations. That is, just as itertools is oriented towards 
manipulating iterables and creating iterators, this module would be oriented 
towards consuming iterators in a reductive fashion.

product(), anytrue() and alltrue() were obvious candidates for inclusion ([1]).
The combination of explicit for loops and a standard toolkit of reductive 
operations was designed to eliminate the need for reduce() ([2]).

Cheers,
Nick.
[1] While any()/all() read well in the context of an if statement, I think 
anytrue()/alltrue() better convey the reductive nature of the operations, read 
nearly as well in the if context, and read significantly better when isolated 
from the if context (e.g. assigned to a variable). I also think the names are 
less likely to collide with existing variable names.

[2] I'm firmly in Guido's camp on this one - whenever I encounter code that uses 
reduce(), I have to rewrite it (either mentally or literally) to use a for loop 
before I can understand it. Getting rid of the function would benefit me because 
I would no longer have to waste time figuring out what such code was doing - it 
would already be an explicit loop, or it would be using one of the standard 
reductive operations.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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

Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents

[Nick Coghlan]

Anthony Baxter wrote:
On Thursday 10 March 2005 17:29, Raymond Hettinger wrote:
Or the implementation can have a switch to choose between keep-first
logic or replace logic.
The latter seems a bit odd to me.  The key position would be determined
by the first encountered while the value would be determined by the last
encountered.  Starting with [(10, v1), (20, v2), (10.0, v3)], the
ordered dictionary's items would look like [(10, v3), (20, v2)].

Or, alternately, we keep the last occurence, and move it to the new position.
There's a wide number of different use cases, each with a slightly different
final result, and for this reason alone I'm -0 on it for the library. 

Anthony
But surely such use cases could be more easily handled by subclassing from 
collections.OrderedDict and tweaking the semantics than by having to implement 
an ordered mapping from scratch.

Would the default semantics below really be that suprising?
"An ordered dictionary remembers the order in which keys are first seen and, 
when iterated over, returns entries based on that order. This applies to direct 
iteration, iteration over values and (key, value) pairs, to the list-producing 
methods (i.e. keys(), values() and items()) and to any other operations that 
involve implicit iteration (e.g. converting to a string representation). 
Overwriting an entry replaces its value, but does not affect its position in the 
key order. Removing an entry (using 'del') _does_ remove it from the key order. 
Accordingly, if the entry is later recreated, it will then occur last in the key 
order.

This behaviour is analagous to that of a list constructed using only 
list.append() to add items (indeed, the key order can be thought of as a list 
constructed in this fashion, with keys appended to the list when they are first 
encountered).

An ordered dictionary provides a sort() method. The sort operation is applied to 
the key ordering and affects future iteration over the dictionary. Again, this 
is analagous to sorting a list."

For instance, to convert a standard dictionary to an ordered dictionary using a 
specific key function:

  x = collections.OrderedDict(sorted(d.itervalues(), key=keyfunc))
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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

Re: [Python-Dev] Adding any() and all()

[Rodrigo Dias Arruda Senra]

[ Pierre Barbier de Reuille ]:
They are called "sometrue" and "alltrue" ... IMHO, it explicits more 
what it means :

  alltrue(i<5 for i in l)
  sometrue(i<5 for i in l)
+1
[ from a comment in GvR's blog ]
> > Why not,
> > if True in (x > 42 for x in S):
> > instead of "any" and why not
> > if not False in (x > 42 for x in S):
> > instead of "all"?
>
> Because "any" and "all" have shortcut semantics (they
> return as soon as they can determine the final result).
[ Guido ]:
--
> See my blog:
> http://www.artima.com/forums/flat.jsp?forum=106&thread=98196
> Do we even need a PEP ?
In the absence of a PEP, soon will see in c.l.p discussions like:
"""
 For completeness sake shouldn't there be a optimiztion
 version for  nonetrue() ?
 def nonetrue(S):
 for x in S:
 if x:
 return False
 return True
 why not allfalse() ?
 Due to the previous use of sometrue(), guess it becomes
 easier to remeber nonetrue() than allfalse().
 One may argue for aliasing(nonetrue, allfalse), and we are
 back to _builtin pollution_.
"""
So, people might fallback to any() and all(),realising that:
'''not all()''' meaning somefalse()
'''not any()''' meaning nonetrue()==allfalse()
All I'm saying: +1 for the PEP.
OFF-TOPIC:
It is curious though that we choose to read an *implicit*
True in [all(), any()] instead of an implicit False.
I guess that is a moral or ethical choice coming from the Human
realm, favouring Truth instead of Falsity. But that difference
does not hold in the Boolean realm .
best regards,
Senra
--
Rodrigo Senra
MSc Computer Engineer [EMAIL PROTECTED]
GPr Sistemas Ltda   http://www.gpr.com.br
___
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

Re: [Python-Dev] Adding any() and all()

[Nick Coghlan]

Rodrigo Dias Arruda Senra wrote:
OFF-TOPIC:
It is curious though that we choose to read an *implicit*
True in [all(), any()] instead of an implicit False.
Actually, I think it's predicate logic's fault:
  if p(x) for any x then conclusion 1
  if q(x) for all x then conclusion 2
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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

Re: [Python-Dev] Adding any() and all()

[Guido van Rossum]

> Even though you can use them as variables (and shadow the builtins), you
> will still get warnings from "pychecker".

So?

> The code will also be harder to
> read: When you see "all" in the middle of some code, you don't know if
> it's referring to the builtin or a variable.

Yes you do. Builtins will be followed by a '('; the variables won't.
(Obviously there can be exceptions, but in practice very, very few.)

> Personally, I think Python has too many builtins already.

It has fewer than most dynamic languages; and remember that I'm
trading product(), any(), all() for reduce(), map() and filter().
There are others slated for disappearance, too.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Adding any() and all()

[Jeremy Hylton]

On Fri, 11 Mar 2005 07:19:56 -0800, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> > Personally, I think Python has too many builtins already.
> 
> It has fewer than most dynamic languages; and remember that I'm
> trading product(), any(), all() for reduce(), map() and filter().
> There are others slated for disappearance, too.

I think I'd miss reduce, but I'd be happy to have it moved to an
extension module.  There's no need for reduce to be a builtin.  I'd be
very happy to have any and all around.

Jeremy
___
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

Re: [Python-Dev] Adding any() and all()

[Guido van Rossum]

Here's my take on the key issues brought up:

Alternative names anytrue(), alltrue(): before I posted to my blog I
played with these names (actually anyTrue(), allTrue(), anyFalse(),
allFalse()). But I realized (1) any() and all() read much better in
their natural context (an if statement), and there's no confusion
there; (2) anyFalse() and allFalse() are redundant, so there's no need
to distinguish between anyTrue() and anyFalse(). (To the person who
wondered why we default to True: because 'if' tests for True, duh. :-)

Whether to always return True and False or the first faling / passing
element? I played with that too before blogging, and realized that the
end case (if the sequence is empty or if all elements fail the test)
can never be made to work satisfactory: picking None feels weird if
the argument is an iterable of bools, and picking False feels weird if
the argument is an iterable of non-bool objects.

Whether to use each() and some() instead of all() and any(), to
preserve variable namespace: each() in particular (and some() to some
extent) emphasizes the individual element, while all() emphasizes the
whole set. As long as we accept that the return value should not
return one of the arguments elements, I prefer emphasizing the group.
The namespace argument doesn't weigh much in my mind; there's no
backwards incompatibility, and there are plenty of builtins that are
routinely reused as variables (e.g. str, file, id, type) without
apparently affecting readability. Context helps a lot!

Whether to segregate these into a separate module: they are really a
very small amount of syntactic sugat, and I expect that in most cases,
instead of importing that module (which totally makes me lose my
context while editing) I would probably just write the extra line that
it takes to get the same effect with an explicit for loop and if
statement.

What worries me a bit about doing a PEP for this simple proposal is
that it might accidentally have the wrong outcome: a compromise that
can carry a majority rather than the "right" solution because nobody
could "sell" it. Yet, if people really feel strongly that there are
more issues that need to be discussed, and they think it's worth their
time, let someone stand up now to own the PEP and guide the
discussion. But personally, I think it's more efficient if Raymond
just checks in his code now. :-)

BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code. The PEP, in addition to making a really strong case for each of
the removals, will have to deal with a deprecation period, possibly
moving the functions to a "functional programming" module, etc.

PS in the blog responses, a problem with sum() was pointed out --
unless you use the second argument, it will only work for numbers. Now
that string concatenation is apparently O(N) rather than O(N**2) (is
that right, Raymond?) maybe this could be revised.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] rationale for the no-new-features approach

[Barry Warsaw]

On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote:

> That way instead of multi-line "except NameError" tests all over the 
> place you can simply have one-liner boilerplate for every module in your 
> project:
> 
>   'from py24compat import *'
> 
> Easy to grep/sed for when you're ready to stop supporting old versions, 
> too, for those of you without a copy of the refactoring editor from the 
> 2009 release of PyDev/Eclipse.

I do something very similar, both for Mailman and for the commercial
products I'm working on.  There are lots of ways to handle this kind of
thing, and there might be some value in a community effort to work
together and standardize this.  IWBNI there were some common idioms and
packages that people could use.  Having said that...

> The only problem with this idea is that the 2.3 -> 2.4 transition has 
> been extremely smooth for me - there are no new features I desperately 
> want to use, and there are no old features that were deprecated or 
> altered (that I've found yet - knock on wood).  Still, future 
> incompatibilties are inevitable.

...I agree.  We just upgraded to 2.4 internally and it went
embarrassingly smoothly.  Had to find something else to do with the four
days (cough - warsaw's first law - cough) we'd scheduled for that.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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

[Python-Dev] Re: @deprecated (was: Useful thread project for 2.5?)

[Reinhold Birkenfeld]

Nick Coghlan wrote:
> Raymond Hettinger wrote:
>> Decorators like this should preserve information about the underlying
>> function:
>> 
>> 
>>>def deprecated(func):
>>>"""This is a decorator which can be used to mark functions
>>>as deprecated. It will result in a warning being emmitted
>>>when the function is used."""
>>>def newFunc(*args, **kwargs):
>>>warnings.warn("Call to deprecated function.")
>>>return func(*args, **kwargs)
>> 
>>   newFunc.__name__ = func.__name__
>>   newFunc.__doc__ = func.__doc__
>>   newFunc.__dict__.update(func.__dict__)
>> 
>>>return newFunc
> 
> A utility method on function objects could simplify this:
>newFunc.update_info(func)

+1. This is really good for 90% of all decorator uses. But maybe a
better name should be found, perhaps "update_meta".

Reinhold

-- 
Mail address is perfectly valid!

___
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

[Python-Dev] Re: Adding any() and all()

[Reinhold Birkenfeld]

Guido van Rossum wrote:
> See my blog: http://www.artima.com/forums/flat.jsp?forum=106&thread=98196
> 
> Do we even need a PEP or is there a volunteer who'll add any() and all() for 
> me?

There is an interesting proposal in the forum:

"""
He proposes that

[x in list if x > 0]

(which is currently undefined) be exactly equal to:

[x for x in list if x > 0]
"""

What about that?

And, don't you want to save any() and all() for junctions, like those in
Perl 6? 

Reinhold

-- 
Mail address is perfectly valid!

___
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

Re: [Python-Dev] Adding any() and all()

[Barry Warsaw]

On Fri, 2005-03-11 at 06:43, Peter Astrand wrote:

> Even though you can use them as variables (and shadow the builtins), you
> will still get warnings from "pychecker". The code will also be harder to
> read: When you see "all" in the middle of some code, you don't know if
> it's referring to the builtin or a variable.

> Personally, I think Python has too many builtins already.

I agree.  Personally, I'd rather see 'all' called 'every' (I'm less sure
about 'any' being called 'some'), and I'd rather see these put in some
module other than builtin.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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

RE: [Python-Dev] Adding any() and all()

[Raymond Hettinger]

> BTW I definitely expect having to defend removing
> map/filter/reduce/lambda with a PEP; that's much more controversial
> because it's *removing* something and hence by definition breaking
> code. 

I suspect that lambda will be the only bone of contention.  The reduce()
function can be moved to the functional module.  The map() and filter()
functions are already covered by the itertools module.

Lambda will be more difficult.  Eric Raymond adapted an anti-gun control
slogan and said "you can pry lambda out of my cold dead hands."  A bunch
of folks will sorely miss the ability to create anonymous functions on
the fly.  When lambda is used for deferred argument evaluation (a la PEP
312), the def syntax is a crummy substitute.



> PS in the blog responses, a problem with sum() was pointed out --
> unless you use the second argument, it will only work for numbers. Now
> that string concatenation is apparently O(N) rather than O(N**2) (is
> that right, Raymond?) maybe this could be revised.

str.join() is still the best practice for string concatenation.  

Armin's optimization doesn't appear in other implementations of Python.
In CPython, it has a set of pre-conditions that are usually but not
always True.  IIRC, it also doesn't apply to Unicode and ASCII mixed
with Unicode.

Also, the optimization is part of ceval.c and would not be triggered by
sum()'s call to PyNumber_Add().  That limitation is not easily removed
because the optimization depends on an interaction between the stack,
variable refcounts, and the sequence of opcodes.

IOW, your original pronouncement on the subject should remain in effect.



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

Re: [Python-Dev] Adding any() and all()

[M.-A. Lemburg]

Raymond Hettinger wrote:
BTW I definitely expect having to defend removing
map/filter/reduce/lambda with a PEP; that's much more controversial
because it's *removing* something and hence by definition breaking
code. 
+1 on the PEP
-1 on removing those tools - breaks too much code.
I suspect that lambda will be the only bone of contention.  The reduce()
function can be moved to the functional module.  The map() and filter()
functions are already covered by the itertools module.
Nope. Think of the side-effects that can occur as a result
of calling the function argument n times with different
arguments. itertools only help if the functions don't have
side-effects.
Iteration is nice, but not the solution to everything :-)
Lambda will be more difficult.  Eric Raymond adapted an anti-gun control
slogan and said "you can pry lambda out of my cold dead hands."  A bunch
of folks will sorely miss the ability to create anonymous functions on
the fly.  When lambda is used for deferred argument evaluation (a la PEP
312), the def syntax is a crummy substitute.
While I'm no fan of lambdas either, the removal would break too
much code (e.g. I have 407 hits in the code base I use regularly
alone).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Mar 11 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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

RE: [Python-Dev] Adding any() and all()

[Barry Warsaw]

On Fri, 2005-03-11 at 12:18, Raymond Hettinger wrote:

> I suspect that lambda will be the only bone of contention.  The reduce()
> function can be moved to the functional module.  The map() and filter()
> functions are already covered by the itertools module.

I'm fine seeing reduce() eventually go; I've used it maybe a handful of
times in all my years of Python.  Using a list comprehension instead of
map() is fine too, but I'll miss the filter(None, seq) idiom.  Ping's
suggested list comprehension abbreviation, i.e.:

[x in seq if x] == [x for x in seq if x]

might help.

> Lambda will be more difficult.  Eric Raymond adapted an anti-gun control
> slogan and said "you can pry lambda out of my cold dead hands."  A bunch
> of folks will sorely miss the ability to create anonymous functions on
> the fly.  When lambda is used for deferred argument evaluation (a la PEP
> 312), the def syntax is a crummy substitute.

Yeah, I'm with you here.  As warty as lambda is, it just is so damn
convenient some times.  I've recently been using it as a companion to
property(), providing concise definitions of read-only attributes.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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

Re: [Python-Dev] Adding any() and all()

[Barry Warsaw]

On Fri, 2005-03-11 at 12:40, M.-A. Lemburg wrote:

> While I'm no fan of lambdas either, the removal would break too
> much code (e.g. I have 407 hits in the code base I use regularly
> alone).

We /are/ talking Python 3000 here, right?  I'm expecting all manner of
code breakage in moving from Python 2 to Python 3.  So while I would
lament the loss of lambda too, I think its impact on my code will be in
the noise compared to dealing with "optional" static typing and the
truly saddening loss of <>.

there's-a-wink-in-there-somewhere-ly y'rs,
-Barry



signature.asc
Description: This is a digitally signed message part
___
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

Re: [Python-Dev] Adding any() and all()

[Alex Martelli]

On Mar 11, 2005, at 17:28, Guido van Rossum wrote:
PS in the blog responses, a problem with sum() was pointed out --
unless you use the second argument, it will only work for numbers. Now
Why is that a *problem*?  It solves the "end case (if the sequence is 
empty" which you mention for any() and all() [[indeed, I think a 
similar approach to any and all might be best: have them return an item 
from the sequence, an empty sequence uses the optional second item 
defaulting to something reasonable -- 0 for sum, False for any, True 
for all, for example]] in a neatly explicit way.  As I recall, I had 
tried to handle non-empty sequences by picking the first item and doing 
following + on it (with internal implementation specialcasing for 
strings, to avoid an "attractive nuisance" situation), and you cut the 
gordian knot by pronouncing about the second argument with a default of 
0 (I immediately thought your pronouncement was excellent and I still 
can't see why it wouldn't be).

Forcing the user to provide a 2nd arg when summing a sequence of 
non-numbers (say, datetime.timedelta instances, that's one example that 
ended up in the 2nd ed Cookbook) is good because it ensures a good 
return value when the sequence is empty (say, timedelta(0) rather than 
0 as a number).

If you're considering revisions to sum's design, my suggestion would be 
to find a way to let the user tell sum to use a more accurate approach 
when summing floats.  Summing a million floats with a loop of 
total+=item loses a LOT of accuracy (several digits' worth!) -- but 
doing the summation the right way takes O(N) auxiliary temporary space, 
so both approaches (the naive, performance-optimized accuracy disaster, 
and the expensive but accurate one) should ideally be available.  An 
optional use_partials keyword argument defaulting to False, for 
example, might allow that... (again, I've hopefully clarified the 
issues in another 2nd ed Cookbook recipe, I guess I can post that if it 
helps).

Alex
___
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

[Python-Dev] sum()

[Raymond Hettinger]

[Alex]
> If you're considering revisions to sum's design, my suggestion would
be
> to find a way to let the user tell sum to use a more accurate approach
> when summing floats.  

FWIW, when accuracy is an issue, I use:

   sum(sorted(data, key=abs))


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

Re: [Python-Dev] Adding any() and all()

[Alex Martelli]

On Mar 11, 2005, at 18:18, Raymond Hettinger wrote:
str.join() is still the best practice for string concatenation.
...except you actually need unicode.join if the strings are of that 
kind.  Fortunately, ''.join intrinsically compensates:

>>> x=[u'\u0fe0']*2
>>> ''.join(x)
u'\u0fe0\u0fe0'
*without* (as one would expect) the GD nuisance of converting x's items 
to str (hellishly hard to document accurately and clearly, but 
extremely convenient!-).

Which reminds me -- could we have a methodcaller relative to attrgetter 
and itemgetter?  "Sort a list of strings in a case-insensitive way" 
would become *SO* easy with sort(dalist, key=methodcaller('lower'))... 
can't REALLY recommend sort(dalist, key=str.lower) then the items of 
dalist MIGHT be either str or unicode items... (the relevance of 
''.join is that it proves SOMEbody considered it important to deal with 
a list of either str or unicode in the joining context... why not in 
the sorting context then?).

Alex
___
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

[Python-Dev] operator.methodcaller

[Steven Bethard]

On Fri, 11 Mar 2005 19:48:45 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Which reminds me -- could we have a methodcaller relative to attrgetter
> and itemgetter?  "Sort a list of strings in a case-insensitive way"
> would become *SO* easy with sort(dalist, key=methodcaller('lower'))...
> can't REALLY recommend sort(dalist, key=str.lower) then the items of
> dalist MIGHT be either str or unicode items...

I'd like to second this suggestion -- I've run into this problem a few
times.  When you're using a listcomp or genexp, you can inline it of
course, but especially with a lot of functions growing the incredibly
convenient key= arguments in 2.5 (e.g. min, max and the deque
functions if I recall correctly), methodcaller would be a much more
duck-typing friendly way to create such callables.

Steve
-- 
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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

[Python-Dev] comprehension abbreviation (was: Adding any() and all())

[Jim Jewett]

Barry:

> Ping's suggested list comprehension abbreviation, i.e.:

>[x in seq if x] == [x for x in seq if x]

> might help.

Note that the last x shouldn't have to be x.

[x in seq if f(x)] 

is by far my most common syntax error, and 

[x for x in seq if f(x)]

is always what I want instead.
___
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

Re: [Python-Dev] sum()

[Alex Martelli]

On Mar 11, 2005, at 19:39, Raymond Hettinger wrote:
[Alex]
If you're considering revisions to sum's design, my suggestion would
be
to find a way to let the user tell sum to use a more accurate approach
when summing floats.
FWIW, when accuracy is an issue, I use:
   sum(sorted(data, key=abs))
...and you may still lose a LOT of accuracy that way:-(.
Raymond, you technically reviewed the 2nd ed Cookbook -- don't you 
recall the sidebar about why partials are the RIGHT way to do 
summations?  I was SO proud of that one, thought I'd made the issue 
clearest than anywhere previously in print...

To summarize: as we all know, a+b loses significant digits from (say) b 
when abs(a) is much larger than abs(b).  Now, say we're summing a 
million numbers, all positive and roughly the same magnitude.  If we do 
it by total += item (which is basically what sum does), by the time 
we've summed the first 100,000 or so total IS *much larger than item* 
in absolute value -- we're systematically tossing away about 5 digits 
from each new item by that time!!!

To avoid such a massacre of digits, one uses partials -- summing items 
two at a time to get half as many partials, then iterating that idea 
about log2(N) times when summing N items.  Problem is, one needs O(N) 
auxiliary space (assuming one can't just overwrite the incoming 
list/array/whatever).

There's all other kinds of accuracy issues with a+b, but the one 
partials-based summation deals with is numero uno in many real-life 
situations, e.g. when one needs to get (say) the total area from N 
regions, each of roughly the same magnitude, whose areas were 
separately measured -- total length from N segments ditto -- total mass 
of N items ditto -- and so forth.

Alex
___
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

[Python-Dev] Adding any() and all()

[Jim Jewett]

Guido van Rossum:

> Whether to segregate these into a separate module: they are really a
> very small amount of syntactic sugat, and I expect that in most cases,
> instead of importing that module (which totally makes me lose my
> context while editing) I would probably just write the extra line that
> it takes to get the same effect with an explicit for loop and if
> statement.

Is that so bad?

If you plan to use them often, then

from itertools import any, every

is reasonable.  If you only use them once and weren't expecting it
(and want your imports at the top) ... well how awful is it to have 
an extra line or two in your code?

These aren't *really* replacing map/filter/reduce because you're
adding the new functions now, but the old-function removal is 
waiting until (forever?)

A compromise (which may not be worth doing) would be to put
them in another module, and then import them into  __builtins__
if desired.  map/filter/reduce could be moved out (but reimported
for at least 2.5) in the same way, which would make their 
inclusion look more like "standard policy" than "part of the 
language".

[And yes, I know that itertools might be the "wrong" module; I 
just don't remember the name of the module for iteration-related 
tools that happen to return something other than an iterator.]

-jJ
___
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

Re: [Python-Dev] Adding any() and all()

[Barry Warsaw]

On Fri, 2005-03-11 at 14:29, Jim Jewett wrote:

> Is that so bad?
> 
> If you plan to use them often, then
> 
> from itertools import any, every

+1

-Barry



signature.asc
Description: This is a digitally signed message part
___
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

Re: [Python-Dev] Adding any() and all()

[François Pinard]

[Guido van Rossum]

> But I realized (1) any() and all() read much better in their natural
> context (an if statement), and there's no confusion there;

I do not think builtins should read good in some statement contexts and
bad in the others, or designed to be legible in only a few contexts.
This would be a waste.  In other contexts dans `if' or `while',
`any(...)' might be read as "pick one of", in which case a True/False
result might be surprising. `allTrue' (or such) is clearer in all
contexts, even if not as nice in some of them.  For `any(...)' to be
clear in all contexts, it should return one of its arguments.  That
would surely do the proper thing in `if' or `while' context.

We've read various arguments about this idea.  Some (pro or con)
arguments are only valid outside `if' and `while' context, other (pro
and con) arguments are only valid within `if' and `while' context.  If
we are going to dismiss contexts outside `if' and `while', we should not
retain arguments which only apply outside those contexts.

This is my only complain.  The overall idea and principle are good,
especially if they succeed in cleaning out `reduce' and the others.
However, if for compatibility reasons, `reduce' stays, than we are
merely adding other ways, without sparing any, and this means yet
another tiny bloat in Python, that might be better avoided.

> What worries me a bit about doing a PEP for this simple proposal is
> that it might accidentally have the wrong outcome:

Isn't that true of any PEP?  I thought going through a PEP for changes,
and additions just as well, was not far from being a principle.
Depending on opinions, the outcome is right or wrong.

The principle of PEPs is not necessarily a good one in practice, as some
PEPs are forever incomplete or unupdated, miss their role, and then sum
up to having nearly been an annoyance.  Good if PEPs may be avoided! :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca
___
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

Re: [Python-Dev] Adding any() and all()

[John Williams]

Jim Jewett wrote:
Guido van Rossum:
[Why any() and all() shouldn't need to be imported.]
Is that so bad?
If you plan to use them often, then
from itertools import any, every
is reasonable.  If you only use them once and weren't expecting it
(and want your imports at the top) ... well how awful is it to have 
an extra line or two in your code?
The problem with this approach is that any() and all() are so 
fundamental* that you should just use them without thinking about it, 
just as when you use "+" to conctenate strings, you don't have to stop 
and think to yourself, "Ah, this program needs to be able to manipulate 
strings.  I'd better make sure string operations as available in this 
module."  Thinking such thoughts takes you away from thinking about the 
problem you're trying to solve by manipulating strings.

Likewise, programmers solve a lot of problems with boolean expressions, 
and it seems silly to require a special declaration just to make the 
full complement of boolean operations available.  I can think of three 
ways of coping with any() and all() being in a module:

First, I could just not use them.  In that case all the effort here is 
wasted, and my code becomes less readable than it would have been 
otherwise.  This is the approach I usually take with modules like 
"operator", where I can just as easily write a lambda expression (for 
now at least).

Second, I could break my concentration to think about import statements 
every time I have a use for these particular functions.

Third, I could import them at the top of every module.  Since one of the 
distinguishing features of Python in a lack of gratuitous boilerplate 
code everywhere, I would find it very sad to add even a little bit.

So while putting any() and all() into a module isn't that bad in itself, 
 it seems like the start of a slippery slope that has Python at the top 
and C++ at the bottom.

-- jw
*I appreciate the irony of calling something "fundamental" when we've 
all gotten by just fine without it for many years--I'm trying to think 
from the perspective of someone used to dealing with a later (and 
hopefully better) version of Python.
___
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

[Python-Dev] code blocks using 'for' loops and generators

[Brian Sabbey]

I would like to get some feedback on a proposal to introduce 
smalltalk/ruby-like "code blocks" to python.  Code blocks are, among other 
things, a clean way to solve the "acquire/release" problem [1][2].  This 
proposal also touches on some of the problems PEP 288 [3] deals with.

The best discussion I have been able to find on this topic is in the 
thread of ref. [4].

Since generators, when used with 'for' loops, are so similar to code 
blocks [5], one can imagine two ways to implement code blocks in python: 
(1, parallel) keep them as similar as possible to 'for' loops so that a 
normal user doesn't distinguish the two, or (2, orthogonal) make them so 
much different than 'for' loops that the normal user doesn't notice the 
similarities.  Anything between these extremes will probably be confusing. 
Here I will describe an attempt at (1).

(I) Give generators a __call__ method as an alternative to 'next'. 
Method __call__ should take a single parameter: a function.  Using 
__call__ will cause the generator to start executing normally, but when a 
'yield' is reached, the generator will invoke the function passed to 
__call__ instead of activating the currently implemented 'yield' 
mechanism.

Since __call__ will be an alternative to 'next', it will raise an 
exception if 'next' has already been called and vice-versa.  Also, any 
calls to 'next' will raise an exception if there is a 'yield' in the try 
of a try/finally.  Such yields will no longer trigger a SyntaxError 
because they will not a problem when using __call__.

(II) Have a method of generators, __blockcall__, which will be equal to 
__call__, but will only exist if (1) the generator contains a "try/finally 
try" yield, or (2) the user explicitly defines it, for example, with a 
function decorator (@completion_required would be a descriptive name).

Have 'for' loops use __blockcall__ if it is available, and __iter__ 
otherwise.  Pass to __blockcall__ the block of code in the 'for' loop.

Scope rules for the passed block of code should mimic current 'for' loop 
behavior.  Behavior of 'break' and 'return' should be mimicked, perhaps 
with special exceptions catchable only by the 'for' loop.  Mimicking 
'yield' will be a problem unless/until multi-level yields are allowed. 
(performance and implementation difficulties for all of this?  I don't 
know).

The thunk shouldn't be savable for later use because the 'for' loop will 
no longer be around to deal with 'break' and 'return'.  This means that 
__blockcall__ will not be implementable as a function that takes a 
function as an argument.

(III) Allow 'continue' to pass values to 'yield' (something similar 
previously rejected here [6]).  As far as I know, all other control 
statements that transfer execution to a different frame (yield, return, 
raise) pass values, and I don't see why this case should be any different. 
I do not see such a mechanism as gimmicky;  being able to cleanly pass 
values when changing scope is an inherent part of nearly every programming 
language.

As an example of the syntax I am suggesting, here is something I was 
desiring recently, a generator to open, unpickle, repickle and close a 
file:

def pickled_file(name):
f = open(name, 'r')
l yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(l, f)
f.close()
The unpickled object is sent to the caller at the yield statement, and the 
modified object is received back at the same statement.  Note the 
suggested 'yield' syntax and the conspicuous absence of '='.  This syntax 
is backwardly compatible with current yield syntax.  Also, this syntax 
does not require yield to appear as a function; it is still clear that 
this is a unique control-flow statement.

This function would be used like this:
for l in pickled_file('greetings.pickle'):
l.append('hello')
l.append('howdy')
continue l
The above code would have the same effect as:
def named(l):
l.append('hello')
l.append('howdy')
return l
pickled_file('greetings.pickle')(named)
(IV)  Allow 'yield' to return no value;  in this case a new keyword, 
'with', will be required instead of an awkward 'for':

"with f():"   instead of   "for in f():"
(V)  For the same reasons as in (III), allow generators to return values. 
These values can be sent with the StopIteration exception if 'next' is 
being used for iteration.  An obvious syntax for receiving these values is 
shown by this example:

with dt = stopwatch():
  f()
  g()
print 'it took', dt, 'seconds'
Although "with stopwatch() result dt:" might not be so bad.
[1] PEP 310 Reliable Acquisition/Release Pairs
http://www.python.org/peps/pep-0310.html
[2] PEP 325 Resource-Release Support for Generators
http://www.python.org/peps/pep-0325.html
[3] PEP 288 Generators Attributes and Exceptions
http://www.python.org/peps/pep-0288.html
[4] http://mail.python.org/pipermail/python-dev/2003-February/032800.html
[5] http://mail.python.org/pipermail/python

Re: [Python-Dev] operator.methodcaller

[James Y Knight]

On Mar 11, 2005, at 2:02 PM, Steven Bethard wrote:
On Fri, 11 Mar 2005 19:48:45 +0100, Alex Martelli <[EMAIL PROTECTED]> 
wrote:
Which reminds me -- could we have a methodcaller relative to 
attrgetter
and itemgetter?  "Sort a list of strings in a case-insensitive way"
would become *SO* easy with sort(dalist, key=methodcaller('lower'))...
can't REALLY recommend sort(dalist, key=str.lower) then the items of
dalist MIGHT be either str or unicode
I'd like to second this suggestion -- I've run into this problem a few
times.  When you're using a listcomp or genexp, you can inline it of
course, but especially with a lot of functions growing the incredibly
convenient key= arguments in 2.5 (e.g. min, max and the deque
functions if I recall correctly), methodcaller would be a much more
duck-typing friendly way to create such callables.
Yeah, if *only* we had some way to create callables in a nice, short, 
generic, and easy to understand way.

How about this proposal:
>> sort(dalist, key=lambda x: x.lower())
Who wants to make a PEP for it? Maybe we can add it in Python 3000.
James
___
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

Re: [Python-Dev] sum()

[Raymond Hettinger]

[Alex]
> > FWIW, when accuracy is an issue, I use:
> >
> >sum(sorted(data, key=abs))
> 
> ...and you may still lose a LOT of accuracy that way:-(.
> 
> Raymond, you technically reviewed the 2nd ed Cookbook -- don't you
> recall the sidebar about why partials are the RIGHT way to do
> summations?  I was SO proud of that one, thought I'd made the issue
> clearest than anywhere previously in print...

No doubt about it.  Partials are superior.  My little snippet meets my
needs with no fuss -- my usual situation is many small values whose
accuracy gets clobbered upon encountering a handful of large values.

In the draft statistics module, nondist/sandbox/statistics/statistics.py
,
I used yet another approach and tracked a separate error term.  The
advantage is adding precision while still keeping O(n) summation speed.

Of course, we can always use the decimal module to add as much precision
as needed.


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

[Python-Dev] distutils fix for building Zope against Python 2.4.1c1

[Trent Mick]

http://mail.python.org/pipermail/python-checkins/2005-March/045185.html

Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
this was the same problem. (Still checking to see if this change fixes
the PyWin32 build for me.)  In any case, this change should also make it
to the trunk, right?

Trent

-- 
Trent Mick
[EMAIL PROTECTED]
___
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

[Python-Dev] Re: distutils fix for building Zope against Python 2.4.1c1

[Tim Peters]

[Trent Mick]
> http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
> 
> Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
> this was the same problem. (Still checking to see if this change fixes
> the PyWin32 build for me.)

Be sure to speak up if it doesn't!  Any build that invokes the C
compiler often on Windows would have the same problem.

> In any case, this change should also make it to the trunk, right?

Don't think it's needed on HEAD.  As the checkin comment said:

This doesn't appear to be an issue on the HEAD (MSVCCompiler initializes
itself via __init__() on the HEAD).

I verified by building Zope with unaltered HEAD too, and had no
problem with that.
___
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

Re: [Python-Dev] rationale for the no-new-features approach

[Skip Montanaro]

Bob> try:
Bob>  set
Bob> except NameError:
Bob>  from sets import Set as set

Bob> You don't need the rest.

Sure, but then pychecker bitches about a statement that appears to have no
effect. ;-)

Skip

___
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

Re: [Python-Dev] rationale for the no-new-features approach

[Bob Ippolito]

On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote:
Bob> try:
Bob>  set
Bob> except NameError:
Bob>  from sets import Set as set
Bob> You don't need the rest.
Sure, but then pychecker bitches about a statement that appears to 
have no
effect. ;-)
Well then fix PyChecker to look for this pattern :)
-bob
___
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

Re: [Python-Dev] distutils fix for building Zope against Python 2.4.1c1

[Trent Mick]

[Trent Mick wrote]
> 
> http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
> 
> Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
> this was the same problem. (Still checking to see if this change fixes
> the PyWin32 build for me.
> ...

It doesn't. Investigating...

Trent

-- 
Trent Mick
[EMAIL PROTECTED]
___
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

Re: [Python-Dev] Adding any() and all()

[M.-A. Lemburg]

Guido van Rossum wrote:
Here's my take on the key issues brought up:
Alternative names anytrue(), alltrue(): before I posted to my blog I
played with these names (actually anyTrue(), allTrue(), anyFalse(),
allFalse()). But I realized (1) any() and all() read much better in
their natural context (an if statement), and there's no confusion
there; (2) anyFalse() and allFalse() are redundant, so there's no need
to distinguish between anyTrue() and anyFalse(). (To the person who
wondered why we default to True: because 'if' tests for True, duh. :-)
I've been using exists() and forall() in mxTools for years.
The names originate from math usage, where you often
use these qualifiers.
A note on builtins: Most tools in mxTools automatically
get registered as builtins when you load the module. The
motivation for this was that wanted to have easy access
to these often used APIs.
However, a few years down the line I realized that this
kind of usage just causes confusion when you read code:
* it is not clear where the APIs originate
* the code dependencies are not longer easily visible
Ever since, I've switched to making all use of these
functions explicit with reference to the mx.Tools
module.
http://www.egenix.com/files/python/mxTools.html
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Mar 12 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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

Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())

[Nick Coghlan]

Jim Jewett wrote:
Note that the last x shouldn't have to be x.
[x in seq if f(x)] 

is by far my most common syntax error, and 

[x for x in seq if f(x)]
is always what I want instead.
That 'x in seq' bit still shouts "containment" to me rather than iteration, 
though.
Perhaps repurposing 'from':
  (x from seq if f(x))
That rather breaks TOOWTDI though (since it is essentially new syntax for a for 
loop). And I have other hopes for the meaning of (x from ()). . .

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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

[Python-Dev] Python2.4.1c1 and win32com

[Leeuw van der, Tim]

Hi,

Win32com generates Python-files for use with com interfaces, using the 
make-py.py utility.

The generated files are OK with Python2.3.5

The generated files crash the Python interpreter with Python 2.4

Under Python 2.4.1c1, They give a syntax error!?

The files unfortunately are very big, nearly 2Mb each, although they compress 
very well (270Kb).

The errors given are for one file:

"D:\Python24\lib\site-packages\win32com\gen_py\00020905---C000-0046x0x8x1.py",
 line 3025
"StyleName": (3, 2, (8, 0), (), "StyleName", None),
"Value": (0, 2, (8, 0), (), "Value", None),
   ^
SyntaxError: invalid syntax
(The marker is in the middle of 'None')

And for the other file:
  File 
"D:\Python24\lib\site-packages\win32com\gen_py\00020813---C000-0046x0x1x3.py",
 line 2591
return ret
  ^
SyntaxError: invalid syntax


At least the interpreter no longer crashes, but I'm very surprised that this 
gives syntax errors when the exact same files do compile with Python 2.3.5 (To 
be sure, I generated the files using Python2.3.5, then copied them to the 
2.4.1c1 installation, and then tried to have them compiled.)

Eyeballing the files, I can definately not see any syntax errors.


Anyone who can help or offer any suggestions?

Please CC me on any replies b/c I'm not subscribed to the list.

regards,

--Tim


___
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

[Python-Dev] Lambda & deferred evaluation (was: Adding any() and all())

[Nick Coghlan]

Barry Warsaw wrote:
On Fri, 2005-03-11 at 12:18, Raymond Hettinger wrote:
Lambda will be more difficult.  Eric Raymond adapted an anti-gun control
slogan and said "you can pry lambda out of my cold dead hands."  A bunch
of folks will sorely miss the ability to create anonymous functions on
the fly.  When lambda is used for deferred argument evaluation (a la PEP
312), the def syntax is a crummy substitute.

Yeah, I'm with you here.  As warty as lambda is, it just is so damn
convenient some times.  I've recently been using it as a companion to
property(), providing concise definitions of read-only attributes.
I'm hoping that "lambda goes in Python3K" will get rid of the *existing* lambda, 
so that a more Pythonic syntax for deferred evaluation can be found. At the 
moment, any such attempt to come up with an alternate syntax tends to get 
shouted down on the basis that "you can already use lambda, TOOWTDI, stop 
wasting time".

I see the *feature* as useful, but the current syntax as lousy. If it was a PEP, 
the latter would be grounds for rejection of lambda expressions (such as 
happened to PEP 308).

A collection of alternate suggestions did get posted to the Wiki though (my 
personal favourite is "( from )"): 
http://www.python.org/moin/AlternateLambdaSyntax

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2

[Kurt B. Kaiser]

Anthony Baxter <[EMAIL PROTECTED]> writes:

> On Thursday 10 March 2005 03:48, Fred L. Drake, Jr. wrote:
>>  > RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/idlever.py,v
>>  > -IDLE_VERSION = "1.1.1"
>>  > +IDLE_VERSION = "1.1.1c1"
>>
>> Shouldn't this progress from 1.1.1 to 1.1.2c1?  Otherwise it's moving
>> backward.
>
> No - Py2.4 shipped with idle 1.1. I must've updated it to 1.1.1 sometime
> after the 2.4 release (I vaguely recall doing this).

To eliminate this confusion I'd propose either 

1. Eliminating the separate IDLE versioning now that it's installed with
   Python when Tcl/Tk is available.

or 

2. Bringing its version in sync with Python 2.5.

I'm in favor of the latter, to handle the situation where a customized
IDLE is decoupled from Python.

-- 
KBK
___
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

Re: [Python-Dev] distutils fix for building Zope against Python 2.4.1c1

[Trent Mick]

[Trent Mick wrote]
> [Trent Mick wrote]
> > 
> > http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
> > 
> > Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
> > this was the same problem. (Still checking to see if this change fixes
> > the PyWin32 build for me.
> > ...
> 
> It doesn't. Investigating...

Investigation has turned up that I cannot keep my Python trees straight.
That patch *does* fix building PyWin32 against 2.4.1c1.

Cheers,
Trent

-- 
Trent Mick
[EMAIL PROTECTED]
___
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

Re: [Python-Dev] distutils fix for building Zope against Python 2.4.1c1

[Tim Peters]

[Trent Mick]
> Investigation has turned up that I cannot keep my Python trees straight.
> That patch *does* fix building PyWin32 against 2.4.1c1.

Good!  Please send a check for US$1000.00 to the PSF by Monday .
___
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

RE: [Python-Dev] Python2.4.1c1 and win32com

[Tony Meyer]

> Win32com generates Python-files for use with com interfaces, 
> using the make-py.py utility.
> 
> The generated files are OK with Python2.3.5
> 
> The generated files crash the Python interpreter with Python 2.4
> 
> Under Python 2.4.1c1, They give a syntax error!?
> 
> The files unfortunately are very big, nearly 2Mb each, 
> although they compress very well (270Kb).
[...]
> Anyone who can help or offer any suggestions?

I believe this is a pywin32 bug, which has been fixed in (pywin32) CVS and
will be fixed for the next build.  It's certainly a probably with 2.4.0 as
well as 2.4.1.

The pywin32 mailing list archives have more details, as do the tracker for
the project: .

=Tony.Meyer

___
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

Re: [Python-Dev] Memory Allocator Part 2: Did I get it right?

[Evan Jones]

On Mar 4, 2005, at 23:55, Brett C. wrote:
Evan uploaded the newest version (@ http://www.python.org/sf/1123430) 
and he says it is "complete".
I should point out (very late! It's been a busy couple of weeks) that I 
fully expect that there may be some issues with the patch that will 
arise when it is reviewed. I am still lurking on Python-Dev, and I will 
strive to correct any defects ASAP. A few users have contacted me 
privately and have tested the patch, so it works for a few people at 
least.

Evan Jones
___
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

Re: [Python-Dev] sum()

[Tim Peters]

FYI, there are a lot of ways to do accurate fp summation, but in
general people worry about it too much (except for those who don't
worry about it at all -- they're _really_ in trouble <0.5 wink>).

One clever way is to build on that whenever |x| and |y| are within a
factor of 2 of each other, x+y is exact in 754 arithmetic.  So you
never lose information (not even one bit) when adding two floats with
the same binary exponent.  That leads directly to this kind of code:

from math import frexp

class Summer:
def __init__(self):
self.exp2sum = {}

def add(self, x):
while 1:
exp = frexp(x)[1]
if exp in self.exp2sum:
x += self.exp2sum.pop(exp) # exact!
else:
break
self.exp2sum[exp] = x # trivially exact

def total(self):
items = self.exp2sum.items()
items.sort()
return sum((x for dummy, x in items), 0.0)

exp2sum maps a binary exponent to a float having that exponent.  If
you pass a sequence of fp numbers to .add(), then ignoring
underflow/overflow endcases, the key invariant is that the exact
(mathematical) sum of all the numbers passed to add() so far is equal
to the exact (mathematical) sum of exp2sum.values().  While it's not
obvious at first, the total number of additions performed inside add()
is typically a bit _less_ than the total number of times add() is
called.

More importantly, len(exp2sum) can never be more than about 2K.  The
worst case for that is having one input with each possible binary
exponent, like 2.**-1000 + 2.**-999 + ... + 2.**999 + 2.**1000.  No
inputs are like that in real life, and exp2sum typically has no more
than a few dozen entries.

total() then adds those, in order of increasing exponent == in order
of increasing absolute value.  This can lose information, but there is
no bad case for it, in part because there are typically so few
addends, and in part because that no two addends have the same binary
exponent implies massive cancellation can never occur.

Playing with this can show why most fp apps shouldn't worry most
often.  Example:

Get a million floats of about the same magnitude:

>>> xs = [random.random() for dummy in xrange(100)]

Sum them accurately:

>>> s = Summer()
>>> for x in xs:
... s.add(x)

No information has been lost yet (if you could look at your FPU's
"inexact result" flag, you'd see that it hasn't been set yet), and the
million inputs have been squashed into just a few dozen buckets:

>>> len(s.exp2sum)
22
>>> from pprint import pprint
>>> pprint(s.exp2sum)
{-20: 8.8332388070710977e-007,
 -19: 1.4206079529399673e-006,
 -16: 1.0065260162672729e-005,
 -15: 2.4398649189794064e-005,
 -14: 5.3980784313178987e-005,
 -10: 0.00074737138777436485,
 -9: 0.0014605198999595448,
 -8: 0.003361820812962546,
 -7: 0.0063811680318408559,
 -5: 0.016214300821313588,
 -4: 0.044836286041944229,
 -2: 0.17325355843673518,
 -1: 0.46194788522906305,
 3: 6.4590200674982423,
 4: 11.684394209886134,
 5: 24.715676913177944,
 6: 49.056084672323166,
 10: 767.69329043309051,
 11: 1531.1560084859361,
 13: 6155.484212371357,
 17: 98286.760386143636,
 19: 393290.34884990752}

Add those 22, smallest to largest:

>>> s.total()
500124.06621686369

Add the originals, "left to right":

>>> sum(xs)
500124.06621685845

So they're the same to about 14 significant decimal digits.  No good
if exact pennies are important, but far more precise than real-world
measurements.

How much does sorting first help?

>>> xs.sort()
>>> sum(xs)
500124.06621685764

Not much!  It actually moved a bit in the wrong direction (which is
unusual, but them's the breaks).

Using decimal as a (much more expensive) sanity check:

>>> import decimal
>>> t = decimal.Decimal(0)
>>> for x in xs:
... t += decimal.Decimal(repr(x))
>>> print t
500124.0662168636972127329455

Of course  Summer's result is very close to that.
___
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

Re: [Python-Dev] sum()

[Tim Peters]

[Tim Peters]
...
> One clever way is to build on that whenever |x| and |y| are within a
> factor of 2 of each other, x+y is exact in 754 arithmetic.

Ack, I'm fried.  Forget that, it's wrong.  The correct statement is
that x-y is always exact whenever x and y are within a factor of two
of each other.  Summer.add() _can_ lose info -- it needs additional
trickery to make it loss-free, and because x+y can lose (at most one
bit) when x and y have the same binary exponent.

Exercise for the abused reader .
___
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

[Python-Dev] func.update_meta (was: @deprecated)

[Nick Coghlan]

Reinhold Birkenfeld wrote:
Nick Coghlan wrote:
A utility method on function objects could simplify this:
  newFunc.update_info(func)

+1. This is really good for 90% of all decorator uses. But maybe a
better name should be found, perhaps "update_meta".
I like "update_meta"
Patch against current CVS added to SF with the behaviour:
  def update_meta(self, other):
self.__name__ = other.__name__
self.__doc__ = other.__doc__
self.__dict__.update(other.__dict__)
http://www.python.org/sf/1161819
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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

Re: [Python-Dev] Python2.4.1c1 and win32com

[Brian Dorsey]

On Sat, 12 Mar 2005 15:31:03 +1300, Tony Meyer <[EMAIL PROTECTED]> wrote:
> > Win32com generates Python-files for use with com interfaces,
> > using the make-py.py utility.
> >
> > The generated files are OK with Python2.3.5
> >
> > The generated files crash the Python interpreter with Python 2.4
> I believe this is a pywin32 bug, which has been fixed in (pywin32) CVS and
> will be fixed for the next build.  It's certainly a probably with 2.4.0 as
> well as 2.4.1.
> 
> The pywin32 mailing list archives have more details, as do the tracker for
> the project: .

Here is a link to the specific (closed) bug:
http://sourceforge.net/tracker/?func=detail&aid=1085454&group_id=78018&atid=551954

And, in case you can't update to the CVS pywin32 for some reason,
there is a work-around listed in the bug.

Take care,
-Brian
___
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

Re: [Python-Dev] code blocks using 'for' loops and generators

[Josiah Carlson]

Brian Sabbey <[EMAIL PROTECTED]> wrote:
> I would like to get some feedback on a proposal to introduce 
> smalltalk/ruby-like "code blocks" to python.  Code blocks are, among other 
> things, a clean way to solve the "acquire/release" problem [1][2].  This 
> proposal also touches on some of the problems PEP 288 [3] deals with.

[...]

My first reaction to the proposal was "ick".  Why?  Because every time
I've seen a mechanism for modifying the internals of generators
constructed using yield, the syntax has been awful; in my opinion
(whether my opinion means anything is another matter), the syntax you
propose is quite awful, and the functionality you desire does not
require syntax modification to be possible.

Strawman 1: the syntax

def pickled_file(name):
 f = open(name, 'r')
 l yield pickle.load(f)
 ^
--
|f.close()
|f = open(name, 'w')
|pickle.dump(l, f)
|f.close()
|
While this is currently a syntax error, it is not clear that an
assignment is happening /at all/, and I don't believe it would be /even
if/ if were documented, and every time someone opened up Python it said
"This is an assignment!" with an example. It looks too magical to me
(and from a guy who had previously proposed 'Some' as the opposite of
'None', that's saying something).


Strawman 2: putting data back into a generator

def pickled_file(name):
 f = open(name, 'r')
 yield pickle.load(f)
 f.close()
 f = open(name, 'w')
 pickle.dump(l, f)
 f.close()

Keep your code, except toss that leading 'l'.

for l in pickled_file('greetings.pickle'):
 l.append('hello')
 l.append('howdy')

Toss that 'continue l', and your code will work (as long as both the
function and the for are sitting in the same namespace).

Hrm, not good enough?  Use a Queue, or use another variable in a
namespace accessable to both your function and your loop.

Strawman 3: there is no strawman 3, but all lists need to have at least
3 items


I'm sorry if this email comes off harsh,
 - Josiah

___
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

Re: [Python-Dev] Adding any() and all()

[Hugh Secker-Walker]

Hello Folks,

I've been lurking here for several months.  I've been using Python for
several years for prototyping fun.  And I'm one of the architects of
its extensive use in research, engineering development, and testing on
a large, commercial speech-recognition system.  I know a lot about
modeling mammalian auditory physiology.  And I have a relatively-large
collection of photos of Tim Peters.


> Raymond Hettinger:
> Will leave it open for discussion for a bit so that folks can voice
> any thoughts on the design.

Ignoring the important naming issues, I have two comments about the
any() and all() ideas:

1. I'm surprised that no one has suggested adding supporting unary
   methods to object, returning a boolean.  If __any__ and __all__
   existed, then containers that observed that their contents were
   immutable could rely on a single counter, self._numtrue, to
   implement the any and all operations in O(0) time via appropriate
   comparisons with __len__() (plus the amortized cost of maintaining
   self._numtrue).  Of course builtin containers could or will do this
   anyway.

2. In an offline discussion about using any() and all() a couple of us
   noticed their similarity to the containment operator 'in'.  Taking
   this idea as far as it can go in Python as we know it, you could
   introduce new keywords, 'any' and 'all', and corresponding byte
   codes dispatching to __any__ and __all__, giving the emminently
   readable usages:

   if any x:
   ...

   if not all y:
   ...

   This latter idea may be far-fetched.  But if there's any chance it
   would happen, it adds a twist to the naming issue.  Were this
   syntax introduced after any() and all() were available as builtins,
   simple use of 'any(blah)' would still work, but references to the
   no-longer-rare tokens 'any' and 'all', e.g. as functional objects,
   would, of course, no longer compile.

-Hugh

___
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

Re: [Python-Dev] Adding any() and all()

[Brett C.]

Jim Jewett wrote:
Guido van Rossum:

Whether to segregate these into a separate module: they are really a
very small amount of syntactic sugat, and I expect that in most cases,
instead of importing that module (which totally makes me lose my
context while editing) I would probably just write the extra line that
it takes to get the same effect with an explicit for loop and if
statement.

Is that so bad?
If you plan to use them often, then
from itertools import any, every
is reasonable.  If you only use them once and weren't expecting it
(and want your imports at the top) ... well how awful is it to have 
an extra line or two in your code?

Basically the question (at least in my mind) when it comes to built-ins is 
whether the usage is so basic and fundamental that sticking them in a module is 
done more for rigid organization than for convenience.  Personally, I think 
any() and all() meet this requirement.  With their ties to basic boolean 
testing they should be built into the language and not just a part of the 
stdlib.  If I am banging something out at a interpreter prompt I will want 
these functions easily accessible and I won't think of them as something to 
import.  This probably comes off as wishy-washy, but it is just what my mind is 
spitting out at the moment.

They also have the feeling as something that could be useful as a syntax 
(although I am just suggesting syntactic support!).  Which could be an even 
better way to measure whether something should be a built-in.  Would the 
function be useful as a syntactic addition to the language, but just can't 
quite reach the need of a new keyword?  Once again any() and all() feel like 
that to me.

These aren't *really* replacing map/filter/reduce because you're
adding the new functions now, but the old-function removal is 
waiting until (forever?)

Even if Python 3000 comes out a while from now, why wait?  Two more is not that 
much.  Besides, it isn't like we are adding functions as some crazy rate.  And 
Guido has stated that the 2.x branch stops once 2.9 (if it goes that long) 
comes out.  So at worst you only have to worry about 5 more releases to worry.  =)

-Brett
___
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