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

[Xavier Morel]

On 2010-10-11, at 07:56 , Carl M. Johnson wrote:
> 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

That's an understatement. As the documentation indicates, if you're going to 
fully consume the iterator the first time around instead of iterating both in 
near-lockstep (combining islice and map for instance) you're better off 
serializing to a list and then using that list twice, memory-wise.

> but it's about as good as you can expect in a single threaded environment.
You could also have coroutines, but they cooperate explicitly so you'd have to 
"fix" min and max (and any other function you can get your hands on, really) in 
order to allow them to act as coroutines, I think.
___
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] Relative imports in Py3k

[Nick Coghlan]

On Mon, Oct 11, 2010 at 1:54 AM, anatoly techtonik  wrote:
> On Sun, Sep 26, 2010 at 2:32 PM, Nick Coghlan  wrote:
>> 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.

Anatoly, unconstructive responses like this are why people often react
negatively to your attempts to be "helpful".

I specifically mentioned 2 things you could do:
- modify PYTHONPATH
- use -m to execute your modules and just switch your current working
directory depending on which version of spyderlib you want to execute

Responding to that by telling me that modifying PYTHONPATH when
working with in-development code is clumsy isn't telling me anything I
don't already know. There's a *reason* why you can now use -m to have
relative imports "just work" so long as your current working directory
includes the top level directory for your package. There's a *reason*
we added the ability to execute directories and zipfiles and have them
automatically add themselves to the head of sys.path. And it's the
same reason: we've been working on making it easier to work with
uninstalled (i.e. not on PYTHONPATH) code for years. Throwing your
hands up and saying "bah, it doesn't work, it should just read my mind
and know what I meant!" really isn't helpful.

Based on your latest response, giving your spyderlib package a
top-level __main__.py and running the directory directly may even be
an option for you. But when your response solely discusses PYTHONPATH
without even mentioning the better alternative I offered (i.e. using
-m and just switching your current working directory in a command
shell), it's hard to assess your actual use case.

As far as documentation goes, I personally find it incredibly
difficult to write simple, user-oriented documentation of the import
system, as I've long since lost my perspective on what's simple and
what's complicated when it comes to the import system. I'd love for
someone to tackle the task of writing clear end-user documentation of
the whole PEP 302, 328, 338, 366, imp, runpy, importlib, etc
arrangement (more comprehensive documentation of the zipfile and
directory execution from issue 1739468 wouldn't hurt either).

The problem is that the people who already know enough to write such
documentation don't need it, and anyone else that sets out to learn
enough to be able to write it discovers that there are so many
backwards compatibility hacks that complicate an otherwise reasonably
clean design that they throw their hands up in despair. (That said, I
did attempt to write such a piece of documentation a few years back
[1] so anyone that wanted to try it could at least consider using that
as a starting point instead of starting with a blank screen)

Cheers,
Nick.

[1] 
http://svn.python.org/view/sandbox/trunk/userref/ODF/Chapter07_ModulesAndApplications.odt

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] PyArg_ParseTuple

[Ioan Ferencik]

I  would like to ask where can I find more detailed info on
PyArg_ParseTuple function.

I find the doc limited on the matter.
Mainly I am curious why the function requires an address of a pointer.

I have issues in the following case:
in python
int jmax = 16

print type(jmax)



which is just all right
  but following C code seems to be working
PyObject *jmax_o = NULL;

if(!PyArg_ParseTuple(args, "i", &jmax_o)){
goto error;
}

but PyInt_Check(jmax_o) fails.

I tried to debug and this is what i could see

Program received signal SIGSEGV, Segmentation fault.
0x767a75bd in fprintf (self=, args=(16,))
at /usr/include/bits/stdio2.h:98
98  return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,

so for some reason the jmax_o can not be converted to int.

I use a x86_64 ubuntu and i suspect it could be because of 64 bits arch.

Cheers

Ioan Ferencik
PhD student
Aalto University
School of Science and Technology
Faculty Of Civil and Env. Engineering
Lahti Center
Tel: +358505122707


___
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] PyArg_ParseTuple

[Benjamin Peterson]

2010/10/11 Ioan Ferencik :
> I  would like to ask where can I find more detailed info on
> PyArg_ParseTuple function.

See python-list.

>
> I find the doc limited on the matter.
> Mainly I am curious why the function requires an address of a pointer.

So it can change the pointer.



-- 
Regards,
Benjamin
___
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] Cheeseshop (was Re: Distutils2 scripts)

[Frank Lomax]

On Oct 08, 2010, at 03:40 PM, Brett Cannon wrote:

>Richard Jones is the authority on the story, but from what I can
>remember from the discussion it was decided that managers would have
>had issues with using a service called the Cheeseshop. So basically
>the idea of professional-sounding name won out. I still use
>cheeseshop.python.org to access the package index.

IOW, the Anti-Humor Subcommittee of the PSU (which emphatically does not
exist), a rough outfit which works to promote snakes over British comedy,
quashed the Happy Laughing Working Group and actively (even though they do not
exist) promotes the boring PHB name in all its propaganda.  The HLWG, having
been defunded and thrown out of office (if there was an office, which there
isn't), toils in exile and hopes to one day reclaim the right and one true
name.

Join the revolt to take back Pythonland!  May the Pythonistas defeat the
Pythoneers!  May the Pythoneers vanquish the Pythonistas!

Long live the Cheeseshop!

it's-very-runny-actual-ly y'rs,
-frank
___
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] Distutils2 scripts

[Martin v. Löwis]

Am 08.10.2010 17:21, schrieb Michael Foord:
>  On 08/10/2010 16:07, Barry Warsaw wrote:
>> On Oct 08, 2010, at 11:04 AM, Toshio Kuratomi wrote:
>>
>>> python-setup  is a lot like python setup.py
>>> pysetup is shorter
>>> pyegg is even shorter :-)
>> wfm!
> 
> To avoid any potential confusion, wfm is a common tla for the following
> phrases:
> 
> Whole Foods Market
> Western Federation of Miners
> Window Fitters Mate
> Workforce Management
> 
> Although wfm is possibly being used here as "works for me" given the
> context... ;-)

Not being a native speaker (of English), I had actually assumed that
Barry is proposing to call the script "wfm". Although, in retrospect,
"/usr/bin/wfm!" might work as well :-)

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] Distutils2 scripts

[Daniel Stutzbach]

On Fri, Oct 8, 2010 at 4:44 PM, Tarek Ziadé  wrote:

> Hehe. What's the story behind changing the name from Cheeseshop to PyPI btw
> ?
> I found the first one much nicer


A through investigation revealed that the Cheeseshop did not in fact have
any cheese at all.  Not even Wensleydale.

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Relative imports in Py3k

[Ron Adam]

On 10/11/2010 07:27 AM, Nick Coghlan wrote:

On Mon, Oct 11, 2010 at 1:54 AM, anatoly techtonik  wrote:

On Sun, Sep 26, 2010 at 2:32 PM, Nick Coghlan  wrote:

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.


Anatoly, unconstructive responses like this are why people often react
negatively to your attempts to be "helpful".

I specifically mentioned 2 things you could do:
- modify PYTHONPATH
- use -m to execute your modules and just switch your current working
directory depending on which version of spyderlib you want to execute


I don't recall Anatoly saying which p3k version and revision he was using. 
 Relative imports was broken for while in 3.2.  It's fixed now and I 
presume he is using a fairly current revision of 3.2.


When you do a "make install" for 3.2 on Ubuntu, the current directory path 
"", isn't perpended to sys.path.  I don't know if that is an over site or 
not, but it could be a factor.



A few more suggestions ...

Make A test runner script which modifies sys.path.  It also could be 
considered a hack, but it doesn't require modifying PYTHONPATH, so it 
wouldn't have any potential to have side effects on other modules/programs.


One of my personal choices when writing large applications (rather than 
scripts), is to make a local "lib" directory and prepend that to sys.path 
in the main application file before any local imports.


# Add a local lib to the search path.
lib = os.path.abspath(os.path.join(__file__, '..', 'lib'))
sys.path.insert(0, lib)

[Appliction dir not in PYthon path]
main_app_file.py
test.py
[lib]
[test package]
...   #test modules
...   #other local modules and packages

I then add a -test option to the main_app_file.py or a create test.py file 
at the same level as the main_app_file.  The test runner also needs to add 
lib to sys.path, but after that it can import and find any/all tests you 
want to run.  The test modules can use relative imports as long as they 
aren't circular.


* The error message in the case of circular imports could be much better!

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

Re: [Python-Dev] Distutils2 scripts

[Giampaolo Rodolà]

2010/10/8 Eric Smith :
> On 10/8/10 10:26 AM, Barry Warsaw wrote:
>> In any case, these could be a simple shell script wrapping 'python -m
>> setup'.
>> It could even take a --use-python-version option to select the pythonX.Y
>> it
>> used, without having to encode the Python version number in the script
>> name.
>
> On Windows it can't be a shell script or batch file, but needs to be an
> executable. setuptools already deals with this.

If that's the case what would I type in the command prompt in order to
install a module?
"C:\PythonXX\pysetup.exe"?
If so I would strongly miss old "setup.py install".


--- Giampaolo
___
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] Distutils2 scripts

[Giampaolo Rodolà]

Wouldn't be kinda weird that one can open the command prompt and run
"pysetup" but not "python" on Windows?
I recall an old issue on the bug tracker in which the latter proposal
was widely discussed and finally rejected for reasons I can't remember
(and it seems I can't even find the bug right now).
I think it's likely that those same reasons are valid for "pysetup" in
the same manner.

For the record, I would be more than happy to be able to open the
command prompt and type "pysetup" and "python" with success, one day.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/


2010/10/12 Eric Smith :
> On 10/11/2010 5:17 PM, Giampaolo Rodolà wrote:
>>
>> 2010/10/8 Eric Smith:
>>>
>>> On 10/8/10 10:26 AM, Barry Warsaw wrote:

 In any case, these could be a simple shell script wrapping 'python -m
 setup'.
 It could even take a --use-python-version option to select the pythonX.Y
 it
 used, without having to encode the Python version number in the script
 name.
>>>
>>> On Windows it can't be a shell script or batch file, but needs to be an
>>> executable. setuptools already deals with this.
>>
>> If that's the case what would I type in the command prompt in order to
>> install a module?
>> "C:\PythonXX\pysetup.exe"?
>> If so I would strongly miss old "setup.py install".
>
> Same thing you would type at a shell prompt. Presumably we're talking about
> "pysetup install" (which you'll note is one character shorter!). You could
> fully qualify the path if need be, on any platform, using its conventions.
>
> Eric.
>
___
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] Distutils2 scripts

[Antoine Pitrou]

On Tue, 12 Oct 2010 01:11:24 +0200
Giampaolo Rodolà  wrote:
> Wouldn't be kinda weird that one can open the command prompt and run
> "pysetup" but not "python" on Windows?

If you add C:\PythonXY to your path, you can run "python".

Regards

Antoine.


___
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] Distutils2 scripts

[Greg Ewing]

Giampaolo Rodolà wrote:


If that's the case what would I type in the command prompt in order to
install a module?
"C:\PythonXX\pysetup.exe"?
If so I would strongly miss old "setup.py install".


Another thing bothers me about this. With the current scheme,
if you have multiple Pythons available, it's easy to be sure
that you're installing into the right one, because it's the
one that you use to run setup.py. Whereas if installation is
performed by a different executable, there's a possibility
of them being out of sync.

So I think I'd prefer some scheme involving 'python -m ...'
or some other option to Python itself, rather than a separate
executable.

--
Greg

___
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] Distutils2 scripts

[Greg Ewing]

Giampaolo Rodolà wrote:

Wouldn't be kinda weird that one can open the command prompt and run
"pysetup" but not "python" on Windows?
I recall an old issue on the bug tracker in which the latter proposal
was widely discussed and finally rejected for reasons I can't remember


On Windows I think it's easier and more reliable to set things
up so that you can invoke a .py file directly as a command.

--
Greg
___
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] Distutils2 scripts

[Giampaolo Rodolà]

2010/10/12 Antoine Pitrou :
> On Tue, 12 Oct 2010 01:11:24 +0200
> Giampaolo Rodolà  wrote:
>> Wouldn't be kinda weird that one can open the command prompt and run
>> "pysetup" but not "python" on Windows?
>
> If you add C:\PythonXY to your path, you can run "python".

I know. My point was you can't do it by default and installing a
module is something even a less experienced user usually does.
Typing "C:\PythonXX\pysetup" is harder compared to "setup.py install"
and solving this problem by modifying your environment paths so that
you can just type "pysetup" is something I would expect to be done by
the MSI installer, not the user.


--- Giampaolo
http://code.google.com/p/pyft/
http://code.google.com/p/psutil/
___
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] Distutils2 scripts

[Eric Smith]

On 10/11/2010 5:17 PM, Giampaolo Rodolà wrote:

2010/10/8 Eric Smith:

On 10/8/10 10:26 AM, Barry Warsaw wrote:

In any case, these could be a simple shell script wrapping 'python -m
setup'.
It could even take a --use-python-version option to select the pythonX.Y
it
used, without having to encode the Python version number in the script
name.


On Windows it can't be a shell script or batch file, but needs to be an
executable. setuptools already deals with this.


If that's the case what would I type in the command prompt in order to
install a module?
"C:\PythonXX\pysetup.exe"?
If so I would strongly miss old "setup.py install".


Same thing you would type at a shell prompt. Presumably we're talking 
about "pysetup install" (which you'll note is one character shorter!). 
You could fully qualify the path if need be, on any platform, using its 
conventions.


Eric.
___
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] Distutils2 scripts

[Éric Araujo]

Le 12/10/2010 01:11, Giampaolo Rodolà a écrit :
> Wouldn't be kinda weird that one can open the command prompt and run
> "pysetup" but not "python" on Windows?
> I recall an old issue on the bug tracker in which the latter proposal
> was widely discussed and finally rejected for reasons I can't remember
> (and it seems I can't even find the bug right now).
> I think it's likely that those same reasons are valid for "pysetup" in
> the same manner.

Arguments for rejection by MvL in http://bugs.python.org/issue3561 :

“Adding something to PATH is nearly unacceptable clutter even during
installation, and completely unacceptable (to me) after uninstallation.
If you install Python several times, will the path get longer and longer?”

“To me, any change to PATH is a problem... (I really think that software
installation should never ever touch it - this aspect of the operating
system completely belongs to the user resp. the system administrator)”

“If such a solution was designed, there would still be many questions,
such as:
- what is the actual problem being solved? Is it real? Could there
  be other solutions to that problem (such as installing things into
  system32, or somewhere else that is on the PATH already)?
- if the path is modified, should the Python directory be added to
  the beginning or the end?
- IMO, this feature needs to be customizable, and IMO, it must be
  turned off by default. So how should such customization be offered?”

Regarding pysetup, would it be acceptable to require programmers on
Windows to edit their PATH or copy the script to a directory on PATH?

Regards

___
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