On Oct 1, 2009, at 1:47 PM, Scott Dial wrote:
Allow me to be naive for a moment and say,
is this not the point of rc1 but to catch bugs that should not be in
the
final?
Actually, no. The point of an rc is to avoid a brown paper bag
mistake, i.e. something we really fscked up in the relea
On Oct 1, 2009, at 5:48 PM, Sridhar Ratnakumar wrote:
No new significant failures have been found. (Some trivial issues
have been reported in the bug tracker).
Fantastic, thanks. I'll be tagging the final release soon.
-Barry
PGP.sig
Description: This is a digitally signed message part
_
On Oct 2, 2009, at 5:34 AM, Antoine Pitrou wrote:
Steven Bethard gmail.com> writes:
But it's not much of a transition plan. Or are you suggesting:
The question is why we want a transition plan that will bother
everyone with no
tangible benefits for the user.
Forcing a transition to {}-
e see
http://docs.python.org/whatsnew/2.6.html
Please report bugs for any Python version in the Python tracker.
http://bugs.python.org
Enjoy,
-Barry
Barry Warsaw
ba...@python.org
Python 2.6 Release Manager
(on behalf of the entire python-dev team)
PGP.sig
Description: This is a digi
On Oct 3, 2009, at 11:41 AM, Steven Bethard wrote:
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
The basic problem is that many APIs in the standard library and
elsewhere support only %-forma
On Oct 5, 2009, at 8:22 AM, Tarek Ziadé wrote:
I'm not proposing to debate the merits of all of the options here.
However, if a 2.6.4 release is to be pushed out quickly for other
reasons, a one-time window of opportunity would be available and it
would be prudent to at least consider the possi
On Oct 5, 2009, at 10:17 AM, Tarek Ziadé wrote:
If setuptools can be made to work with Python 2.6.3 /and/ earlier
versions
of Python 2.6.x, then it should be patched and an update released.
If not,
then perhaps we should revert the change in a quick Python 2.6.4.
It's technically possible
On Oct 5, 2009, at 10:50 AM, Tarek Ziadé wrote:
If, as I hope, the answer to that is "yes", then I strongly support
releasing a fixed setuptools instead of reverting the change to
Python.
Yes it does.
Excellent, thanks.
The fix makes sure build_ext.get_ext_filename still works as it is
On Oct 5, 2009, at 10:50 AM, Daniel Stutzbach wrote:
On Mon, Oct 5, 2009 at 9:32 AM, Barry Warsaw wrote:
If, as I hope, the answer to that is "yes", then I strongly support
releasing a fixed setuptools instead of reverting the change to
Python.
How do your propose to get the
On Oct 4, 2009, at 4:11 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I also don't think this is a case of anti-TOOWTDI. For most
situations
{}-strings are great (IMO), but in the specific translation domain, I
suspect $-strings are still better.
I agree that keeping string.Template a
On Oct 5, 2009, at 4:41 PM, Nick Coghlan wrote:
Oh, I see what you meant now - you were pointing out that lazy
formatting APIs (such as logging) already don't work properly for
alternative formatting mechanisms (such as string.Template).
Yep.
(Although printing to a String IO doesn't seem ne
Hello everyone.
The source tarballs and Windows installers for Python 2.6.4rc1 are now
available:
http://www.python.org/download/releases/2.6.4/
Please download them, install them, and try to use them with your
projects and environments. Let us know if you encounter any problems
with th
On Oct 7, 2009, at 10:54 AM, Koen van de Sande wrote:
If there is going to be any quick 2.6.4 release, can you consider a
fix to the building of extensions under Windows ( http://bugs.python.org/issue4120
)?
Extensions built without this patch applied will not work if the
MSVC9 runtimes are
On Oct 7, 2009, at 1:26 PM, Scott Dial wrote:
I suspect this release is primarily to quench the problems with
distutils, but..
http://bugs.python.org/issue5949
doesn't seem to have been addressed by you. And this seems like it
would
be another unfortunate loss of an opportunity.
I want us
On Oct 7, 2009, at 3:46 PM, Brett Cannon wrote:
On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren
wrote:
On 7 Oct, 2009, at 20:53, Brett Cannon wrote:
I just tried building out of svn and a ton of tests that rely on
urllib failed because the _scproxy module wasn't built and it
unconditio
On Oct 8, 2009, at 4:31 AM, Tarek Ziadé wrote:
- no more namespaced packages system, if PEP 381 (namespaces package
support) makes it to 2.7
Make that PEP 382:
http://www.python.org/dev/peps/pep-0382/
-Barry
PGP.sig
Description: This is a digitally signed message part
On Oct 8, 2009, at 8:45 AM, Zvezdan Petkovic wrote:
On Oct 7, 2009, at 2:09 PM, Barry Warsaw wrote:
I want us to be very careful about 2.6.4. This isn't a normal bug
fix release, it's specifically there to remove the brown paper bag
of 2.6.3 from our heads. So let's be c
Are we on track to release 2.6.4 final this Sunday or do we need
another rc?
Yesterday, Tarek committed another setuptools related fix and said
that he was going to run a bunch of build tests locally. Tarek, how
did that go?
Please note that issue 7064 is still open as a release blocker.
On Oct 13, 2009, at 8:31 AM, Zvezdan Petkovic wrote:
Excellent. That's exactly what I meant.
I quoted the part of the previous message where you proposed to
review another patch for 2.6.5. I guess it was not very clear that
I'm proposing to review this for 2.6.5 as well. Well, at least
On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote:
Then I'd suggest to wait another week with 2.6.4 to give you a
chance to look at the patch.
That's not a good option, IMO. We have a known broken 2.6.3 out there
and we owe it to our users to correct our mistake and given them the
release
On Oct 13, 2009, at 11:16 AM, Tarek Ziadé wrote:
I still need to do some more tests, I didn't have time to try the
various projects under win32.
It's planned to night.
The tests are consisting of compiling and insatling a dozain of
projects on linux and win32 (and bith when possible)
Great th
On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote:
Would it be reasonable to shorten that period, if the fix for the
mentioned problem gets ready for prime time earlier ?
I think there are many 2.6.x bugs queued up for after 2.6.4 is
released. I'm not at all opposed to setting a date approxi
On Oct 13, 2009, at 1:41 PM, R. David Murray wrote:
I always thought that the idea of a release candidate was that if
there
were any fixes _at all_ that there would be a new rc. Only when no
bugs needing fixed are found does the rc turn into the actual release.
But I understand that this is a
On Oct 13, 2009, at 2:00 PM, Guido van Rossum wrote:
Traceback (most recent call last):
File "umbrella_rules.py", line 6, in
UmbrellaRule()
File "unbrella_rules.py", line 4, in UmbrellaRule
raise
DuplicateRuleName('http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules
On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote:
I always thought that the idea of a release candidate was that if
there
were any fixes _at all_ that there would be a new rc. Only when no
bugs needing fixed are found does the rc turn into the actual
release.
This was also my understand
On Oct 13, 2009, at 10:15 PM, Martin v. Löwis wrote:
So, we can either make Sunday's release rc2 and do the final
release one
week later, or I can try to get an rc2 out in the next day or two,
with
a final release mid-next week.
Thoughts?
I won't be able to produce Windows binaries until
On Oct 14, 2009, at 8:06 AM, Martin v. Löwis wrote:
That seems to argue for doing rc2 on Sunday the 18th. If I tag the
release some time Saturday, you could have the binaries by Sunday
right?
Correct.
Cool. I've updated the Python Release Schedule calendar to reflect
the new dates.
-Ba
On Oct 15, 2009, at 9:05 AM, Jesse Noller wrote:
Here's another one barry:
http://bugs.python.org/issue7120
We should get this in - it's a regression I introduced awhile ago for
environments without the multiprocessing module using logging.
Was this a regression in 2.6.2 or 2.6.3? I think i
On Oct 15, 2009, at 10:00 AM, Jesse Noller wrote:
On Thu, Oct 15, 2009 at 9:40 AM, Barry Warsaw
wrote:
On Oct 15, 2009, at 9:05 AM, Jesse Noller wrote:
Here's another one barry:
http://bugs.python.org/issue7120
We should get this in - it's a regression I introduced awhile
Hello everyone.
The source tarballs and Windows installers for Python 2.6.4rc2 are now
available:
http://www.python.org/download/releases/2.6.4/
Please download them, install them, and try to use them with your
projects and environments. Let's make 2.6.4 a rock solid release! If
there
On Oct 19, 2009, at 3:59 AM, Vinay Sajip wrote:
Barry Warsaw python.org> writes:
http://www.python.org/download/releases/2.6.4/
Good news, but just one little nit: the page above appears to link
to the NEWS
file for 2.6.4rc1.
Ooops! Fixed, thanks.
-Barry
PGP.sig
Description: T
On Oct 19, 2009, at 11:10 PM, Lisandro Dalcin wrote:
I'm getting this warning. It seems nothing is actually broken, but the
fix is pretty easy.
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-IInclude -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o
Objects/unico
On Oct 21, 2009, at 7:00 PM, Zooko O'Whielacronx wrote:
Do you know anything about this alleged regression in 2.6.3 with
regard to the __doc__ property?
https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
This is the first I've heard of it, but my guess is that it's caused
I'd like to get a second opinion on bug 7183:
http://bugs.python.org/issue7183
The Boost folks have reported this as a regression in 2.6.3, making it
a candidate for Python 2.6.4. IIUC, the latest version of Boost fixes
the problem in their code, but if it really is a regression it could
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw :
So does anybody else think bug 7183 should be a release blocker for
2.6.4
final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code
snippet
On Oct 22, 2009, at 1:16 PM, Tres Seaver wrote:
That being said, I can't this bug as a release blocker: people can
either upgrade to super-current Boost, or stick with 2.6.2 until
they can.
Agreed. I've knocked it down from release-blocker.
-Barryu
PGP.sig
Description: This is a digita
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote:
...
That being said, I can't this bug as a release blocker: people can
either upgrade to super-current Boost, or stick with 2.6.2 until
they can.
Thats the challenge Ubuntu faces:
https
While I think there is some risk of exposure on this bug, I haven't
yet heard a compelling argument for delaying 2.6.4 final for it. I
think we should go ahead and do the release this Sunday as planned
with the code from 2.6.4rc2.
If you strongly disagree, please private email me. Otherwi
on Python 2.6 in general, please see
http://docs.python.org/whatsnew/2.6.html
Please report bugs for any Python version in the Python tracker.
http://bugs.python.org
Enjoy,
-Barry
Barry Warsaw
ba...@python.org
Python 2.6 Release Manager
(on behalf of the entire python-dev team)
On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
A better language, i.e. Python 3.x, will become better faster
without dragging the 2.x series out any longer.
If Python 2.7 becomes the last of the 2.x series, then I personally
favor back porting as many features from Python 3 as poss
On Nov 3, 2009, at 1:07 AM, Martin v. Löwis wrote:
Barry Warsaw wrote:
On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
A better language, i.e. Python 3.x, will become better faster
without
dragging the 2.x series out any longer.
If Python 2.7 becomes the last of the 2.x series
On Nov 2, 2009, at 11:51 PM, sstein...@gmail.com wrote:
I agree as long as:
A> 2.7 comes out as soon as possible, even if it's missing helpful
porting features.
B> 2.7 will get ONLY new features that make it easier to port to
3.x, not every feature added to 3.x or all you've done is make
On Nov 3, 2009, at 10:54 AM, Guido van Rossum wrote:
Ouch. sets. I'm guessing you are referring to code that was still
using the pre-2.4 sets.py module? Yes, that must have been painful.
Indeed. :) What's nice though is that these changes could be made for
the Python 2.5 branch and didn't h
On Nov 3, 2009, at 12:35 PM, Guido van Rossum wrote:
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected, in fact) but I'm brac
On Nov 8, 2009, at 12:56 PM, Martin v. Löwis wrote:
Also, for Python 2.5 and earlier, any SSL-based code is vulnerable
to a MitM
anyway, so this can only be an issue for code using the new APIs
in Python
2.6.
That's not going to stop the
wannabe-self-proclaimed-so-called-vulnerability-"exp
On Nov 10, 2009, at 8:28 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I don't think it's worth making a quick 2.6.5 release for this if
it's
primary intent is to produce new Windows binaries. I'm okay with
making
the changes to the tree, but we'll release 2.6.5
On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote:
Frankly, I agree with him. As implemented, I *and others* think this
is broken. I've taken the stance of not publishing things to PyPi
until A> I find the time to contribute to make it better or B> It
changes.
That's distressing. For better or
On Nov 17, 2009, at 4:55 PM, Georg Brandl wrote:
Benjamin Peterson schrieb:
After more thought, I think that separating the 2.7 and 3.2 releases
is not as big of an issue as I once thought. Therefore, I'd like to
adopt the schedule I posted a few weeks back for 2.7 only.
This only means some o
On Jan 10, 2010, at 6:07 PM, Martin v. Löwis wrote:
> As for decisions: I don't think there was an official BDFL pronouncent,
> but I recall Guido posting a message close to that, proposing that 2.7
> will be a release that will see bug fix releases for an indefinite
> period of time (where indefi
On Jan 11, 2010, at 10:42 PM, Martin v. Löwis wrote:
>Wrt. the distribute feature you've noticed: Python 3.0 already supports
>that in distutils. So from day one of Python 3.x, you could have used
>that approach for porting Python code. I had been promoting it ever
>since, but it's taking up only
On Jan 11, 2010, at 02:55 PM, Guido van Rossum wrote:
>PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
>helpful. But I trust he has ported a lot more code to 3.x than I have
>personally. Are there other experiences?
I've only done one small library so far, but it was helpful t
On Jan 11, 2010, at 10:53 PM, Jack Diederich wrote:
>3) 100% of the module level assignments in public projects were the
>"__metaclass__ = type" variety which is why there isn't a fixer for
>that. Also, a fixer would have been really, really ugly (munge every
>class definition in this module beca
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
>Actually there's a solution to this one too:
>
>FooBase = Meta('FooBase', (), {})
>class Foo(FooBase):
>...
>
>That should work in Python 2.X and 3.X.
Ugly, but good call! :)
>I've got argparse running on Python 2.3-3.1, and th
On Jan 17, 2010, at 4:21 AM, Martin v. Löwis wrote:
> Barry was once proposing time-based releases; this idea didn't really
> catch on.
I'm still a proponent of this, but it doesn't seem like there's enough support
for it.
> It's the release manager who decides when the next bug fix release wil
I've just updated the Launchpad mirrors for the 4 active Python branches,
trunk, py3k, 2.6, and 3.1. These used to mirror the defunct Bazaar branches
on code.python.org but it's probably been 7 months or so since those were
regularly updated. Now the Launchpad branches sync against the read-only
On Jan 19, 2010, at 03:50 PM, Vinay Sajip wrote:
>When I look at the mailing list archive for python-dev, I see some odd stuff at
>the bottom of the page:
>
>http://mail.python.org/pipermail/python-dev/2010-January/thread.html#95232
>
>Anyone know what's happened?
WTF? I think the archives were
On Jan 19, 2010, at 11:24 AM, James Y Knight wrote:
>No doubt, you've now broken every link anyone had ever made into the
>python-dev archives, because now all the article numbers are
>different. BTDT...unfortunately... Pipermail really is quite crappy,
>sigh.
I've been trying for 10+ years
On Jan 20, 2010, at 10:16 AM, David Lyon wrote:
>Hi Barry,
>
>That looks very interesting...
Hi David,
>So does that mean we could update the stdlib for a given
>python version using this ?
In a sense, yes (if I understand your question correctly).
You can use Bazaar to branch any of the 4 Pyt
On Jan 19, 2010, at 08:09 PM, Jesse Noller wrote:
>The decision to move python's source control from SVN to mercurial was
>controversial enough; including 3 or more scm libraries into core
>would be an intractable uphill mountain of bike sheds.
I'd be surprised if any of the big 3 DVCS developers
On Jan 20, 2010, at 02:43 PM, David Lyon wrote:
>> On Tue, Jan 19, 2010 at 7:51 PM, Jesse Noller wrote:
>> A SCM is not a "package management system".
>
>Exactly. It almost makes the need for a "package management system"
>pretty much obsolete if you can update your code directly from
>the develo
Okay, last follow up on this and then I'm going to bed. :)
On Jan 20, 2010, at 03:29 PM, David Lyon wrote:
>> On Jan 19, 2010, at 08:09 PM, Barry Warsaw wrote:
>>
>> I'd be surprised if any of the big 3 DVCS developers would actually /want/
>> their stuff in t
On Jan 20, 2010, at 11:05 PM, Jack Diederich wrote:
>Does disabling the LLVM change binary compatibility between modules
>targeted at the same version? At tonight's Boston PIG we had some
>binary package maintainers but most people (including myself) only
>cared about source compatibility.I a
On Jan 20, 2010, at 10:09 PM, Benjamin Peterson wrote:
>> Does disabling the LLVM change binary compatibility between modules
>> targeted at the same version? At tonight's Boston PIG we had some
>> binary package maintainers but most people (including myself) only
>> cared about source compatibil
On Jan 21, 2010, at 12:42 PM, Collin Winter wrote:
Hi Collin,
>I don't believe that introducing the Unladen Swallow JIT will make
>maintaining a stable ABI per PEP 384 more difficult. We've been careful about
>not exporting any C++ symbols via PyAPI_FUNC(), so I don't believe that will
>be an iss
On Jan 21, 2010, at 02:46 PM, Jeffrey Yasskin wrote:
>LLVM's under the University of Illinois/NCSA license, which is
>BSD-like: http://www.opensource.org/licenses/UoI-NCSA.php or
>http://llvm.org/releases/2.6/LICENSE.TXT.
Cool. This is a GPL compatible license, so it would presumably not change
On Jan 21, 2010, at 04:07 PM, Jeffrey Yasskin wrote:
>I could imagine a problem if Python+LLVM link in one libstdc++, and an
>extension module links in a different one, even if no C++ objects are
>passed across the boundary. Does that cause problems in practice? We'd
>have the same problems as fro
On Jan 22, 2010, at 10:06 AM, Chris McDonough wrote:
>Can you tell us where Uncle Timmy has been and when he'll be back?
He's given up bags of ham for walls of chocolate.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Pyt
On Jan 28, 2010, at 8:33 AM, Benjamin Schweizer wrote:
> I've updated the traceback.py module; my improved version dumps all
> local variabes from the stack trace, which helps in debugging rare
> problems. You can find details in my latest blog post here:
>
> http://benjamin-schweizer.de/improve
PEP: 3147
Title: PYC Repository Directories
Version: $Revision$
Last-Modified: $Date$
Author: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2009-12-16
Python-Version: 3.2
Post-History:
Abstract
This PEP describes an extension to Python's i
I'm thinking about doing a Python 2.6.5 release soon. I've added the
following dates to the Python release schedule Google calendar:
2009-03-01 Python 2.6.5 rc 1
2009-03-15 Python 2.6.5 final
This allows us to spend some time on 2.6.5 at Pycon if we want. Please let me
know if you have any conc
I have to say up front that I'm somewhat shocked at how quickly this thread
has exploded! Since I'm sprinting this week, I haven't thoroughly read every
message and won't have time tonight to answer every question, but I'll try to
pick out some common ideas. I really appreciate everyone's input a
On Jan 30, 2010, at 11:21 PM, Vitor Bosshard wrote:
>Why not:
>
>foo.py
>foo.pyc # < 2.7 or < 3.2
>foo.27.pyc
>foo.32.pyc
>etc.
Because this clutters the module's directory more than it does today, which I
considered to be a negative factor. And as others have pointed out, there
isn't a one-to-o
On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote:
>We deliberate don't document -U because its typical effect is "break the
>world" - it makes all strings unicode in 2.x.
As an aside, I think this should be documented *somewhere* other than just in
import.c! I'd totally forgotten about it until
On Jan 31, 2010, at 03:07 PM, Ben Finney wrote:
>In other words, my understanding is that the current PEP would have the
>following tree for an example project::
>
>foo/
>__init__.py
>__init__.pyr/
>deadbeef.pyc
>decafbad.pyc
>lorem.py
>l
On Jan 31, 2010, at 12:36 PM, Georg Brandl wrote:
>Not really -- much of the code I've seen that tries to guess the source
>file name from a __file__ value just does something like this:
>
> if fname.lower().endswith(('.pyc', '.pyo')): fname = fname[:-1]
>
>That's not compatible with using .pyr,
On Jan 31, 2010, at 09:30 PM, Martin v. Löwis wrote:
>If a single pyc folder is used, I think an additional __source__
>attribute would be needed to indicate what source file time stamp had
>been checked (if any) to determine that the byte code file is current.
This is a good point. __file__ is
On Feb 03, 2010, at 11:31 PM, Nick Coghlan wrote:
>Having a lookup dictionary from Python version + C API magic numbers to
>the magic strings used in cache filenames in the import engine shouldn't
>be too tricky. I'll admit it wasn't until the thread had already been
>going for a while that I real
On Feb 03, 2010, at 12:57 PM, Antoine Pitrou wrote:
>How about doing measurements /with the current implementation/? Everyone
>seems to worry about stat() calls but there doesn't seem to be any figures to
>evaluate their significance.
Yes, very good idea, if for no other reason than to give us a
On Feb 03, 2010, at 11:10 PM, Nick Coghlan wrote:
>Ripping it out is probably a reasonable idea given that there is a much
>better approach available now (i.e. trying to run under Py3k) that
>actually has a vague hope of working.
>
>Then again, if 2.7 really is the last non-maintenance 2.x release
On Feb 03, 2010, at 04:21 PM, M.-A. Lemburg wrote:
>exar...@twistedmatrix.com wrote:
>> On 02:52 pm, m...@egenix.com wrote:
>>>
>>> Note that in Python 2.7 you can use
>>>
>>> from __future__ import unicode_literals
>>>
>>> on a per module basis to achieve much the same effect.
>>
>> In P
On Feb 03, 2010, at 09:55 AM, Guido van Rossum wrote:
>On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw wrote:
>> -snip snip-
>> from __future__ import unicode_literals
>>
>> def func(foo, bar):
>> print foo, bar
>>
>> kw = {'
On Feb 03, 2010, at 11:50 PM, Ronald Oussoren wrote:
>> Barry's answer was "yes" back in October.
>
>I will backport the patch if Barry says it's fine. Feel free to ping me if
>that doesn't happen before the end of next week.
I still think this should go in 2.6.5. The patch does not apply to th
On Feb 03, 2010, at 08:52 PM, Martin v. Löwis wrote:
>>> As an aside, I think this should be documented *somewhere* other than
>>> just in import.c! I'd totally forgotten about it until I read the
>>> source and almost missed it. Either it should be documented or it
>>> should be ripped out.
>>
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 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 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 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 or
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 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)),
On Feb 06, 2010, at 02:20 PM, Guido van Rossum wrote:
>> Upon further reflection, I agree. __file__ also points to the source in
>> Python 2.7.
>
>Not in the 2.7 svn repo I have access to. It still points to the .pyc
>file if it was used.
Ah, I was fooled by a missing pyc file. Run it a second
On Feb 04, 2010, at 03:00 PM, Glenn Linderman wrote:
>When a PEP 3147 (if modified by my suggestion) version of Python runs,
>and the directory doesn't exist, and it wants to create a .pyc, it would
>create the directory, and put the .pyc there. Sort of just like how it
>creates .pyc files, no
On Jan 31, 2010, at 01:06 PM, Ron Adam wrote:
>With a single cache directory, we could have an option to force writing
>bytecode to a desired location. That might be useful on it's own for
>creating runtime bytecode only installations for installers.
One important reason for wanting to keep th
On Jan 31, 2010, at 08:10 PM, Silke von Bargen wrote:
>Martin v. Löwis schrieb:
>> There is also the issue of race conditions with multiple simultaneous
>> accesses. The original format for the PEP had race conditions for
>> multiple simultaneous writers; ZIP will also have race conditions for
>>
On Jan 31, 2010, at 11:34 PM, Nick Coghlan wrote:
>I must admit I quite like the __pyr__ directory approach as well. Since
>the interpreter knows the suffix it is looking for, names shouldn't
>conflict. Using a single directory allows the name to be less cryptic,
>too (e.g. __pycache__).
Somethin
On Feb 01, 2010, at 08:26 AM, Tim Delaney wrote:
>The pyc/pyo files are just an optimisation detail, and are essentially
>temporary. Given that, if they were to live in a single directory, to me it
>seems obvious that the default location for that should be in the system
>temporary directory. I an
On Feb 06, 2010, at 04:02 PM, Guido van Rossum wrote:
>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 r
On Feb 06, 2010, at 04:39 PM, Guido van Rossum wrote:
>The conflict is purely that PEP 3147 proposes the new behavior to be
>optional, and adds a flag (-R) and an environment variable
>($PYTHONPYR) to change it. I presume Barry is proposing this out of
>fear that the new behavior might upset someb
On Feb 07, 2010, at 05:59 PM, Michael Foord wrote:
>On 07/02/2010 17:48, Barry Warsaw wrote:
>> [snip...]
>>> And I propose not to disturb this in 2.7, at least not by default. I'm
>>> fine though with a flag or distro-overridable config setting to change
>
1001 - 1100 of 2704 matches
Mail list logo
