Re: [Python-Dev] Possible py3k io wierdness
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 suppose it's so that people who only override flush() automatically get the flush-on-close behaviour. 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. Are you imagining something like this? class RawIOBase(object): def flush(self): pass def _internal_close(self): pass def close(self): self.flush() self._internal_close() class FileIO(RawIOBase): def _internal_close(self): # Do close super()._internal_close() class SomeSubclass(FileIO): def flush(self): # Do flush super().flush() def _internal_close(self): # Do close super()._internal_close() That looks pretty good. RawIOBase.close acts as the controller and .flush() calls move up the class hierarchy. The downsides that I see: - you need the cooperation of your subclasses i.e. they must call super().flush() in .flush() to get correct close behavior (and this represents a backwards-incompatible semantic change) - there is also going to be some extra method calls Another approach is to get every subclass to deal with their own close semantics i.e. class RawIOBase(object): def flush(self): pass def close(self): pass class FileIO(RawIOBase): def close(self): # Do close super().close() class SomeSubclass(FileIO): def _flush_internal(self): # Do flush def flush(self): self._flush_internal() super().flush() def close(self): FileIO._flush_internal(self) # Do close super().close() I was thinking about this approach when I wrote this patch: http://bugs.python.org/file13620/remove_flush.diff But I think I like your way better. Let me play with it a bit. Cheers, Brian ___ 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
Re: [Python-Dev] Mercurial?
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 made clear that this is > not wanted. So an alternative approach is to add a interface > accessible via SSH. As I previously mentioned, this is the approach > used by Mozilla. The easier solution here is to just allow normal local-to-remote clones. hg supports commands like hg clone . ssh://h...@hg.python.org/my-branch without the need for any extra scripts or setup. I think that would be a good start. > 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 to. Or we could drink the > kool-aid and go with a kernel-style development workflow—i.e., each > developer maintains his own branch and pull changes from each others. The differences between these workflows aren't all that big, i.e. it's not like there's a big schisma between them. But I suspect that, in a setup where buildbots are important, a very much multi-repo setup probably isn't a good idea (this is also why Mozilla doesn't use that many repos; their continuous integration infra is /very/ important to them). Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 course you could drop the other stuff right after branching it, but that would kind of defy the point of branching (since you won't really be able to merge later on). This is why it might be interesting to just split out the stdlib entirely. Though maybe we should wait for Mercurial's subrepos support to arrive before we go there (so we can a CPython repo that has the stdlib repo included automatically). Something like that is already provided by the forest extension, but it's not being maintained. Subrepo support is slated for the 1.3 release, which is planned for early July. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 details. So we'll explain how to configure that in the .hgrc/Mercurial.ini file that people will have to create anyway. Alternatively, we do it the way Mozilla has done and let everyone clone/pull over http and push over ssh. Then everyone always gets compression for the big clones/pulls, pushes are a little slower (but they aren't usually that large), and people who don't have push access already have the right setup. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 agreement anyway, there's already some list out there that we can leverage. The other option is to play the consenting adults card and ask all people with push access to ascertain the correct names of committer names on patches they push. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 more, it's still quite easy to cope with. This would also be one of the arguments *for* named branches, I suppose. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 checked those. > I'm listed twice: > > mark.hammond = Mark Hammond > mhammond = Mark Hammond > > but that email address isn't the address normally associated with any > checkins I make, nor the address in the comments of the ssh keys I use > (which is mhamm...@skippinet.com.au) Your being listed twice is normal; both mark.hammond and mhammond have been used in the commit history, and I just assumed they're both you. I'll probably change your email address to be the one associated with the checkins/public key, though. Is there a list of such email addresses? I just parsed python-dev archives to get to my list. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 declaring a volunteer to maintain the main repositories and ask core developers to avoid committing directly to them. Cheers, -- Alexandre ___ 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
Re: [Python-Dev] Mercurial?
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 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 details. -- Alexandre ___ 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
Re: [Python-Dev] Mercurial?
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 usernames include one of those names and an email address (so > people can still start using another email address). > 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. -- Alexandre ___ 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
Re: [Python-Dev] Mercurial?
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 to. Or we could drink the > kool-aid and go with a kernel-style development workflow?i.e., each > developer maintains his own branch and pull changes from each others. 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? -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons." --Aahz ___ 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
Re: [Python-Dev] Mercurial?
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 history here. IIUC, the Debian bugtracker understands > > Closes: #4532 > > and some other syntaxes. It must be easy to remember, else people > won't use it. > That should reasonable. Personally, I don't really care about the syntax we would use as long its consistent and documented. > 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) > I know Netbeans has Mercurial support built-in (which makes sense because Sun uses Mercurial for its open-source projects). However, I am not sure if Eclipse has good Mercurial support yet. There are 3rd-party plugins for Eclipse, but I don't know if they work well. > Ok, I take that back. I assumed that Mercurial could work *exactly* > as Subversion. Apparently, that's not the case (although I have no > idea what a server-side clone is). So I wait for the PEP to explain > how authentication and access control is to be implemented. Creating > individual Unix accounts for committers should be avoided. With Subversion, we can do a server-side clone (or copy) using the copy command: svn copy SRC_URL DEST_URL This prevents wasting time and bandwidth by doing the copy directly on server. Without this feature, you would need to checkout the remote repository to clone, then push it to a different location. Since upload bandwidth is often limited, creating new branch in a such fashion would be time consuming. 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 made clear that this is not wanted. So an alternative approach is to add a interface accessible via SSH. As I previously mentioned, this is the approach used by Mozilla. Yet another approach would be to add a web interface for managing the repositories. This what OpenSolaris admins opted for. Personnally, I do not think this a good idea because it would requires us to roll our own authentication mechanism which is clearly a bad thing (both security-wise and usability-wise). 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 to. Or we could drink the kool-aid and go with a kernel-style development workflow—i.e., each developer maintains his own branch and pull changes from each others. From what I have heard, the CVS-style workflow has a lower overhead than the kernel-style workflow. However the kernel-style workflow somehow advantageous because changes get reviewed several times before they get in the main branches. Thus, it is less likely that someone manage to break the build. In addition, Mercurial is much better suited at supporting the kernel-style workflow. However if we go kernel-style, I will need to designate someone (i.e., an integrator) that will maintain the main branches, which will tested by buildbot and used for the public releases. These are issues I would like to address in the PEP. > I can give you access to the master setup. Ideally, this should > be tested before the switchover (with a single branch). We also > need instructions for the slaves (if any - perhaps installing > a hg binary is sufficient). > I am not too familiar with our buildbot setup. So, I will to do some reading before actually doing any change. You can give me access to the buildbot master now. However, I would use this access only to study how the current setup works and to plan the changes we need accordingly. >> Since the directories in /external are considered read-only, we could >> simply a new Mercurial repository and copy the content of /external in >> it. >>> - decide what to do with the bzr mirrors >>> >> >> I don't see much benefits to keep them. > > Both should go into the PEP. Noted. Regards, -- Alexandre ___ 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
Re: [Python-Dev] Tools
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 can pick up external > maintenance if desired. I liked Brett's (Georg's?) half joking idea at sprints. Just delete each subdirectory in a separate commit and then wait to see what people revert. -Jack ___ 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
Re: [Python-Dev] Tools
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 ___ 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
Re: [Python-Dev] Mercurial?
>> 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 twice. Maybe once for each currently active Subversion branch (2.6, 2.7, 3.0, 3.1)? Skip ___ 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
Re: [Python-Dev] Mercurial?
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 with my little lockfile module, so the damage was very isolated. (And perhaps "damage" is the wrong word. Someone more experienced with hg could almost certainly correct my mistakes.) I freely admit that my own misunderstanding of how Mercurial works was the primary cause of my problems. Still, until people are real familiar with what is going on, especially people like me who have little or no familiarity with dVCSs I think it's best to just treat it like Subversion if at all possible. Skip ___ 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
Re: [Python-Dev] Possible py3k io wierdness
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 before closing, and make that the responsibility of the derived class. -- Greg ___ 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
Re: [Python-Dev] Possible py3k io wierdness
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 class as "self.flush();
> >> self._internal_close()" and never overridden.
> >
> > I'm completely open to changes as long as there is a reasonable consensus
> around
> > them. 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.
>
> Note that we already do that in a couple of places where it makes sense
> - in those cases the underscore is there to tell *clients* of the class
> "don't call this directly", but it is still explicitly documented as
> part of the subclassing API.
>
> (the only example I can find at the moment is in asynchat, but I thought
> there were a couple of more common ones than that - hopefully I'll think
> of them later)
>
Queue.Queue in 2.* (and queue.Queue in 3.*) is like that too -- the single
leading underscore meaning "protected" ("I'm here for subclasses to override
me, only" in C++ parlance) and a great way to denote "hook methods" in a
Template Method design pattern instance. Base class deals with all locking
issues in e.g. 'get' (the method a client calls), subclass can override _get
and not worry about threading (it will be called by parent class's get with
proper locks held and locks will be properly released &c afterwards).
Alex
___
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
Re: [Python-Dev] Mercurial?
"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 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) I can spend some time on Mercurial integration for the main IDEs in use by core devs, I'm sure the PIDA folks have most of this sorted already. It would be important to have these (and any other non-PEP worthy tasks/helpers) listed with some detail, e.g., in a wiki page. If anyone has requests for tools that would make the transition smoother (e.g. the script for /external, a wrapper for svnmerge semantics on top of hg transplant, etc.) but has no time to work on them, please add them to http://wiki.python.org/moin/CoreDevHelperTools . Daniel ___ 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
Re: [Python-Dev] Tools
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 from both > the Python 2.x and 3.x trunks? +1, but please for 2.7 and 3.1 only. ___ 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
Re: [Python-Dev] graphics maths types in python core?
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 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
Re: [Python-Dev] graphics maths types in python core?
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 is > one among many. > Probably because memoryview *is* the Python API for the C-level buffer interface. While I can understand that point of view, I don't agree with it, which is why I consider it important to point out that memoryview's limitations aren't shared by the underlying API when the topic comes up. /tangent from the vector math thread (hopefully) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] Generator methods - "what's next" ?
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 part of the iterator protocol that applies to all iterators, whereas the others are specific to generators. By your reasoning, any object that has any __xxx__ methods should have all its other methods turned into __xxx__ methods as well. -- Greg ___ 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
Re: [Python-Dev] Possible py3k io wierdness
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 never overridden. > > I'm completely open to changes as long as there is a reasonable consensus > around > them. 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. Note that we already do that in a couple of places where it makes sense - in those cases the underscore is there to tell *clients* of the class "don't call this directly", but it is still explicitly documented as part of the subclassing API. (the only example I can find at the moment is in asynchat, but I thought there were a couple of more common ones than that - hopefully I'll think of them later) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] Mercurial?
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 Hammond but that email address isn't the address normally associated with any checkins I make, nor the address in the comments of the ssh keys I use (which is mhamm...@skippinet.com.au) The addresses given are valid though, so I'm not sure what kind of review or feedback you are after. Cheers, Mark ___ 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
Re: [Python-Dev] graphics maths types in python core?
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 even without memoryview at all. Mostly you would just use them directly on array.array or other sequence types. 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 is one among many. -- Greg ___ 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
Re: [Python-Dev] Possible py3k io wierdness
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 all. If someone overrides flush() but not close(), their flush method won't get called, which would be surprising. To get the desired behaviour, you need something like def close(self): if not self.__closed: self.flush() self._close() self.__closed = True and then tell people to override _close() rather than close(). -- Greg ___ 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
Re: [Python-Dev] Mercurial?
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 or imported >> via hg import? > > Not sure. What is the recommendation? > > Ideally, we would have a contributor agreement on file of any, well, > contributor. Well, in theory it shouldn't make a difference if a contributed patch is committed by a committer under his name (and the contributor's name mentioned in the commit message), or if the patch is committed under the contributor's name. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Python-Dev] Mercurial?
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-do all the commits, or can you just commit the > whitespace fixes separately? Probably yes. I was just painting the devil on the wall :) At PyCon, I already wrote the pre-commit hook. And what's best, since it runs locally it can fix the files for you instead of just bitching around... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Python-Dev] Mercurial?
>> 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 import? Not sure. What is the recommendation? Ideally, we would have a contributor agreement on file of any, well, contributor. 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
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 commit the whitespace fixes separately? ___ 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
Re: [Python-Dev] Mercurial?
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 a PEP was modified >> (but then, whether or not the PEPs will be maintained >> in hg also needs to be decided) > > All this is easy to do with Mercurial's hook system. One caveat is that > stuff (like whitespace) only gets checked at push time, not at commit > time (running commit hooks would have to be done on the client, but > since we don't sandbox hooks, they would be a liability to distribute by > default). People could still set them up locally for pre-commit if they > want, of course, but otherwise they may need some trickery to modify the > changesets they want to push. 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 :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Python-Dev] Mercurial?
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 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 import? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Python-Dev] Tools
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 projects > (retaining the PSF license). Should I remove them from both the Python 2.x > and 3.x trunks? +1 to removing some of the old unused stuff from those directories. -- Regards, Benjamin ___ 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
Re: [Python-Dev] Mercurial?
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 still start using another email address). In the long run, the current trunk may cease to exist, and the py3k branch may take over its role. Not sure whether this needs to be considered. I considered that in some other subthread. :) Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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, whether or not the PEPs will be maintained in hg also needs to be decided) All this is easy to do with Mercurial's hook system. One caveat is that stuff (like whitespace) only gets checked at push time, not at commit time (running commit hooks would have to be done on the client, but since we don't sandbox hooks, they would be a liability to distribute by default). People could still set them up locally for pre-commit if they want, of course, but otherwise they may need some trickery to modify the changesets they want to push. For the email messages, we'll probably want to use the notify extension that comes with hg. How to authenticate in that interface? We don't have passwords per committer. Okay, so we'll use ssh. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
>> 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 like annotate/blame, for > example, where you may have to switch to another branch while chasing > down a defective change. FWIW, I also think that all branches should go back to the very beginning. > 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? 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
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 for most of the interested parties. ;) Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
> 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? > At the very least we should have a proper discussion over this. If so, I would like to see that discussion in the PEP. I don't think I can personally contribute to that discussion. I will have to trust that whatever Mercurial experts propose is good. > The current Mercurial mirror for py3k also doesn't include any history > from before it was branched, which is bad, IMO. In order to get the most > of the DVCS structure, it would be helpful if py3k shared history with > the normal (trunk) branches. In the long run, the current trunk may cease to exist, and the py3k branch may take over its role. Not sure whether this needs to be considered. >> Not really. Currently, core developers can only push stuff using the >> Bazaar setup. Personally, I think SSH access would be a lot nicer, but >> this will depend how confident python.org's admins are with this idea. If it's the same as the current subversion access, it's fine. Otherwise, it needs discussion. > We could still enable pushing through http(s) for hgweb(dir). But that would require to hand out (and manage) passwords, right? 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
> 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 very old history; it's still useful to find out that some change goes back to 1994. I'm -0 on removing old branches (your 18 month policy sounds reasonable). >> - Convert the current svn commit hooks to Mercurial. > > Some new hooks should also be discussed. For example, Mozilla uses a > single-head hook, to prevent people from pushing multiple heads. They > also have a pushlog extension that keeps a SQLite database of what > people pushed. This is particularly useful for linearizing history, > which is required for integration with buildbot infrastructure. 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, whether or not the PEPs will be maintained in hg also needs to be decided) >> - Augment code.python.org infrastructure to support the creation of >> developer accounts. > > Developers already have accounts, don't they? Depends on the term "account". There is a mapping ssh-key <-> logname. > In any case, some web > interface to facilitate setting up new clones (branches) is also > something that's probably desirable. I think Mozilla has some tooling > for that which we might be able to start off of. How to authenticate in that interface? We don't have passwords per committer. 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
> 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 svn). The PEP should then explain what the authorized_keys lines should look like; this allows people to review the security of the setup. 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/archive%40mail-archive.com
[Python-Dev] Tools
-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). Should I remove them from both the Python 2.x and 3.x trunks? Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdj2S3EjvBPtnXfVAQJvkAQAhj/Go+OtfYP//OZ7HIHwTjaeMlpAkfwn iPxE6O8gY0K48J1AUmjvGSeckfP4FRqVJWOVMQYvX8yTHNFnCJxDSl4JjgboqLz4 s/IvrUYjSiN1FGrQJBA3RI4jFmuetzmKxNWgi6gEzQ6ocTLC80EyCHhxsAMhCeqr SGQ+Alrewis= =ODWt -END 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
Re: [Python-Dev] Mercurial?
>> 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 page gone? I had that in my 0.7.9 setup, at > least. Provided the 0.7.5 slaves work with 0.7.10, then no, it's not > necessary to upgrade the slaves. The problem in buildbot was strictly > with the change detection in hg repos (combined with the Mercurial API, > which hasn't entirely become stable -- so it changed a bit in 1.1). My understanding is that with 0.7.6 and later, the default page won't be the waterfall anymore. In the 0.7.6 release notes, it says # The initial page (when you hit the root of the web site) is served # from index.html, and provides links to the Waterfall as well as the # other pages. In the 0.7.9 release notes, it says # The html.Waterfall status target was replaced by html.WebStatus in # 0.7.6, and will be removed by 0.8.0. But then, I have not tried installing it, so I don't know what it actually looks like. 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
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 should be good support for Eclipse (through MercurialEclipse), NetBeans (they use hg themselves, after all), and the IDE-version of Komodo 5.0+ also includes hg support. I suppose other, more Python-specific IDEs might be following suit as Python switches. Ok, I take that back. I assumed that Mercurial could work *exactly* as Subversion. Apparently, that's not the case (although I have no idea what a server-side clone is). So I wait for the PEP to explain how authentication and access control is to be implemented. Creating individual Unix accounts for committers should be avoided. 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. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 upgrade. Why is the waterfall default page gone? I had that in my 0.7.9 setup, at least. Provided the 0.7.5 slaves work with 0.7.10, then no, it's not necessary to upgrade the slaves. The problem in buildbot was strictly with the change detection in hg repos (combined with the Mercurial API, which hasn't entirely become stable -- so it changed a bit in 1.1). Take a look at the batch files in Tools/buildbot - they are the primary consumers. PCbuild/readme.txt also refers to it. Will do. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
> 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 > Distutils tags). Are there any other particularly useful tags we should > keep? First of all, if the conversion is incomplete, the PEP should make explicit what information will be lost. As for tags - I think providing just the release tags is fine. > BTW, this would also be a good time to split out the stdlib if that's > still desirable (which I seem to have gleaned from the PyCon videos). 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. 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
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 mainline/trunk of what is currently in trunk/branches/tags. Richard Tew would be the person discuss the details with. >> - integrate with the buildbot > > I've setup the buildbot infra for Mercurial (though not many people are > interesting in it, so it's kind of languished). Using buildbot's hg > support is easy. 0.7.10 is the first version which works with hg 1.1+, > though, so we probably don't want to go with anything earlier. 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. >> - 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 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 (repository) + tag, which can then be easily pulled in. > > But it'd be nice to know where and how exactly this is used. Take a look at the batch files in Tools/buildbot - they are the primary consumers. PCbuild/readme.txt also refers to it. 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/archive%40mail-archive.com
Re: [Python-Dev] Possible py3k io wierdness
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 completely open to changes as long as there is a reasonable consensus around them. 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. I'd also like to have some advice from Guido, since he was one of the driving forces behind the specification and the original Python implementation. Regards Antoine. ___ 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
Re: [Python-Dev] Mercurial?
> 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, you two need to decide who is in charge. Whoever does that will certainly get access to code.python.org; the demo installation should run on that machine. 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
>> 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 >> (repository) + tag, which can then be easily pulled in. >> >> But it'd be nice to know where and how exactly this is used. > > Basically it contains released versions of packages that some parts of > Python depend on. For example, Sphinx dependencies to build the docs > reside their. A simple script that downloads a tarball and extracts it > seems more elegant. Such a script would, in particular, also have to work on the Windows buildbot slaves. /external is primarily used for the Window build. 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
> 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 a simple to use script could be provided and > developer could run it directly on the server to create a user > branch). 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. > An auto-close would be a nice feature, but, as you said, not necessary > for the migration. The main stumbling block to implement an auto-close > feature is to define when an issue should be closed. Maybe we could > add our own meta-data to the commit message. For example: > >Fix some nasty bug. > >Close-Issue: 4532 > > When a such commit would arrive in one of the main branches, a commit > hook would close the issue if all the affected releases have been > fixed. I think there is a long tradition of such annotations; we should try to repeat history here. IIUC, the Debian bugtracker understands Closes: #4532 and some other syntaxes. It must be easy to remember, else people won't use it. >>>- Setup temporary svn mirrors for the main Mercurial repositories. >> What is that? >> > > 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 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) >>>- Augment code.python.org infrastructure to support the creation of >>> developer accounts. >> One option would be to carry on with the current setup; migrating it >> to hg might work as well, of course. >> > > You mean the current setup for svn.python.org? Would you be > comfortable to let this machine be accessed by core developers through > SSH? Since with Mercurial, SSH access will be needed for server-side > clone (or, a script similar to what the Mozilla folk have [1] could be > added). > > [1]: https://developer.mozilla.org/en/Publishing_Mercurial_Clones Ok, I take that back. I assumed that Mercurial could work *exactly* as Subversion. Apparently, that's not the case (although I have no idea what a server-side clone is). So I wait for the PEP to explain how authentication and access control is to be implemented. Creating individual Unix accounts for committers should be avoided. >> - integrate with the buildbot > > Good one. It seems buildbot has support for Mercurial. [2] So, this > will be a matter of tweaking the right options. The batch scripts in > Tools/buildbot will also need to be updated. > > [2]: > http://djmitche.github.com/buildbot/docs/0.7.10/#How-Different-VC-Systems-Specify-Sources I can give you access to the master setup. Ideally, this should be tested before the switchover (with a single branch). We also need instructions for the slaves (if any - perhaps installing a hg binary is sufficient). > Since the directories in /external are considered read-only, we could > simply a new Mercurial repository and copy the content of /external in > it. >> - decide what to do with the bzr mirrors >> > > I don't see much benefits to keep them. Both should go into the PEP. 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/archive%40mail-archive.com
Re: [Python-Dev] Generator methods - "what's next" ?
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 methods of the generator had
> stayed the same (send, throw, close...), which gives really weird (imo)
> codes :
>
>next(it)
>it.send(35)
>it.throw(Exception())
>next(it)
>
>
> Browsing the web, I've found people troubled by that asymmetry, but no
> remarks on its causes nor its future...
Well, this kind of discussion generally belongs on c.l.py, but as far
as I know, .next() is still present for generators but it's spelled
.send(None). See PEP 342. It seems to me that the rationale for
respelling .next() as .__next__() given in PEP 3114 doesn't apply to
.send() and .throw(), since there is no syntax which invokes those
methods magically.
Also note that since next() takes no argument, it presumes no
knowledge of the implementation of the iterator. So specification as
a function called "on" the iterator seems natural to me. But .send()
and .throw() are only useful if you know the semantics of their
arguments, ie, the implementation of the generator. Thus using method
syntax for them seems more natural to me.
If you have some concrete suggestions you want to follow up to
Python-Dev with, two remarks:
The code presented above is weird because that code is weird, not
because the generator methods are messed up. Why would you ever write
that code? You need a plausible use case, one where a generator is
the natural way to write the code, but it's not explicitly iterative.
Second, the whole trend is the other direction, fitting generators
naturally into Python syntax without using explicit invocation of
methods. Again, PEP 380 is an example (though rather specialized).
As is the expression form of yield (half-successful in that no
recv() syntax or builtin is needed, although .send() seems to be). So
the use case requested above will need to be compelling.
Whoups, now that you mention it, I discover other mailing-lists seemed
more suitable for this subject... sorry
Actually I ran over an example like the following, in the case of a
"reversed generator" that has to be activated by a first call to "next",
before we're able to send data to the yield expression it has encountered.
But as you mention, send(None) would work as well, and this kind of
"setup operation" had better be hidden in a function decorator or
something like that.
>next(it) # init phase
>it.send(35)
>it.send(36)
Regards,
pascal Chambon
___
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
Re: [Python-Dev] Mercurial?
-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: GnuPG v1.4.9 (Darwin) iQCVAwUBSdjki3EjvBPtnXfVAQK2gAP8Duw+imZwZhsyGildHkUSeNW1uHazxbzL cKPeEfanSDUtkC51478/NC7+UxfNGdQJ4umo+LNiy6GXG3Kx7KCmYKHr6yBCzaxS 4HsuOVkFcjqn57u2eT9A5PDcxGgK4Os7XfB3kMS/f1xlBPYsF7W4Qpdck8gTbL+i dXJnq/+rd6k= =QSw3 -END 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
Re: [Python-Dev] Possible py3k io wierdness
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 people who only override flush() automatically get the flush-on-close behaviour. 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. James ___ 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
Re: [Python-Dev] Mercurial?
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 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 have different experiences, though. I agree with Dirkjan. > > 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. I suppose this is me. Cloning the hg trunk repo only takes slightly longer than an svn checkout for me, and it only needs to be done occasionally, so I have no problem with including all the history. -- Regards, Benjamin ___ 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
Re: [Python-Dev] Mercurial?
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 have different experiences, though. 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. Sure it's painful, but he only has to go through that once, maybe twice. The consensus seems to be that it will not happen before a couple of years. See, I think the point here is that, even though you want the branches to be clones, you also want them to all be part of the same directed acyclic graph (that DAG thing I keep nattering on about). That way, you can later merge every branch back in to some other branch (even if it's trivial merge that doesn't keep anything from one of the branches). Even if that's not for a couple of years, it's nice when you'll be able to do it in a couple of years without changing all the hashes (meaning everybody has to re-clone). For any dial-up providers, we could for example provide a repository that just has the changesets up to the split between trunk and py3k. He can clone that once, clone it locally, then pull the rest of the respective history in those local clones. If you don't have common history, a few of the niceties of having a DAG-based DVCS in the first place go away; that seems like a pity. Does the hg protocol compress that good? I would have thought there is already a lot of compression in the layout (given that it seems much more efficient than some of its competitors). When used over HTTP, hg uses bundles (which can also be used as separate file to exchange changesets informally). Bundles contain gzip- or bzip2-compressed csets. When communicating over SSH, on the other hand, hg defaults to uncompressed streams, because the assumption is that connections can use SSH's compression, which is more efficient. All of this functions on top of the already quite efficient revlogs that make up the basic storage model for hg. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 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 have different experiences, though. 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. > Also, at some point you > presumably want to deprecate the whole 2.x line, right? The consensus seems to be that it will not happen before a couple of years. > Okay, sounds like that will be easy. Would be good to enable compression > on the SSH, though, if that's not already done. Does the hg protocol compress that good? I would have thought there is already a lot of compression in the layout (given that it seems much more efficient than some of its competitors). Regards Antoine. ___ 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
Re: [Python-Dev] Mercurial?
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 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 like annotate/blame, for example, where you may have to switch to another branch while chasing down a defective change. 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). Also, at some point you presumably want to deprecate the whole 2.x line, right? So at that point, it'd be nice to have a full 3.x line with all the history in it, so that you can just throw away the 2.x stuff and still have full history. I do agree that 2.x and 3.x should probably be in separate clones. Is any SVN-to-hg conversion tool able to parse the commits produced by svnmerge? And, even then, turn that information into useful hg information (say, transplant metadata of which changes were ported)? I think things are these are planned for hgsubversion, yes. I'd probably want to look at implementing some support for it myself if that makes the conversion of the Python repositories better. I'm not sure what the problem is. Developer SVN access already goes through ssh. Okay, sounds like that will be easy. Would be good to enable compression on the SSH, though, if that's not already done. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 workable for the CPython repo, which is too big), and there are no cases of SVN revisions being either ignored or split between several hg changesets (for example because they span multiple branches). 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. > 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. Good idea. [in-repo multiple branches] > No, the Mercurial project currently doesn't use them. Mozilla does use > them at the moment, because they found they did have some advantages > (especially lower disk usage because no separate clones were needed). I > think named branches are fine for long-lived branches. > > At the very least we should have a proper discussion over this. 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). > The current Mercurial mirror for py3k also doesn't include any history > from before it was branched, which is bad, IMO. Given how much separate work has taken place in both, I'm not sure having that history would be very useful. We have to take into account practical needs. Someone needing to search history before py3k was created can just do a clone of the trunk. > In order to get the most > of the DVCS structure, it would be helpful if py3k shared history with > the normal (trunk) branches. Is any SVN-to-hg conversion tool able to parse the commits produced by svnmerge? And, even then, turn that information into useful hg information (say, transplant metadata of which changes were ported)? > > Not really. Currently, core developers can only push stuff using the > > Bazaar setup. Personally, I think SSH access would be a lot nicer, but > > this will depend how confident python.org's admins are with this idea. > > We could still enable pushing through http(s) for hgweb(dir). I'm not sure what the problem is. Developer SVN access already goes through ssh. cheers Antoine. ___ 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
Re: [Python-Dev] Mercurial?
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 branch to be imported into a Mercurial branch (or a simple to use script could be provided and developer could run it directly on the server to create a user branch). 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 Distutils tags). Are there any other particularly useful tags we should keep? An auto-close would be a nice feature, but, as you said, not necessary for the migration. The main stumbling block to implement an auto-close feature is to define when an issue should be closed. Maybe we could add our own meta-data to the commit message. For example: Fix some nasty bug. Close-Issue: 4532 When a such commit would arrive in one of the main branches, a commit hook would close the issue if all the affected releases have been fixed. It makes more sense to me to use the syntax already used by Trac et al., e.g. "(fix|close)s? (issue|#)\d+" for closing and possibly "ref(erence)?s? (issue|#)\d+" for creating a link on the issue. BTW, this would also be a good time to split out the stdlib if that's still desirable (which I seem to have gleaned from the PyCon videos). Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
(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 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. On top of that, good conversion tools save the svn revision in the revision metadata in hg, so that you can see it with log --debug. 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. 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. I largely prefer clone to named branches. From personal experience, I found named branches difficult to use properly. And, I think even Mercurial developers don't use them. No, the Mercurial project currently doesn't use them. Mozilla does use them at the moment, because they found they did have some advantages (especially lower disk usage because no separate clones were needed). I think named branches are fine for long-lived branches. At the very least we should have a proper discussion over this. How do you reorder the revlog of a repository? There are scripts for this which can be investigated. I am in favor of pruning the old branches, but not of leaving the old history behind. The current Mercurial mirror of py3k is 92M on my disk which is totally reasonable. So, I don't see what would be the advantage there. The current Mercurial mirror for py3k also doesn't include any history from before it was branched, which is bad, IMO. In order to get the most of the DVCS structure, it would be helpful if py3k shared history with the normal (trunk) branches. I was thinking of something very basic—e.g., something like a commit hook that would asynchronously commit the latest revision to svn. We wouldn't to keep convert much meta-data just the committer's name and the changelog would be fine. What's the use case, who do you want to support with this? hgweb trivially provides tarballs for download on every revision, so people who don't want to use hg can easily download a snapshot. Not really. Currently, core developers can only push stuff using the Bazaar setup. Personally, I think SSH access would be a lot nicer, but this will depend how confident python.org's admins are with this idea. We could still enable pushing through http(s) for hgweb(dir). Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 back- or forward-port stuff. In particular, > tracking of already done or blocked backports. > > (the issue being that "svnmerge" is different from what DVCS'es call "merging" > :-)) > See the PEP about that. I have written a fair amount of details how this would work with Mercurial: http://www.python.org/dev/peps/pep-0374/#backport -- Alexandre ___ 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
Re: [Python-Dev] Generator methods - "what's next" ?
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 all the other methods of the generator had stayed the same (send, throw, close...), which gives really weird (imo) codes : next(it) it.send(35) it.throw(Exception()) next(it) Browsing the web, I've found people troubled by that asymmetry, but no remarks on its causes nor its future... Since __next__(), send() and others have really really close semantics, I consider that state as a python wart, one of the few real ones I can think of. You're missing an important detail: next()/__next__() is a feature of all iterators, while send() and throw() are generator-only methods. The only thing I could imagine is to add a generator.next() method that is simply an alias for generator.__next__(). However, TSBOOWTDI. cheers, Georg Good point indeed. Generator methods (send, throw...) are some kind of black magic compared to normal methods, so I'd find it normal if their naming reflected this specificity, but on the other end it wouldn't be cool to overflow the builtin scope with all the corresponding functions "send(iter, var)"... so I guess all that will stay the way it is. Regards, Pascal ___ 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
Re: [Python-Dev] Mercurial?
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 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 > (repository) + tag, which can then be easily pulled in. > > But it'd be nice to know where and how exactly this is used. Basically it contains released versions of packages that some parts of Python depend on. For example, Sphinx dependencies to build the docs reside their. A simple script that downloads a tarball and extracts it seems more elegant. -- Regards, Benjamin ___ 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
Re: [Python-Dev] Mercurial?
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.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial?
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 branches? > Will they be converted, or not? What about the stuff outside /python? > 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 a simple to use script could be provided and developer could run it directly on the server to create a user branch). > In particular, the Stackless people have requested that they move along > with what core Python does, so their code should also be converted. > Noted. >> - Add Mercurial support to the issue tracker. > > 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 I would not make it a prerequisite for the switch. > Yes, I was referring to the rNNN references. Actually, I am not sure how this could be implemented, since with Mercurial we lose atomic revision IDs. We could use something like h...@branch-name (e.g, bf94293b1...@py3k) referring to specific revision. An auto-close would be a nice feature, but, as you said, not necessary for the migration. The main stumbling block to implement an auto-close feature is to define when an issue should be closed. Maybe we could add our own meta-data to the commit message. For example: Fix some nasty bug. Close-Issue: 4532 When a such commit would arrive in one of the main branches, a commit hook would close the issue if all the affected releases have been fixed. >> - Setup temporary svn mirrors for the main Mercurial repositories. > > What is that? > 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. >> - Augment code.python.org infrastructure to support the creation of >> developer accounts. > > One option would be to carry on with the current setup; migrating it > to hg might work as well, of course. > You mean the current setup for svn.python.org? Would you be comfortable to let this machine be accessed by core developers through SSH? Since with Mercurial, SSH access will be needed for server-side clone (or, a script similar to what the Mozilla folk have [1] could be added). [1]: https://developer.mozilla.org/en/Publishing_Mercurial_Clones >> - Update the release.py script. >> >> There is probably some other things that I missed > > Here are some: > > - integrate with the buildbot Good one. It seems buildbot has support for Mercurial. [2] So, this will be a matter of tweaking the right options. The batch scripts in Tools/buildbot will also need to be updated. [2]: http://djmitche.github.com/buildbot/docs/0.7.10/#How-Different-VC-Systems-Specify-Sources > - come up with a strategy for /external (also relevant for > the buildbot slaves) Since the directories in /external are considered read-only, we could simply a new Mercurial repository and copy the content of /external in it. When a new release needs to be added, just create a new directory and commit. > - decide what to do with the bzr mirrors > I don't see much benefits to keep them. So, I say, archive the branches there unless someone step-up to maintain them. -- Alexandre ___ 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
Re: [Python-Dev] Generator methods - "what's next" ?
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 methods of the generator had > stayed the same (send, throw, close...), which gives really weird (imo) > codes : > >next(it) >it.send(35) >it.throw(Exception()) >next(it) > > > Browsing the web, I've found people troubled by that asymmetry, but no > remarks on its causes nor its future... > > Since __next__(), send() and others have really really close semantics, > I consider that state as a python wart, one of the few real ones I can > think of. You're missing an important detail: next()/__next__() is a feature of all iterators, while send() and throw() are generator-only methods. The only thing I could imagine is to add a generator.next() method that is simply an alias for generator.__next__(). However, TSBOOWTDI. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Python-Dev] Mercurial?
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 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. That's what I do as well in Sphinx. It works fine there, but there are two issues if you want to apply it to Python: * As Antoine said, trunk and py3k are very different. Merging would still be possible, but confusing. * Our current trunk/maint branches will have completely different commits, so pulling (e.g.) from 2.6 into trunk won't work. So I'd be in favor of a solution like the following: * Once 2.7 and 3.1 are final, create their maint branches as "real" Hg branches, so that for each pair committing to maint and pulling into trunk works. * For the 2->3 merging, use transplant (optionally with the mentioned feature of keeping track what was already transplanted and blocked). Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
[Python-Dev] Generator methods - "what's next" ?
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 stayed the same (send, throw, close...), which gives really weird (imo) codes : next(it) it.send(35) it.throw(Exception()) next(it) Browsing the web, I've found people troubled by that asymmetry, but no remarks on its causes nor its future... Since __next__(), send() and others have really really close semantics, I consider that state as a python wart, one of the few real ones I can think of. Is there any plan to fix this ? Either by coming back to the next() method, or by putting all the "magical methods" of generators in the __specialattributes__ bag ? next(it) send(it, 5) throw(it, Exception()) ... Thanks a lot for the information, Pascal ___ 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
Re: [Python-Dev] graphics maths types in python core?
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 understand correctly, one of the motivations behind memoryview() is to > replace buffer() as a way to get cheap slicing without memory copies (it's > used > e.g. in the C IO library). I don't know whether the third-party types > mentioned > above could also benefit from that. Well, PEP 3118 is useful because it would be nice having e.g. the possibility of opening an image with PIL, manipulate it directly with NumPy and saving it to file with PIL. Right now this is possible only if the PIL image is first converted (and copied) to a new NumPy array and then the array is converted back to an image. BTW, while PEP 3118 provides a common C API for this, the related PEP 368 proposes a standard "image protocol" on the Python side that should be compatible with the image classes of PIL, wxPython and pygame, and (mostly) with NumPy arrays. I started an implementation of PEP 368 at: http://code.google.com/p/pyimage/ Both the PEP and the implementation need updates (pyimage already includes an IEEE 754r compatible half-precision floating point type, aka float16, that's not yet in the PEP), but if someone is interested and willing to help I may start again working on them. Also note that the subjects "vec2, vec3, quaternion, etc" (PEP 3141) and "multi-dimensional arrays" (PEP 3118) are mostly unrelated. -- Lino Mastrodomenico ___ 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
Re: [Python-Dev] graphics maths types in python core?
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 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 understand correctly, one of the motivations behind memoryview() is to > replace buffer() as a way to get cheap slicing without memory copies (it's > used > e.g. in the C IO library). I don't know whether the third-party types > mentioned > above could also benefit from that. Yep, once memoryview supports all of the PEP 3118 semantics it should be usable with sufficiently recent versions of NumPy arrays and the like. It's implementation has unfortunately lagged because those with the most relevant expertise don't need it (they access the objects they care about through the C API), and there are some interesting semantics to get right which are hard to judge without that expertise. 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 - it's only if they try to use it with the more sophisticated aspects of the PEP 3118 API that people may be disappointed by its capabilities. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] Mercurial?
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 the original hashes, not the ones after transplant), and parse that file in order to compare it with the incoming changesets from an other repo) Transplant can already keep the source revision hash on the new revision (in hg's equivalent of generic revprops, the extra dict). I think that blocked revisions will not be an issue due to the nature of the DAG, but I have too little experience with svnmerge to say for sure. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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, which are wildly diverging. > In that case, there are a number of > alternatives. For example, hg's export/import commands can be used to > explicitly deal with diffs that contain hg metadata, the transplant > extension can be used to automate that, or in some cases, the rebase > extension might be more appropriate. 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 the original hashes, not the ones after transplant), and parse that file in order to compare it with the incoming changesets from an other repo) Regards Antoine. ___ 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
Re: [Python-Dev] Possible py3k io wierdness
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() automatically get the flush-on-close behaviour. But the way that the code is currently written, flush only gets called *after* the file has been closed (see my original example). It seems very unlikely that this is the behavior that the subclass would want/expect. So any objections to me changing IOBase (and the C implementation) to: def close(self): """Flush and close the IO object. This method has no effect if the file is already closed. """ if not self.__closed: try: -self.flush() +IOBase.flush(self) except IOError: pass # If flush() fails, just give up self.__closed = True Cheers, Brian ___ 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
Re: [Python-Dev] Mercurial?
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 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. From what I've understood, this doesn't fit the way the Python-dev community/process works very well. In that case, there are a number of alternatives. For example, hg's export/import commands can be used to explicitly deal with diffs that contain hg metadata, the transplant extension can be used to automate that, or in some cases, the rebase extension might be more appropriate. We can put extended examples from the PEP in the wiki to help people discovering the best workflow. Cheers, Dirkjan ___ 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
Re: [Python-Dev] graphics maths types in python core?
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 motivation behind PEP 3118 was so that libraries like NumPy, PIL > and the like would have a common standard for data interchange. If I understand correctly, one of the motivations behind memoryview() is to replace buffer() as a way to get cheap slicing without memory copies (it's used e.g. in the C IO library). I don't know whether the third-party types mentioned above could also benefit from that. Regards Antoine. ___ 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
Re: [Python-Dev] Possible py3k io wierdness
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 the flush-on-close behaviour. cheers Antoine. ___ 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
Re: [Python-Dev] Mercurial?
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 done or blocked backports. (the issue being that "svnmerge" is different from what DVCS'es call "merging" :-)) ___ 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
Re: [Python-Dev] BufferedReader.peek() ignores its argument
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 as some kind of internal heuristic (in the Python version) or not used at all (in the C version). Regards Antoine. ___ 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
Re: [Python-Dev] Mercurial?
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 currently in trunk/branches/tags. - integrate with the buildbot I've setup the buildbot infra for Mercurial (though not many people are interesting in it, so it's kind of languished). Using buildbot's hg support is easy. 0.7.10 is the first version which works with hg 1.1+, though, so we probably don't want to go with anything earlier. - 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 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 (repository) + tag, which can then be easily pulled in. But it'd be nice to know where and how exactly this is used. - decide what to do with the bzr mirrors I'm assuming the bzr people have ways of importing hg repos. It's probably more effective for them to deal with this problem. If helpful, there are some scripts that do fast-exporting from hg repos. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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 foreseeable future. > To proceed, I think the next step should be to discuss in the PEP the > details of the migration procedure (see PEP 347 for what level of detail > I produced for the svn migration), and to set up a demo installation > that is considered ready-to-run, except that it might get torn down > again, if the actual conversion requires that (it did for the CVS->svn > case), or if problems are found with the demo installation. 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. > I would personally remove all non-mercurial stuff out of PEP 374, > and retitle it, but that would be your choice. Moving the current content to a wiki page like you suggest later in this thread sounds like a good idea. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
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. clones, for example, and if we could try to reorder revlogs to make the repo smaller after conversion. 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. - Convert the current svn commit hooks to Mercurial. Some new hooks should also be discussed. For example, Mozilla uses a single-head hook, to prevent people from pushing multiple heads. They also have a pushlog extension that keeps a SQLite database of what people pushed. This is particularly useful for linearizing history, which is required for integration with buildbot infrastructure. - Add Mercurial support to the issue tracker. I don't think there's much to do there, but a regex to link up some commonly-used revision references would be good. If we use cloned branches, we'll have to come up with some syntax to make that work. - Update the developer FAQ. - Setup temporary svn mirrors for the main Mercurial repositories. How do you plan to do that? I don't think there are any tools that support that, yet. I've actually started on my own, but I haven't gotten very far with it, yet. - Augment code.python.org infrastructure to support the creation of developer accounts. Developers already have accounts, don't they? In any case, some web interface to facilitate setting up new clones (branches) is also something that's probably desirable. I think Mozilla has some tooling for that which we might be able to start off of. Cheers, Dirkjan ___ 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
Re: [Python-Dev] Mercurial?
> > > 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 I would not make it a prerequisite for the switch. > > While I don't know how urgent this is, I will just mention that I am willing to work on Roundup-mercurial during GSoC (or outside it, if I don't get accept). Cheers, M. ___ 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
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
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 releases never had problems with it. It was much > more painful to create the .exe-style Windows installers. Back when I was maintaining setup.exe was when XEmacs started using setup.exe to do installers; it must have been fairly straight forward because we first heard of it when it was complete :). The following may have changed, but I doubt it has changed dramatically - the setup.exe system is kindof trivial: There is a .lst file which is a .INI format file listing packages and direct dependencies. - each package is a .tar.(gz|bz2) which is unpacked on disk, and [optional] post-install, pre-removal scripts inside the tarball. Doing an installer for something not part of Cygwin requires a one-time fork of the setup.exe program, to change the master source for .lst files, and thats about it. Beyond that its all maintaining whatever set of packages and dependencies you have. If you are installing things for Cygwin itself you can just depend directly on things Cygwin ships in your .lst file; and not ship a setup.exe at all - setup.exe can source from many places to satisfy dependencies. -Rob signature.asc 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%40mail-archive.com
Re: [Python-Dev] Mercurial?
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 branches? > Will they be converted, or not? What about the stuff outside /python? > > In particular, the Stackless people have requested that they move along > with what core Python does, so their code should also be converted. I don't know the capabilities of hg w.r.t svn conversion, so this may well be overkill, but git has a really good tool for svn conversion (svn-all-fast-export, developed by KDE). You can handle almost any svn organization (e.g. outside the usual trunk/tags/branches), and convert email addresses of committers, split one big svn repo into subprojects, etc... Then, the git repo could be converted to hg relatively easily I believe. cheers, David ___ 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
Re: [Python-Dev] Possible py3k io wierdness
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 its superclass' close method. But then _RawIOBase will pointlessly call the subclass' flush method a second time. This second call should raise (because the file is closed) and the exception will be caught and suppressed. I don't see why this is helpful. Could you explain why _RawIOBase.close() calling self.flush() is useful? Cheers, Brian Antoine Pitrou wrote: Hi! sweetapp.com> writes: class _RawIOBase(_FileIO): FileIO is a subclass of _RawIOBase, not the reverse: issubclass(_io._RawIOBase, _io.FileIO) False issubclass(_io.FileIO, _io._RawIOBase) True I do understand your surprise, but the Python implementation of IOBase.close() in _pyio.py does the same thing: def close(self) -> None: """Flush and close the IO object. This method has no effect if the file is already closed. """ if not self.__closed: try: self.flush() except IOError: pass # If flush() fails, just give up self.__closed = True Note how it calls `self.flush()` and not `IOBase.flush(self)`. When writing the C version of the I/O stack, we tried to keep the semantics the same as in the Python version, although there are a couple of subtleties. Your problem here is that it's IOBase.close() which calls your flush() method, but FileIO.close() has already done its job before and the internal file descriptor has been closed (hence `self.closed` is True). In this particular case, I advocate overriding close() as well and call your flush() method manually from there. Thanks for your feedback! Regards Antoine. ___ 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/brian%40sweetapp.com ___ 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
Re: [Python-Dev] Mercurial?
> 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 /python? In particular, the Stackless people have requested that they move along with what core Python does, so their code should also be converted. >- Add Mercurial support to the issue tracker. 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 I would not make it a prerequisite for the switch. >- Setup temporary svn mirrors for the main Mercurial repositories. What is that? >- Augment code.python.org infrastructure to support the creation of > developer accounts. One option would be to carry on with the current setup; migrating it to hg might work as well, of course. >- Update the release.py script. > > There is probably some other things that I missed Here are some: - integrate with the buildbot - come up with a strategy for /external (also relevant for the buildbot slaves) - decide what to do with the bzr mirrors 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/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
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 to have. And if they work through the new buffer protocol, they'll be ready for multi-dimensional types if and when such types appear. -- Greg ___ 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
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
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 the .exe-style Windows installers. ___ 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
Re: [Python-Dev] graphics maths types in python core?
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 plain linear collections of bytes. > (I have added tests for arrays in test_memoryview, but that's all. And that's > only in py3k since array.array in 2.x only supports the old buffer interface) Step back for a sec here... PEP 3118 has three pieces, not two. Part 1, the actual new buffer protocol, is complete and works fine as far as I know. If it didn't, we would have heard about it from the third clients of the new protocol by now. 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 motivation behind PEP 3118 was so that libraries like NumPy, PIL and the like would have a common standard for data interchange. Since those all have their own extension objects and will be using the PEP 3118 C API directly rather than going through memoryview, the state of the Python API and the support from builtin containers types is largely irrelevant to the target audience for the PEP. 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
