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 neve
On 6 Feb, 11:53 pm, gu...@python.org wrote:
On Sat, Feb 6, 2010 at 3:22 PM, 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
want to have some kind of
Nick Coghlan 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 explicit that th
On Sat, Feb 6, 2010 at 5:10 PM, Nick Coghlan 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 bytecode
>> files”
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 manuall
On Sat, Feb 6, 2010 at 4:36 PM, Christian Heimes wrote:
> Guido van Rossum schrieb:
>> Are you sure you remember this right? The .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
On Sat, Feb 6, 2010 at 4:27 PM, Ben Finney wrote:
> Barry Warsaw 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 that. I don't see any
> conflict betwe
[redirecting to python-ideas]
On Sat, Feb 6, 2010 at 4:08 PM, Tarek Ziadé wrote:
> 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
Guido van Rossum schrieb:
> Are you sure you remember this right? The .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
> corr
Barry Warsaw 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 that, a su
On Sat, Feb 6, 2010 at 4:04 PM, Christian Heimes 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 the initial
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 pro
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 valu
On Sat, Feb 6, 2010 at 3:28 PM, Barry Warsaw 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 to handle
On Sat, Feb 6, 2010 at 3:22 PM, wrote:
> On 10:29 pm, gu...@python.org wrote:
>>
>> On Sat, Feb 6, 2010 at 12:49 PM, Ezio Melotti
>> 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
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)),
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 10:29 pm, gu...@python.org wrote:
On Sat, Feb 6, 2010 at 12:49 PM, Ezio Melotti
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
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 dire
On Sat, Feb 6, 2010 at 12:49 PM, Ezio Melotti 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 run ./python -m test.
On Sat, Feb 6, 2010 at 12:21 PM, Barry Warsaw 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
Am 25.11.2009 11:32, schrieb Vinay Sajip:
> Georg Brandl 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 you
On Wed, Feb 3, 2010 at 05:57, Nick Coghlan 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 Python
>> 3.4, t
Pascal Chambon 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 windows
> trunc
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
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/ i
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 or
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 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 li
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 filena
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. S
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 relea
On Fri, Feb 5, 2010 at 10:28 PM, Antoine Pitrou wrote:
> Pascal Chambon 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 able to handle the new
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
othe
34 matches
Mail list logo
