Antoine Pitrou a écrit :
What is the difference between file handle and a regular C file descriptor?
Is it some Windows-specific thing?
If so, then perhaps it deserves some Windows-specific attribute (handle?).
At the moment it's windows-specific, but it's not impossible that some
other
On Fri, Feb 5, 2010 at 10:28 PM, Antoine Pitrou solip...@pitrou.net wrote:
Pascal Chambon pythoniks at gmail.com writes:
By the way, I'm having trouble with the name attribute of raw files,
which can be string or integer (confusing), ambiguous if containing a
relative path, and which isn't
On behalf of the Python development team, I'm cheerful to announce the third
alpha release of Python 2.7.
Python 2.7 is scheduled (by Guido and Python-dev) to be the last major version
in the 2.x series. Though more major releases have not been absolutely ruled
out, it's likely that the 2.7
On Feb 03, 2010, at 01:17 PM, Guido van Rossum wrote:
Can you clarify? In Python 3, __file__ always points to the source.
Clearly that is the way of the future. For 99.99% of uses of __file__,
if it suddenly never pointed to a .pyc file any more (even if one
existed) that would be just fine. So
On Feb 05, 2010, at 07:37 PM, Nick Coghlan wrote:
Brett Cannon wrote:
Does code exist out there where people are constructing bytecode from
multiple files for a single module?
I'm quite prepared to call YAGNI on that idea and just return a 2-tuple
of source filename and compiled filename.
Me
On Feb 03, 2010, at 11:59 AM, M.-A. Lemburg wrote:
How about using an optionally relative cache dir setting to let
the user decide ?
Why do we need that level of flexibility?
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing
On Feb 03, 2010, at 11:07 PM, Nick Coghlan wrote:
It's also the case that having to run Python to manage my own filesystem
would very annoying. If a dev has a broken .pyc that prevents the
affected Python build from even starting how are they meant to use the
nonfunctioning interpreter to find
On Feb 03, 2010, at 09:26 AM, Floris Bruynooghe wrote:
On Wed, Feb 03, 2010 at 06:14:44PM +1100, Ben Finney wrote:
I don't understand the distinction you're making between those two
options. Can you explain what you mean by each of “siblings” and
“folder-per-folder”?
sibilings: the original
In #7712 I was trying to change regrtest to always run the tests in a
temporary CWD (e.g. /tmp/@test_1234_cwd/).
The patches attached to the issue add a context manager that changes the
CWD, and it works fine when I run ./python -m test.regrtest from trunk/.
However, when I try from trunk/Lib/
On 08:21 pm, ba...@python.org wrote:
On Feb 03, 2010, at 01:17 PM, Guido van Rossum wrote:
Can you clarify? In Python 3, __file__ always points to the source.
Clearly that is the way of the future. For 99.99% of uses of __file__,
if it suddenly never pointed to a .pyc file any more (even if one
Pascal Chambon chambon.pascal at gmail.com writes:
The problem is, doing that forwarding is quite complicated.
Hmm, why is it complicated? I agree it can be tedious (especially in C), but it
doesn't seem complicated in itself.
My own FileIO class alas needs locking, because for example, on
On Wed, Feb 3, 2010 at 05:57, Nick Coghlan ncogh...@gmail.com wrote:
Mark Dickinson wrote:
Agreed on all points. Would it be terrible to simply add all relevant
tags the moment a PEP is accepted? E.g., if a PEP pronounces some
particular behaviour deprecated in Python 3.3 and removed in
Am 25.11.2009 11:32, schrieb Vinay Sajip:
Georg Brandl g.brandl at gmx.net writes:
Making the loggerClass configurable per manager would solve the
problem for me, and AFAICS since most applications don't use
different managers anyway, there should not be any detrimental
effects. What do
On Sat, Feb 6, 2010 at 12:21 PM, Barry Warsaw ba...@python.org wrote:
On Feb 03, 2010, at 01:17 PM, Guido van Rossum wrote:
Can you clarify? In Python 3, __file__ always points to the source.
Clearly that is the way of the future. For 99.99% of uses of __file__,
if it suddenly never pointed to a
On Sat, Feb 6, 2010 at 12:49 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
In #7712 I was trying to change regrtest to always run the tests in a
temporary CWD (e.g. /tmp/@test_1234_cwd/).
The patches attached to the issue add a context manager that changes the
CWD, and it works fine when I
On Jan 31, 2010, at 11:04 AM, Raymond Hettinger wrote:
It does this by
allowing many different byte compilation files (.pyc files) to be
co-located with the Python source file (.py file).
It would be nice if all the compilation files could be tucked
into one single zipfile per directory to
On 10:29 pm, gu...@python.org wrote:
On Sat, Feb 6, 2010 at 12:49 PM, Ezio Melotti ezio.melo...@gmail.com
wrote:
In #7712 I was trying to change regrtest to always run the tests in a
temporary CWD (e.g. /tmp/@test_1234_cwd/).
The patches attached to the issue add a context manager that changes
On Feb 01, 2010, at 02:04 PM, Paul Du Bois wrote:
It's an interesting challenge to write the file in such a way that
it's safe for a reader and writer to co-exist. Like Brett, I
considered an append-only scheme, but one needs to handle the case
where the bytecode for a particular magic number
On Feb 01, 2010, at 11:28 PM, Martin v. Löwis wrote:
So what would you do for concurrent writers, then? The current
implementation relies on creat(O_EXCL) to be atomic, so a second
writer would just fail. This is but the only IO operation that is
guaranteed to be atomic (along with mkdir(2)), so
On Sat, Feb 6, 2010 at 3:22 PM, exar...@twistedmatrix.com wrote:
On 10:29 pm, gu...@python.org wrote:
On Sat, Feb 6, 2010 at 12:49 PM, Ezio Melotti ezio.melo...@gmail.com
wrote:
In #7712 I was trying to change regrtest to always run the tests in a
temporary CWD (e.g. /tmp/@test_1234_cwd/).
On Sat, Feb 6, 2010 at 3:28 PM, Barry Warsaw ba...@python.org wrote:
On Feb 01, 2010, at 02:04 PM, Paul Du Bois wrote:
It's an interesting challenge to write the file in such a way that
it's safe for a reader and writer to co-exist. Like Brett, I
considered an append-only scheme, but one needs
Guido van Rossum wrote:
What we do instead, is code in site.py that walks over the elements of
sys.path and turns them into absolute paths. However this code runs
before '' is inserted in the front of sys.path, so that the initial
value of sys.path is ''.
You may want to print the value of
Hello,
I would like to propose a small change in the getpass module so it's
able to get passwords from keyrings (like KWallet, Keychain, etc)
The idea is to provide a getpass.cfg configuration file where people
can provide the name of a function to use when getpass is called.
Then third-party
On Sat, Feb 6, 2010 at 4:04 PM, Christian Heimes li...@cheimes.de wrote:
Guido van Rossum wrote:
What we do instead, is code in site.py that walks over the elements of
sys.path and turns them into absolute paths. However this code runs
before '' is inserted in the front of sys.path, so that
Barry Warsaw ba...@python.org writes:
On Feb 03, 2010, at 11:07 PM, Nick Coghlan wrote:
It's also the case that having to run Python to manage my own
filesystem would very annoying.
[…]
Files that are problematic wouldn't need Python to manage any more than
currently. The suggestion was just
Guido van Rossum schrieb:
Are you sure you remember this right? The code.co_filename
attributes will be unmarshalled straight from the bytecode file which
indeed will have the relative path in this case (hopefully we'll
finally fix this in 3.2 and 2.7). But if I read the code in import.c
On Sat, Feb 6, 2010 at 4:27 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Barry Warsaw ba...@python.org writes:
I agree. I'd prefer to have a predictable place for the cached files,
independent of having to run Python to tell you where that is.
Right; I don't see who would disagree with
On Sat, Feb 6, 2010 at 4:36 PM, Christian Heimes li...@cheimes.de wrote:
Guido van Rossum schrieb:
Are you sure you remember this right? The code.co_filename
attributes will be unmarshalled straight from the bytecode file which
indeed will have the relative path in this case (hopefully we'll
Ben Finney wrote:
Right; I don't see who would disagree with that. I don't see any
conflict between “decouple compiled bytecode file locations from source
file locations” versus “predictable location for the compiled bytecode
files”.
The more decoupled they are, the harder it is to manually
On Sat, Feb 6, 2010 at 5:10 PM, Nick Coghlan ncogh...@gmail.com wrote:
Ben Finney wrote:
Right; I don't see who would disagree with that. I don't see any
conflict between “decouple compiled bytecode file locations from source
file locations” versus “predictable location for the compiled
Nick Coghlan ncogh...@gmail.com writes:
The more decoupled they are, the harder it is to manually find the
bytecode file.
Okay. So it's not so much about “predictable”, but rather about
“predictable by a human without too much cognitive effort”.
I can see value in that, though it's best to be
On 6 Feb, 11:53 pm, gu...@python.org wrote:
On Sat, Feb 6, 2010 at 3:22 PM, exar...@twistedmatrix.com wrote:
On 10:29 pm, gu...@python.org wrote:
[snip]
I haven't tried to repro this particular example, but the reason is
that we don't want to have to call getpwd() on every import nor do we
exar...@twistedmatrix.com wrote:
On 08:21 pm, ba...@python.org wrote:
On Feb 03, 2010, at 01:17 PM, Guido van Rossum wrote:
Can you clarify? In Python 3, __file__ always points to the source.
Clearly that is the way of the future. For 99.99% of uses of __file__,
if it suddenly never pointed
33 matches
Mail list logo
