Re: [Python-Dev] Add python.exe to PATH environment variable

[Tarek Ziadé]

On Wed, Sep 3, 2008 at 7:39 AM, Curt Hagenlocher <[EMAIL PROTECTED]>wrote:

>
> One other reason not to mess with the PATH -- at least by default --
> is that the user may have multiple copies of Python installed.  I know
> I have at least one machine with 2.4.5, 2.5.2, 2.6b2 and 3.0b2
> installed -- and I don't want *any* of them in my path.


Why ? you have them under Linux, through different names (python2.4,
python2.5, etc)
maybe this should be the same under Windows, e.g. having a common directory
where
all Python installations add a binary with a specific name, and same thing
for binaries in Scripts,
(easy_install-2.4, easy_install-2.5)

a /usr/local/bin for Windows in a way... system32 ?

Tarek

>
>
> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> 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/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
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] Add python.exe to PATH environment variable

[Cesare Di Mauro]

On 03 sep 2008 at 00:50:13, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:

> There already is a menu entry that starts the Python interpreter
> on Windows, so why not use that ?

Because i need to start Python from folders which have
files that define a specific "environment".

I have several servers and applications that develop and test this way.

> Also .py files are automatically associated with the last installed
> Python interpreter, so the double-clicking on .py files works and is
> probably the most common way of starting a Python file on Windows.

99% of time I run Python from a command prompt (on specific
directories).

I use the default menu entry only when I have to play with Python to test some
pieces of code.

> Adding paths to the PATH variable is not easy on Windows, esp. if
> you want to support multiple Windows versions. The global PATH
> settings are not read from autoexec.bat anymore (only once at boot
> time). Instead those environment variables are managed via the
> registry.
>
> See e.g.
>
> http://agiletesting.blogspot.com/2005/06/handling-path-windows-registry-value.html
>
> for how to setup PATH to your liking using Python.
>
> The problem is: how to undo those changes without accidentally
> undoing an explicit change made by the user ?
>
> BTW: Adding the Python dir to the PATH per default would cause
> problems for users who regularly have multiple different
> Python installations on a machine. If this is done, it should
> be an install option and not forced.

Let the user to decide to update or not the PATH envar by marking a
chechbox in the setup process, displaying that doing that the
changes will NOT be reverted when uninstalling it.

Cheers,
Cesare
___
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] Further PEP 8 compliance issues in threading and multiprocessing

[Nick Coghlan]

Greg Ewing wrote:
> Steven D'Aprano wrote:
>> Why not expose the class directly, instead of making it private and
>> then exposing it via a factory function that does nothing else?
> 
> This option would also have the advantage of not
> changing the API (unless there's code out there that
> actually depends on them *not* being classes, and
> that seems rather unlikely).

The multiprocessing implementation currently appears to have an annoying
circular import involving the multiprocessing package and the
_multiprocessing extension module - the factory functions in
multiprocessing.__init__ currently delay some of the relevant imports
long enough to keep any problems from actually occurring.

At some point that circular import should probably be eliminated (e.g.
via a _mp_bootstrap module), but until that happens at least some of the
factory functions in multiprocessing are actually required in order for
it to be possible to import the package at all.

And, as Guido already noted, leaving them as factory functions with
private implementations means users can't come to rely on the objects
being subclassable, and thus potentially allows more efficient
implementations (e.g. using near native locking implementations directly).

The only unfortunate aspect of the API is that the current names suggest
that these are factory functions rather than classes - if it hadn't been
for that, the question would have never even been raised. Since we
already have guidelines in place for dealing with ordinary API renames,
this is no longer something that strikes me as particularly urgent in
the 2.6/3.0 timeframe.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] Add python.exe to PATH environment variable

[M.-A. Lemburg]

On 2008-09-03 04:12, Greg Ewing wrote:
> M.-A. Lemburg wrote:
> 
>> The problem is: how to undo those changes without accidentally
>> undoing an explicit change made by the user ?
> 
> Is that really much of an issue? If the PATH contains an
> entry corresponding to the Python installation that's
> being uninstalled, then it's not going to work once the
> installation is gone, so removing it isn't going to do
> much harm.

You have a point there :-)

> In any case, the danger could be reduced by picking
> some distinctive name for a new environment variable that
> a user isn't likely to come up with on their own, such
> as __AUTOPYEXECDIR__, setting that to the Python directory,
> and adding it to PATH. The uninstaller can then be fairly
> selective about what it removes.
> 
>> BTW: Adding the Python dir to the PATH per default would cause
>> problems for users who regularly have multiple different
>> Python installations on a machine.
> 
> No more problem than having it set the file associations,
> as far as I can see. If you have multiple Pythons, you're
> going to have to be explicit about which one you want
> from the command shell anyway, and not rely on a PATH
> setting.

True, I have configured Windows to provide several
"Open with Python x.x" in order to have more flexibility.

However, always having the latest version on PATH is not
an option either, since e.g. I wouldn't want all .py scripts
to be run by Python 3.0 just because I installed it for
testing purposes.

>> If this is done, it should be an install option and not forced.
> 
> Certainly it should be an option. I'm not sure about
> having it disabled by default, though, since naive users
> are the ones that stand to benefit most from it, yet
> they're least likely to know that they need to turn it
> on.

In my experience, Windows apps seem to be moving aways from
cluttering up PATH and include each and every single app
dir to it.

Instead, if they bother at all, they simply place a .bat or
small .exe into the Window system dir (which already is
on PATH).

Perhaps we could have an option to place a "python.bat"
into C:\Windows\ or C:\Windows\System\.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 03 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Add python.exe to PATH environment variable

[M.-A. Lemburg]

On 2008-09-03 10:15, Cesare Di Mauro wrote:
> On 03 sep 2008 at 00:50:13, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> 
>> There already is a menu entry that starts the Python interpreter
>> on Windows, so why not use that ?
> 
> Because i need to start Python from folders which have
> files that define a specific "environment".
> 
> I have several servers and applications that develop and test this way.

Same here, but I usually have a env.bat that sets up whatever
environment I need (including the required Python version) and
run that when opening a prompt to work on a particular project.

>> Also .py files are automatically associated with the last installed
>> Python interpreter, so the double-clicking on .py files works and is
>> probably the most common way of starting a Python file on Windows.
> 
> 99% of time I run Python from a command prompt (on specific
> directories).
> 
> I use the default menu entry only when I have to play with Python to test some
> pieces of code.

IMHO, the only point of having the installer do this for the user
is for the case where the user does not know how to manipulate
PATH on Windows, but still wants to use the command line to access it
directly.

How many users would fit that category ?

>> Adding paths to the PATH variable is not easy on Windows, esp. if
>> you want to support multiple Windows versions. The global PATH
>> settings are not read from autoexec.bat anymore (only once at boot
>> time). Instead those environment variables are managed via the
>> registry.
>>
>> See e.g.
>>
>> http://agiletesting.blogspot.com/2005/06/handling-path-windows-registry-value.html
>>
>> for how to setup PATH to your liking using Python.
>>
>> The problem is: how to undo those changes without accidentally
>> undoing an explicit change made by the user ?
>>
>> BTW: Adding the Python dir to the PATH per default would cause
>> problems for users who regularly have multiple different
>> Python installations on a machine. If this is done, it should
>> be an install option and not forced.
> 
> Let the user to decide to update or not the PATH envar by marking a
> chechbox in the setup process, displaying that doing that the
> changes will NOT be reverted when uninstalling it.

Hmm, I don't think that's a good way to go about this. The uninstall
should undo all changes.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 03 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Add python.exe to PATH environment variable

[Eric Smith]

M.-A. Lemburg wrote:

On 2008-09-03 04:12, Greg Ewing wrote:

M.-A. Lemburg wrote:


The problem is: how to undo those changes without accidentally
undoing an explicit change made by the user ?

Is that really much of an issue? If the PATH contains an
entry corresponding to the Python installation that's
being uninstalled, then it's not going to work once the
installation is gone, so removing it isn't going to do
much harm.


You have a point there :-)


Unless you install it with the "add to path" option, deinstall it, and 
the reinstall without the "add to path" option. That is, assuming the 
install directory is the same every time.


Not that I think this is common, except in testing scenarios.

> Perhaps we could have an option to place a "python.bat"
> into C:\Windows\ or C:\Windows\System\.

Except you still have the "last in wins" issue, and you have to make a 
decision on whether or not to delete the file.  But I agree that 
managing a single batch file is easier than dealing with the PATH 
variable, and has fewer side effects (finding DLL's, etc.).


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] fileobj.read(float): warning or error?

[Isaac Morland]

On Wed, 3 Sep 2008, Greg Ewing wrote:


> The Unix read() system call doesn't treat EOF as special other than it
> won't return bytes from "beyond" EOF and therefore even when reading a
> regular file could return fewer (including 0) bytes than asked for in
> the call.


No, that's not right -- a read of more than 0 bytes will
always block until at least 1 byte is available, or
something happens that counts as an EOF condition.

However, with some devices it's possible for what
counts as EOF to happen more than once, e.g. ttys.


Sorry, you're absolutely right.  I was thinking only of the fact that 
read() at EOF is not an error, rather than the blocking behaviour.  It 
sounds like Python read() really is very similar to Unix read() in 
behaviour.


Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
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] Add python.exe to PATH environment variable

[Thomas Heller]

>  > Perhaps we could have an option to place a "python.bat"
>  > into C:\Windows\ or C:\Windows\System\.
> 
> Except you still have the "last in wins" issue, and you have to make a 
> decision on whether or not to delete the file.

If this is done the batch file should be named "python25.bat" or so
depending on the version.

-- 
Thanks,
Thomas

___
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] Add python.exe to PATH environment variable

[karim hamidou]

On Wed, Sep 3, 2008 at 3:10 PM, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>  > Perhaps we could have an option to place a "python.bat"
>>  > into C:\Windows\ or C:\Windows\System\.
>>
> If this is done the batch file should be named "python25.bat" or so
> depending on the version.
>
Instead of having a .bat file we could have a helper program that sets
the appropriate PATH and then runs cmd.exe.
It would be available from the start menu. This way, we wouldn't
clutter C:\Windows\System\ with batch files.
___
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] Add python.exe to PATH environment variable

[Paul Moore]

On 03/09/2008, Thomas Heller <[EMAIL PROTECTED]> wrote:
> >  > Perhaps we could have an option to place a "python.bat"
> >  > into C:\Windows\ or C:\Windows\System\.
> >
> > Except you still have the "last in wins" issue, and you have to make a
> > decision on whether or not to delete the file.
>
> If this is done the batch file should be named "python25.bat" or so
> depending on the version.

Bat files don't work when called from another bat file. This hits me
regularly, when people supply wrapper bat files. Example:

myscript.bat:
@echo off
do some stuff
python my_py_script.py
do some more stuff

If "python" is a bat file, "do some more stuff" will never get run
(you need to say "call python" to allow bat files to nest).

-1 (or stronger!) on a bat file.

If it goes in anyway, make it optional and off by default. The
confusion and wasted time caused by bat files "stopping" part way
through is FAR worse than that caused by having to manage PATH for
yourself.

Paul.

PS If anyone knows a *good* way of writing wrapper scripts on Windows
which doesn't suffer from the bat file nesting problem above, please
let me (and the rest of the world!) know!
___
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] Add python.exe to PATH environment variable

[Tim Golden]

Paul Moore wrote:

On 03/09/2008, Thomas Heller <[EMAIL PROTECTED]> wrote:

 > Perhaps we could have an option to place a "python.bat"
 > into C:\Windows\ or C:\Windows\System\.

Except you still have the "last in wins" issue, and you have to make a
decision on whether or not to delete the file.

If this is done the batch file should be named "python25.bat" or so
depending on the version.


Bat files don't work when called from another bat file. 


You can use "CALL" within one batch file to chain
another, returning afterwards to the first. But
this is obviously not the most transparent thing
on earth!

TJG
___
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] Add python.exe to PATH environment variable

[Thomas Heller]

Paul Moore schrieb:
> Bat files don't work when called from another bat file. This hits me
> regularly, when people supply wrapper bat files. Example:
> 
> myscript.bat:
> @echo off
> do some stuff
> python my_py_script.py
> do some more stuff
> 
> If "python" is a bat file, "do some more stuff" will never get run
> (you need to say "call python" to allow bat files to nest).
> 
> -1 (or stronger!) on a bat file.
> 
> If it goes in anyway, make it optional and off by default. The
> confusion and wasted time caused by bat files "stopping" part way
> through is FAR worse than that caused by having to manage PATH for
> yourself.
> 
> Paul.
> 
> PS If anyone knows a *good* way of writing wrapper scripts on Windows
> which doesn't suffer from the bat file nesting problem above, please
> let me (and the rest of the world!) know!

/F's exemaker and Philip's setuptools script wrapper come to mind.

-- 
Thanks,
Thomas

___
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] Add python.exe to PATH environment variable

[Paul Moore]

On 03/09/2008, Tim Golden <[EMAIL PROTECTED]> wrote:
> You can use "CALL" within one batch file to chain
> another, returning afterwards to the first.

Correct. Sorry, I forgot to mention that.

> But this is obviously not the most transparent thing
> on earth!

Indeed - and it certainly isn't a "wrapper" in the sense that I would
use the word (which is more in the sense of "drop-in replacement").

Paul.
___
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] Add python.exe to PATH environment variable

[Tarek Ziadé]

On Wed, Sep 3, 2008 at 3:46 PM, Paul Moore <[EMAIL PROTECTED]> wrote:

>
>
> PS If anyone knows a *good* way of writing wrapper scripts on Windows
> which doesn't suffer from the bat file nesting problem above, please
> let me (and the rest of the world!) know!


You can use setuptools console scripts, they are added in the Scripts
directory by default,
but this is optional

see :
http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation

We write all our wrappers with it and... hum.. add /Scripts to PATH under
Windows :D

Tarek
___
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] Add python.exe to PATH environment variable

[Cesare Di Mauro]

On 03 Sep 2008 at 13:34:18, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:

> Same here, but I usually have a env.bat that sets up whatever
> environment I need (including the required Python version) and
> run that when opening a prompt to work on a particular project.

> IMHO, the only point of having the installer do this for the user
> is for the case where the user does not know how to manipulate
> PATH on Windows, but still wants to use the command line to access it
> directly.
>
> How many users would fit that category ?

I don't know, but when you are working with just one python instance,
there's no need to use batch files neither to care about what PATH says:
it's always the right one instance that will be picked. :)

>> Let the user to decide to update or not the PATH envar by marking a
>> chechbox in the setup process, displaying that doing that the
>> changes will NOT be reverted when uninstalling it.
>
> Hmm, I don't think that's a good way to go about this. The uninstall
> should undo all changes.

The problem here is that uninstaller doesn't work this way.

May be an external program called by the uninstaller can take care
of this, removing what was added to PATH.

Cesare
___
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] Add python.exe to PATH environment variable

[Antoine Pitrou]

Mark Hammond  skippinet.com.au> writes:
> 
> I mean that many Windows use the PATH, and as such, may fail if a new
> directory is added to the PATH that contains a DLL they indirectly use.

Then it's just a matter of not putting any DLLs in those directories, isn't it?

> If I *did* expect other programs to be able to find a
> 'python.exe', I'm not sure I'd want to risk that installing a later version
> of Python will change what Python is found.

Most Linux distributions solve that by installing binaries named
/usr/bin/python2.4, /usr/bin/python2.5, etc., and making /usr/bin/python a
symlink to one of those. Thus if a program relies on particular Python version,
it can just use a specific executable rather than a generic one.



___
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] 2.6 doc searching issue?

[skip]

>From this page:

http://docs.python.org/dev/index.html

I searched for "csv" and got just one hit:

http://docs.python.org/dev/contents.html?highlight=csv

Shouldn't it have at least matched the docs for the csv module itself, not
just the table of contents?

Thx,

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

[Python-Dev] HTTPS read-only SVN access is denied?

[techtonik]

SVN checkout over HTTPS protocol requires password. Is it intentional
or just temporary server issue? I am behind a proxy that doesn't
support PROPFIND requests and I can't test SVN+SSH, because 22 port is
closed.

Site docs keep silence about that HTTPS is used at all. Shouldn't
authentication be asked only on write access in normal SVN setup?


BTW, link to "current svn tree" is broken here -
http://www.python.org/dev/patches/
-- 
--anatoly t.
___
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] HTTPS read-only SVN access is denied?

[Antoine Pitrou]

techtonik  gmail.com> writes:
> 
> SVN checkout over HTTPS protocol requires password. Is it intentional
> or just temporary server issue? I am behind a proxy that doesn't
> support PROPFIND requests and I can't test SVN+SSH, because 22 port is
> closed.

As a workaround, if you only need read-only access, you can use the Mercurial
mirrors which should work through your proxy (AFAIK Mercurial only uses GET and
POST).

Type "hg clone http://code.python.org/hg/trunk/"; or "hg clone
http://code.python.org/hg/branches/py3k"; depending on what you need exactly.

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] Further PEP 8 compliance issues in threading and multiprocessing

[Guido van Rossum]

2008/9/2 Greg Ewing <[EMAIL PROTECTED]>:
> Steven D'Aprano wrote:
>>
>> Why not expose the class directly, instead of making it private and then
exposing it via a factory function that does nothing else?
>
> This option would also have the advantage of not
> changing the API (unless there's code out there that
> actually depends on them *not* being classes, and
> that seems rather unlikely).

No. Allowing them to be subclassed makes it harder to replace them on some
platforms with equivalent but faster implementations.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] HTTPS read-only SVN access is denied?

[techtonik]

On Wed, Sep 3, 2008 at 6:08 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> As a workaround, if you only need read-only access, you can use the Mercurial
> mirrors which should work through your proxy (AFAIK Mercurial only uses GET 
> and
> POST).
>
> Type "hg clone http://code.python.org/hg/trunk/"; or "hg clone
> http://code.python.org/hg/branches/py3k"; depending on what you need exactly.

I do not need the whole branch - only a small subset of files related
to distutils. I know that bazaar can't do partial checkouts - it can
only fetch the whole branch. What about mercurial?

And why not to setup HTTPS for anonymous read and authorized write
access? It is not that hard to do and will solve many problems with
proxies.

-- 
--anatoly t.
___
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] HTTPS read-only SVN access is denied?

[Brett Cannon]

On Wed, Sep 3, 2008 at 3:39 PM, techtonik <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 3, 2008 at 6:08 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>
>> As a workaround, if you only need read-only access, you can use the Mercurial
>> mirrors which should work through your proxy (AFAIK Mercurial only uses GET 
>> and
>> POST).
>>
>> Type "hg clone http://code.python.org/hg/trunk/"; or "hg clone
>> http://code.python.org/hg/branches/py3k"; depending on what you need exactly.
>
> I do not need the whole branch - only a small subset of files related
> to distutils. I know that bazaar can't do partial checkouts - it can
> only fetch the whole branch. What about mercurial?
>
> And why not to setup HTTPS for anonymous read and authorized write
> access? It is not that hard to do and will solve many problems with
> proxies.

Because it requires setting up a certificate. You can use HTTP to do a
read-only checkout.

-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] HTTPS read-only SVN access is denied?

[Antoine Pitrou]

techtonik  gmail.com> writes:
> 
> I do not need the whole branch - only a small subset of files related
> to distutils. I know that bazaar can't do partial checkouts - it can
> only fetch the whole branch. What about mercurial?

Mercurial can't do it either. But I don't think it matters a lot; unless your
bandwidth is very low the full clone should be fast enough. Here it takes just
150s. for the trunk.

> And why not to setup HTTPS for anonymous read and authorized write
> access? It is not that hard to do and will solve many problems with
> proxies.

I don't know really, someone else should answer.



___
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] HTTPS read-only SVN access is denied?

[Benjamin Peterson]

On Wed, Sep 3, 2008 at 6:08 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 3, 2008 at 3:39 PM, techtonik <[EMAIL PROTECTED]> wrote:
>> On Wed, Sep 3, 2008 at 6:08 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>>
>>> As a workaround, if you only need read-only access, you can use the 
>>> Mercurial
>>> mirrors which should work through your proxy (AFAIK Mercurial only uses GET 
>>> and
>>> POST).
>>>
>>> Type "hg clone http://code.python.org/hg/trunk/"; or "hg clone
>>> http://code.python.org/hg/branches/py3k"; depending on what you need exactly.
>>
>> I do not need the whole branch - only a small subset of files related
>> to distutils. I know that bazaar can't do partial checkouts - it can
>> only fetch the whole branch. What about mercurial?
>>
>> And why not to setup HTTPS for anonymous read and authorized write
>> access? It is not that hard to do and will solve many problems with
>> proxies.
>
> Because it requires setting up a certificate. You can use HTTP to do a
> read-only checkout.

Or you could download a tarball snapshot: http://svn.python.org/snapshots/

>
> -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/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] [issue3769] Deprecate bsddb for removal in 3.0

[Raymond Hettinger]

I think this should be deferred to Py3.1. 

This decision was not widely discussed and 
I think it likely that some users will

be surprised and dismayed.  The release
candidate seems to be the wrong time to
yank this out (in part because of the surprise
factor) and in part because I think the change
silently affects shelve performance so that the
impact may be significantly negative but not
readily apparent.

We don't have to take this out.  So why do
it hastily at the last minute and without some
discussion on comp.lang.python at least.

If it were any other release, we would have
disciplined ourselves to deprecate first and
remove a generation or two later.

Also, the reason for removal may yet disappear
if jcrea steps in an continues to make updates.

Also, the referenced note ( 
http://mail.python.org/pipermail/python-dev/2008-July/081379.html )
say to "start end-of-lifing it" which I took to mean deprecate rather than 
remove during a release candidate.


Raymond




- Original Message - 
From: "Benjamin Peterson" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 03, 2008 4:32 PM
Subject: [issue3769] Deprecate bsddb for removal in 3.0




Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Also see this:
http://mail.python.org/pipermail/python-3000/2008-September/014712.html

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/python%40rcn.com


___
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] [issue3769] Deprecate bsddb for removal in 3.0

[Brett Cannon]

On Wed, Sep 3, 2008 at 4:41 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I think this should be deferred to Py3.1.
> This decision was not widely discussed and I think it likely that some users
> will
> be surprised and dismayed.

Perhaps, but that could be said about almost any module that has been
removed through the stdlib reorg.

>  The release
> candidate seems to be the wrong time to
> yank this out (in part because of the surprise
> factor) and in part because I think the change
> silently affects shelve performance so that the
> impact may be significantly negative but not
> readily apparent.
>
> We don't have to take this out.

We don't have to remove anything that has gone through the stdlib
reorg, so that is not a solid argument.

>  So why do
> it hastily at the last minute and without some
> discussion on comp.lang.python at least.
>

It isn't being done "hastily"; this has been planned for a while.
People have just been too busy to get around to it. And we are not
changing any semantics or removing something from the language which
is what I view as what you don't change in an rc. So this might come
down to a different opinion of what one can do during an rc.

> If it were any other release, we would have
> disciplined ourselves to deprecate first and
> remove a generation or two later.
>

We are deprecating first in 2.6.

> Also, the reason for removal may yet disappear
> if jcrea steps in an continues to make updates.
>

OK, but none of his changes have received a code review, so if we are
going to go down the whole "disciplined" route about it being an rc
then we should back out all of Jesus' changes for both 2.6 and 3.0,
which puts us back to the same instability issues.

> Also, the referenced note (
> http://mail.python.org/pipermail/python-dev/2008-July/081379.html )
> say to "start end-of-lifing it" which I took to mean deprecate rather than
> remove during a release candidate.

Well, it was in the PEP before beta2 even went out the door.

-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] Add python.exe to PATH environment variable

[Greg Ewing]

Eric Smith wrote:

But I agree that 
managing a single batch file is easier than dealing with the PATH 
variable, and has fewer side effects (finding DLL's, etc.).


This would only be possible for an administrator
installation, though, not a per-user one.

--
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] Add python.exe to PATH environment variable

[Greg Ewing]

M.-A. Lemburg wrote:


However, always having the latest version on PATH is not
an option either, since e.g. I wouldn't want all .py scripts
to be run by Python 3.0 just because I installed it for
testing purposes.


Keep in mind that the normal installation process on
unix *does* make "python" refer to the most recently
installed version, at least for 2.x, and it's not
considered a problem there.

In the case of 3.0, didn't we decide not to do that?

--
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] Add python.exe to PATH environment variable

[Greg Ewing]

Tim Golden wrote:


You can use "CALL" within one batch file to chain
another, returning afterwards to the first.


You need to know that what you're calling is a bat
file to have the foresight to do that, though. I
can imagine people not expecting "python" to be
a bat file.

Instead of a bat file, maybe generate a small exe
that does the job?

--
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] [Python-3000] bsddb finished for 2.6/3.0 (and ": str() on a bytes instance")

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 3, 2008, at 7:01 PM, Jesus Cea wrote:


Barry Warsaw wrote:
and I know Brett agrees, so that's it.  On IRC, I've just asked  
Benjamin

to do the honors for 3.0 and Brett will add the deprecations for 2.6.


I just committed the fix for bsddb testsuite in Python 3.0 branch:
http://www.python.org/dev/buildbot/3.0.stable/changes/2687

Can I do anything to revert this decision?. If not, what can I do to  
be

reconsidered in 3.1?.


Start raising some pitchforks.  It looks like Raymond will join the  
march :).


Really, this is about what's best for Python and pybsddb.  In this  
article, Guido unambiguously states his opinion:


http://mail.python.org/pipermail/python-dev/2008-July/081362.html

"+1. In my recollection maintaining bsddb has been nothing but trouble
right from the start when we were all sitting together at "Zope Corp
North" in a rented office in McLean... We can remove it from 3.0. We
can't really remove it from 2.6, but we can certainly start
end-of-lifing it in 2.6."

Jesus, let me stress that IMO this is not a reflection on your work at  
all.  On the contrary, keeping it alive in 2.x and providing a really  
solid independent package for 3.0 is critical for its continued  
relevance to Python programmers.


I completely agree with Guido that bsddb (not pybsddb) has been a  
headache since forever.  For example, IIRC Sleepycat was notorious for  
changing the API in micro releases, though I don't know if that's  
still the case with the current maintainers.  I personally believe  
that Python and pybsddb are both better off with their own maintenance  
lifecycles so I stand by my decision that pulling it out of 3.0 is the  
right thing to do.  3.1 is far enough away that any decision we make  
in 3.0 can be re-evaluated.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSL85BnEjvBPtnXfVAQLfkwQAtoagOP37uAwL1r2H7w73erTsWBYHf4VH
KcTZsjeQ/mEvmaaJIG86ylAtpxmDmMF5x7OClR66bXXxf0oTnWV4KMC9rLdQW8R/
KpMIfuQw/501AQgFmcB0M6SQ6CYyJHU5K+K6X+ScOPHOJoG8usPK1pk8XFGOXBZK
UGXCEHVvlrk=
=7AOQ
-END 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

[Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Wed, Sep 03, 2008 at 04:41:32PM -0700, Raymond Hettinger wrote:
-> I think this should be deferred to Py3.1. 
-> 
-> This decision was not widely discussed and 
-> I think it likely that some users will
-> be surprised and dismayed.  The release
-> candidate seems to be the wrong time to
-> yank this out (in part because of the surprise
-> factor) and in part because I think the change
-> silently affects shelve performance so that the
-> impact may be significantly negative but not
-> readily apparent.

Related but tangential question that we were discussing on the pygr[0]
mailing list -- what is the "official" word on a scalable object store
in Python?  We've been using bsddb, but is there an alternative?  And
what if bsddb is removed?

It would be very nice to have a moderately scalable (thousands to
millions, if not billions) cross-platform object store backend
distributed with Python.

sqlite could be one choice, but I haven't used it much yet, so I don't
know.

thanks,
--titus

[0] Python graph database for bioinformatics, 

http://code.google.com/p/pygr
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Python 3.0b3 documentation typo

[Reed O'Brien]

I was reading through the Dictionary views section:

http://docs.python.org/dev/3.0/library/stdtypes.html#dictionary-view-objects

Unless I am mistaken; the intersection at the end of the example usage  
should be:


>>> keys & {'eggs', 'bacon', 'salad'}
{'bacon'}


Cheers,
~ro
___
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] Not releasing rc1 tonight

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm not going to release rc1 tonight.  There are too many open release  
blockers that I don't want to defer, and I'd like the buildbots to  
churn through the bsddb removal on all platforms.  Let me first thank  
Benjamin, Brett, Mark and Antoine for their help on IRC tonight.


Here are the issues I'm not comfortable with deferring:

  3640 test_cpickle crash on AMD64 Windows build
874900 threading module can deadlock after fork
  3574 compile() cannot decode Latin-1 source encodings
  3657 pickle can pickle the wrong function
  3187 os.listdir can return byte strings
  3660 reference leaks in 3.0
  3594 PyTokenizer_FindEncoding() never succeeds
  3629 Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2

In addition, Mark reported in IRC that there are some regressions in  
the logging module.


I appreciate any feedback or fixes you can provide on these issues.   
You might also want to look at the deferred blockers to see if there's  
anything that really should be blocking rc1.


I'd like to try again on Friday and stick to rc2 on the 17th.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSL9Y53EjvBPtnXfVAQJGXwP+JZUa5EWlQh7yzt7aFdEM3qgiFZnKqWhz
TN4Cen0/eK8c4+t8a5WC+OLvc/P3PhMPhLSnE+g6IqQUO+pt+2LANgpAvCUrUahc
Nk2pt3gCclcmWlzVvCBspVPZjFPkHsW0uVhgK6x1C/2Re90yjeBqPGgT4LGlmaR3
bz6A3iiUnk0=
=Y5aN
-END 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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Brett Cannon]

On Wed, Sep 3, 2008 at 7:56 PM, C. Titus Brown <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 03, 2008 at 04:41:32PM -0700, Raymond Hettinger wrote:
> -> I think this should be deferred to Py3.1.
> ->
> -> This decision was not widely discussed and
> -> I think it likely that some users will
> -> be surprised and dismayed.  The release
> -> candidate seems to be the wrong time to
> -> yank this out (in part because of the surprise
> -> factor) and in part because I think the change
> -> silently affects shelve performance so that the
> -> impact may be significantly negative but not
> -> readily apparent.
>
> Related but tangential question that we were discussing on the pygr[0]
> mailing list -- what is the "official" word on a scalable object store
> in Python?  We've been using bsddb, but is there an alternative?  And
> what if bsddb is removed?
>

Beyond shelve there are no official plans to add a specific object store.

-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] Not releasing rc1 tonight

[Raymond Hettinger]

[Barry]
I'm not going to release rc1 tonight.  


Can I go ahead with some bug fixes and doc improvements
or should I wait until after Friday?


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] Python 3.0b3 documentation typo

[Gregory P. Smith]

thanks.  in general report all issues even ones like this on
bugs.python.org rather than on a mailing list where they can get lost.

i've fixed this trivial one in py3k svn r66207.

On Wed, Sep 3, 2008 at 8:16 PM, Reed O'Brien <[EMAIL PROTECTED]> wrote:
> I was reading through the Dictionary views section:
>
> http://docs.python.org/dev/3.0/library/stdtypes.html#dictionary-view-objects
>
> Unless I am mistaken; the intersection at the end of the example usage
> should be:
>
 keys & {'eggs', 'bacon', 'salad'}
> {'bacon'}
>
>
> Cheers,
> ~ro
> ___
> 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/greg%40krypto.org
>
___
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] [issue3769] Deprecate bsddb for removal in 3.0

[Michele Simionato]

On Thu, Sep 4, 2008 at 1:41 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The release
> candidate seems to be the wrong time to
> yank this out (in part because of the surprise
> factor) and in part because I think the change
> silently affects shelve performance so that the
> impact may be significantly negative but not
> readily apparent.

I do not use bsddb directly, but I use shelve which on Linux usually
takes advantage of bsddb. Does removing bsddb mean that
I will not be able to read shelve files written with Python 2.5
with Python 3.0? That would be quite disturbing to me.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C API for gc.enable() and gc.disable()

[Andrey Zhmoginov]

Would anyone mind if I did add a public C API for gc.disable() and
gc.enable()? I would like to use it as an optimization for the pickle
module (I found out that I get a good 2x speedup just by disabling the
GC while loading large pickles). Of course, I could simply import the
gc module and call the functions there, but that seems overkill to me.
I included the patch below for review.
  
I don't know if the following question is relevant, but it seems that 
many people here are familiar with Python cyclic garbage collector.
I see Python [v2.5.2 (r252:60911, Jul 31 2008, 17:28:52)] crashing with 
Segment fault when I extend Python with a very simple module. This 
behavior is observed when I create a thousand of lists (it does not 
crash with 10-100) in the module with the garbage collector turned on. 
When I turn it off - everything is perfect. I suspect that it is my 
module, but if it is a Python bug ( _GC_Malloc? memory leak somewhere?), 
it may be worth reporting.


The gdb "where" reply is the following:

   #0  0x080d8de9 in PyErr_Occurred ()
   #1  0x080f508f in _PyObject_GC_Malloc ()
   #2  0x080f5155 in _PyObject_GC_New ()
   #3  0x08079c98 in PyList_New ()
   #4  0xb7f53519 in draw_d_simple () from ./rt/rt_core.so
   #5  0xb7cf7833 in ffi_call_SYSV () from 
/usr/lib/python2.5/lib-dynload/_ctypes.so
   #6  0xb7cf766a in ffi_call () from 
/usr/lib/python2.5/lib-dynload/_ctypes.so
   #7  0xb7cf2534 in _CallProc () from 
/usr/lib/python2.5/lib-dynload/_ctypes.so

   #8  0xb7cec02a in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
   #9  0x0805cb97 in PyObject_Call ()
   #10 0x080c7aa7 in PyEval_EvalFrameEx ()
   #11 0x080c96e5 in PyEval_EvalFrameEx ()
   #12 0x080cb1f7 in PyEval_EvalCodeEx ()
   #13 0x080cb347 in PyEval_EvalCode ()
   #14 0x080ea818 in PyRun_FileExFlags ()
   #15 0x080eaab9 in PyRun_SimpleFileExFlags ()
   #16 0x08059335 in Py_Main ()
   #17 0x080587f2 in main ()

The crashing python code is:

   from ctypes import *
   import gc
   core = CDLL( "./tst.so" )
   core.a.argtypes = []
   core.a.restype = py_object
   #gc.disable()
   core.a()
   #gc.enable()

And tst.cpp is:

   #include 
   extern "C" { PyObject *a(); }
   PyObject *a()
   {
   int n = 1000;
   PyObject *item;
   for ( int i = 0; i < n; i++ ) item = PyList_New( 0 );  // 
Crashes here (somewhere in between).

   return item;
   }

tst.cpp is compiled with:

   g++ -shared -Wl,-soname,tst.tmp.so -o tst.so tst.o
   g++ -I /usr/include/python2.5 -Wall -fPIC -o tst.o -c tst.cpp

Thanks for your help!

- Andrew.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com