James Y Knight wrote:
On Apr 5, 2009, at 6:29 AM, Antoine Pitrou wrote:
Brian Quinlan sweetapp.com> writes:
I don't see why this is helpful. Could you explain why
_RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python version.
I
Alexandre Vassalotti peadrop.com> writes:
> With Mercurial, we will need to add support for server-side clone
> ourselves. There's few ways to provide this feature. We give Unix user
> accounts to all core developers and let developers manages their
> private branches directly on the server. You m
Martin v. Löwis v.loewis.de> writes:
> Is it possible to branch from a subdirectory? For the "different VMs"
> stuff, it's rather desirable to have a branch of the test suite, and
> the perhaps the standard library, than extracting it from the source.
You can only branch the whole repository. Of
Alexandre Vassalotti peadrop.com> writes:
> If I recall correctly, only ssh clients can request compression to the
> server—in other words, the server cannot forces the clients to use
> compression, but merely allow them use it.
>
> See the man page for sshd_config and ssh_config for the specific
On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti
wrote:
> But that won't work if people who are not core developers submit us
> patch bundle to import. And maintaining a such white-list sounds to me
> more burdensome than necessary.
Well, if you need contributors to sign a contributor's agreeme
On Mon, Apr 6, 2009 at 04:27, wrote:
> Maybe once for each currently active Subversion branch (2.6, 2.7, 3.0, 3.1)?
Sure, if we're doing cloned branches. But then someone will also need
to clone 2.5, and maybe 2.4. The point is, as long as it's a constant
factor and not an order of magnitude mor
On Mon, Apr 6, 2009 at 00:48, Mark Hammond wrote:
> Just to be clear, what input would you like on that map?
Review of email addresses, pointers to names/email addresses for the
usernames I don't have anything for yet. Also, there's a few commented
question marks, it would be useful if someone ch
On Mon, Apr 6, 2009 at 12:20 AM, Aahz wrote:
> How difficult would it be to change the decision later? That is, how
> about starting with a CVS-style system and maybe switch to kernel-style
> once people get comfortable with Hg?
I believe it would be fairly easy. It would be a matter of declarin
On Sun, Apr 5, 2009 at 2:40 PM, "Martin v. Löwis" wrote:
>> Okay, sounds like that will be easy. Would be good to enable compression
>> on the SSH, though, if that's not already done.
>
> Where is that configured?
>
If I recall correctly, only ssh clients can request compression to the
server—in
On Sun, Apr 5, 2009 at 2:45 PM, Dirkjan Ochtman wrote:
> On 05/04/2009 20:36, "Martin v. Löwis" wrote:
>>
>> We do require full real names (i.e. no nicknames). Can Mercurial
>> guarantee such a thing?
>
> We could pre-record the list of allowed names in a hook, then have the hook
> check that user
On Mon, Apr 06, 2009, Alexandre Vassalotti wrote:
>
> This makes me remember that we will have to decide how we will
> reorganize our workflow. For this, we can either be conservative and
> keep the current CVS-style development workflow?i.e., a few main
> repositories where all developers can comm
On Sun, Apr 5, 2009 at 1:37 PM, "Martin v. Löwis" wrote:
> I think it should be stated in the PEP what branches get converted,
> in what form, and what the further usage of the svn repository should
> be.
>
Noted.
> I think there is a long tradition of such annotations; we should
> try to repeat
On Sun, Apr 5, 2009 at 10:50 PM, wrote:
> Barry> Someone asked me at Pycon about stripping out Demos and Tools.
>
> Matthias> +1, but please for 2.7 and 3.1 only.
>
> Is there a list of other demos or tools which should be deleted? If
> possible the list should be publicized so that people
Barry> Someone asked me at Pycon about stripping out Demos and Tools.
Matthias> +1, but please for 2.7 and 3.1 only.
Is there a list of other demos or tools which should be deleted? If
possible the list should be publicized so that people can pick up external
maintenance if desired.
Ski
>> As for the clone time, one of our proeminent developers is, IIRC, on
>> a 40 kb/s line. Perhaps he wants to step in and say whether cloning
>> the trunk is a painful experience for him, or not.
Dirkjan> Sure it's painful, but he only has to go through that once,
Dirkjan> ma
After the private hell I've gone through the past few days stumbling around
Mercurial without really understanding what the hell I was doing, I strongly
recommend that when the conversion is complete that there is a "do it just
like you did it with svn" mode available. Fortunately, this was just w
Antoine Pitrou wrote:
Your proposal looks sane, although the fact that a semi-private method
(starting with an underscore) is designed to be overriden in some classes is a
bit annoying.
The only other way I can see is to give up any attempt
in the base class to ensure that flushing occurs befor
On Sun, Apr 5, 2009 at 3:54 PM, Nick Coghlan wrote:
> Antoine Pitrou wrote:
> > James Y Knight fuhm.net> writes:
> >> It seems that a separate method "_internal_close" should've been
> >> defined to do the actual closing of the file, and the close() method
> >> should've been defined on the base
"Martin v. Löwis" wrote:
>> I think it would be a good idea to host a temporary svn mirrors for
>> developers who accesses their VCS via an IDE. Although, I am sure
>> anymore if supporting these developers (if there are any) would worth
>> the trouble. So, think of this as optional.
>
> Any decisi
Barry Warsaw schrieb:
> Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out
> Demos and Tools. I'm happy to remove the two I wrote - Tools/world and
> Tools/pynche - from the distribution and release them as separate
> projects (retaining the PSF license). Should I remove the
Greg Ewing canterbury.ac.nz> writes:
>
> Why is it that whenever the word "buffer" is mentioned,
> some people seem to think it has something to do with
> memoryview? There is no such thing as "a buffer".
There is a Py_buffer struct.
___
Python-Dev m
Greg Ewing wrote:
>
> Why is it that whenever the word "buffer" is mentioned,
> some people seem to think it has something to do with
> memoryview? There is no such thing as "a buffer". There
> is the buffer interface, and there are objects which
> support the buffer interface, of which memoryview
Firephoenix wrote:
I basically agreed with renaming the next() method to __next__(), so as
to follow the naming of other similar methods (__iter__() etc.).
But I noticed then that all the other methods of the generator had
stayed the same (send, throw, close...)
Keep in mind that next() is pa
Antoine Pitrou wrote:
> James Y Knight fuhm.net> writes:
>> It seems that a separate method "_internal_close" should've been
>> defined to do the actual closing of the file, and the close() method
>> should've been defined on the base class as "self.flush();
>> self._internal_close()" and ne
On 6/04/2009 12:13 AM, Dirkjan Ochtman wrote:
I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
Could use some review, but it seems like a good start.
Just to be clear, what input would you like on that map?
I'm listed twice:
mark.hammond = Mark Hammond
mhammond = Mark
Nick Coghlan wrote:
Still, as both you and Greg have pointed out, even in its current form
memoryview is already useful as a replacement for buffer that doesn't
share buffer's problems
That may be so, but I was more pointing out that the
elementwise functions I'm talking about would be useful
Brian Quinlan wrote:
if not self.__closed:
try:
-self.flush()
+IOBase.flush(self)
except IOError:
pass # If flush() fails, just give up
self.__closed = True
That doesn't seem like a good idea to me at
Martin v. Löwis schrieb:
>>> We could pre-record the list of allowed names in a hook, then have the
>>> hook check that usernames include one of those names and an email
>>> address (so people can still start using another email address).
>>
>> What about commits from other people, e.g. pulled f
Antoine Pitrou schrieb:
> Georg Brandl gmx.net> writes:
>>
>> When commits with bad whitespace changes are rejected on push, this is a
>> pretty good incentive to run the pre-commit hook next time, so that you
>> don't have to re-do all the commits in that batch :)
>
> Do you really have to re-d
>> We could pre-record the list of allowed names in a hook, then have the
>> hook check that usernames include one of those names and an email
>> address (so people can still start using another email address).
>
> What about commits from other people, e.g. pulled from a repo or imported
> via h
Georg Brandl gmx.net> writes:
>
> When commits with bad whitespace changes are rejected on push, this is a
> pretty good incentive to run the pre-commit hook next time, so that you
> don't have to re-do all the commits in that batch :)
Do you really have to re-do all the commits, or can you just
Dirkjan Ochtman schrieb:
> On 05/04/2009 20:29, "Martin v. Löwis" wrote:
>> FYI: this is the list of hooks currently employed:
>> - pre: check whitespace
>> - post: mail python-checkins
>> inform regular buildbot
>> inform community buildbot
>> trigger website rebuild if
Dirkjan Ochtman schrieb:
> On 05/04/2009 20:36, "Martin v. Löwis" wrote:
>> We do require full real names (i.e. no nicknames). Can Mercurial
>> guarantee such a thing?
>
> We could pre-record the list of allowed names in a hook, then have the
> hook check that usernames include one of those names
2009/4/5 Barry Warsaw :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Someone (I'm sorry, I forgot who) asked me at Pycon about stripping out
> Demos and Tools. I'm happy to remove the two I wrote - Tools/world and
> Tools/pynche - from the distribution and release them as separate project
On 05/04/2009 20:36, "Martin v. Löwis" wrote:
We do require full real names (i.e. no nicknames). Can Mercurial
guarantee such a thing?
We could pre-record the list of allowed names in a hook, then have the
hook check that usernames include one of those names and an email
address (so people ca
On 05/04/2009 20:29, "Martin v. Löwis" wrote:
FYI: this is the list of hooks currently employed:
- pre: check whitespace
- post: mail python-checkins
inform regular buildbot
inform community buildbot
trigger website rebuild if a PEP was modified
(but then, whet
>> I think at least 3.x and 2.x should live in separate repos. It is
>> pointless for
>> a clone of py3k to end up pulling all 4+ changesets from the
>> trunk. It would
>> add 100MB+ to every py3k clone (that is, quadrupling the size of the
>> repository).
>
> I don't agree. It's quite annoyin
On 05/04/2009 20:18, "Martin v. Löwis" wrote:
But then, I have not tried installing it, so I don't know what it
actually looks like.
Ah, right. In my setup, there was an index page with three lines of
text, one of which had a link to the waterfall. So I think that should
still be simple enoug
> For another, I'd like to use an author map to bring the revision authors
> more in line with what Mercurial repositories usually display; this
> helps with tool support and is also just a nicer solution IMO.
We do require full real names (i.e. no nicknames). Can Mercurial
guarantee such a thing?
> I've svnsynced the SVN repo so that we can work on it efficiently, and
> I've already talked with Augie Fackler, the hgsubversion maintainer,
> about what the best way forward is. For example, we may want to leave
> some of the very old history behind, or prune some old branches.
I'm -1 on remov
> Yeah, that won't be necessary. The canonical solution is to have just
> one Unix account called hg, to which we can add public keys.
That would work fine for me. We currently call the account pythondev,
but calling it hg would be shorter, and therefore better (plus,
pythondev is associated with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Someone (I'm sorry, I forgot who) asked me at Pycon about stripping
out Demos and Tools. I'm happy to remove the two I wrote - Tools/
world and Tools/pynche - from the distribution and release them as
separate projects (retaining the PSF license
>> Ok, that's a problem. We currently run 0.7.5 on the master, and have
>> made custom changes that need to be forward-ported. IIUC, this will
>> also mean that the waterfall default page is gone, which might surprise
>> people.
>>
>> I suppose all slaves also need to upgrade.
>
> Why is the water
On 05/04/2009 19:37, "Martin v. Löwis" wrote:
Any decision to have or not have such a feature should be stated in
the PEP. I personally don't use IDEs, so I don't care (although
I do notice that the apparent absence of IDE support for Mercurial
indicates maturity of the technology)
Well, there
On 05/04/2009 19:50, "Martin v. Löwis" wrote:
Ok, that's a problem. We currently run 0.7.5 on the master, and have
made custom changes that need to be forward-ported. IIUC, this will
also mean that the waterfall default page is gone, which might surprise
people.
I suppose all slaves also need to
> We should probably not include any branches that haven't been touched in
> the last 18 months. Then we also leave out branches that have been pruned.
>
> BTW, tags are also missing from the current conversions. We probably
> want to keep all release tags, but not the partial tags (e.g. the
> Dis
Dirkjan Ochtman wrote:
> On 05/04/2009 11:06, "Martin v. Löwis" wrote:
>> In particular, the Stackless people have requested that they move along
>> with what core Python does, so their code should also be converted.
>
> I'd be interested to hear if they want all of their stuff converted, or
> jus
James Y Knight fuhm.net> writes:
>
> It seems that a separate method "_internal_close" should've been
> defined to do the actual closing of the file, and the close() method
> should've been defined on the base class as "self.flush();
> self._internal_close()" and never overridden.
I'm comp
> Sounds sane. Would I be able to get access to PSF infrastructure to get
> started on that, or do you want me to get started on my own box? I'll
> probably do the conversion on my own box, but for authn/authz it might
> be useful to be able to use PSF infra.
Now that Alexandre has also volunteere
>> I'm not sure exactly what the purpose or mechanism for /external is. Sure,
>> it's like a snapshot dir, probably used for to pull some stuff into other
>> process? Seems to me like it might be interesting to, for example, convert
>> to a simple config file + script that lets you specify a packag
> I am not sure if it would be useful to convert the old branches to
> Mercurial. The simplest thing to do would be to keep the current svn
> repository as a read-only archive. And if people needs to commit to
> these branches, they could request the branch to be imported into a
> Mercurial branch
Stephen J. Turnbull a écrit :
Firephoenix writes:
> I'm a little confused by the recent changes to the generator system...
Welcome to the club. It's not easy even for the gurus. See the PEP
380 ("yield from") discussions (mostly on Python-Ideas).
> But I noticed then that all the other me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 5, 2009, at 5:06 AM, Martin v. Löwis wrote:
- decide what to do with the bzr mirrors
I don't see any reason to keep them running on python.org. There are,
or will be, other alternatives.
Barry
-BEGIN PGP SIGNATURE-
Version: Gn
On Apr 5, 2009, at 6:29 AM, Antoine Pitrou wrote:
Brian Quinlan sweetapp.com> writes:
I don't see why this is helpful. Could you explain why
_RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python
version.
I suppose it's so that
2009/4/5 Antoine Pitrou :
> Dirkjan Ochtman ochtman.nl> writes:
>>
>> I also think 100MB+ is a cheap price to pay,
>> given you only pay it in disk space (cheap) and initial clone time (not
>> very often, and usually still quite fast).
>
> It is a cheap price to pay if there is a significant retur
On 05/04/2009 17:18, Antoine Pitrou wrote:
It is a cheap price to pay if there is a significant return for it. In my
experience using the hg mirror of the py3k branch, I don't remember having had
to run "annotate" on the trunk to hunt for a change that I'd witnessed in py3k.
Other developers may
Dirkjan Ochtman ochtman.nl> writes:
>
> I also think 100MB+ is a cheap price to pay,
> given you only pay it in disk space (cheap) and initial clone time (not
> very often, and usually still quite fast).
It is a cheap price to pay if there is a significant return for it. In my
experience using
On 05/04/2009 16:39, Antoine Pitrou wrote:
The other nice thing with having "[svn rXXX]" in the patch subject line is that
it makes the info easily viewable and searchable in the Web front-end.
We can still make it accessible/searchable on the web if we don't put it
in the commit message.
I
Hello,
> hgsubversion in many cases will preserve the rev order from svn so
> that the local revision numbers that hg shows will be the same as in SVN
> anyway.
Er... I guess it's only the case in simplistic cases where you convert all
branches in the SVN repo to a single hg repo (which is not
On 05/04/2009 15:11, Alexandre Vassalotti wrote:
I am not sure if it would be useful to convert the old branches to
Mercurial. The simplest thing to do would be to keep the current svn
repository as a read-only archive. And if people needs to commit to
these branches, they could request the branc
(going back on-list)
On 05/04/2009 15:42, Alexandre Vassalotti wrote:
I'm pretty sure that we'll need to reconvert; I don't think the current
conversion is particularly good.
What is bad about it?
For one thing, it has the [svn] prefixes, which I found to be quite
ugly. hgsubversion in many
On Sun, Apr 5, 2009 at 6:27 AM, Antoine Pitrou wrote:
> Alexandre Vassalotti peadrop.com> writes:
>>
>> Off the top of my head, the following is needed for a successful migration:
>
> There's also the issue of how we adapt the current workflow of "svnmerging"
> between branches when we want to ba
Georg Brandl a écrit :
Firephoenix schrieb:
Hello everyone
I'm a little confused by the recent changes to the generator system...
I basically agreed with renaming the next() method to __next__(), so as
to follow the naming of other similar methods (__iter__() etc.).
But I noticed then that
2009/4/5 Dirkjan Ochtman :
> On 05/04/2009 11:06, "Martin v. Löwis" wrote:
>> - come up with a strategy for /external (also relevant for
>> the buildbot slaves)
>
> I'm not sure exactly what the purpose or mechanism for /external is. Sure,
> it's like a snapshot dir, probably used for to pull som
2009/4/5 Alexandre Vassalotti :
> Off the top of my head, the following is needed for a successful migration:
...
> - Update the release.py script.
I'll do this.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
On Sun, Apr 5, 2009 at 5:06 AM, "Martin v. Löwis" wrote:
>> Off the top of my head, the following is needed for a successful migration:
>>
>> - Verify that the repository at http://code.python.org/hg/ is
>> properly converted.
>
> I see that this has four branches. What about all the other bran
Firephoenix schrieb:
> Hello everyone
>
> I'm a little confused by the recent changes to the generator system...
>
> I basically agreed with renaming the next() method to __next__(), so as
> to follow the naming of other similar methods (__iter__() etc.).
> But I noticed then that all the other
Dirkjan Ochtman schrieb:
> On 05/04/2009 12:27, Antoine Pitrou wrote:
>> There's also the issue of how we adapt the current workflow of "svnmerging"
>> between branches when we want to back- or forward-port stuff. In particular,
>> tracking of already done or blocked backports.
>
> Right. The cano
Hello everyone
I'm a little confused by the recent changes to the generator system...
I basically agreed with renaming the next() method to __next__(), so as
to follow the naming of other similar methods (__iter__() etc.).
But I noticed then that all the other methods of the generator had
stay
2009/4/5 Antoine Pitrou :
> Nick Coghlan gmail.com> writes:
>>
>> That's largely because parts 2 and 3 are somewhat use case challenged:
>> the key motivation behind PEP 3118 was so that libraries like NumPy, PIL
>> and the like would have a common standard for data interchange.
>
> If I understan
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> Parts 2 and 3, being the memoryview API and support for the new protocol
>> in the builtin types are the parts that are currently restricted to
>> simple linear memory views.
>>
>> That's largely because parts 2 and 3 are somewhat use case
On 05/04/2009 13:00, Antoine Pitrou wrote:
Transplant or export/import have the right semantics IMO, but we lose the
tracking that's built in svnmerge. Perhaps a new hg extension? ;)
(the missing functionality is to store the list of transplanted or blocked
changesets in a .hgXXX file (storing th
Dirkjan Ochtman ochtman.nl> writes:
>
> Right. The canonical way to do that with Mercurial is to commit patches
> against the "oldest" branch where they should be applied, so that every
> stable branch is a strict subset of every less stable branch.
It doesn't work between py3k and trunk, whic
Antoine Pitrou wrote:
Brian Quinlan sweetapp.com> writes:
I don't see why this is helpful. Could you explain why
_RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python version.
I suppose it's so that people who only override flush()
On 05/04/2009 12:27, Antoine Pitrou wrote:
There's also the issue of how we adapt the current workflow of "svnmerging"
between branches when we want to back- or forward-port stuff. In particular,
tracking of already done or blocked backports.
Right. The canonical way to do that with Mercurial i
Nick Coghlan gmail.com> writes:
>
> Parts 2 and 3, being the memoryview API and support for the new protocol
> in the builtin types are the parts that are currently restricted to
> simple linear memory views.
>
> That's largely because parts 2 and 3 are somewhat use case challenged:
> the key mo
Brian Quinlan sweetapp.com> writes:
>
> I don't see why this is helpful. Could you explain why
> _RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python version.
I suppose it's so that people who only override flush() automatically get
Alexandre Vassalotti peadrop.com> writes:
>
> Off the top of my head, the following is needed for a successful migration:
There's also the issue of how we adapt the current workflow of "svnmerging"
between branches when we want to back- or forward-port stuff. In particular,
tracking of already d
Alexandre Vassalotti peadrop.com> writes:
>
> I am not sure if this is a good idea. Currently, the argument of
> peek() is documented as a lower bound that cannot exceed the size of
> the buffer:
Unfortunately, in practice, the argument is neither a lower bound nor an upper
bound. It's just used
On 05/04/2009 11:06, "Martin v. Löwis" wrote:
In particular, the Stackless people have requested that they move along
with what core Python does, so their code should also be converted.
I'd be interested to hear if they want all of their stuff converted, or
just the mainline/trunk of what is c
On 05/04/2009 02:44, "Martin v. Löwis" wrote:
> I'm personally happy letting you do that (although I do wonder who would
> then be in charge of the Mercurial installation in the long run, the way
> I have been in charge of the subversion installation).
I'd be happy to commit to that for the fores
On 05/04/2009 07:55, Alexandre Vassalotti wrote:
- Verify that the repository at http://code.python.org/hg/ is
properly converted.
I'm pretty sure that we'll need to reconvert; I don't think the current
conversion is particularly good. We'll also have to decide on named
branches vs. clone
>
>
> Not sure what this means. There is currently svn support insofar as the
> tracker can format rNNN references into ViewCVS links; this should be
> updated if possible (removed if not). There would also be a possibility
> to auto-close issues from the commit messages. This is not done
> current
On Sun, 2009-04-05 at 18:08 +0900, Stephen J. Turnbull wrote:
> Steve Holden writes:
>
> > Not only that, but the Cygwin packaging system appears to be extremely
> > difficult to organize a package for.
>
> Really? I Don't Do Windows[tm], but the people who did installers and
> stuff for XEmac
On Sun, Apr 5, 2009 at 6:06 PM, "Martin v. Löwis" wrote:
>> Off the top of my head, the following is needed for a successful migration:
>>
>> - Verify that the repository at http://code.python.org/hg/ is
>> properly converted.
>
> I see that this has four branches. What about all the other bran
Hey Antoine,
Thanks for the clarification!
I see that the C implementation matches the Python implementation but I
don't see how the semantics of either are useful in this case.
If a subclass implements flush then, as you say, it must also implement
close and call flush itself before calling
> Off the top of my head, the following is needed for a successful migration:
>
>- Verify that the repository at http://code.python.org/hg/ is
> properly converted.
I see that this has four branches. What about all the other branches?
Will they be converted, or not? What about the stuff outsi
Nick Coghlan wrote:
Actually *finishing* parts 2 and 3 of PEP 3118 would be a good precursor
to having some kind of multi-dimensional mathematics in the standard
library though.
Even if they only work on the existing one-dimensional
sequence types, elementwise operations would still be
useful
Steve Holden writes:
> Not only that, but the Cygwin packaging system appears to be extremely
> difficult to organize a package for.
Really? I Don't Do Windows[tm], but the people who did installers and
stuff for XEmacs releases never had problems with it. It was much
more painful to create t
Antoine Pitrou wrote:
> Greg Ewing canterbury.ac.nz> writes:
>> So you're saying the buffer interface *has* been fully
>> implemented, it just hasn't been tested very well?
>
> No, it hasn't been implemented for multi-dimensional types, and it hasn't been
> really tested for anything other than p
90 matches
Mail list logo
