Antoine Pitrou wrote:
> > or if a user installs by dragging into
> > site-packages instead of using an installer?
>
> Well... do people actually do this?
Why not?
And it is also common to just set the PYTHONPATH environment variable
instead of using setup.py install or copy the files to the
lib/
Nick Coghlan wrote:
Another option is to remove bytecode-only support from the default
filesystem importer, but keep it for zipimport (since the stat call
savings don't apply in the latter case).
+1
Baptiste Carvello wrote:
However, making a difference between zipimport and the filesystem imp
I like the idea of the PEP.
On the other hand, I dislike using directories for it.
Others have explained enough reasons for why creating many
directories is a bad idea; and there may be other reasons
(file-system limits for number of directories, problems when
the directories are located on the ne
From: Stefan Behnel
To: python-dev@python.org
Subject: Re: [Python-Dev] Forking and Multithreading - enemy brothers
Message-ID:
Content-Type: text/plain; charset=ISO-8859-15
Pascal Chambon, 29.01.2010 22:58:
I've just recently realized the huge problems surrounding the mix of
multithreading an
If Python should support BOM when reading text files,
it should also be able to *write* such files.
An encoding="BOM" argument wouldn't help here, because
it does not specify which encoding to use actually:
UFT-8, UTF-16-LE or what?
That would be a point against encoding="BOM" and
pro an additio
mode = "python-dev reader"
Please excuse me if I'm wrong here,
but I think python-dev just isn't the right place to discuss this topic,
because it's about 3rd party packages and it's got nothing to do with
the development *of the python language itself*, but generated a lot of
traffic.
mode =
I totally agree with Matthew.
I don't understand the code at first sight.
The "with ... do ..." syntax breaks the
"Python is executable pseudo-code" pattern.
And according the example given at Tav's web site:
with employees.select do (emp):
if emp.salary > developer.salary:
return fire
One of the things I like about Python is that
* it doesn't actually need an installation. *
It is sufficient to set up PATH (and, if you like, PYTHONPATH)
accordingly to start python. However, you need the DLLs somewhere
in the Python directory, too.
That way it is possible to install Python ap
Please, please, please: Keep the % formatting!
In 99% of the Python code I have seen,
the str.format wouldn't gain any advantage
(not even regarding the code readability).
Yes, there may be special cases where str.format
offers more flexibility, but until now I never missed
anything in the % for
> Martin v. Löwis wrote:
> Exactly. My proposal is still to provide an API to toggle the
> flag after the handle was created.
OK, here is an API that I tested on Windows and for sockets only.
Perhaps someone can test it on Non-Windows (Linux, for example?)
I think the best place for it would be a
Hi,
# I'm not sure about netiquette here:
# I decided to continue posting to the python-list without CCing to
everyone.
First of all, here's the prototype.
It's a prototype and I know it's far from perfect, but it works for me
(in production code) - however, I did not yet test it on Non-Windows.
"""
My very personal opinion:
After a sleepness night, it seems to me that this is not a Python problem
(or any other programming language at all).
It looks more like an OS design problem (on MS Windows as well as
on Linux etc). In an ideal world, when a program asks the OS to start
a child process
Stephen,
thank you for speaking it out loud on python-dev.
And you know better english words like "tremendous"
and "obtuse" (whatever that means:-)
that express what a PITA this really is.
When I said it took me two weeks, that's actually not the truth.
It was even more.
The first problem was wit
> "Martin v. Löwis" wrote:
>> Yes, I have a patch implemented in pure Python.
>>
>> I got the code on my workplace PC (now I am writing from home,
>> that's why I said I'll post the code later).
>>
>> The patch uses os.fdopen ( os.open (..., ...), ...).
>> It translates IOError into OSError then
"""
OT: Argh - my email address is visible in the posting - I am doomed!
"""
- Original Message -
> Martin v. Löwis wrote:
>
> Do you have a patch implementing that feature? I believe
> it's unimplementable in Python 2.x: open() is mapped
> to fopen(), which does not support O_NOINHERIT.
I'd like to propose a new function "open_noinherit"
or maybe even a new mode flag "n" for the builtin "open"
(see footnote for the names).
The new function should work exactly like the builtin "open", with one
difference:
The open file is not inherited to any child processes
(whereas files opened
16 matches
Mail list logo
