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.
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
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/
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
--
Nick Coghlan ncoghlan at 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
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
-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
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
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
On Tue, Sep 2, 2008 at 10:03 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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
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:
-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
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
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)
-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
-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
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
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
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.
-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
Terry Reedy tjreedy at 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
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
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
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
Mark Hammond mhammond at 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
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
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
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,
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
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
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
Mark Hammond mhammond at 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
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
33 matches
Mail list logo
