[Python-Dev] make iter() return an empty iterator?

[Georg Brandl]

Sure, you could use ``iter(())`` or ``iter([])``, but for consistency's sake
wouldn't it make sense for ``iter()`` to return an empty iterator, as ``str()``
returns an empty string etc.?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] make iter() return an empty iterator?

[Andrew Bennetts]

Georg Brandl wrote:
> Sure, you could use ``iter(())`` or ``iter([])``, but for consistency's sake
> wouldn't it make sense for ``iter()`` to return an empty iterator, as 
> ``str()``
> returns an empty string etc.?

I had no idea that "str()" or "int()" would do that.  "file()" certainly
doesn't! :)

I don't really think there's much reason to make "iter()" work.  As you say,
"iter([])" works just fine.  For those rare times you want an empty iterator, I
don't think the two extra characters is much of a price to pay.

-Andrew.

___
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] make iter() return an empty iterator?

[Steve Holden]

Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> On 8/3/07, *Facundo Batista* <[EMAIL PROTECTED] 
> > wrote:
> 
> 2007/8/3, Andrew Bennetts <[EMAIL PROTECTED]
> >:
> 
>  > I don't really think there's much reason to make "iter()"
> work.  As you say,
> 
> What bad thing could happen if we make iter() work? If nothing, we
> should ask ourselves: which is the more intuitive behaviour to expect
> of iter()? To raise an exception or to return an empty iterator?
> 
> I'm +0 for the latter.
> 
> 
> -1.  I'm a heavy user of iterators on finite and infinite streams and, 
> for me, iter() is an error that I do not want to paper over.  The 
> alternate logic implies, e.g ., len() should return 0.
> 
-1 here too. iter() should have an argument just like sum() and len().

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

___
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] NotImplemented comparisons

[Facundo Batista]

2007/8/2, Facundo Batista <[EMAIL PROTECTED]>:

> > Given that you 'should' return an int, doing elsewise has undefined
> > results.
>
> I'll fix decimal to always return sane values from __cmp__, :)

Done, thanks again everybody!

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] Pythreads and BSD descendants

[Jon Ribbens]

On Thu, Jul 26, 2007 at 04:08:37PM +, Cameron Laird wrote:
> Folklore that I remember so unreliably I avoid trying to repeat it here
> held that Python threading had problems on BSD and allied Unixes.  What's
> the status of this?  I suspect the answer is, "Everything works, and the
> only real problem ever was that *signals* have different semantics under
> Linux and *BSD."  Anyone who can answer explicitly, though, would repre-
> sent a help to me.

This is just my personal opinion, but I suspect that this is perhaps
because people have *tried* threading more in Python than in many
other languages, because Python makes it particularly easy.

I've certainly had the experience that multithreaded stuff I have
tried has sometimes had problems under various OSes (Linux, Solaris,
OpenBSD, etc) due to operating system bugs with threading in general
rather than Python problems per se.
___
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] make iter() return an empty iterator?

[Kevin Jacobs <[EMAIL PROTECTED]>]

On 8/3/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/8/3, Andrew Bennetts <[EMAIL PROTECTED]>:
>
> > I don't really think there's much reason to make "iter()" work.  As you
> say,
>
> What bad thing could happen if we make iter() work? If nothing, we
> should ask ourselves: which is the more intuitive behaviour to expect
> of iter()? To raise an exception or to return an empty iterator?
>
> I'm +0 for the latter.
>

-1.  I'm a heavy user of iterators on finite and infinite streams and, for
me, iter() is an error that I do not want to paper over.  The alternate
logic implies, e.g., len() should return 0.

-Kevin
___
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] Pythreads and BSD descendants

[Paul Colomiets]

Cameron Laird wrote:
> Folklore that I remember so unreliably I avoid trying to repeat it here
> held that Python threading had problems on BSD and allied Unixes.  What's
> the status of this?  I suspect the answer is, "Everything works, and the
> only real problem ever was that *signals* have different semantics under
> Linux and *BSD."  Anyone who can answer explicitly, though, would repre-
> sent a help to me.
>   
I use Python with multithreading applications on FreeBSD
for several years, and really single problem I've discovered
is that default stack size for new threads is small for the
default recursion limit. It can be easily fixed in Python 2.5.

Apart from that everything works OK for me.

___
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] make iter() return an empty iterator?

[Facundo Batista]

2007/8/3, Andrew Bennetts <[EMAIL PROTECTED]>:

> I don't really think there's much reason to make "iter()" work.  As you say,

What bad thing could happen if we make iter() work? If nothing, we
should ask ourselves: which is the more intuitive behaviour to expect
of iter()? To raise an exception or to return an empty iterator?

I'm +0 for the latter.

--
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] make iter() return an empty iterator?

[Guido van Rossum]

On 8/3/07, Steve Holden <[EMAIL PROTECTED]> wrote:
> Kevin Jacobs <[EMAIL PROTECTED]> wrote:
> > On 8/3/07, *Facundo Batista* <[EMAIL PROTECTED]
> > > wrote:
> >
> > 2007/8/3, Andrew Bennetts <[EMAIL PROTECTED]
> > >:
> >
> >  > I don't really think there's much reason to make "iter()"
> > work.  As you say,
> >
> > What bad thing could happen if we make iter() work? If nothing, we
> > should ask ourselves: which is the more intuitive behaviour to expect
> > of iter()? To raise an exception or to return an empty iterator?
> >
> > I'm +0 for the latter.
> >
> >
> > -1.  I'm a heavy user of iterators on finite and infinite streams and,
> > for me, iter() is an error that I do not want to paper over.  The
> > alternate logic implies, e.g ., len() should return 0.
> >
> -1 here too. iter() should have an argument just like sum() and len().

Amen.

-- 
--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] make iter() return an empty iterator?

[Ron Adam]

Georg Brandl wrote:
> Sure, you could use ``iter(())`` or ``iter([])``, but for consistency's sake
> wouldn't it make sense for ``iter()`` to return an empty iterator, as 
> ``str()``
> returns an empty string etc.?
> 
> Georg

There is a difference.

 >>> type(iter)

 >>> type(str)

 >>> type(int)

 >>> type(list)


Cheers,
Ron

___
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] Pythreads and BSD descendants

[Cameron Laird]

Folklore that I remember so unreliably I avoid trying to repeat it here
held that Python threading had problems on BSD and allied Unixes.  What's
the status of this?  I suspect the answer is, "Everything works, and the
only real problem ever was that *signals* have different semantics under
Linux and *BSD."  Anyone who can answer explicitly, though, would repre-
sent a help to me.
___
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] [Python-3000] interaction between locals, builtins and except clause

[Eduardo \"EdCrypt\" O. Padoan]

On 7/26/07, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
> Porting to Py3K, I modified a function like the followin, using a
> trick for it working in Py2.x .
>
> def __iter__(self):
> if self == _mpi.INFO_NULL:
> return
> try:range = xrange
> except: pass
> nkeys = _mpi.info_get_nkeys(self)
> for nthkey in range(nkeys):
> yield _mpi.info_get_nthkey(self, nthkey)
>
> However, I've got in my unittests (running with py3k)
>
> ERROR: testPyMethods (__main__.TestInfo)
> --
> Traceback (most recent call last):
>   File "tests/unittest/test_info.py", line 123, in testPyMethods
> for key in INFO:
>   File "/u/dalcinl/lib/python/mpi4py/MPI.py", line 937, in __iter__
> for nthkey in range(nkeys):
> UnboundLocalError: local variable 'range' referenced before assignment
>
>
> I am not completelly sure if this is expected (it is, regarding
> implementation, but perhaps not regarding Python as a language),  so
> I post this for your consideration.
>

Python thinnks range is local, because you referenced it, even if an
error ocurred. Use 'global range' at the top of the file.

But, as I understand, you are trying to target both Python 2.x and 3
with the same code, using tricks like this one. I think that, even if
you succeed, the resulting code will be quite unmaintainable.

-- 
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
___
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] Building Python with CMake

[Alexander Neundorf]

On Friday 13 July 2007 16:11, Giovanni Bajo wrote:
...
> Because it would be a single unified build system instead of having two
> build systems like we have one (UNIX and Windows).
>
> Also, it would be much easier to maintain because Visual Studio projects
> are generated from a simple description, while right now if you want to
> change something you need to go through the hassle of defining it within
> the Visual Studio GUI.
>
> Consider for instance if you want to change the Windows build so that a
> builtin module is compiled as an external .pyd instead. Right now, you need
> to go through the hassle of manually defining a new project, setting all
> the include/libraries dependencies correctly, ecc. ecc. With CMake or a
> similar tool, it would be a matter of a couple of textual line changes.
>
> [ I'll also remember that "ease of maintanance for developers" is the #1
> reason for having a 2.1Mb python25.dll under Windows, which I would really
> love to reduce. ]

I thought I'll keep you updated, so:

attached you can find the current cmake files I use for Python 2.5.1.
They work for eCos, Linux, BlueGene and Windows (which doesn't mean everything 
is supported or installed, but they create working python interpreters and 
libs and install the most required files).

Compared to the first version they now contain more install rules, the 
platform path is not hardcoded anymore and it contains a basic setup for 
creating source and binary packages (tgz, Debian, Nullsoft installer, 
PackageMaker depending on your cmake version).

Bye
Alex


Python-2.5.1-cmakefiles.tar.gz
Description: application/tgz
___
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] Pythreads and BSD descendants

[Martin v. Löwis]

Cameron Laird schrieb:
> Folklore that I remember so unreliably I avoid trying to repeat it here
> held that Python threading had problems on BSD and allied Unixes.  What's
> the status of this?

The problem that people run into again and again is the stack size. The
BSDs allow for so little stack so that even the quite conservative
estimates of Python as to how many recursions you can have are
incorrect, and you get an interpreter crash rather than a RuntimeError
(as you should).

Furthermore, every time we decrease the that number, the next system
release somehow manages to make the limit even smaller. This was
never properly analyzed; I suspect that the stack usage of Python
increases, either due to compiler changes or due to change to Python
itself.

Another annoyance is the ongoing battle with Posix; the BSDs have
not been very accepting towards Posix for many years. This resulted
in an interpretation of Posix where defining _XOPEN_SOURCE hides
many system interfaces, resulting in these system interfaces either
not being present, or compilation to fail. I consider this a bug
in the system: compilation should *never* fail if you define
_XOPEN_SOURCE, and additional interfaces should be available if
requested (that requires a way to request them). The work-around
was to not define _XOPEN_SOURCE for those buggy system releases,
hoping that the next release would fix the bug. Over the years,
the maintainers of these systems seem to have come to a better
understanding, so they offer various custom _SOURCE macros
(_NETBSD_SOURCE, __BSD_VISIBLE). The latest addition here was
OpenBSD, which now supports _BSD_SOURCE (apparently following a
tradition set by GNU libc, and perhaps others). So I hope this is
fixed for good now (except that FreeBSD may decide to break
__BSD_VISIBLE the same way it got "broken" in OpenBSD, so we
need to add their "official" feature selection macro once we
find out what that is). The same problem exists of course on many
other systems, but those solved the problem long ago (e.g.
_GNU_SOURCE - glibc, _BSD_TYPES - Irix)

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] [Python-3000] optimizing [x]range

[Lisandro Dalcin]

On 8/2/07, Stargaming <[EMAIL PROTECTED]> wrote:
> >> made into an O(1) operation. here's a demo code (it should be trivial
> >> to implement this in CPython)
> [snipped algorithm]

Did you taked into account that your patch is not backward compatible
with py2.5?? Just try to do this with your patch,

$ python
Python 2.5.1 (r251:54863, Jun  1 2007, 12:15:26)
>>> class A:
...   def __eq__(self, other):
... return other == 3
...
>>> A() in xrange(3)
False
>>> A() in xrange(4)
True
>>>

I know, my example is biased, but I have to insist. With this patch,
'a in xrange' will in general not be the same as 'a in range(...)'. I
am fine with this for py3k, but not sure if all people will agree on
this for python 2.6.



-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
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] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  404 open ( +5) /  3847 closed (+11) /  4251 total (+16)
Bugs: 1059 open ( +3) /  6784 closed ( +8) /  7843 total (+11)
RFE :  263 open ( +0) /   295 closed ( +1) /   558 total ( +1)

New / Reopened Patches
__

struni: Fix test_aepack by converting 4cc's to bytes  (2007-07-26)
CLOSED http://python.org/sf/1761465  reopened by  gvanrossum

distutils.util.get_platform() return value on 64bit Windows  (2007-07-27)
   http://python.org/sf/1761786  opened by  Mark Hammond

Some fix abount _WIN32_WINNT  (2007-07-27)
CLOSED http://python.org/sf/1761803  opened by  Hirokazu Yamamoto

struni: test_xml_etree.py  (2007-07-27)
CLOSED http://python.org/sf/1762412  opened by  Joe Gregorio

unable to serialize Infinity or NaN on ARM using marshal  (2007-07-28)
   http://python.org/sf/1762561  opened by  Matthias Klose

struni: test_urllib2, test_cookielib  (2007-07-29)
CLOSED http://python.org/sf/1762940  opened by  Joe Gregorio

socket close fixed  (2007-07-29)
CLOSED http://python.org/sf/1763387  opened by  Hasan Diwan

tiny addition to peephole optimizer  (2007-07-31)
   http://python.org/sf/1764087  opened by  Paul Pogonyshev

Fix for test_socketserver for Py3k  (2007-07-31)
CLOSED http://python.org/sf/1764815  opened by  ??PC??

generic and more efficient removal of unreachable code  (2007-08-01)
   http://python.org/sf/1764986  opened by  Paul Pogonyshev

logging: delay_fh option and configuration kwargs  (2007-08-01)
   http://python.org/sf/1765140  opened by  Chris Leary

small improvement for peephole conditional jump optimizer  (2007-08-01)
   http://python.org/sf/1765558  opened by  Paul Pogonyshev

urllib2-howto - correction  (2007-08-02)
   http://python.org/sf/1765839  opened by  O.R.Senthil Kumaran

improve xrange.__contains__  (2007-08-02)
   http://python.org/sf/1766304  opened by  Stargaming

Fix for test_zipimport  (2007-08-03)
CLOSED http://python.org/sf/1766592  opened by  ??PC??

Make xmlrpc use HTTP/1.1 and keepalive  (2007-08-04)
   http://python.org/sf/1767370  opened by  Donovan Baarda

test_csv struni fixes + unicode support in _csv  (2007-08-03)
   http://python.org/sf/1767398  opened by  Adam Hupp

Patches Closed
__

struni: Fix test_aepack by converting 4cc's to bytes  (2007-07-26)
   http://python.org/sf/1761465  closed by  gvanrossum

struni: Fix test_aepack by converting 4cc's to bytes  (2007-07-26)
   http://python.org/sf/1761465  closed by  gvanrossum

Some fix abount _WIN32_WINNT  (2007-07-27)
   http://python.org/sf/1761803  closed by  mhammond

struni pulldom: Don't use 'types' to check strings  (2007-07-24)
   http://python.org/sf/1759922  closed by  gvanrossum

struni: test_xml_etree.py  (2007-07-27)
   http://python.org/sf/1762412  closed by  loewis

struni: test_urllib2, test_cookielib  (2007-07-28)
   http://python.org/sf/1762940  closed by  gvanrossum

socket close fixed  (2007-07-30)
   http://python.org/sf/1763387  closed by  facundobatista

itertools.getitem()  (2007-07-08)
   http://python.org/sf/1749857  closed by  rhettinger

Fix for test_socketserver for Py3k  (2007-07-31)
   http://python.org/sf/1764815  closed by  gvanrossum

Fix Decimal.sqrt bugs described in #1725899  (2007-06-22)
   http://python.org/sf/1741308  closed by  facundobatista

Fix for test_zipimport  (2007-08-03)
   http://python.org/sf/1766592  closed by  gvanrossum

urllib2 tests pass  (2007-07-16)
   http://python.org/sf/1755133  closed by  gvanrossum

New / Reopened Bugs
___

'exec' does not accept what 'open' returns  (2007-07-28)
   http://python.org/sf/1762972  opened by  Brett Cannon

S.find documentation uses s[start, end] vs. s[start:end]  (2007-07-29)
CLOSED http://python.org/sf/1763149  opened by  Rob

copy 2  (2007-07-30)
   http://python.org/sf/1764044  opened by  robs pythonid

_RLock.__repr__ throws exception  (2007-07-30)
CLOSED http://python.org/sf/1764059  opened by  Greg Kochanski

The -m switch does not use the builtin __main__ module  (2007-07-31)
   http://python.org/sf/1764407  opened by  Nick Coghlan

Decimal comparison with None fails in Windows  (2007-07-31)
CLOSED http://python.org/sf/1764761  opened by  pablohoffman.com

setup.py trashes LDFLAGS  (2007-08-01)
   http://python.org/sf/1765375  opened by  Harald Koenig

poll() returns "status code", not "return code"  (2007-08-02)
   http://python.org/sf/1766421  opened by  sjbrown

os.chmod failure  (2007-08-03)
   http://python.org/sf/1767242  reopened by  rgheck

os.chmod failure  (2007-08-03)
   http://python.org/sf/1767242  opened by  Richard Heck

String.capwords() does not capitalize first word  (2007-08-03)
   http://python.org/sf/1767363  opened by  Saatvik Agarwal

Bugs Closed
___

No docs for list comparison  (2007-07-25)
   http://python.org/sf/1760423  closed by  gbrandl

SSL-ed soc