Re: [Python-Dev] mingw32 and gc-header weirdness

2009-07-27 Thread Christian Tismer 

On 7/25/09 7:11 AM, Neil Hodgson wrote:

Martin v. Löwis:


I propose to add another (regular) double into the union.


Adding a regular double as a second dummy gives the same sizes and
alignments with Mingw or MSVC as the original definition with MSVC:


Great (checked that, too)

This makes pretty much sense, also given that this waste
happens under Windows, already.


In regard to alignment penalties, a simple copy loop for doubles
runs about 20% slower when misaligned on an my AMD processor. Other
x86 processors can be much worse. As much as 2 to 3.25 times according
to


I am still unhappy with this waste of memory, just because the
GC header has to be rounded up, regardlwss wether that is needed
or not.
We should keep Martin's hint in mind, that Python 4 could place
the gc header at the end of structures, instead.

cheers - chris
--
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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] mingw32 and gc-header weirdness

2009-07-27 Thread Christian Heimes 
Christian Tismer wrote:
> We should keep Martin's hint in mind, that Python 4 could place
> the gc header at the end of structures, instead.

Wow, 3.1 just came out and we already have the first PEP for Python 4k? :)

Christian
___
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] Py_TPFLAGS_HEAPTYPE too overloaded

2009-07-27 Thread Joshua Haberman 
Greg Ewing  canterbury.ac.nz> writes:
> Joshua Haberman wrote:
> > This is not as bad as having someone
> > set __class__ on one of my instances, or set attributes on my type, etc.
> 
> Is there any real need to prevent someone from doing
> those things?

My ultimate goal is to make my types as much like regular built-in types
as possible.  Python as a language has chosen to "lock down" built-in
objects, even going so far as to specifically check for the "Carlo Verre
hack."  I defer to those decisions to answer the question "is there any
real need to prevent someone from doing these things?"  If it's
important for the built-in types, why should it be less important for
mine?

I don't want my type to be a second-class citizen just because I happen
to be dynamically allocating it.

If I were writing this extension for a language like Ruby, for which it is
convention that built-in classes are "open," then I wouldn't mind allowing
these things.  I'm just trying to make my extension as idiomatic and "native"
as possible.

Josh

___
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] Update to Python Documentation Website Request

2009-07-27 Thread David Lyon 
On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull"
 wrote:
> [1] on
> my part") and sysadmin goals ("something that works and plays nicely
> with the rest of the system").
> 
> pythonpkgmgr seems entirely oblivious to the latter issue, and not
> particularly compatible with the way package management works in *nix
> OSS distros (including Linux distros, but also *BSD, MacPorts, and
> Fink).  

Well I'm a sysadmin on linux in my day job.

I'm entirely wondering what you mean by that ? I'm oblivious how?

What can a developer mode project, like pythonpkgmgr possibly do
except to make it easier to manage local package space?

A developer shouldn't need to do sudo every time they want
to put or try some python package from pypi. imho that's
wrong and I'm helping to reduce that need.

If the sysadmin puts a package in (/usr/lib/pythonX.Y/site-packages)
via the O/S package manager (ie synaptics/yum/apt) then that
should stick over what a developer is doing.

But the developer should be able to stick their own packages
in their own local space.

Correct me if my assertion is wrong.

David

___
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] Update to Python Documentation Website Request

2009-07-27 Thread David Lyon 
On Sun, 26 Jul 2009 17:23:59 +0100, Michael Foord
 wrote:
> It would be great to have  a decent visual package manager for Python. 

Hopefully one day we'll have one - haha

> It needs to be built on top of the work that Tarek is doing with 
> distutils (and be compatible with his Distribute fork of setuptools) and 
> it also needs to be established.

I'm planning to support it - like I do for setuptools and pip

> The good news is that there is time for both... Aren't there other tools 
> that have similar goals? PyPI browser, Yolk etc

The fact is that there's way more glamorous things to work on
than a package manager. Nobody has written a package manager for
python imho simply because there's so many more fun things to
do with python than that...

> It is a shame that it needs to be built on Tk if it is to stand a chance 
> of ever being included in the standard library - but with the right 
> expertise it is *possible* to create decent looking UIs with Tk.

I'm working on a TK version.. yes.. a TK version is better than nothing
and the differences between a TK and a WX version is really only pretty 
minor. To me, wx is ancient... and tk is simply prehistoric. 

mr.new-to-python developer wouldn't really cares too much either I
would suspect. All they want is to be up and running quickly.

My only point is that Windows ain't no embedded system. It's not
short on memory or disk space. If a package manager is 5 megabytes
extra say, with it's libraries.. what's the extra download time on
that ? compared to three days+ stuffing around trying to find out
how to install packages for a new user.

If the source needs to go in too.. that's a few kilobytes.

That's like 57 extra bytes to an old-timer... I know.. it's
such a sacrifice.. and we're all working on 300 baud... :-)

David


___
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] Update to Python Documentation Website Request

2009-07-27 Thread David Cournapeau 
On Mon, Jul 27, 2009 at 7:20 PM, David Lyon wrote:

> My only point is that Windows ain't no embedded system. It's not
> short on memory or disk space. If a package manager is 5 megabytes
> extra say, with it's libraries.. what's the extra download time on
> that ? compared to three days+ stuffing around trying to find out
> how to install packages for a new user.

The problem is not so much  the size by itself that more code means
more maintenance burden for python developers. Including new code
means it has to work everywhere where python works currently, and that
other people can understand/support the related code. Adding code to a
project is far from free from python maintainers POV.

cheers,

David
___
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] Update to Python Documentation Website Request

2009-07-27 Thread David Lyon 
On Mon, 27 Jul 2009 19:29:14 +0900, David Cournapeau 
wrote:
>> My only point is that Windows ain't no embedded system. It's not
>> short on memory or disk space. If a package manager is 5 megabytes
>> extra say, with it's libraries.. what's the extra download time on
>> that ? compared to three days+ stuffing around trying to find out
>> how to install packages for a new user.
> 
> The problem is not so much  the size by itself that more code means
> more maintenance burden for python developers. Including new code
> means it has to work everywhere where python works currently, and that
> other people can understand/support the related code. Adding code to a
> project is far from free from python maintainers POV.

Well I concede that you might have a point.

And I know there have been some issues in the past with package
management in python and people being able to understand other
peoples code.

In this specific case, I don't think you'll find the same problems.

pythonpkgmgr is not an entirely self inclusive project. It leverages
on setuptools and pip. I want to extend it to enstall. If there is
any preference towards setuptools - it's only by test-time availability.

In windows, it's built with py2exe. There are some supporting
.dll files that need to go with it from wxpython. They're both really
mainstream python(windows) toolkits.

Everything in pythonpkgmgr is transperant - and was designed to
be. Otherwise there's no point.

If any developers want to join the project with 'commit' privaleges
on the source, I'll make sure it will happen.

If not.. I'm very happy just continuing on with my own merry way...

:-)

David



___
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] Update to Python Documentation Website Request

2009-07-27 Thread Stephen J. Turnbull 
David Lyon writes:
 > On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull"
 >  wrote:
 > > [1] on
 > > my part") and sysadmin goals ("something that works and plays nicely
 > > with the rest of the system").
 > > 
 > > pythonpkgmgr seems entirely oblivious to the latter issue, and not
 > > particularly compatible with the way package management works in *nix
 > > OSS distros (including Linux distros, but also *BSD, MacPorts, and
 > > Fink).  
 > 
 > Well I'm a sysadmin on linux in my day job.
 > 
 > I'm entirely wondering what you mean by that ? I'm oblivious how?

Not you; pythonpkgmgr.  You've said nothing about how pythonpkgmgr is
supposed to deal with multiple installed versions of Python or
individual modules, or how it helps if you need a custom version of a
module, etc., or how it can help the developer's "local" modules
cooperate/not interfere with system versions, etc.

 > What can a developer mode project, like pythonpkgmgr possibly do
 > except to make it easier to manage local package space?

Pave the road to DLL Hell with good intentions, of course.

 > A developer shouldn't need to do sudo every time they want
 > to put or try some python package from pypi.

I don't remember *ever* sudo-ing to try a package from pypi.

 > If the sysadmin puts a package in (/usr/lib/pythonX.Y/site-packages)
 > via the O/S package manager (ie synaptics/yum/apt) then that
 > should stick over what a developer is doing.

But I disagree about that, too.  The last thing I want is to have my
in-development environment hosed by system upgrades or installations.
Eventually I want to deal with that for deployment, but in the early
stages one can make faster progress on demos or initial target
platforms by sticking to particular versions of prerequisite libraries.

 > But the developer should be able to stick their own packages
 > in their own local space.
 > 
 > Correct me if my assertion is wrong.

"Should", yes.  But your assertion is incomplete IME: the developer
*is* able to install packages in their own local space *without*
sudo-ing.

I just don't understand what problem you're claiming to solve.  The
problem of managing local package space is in some sense solved by
virtualenv, but you haven't mentioned that at all.  Is pythonpkgmgr an
alternative?  A complement?  to virtualenv or zc.buildout?

___
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] Implementing File Modes

2009-07-27 Thread Eric Pruitt 
Hello,

Since there was a bit of confusion last time, I'll start by saying I am
working on the subprocess.Popen module for Google Summer of Code. One of the
features I am implementing is a class so that a running process can stand in
in place of a file. For examples, instead of open( "filelist", mode = 'r')
one would call ProcessIOWrapper( "ls -l", mode = 'r'). I am trying to decide
if I should fully implement the mode argument. Right now, it essentially
ignores everything but a 'U' indicated universal newlines in the mode
argument. Should I leave that as is or make it so that things like "r+",
"w", "a" are handled the way they would be for an actual file?

Eric
___
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] mingw32 and gc-header weirdness

2009-07-27 Thread Christian Tismer 

On 7/27/09 12:48 AM, Christian Heimes wrote:

Christian Tismer wrote:

We should keep Martin's hint in mind, that Python 4 could place
the gc header at the end of structures, instead.


Wow, 3.1 just came out and we already have the first PEP for Python 4k? :)

Christian


Maybe it's even possible right now, with a couple of tweaks
that allow to explicitly say where the header is, for a specific
extension type. Might cost a few cycles, tho.

Christian

--
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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] mingw32 and gc-header weirdness

2009-07-27 Thread Christian Tismer 

On 7/24/09 5:16 AM, Roumen Petrov wrote:

Christian Tismer wrote:

...

Did the crash disappear is you add "__attribute__((aligned(8)))" after
variable dummy ?


Did not try. But the proposed addition of a double does it,
see the dev list.

cheers - chris
--
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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] Implementing File Modes

2009-07-27 Thread Paul Moore 
2009/7/27 Eric Pruitt :
> Hello,
>
> Since there was a bit of confusion last time, I'll start by saying I am
> working on the subprocess.Popen module for Google Summer of Code. One of the
> features I am implementing is a class so that a running process can stand in
> in place of a file. For examples, instead of open( "filelist", mode = 'r')
> one would call ProcessIOWrapper( "ls -l", mode = 'r'). I am trying to decide
> if I should fully implement the mode argument. Right now, it essentially
> ignores everything but a 'U' indicated universal newlines in the mode
> argument. Should I leave that as is or make it so that things like "r+",
> "w", "a" are handled the way they would be for an actual file?

I would expect "r" to produce a pipe that reads from stdout of the
subprocess, and "w" to produce a pipe that writes to stdin of the
subprocess. "a" would be the same as "w", and arguably "r+" would be a
bidirectional pipe - read from the subprocess stdout and write to its
stdin.

I'd be OK with "r+" not being implemented (if it's too hard to avoid
deadlocks) but "r" and "w" should be present.

Paul.
___
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] Implementing File Modes

2009-07-27 Thread MRAB 

Paul Moore wrote:

2009/7/27 Eric Pruitt :

Hello,

Since there was a bit of confusion last time, I'll start by saying I am
working on the subprocess.Popen module for Google Summer of Code. One of the
features I am implementing is a class so that a running process can stand in
in place of a file. For examples, instead of open( "filelist", mode = 'r')
one would call ProcessIOWrapper( "ls -l", mode = 'r'). I am trying to decide
if I should fully implement the mode argument. Right now, it essentially
ignores everything but a 'U' indicated universal newlines in the mode
argument. Should I leave that as is or make it so that things like "r+",
"w", "a" are handled the way they would be for an actual file?


I would expect "r" to produce a pipe that reads from stdout of the
subprocess, and "w" to produce a pipe that writes to stdin of the
subprocess. "a" would be the same as "w", and arguably "r+" would be a
bidirectional pipe - read from the subprocess stdout and write to its
stdin.

I'd be OK with "r+" not being implemented (if it's too hard to avoid
deadlocks) but "r" and "w" should be present.


What about stderr? You could add "e" if you want to read from it.
___
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] Implementing File Modes

2009-07-27 Thread Eric Pruitt 
I am implementing the file wrapper using changes to subprocess.Popen that
also make it asynchronous and non-blocking so implementing "r+" should be
trivial to do. How about handling stderr? I have the following ideas: leave
out support for reading from stderr, make it so that there is an optional
additional argument like "outputstderr = False", create another function
that toggles / sets whether stderr or stdout is returned or mix the two
outputs.

Thanks for the input,
Eric

On Mon, Jul 27, 2009 at 10:46, Paul Moore  wrote:

> 2009/7/27 Eric Pruitt :
> > Hello,
> >
> > Since there was a bit of confusion last time, I'll start by saying I am
> > working on the subprocess.Popen module for Google Summer of Code. One of
> the
> > features I am implementing is a class so that a running process can stand
> in
> > in place of a file. For examples, instead of open( "filelist", mode =
> 'r')
> > one would call ProcessIOWrapper( "ls -l", mode = 'r'). I am trying to
> decide
> > if I should fully implement the mode argument. Right now, it essentially
> > ignores everything but a 'U' indicated universal newlines in the mode
> > argument. Should I leave that as is or make it so that things like "r+",
> > "w", "a" are handled the way they would be for an actual file?
>
> I would expect "r" to produce a pipe that reads from stdout of the
> subprocess, and "w" to produce a pipe that writes to stdin of the
> subprocess. "a" would be the same as "w", and arguably "r+" would be a
> bidirectional pipe - read from the subprocess stdout and write to its
> stdin.
>
> I'd be OK with "r+" not being implemented (if it's too hard to avoid
> deadlocks) but "r" and "w" should be present.
>
> Paul.
>
___
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] Implementing File Modes

2009-07-27 Thread Paul Moore 
2009/7/27 Eric Pruitt :
> I am implementing the file wrapper using changes to subprocess.Popen that
> also make it asynchronous and non-blocking so implementing "r+" should be
> trivial to do. How about handling stderr? I have the following ideas: leave
> out support for reading from stderr, make it so that there is an optional
> additional argument like "outputstderr = False", create another function
> that toggles / sets whether stderr or stdout is returned or mix the two
> outputs.

I like MRAB's idea of using a (non-standard) "e" flag to include
stderr. So "r" reads from stdout, "re" reads from stdout+stderr.

Anything more complicated probably should just use "raw" Popen
objects. Don't overcomplicate the interface.

Paul.
___
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] Implementing File Modes

2009-07-27 Thread Steven D'Aprano 
On Tue, 28 Jul 2009 03:21:30 am MRAB wrote:

> What about stderr? You could add "e" if you want to read from it.

"Read from stderr" is just a read. "Write to stderr" is just a write. 
The difference between reading stdout and stderr is not that you have 
different modes, but that you are reading from different files.


-- 
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] Implementing File Modes

2009-07-27 Thread MRAB 

Steven D'Aprano wrote:

On Tue, 28 Jul 2009 03:21:30 am MRAB wrote:


What about stderr? You could add "e" if you want to read from it.


"Read from stderr" is just a read. "Write to stderr" is just a write. 
The difference between reading stdout and stderr is not that you have 
different modes, but that you are reading from different files.



By the same argument, aren't stdin and stdout also different files?
___
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] Py_TPFLAGS_HEAPTYPE too overloaded

2009-07-27 Thread Greg Ewing 

Joshua Haberman wrote:

Python as a language has chosen to "lock down" built-in
objects...  If it's
important for the built-in types, why should it be less important for
mine?


I'm not really sure why so much trouble is taken to lock
down builtin types -- it seems to go against Python's
general consenting-adults philosophy.

I suppose it's felt that you should be able to rely on
builtin types not changing their behaviour. This is probably
more important for the core types than those in extension
modules. Many of the standard library classes are written in
Python, so this protection doesn't extend to them.


I don't want my type to be a second-class citizen just because I happen
to be dynamically allocating it.


I don't think anyone will regard your types as second-class
because they allow you to do *more* with them.

The only real concern would be if it were somehow possible
to crash the interpreter by modifying the type dict.
I don't see how that could happen -- but maybe someone
else on python-dev knows more about this?

--
Greg
___
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] Implementing File Modes

2009-07-27 Thread Steven D'Aprano 
On Tue, 28 Jul 2009 04:06:45 am Eric Pruitt wrote:
> I am implementing the file wrapper using changes to subprocess.Popen
> that also make it asynchronous and non-blocking so implementing "r+"
> should be trivial to do. How about handling stderr? I have the
> following ideas: leave out support for reading from stderr, make it
> so that there is an optional additional argument like "outputstderr =
> False", create another function that toggles / sets whether stderr or
> stdout is returned or mix the two outputs.

Leaving it out is always an option.

As I see it, fundamentally you can either read from stdout and sterr as 
two different streams, or you can interleave (mix) them. To me, that 
suggests three functions:

ProcessIOWrapper()  # read from stdout (or write to stdin etc.)
ProcessIOWrapperStdErr()  # read/write from stderr
ProcessIOWrapper2()  # read from mixed stdout and stderr

I don't like a function to toggle between one and the other: that smacks 
of relying on a global setting in a bad way. I suppose you could add an 
optional argument to ProcessIOWrapper() to select between stdout, 
stderr, or both together.



-- 
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] Implementing File Modes

2009-07-27 Thread Glyph Lefkowitz 
On Mon, Jul 27, 2009 at 3:04 PM, Paul Moore  wrote:

> I like MRAB's idea of using a (non-standard) "e" flag to include
> stderr. So "r" reads from stdout, "re" reads from stdout+stderr.
>
> Anything more complicated probably should just use "raw" Popen
> objects. Don't overcomplicate the interface.
>

In my opinion, mangling stderr and stdout together is already an
overcomplication.  It shouldn't be implemented.

It *seems* like a good idea, until you realize that subtle changes to your
OS, environment, or buffering behavior may result in arbitrary, unparseable
output.

For example, let's say you've got a program whose output is a list of lines,
each one containing a number.  Sometimes it tries to import gtk, and fails
to open its display.

That's fine, and you can still deal with it, as long as the interleaved
output looks like this:

100
200
Gtk-WARNING **: cannot open display:
300
400

but of course the output *might* (although unlikely with such small chunks
of output) end up looking like this, instead:

100
2Gtk-WAR0NING0 **:
can30not 0open display:

400

this is the sort of thing which is much more likely to happen once you start
dealing with large volumes of data, where there are more page-boundaries for
your buffers to get confused around, and you are playing with buffering
options to improve performance.  In other words, it's something that fails
only at scale or under load, and is therefore extremely difficult to debug.

This option *might* be okay if it were allowed only on subprocesses opened
in a *text* mode, and if the buffering logic involved forced stderr and
stdout to be line-delimited, and interleave only lines, rather than
arbitrary chunks of bytes.  Of course then if you use this flag with a
program that outputs binary data with no newlines it will buffer forever and
crash your program with a MemoryError, but at least that's easy to debug
when it happens.
___
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] Update to Python Documentation Website Request

2009-07-27 Thread David Lyon 
On Mon, 27 Jul 2009 20:12:54 +0900, "Stephen J. Turnbull"
 wrote:
> Not you; pythonpkgmgr.  You've said nothing about how pythonpkgmgr is
> supposed to deal with multiple installed versions of Python

Under windows it can deal with multiple versions of python. You just
go to options and select which version of python you wish to manage.

It's as simple as that.

> or how it helps if you need a custom version of a
> module, etc., or how it can help the developer's "local" modules
> cooperate/not interfere with system versions, etc.

It manages local developer modules for python 2.6+.

As for checks, it doesn't have so many at present. But it makes
it a lot easier to see what you have installed. So if something
needs to be removed and reinstalled - it can do that.

> Pave the road to DLL Hell with good intentions, of course.

Well - there's plenty of that

> 
>  > A developer shouldn't need to do sudo every time they want
>  > to put or try some python package from pypi.
> 
> I don't remember *ever* sudo-ing to try a package from pypi.

ok. But if you were using an O/S level package manager you
would have to enter a su password to start the tool. Because
that is needed to load packages into /usr/lib/pythonX.y

> I just don't understand what problem you're claiming to solve.  

Making it simpler for new users to find and install packages
from pypi. And manage the existing packages that are installed
on their machine.

> The
> problem of managing local package space is in some sense solved by
> virtualenv, but you haven't mentioned that at all.  

I never heard of it till a few months ago. To my knowledge it
doesn't offer a gui. I'm told it's good for certain things and
I believe it.

My problem was installing packages on windows boxes, not in
the development.

> Is pythonpkgmgr an
> alternative?  A complement?  to virtualenv or zc.buildout?

pythonpkgmgr is aimed at featherweight users. It could be
highly complementory to both virtualenv or zc.buildout at
some stage if it were customised to work with those.

For example, it could work with virtualenv by having a
a drop down list of the different 'environments'. I don't
know how to do it right now - but I'm hoping I can figure
it out sometime.

With zc.buildout, there's no reason why it couldn't generate
a package list in that format, or do an import from a
manifest. pythonpkgmgr already can generate a list of
local packages as a manifest - but not in the zc.buildout
format. I'm sure in the future - I'll figure that one out
as well.

David



___
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] Update to Python Documentation Website Request

2009-07-27 Thread David Lyon 
On Sun, 26 Jul 2009 19:31:40 +0200, "Martin v. Löwis" 
wrote:
>>> If they read examples, they will see import
>>> statements, and then they have to find out how to make those work.
>>> Does your tool help with that?
>> 
>> Yes. It will open the website or homepage to the project/package
>> in question.
> 
> How does it know the project in question?

Because it is either in the pypi search results or list of installed
packages.

> How do they find interbasedb in the list of installed packages if
> they haven't installed interbasedb yet?

They'd already installed it. But perphaps through a .exe installer.


David



___
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] Update to Python Documentation Website Request

2009-07-27 Thread David Lyon 
On Sun, 26 Jul 2009 19:33:37 +0200, "Martin v. Löwis" 
wrote:
>> pythonpkgmgr is not so different to that. And the idea behind it is
>> to bring consistancy in package management across the different 
>> platforms.
> 
> At the cost of being inconsistent within a platform.

It has the most generic of user interfaces.

On Windows, a command line interface is the most out-of-place thing
anybody could ask for.

19/20 kids these days wouldn't even know what a command line interface
is until you show them.

The first thing that they would look for is a GUI tool in the Python X.Y
programs menu...

So I respectfully say that there couldn't be anything less true than
the assertion that a GUI package manager is inconsistent within a
modern GUI desktop environment.

David

___
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] Update to Python Documentation Website Request

2009-07-27 Thread Stephen J. Turnbull 
David Lyon writes:

 > It manages local developer modules for python 2.6+.

 > pythonpkgmgr is aimed at featherweight users.

You were talking about "developers", but now they're "featherweight
users"?  I'm sorry, but the more you post, the less I like the idea of
including it with Python.  Please do develop it, do post it to pypi,
and do discuss it on python-list.  I'm sure there is an audience for
it, not only for Windows users but for the more GUI-oriented POSIX-
based platforms as well.

But I really don't think that python-dev is the appropriate place any
more.
___
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] Going nomail

2009-07-27 Thread Aahz 
I just started a new job today, and I've got a bunch of other stuff going
on in my life, so I'm setting python-dev and python-ideas to nomail for
a while.  Please feel free to ping me directly if you want.

I'll be back.
-- 
Aahz ([email protected])   <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
___
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] Update to Python Documentation Website Request

2009-07-27 Thread Martin v. Löwis 
>>> pythonpkgmgr is not so different to that. And the idea behind it is
>>> to bring consistancy in package management across the different 
>>> platforms.
>> At the cost of being inconsistent within a platform.
> 
> It has the most generic of user interfaces.
> 
[...]
> 
> So I respectfully say that there couldn't be anything less true than
> the assertion that a GUI package manager is inconsistent within a
> modern GUI desktop environment.

That's not my concern - I'm not worried about how it looks, but what
it does. If it "manages packages", I would expect it to manage them
the same way as the native package manager does, but alas, it doesn't
(IIUC). So there are now two incompatible ways to install a package:
either with the native manager, or with pythonpkgmgr. If you install
them one way, and try to remove them the other way, you lose.

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] Update to Python Documentation Website Request

2009-07-27 Thread David Lyon 
On Tue, 28 Jul 2009 07:12:25 +0200, "Martin v. Löwis" 
wrote:
> So there are now two incompatible ways to install a package:
> either with the native manager, or with pythonpkgmgr. If you install
> them one way, and try to remove them the other way, you lose.

pythonpkgmgr is only a thin wrapper for easy_install/pip.

If there is a problem, then it is already a pre-existing problem
that is not of my doing.

It's certainly true that if a python package is installed with a
windows installer or as a .deb/.rpm, then that package should be
uninstalled using the appropriate and corresponding tool.

The same is true if the package was installed with either pip
or easy_install. 

All I can do is put it in my tracker as a bug and deal with it
later when I have time.

Good point

David

___
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] Update to Python Documentation Website Request

2009-07-27 Thread Martin v. Löwis 
>> So there are now two incompatible ways to install a package:
>> either with the native manager, or with pythonpkgmgr. If you install
>> them one way, and try to remove them the other way, you lose.
> 
> pythonpkgmgr is only a thin wrapper for easy_install/pip.
> 
> If there is a problem, then it is already a pre-existing problem
> that is not of my doing.

Yes, eggs have the same problem. That's one of the reasons they
don't get integrated into Python.

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