Re: [Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

[Nick Coghlan]

Tony Nelson wrote:
> I suppose the question is what a capitalized name promises.  If it means
> only "Class", then how should "Returns a new object", either from a Class
> or a Factory, be shown?  Perhaps a new convention is needed for Factories?

Any function can always return a new object (e.g. operator.add(list1,
list2), so I don't think we need a special naming convention to
explicitly flag factory functions.

The question I am raising is whether or not aberrations in the other
direction (factory functions that are named like a class, incorrectly
implying they can be used as a base class or as part of isinstance() or
issubclass() checks) are enough of a concern to add additional aliases
to the threading API, and to further modify the multiprocessing API this
close to RC1.

(Issue 3352 actually provides a complete list of the names that are
potentially at issue for both multiprocessing and threading - note that
Ben, with my concurrence, has closed that issue on the assumption that
the current naming scheme for these factory functions is acceptable).

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] Things to Know About Super

[Nick Coghlan]

average wrote:
> It seems that the frustration with super revolves around how Python
> currently conflates (as well as many users) two very different types
> of inheritance, both "is-a" and "has-a" (or compositional)
> inheritance.  Unfortunately, Python assists this confusion because the
> language doesn't provide a distinct enough way to differentiate
> between them.

has-a should be modelling with attributes, not inheritance. The latter
relationship should always mean is-a (even for mixins).

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

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

[Giampaolo Rodola']

Hi,
I've always found it strange that Python Windows installers never
managed to add the python executable to the PATH environment variable.
Are there plans for adding such a thing?

Thanks in advance

--- Giampaolo
http://code.google.com/p/pyftpdlib/
___
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

[Amaury Forgeot d'Arc]

Hello,

Giampaolo Rodola' wrote:
> Hi,
> I've always found it strange that Python Windows installers never
> managed to add the python executable to the PATH environment variable.
> Are there plans for adding such a thing?

I don't think so.
See the discussion of http://bugs.python.org/issue3561

-- 
Amaury Forgeot d'Arc
___
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

[Antoine Pitrou]

Nick Coghlan  gmail.com> writes:
> 
> Given the proximity of RC1, Antoine's option 3 (leaving the capitalised
> factory functions in both multiprocessing and threading APIs) is
> actually sounding pretty appealing to me at the moment.

I was actually suggesting this course for the threading module, whose API has
existed for a lot of time now, but I think it would be better to clean up
multiprocessing before its first stable relase. But the issue of time and
manpower starts being a bit critical :)



___
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.6b3 Windows installers

[M.-A. Lemburg]

The download page doesn't list any Windows installer for 2.6b3:

http://www.python.org/download/releases/2.6/

I suppose this is due to Martin building the installers and him not
be available at the moment.

Since Python on Windows will likely only get very few beta testers
without a Windows installer build, I'd suggest to postpone the
RC1 release that's planned for tomorrow to get more feedback for the
Windows builds.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 02 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] 2.6b3 Windows installers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 2, 2008, at 8:09 AM, M.-A. Lemburg wrote:


I suppose this is due to Martin building the installers and him not
be available at the moment.


He should be back today.


Since Python on Windows will likely only get very few beta testers
without a Windows installer build, I'd suggest to postpone the
RC1 release that's planned for tomorrow to get more feedback for the
Windows builds.


I'd rather still release the rc tomorrow.

- -Barry

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

iQCVAwUBSL0we3EjvBPtnXfVAQKbRgQAhNM2q8M4Yd0IhbEd2+DWtZnfALdxXr8e
vfK0h3tH3+DZuEYyNLZHQOwLC7uUjqcKXc/y+v0EwY7Q13tYz0TCVcLY+0zbXsoi
on0TMh8kn/Wwlw/byKc8K3HFkKU4mhzxmLm4oq/8sbsQPABjkEtgNEXP4enmZFLU
U1R8E273MjY=
=e7/S
-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] Add python.exe to PATH environment variable

[Tarek Ziadé]

On Tue, Sep 2, 2008 at 1:38 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]>wrote:

> Hello,
>
> Giampaolo Rodola' wrote:
> > Hi,
> > I've always found it strange that Python Windows installers never
> > managed to add the python executable to the PATH environment variable.
>

+1

At this point, as far as I know, changing the PATH variable manually under
Windows is the most convenient
way to be able to work correctly with Python.


>
> > Are there plans for adding such a thing?
>
> I don't think so.
> See the discussion of http://bugs.python.org/issue3561
>

I don't understand why it is closed/wontfix though.

In the tracker Martin said:
"""

The very end-user related aspects of it need to be discussed
on python-dev (perhaps taking a poll whether this is desirable, whether
it should be optional, and if so, what the default should be)

"""

So I'd like to give my opinion here about this, because I've had this
problem while writing a book about Python.
(a book that is for people that use Python on *any* platform bien sûr, not
only Linux)

For me, the Windows installer does not work properly: I cannot open a
console and run Python right away.
I don't care about the technical complexity of setting it up automatically :
I simply think it is wrong not to be able to run
the interpreter the same way on Windows and Linux/Mac OS.

You may end up having to deal with it in your documentation. Look at all the
documentation out there. For instance Pylons:

http://wiki.pylonshq.com/display/pylonsdocs/Installing+Pylons

-> there's a small note on that page  "All windows users also should read
the section Post install tweaks for
Windowsafter
installation"
-> windows users need to go there :
http://wiki.pylonshq.com/display/pylonsdocs/Windows+Notes

Why do we have to take care about that ? Python installers should.

A lot of package out there create console scripts (buildout, sphinx,
rst2html, etc..) that lives in /Script, and are not reachable
in Windows unless the PATH is changed.

So I don't see any good reason (besides the technical complexity) to add it
to the Windows installer.
Or at least do something that will let us run Python and third-party scripts
from the command line even if it is done with PATH.

So I would love to see this ticket open again; I personnaly would be in
favor of an automatic change of PATH by the installer.

My 2 cents
Tarek

-- 
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

[Tarek Ziadé]

On Tue, Sep 2, 2008 at 3:04 PM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:

>
> So I don't see any good reason (besides the technical complexity) to add it
> to the Windows installer.
>

oups..  I don't see any good reason *not* to add it ... :)
___
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

[Christian Heimes]

Giampaolo Rodola' wrote:

Hi,
I've always found it strange that Python Windows installers never
managed to add the python executable to the PATH environment variable.
Are there plans for adding such a thing?


No, but I've added a little helper script several months ago. It adds
the Python and Script paths to %PATH%. See Tools/Scripts/win_add2path.py

Christian

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

Antoine Pitrou wrote:
> Nick Coghlan  gmail.com> writes:
>> Given the proximity of RC1, Antoine's option 3 (leaving the capitalised
>> factory functions in both multiprocessing and threading APIs) is
>> actually sounding pretty appealing to me at the moment.
> 
> I was actually suggesting this course for the threading module, whose API has
> existed for a lot of time now, but I think it would be better to clean up
> multiprocessing before its first stable relase. But the issue of time and
> manpower starts being a bit critical :)

Unfortunately, that's where the whole "close to a drop-in replacement
for threading" concept brings additions to the threading module API back
into play.

If I'd realised this a bit sooner I probably would have been pushing for
it to be dealt with for 2.6/3.0, but given that it's the kind of change
that we can easily do through the normal API deprecation process, I'm
really not comfortable messing with it this close to the release
(particularly after Jesse found a problem with the seemingly innocent
change to the multiprocessing implementation in issue 3589).

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

[Jesse Noller]

On Tue, Sep 2, 2008 at 10:03 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Antoine Pitrou wrote:
>> Nick Coghlan  gmail.com> writes:
>>> Given the proximity of RC1, Antoine's option 3 (leaving the capitalised
>>> factory functions in both multiprocessing and threading APIs) is
>>> actually sounding pretty appealing to me at the moment.
>>
>> I was actually suggesting this course for the threading module, whose API has
>> existed for a lot of time now, but I think it would be better to clean up
>> multiprocessing before its first stable relase. But the issue of time and
>> manpower starts being a bit critical :)
>
> Unfortunately, that's where the whole "close to a drop-in replacement
> for threading" concept brings additions to the threading module API back
> into play.
>
> If I'd realised this a bit sooner I probably would have been pushing for
> it to be dealt with for 2.6/3.0, but given that it's the kind of change
> that we can easily do through the normal API deprecation process, I'm
> really not comfortable messing with it this close to the release
> (particularly after Jesse found a problem with the seemingly innocent
> change to the multiprocessing implementation in issue 3589).
>
> Cheers,
> Nick.
>

Yes, the innocuous change in 3589 - which really made a lot of sense,
introduced a bug that didn't get caught until a complete make
distclean; rebuild - that actually scared me off of the idea of
addressing 3589 right now. I would move 3589 to 2.7/3.1 and file an
additional bug for any further pep8-ifying to both the threading and
mp APIs against 2.7 and 3.1

-jesse
___
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

[Steven D'Aprano]

On Mon, 1 Sep 2008 11:24:02 pm Nick Coghlan wrote:
> I've been taking a close look at the API for multiprocessing and
> threading, and have discovered a somewhat strange pattern that occurs
> multiple times in both interfaces: factory functions with names that
> start with a capital letter so they look like they're actually a
> class.
>
> At first I thought it was a quirk of the multiprocessing
> implementation, but then I discovered that the threading module also
> does it for all of the synchronisation objects as well as
> threading.Timer, with examples like:
>
>   def Event(*args, **kwds):
> return _Event(*args, **kwds)


Can anyone explain why those factory functions exist at all? They don't 
seem to do anything. Why not expose the class directly, instead of 
making it private and then exposing it via a factory function that does 
nothing else? Never mind whether or not the factory functions should 
start with an uppercase letter or not. Why are they even there?

Perhaps I'm missing some subtle (or even not-so-subtle) advantage, but 
it seems rather silly to me, as silly as this:

f = lambda x: function(x)
# better written as f = function

And yet threading.py has at least six examples just like that. What am I 
missing?


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

On Tue, Sep 2, 2008 at 9:36 AM, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Mon, 1 Sep 2008 11:24:02 pm Nick Coghlan wrote:
>> I've been taking a close look at the API for multiprocessing and
>> threading, and have discovered a somewhat strange pattern that occurs
>> multiple times in both interfaces: factory functions with names that
>> start with a capital letter so they look like they're actually a
>> class.
>>
>> At first I thought it was a quirk of the multiprocessing
>> implementation, but then I discovered that the threading module also
>> does it for all of the synchronisation objects as well as
>> threading.Timer, with examples like:
>>
>>   def Event(*args, **kwds):
>> return _Event(*args, **kwds)

> Can anyone explain why those factory functions exist at all? They don't
> seem to do anything. Why not expose the class directly, instead of
> making it private and then exposing it via a factory function that does
> nothing else? Never mind whether or not the factory functions should
> start with an uppercase letter or not. Why are they even there?
>
> Perhaps I'm missing some subtle (or even not-so-subtle) advantage, but
> it seems rather silly to me, as silly as this:
>
> f = lambda x: function(x)
> # better written as f = function
>
> And yet threading.py has at least six examples just like that. What am I
> missing?

I take full responsibility. This started out as an experiment in API
design, where I tried to make things look as much like the similar
Java API as possible (I didn't want to invent yet anotherwobbly
wheel). I specifically wanted these *not* to be classes so that people
wouldn't start subclassing them. At the time PEP-8 wasn't well
established (if at all) and I wanted the factory functions to look
like classes. I think in 2.7 / 3.1 we can change the factory functions
to conform to PEP-8 (leaving the old names in for a couple of
release). I still want the classes to be private, so that it's safe to
replace them with more efficient implementations on some platforms
without having to worry about subclasses.

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

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Guido van Rossum wrote:
> On Mon, Jul 21, 2008 at 10:37 PM, Cameron Simpson <[EMAIL PROTECTED]> wrote:
>> Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an
>> exception if asked for < 1 bytes? Or is there a legitimate use for read(0)
>> with which I was not previously aware?
> 
> Indeed. read(0) is quite often generated as an edge case when one is
> computing buffer sizes, and returning an empty string is most
> definitely the right thing to do here (otherwise some application code
> becomes more complex by having to avoid calling read(0) at all).

How do you differenciate between that empty string (when doing
"read(0)"), from EOF (that is signaled by an empty string)?.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSL1yZplgi5GaxT1NAQJdTAP7B4GaeBRFg1A6PibmH+2cmJs3AIO2qWrx
xfgRO1QVF4OnxGWIKTTbKWX4whBY/zA3UUs35XMSRUROlxPR1dCNIvlaQb+rCuO6
AL0IkE5Fe6iN+VlS9UqarUla9vGhrqD9BxMZmDisIu4uKJi7c3ChlGKuatk16RBQ
BosUJe3VjNM=
=GkbX
-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] fileobj.read(float): warning or error?

[Guido van Rossum]

On Tue, Sep 2, 2008 at 10:05 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>> On Mon, Jul 21, 2008 at 10:37 PM, Cameron Simpson <[EMAIL PROTECTED]> wrote:
>>> Leaving aside the 0.2 => 0 converstion, shouldn't read() raise an
>>> exception if asked for < 1 bytes? Or is there a legitimate use for read(0)
>>> with which I was not previously aware?
>>
>> Indeed. read(0) is quite often generated as an edge case when one is
>> computing buffer sizes, and returning an empty string is most
>> definitely the right thing to do here (otherwise some application code
>> becomes more complex by having to avoid calling read(0) at all).
>
> How do you differenciate between that empty string (when doing
> "read(0)"), from EOF (that is signaled by an empty string)?.

You don't. If you want to know whether you hit EOF you should try
reading a non-zero number of bytes. (Also note that getting fewer
bytes than you asked for is not enough to conclude that you have hit
EOF.)

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

[Isaac Morland]

On Tue, 2 Sep 2008, Jesus Cea wrote:


Indeed. read(0) is quite often generated as an edge case when one is
computing buffer sizes, and returning an empty string is most
definitely the right thing to do here (otherwise some application code
becomes more complex by having to avoid calling read(0) at all).


How do you differenciate between that empty string (when doing
"read(0)"), from EOF (that is signaled by an empty string)?.


Why would you expect a difference between reading 0 bytes at EOF and 
reading 0 bytes anywhere else?  If you read(4) when at offset 996 in a 
1000-byte file I doubt you expect any special notification that you are 
now at EOF.


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.


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

[Python-Dev] Also bsddb (was: Re: Further PEP 8 compliance issues in threading and multiprocessing)

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jean-Paul Calderone wrote:
> Here's a complaint.  It's surprising that you can't use Event et al with
> isinstance.  This is something I'm sure a lot of people run into (I did,
> many years ago) when they start to use these APIs.  Once you do figure
> out why it doesn't work, it's not clear how to do what you want, since
> _Event is private.


I have similar issues with bsddb. Here, there are Factory functions like
"DBEnv" or "DB", creating "DBEnv" and "DB" class instances. Note the
name aliasing.

I don't understand why these functions exist. It causes a few problems,
like being unable to subclass the bsddb classes, for example.

For future bsddb4.6.4 (Late october, I think) I plan to remove the
Factory functions, exporting the classes directly, and allowing
subclassing. The code should be 100% compatible.

Any opinion?

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCUAwUBSL2D3Jlgi5GaxT1NAQLJugP4qynGMZI8nN06rDyPU8FQ2kHig6uReuSE
GW2fTuKXrYLlwRW5vA1GV/nA1y+6dUPuOF5erwCjVsXp28jMKNlk0BfIXmqe1wz9
+N6bIVYlFeChp5M05TDYaCNUNgRGuHURV44DvZ+vjr9GqxHuVWHHcl0EKTTSlpMi
K6FBYiZjbw==
=DGEq
-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] fileobj.read(float): warning or error?

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Isaac Morland wrote:
> On Tue, 2 Sep 2008, Jesus Cea wrote:
> 
>>> Indeed. read(0) is quite often generated as an edge case when one is
>>> computing buffer sizes, and returning an empty string is most
>>> definitely the right thing to do here (otherwise some application code
>>> becomes more complex by having to avoid calling read(0) at all).
>>
>> How do you differenciate between that empty string (when doing
>> "read(0)"), from EOF (that is signaled by an empty string)?.
> 
> Why would you expect a difference between reading 0 bytes at EOF and
> reading 0 bytes anywhere else?  If you read(4) when at offset 996 in a
> 1000-byte file I doubt you expect any special notification that you are
> now at EOF.

My message was an answer to Guido one, saying that some programs
calculate the read len substracting buffer lengths, so, then can try to
read 0 bytes. Guido argues that returning a empty string is the way to go.

My point is: we are simplifying the program considering "0" a valid len
counter, but we complicates it because now the code can't consider "" =
EOF if it actually asked for 0 bytes.

> 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.

I always consider ""==EOF. I thought that was correct for non-blocking
sockets. Am I wrong?.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSL2GjZlgi5GaxT1NAQLniwP/SwdmA929j4oPplhtkVU82TYFoyevP/E2
QsHvCZ18CWYSa5LO00Vsd0Uo8ZQeqV8Gx6o2pG2ke66qI7c7pjTQcSO28Z3ztlVW
YZVbc46WGozjuiHh2tLVSckI4GyZJzs7+Btho2klE2dNygxWVEpT5Ueu+o2CK0Pl
Onf7jG4L+h0=
=YHQ/
-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] fileobj.read(float): warning or error?

[Guido van Rossum]

On Tue, Sep 2, 2008 at 11:31 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
> Isaac Morland wrote:
>> On Tue, 2 Sep 2008, Jesus Cea wrote:
>>
 Indeed. read(0) is quite often generated as an edge case when one is
 computing buffer sizes, and returning an empty string is most
 definitely the right thing to do here (otherwise some application code
 becomes more complex by having to avoid calling read(0) at all).
>>>
>>> How do you differenciate between that empty string (when doing
>>> "read(0)"), from EOF (that is signaled by an empty string)?.
>>
>> Why would you expect a difference between reading 0 bytes at EOF and
>> reading 0 bytes anywhere else?  If you read(4) when at offset 996 in a
>> 1000-byte file I doubt you expect any special notification that you are
>> now at EOF.
>
> My message was an answer to Guido one, saying that some programs
> calculate the read len substracting buffer lengths, so, then can try to
> read 0 bytes. Guido argues that returning a empty string is the way to go.
>
> My point is: we are simplifying the program considering "0" a valid len
> counter, but we complicates it because now the code can't consider "" =
> EOF if it actually asked for 0 bytes.

Note that it has been like this for a very long time.

>> 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.
>
> I always consider ""==EOF. I thought that was correct for non-blocking
> sockets. Am I wrong?.

You can continue to assume this if you never pass 0 to read().

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

[Terry Reedy]

Tarek Ziadé wrote:


So I don't see any good reason (besides the technical complexity)


Unless and until someone is able and willing to deal with the technical 
complexity, that would seem to be a sufficient reason.


>  to [not, I presume] add  it to the Windows installer.

So I would love to see this ticket open again; I personnaly would be in 
favor of an automatic change of PATH by the installer.


Martin said he would discuss a patch when there is a patch to discuss.
He feels strongly about there being a clean uninstall, including PATH 
restoration if it is changed.


The problem is that a) the Window's way to run user apps is via icons 
and menus and that b) the old DOS path/command way, based on Unix, has 
been neglected.


An alternative to manipulating PATH would be to make and add to the 
Start Menu a Command Prompt shortcut, call it Command Window or 
something, that starts in the Python directory.  Then one could enter 
>python or >Scripts/goforit without chdir-ing to the Python directory 
first.  The background could even be set to green, for instance, to 
differentiate it from the standard Command Prompt window.


Terry Jan Reedy

___
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] 2.6b3 Windows installers

[Benjamin Peterson]

On Tue, Sep 2, 2008 at 7:24 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sep 2, 2008, at 8:09 AM, M.-A. Lemburg wrote:
>
>> I suppose this is due to Martin building the installers and him not
>> be available at the moment.
>
> He should be back today.
>
>> Since Python on Windows will likely only get very few beta testers
>> without a Windows installer build, I'd suggest to postpone the
>> RC1 release that's planned for tomorrow to get more feedback for the
>> Windows builds.
>
> I'd rather still release the rc tomorrow.

Even with 41 release blockers, are you still planning a release tomorrow?

I guess there's nothing wrong with that; the more testing the better!
2.6 and 3.0 are also pretty stable; we're just ironing out a few of
the rough spots. :)



-- 
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] 2.6b3 Windows installers

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 2, 2008, at 5:58 PM, Benjamin Peterson wrote:


On Tue, Sep 2, 2008 at 7:24 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 2, 2008, at 8:09 AM, M.-A. Lemburg wrote:


I suppose this is due to Martin building the installers and him not
be available at the moment.


He should be back today.


Since Python on Windows will likely only get very few beta testers
without a Windows installer build, I'd suggest to postpone the
RC1 release that's planned for tomorrow to get more feedback for the
Windows builds.


I'd rather still release the rc tomorrow.


Even with 41 release blockers, are you still planning a release  
tomorrow?


I guess there's nothing wrong with that; the more testing the better!
2.6 and 3.0 are also pretty stable; we're just ironing out a few of
the rough spots. :)


I hope to start going through the blockers tonight.  We'll see!

- -Barry

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

iQCVAwUBSL24SHEjvBPtnXfVAQLQ0wP8D3zjs97No9dnR8WgOV/4IJHGQ4FK0e7k
XadqGmdEy0uLlpfjxCuBjWhdq5q1n/NPuJtX/wVtf0CQZtadb8gFde88+KyPkwYk
T8eAwz7OFv+kmclj2tnGh1Raps+0ocBrG5BWJG3D85ofGIZL4NZTLkDr9b6LDONA
lr85NvbpqMg=
=bj/j
-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] Add python.exe to PATH environment variable

[Antoine Pitrou]

Terry Reedy  udel.edu> writes:
> 
> An alternative to manipulating PATH would be to make and add to the 
> Start Menu a Command Prompt shortcut, call it Command Window or 
> something, that starts in the Python directory.

The reason for adding the directory to the PATH is for it to be recognized in
any command prompt, not only the Python-dedicated command prompt shortcut. 

Otherwise, the minute another project decides to do the same thing (provide a
custom command prompt shortcut rather than add its own directory to the PATH),
the user experience becomes very tedious.


___
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-02 23:14, Terry Reedy wrote:
> Tarek Ziadé wrote:
> 
>> So I don't see any good reason (besides the technical complexity)
> 
> Unless and until someone is able and willing to deal with the technical
> complexity, that would seem to be a sufficient reason.
> 
>>  to [not, I presume] add  it to the Windows installer.
> 
>> So I would love to see this ticket open again; I personnaly would be
>> in favor of an automatic change of PATH by the installer.
> 
> Martin said he would discuss a patch when there is a patch to discuss.
> He feels strongly about there being a clean uninstall, including PATH
> restoration if it is changed.
> 
> The problem is that a) the Window's way to run user apps is via icons
> and menus and that b) the old DOS path/command way, based on Unix, has
> been neglected.
> 
> An alternative to manipulating PATH would be to make and add to the
> Start Menu a Command Prompt shortcut, call it Command Window or
> something, that starts in the Python directory.  Then one could enter
>>python or >Scripts/goforit without chdir-ing to the Python directory
> first.  The background could even be set to green, for instance, to
> differentiate it from the standard Command Prompt window.

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

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.

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.

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

[Greg Ewing]

Tony Nelson wrote:


I suppose the question is what a capitalized name promises.  If it means
only "Class", then how should "Returns a new object", either from a Class
or a Factory, be shown?


Is there really a strong need to show that? There are
many ways in which functions could be categorized.
Is this particular one so important that it warrants
a naming convention?

--
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

[Mark Hammond]

> > An alternative to manipulating PATH would be to make and add to the
> > Start Menu a Command Prompt shortcut, call it Command Window or
> > something, that starts in the Python directory.
> 
> The reason for adding the directory to the PATH is for it to be
> recognized in any command prompt, not only the Python-dedicated 
> command prompt shortcut.

Actually, that is *your* reason for adding it to the global path.  But
adding it to the global path has many more side-effects than just allowing
'python' to work at the command-prompt - every running program of yours,
even those not related to command-prompts or Python, has the opportunity to
get confused about the files that might appear in those directories.

> Otherwise, the minute another project decides to do the same thing
> (provide a
> custom command prompt shortcut rather than add its own directory to the
> PATH), the user experience becomes very tedious.

The problem is that if every installer offers to update the path, it gets
quite tedious making corrections and tweaks (eg, I'm never offered the
option of *where* on the path to install it, and sometimes this is very
important!)

FWIW, my opinion is similar to how I read Martin's - that if a suitable,
safe patch that cleanly uninstalls can be found, it should be included, but
disabled by default.  Personally I'd never use it.

Cheers,

Mark

___
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:
> > 
> > The reason for adding the directory to the PATH is for it to be
> > recognized in any command prompt, not only the Python-dedicated 
> > command prompt shortcut.
> 
> Actually, that is *your* reason for adding it to the global path.

What do you mean? Are there other practical reasons than the above for adding
the directory to the PATH?

>  But
> adding it to the global path has many more side-effects than just allowing
> 'python' to work at the command-prompt - every running program of yours,
> even those not related to command-prompts or Python, has the opportunity to
> get confused about the files that might appear in those directories.

What do you mean by "get confused about the files that might appear in those
directories"?
Unless those running programs of mine deliberately crawl through the PATH (in
which case I assume they have a good reason of doing so), I don't understand in
what way they would "get confused". But I admit I'm not an expert Windows user.

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

[Greg Ewing]

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).

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

[Greg Ewing]

Jesus Cea wrote:


How do you differenciate between that empty string (when doing
"read(0)"), from EOF (that is signaled by an empty string)?.


If you need to be able to make that distinction, then
you have to be careful not to try to read 0 bytes.

Personally I've never come across a situation where
allowing read(0) to occur would have simplified the
code. In the usual keep-reading-until-we've-got-the-
required-number-of-bytes scenario, you're checking
for 0 bytes left to read in order to tell when to
stop.

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

[Greg Ewing]

Jesus Cea wrote:


My point is: we are simplifying the program considering "0" a valid len
counter, but we complicates it because now the code can't consider "" =
EOF if it actually asked for 0 bytes.


What are you suggesting read(0) *should* do, then?
If it returns None or some other special value, or
raises an exception, then you need a special case
to handle that. So you've just substituted one special
case for another.

> Isaac Morland 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.

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

Terry Reedy wrote:

An alternative to manipulating PATH would be to make and add to the 
Start Menu a Command Prompt shortcut, call it Command Window or 
something, that starts in the Python directory.


That doesn't seem very satisfactory, because the user
is going to want to work in the directory containing
his script, or the data he wants to run the script on.

A better way would be to start a command process with
the Python directory added to PATH just for that
process.

How easy would that be to do on Windows? Do environment
variables get inherited by child processes the way
they do on Unix?

--
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

[Terry Reedy]

M.-A. Lemburg wrote:

On 2008-09-02 23:14, Terry Reedy wrote:



An alternative to manipulating PATH would be to make and add to the
Start Menu a Command Prompt shortcut, call it Command Window or
something, that starts in the Python directory.  Then one could enter

python or >Scripts/goforit without chdir-ing to the Python directory

first.  The background could even be set to green, for instance, to
differentiate it from the standard Command Prompt window.


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


I do and will*, but some people want to start a command window and then 
type 'python' just like they would on *nix (*without having to 
explicitly change to the Python directory*), or be able to run stuff in 
a subdirectory of the Python directory.  So I suggested an alternative 
to the request for PATH manipulation that could easily be done now.


* I recently *did* run Python from a command prompt so I could make sure 
it was running 'cmd.exe /u' and try changing the code page (but this is 
another story), but I simply moved to the directory first.  For me, not 
a big deal.


tjr

___
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:


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.

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.


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.

--
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

[Mark Hammond]

> Mark Hammond  skippinet.com.au> writes:
> > >
> > > The reason for adding the directory to the PATH is for it to be
> > > recognized in any command prompt, not only the Python-dedicated
> > > command prompt shortcut.
> >
> > Actually, that is *your* reason for adding it to the global path.
> 
> What do you mean? Are there other practical reasons than the above for
> adding the directory to the PATH?

My point was that it applies to much more than command-prompts.  There are
pratical reasons for adding entries to your global PATH that don't include
the ability to run executables at the command-line.

> What do you mean by "get confused about the files that might appear in
> those directories"?

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.

I don't need any program *except* a command-prompt to be able to locate a
'python.exe', so I arrange for only command-prompts to have their PATH setup
that way.  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.

Cheers,

Mark

___
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

[Curt Hagenlocher]

One of these days, I'm actually going to remember that I need to click
"Reply All" when posting to this list... .  Sorry for the duplicate,
Greg.

On Tue, Sep 2, 2008 at 6:45 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> A better way would be to start a command process with
> the Python directory added to PATH just for that
> process.

This is similar to what Visual Studio or the Windows SDK do to give
you a command prompt with the PATH and other environmental variables
setup "correctly" -- they add a shortcut to a batch file that's set to
keep the command prompt open after the batch file runs.

> How easy would that be to do on Windows? Do environment
> variables get inherited by child processes the way
> they do on Unix?

Generally, yes.  I think there's a catch in that there are ways to
start processes that don't make them children of your process, but I
don't remember why I think that.

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.

--
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/archive%40mail-archive.com