Re: [Python-Dev] Allowing slicing of iterators

[Nick Coghlan]

Guido van Rossum wrote:
Iterators are for single sequential access. It's a feature that you
have to import itertools (or at least that you have to invoke its
special operations) -- iterators are not sequences and shouldn't be
confused with such.
I agree the semantic difference between an iterable and an iterator is 
important, but I am unclear on why that needs to translate to a syntactic 
difference for slicing, when it doesn't translate to such a difference for 
iteration (despite the *major* difference in the effect upon the object that is 
iterated over). Are the semantics of slicing really that much more exact than 
those for iteration?

Also, would it make a difference if the ability to extract an individual item 
from an iterator through subscripting was disallowed? (i.e. getting the second 
item of an iterator being spelt "itr[2:3].next()" instead of "itr[2]")

Regards,
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] RELEASED Python 2.3.5, release candidate 1

[Anthony Baxter]

On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.5 (release candidate 1).

Python 2.3.5 is a bug-fix release. See the release notes at the website
(also available as Misc/NEWS in the source distribution) for details of
the bugs squished in this release.

Assuming no major problems crop up, a final release of Python 2.3.5 will
follow in about a week's time. 

Python 2.3.5 is the last release in the Python 2.3 series, and is being
released for those people who still need to use Python 2.3. Python 2.4
is a newer release, and should be preferred if possible. From here,
bugfix releases are switching to the Python 2.4 branch - a 2.4.1 will
follow 2.3.5 final.

For more information on Python 2.3.5, including download links for
various platforms, release notes, and known issues, please see:

http://www.python.org/2.3.5

Highlights of this new release include:

  - Bug fixes. According to the release notes, more than 50 bugs 
have been fixed, including a couple of bugs that could cause 
Python to crash. 

Highlights of the previous major Python release (2.3) are available 
from the Python 2.3 page, at

http://www.python.org/2.3/highlights.html

Enjoy the new release,
Anthony

Anthony Baxter
[EMAIL PROTECTED]
Python Release Manager
(on behalf of the entire python-dev team)


pgp2S8sRF5Q6Y.pgp
Description: PGP signature
___
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] Speed up function calls

[Walter Dörwald]

Neal Norwitz wrote:
> [...]
This is the python test coverage:

http://coverage.livinglogic.de/coverage/web/selectEntry.do?template=2850&entryToSelect=182530
This link won't work because of session management. To get the
coverage info of ceval.c go to http://coverage.livinglogic.de,
click on the latest run, enter "ceval" in the "Filename" field,
click "Search" and click on the one line in the search result.
Bye,
   Walter Dörwald
___
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] Speed up function calls

[Raymond Hettinger]

> I agree that METH_O and METH_NOARGS are near
> optimal wrt to performance.  But if we could have one METH_UNPACKED
> instead of 3 METH_*, I think that would be a win.
 . . .
> Sorry, I meant eliminated w/3.0. 

So, leave METH_O and METH_NOARGS alone.  They can't be dropped until 3.0
and they can't be improved speedwise.



> > * not handling more than nine arguments,
> 
> There are very few functions I've found that take more than 2
arguments.

It's not a matter of how few; it's a matter of imposing a new, arbitrary
limit where none previously existed.  This is not a positive point for
the patch.



> Ultimately, I think we can speed things up more by having 9 different
> op codes, ie, one for each # of arguments.  CALL_FUNCTION_0,
> CALL_FUNCTION_1, ...
> (9 is still arbitrary and subject to change)

How is the compiler to know the arity of the target function?  If I call
pow(3,5), how would the compiler know that pow() can take an optional
third argument which would be need to be initialized to NULL?



> Then we would have N little functions, each with the exact # of
> parameters.  Each would still need a switch to call the C function
> because there may be optional parameters.  Ultimately, it's possible
> the code would be small enough to stick it into the eval_frame loop.
> Each of these steps would need to be tested, but that's a possible
> longer term direction.
 . . .
> There would only be an if to check if it was a C function or not.
> Maybe we could even get rid of this by more fixup at import time.

This is what I mean about the patch taking on a life of its own.  It's
an optimization patch that slows down METH_O and METH_NOARGS.  It's a
incremental change that throws away backwards compatibility.  It's a
simplification that introduces a bazillion new code paths.  It's a
simplification that can't be realized until 3.0.  It's a minor change
that entails new opcodes, compiler changes, and changes in all
extensions that have ever been written.

IOW, this patch has lost its focus (or innocence).  That can be
recovered by limiting the scope to improving the call time for methods
with signatures like "O}O".  That is an achievable goal that doesn't
impact backwards compatibility, doesn't negatively impact existing
near-optimal METH_O and METH_NOARGS code, doesn't mess with the
compiler, doesn't introduce new opcodes, doesn't alter import logic, and
doesn't muck-up existing extensions.



Raymond


"Until next week, keep your feet on the ground and keep reaching for the
stars." -- Casey Kasem

___
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: Allowing slicing of iterators

[Fredrik Lundh]

Guido van Rossum wrote:
>> I'd like to see iterators become as easy to work with as lists are. At the
>> moment, anything that returns an iterator forces you to use the relatively
>> cumbersome itertools.islice mechanism, rather than Python's native slice 
>> syntax.
>
> Sorry. Still -1.

can we perhaps persuade you into changing that to a -0.1, so we can
continue playing with the idea?

> iterators are not sequences and shouldn't be confused with such.

the for-in statement disagrees with you, I think.  on the other hand, I'm not
sure I trust that statement any more; I'm really disappointed that it won't let
me write my loops as:

for item in item for item in item for item in item for item in seq:
...

 



___
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: [PyCON-Organizers] PyCon: The Spam Continues ;-)

[Steve Holden]

David Ascher wrote:
Steve Holden wrote:
Dear python-dev:
The current (as of even date) summary of my recent contributions to 
Python -dev appears to be spam about PyCon.

Not being one to break habits, even not those of a lifetime sometimes, 
I spam you yet again to show you what a beautiful summary ActiveState 
have provided (I don't know whether this URL is cacheable or not):

 

Yup, we try to make all our URLs portable and persistent.
Good for you.
If I remember Trent Lott (?) 

Nah, that's a US politician.  T'was Trent Mick.
Indeed, and already corrected.
described at an IPC the SQL Server database that drives this system, 
and it was a great example of open source technology driving a 
proprietary (but I expect (?) relatively portable) repository.

Modulo some SQLServer features we're using.
Well free-text indexing would be my first guess. Anything else of 
interest? MySQL's free text indexing really sucks compared with SQL 
Server's, which to my mind is a good justification for the Microsoft 
product.

Since I have your attention (and if I haven't then it really doesn't 
matter what I write hereafter, goodbye ...) I will also point out that 
the current top hit on Google for

"Microsoft to Provide PyCon Opening Keynote"

What a bizarre search.
Oh, no, people run that search all the time :-)
It's actually hit #3 for "Microsoft PyCon" as well, so I guess that's 
not too bad.

(note that some of your To's and Cc's were pretty strange...
Hmm, yes, I cringed when I got the bounces. That information didn't 
belong there. If only there were a way to take emails back ...

regards
 Steve
--
Steve Holden   http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC  +1 703 861 4237  +1 800 494 3119
___
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] I think setup.py needs major rework

[Kurt B. Kaiser]

Skip Montanaro <[EMAIL PROTECTED]> writes:

> Python's setup.py has grown way out of control.  I'm trying to
> build and install Python 2.4.0 on a Solaris system with Tcl/Tk
> installed in a non-standard place and I can't figure out the
> incantation to tell setup.py to look where they are installed.

This may be more due to the complexity of distutils than to setup.py
itself.  Special cases are special cases, after all, e.g. look at
Autotools.

setup.py is billed as "Autodetecting setup.py script for building
the Python extensions" but exactly how to override it without hacking
it isn't very well documented, when possible at all.

"Distributing Python Modules" helped me, but the reference section
is missing, so it's utsl from there.

So one improvement would be to better document overriding setup.py in
README.

Your solution may be as simple as adding to Makefile:342 (approx)

--include-dirs= --library-dirs=

where setup.py is called.  (distutils/command/build_ext.py)

*But* I suspect build() may not pass the options through to build_ext()!

So, a config file approach:

.../src/setup.cfg:
[build_ext]
include-dirs=
library-dirs=


In setup.py, PyBuildExt.build_extension() does most of the special
casing.  The last thing done is to call PyBuildExt.detect_tkinter()
which handles a bunch of platform incompatibilities. e.g.

 # OpenBSD and FreeBSD use Tcl/Tk library names like libtcl83.a, but
 # the include subdirs are named like .../include/tcl8.3.

If the previous ideas flub, you could hack your detect_tkinter() and
append your include and lib dirs to inc_dirs and lib_dirs at the
beginning of the method.

All else fails, use Modules/Setup.dist to install Tcl/Tk?

Or maybe symlink your non-standard location?

-- 
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] I think setup.py needs major rework

[Brett C.]

Fred L. Drake, Jr. wrote:
On Tuesday 25 January 2005 23:30, Skip Montanaro wrote:
 > Python's setup.py has grown way out of control.  I'm trying to build
 > and install Python 2.4.0 on a Solaris system with Tcl/Tk installed in a
 > non-standard place and I can't figure out the incantation to tell setup.py
 > to look where they are installed.
...
 > This might be an excellent sprint topic for PyCon.
Indeed it would be!
... and now it is listed as one.  Started a section on the sprint wiki page for 
orphaned sprint topics with a subsection on core stuff.  Listed a rewrite of 
setup.py along with a rewrite of site.py and the usual bug/patch squashing.

URL is http://www.python.org/moin/PyConDC2005/Sprints for those not wanting to 
go hunting for it.

-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

Re: [Python-Dev] Strange segfault in Python threads and linux kernel 2.6

[Donovan Baarda]

On Wed, 2005-01-26 at 01:53 +1100, Anthony Baxter wrote:
> On Wednesday 26 January 2005 01:01, Donovan Baarda wrote:
> > In this case it turns out to be "don't do exec() in a thread, because what
> > you exec can have all it's signals masked". That turns out to be a hell of
> > a lot of things; popen, os.command, etc. They all only work OK in a
> > threaded application if what you are exec'ing doesn't use any signals.
> 
> Yep. You just have to be aware of it. We do a bit of this at work, and we
> either spool via a database table, or a directory full of spool files. 
> 
> > Actually, I've noticed that zope often has a sorta zombie "which" process
> > which it spawns. I wonder it this is a stuck thread waiting for some
> > signal...
> 
> Quite likely.

For the record, it seems that the java version also contributes. This
problem only occurs when you have the following combination;

Linux >=2.6
Python <=2.3
j2re1.4 =1.4.2.01-1 | kaffe 2:1.1.4xxx

If you use Linux 2.4, it goes away. If you use Python 2.4 it goes away.
If you use j2re1.4.1.01-1 it goes away.

For the problem to occur the following combination needs to occur;

1) Linux uses the thread's sigmask instead of the main thread/process
sigmask for the exc'ed process (ie, 2.6 does this, 2.4 doesn't).

2) Python needs to screw with the sigmask in threads (python 2.3 does,
python 2.4 doesn't).

3) The exec'ed process needs to rely on threads (j2re1.4 1.4.2.01-1
does, j2re1.4 1.4.1.01-1 doesn't).

It is hard to find old Debian deb's of j2re1.4 (1.4.1.01-1), and when
you do, you will also need the now non-existent j2se-common 1.1 package.
I don't know if this qualifies as a potential bug against j2re1.4
1.4.2.01-1.

For now my solution is to roll back to the older j2re1.4.


-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
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] Patch review: [ 1100942 ] datetime.strptime constructor added

[Alan Green]

I see a need for this patch - I've had to write
"datetime(*(time.strptime(date_string, format)[0:6]))" far too many
times.

I don't understand the C API well enough to check if
reference counts are handled properly, but otherwise the
implementation looks straight forward.

Documentation looks good and the test passes on my machine.

Two suggestions:

1. In the time module, the strptime() function's format
parameter is  optional. For consistency's sake, I'd expect
datetime.strptime()'s format parameter also to be optional.
(On the other hand, the default value for the format is not
very useful.)

2. Since strftime is supported by datetime.time,
datetime.date and datetime.datetime, I'd also expect
strptime to be supported by all three classes. Could you add
that now, or would it be better to do it as a separate patch?

Alan. 
-- 
Alan Green 
[EMAIL PROTECTED] - http://cardboard.nu
___
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] Patch review: [ 1094542 ] add Bunch type to collections module

[Alan Green]

Steven Bethard is proposing a new collection class named Bunch. I had
a few suggestions which I attached as comments to the patch - but what
is really required is a bit more work on the draft PEP, and then
discussion on the python-dev mailing list.

http://sourceforge.net/tracker/?func=detail&aid=1100942&group_id=5470&atid=305470

Alan.
-- 
Alan Green 
[EMAIL PROTECTED] - http://cardboard.nu
___
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] Patch review: [ 1094542 ] add Bunch type to collections module

[Steven Bethard]

Alan Green <[EMAIL PROTECTED]> wrote:
> Steven Bethard is proposing a new collection class named Bunch. I had
> a few suggestions which I attached as comments to the patch - but what
> is really required is a bit more work on the draft PEP, and then
> discussion on the python-dev mailing list.
> 
> http://sourceforge.net/tracker/?func=detail&aid=1100942&group_id=5470&atid=305470

I believe the correct tracker is:

http://sourceforge.net/tracker/index.php?func=detail&aid=1094542&group_id=5470&atid=305470

There was a substantial discussion about this on the python-list
before I put the PEP together:

http://mail.python.org/pipermail/python-list/2004-November/252621.html

I applied for a PEP number on 2 Jan 2005 and haven't heard back yet,
but the patch was posted so people could easily play around with it if
they liked.  My intentions were to post the PEP to python-dev as soon
as I got a PEP number for it.

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] Patch review: [ 1009811 ] Add missing types to __builtin__

[Alan Green]

Last August, James Knight posted to python-dev, "There's a fair number
of classes that claim they are defined in __builtin__, but do not
actually appear there". There was a discussion and James submitted
this patch:

http://sourceforge.net/tracker/index.php?func=detail&aid=1009811&group_id=5470&atid=305470

The final result of the discussion is unclear. Guido declared himself
+0.5 on the concept, but nobody has reviewed the patch in detail yet.

The original email thread starts here: 

http://mail.python.org/pipermail/python-dev/2004-August/047477.html

The patch still applies, and test cases still run OK afterwards.

Now that 2.4 has been released it is perhaps a good time to discuss in
on python-dev again. If it isn't discussed, then the patch should be
closed due to lack of interest.

Alan.
-- 
Alan Green 
[EMAIL PROTECTED] - http://cardboard.nu
___
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] Patch review: [ 1100942 ] datetime.strptime constructor added

[Skip Montanaro]

Alan> 1. In the time module, the strptime() function's format
Alan> parameter is optional.  For consistency's sake, I'd expect
Alan> datetime.strptime()'s format parameter also to be optional.  (On
Alan> the other hand, the default value for the format is not very
Alan> useful.)

Correct.  No need to propagate a mistake.

Alan> 2. Since strftime is supported by datetime.time,
Alan> datetime.date and datetime.datetime, I'd also expect strptime to
Alan> be supported by all three classes.  Could you add that now, or
Alan> would it be better to do it as a separate patch?

That can probably be done, but I'm not convinced strftime really belongs on
either date or time objects given the information those objects are missing:

>>> t = datetime.datetime.now().time()
>>> t.strftime("%Y-%m-%d")
'1900-01-01'
>>> d = datetime.datetime.now().date()
>>> d.strftime("%H:%M:%S")
'00:00:00'

I would be happy for strftime to only be available for datetime objects
(assuming there was a good way to get from time or date objects to datetime
objects short of extracting their individual attributes).  In any case,
going from datetime to date or time objects is trivial:

>>> dt = datetime.datetime.now()
>>> dt.time()
datetime.time(21, 12, 18, 705365)

so parsing a string into a datetime object then splitting out date and time
objects seems reasonable.

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] Patch review: [ 1009811 ] Add missing types to__builtin__

[Raymond Hettinger]

> Last August, James Knight posted to python-dev, "There's a fair number
> of classes that claim they are defined in __builtin__, but do not
> actually appear there". There was a discussion and James submitted
> this patch:
> 
>
http://sourceforge.net/tracker/index.php?func=detail&aid=1009811&group_i
d=
> 5470&atid=305470

I'm -1 on adding these to __builtin__.  They are just distractors and
have almost no use in real Python programs.  Worse, if you do use them,
then you are likely to be programming badly -- we don't want to
encourage that.

Also, I take some of these, such as dictproxy and cell, to be
implementation details that are subject to change.  Adding them to
__builtin__ would unnecessarily immortalize them.



> The final result of the discussion is unclear. Guido declared himself
> +0.5 on the concept, but nobody has reviewed the patch in detail yet.

Even if Guido were suffering from time machine induced hallucinations
that day, he still knew better than to go a full +1.


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] Patch review: [ 1009811 ] Add missing types to__builtin__

["Martin v. Löwis"]

Raymond Hettinger wrote:
I'm -1 on adding these to __builtin__.  They are just distractors and
have almost no use in real Python programs.  Worse, if you do use them,
then you are likely to be programming badly -- we don't want to
encourage that.
I agree. Because of the BDFL pronouncement, I cannot reject the patch,
but I won't accept it, either. So it seems that this patch will have
to sit in the SF tracker until either Guido processes it, or it is
withdrawn.
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] Patch review: [ 1009811 ] Add missing types to__builtin__

[James Y Knight]

On Jan 27, 2005, at 1:20 AM, Martin v. Löwis wrote:
I agree. Because of the BDFL pronouncement, I cannot reject the patch,
but I won't accept it, either. So it seems that this patch will have
to sit in the SF tracker until either Guido processes it, or it is
withdrawn.
If people want to restart this discussion, I'd like to start back with 
the following message, rather than simply accepting/rejecting the 
patch. From the two comments so far, it seems like it's not the patch 
that needs reviewing, but still the concept.

On August 10, 2004 12:17:14 PM EDT, I wrote:
Sooo should (for 'generator' in objects that claim to be in
__builtins__ but aren't),
1) 'generator' be added to __builtins__
2) 'generator' be added to types.py and its __module__ be set to 
'types'
3) 'generator' be added to .py and its __module__ be set to
'' (and a name for the module chosen)
Basically, I'd like to see them be given a binding somewhere, and have 
their claimed module agree with that, but am not particular as to 
where. Option #2 seemed to be rejected last time, and option #1 was 
given approval, so that's what I wrote a patch for. It sounds like it's 
getting pretty strong "no" votes this time around, however. Therefore, 
I would like to suggest option #3, with  being, say, 
'internals'.

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