On Sat, Apr 4, 2009 at 9:03 PM, Antoine Pitrou solip...@pitrou.net wrote:
Hello,
Currently, BufferedReader.peek() ignores its argument and can return more or
less than the number of bytes requested by the user. This is how it was
implemented in the Python version, and we've reflected this in
Hello,
I would like to call to your attention the following behavior of TextIOWrapper:
import io
def test(buf):
textio = io.TextIOWrapper(buf)
buf = io.BytesIO()
test(buf)
print(buf.closed) # This prints True currently
The problem here is TextIOWrapper closes its buffer
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
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
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 outside
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
On Sun, Apr 5, 2009 at 6:06 PM, Martin v. Löwis mar...@v.loewis.de 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
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 XEmacs
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
currently, so
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.
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
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
Alexandre Vassalotti alexandre at 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
Alexandre Vassalotti alexandre at 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
Brian Quinlan brian at 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
Nick Coghlan ncoghlan at 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
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 is
Antoine Pitrou wrote:
Brian Quinlan brian at 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
Dirkjan Ochtman dirkjan at 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,
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
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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
2009/4/5 Antoine Pitrou solip...@pitrou.net:
Nick Coghlan ncoghlan at 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
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
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 canonical way
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
On Sun, Apr 5, 2009 at 5:06 AM, Martin v. Löwis mar...@v.loewis.de 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
2009/4/5 Alexandre Vassalotti alexan...@peadrop.com:
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
2009/4/5 Dirkjan Ochtman dirk...@ochtman.nl:
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
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
On Sun, Apr 5, 2009 at 6:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
Alexandre Vassalotti alexandre at 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
(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
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
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 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
Dirkjan Ochtman dirkjan at 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
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
2009/4/5 Antoine Pitrou solip...@pitrou.net:
Dirkjan Ochtman dirkjan at 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
On Apr 5, 2009, at 6:29 AM, Antoine Pitrou wrote:
Brian Quinlan brian at 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
-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:
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
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 (or
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 package
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 volunteered,
James Y Knight foom at 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
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
just the
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
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
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
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 waterfall default
-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
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
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 removing
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 enough
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 annoying for things
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,
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 can
Georg Brandl g.brandl at 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
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 hg
Antoine Pitrou schrieb:
Georg Brandl g.brandl at 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
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 from a repo
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
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
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
Antoine Pitrou wrote:
James Y Knight foom at 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
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
Greg Ewing wrote:
rant subject=terminology
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
Greg Ewing greg.ewing at 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.
___
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 them
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 decision to have
On Sun, Apr 5, 2009 at 3:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
Antoine Pitrou wrote:
James Y Knight foom at 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
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
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
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 maybe
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.
Skip
On Sun, Apr 5, 2009 at 10:50 PM, s...@pobox.com 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
On Sun, Apr 5, 2009 at 1:37 PM, Martin v. Löwis mar...@v.loewis.de 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
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 commit
On Sun, Apr 5, 2009 at 2:45 PM, Dirkjan Ochtman dirk...@ochtman.nl 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
On Sun, Apr 5, 2009 at 2:40 PM, Martin v. Löwis mar...@v.loewis.de 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
On Mon, Apr 6, 2009 at 12:20 AM, Aahz a...@pythoncraft.com 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
80 matches
Mail list logo
