Re: [Python-Dev] Build failure in test_cmd_line on OSX-x86

2010-10-10 Thread Antoine Pitrou

> If someone wants to throw an issue my way, I can take a look at
> dumping stdout/stderr from the various test_cmd_line tests (I may not
> get to it until post-beta1 though).

It's done in r85324.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Build failure in test_cmd_line on OSX-x86

2010-10-10 Thread Nick Coghlan
On Sun, Oct 10, 2010 at 5:54 PM, Antoine Pitrou  wrote:
>
>> If someone wants to throw an issue my way, I can take a look at
>> dumping stdout/stderr from the various test_cmd_line tests (I may not
>> get to it until post-beta1 though).
>
> It's done in r85324.

Even better :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Allow registered users to link bugs

2010-10-10 Thread anatoly techtonik
Can anybody remind me why we don't allow registered tracker users to
link dependent bugs between each other?
--
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Relative imports in Py3k

2010-10-10 Thread anatoly techtonik
On Sat, Sep 25, 2010 at 4:52 PM, Georg Brandl  wrote:
>>
>> I wonder if situation with relative imports in packages is improved in
>> Python 3k or we are still doomed to a chain of hacks?
>>
>> My user story:
...
>> PEP 328 http://www.python.org/dev/peps/pep-0328/  proposes:
>>
>> from ... import config
>> from ..utils.qthelpers import translate, add_actions, create_action
>>
>> But this doesn't work, and I couldn't find any short user level
>> explanation why it is
>> not possible to make this work at least in Py3k without additional magic.
>
> Uh, "this doesn't work" is a report that every developer loves.  I suppose
> Python does raise an exception with a message?

It is not a bug report. It is a "user story" - that means the thing
that I, as a user of Python, assumed to work. But instead have got:

ValueError: Attempted relative import in non-package

There are __init__.py files in every directory of spyderlib, but I
don't want to debug or seek a workarounds against this in Python 2. I
just want to know if relative imports are fixed in Python 3.

-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Relative imports in Py3k

2010-10-10 Thread anatoly techtonik
On Sun, Sep 26, 2010 at 2:32 PM, Nick Coghlan  wrote:
>>
>> I wonder if situation with relative imports in packages is improved in
>> Python 3k or
>> we are still doomed to a chain of hacks?

This is The question. Is Python 3k more friendly to users or require
them to learn the "zen of import" (which is not available in concise
format, unfortunately, unlike "this" thing)?

>> relatives. All imports are like:
>>
>> from spyderlib.config import get_icon
>> from spyderlib.utils.qthelpers import translate, add_actions, create_action
>
> This is almost certainly failing because the directory containing the
> spyderlib package isn't on sys.path anywhere (instead, whichever
> directory contains the script you executed directly will be in there,
> which will be somewhere inside the package instead of outside it). Put
> the appropriate directory in PYTHONPATH and these tests should start
> working.

This is a hack. I use relative imports, because I don't want to care
about PYTHONPATH issues. I work with two clones of spyderlib
(reference point and feature branch). You propose to switch PYTHONPATH
every time I want to execute debug code in the __main__ section from
either of them.

Of course, I can write scripts to automate the thing, but it is a
_basic_ debug operation, and as a one of the hundreds Python users I
don't want to go through this misery just to be able to run "python
submodule.py". Hope this clarifies The question.

>> PEP 328 http://www.python.org/dev/peps/pep-0328/  proposes:
>>
>> from ... import config
>> from ..utils.qthelpers import translate, add_actions, create_action
>
> This fails for two reasons:
> 1. "__main__" is missing the module namespace information PEP 328
> needs to do its thing
> 2. Even if 1 is resolved, PEP 328 will resolve to the same absolute
> imports you're already using and likely fail for the same reason (i.e.
> spyderlib not found on sys.path)

This is a hack. There is no explanation why this hack is required, or
it is not a user-friendly explanation.

>> But this doesn't work, and I couldn't find any short user level
>> explanation why it is
>> not possible to make this work at least in Py3k without additional magic.
>
> If you use the -m switch to run your module from the directory that
> contains the spyderlib package directory, it will work. The use of -m
> provides the module namespace information that PEP 328 needs, while
> running from the directory that contains the spyderlib package ensures
> it is visible through sys.path.
>
> The one caveat is that the specified module is run as "__main__" and
> hence does not exist in sys.modules under its normal name. If it gets
> imported by another module, then you will end up with two copies of
> the module (one as "__main__" and one under the normal name). This may
> or may not cause problems, depending on the nature of the module being
> executed.
>
> While PEP 366 describes the boilerplate you can put at the top of your
> module to allow a directly executed module to try to find its
> siblings, it still requires that PYTHONPATH be set appropriately. And
> if you set PYTHONPATH appropriately, then direct execution with
> absolute imports will work.
>
> (The explanation of the failures applies for all Python versions that
> I am aware of, but the -m based fix only became available in 2.6)
> (The impact of various command line options and the PYTHONPATH
> environment variable on sys.path are described at
> http://docs.python.org/using/cmdline.html)
> (The basic import search algorithm is described in the tutorial:
> http://docs.python.org/tutorial/modules.html#the-module-search-path)
> (And the full gory specification details are in PEP 302, with a few
> subsequent tweaks courtesy of PEP 328 and PEP 366).

This what I call "zen of import".

I don't see why such awkward way should be necessary in Python 3k,
which breaks backwards compatibility. Why it can't "just work" for my
user story?

-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] [Python-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

2010-10-10 Thread Paul McGuire
Just as an exercise, I wanted to try my hand at adding a function to the
compiled Python C code.  An interesting optimization that I read about
(where? don't recall) finds the minimum and maximum elements of a sequence
in a single pass, with a 25% reduction in number of comparison operations:
- the sequence elements are read in pairs
- each pair is compared to find smaller/greater
- the smaller is compared to current min
- the greater is compared to current max

So each pair is applied to the running min/max values using 3 comparisons,
vs. 4 that would be required if both were compared to both min and max.

This feels somewhat similar to how divmod returns both quotient and
remainder of a single division operation.

This would be potentially interesting for those cases where min and max are
invoked on the same sequence one after the other, and especially so if the
sequence elements were objects with expensive comparison operations.

However, it *would* add "minmax" to the namespace bloat wherever this
function might land (builtin? itertools? collections?). And I'm sure we
wouldn't want to subsume the current min and max to just be minmax(s)[0] or
minmax(s)[1], since that would *increase* the number of comparisons by 50%
for either function when used alone.

I did my prototyping using Python 2.5.5 source, since I only have Visual
Studio 2005 - here is a diff to the that version's bltinmodule.c file:
http://pastebin.com/4xv6SLBM

Through the magic of Google, I've found these minmax implementations in the
wild:
http://www2-pcmdi.llnl.gov/cdat/source/api-reference/genutil.minmax.html
http://mth.uct.ac.za/~lab/chap1/ans/ans2.pdf

I also found a few other minmax references, but these methods were different
implementations (minimum of sequence of maxima, or a generic min_or_max
function taking a comparison flag or function in order to perform min or
max).  Unfortunately, I did not come up with a good way to search for cases
where min and max were called one after the other.

Any comments? Interest? Should I write up a PEP? Go back to my pyparsing
hole?

-- Paul McGuire

___
Python-Dev mailing list
[email protected]
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-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

2010-10-10 Thread Martin v. Löwis
> Any comments?

For 3.2, this is out of scope, because of the moratorium.

For later versions, I'd rather not see a builtin name polluting the
global namespace for this.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

2010-10-10 Thread Antoine Pitrou
On Sun, 10 Oct 2010 13:57:21 -0500
"Paul McGuire"  wrote:
> 
> Any comments? Interest? Should I write up a PEP? Go back to my pyparsing
> hole?

Generally, these things are discussed on python-ideas first.  I don't
think a PEP required for a single function, but you'll have to convince
people that it's useful ;)

Personnally, I'm not convinced that a maximum 25% improvement on a
rather uncommon use case (min() and max() on a sequence of objects
which take a long time to compare) is a compelling argument for a
builtin.  On the other hand, it would be a rather simple and intuitive
builtin, so why not?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

2010-10-10 Thread Steven D'Aprano
On Mon, 11 Oct 2010 05:57:21 am Paul McGuire wrote:
> Just as an exercise, I wanted to try my hand at adding a function to
> the compiled Python C code.  An interesting optimization that I read
> about (where? don't recall) finds the minimum and maximum elements of
> a sequence in a single pass, with a 25% reduction in number of
> comparison operations:
> - the sequence elements are read in pairs 
> - each pair is compared to find smaller/greater
> - the smaller is compared to current min
> - the greater is compared to current max
>
> So each pair is applied to the running min/max values using 3
> comparisons, vs. 4 that would be required if both were compared to
> both min and max.
>
> This feels somewhat similar to how divmod returns both quotient and
> remainder of a single division operation.
>
> This would be potentially interesting for those cases where min and
> max are invoked on the same sequence one after the other, and
> especially so if the sequence elements were objects with expensive
> comparison operations.

Perhaps more importantly, it is ideal for the use-case where you have an 
iterator. You can't call min() and then max(), as min() consumes the 
iterator leaving nothing for max(). It may be undesirable to convert 
the iterator to a list first -- it may be that the number of items in 
the data stream is too large to fit into memory all at once, but even 
if it is small, it means you're now walking the stream three times when 
one would do.

To my mind, minmax() is as obvious and as useful a built-in as divmod(), 
but if there is resistance to making such a function a built-in, 
perhaps it could go into itertools. (I would prefer it to keep the same 
signature as min() and max(), namely that it will take either a single 
iterable argument or multiple arguments.)

I've experimented with minmax() myself. Not surprisingly, the 
performance of a pure Python version doesn't even come close to the 
built-ins.

I'm +1 on the idea.

Presumably follow-ups should go to python-ideas.



-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Relative imports in Py3k

2010-10-10 Thread R. David Murray
> On Sun, 10 Oct 2010 18:54:20 +0300, anatoly techtonik  
> wrote:
> > (The explanation of the failures applies for all Python versions that
> > I am aware of, but the -m based fix only became available in 2.6)
> > (The impact of various command line options and the PYTHONPATH
> > environment variable on sys.path are described at
> > http://docs.python.org/using/cmdline.html)
> > (The basic import search algorithm is described in the tutorial:
> > http://docs.python.org/tutorial/modules.html#the-module-search-path)
> > (And the full gory specification details are in PEP 302, with a few
> > subsequent tweaks courtesy of PEP 328 and PEP 366).
> 
> This what I call "zen of import".
> 
> I don't see why such awkward way should be necessary in Python 3k,
> which breaks backwards compatibility. Why it can't "just work" for my
> user story?

Because you weren't around advocating and implementing a change when
Python 3 was developed?

It's too late now to arbitrarily break backward compatibility, so you'll
have to advocate and develop any change inside the parameters of Python's
normal backward compatibility policy.

In other words, you should move this discussion to python-ideas.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
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-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

2010-10-10 Thread Benjamin Peterson
2010/10/10 Antoine Pitrou :
> Personnally, I'm not convinced that a maximum 25% improvement on a
> rather uncommon use case (min() and max() on a sequence of objects
> which take a long time to compare) is a compelling argument for a
> builtin.  On the other hand, it would be a rather simple and intuitive
> builtin, so why not?

Because new builtins should have a better reason that there's no good
reason not to. :)


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
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-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

2010-10-10 Thread Zac Burns
This could be generalized and placed into itertools if we create a function
(say, apply for lack of a better name at the moment) that takes in an
iterable and creates new iterables that yield each from the original
(avoiding the need for a list) holding only one in memory. Then you could
pass the whatever function you wanted to run the iterables over an get the
result back in a tuple.

Eg:

itertools.apply(iterable, min, max) ~= (min(iterable), max(iterable))

This class that creates 'associated iterables' from an original iterable
where each new iterable has to be iterated over at the same time might also
be useful in other contexts and could be added to itertools as well.


Unfortunately this solution seems incompatable with the implementations with
for loops in min and max (EG: How do you switch functions at the right
time?) So it might take some tweaking.

--
Zachary Burns
(407)590-4814
Aim - Zac256FL



On Sun, Oct 10, 2010 at 4:17 PM, Steven D'Aprano wrote:

> On Mon, 11 Oct 2010 05:57:21 am Paul McGuire wrote:
> > Just as an exercise, I wanted to try my hand at adding a function to
> > the compiled Python C code.  An interesting optimization that I read
> > about (where? don't recall) finds the minimum and maximum elements of
> > a sequence in a single pass, with a 25% reduction in number of
> > comparison operations:
> > - the sequence elements are read in pairs
> > - each pair is compared to find smaller/greater
> > - the smaller is compared to current min
> > - the greater is compared to current max
> >
> > So each pair is applied to the running min/max values using 3
> > comparisons, vs. 4 that would be required if both were compared to
> > both min and max.
> >
> > This feels somewhat similar to how divmod returns both quotient and
> > remainder of a single division operation.
> >
> > This would be potentially interesting for those cases where min and
> > max are invoked on the same sequence one after the other, and
> > especially so if the sequence elements were objects with expensive
> > comparison operations.
>
> Perhaps more importantly, it is ideal for the use-case where you have an
> iterator. You can't call min() and then max(), as min() consumes the
> iterator leaving nothing for max(). It may be undesirable to convert
> the iterator to a list first -- it may be that the number of items in
> the data stream is too large to fit into memory all at once, but even
> if it is small, it means you're now walking the stream three times when
> one would do.
>
> To my mind, minmax() is as obvious and as useful a built-in as divmod(),
> but if there is resistance to making such a function a built-in,
> perhaps it could go into itertools. (I would prefer it to keep the same
> signature as min() and max(), namely that it will take either a single
> iterable argument or multiple arguments.)
>
> I've experimented with minmax() myself. Not surprisingly, the
> performance of a pure Python version doesn't even come close to the
> built-ins.
>
> I'm +1 on the idea.
>
> Presumably follow-ups should go to python-ideas.
>
>
>
> --
> Steven D'Aprano
> ___
> Python-ideas mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-ideas
>
___
Python-Dev mailing list
[email protected]
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-ideas] minmax() function returning (minimum, maximum) tuple of a sequence

2010-10-10 Thread Carl M. Johnson
On Sun, Oct 10, 2010 at 2:55 PM, Zac Burns  wrote:

> This could be generalized and placed into itertools if we create a function
> (say, apply for lack of a better name at the moment) that takes in an
> iterable and creates new iterables that yield each from the original
> (avoiding the need for a list) holding only one in memory. Then you could
> pass the whatever function you wanted to run the iterables over an get the
> result back in a tuple.

Time machine partially beat you to this one. Look at the docs on itertools.tee

tee(it, n=2) --> (it1, it2 , ... itn) splits one iterator into n

Can be used like so:

>>> it = iter(range(100))
>>> it1, it2 = itertools.tee(it)
>>> max(it1)
99
>>> min(it2)
0

This doesn't quite have the memory characteristics you describe, but
it's about as good as you can expect in a single threaded environment.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com