n them the
release they should have gotten in the first place.
We don't need to wait too long for 2.6.5 though. A few months would
be appropriate.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing
e)
Great thanks, let us know how it goes. If there's any question at all
about the fixes that have gone in since rc1, we should spin an rc2.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python
date approximately 1
month from now for the first 2.6.5 rc. That should give people plenty
of time to get their top fixes in.
i-like-timed-releases-ly y'rs,
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev ma
an idealized rc/release policy :)
I'll invoke the Umbrella Rule now. If we don't do one we'll wish we
had. If we do, we won't have needed it.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev
umbrella-rule-and-sharing-rules-in-general/')
DuplicateRuleName:
http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules-in-general/
MisinformedMeteorologistRule (probably more PC than stupid weatherman
rule :)
-Barry
PGP.sig
Description: This is a
understanding; that's the point of calling it
"candidate". Since the code base of 2.6.4rc1 was not released as-is,
we would need to consider another candidate.
But then, Barry doesn't like release candidates in the first place.
No, but let's do one anyway!
So, we can either make
ase the final on the 25th.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/
dates.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%4
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
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
there are no more regressions found, we'll do the final release in one
week, on 25-October.
Enjoy,
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
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
will not break
existing code, but
adding const to output parameters may well require code changes for
users of the Python
API.
What is the best approach to this problem that will be acceptable?
Barry
___
Python-Dev mailing list
Python-Dev
#x27;t a regression in 2.6.3, nor is it critical enough, to be
fixed for 2.6.4.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
have output params changed to const to avoid casting.
PyOS_strtoul- ptr
PyLong_FromString - pend
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
t's caused
by the fix for bug 5890.
http://bugs.python.org/issue5890
It's a change in Python 2.6.3, but I don't believe it's a regression
(as in, currently broken).
-Barry
PGP.sig
Description: This is a digitally signed message part
wait of another week for the final.
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?
Thanks,
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Pyt
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
ch to include a comment explaining
why output param is char ** and the need for a cast.
Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
faces:
https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
We've just announced our Karmic RC, boost 1.40 isn't released, and
python 2.6.3 doesn't work with a released boost :(
Aren't we stuck either way though? :(
-Barry
PGP.sig
Description: This is a digi
il me. Otherwise...
there's always 2.6.5! :)
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
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 22 Oct 2009, at 20:31, Barry Scott wrote:
On 21 Oct 2009, at 06:15, Martin v. Löwis wrote:
I suggest following POSIX's lead and omitted the const in these
cases.
Ah... Yes I see this in strstr for example.
Thanks, that sounds reasonable.
This is basically what I have done i
library and
application authors as much help as possible to provide Python 3
compatible software. Putting together Python tools involves so many
dependencies in a fairly deep stack that even one unconverted library
can cause everything above it to stall on Python 2.
-Barry
PGP.s
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
t;Oh, I'm having to convert a lot of things to use
Python 3" doesn't seem to improve their mood much.
I completely agree. What happens when your application depends on a
half dozen Zope packages, Twisted, and 15 or 20 other established,
mature packages? It's a daunting pro
out.
Running with the -3 is a great idea, and something I will definitely
try after finishing the straight 2.6 port.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
htt
back to the 3.1 release, i.e. the "frozen" version of the language is
the state in which it was released as 3.1.
I think this is a great idea. I'd love to see the energy normally put
into evolving the language into making the stdlib real
likely then for both
2.6
and 3.1).
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 a "normal"
schedule.
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
esome
software that the bogus bad reviews will be buried by an avalanche of
kudos.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
some other lucky victi... I mean volunteer can do
3.2. :)
If no one else wants to try and ruin Python 3, I'll do it .
Ha ha ha^H^H^H^H^H^H^H^H^HGreat! Benjamin's the expert now, but I'm
here to help if needed.
-Barry
PGP.sig
Description: This is a digitally
t easy for people to
port their Python 2 code to Python 3, and to support that with one code base,
the quicker we'll get to a predominantly Python 3 world.
So the question we should be asking is: what's missing from Python 2.7 to help
with this transition? If we can't get it
s
are often back ported. Or if not, then who cares? You're not going to use a
newer version of a library on an LTS anyway.
I'm not necessarily saying that justifies a 2.8 release. I'm just asking how
we can make it easier for people to port to Python 3. The automatic 2to3 has
al
but it was helpful to me.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
s definition in this module because there is a top level
>assignment).
And almost certainly unnecessary. IME, those are all to easily make bare
class definitions new style in Python 2.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mail
aven't had the time.
The more resources we can provide people, both in code and in documentation,
the better.
Thanks!
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
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 dec
ranch lp:python/py3k
Bazaar 2.0 or better is recommended. For me, it took about 5m to check the
first branch out from Launchpad, and then about 30s or so for each subsequent
branch.
Enjoy,
-Barry
signature.asc
Description: PGP signature
___
Python-Dev
think the archives were recently regenerated, so there's probably a
fubar there. CC'ing the postmasters.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
archive.org or something).
bin/cleanarch uses a set of heuristics to find unescaped From lines and fix
them. It's generally pretty good, but it certain can change message numbers
(and sadly, their urls).
-Barry
signature.asc
Description: PGP signature
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 bran
y of the big 3 DVCS developers would actually /want/
their stuff in the stdlib. Being in the stdlib has its advantages and
disadvantages. I think for rapidly developing technology, the latter can
actually outweigh the former.
(Besides, git in the stdlib doesn't make much sense :).
>Barry made bz
t will allow you to
"build-from-branch" so that in a sense you could let a build farm take your
Bazaar branches and automatically build the packages from them.
I've strayed off-topic I suppose, but I see SCMs and package managers as
complementary technologies that help with importan
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
27;s a lot of issues
that need to be addressed, and the PEP process is the right way to do that.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
4 be implemented.
Yep, and implementing PEP 384 is on my radar.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
a show-stopper, but it will make things more difficult for
Python users, so we have to add this to the list of implications for including
C++ in Python's core.
>Yes; there is
>http://code.google.com/p/unladen-swallow/source/browse/trunk/Python/llvm_notes.txt,
Excellent. Thanks for the answ
bly not change
Python's status there.
http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
same problems as from having two different C runtimes in the
>same application.
Yes, I think this could cause problems.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
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
enjamin-schweizer.de/improved-python-traceback-module.html
Cool. Does it work with Python 3's chained exceptions?
http://www.python.org/dev/peps/pep-3134/
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
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
u have any concerns about those dates.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/arch
sibling directories or folder-per-folder I think
performance issues should be the deciding factor. There are file system
limitations to consider (but also a wide variety of file systems in use). Do
the number of stat calls predominate the performance costs? Maybe it makes
sense to implement th
is going to be very subjective, but in skimming the thread it
seems like most people like putting the byte code cache artifacts in
subdirectories (be they siblings or folder-per-folder).
-Barry
signature.asc
Description: PGP signature
___
y forgotten about it until I read the source and almost
missed it. Either it should be documented or it should be ripped out.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
e to search up the file system,
and then back down again to find the pyc file to delete. How many ..'s does
it take until you're lost in the twisty maze of ls?
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python
;
>That's not compatible with using .pyr, either.
The rationale for the .pyr extension is because I've usually seen (and
written) this instead:
base, ext = os.path.splitext(fname)
py_file = base + '.py'
# ...or...
if ext != '.py':
continu
ocation of the PVM, JVM, LLVM or
whatever compilation cache artifact file.
I've added a note to my working update of the PEP.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
numbers don't seem quite right, but maybe they are a "good enough"
solution.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
n to give us a baseline for
comparison. Added to the PEP.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
maintenance 2.x release,
>what's to be gained by messing with it?
Well, in case we decide to do it, this bug tracks that effort:
http://bugs.python.org/issue7847
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Pyt
talking about this a
while back but I don't remember what we decided and I can't find a bug on the
issue.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 g
d or it
>>> should be ripped out.
>>
>> The -U option is already gone in 3.x.
>
>Precisely my view.
I took the "or document it" approach.
http://bugs.python.org/file16127/7847.patch
http://bugs.python.org/issue7847
-Barry
signature.asc
Description: PGP signatu
be just fine. So what's this talk of switching to
>__source__?
Upon further reflection, I agree. __file__ also points to the source in
Python 2.7. Do we need an attribute to point to the compiled bytecode file?
-Barry
signature.asc
Descri
source filename and compiled filename.
Me too. I think a 2-tuple of (source-path, compiled-path) is probably going
to be fine for all practical purposes. I'd assign the former to a module's
__file__ (as is done today in Python >= 2.7) and the latter to a module's
__cached__.
-B
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 m
having to run Python to tell you where that is.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/optio
1.pyc
>foo.MAGIC1.pyo
>foo.MAGIC2.pyc
> bar.MAGIC1.pyc
>...
>
>IIUC
Correct. If necessary, I'll define those two terms in the PEP.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Pyt
o the original (uncirculated) PEP which called for
fat pyc files, but without the complicated implementation details. It's still
an interesting approach to explore.
Writer concurrency can be handled with dot-lock files, but that does incur
some extra overhead, such as the remove() of the loc
ge if
the source file has changed, and in that case, /all/ the byte code in the "fat
pyc" file will be invalidated, so the whole thing can be deleted by the first
writer. I'd worked that out in the original fat pyc version of the PEP.
-Barry
signature.asc
Description: PGP si
with mkdir(2)), so reusing the current
>approach doesn't work.
I believe rename(2) is atomic also, at least on POSIX. I'm not sure if that
helps us though.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
P
e on extension modules is
diagnostics. I want to be able to find out where on the file system a .so
actually lives:
Python 2.7a3+ (trunk:78030, Feb 6 2010, 15:18:29)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more inform
ting different semantics
>for how many directories, and what is contained in them.
I've added __pyr_version__ as an open question in the PEP (not yet committed),
as is making this default behavior (no -R flag required).
-Barry
signature.asc
Description: PGP signature
__
ile you expect, but how would that interact with
how Python finds its cache files? I'm strongly in favor of keeping the cache
files as close to the source they were generated from as possible.
-Barry
signature.asc
Description: PGP signature
___
; Martin
>>
>>
>Good point. OTOH the probability for this to happen actually is very small.
And yet, when it does happen, it's probably a monster to debug and defend
against. Unless we have a convincing cross-platform story for preventing
these race conditions, I think a sin
ill gives us plenty of opportunity to bikeshed, but __pycache__ seems
reasonable to me (it's the cache of parsing and compiling the .py file).
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
pproach:
Take the full absolutely path to the .py file, plus the magic number, plus the
time stamp and hash that. Cache the pyc file under /var/cache/python/.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@py
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
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
>
uick. Compared to everything else that happens during an
>import, I'm not convinced this wouldn't be lost in the noise. I think
>it's at least worth implementing and measuring.
I'd like to see the effect on command line scripts that are run often and then
exit,
> Of course, if this gets fixed before the scheduled release of 2.6.5,
> anyway, that would be nice.
I completely agree.
Besides, unless we have volunteers to step up, create, review, and apply
patches, it makes no sense to hold up releases. In the case of the firs
er if it's clear that we
won't have a fix in time, and it meets the other criteria that Martin has laid
out.
So feel free to mark issues as release blockers for 2.6.5. That doesn't mean
it will actually block the release.
-Barry
___
Pyth
his particular issue seems like a new feature so it's not appropriate for
Python 2.6.5.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
On Feb 10, 2010, at 11:46 PM, Martin v. Löwis wrote:
>That would require that Barry actually *can* judge the issue at hand. In
>the specific case, I would expect that Barry would defer the specifics
>of the Windows issue to Windows experts, and then listen to what they
>say.
Yep
On Feb 11, 2010, at 10:05 PM, Nick Coghlan wrote:
>When I've kicked issues in the RM's direction for a decision, I've
>generally tried to make sure my last comment makes it clear exactly what
>decision I'm asking them to make.
Yes, this is an *excellent* p
ment should be a subdirectory of a working tree. That
subdirectory will be converted into an independent tree, with its own
branch. Commits in the top-level tree will not apply to the new subtree.
See also: join
-Barry
___
Python-Dev mailing list
On Feb 13, 2010, at 1:43 PM, Benjamin Peterson wrote:
> 2010/2/13 Dirkjan Ochtman :
>> On Sat, Feb 13, 2010 at 17:14, Barry Warsaw wrote:
>>> Does hg support an equivalent of 'bzr split'?
>>>
>>> % bzr split --help
>>> Purpose: Split a
will be possible to subscribe to notifications to just interesting
> threads.
Try mail-archive.com, it's searchable.
http://www.mail-archive.com/python-dev@python.org/
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
s really about development and the
FHS is really about installation. Is that what you meant by "antithetical"?
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
bers to follow the
developments of our various projects.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Feb 23, 2010, at 01:56 AM, Tarek Ziadé wrote:
>Let me know if it fits your maintenance process. if so I'll ask for a
>mailing list for this particular repo.
Ask and ye shall receive :)
-Barry
signature.asc
Description: PGP signature
___
ructions on using Bazaar via
the Launchpad mirrors of the Subversion masters:
http://wiki.python.org/moin/Bazaar
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
itten), or the path to where the pyc file /would/ exist if
the source lives on a read-only file system or -B/$PYTHONDONTWRITEBYTECODE is
set.
For alternative implementations of Python that compose modules from multiple
sources, __cached__ can be a tuple.
-Barry
signature.as
ess deployments are not possible though. To
support this use case, you'd have to write a custom import hook. We may write
one as part of the PEP 3147 implementation. Contributions are of course
welcome!
-Barry
signature.asc
Description: PGP signature
__
1101 - 1200 of 2826 matches
Mail list logo
