> Assuming people agree that this is an accurate summary, it should be
> incorporated into the PEP.
Done!
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
> I think it has to be excluded from mapping in order to not introduce
> security issues.
I think you are right. I have now excluded ASCII bytes from being
mapped, effectively not supporting any encodings that are not ASCII
compatible. Does that sound ok?
Regards,
Martin
_
> OK, so what's wrong with os.listdir() and similar functions returning a
> unicode string for strings that correctly encode/decode, and with byte
> strings for strings that are not valid unicode?
See http://bugs.python.org/issue3187
in particular msg71655
Regards,
Martin
__
> There are several different ways I tried it. The easiest was to mount a
> vfat file system with various encodings on Linux and use the Python byte
> interface to write file names, then plug that flash drive into Windows.
So can you share precisely what you have done, to allow others to
reproduc
> Why didn't you point to that discussion from the PEP 383? And why
> didn't you point to Kowalczyk's message on encodings in Mono, Java, etc.
> from the PEP?
Because I assumed that readers of the PEP would know (and I'm sure
many of them do - this has been *really* discussed over and over aga
> Did you use a name with other characters? Were they displayed? Both
> before and after the surrogates?
Yes, yes, and yes (IOW, I put the surrogate in the middle).
> Did you use one or three half surrogates, to produce the three crossed
> boxes?
Only one, and it produced three boxes - probabl
Guido found out that I had misunderstood the existing
pkg mechanism: If a "zope" package is imported, and
it uses pkgutil.extend_path, then it won't glob for files
ending in .pkg, but instead searches the path for
files named zope.pkg.
IOW, this is unsuitable as a foundation of PEP 382. I have
now
>> Because in Python, we want to be able to access all files on disk.
>> Neither Java nor Mono are capable of doing that.
>
> Java is not capable of doing that. Mono, as I keep pointing out, is. It
> uses NULLs to escape invalid UNIX filenames. Please see:
>
> http://go-mono.com/docs/index.aspx
> OK, so why not adopt the Mono solution in CPython? It seems to produce
> valid unicode strings, removing at least one issue with PEP 383. It
> also means that IronPython and CPython actually would be compatible.
See my other message. The Mono solution may not be what you expect it to be.
Rega
> This has nothing to do with how Mono quotes. The reason for this is
> that Mono quotes at all and that the Mono developers decided not to
> change System.IO to understand UNIX quoting.
>
> If Mono used PEP 383 quoting, this would fail the same way.
>
> And analogous failures will exist with
> What's an analogous failure? Or, rather, why would a failure analogous
> to the one I got when using System.IO.DirectoryInfo ever exist in
> Python?
>
>
> Mono.Unix uses an encoder and a decoder that knows about special quoting
> rules. System.IO uses a different encoder and decode
> Martin, if you're going to stick with the half-surrogate trick, would
> you mind adding a section to the PEP on "alternate encoding strategies",
> explaining why the NULL method was not selected?
In the PEP process, it isn't my job to criticize competing proposals.
Instead, proponents of competi
>> If I pass a string with an embedded U+ to gtk, gtk will truncate
>> the string, and stop rendering it at this character. This is worse than
>> what it does for invalid UTF-8 sequences. Chances are fairly high that
>> other C libraries will fail in the same way, in particular if they
>> expec
MRAB wrote:
> One further question: should the encoder accept a string like
> u'\xDCC2\xDC80'? That would encode to b'\xC2\x80'
Indeed so.
> which, when decoded, would give u'\x80'.
Assuming the encoding is UTF-8, yes.
> Does the PEP only guarantee that strings decoded
> from the filesystem are
>>> How do get a printable unicode version of these path strings if they
>>> contain none unicode data?
>>
>> Define "printable". One way would be to use a regular expression,
>> replacing all codes in a certain range with a question mark.
>
> What I mean by printable is that the string must be va
> I've taken the liberty of explicitly CCing Martin just incase he missed
> the thread with all the noise regarding PEP383.
>
> If there are no objections from Martin
It's fine with me - I just won't have time to look into the details of
that change.
Regards,
Martin
_
During Guido's review, we discovered that PEP 382 doesn't
deal with PEP 302 loaders; I believe that it should, though.
Rather than coming up with an ad-hoc design, I propose to
defer the PEP to Python 3.2 - unless somebody can propose
a straight-forward design with not too many new interfaces.
FW
> Okay, I am wrong about this. Having a flag to remember whether I had to
> fall back to the utf-8b trick is one method to implement my requirement,
> but my actual requirement is this:
>
> Requirement: either the unicode string or the bytes are faithfully
> transmitted from one system to another
> In either of the proposals on the table, what code would I write and
> where to have a base package with a set of add-on packages?
I don't quite understand the question. Why would you want to write code
(except for the code that actually is in the packages)?
PEP 382 is completely declarative -
>>> In either of the proposals on the table, what code would I write and
>>> where to have a base package with a set of add-on packages?
>>
>> I don't quite understand the question. Why would you want to write code
>> (except for the code that actually is in the packages)?
>>
>> PEP 382 is complete
>> It's unclear, however, who is using base packages besides mx.* and
>> ll.*, although I'd guess from the PyPI listings that perhaps Django
>> is. (It seems that "base" packages are more likely to use a
>> 'base-extension' naming pattern, vs. the 'namespace.project' pattern
>> used by "pure" pack
> Actually, if you are using only the distutils, you can do this by
> listing only modules in the addon projects; this is how the ll.* tools
> are doing it. That only works if the packages are all being installed
> in the same directory, though, not as eggs.
Right: if all portions install into th
With issue 3672 resolved, it is now unnecessary to introduce
an utf-8b codec, since the utf-8 codec will properly report errors
for all byte sequences invalid in UTF-8, including lone surrogates.
Therefore, utf-8b can be implemented solely through the error handler.
Glenn Linderman suggested that
> That's even nicer. One minor detail though, in the sentence:
>
> "non-decodable bytes >128 will be represented as lone half surrogate"
>
> ">" should be ">=".
Thanks, fixed.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
> If the error handler is supposed to be used for codecs other than utf-8,
> perhaps it should renamed something more generic, e.g. "surrogate-escape"?
Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
it's an algorithm based on 16-bit or 32-bit code points.
> Also, if utf8
> > If the error handler is supposed to be used for codecs other than
> utf-8,
> > perhaps it should renamed something more generic, e.g.
> "surrogate-escape"?
>
> Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
> it's an algorithm based on 16-bit o
> > > Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
> > > it's an algorithm based on 16-bit or 32-bit code points.
>
> I don't understand this phrasing. The algorithm is only applicable to
> ASCII-compatible octet streams. It results in code points by a simple
> disp
> I have three substantive comments. First, although consequences for
> Python 3 byte interfaces (ie, "none") are explicitly stated, as far as
> I can see this PEP could apply to Python 2 as well. I don't think
> it's intended that way. Either way, I think you should clarify that
> point.
Done:
> It occurs to me that the PEP maybe should say that it is an error
> to have your POSIX locale set to UTF-16 or something like that.
No. It is *impossible* to have UTF-16 as the locale character set,
not an error. Your statement is like saying "it is an error to
breathe in the vacuum".
I
> The name "utf8b" suggested in the PEP is not in line with the codec
> design
Where is that design documented, and how exactly violates the name
the design (chapter and verse, please).
> Error handlers and codecs are two different things, so the namespaces
> need to be clearly separate.
They *a
Stephen J. Turnbull wrote:
> "Martin v. Löwis" writes:
> > > It occurs to me that the PEP maybe should say that it is an error
> > > to have your POSIX locale set to UTF-16 or something like that.
> >
> > No. It is *impossible* to have UTF-
> > > Second, I suggest "surrogate-replace" as the name of the error handler
> > > rather than "utf8b".
> >
> > I think this is bike-shedding.
>
> I don't personally care (I already was aware of UTF-8B), but there are
> plenty of others who do.
I think it is a fairly bad name, because it is
> Yeah, yeah, this is the same old same old from PEP 3131. Anything
> that handles the various attacks based on ASCII-alike characters
> should at least rule out invalid Unicode, too!
>
> And where is this U+DC2F supposed to be coming from, anyway? The
> user's *local* environment or the user's
>>> The name "utf8b" suggested in the PEP is not in line with the codec
>>> design
>> Where is that design documented, and how exactly violates the name
>> the design (chapter and verse, please).
>
> Martin, I designed the whole Python codec machinery
Not true. PEP 293 was written and designed by
> I'm sorry for the lack of clarity of my posts, but somehow you're
> completely missing the point. The point is precisely that Python
> *won't* use Shift JIS as the file system encoding (if it did there
> would be no problem with reading Shift JIS), but the people who
> created the media *did*.
>
> Judging by the existing names, I think that 'surrogate' would be
> reasonable
MAL's list of existing names is incomplete. "surrogates" is already
an existing name, also, and it means something different (similar,
but different).
Regards,
Martin
___
Py
Terry Reedy wrote:
> Glenn Linderman wrote:
>> On approximately 5/6/2009 3:08 AM, came the following characters from
>> the keyboard of MRAB:
>>> M.-A. Lemburg wrote:
>>>> Martin v. Löwis wrote:
>>
>>> Judging by the existing names, I think t
> Is it only usable with utf8 as an encoding?
No, it applies to any codec which potentially cannot decode
all bytes >127.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
> But first, it should be stopped by any of several
> standard precautions. For example, applying os.path.realpath (come to
> think of it, PEP 383 should say something about realpath, shouldn't
> it?)
Why do you think so? I think the existing documentation of realpath
is correct and complete.
>
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> Despite there being also an error handler called "surrogates".
>
> People, perhaps we could end all the bikeshedding and call one of those
> handlers
> "surrogates-pass" and the o
>> Are you serious?
>
> Are you? ;-? You are the one naming a codec-agnostic error handler (if
> I understand correctly, and correct me if I do not) after a particular
> codec, and denying that that could cause confusion. See other message.
I can only repeat what I said before: I call it utf8b
> I qualify with a). I believe I understand c) but, as explained in my
> other post, I do not think your reason applies. In fact, I think
> concern for naming rights might suggest that you *not* reuse the name
> for something different. I would have to learn more about the existing
> 'surrogates'
Michael Urman wrote:
> On Wed, May 6, 2009 at 15:42, "Martin v. Löwis" wrote:
>> Despite there being also an error handler called "surrogates".
>
> Not that I have to be, but I'm not sold on the previous UTF-8 codec
> behavior becoming an error handler
> By the way, what are the ASCII characters that are not suppported by
> Shift-JIS?
> Not many I suppose? (if I read the Wikipedia entry correctly, it's only the
> backslash and the tilde).
The problem with this encoding is that bytes below 128 appear as second
bytes of a two-byte encoding:
py>
>> So are you proposing that I should rename the PEP 383 handler
>> to "utf_8b_encoder_invalid_codepoints"?
>
>
> No, he's saying that your algorithm for choosing the PEP 383 handler
> should have come up with that name, rather than utf8b. But since PEP
> 383 applies to other codecs besides UTF-
> Wouldn't renaming the existing "surrogates" handler be an incompatible
> change, and thus inappropriate?
No - it's new in Python 3.1.
So what do you think about Antoine's proposal?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
> The error handler designed with utf-8 in mind has no name in the encode
> direction and is called "utf_8b_decoder_invalid_bytes" in the decode
> direction. By your reasoning, *that* should be its name in Python. The
> encoding error handler would then be named analogously
> "utf_8b_encoder_inva
>> Well, there is a way to stack error handlers, although it's not pretty:
>> [...]
>> codecs.register_error("surrogates_then_replace",
>> surrogates_then_replace)
>
> That mitigates my arguments significantly, although I'd rather see
> something like errors=('surrogates', 're
> I haven't come up with anything I like better than errors="lenient"
> for the old utf8 behavior handler; would errors="nonvalidating" be
> correct?
I think either is fairly unspecific.
> For the utf8b error handler, I could see any of errors="roundtrip",
> errors="roundtripreplace", errors="tos
> The error handler for undoing this operation (ie. when converting
> a Unicode string to some other encoding) should probably use the
> same name based on symmetry and the fact that the escaping
> scheme is meant to be used for enabling round-trip safety.
Could you please familiarize yourself wit
> Given your explanation of what the new 'surrogates' handler does (pass
> rather than reject erroneous surrogates), I think 'surrogates_pass' is
> fine. Thus, I considoer that and 'surrogates_excape' the best proposal
> the best so far and suggest that you make this pair the current status
> quo
>> Ok, so create three tar files:
>>
>> 1. base.tar, containing
>>
>>simplistix/
>>simplistix/__init__.py
>
> So this __init__.py can have code in it?
That's the point, yes.
> And base.tar can have other modules and subpackages in it?
Certainly, yes.
> What happens if the base and an
>> Right: if all portions install into the same directory, you can have
>> base packages already.
>
> Speaking as a user of packages, this use case is one I hardly ever encounter
> with the Python software/modules/packages I use. The only ones that spring
> to mind are the mx.* and ll.* packages.
Zooko O'Whielacronx wrote:
> .pth files are why I can't easily use GNU stow with easy_install.
> If installing a Python package involved writing new files into the
> filesystem, but did not require reading, updating, and re-writing any
> extant files such as .pth files, then GNU stow would Just Wor
Chris Withers wrote:
> Martin v. Löwis wrote:
>>> So this __init__.py can have code in it?
>>
>> That's the point, yes.
>>
>>> And base.tar can have other modules and subpackages in it?
>>
>> Certainly, yes.
>
> Great, when is the
Jeroen Ruigrok van der Werven wrote:
> -On [20090509 16:07], Chris Withers (ch...@simplistix.co.uk) wrote:
>> They're also all pure namespace packages rather than base + addons,
>> which is what we've been discussing...
>
> But from Martin's email I understood it more as being base packages. Unle
>> If you always use --single-version-externally-managed with easy_install,
>> it will stop editing .pth files on installation.
>
> It's --multi-version (-m) that does that.
> --single-version-externally-managed is a "setup.py install" option.
>
> Both have the effect of not editing .pth files,
> GNU stow does handle these issues.
If GNU stow solves all your problems, why do you want to
use easy_install in the first place?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
Zooko Wilcox-O'Hearn wrote:
> On May 10, 2009, at 11:18 AM, Martin v. Löwis wrote:
>
>> If GNU stow solves all your problems, why do you want to use
>> easy_install in the first place?
>
> That's a good question. The answer is that there are two separate jobs:
Hi Sean,
Can you please setup backup for albatross?
I gave sudo permissions to the "jafo" user, which has
the key j...@guin.tummy.com authorized.
I think the policy now is that root logins to albatross
are not allowed. So what might work is this:
Create an rsyncbackup user, and give it sudo per
[please ignore this message - I sent it to the wrong mailing list]
Regards,
Martin
___
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/archiv
> Just food for thought here, but seeing how 3.1 is going to be a real
> featureful
> schedule despite being released shortly after 3.0, wouldn't it make sense to
> tighten future release planning a little?
Do you have any specific releases in mind that you would like to apply
such a tightened sc
> How to build Python 2.6.2 on HP-UX Itanium with thread support?
> Note: I know that the first address to post this question is
> comp.lang.python, but
> I posted this question a week ago on comp.lang.python
> (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c7006ad8e5cf81e8)
> Now, this looks like python-dev material. PEP 11[0], the information
> in README[1] and the notes in the downloads pages[2] could be
> improved and updated. If someone has time to invest in this, a
> compatibility matrix would be very nice to have.
I don't think HP-UX is ready for PEP 11 yet. I
Alexander Shigin wrote:
> В Сбт, 16/05/2009 в 14:58 -0400, P.J. Eby пишет:
>> ";" *is* valid in Windows filenames, actually. Tabs aresn't.
>
> I was sure ';' is separator for PATH in Windows. Do I miss something?
Yes, this:
http://msdn.microsoft.com/en-us/library/aa365247.aspx
Regards,
Martin
Issue 6012 proposes to add cleanup support for O& converters;
a first client for this would be PyUnicode_FSConverter. Using
cleanup is always necessary if the conversion function allocates
memory, and a later argument converter fails. The memory allocated
must then be released.
There are three opt
> But, there's an option in Distutils.make_archive to create a tarball
> using the "compress" [1] program rather than gzip or bzip2.
> Using tar -Z, it will pipe it to the compress program if present. This
> program implements the LZW algorithm [2].
As everybody else says: it might be best to just
Thomas Wouters reminded me of a long-standing idea; I finally
found the time to write it down.
Please comment!
Regards,
Martin
PEP: 384
Title: Defining a Stable ABI
Version: $Revision: 72754 $
Last-Modified: $Date: 2009-05-17 21:14:52 +0200 (So, 17. Mai 2009) $
Author: Martin v. Löwis
Status
>> Functions declared in the following header files are not part
>> of the ABI:
>> - cellobject.h
>> - classobject.h
>> - code.h
>> - frameobject.h
>> - funcobject.h
>> - genobject.h
>> - pyarena.h
>> - pydebug.h
>> - symtable.h
>> - token.h
>> - traceback.h
>
> What kind of effect does this have
>> Header Files and Preprocessor Definitions
>> -
>>
>> Applications shall only include the header file Python.h (before
>> including any system headers), or, optionally, include pyconfig.h, and
>> then Python.h.
>
> What about structmember.h? It's not yet
Dirkjan Ochtman wrote:
> On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis"
> wrote:
>> I fail to see the relationship, so: no effect that I can see.
>>
>> Why do you think that optimization efforts could be related to
>> the PEP 384 proposal?
>
&
Dino Viehland wrote:
> Dirkjan Ochtman wrote:
>> It would seem to me that optimizations are likely to require data
>> structure changes, for exactly the kind of core data structures that
>> you're talking about locking down. But that's just a high-level view,
>> I might be wrong.
>>
>
>
> In part
>>> It also might make it easier for alternate implementations to support
>>> the same API so some modules could work cross implementation - but I
>>> suspect that's a non-goal of this PEP :).
>>>
>>
>> Indeed :-) I'm also skeptical that this would actually allow
>> cross-implementation module
> Something I haven't seen explicitly mentioned as yet (in the PEP or the
> python-dev list discussion) are the memory management APIs and the FILE*
> APIs which can cause the MSVCRT versioning issues on Windows.
>
> Those would either need to be excluded from the stable ABI or else
> changed to u
Aahz wrote:
> Yes, this is ancient, I've been putting off dealing with it because I
> couldn't figure out who should handle it. At this point, I think that if
> anyone does it should be the release team, therefore I'm forwarding to
> python-dev. Feel free to tell me I made the wrong choice. ;-)
> Now, with the PEP, I have a feeling that the Python C-API
> will in effect be limited to what's in the PEP's idea of
> a usable ABI and open up the non-inluded public C-APIs
> to the same rate of change as the private APIs.
That's certainly not the plan. Instead, the plan is to have
a stable ABI
The structure of type objects is not available to applications;
declaration of "static" type objects is not possible anymore
(for applications using this ABI).
>>> Hmm, that's going to create big problems for extensions that
>>> want to expose a C-API for their types: Type checks are
Functions declared in the following header files are not part
of the ABI:
- cellobject.h
- classobject.h
- code.h
- frameobject.h
- funcobject.h
- genobject.h
- pyarena.h
- pydebug.h
- symtable.h
- token.h
- traceback.h
>>> I don't th
> 3. ?? - I'm sure there are other issues that deserve a look.
What about fairness? I don't know off-hand whether the GIL is
fair, or whether critical sections are fair, but it needs to be
considered.
Regards,
Martin
___
Python-Dev mailing list
Python-D
> If you define fairness in this context as not starving other threads
> while consuming resources, that is built into the interpreter via
> sys.setcheckinterval() and also anywhere the GIL is released for I/O.
> What might be interesting is to see if releasing a critical section
> and immediately
>> According to a past discussion on this list, the current implementation
>> isn't:
>> http://mail.python.org/pipermail/python-dev/2008-March/077814.html
>> (at least on the poster's system)
>>
>
> I believe he's only talking about Linux. Apples & oranges when it
> comes to stuff like this
Plea
Raymond Hettinger wrote:
> Also at issue is whether the
> addition was too rushed (see David Moss's comment on the tracker and
> later comments by Antoine Pitrou).
That comment was from January 2009; it had two aspects
a) is ipaddr getting special treatment just because it was contributed
by Go
> Clay is basically correct. The ipaddr.py API is missing important
> features, and it would probably be a mistake to add it to the python
> standard library if that means we'd have to maintain compatibility for
> the indefinite future.
>From a maintenance point of view, these two statements don'
> If this were a core feature that many developers were anxiously
> awaiting, I could understand the desire to release and iterate. But is
> there really a pressing need for an IP library in the stdlib?
You should have asked this question a few month ago. Now, release
mechanics make it difficult t
Clay McClure wrote:
> On Tue, Jun 2, 2009 at 1:38 AM, "Martin v. Löwis" wrote:
>
>> For the net-vs-host issue, I think a backwards-compatible solution
>> is possible: just give the IP() function an option parameter that
>> makes it reject a netmask during par
> This argument makes no sense. The feasibility of removing the library
> does not depend on the severity of the issues found within it. Either
> it is hard to remove the library, or it is easy. If it's hard to
> remove, it doesn't get any easier because I discover a fatal flaw.
We could remove it
>> We could remove it, but then what we have wouldn't really be a release
>> candidate anymore, so the release would get delayed.
>
> How long do release candidates soak in the field before being accepted?
For this release, the release schedule is defined in PEP 375
> I'm curious if an exception
> Clay repeatedly pointed out that other people have objected to ipaddr and
> been ignored. It's really, really disappointing to see you continue to
> ignore not only them, but the repeated attempts Clay has made to point
> them out.
[I meant to stop discussing here, but I just want comment on th
> To go back to JP's original comments though: what was the right thing
> for him to do, back in January, when he had these concerns? Should he
> have said "I am therefore -1 on this inclusion"? Should he have been
> discussing this on the mailing list rather than the tracker? Should he
> have k
> The thing that stands out about the earlier tracker/mailing list
> discussions is how very few people affirmatively wanted ipaddr added
> to the standard library. Most people thought it sounded ok in
> principle, didn't care, or thought it was not a great idea but didn't
> feel like arguing abou
> Not true - if you are added as nosy on a tracker item (which happens
> when you make a comment or you can do yourself) then you get emailed
> about new comments. The email contains the body of the comment so you
> can follow discussions completely by email only going to the tracker to
> add respo
> Is there a document which lists these things, and explains how it is
> desirable to communicate them? I recently updated Twisted's equivalent
> document, adding minutae like which buttons to click on in our issue
> tracker, since that seems obvious to me but apparently wasn't obvious to
> a lot
> Is there a good python-dev archive search mechanism (other than to
> google "python-dev " ;) out there? Wouldn't that help?
I would add site:mail.python.org into the google query, but apart from
that: what's wrong with google search?
Regards,
Martin
Alexander Belopolsky wrote:
> Alternatively, one could create a python-dev profile on roundup and
> encourage people to add python-dev to the nosy list when discussion
> needs to be broaden. This way replies to all will be posted in both
> places. Once discussion gets too specialized, someone can
> In addition, you can fairly easily create a saved query to show you all
> the open tickets that you are on the nosy list for. (Although I created
> and saved my query for that so long ago that I don't recall the exact
> details on how to go about doing that).
It's fairly easy. Start a search, pu
> I have thought that 2.7 was now to come out instead with 3.2 and would
> include backported 3.2 new features. Others expect 2.7 to come out soon
> after 3.1 and to only contain new 3.1 features. So Guido or someone,
> please clarify: is 2.7 to be the counterpart of 3.1 or 3.2?
Neither, nor. 2.
Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I have thought that 2.7 was now to come out instead with 3.2 and would
>>> include backported 3.2 new features. Others expect 2.7 to come out soon
>>> after 3.1 and to only contain new 3.1 features. So Guido or someo
> I'm neutral on time frames, but I think that it _should_ be a policy
> that new features only get released to the 2.x branch after they have
> been released in the 3.x branch. Or, rather, I though that policy was
> implicit in the idea that we weren't _automatically_ backporting features,
> spec
>> Also, Martin suggested we migrate to Python's svn and then go along
>> for the svn->hg ride. Does that still make sense now that some
>> planning has been done?
>
> I don't think so. It should not matter from which repository the conversion
> is done, especially since there is no shared histo
> For my part I'm fine either way (and I agree that Martin should decide
> based on what is best for him).
See my other message. We need to collect SSH keys, and I don't mind
moving the Jython repository. OTOH, if the Jython repository gets
converted into hg right away, it's certainly (a little)
401 - 500 of 5277 matches
Mail list logo
