Re: [Python-Dev] Removing IDLE from the standard library
One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. Having that alone would be a great improvement. --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ 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] Removing IDLE from the standard library
Am 12.07.2010 00:51, schrieb Mark Lawrence: I have been attempting to fill this hole and have been faced with animosity from people who hang out on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back. I agree with everything David said about this. My personal opinion is that you've done great work on the tracker, and like a few others, I've rediscovered a few issues I wanted to fix thanks to your stirring up the silt. I don't think you have reason to be offended by criticism (which was even pointed out to you as such). Try hanging around a little bit longer, take nothing too seriously, and see if you still get nothing of value from #python-dev. I would like things fixed, not a cosy little who's round is it next mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done. Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that. cheers, Georg ___ 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] notifications form Hg to python-checkins
Am 14.07.2010 00:00, schrieb Nick Coghlan: On Wed, Jul 14, 2010 at 7:45 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Tue, Jul 13, 2010 at 23:22, Nick Coghlan ncogh...@gmail.com wrote: No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :) As I recall, that's what I first implemented, but it was shot down by some of the committers... anyway, I'd be happy to change it back. I think I was one of the shooters :) Having seen the per-commit approach in action, I'd personally like it changed back to per-push notifications, but you may want to start a thread on python-committers about it (given the number of tangents it has spawned, I wouldn't be surprised if a lot of people have stopped following this discussion by now). My rationale is as follows: - for small changesets with only one or two changes, per-push or per-commit emails don't make much difference True. - for large changesets, per-commit can be very noisy (as Tarek's 100+ notifications showed) while per-push stays the same I assume you mean large pushes, consisting of tens of changesets? In this case, I see several problems with a single email: * it can get huge, and therefore a pain to load, and view in mail clients * it's needlessly clumsy to reply to single changes, since you have to go and delete the thousands of lines inbetween * there's no indication of what was pushed in the subject I also don't think we will see pushes like Tarek's 100+ one very often for Python. Usually changes will be bug fixes, and unless the committer is offline I expect them to be pushed immediately. I seem to have a vague recollection of the discussion you mention - do you remember if the specific objection was to a lack of a list of filenames affected in the subject line for the old per-push emails? Listing all the files affected by the push in the subject line would definitely still be desirable. No, I think we agreed to put the (first line of the) commit message there, which I think tells potential reviewers much better if they want to look at that changeset. Georg ___ 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] python-checkins replies
Am 13.07.2010 22:29, schrieb Brett Cannon: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Maybe reply-to on the checkin messages could be set to python-dev. Not sure if that's a mailman feature, though. I think this would be a good idea. It would be nice to have on-topic traffic here. :-) Or python-committers since this is discussing code already checked in and thus is somewhat committer-specific. This also has the perk of being easier to spot (don't know about the rest of you but my python-committers filter makes those emails much more obvious than python-dev traffic). I think I've suggested this once, but it met some resistance IIRC (it supposedly made our development exclusive). I'm still +1 on the idea though, and +1 on python-committers. Georg ___ 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] notifications form Hg to python-checkins
On Wed, Jul 14, 2010 at 10:15, Georg Brandl g.bra...@gmx.net wrote: I also don't think we will see pushes like Tarek's 100+ one very often for Python. Usually changes will be bug fixes, and unless the committer is offline I expect them to be pushed immediately. Depends. If we do feature branches in separate clones, the merges for those can potentially push large numbers of csets at once. Presumably, we could push some more complexity into the hook, and have it send emails per-group for groups of 5 and larger and per-cset for smaller groups. No, I think we agreed to put the (first line of the) commit message there, which I think tells potential reviewers much better if they want to look at that changeset. Not sure there was actual consensus on that, but I still stand behind this point. 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] python-checkins replies
On 7/14/2010 4:21 AM, Georg Brandl wrote: Am 13.07.2010 22:29, schrieb Brett Cannon: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Maybe reply-to on the checkin messages could be set to python-dev. Not sure if that's a mailman feature, though. I think this would be a good idea. It would be nice to have on-topic traffic here. :-) Or python-committers since this is discussing code already checked in and thus is somewhat committer-specific. This also has the perk of being easier to spot (don't know about the rest of you but my python-committers filter makes those emails much more obvious than python-dev traffic). I think I've suggested this once, but it met some resistance IIRC (it supposedly made our development exclusive). That's why I think it should go on python-dev. If the code hadn't been checked in and you were asking what do you think of solving this by using the following code, I think you'd put it on python-dev. I'd want the discussion of an actual checkin to occur in that same venue. I'm still +1 on the idea though, and +1 on python-committers. That said, I'm +1 on the idea, but only +0 on python-dev. Eric. ___ 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] python-checkins
Dirkjan Ochtman dirk...@ochtman.nl writes: - http://bitbucket.org/mg/commitsigs is another extension, which takes a different tack to signing (I believe it doesn't sign the commit metadata, only the file tree, which lets it sign before the commit is finished, meaning it doesn't take up an extra cset). It does signs the complete changeset hash including the commit message, username, etc, and it does this without creating an extra changeset. This is done by computing what the changeset hash would be without an embedded signature. This hash is then signed and embedded in the changeset. This is similar to how TCP checksums are computed. This increases the size of each changeset by about 2 KB of data which cannot be compressed -- this adds up over time and I would only advice people to use the extension if they are very paranoid or have special legal requirements. -- Martin Geisler Mercurial links: http://mercurial.ch/ pgpQIiKj4dVLR.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
Georg Brandl wrote: Am 12.07.2010 00:51, schrieb Mark Lawrence: I have been attempting to fill this hole and have been faced with animosity from people who hang out on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back. I agree with everything David said about this. My personal opinion is that you've done great work on the tracker, and like a few others, I've rediscovered a few issues I wanted to fix thanks to your stirring up the silt. I don't think you have reason to be offended by criticism (which was even pointed out to you as such). Try hanging around a little bit longer, take nothing too seriously, and see if you still get nothing of value from #python-dev. I would like things fixed, not a cosy little who's round is it next mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done. Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that. I tend to agree with you, but the fact that it can deter stalwarts like Mark perhaps indicate that a little caution should be applied when dealing with newcomers or outsiders. Without, I trust, spoiling the fun for the regulars. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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] Peculiar import code in pickle.py
Brett Cannon wrote:
On Tue, Jul 13, 2010 at 11:34, Alexander Belopolsky
alexander.belopol...@gmail.com mailto:alexander.belopol...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 1:57 PM, Benjamin Peterson
benja...@python.org mailto:benja...@python.org wrote:
..
No! That's not recommended and a complete hack. The dance or
importlib.import_module is preferred.
Nevertheless, a complete hack is what PyImport_Import does:
PyObject *
PyImport_Import(PyObject *module_name)
{
static PyObject *silly_list = NULL;
..
/* Call the __import__ function with the proper argument list
* Always use absolute import here. */
r = PyObject_CallFunction(import, i, module_name, globals,
globals, silly_list, 0, NULL);
..
}
and _pickle.c uses PyImport_Import() and thus is different form
pickle.py which uses the double-lookup dance. As a result, the two
implementations are subtly different. They cannot be both right. It
should be easy to fix _pickle.c to do the sys.modules lookup, but I
am not sure this is right.
Pulling from sys.modules is the correct way to do this. There are subtle
issues when using a bunk fromlist argument (empty modules, double
initialization, etc.). If one does not use importlib.import_module --
written *specifically* to prevent people from doing the nasty hack with
the fromlist -- then you should use the sys.modules approach, period. If
import.c is not doing this then it should get fixed. You can assign me
the issue if you want.
I say this every time I give an import talk and it has been brought up
here before but obviously not everyone catches it (which is
understandable as I think when it came up on python-dev it was at the
tail end of a discussion), so I am just going to repeat myself:
Do not put junk in fromlist if you call __import__ directly! Use
importlib.import_module! Or if you have a *really* good reason to not
use it, then use ``__import__(name); module = sys.modules[name]``.
I have stopped fixing bugs related to this in import.c because of the
annoying issues it causes and I expect the correct approach to gain
traction at some point (plus get importlib bootstrapped in so I don't
have to care about import.c anymore).
It's only a matter of time until someone decides to provide a C
implementation of importlib ;-)
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video! http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.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] Peculiar import code in pickle.py
On Wed, Jul 14, 2010 at 9:05 PM, Steve Holden st...@holdenweb.com wrote: I have stopped fixing bugs related to this in import.c because of the annoying issues it causes and I expect the correct approach to gain traction at some point (plus get importlib bootstrapped in so I don't have to care about import.c anymore). It's only a matter of time until someone decides to provide a C implementation of importlib ;-) A C accelerated version of importlib would probably be an awful lot cleaner than the current import implementation. While the import code isn't quite the mess that we sometimes make it out to be (it does basically work after all, and most of the problems lie in dim dark corners that 99% of developers will never get close to), but it has definitely suffered from an accumulation of features on top of a core approach that has been pushed far beyond what it was originally designed to support. That said, I believe the limiting factor in import speed is likely to remain the number of stat calls and other filesystem operations, so it will be interesting to find out just how significant a slowdown there is between import.c and importlib. If I'm right about the real source of bottlenecks in import performance, the difference may be surprisingly small. 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] Issue 2986: difflib.SequenceMatcher is partly broken
On Wed, 14 Jul 2010 11:45:25 am Terry Reedy wrote: Summary: adding an autojunk heuristic to difflib without also adding a way to turn it off was a bug because it disabled running code. 2.6 and 3.1 each have, most likely, one final version each. Don't fix for these but add something to the docs explaining the problem and future fix. 2.7 will have several more versions over several years and will be used by newcomers who might encounter the problem but not know to diagnose it and patch a private copy of the module. So it should have a fix. Solutions thought of so far. 1. Modify the heuristic to somewhat fix the problem. Bad (unacceptable) because this would silently change behavior and could break tests. 2. Add a parameter that defaults to using the heuristic but allows turning it off. Perhaps better, but code that used the new API would crash if run on 2.7.0 3. Tim Peters [... snip crazy scheme...] 4. I normally dislike global flags, but this is one time it might be less-worse than the alternatives. Modify SequenceMatcher to test for the value of a global flag, defaulting to False if it doesn't exist. try: disable = disable_heuristic except NameError: disable = False if disable: # use the new, correct behaviour else: # stick to the old, backwards-compatible but wrong behaviour The flag will only exist if the caller explicitly creates it: import difflib difflib.disable_heuristic = True On 2.7.0 and older versions, creating the flag won't do anything useful, but nor will it cause an exception. It will be harmless. I think an explicit flag is better than relying on magic behaviour triggered by unlikely input. -- Steven D'Aprano ___ 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] Removing IDLE from the standard library
On 14/07/2010 09:10, Georg Brandl wrote: Am 12.07.2010 00:51, schrieb Mark Lawrence: I have been attempting to fill this hole and have been faced with animosity from people who hang out on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back. I agree with everything David said about this. My personal opinion is that you've done great work on the tracker, and like a few others, I've rediscovered a few issues I wanted to fix thanks to your stirring up the silt. I don't think you have reason to be offended by criticism (which was even pointed out to you as such). Try hanging around a little bit longer, take nothing too seriously, and see if you still get nothing of value from #python-dev. I would like things fixed, not a cosy little who's round is it next mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done. Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that. cheers, Georg Georg, Thanks to your response and the earlier one from David I now understand how things work. I'm actually on IRC right now. I consider this matter done and dusted, so let's move on shall we? Kindest regards. Mark Lawrence. ___ 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] Issue 2986: difflib.SequenceMatcher is partly broken
On Wed, Jul 14, 2010 at 10:38 PM, Steven D'Aprano st...@pearwood.info wrote: 4. I normally dislike global flags, but this is one time it might be less-worse than the alternatives. Modify SequenceMatcher to test for the value of a global flag, defaulting to False if it doesn't exist. try: disable = disable_heuristic except NameError: disable = False if disable: # use the new, correct behaviour else: # stick to the old, backwards-compatible but wrong behaviour The flag will only exist if the caller explicitly creates it: import difflib difflib.disable_heuristic = True On 2.7.0 and older versions, creating the flag won't do anything useful, but nor will it cause an exception. It will be harmless. I think an explicit flag is better than relying on magic behaviour triggered by unlikely input. Why make it a global? A property on the SequenceMatcher object should be able to do the right thing. @property def use_autojunk(self): if self._use_autojunk is None: raise AttributeError(...) # Same error as 2.7.0 would raise return self._use_autojunk @use_autojunk.set def use_autojunk(self, val): self._use_autojunk = bool(val) Then use the self._use_autojunk flag to decide whether or not to use the heuristic on 2.7.1+. Code that sets the flag would behave the same on both 2.7.1+ and on 2.7.0, it would just fail to turn the heuristic off in 2.7.0. Code that only read the flag without setting it would also behave the same on the whole 2.7.x series (i.e. raising AttributeError if the flag had not been explicitly set by the application) A flag on the object rather than a per-call flag may actually be the better API here anyway. 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] More C API abstraction for user defined types
Nick Coghlan ncoghlan at gmail.com writes: On Tue, Jul 13, 2010 at 6:44 PM, Mark Dickinson dickinsm at gmail.com wrote: On Mon, Jul 12, 2010 at 10:19 PM, Nick Coghlan ncoghlan at gmail.com wrote: On Tue, Jul 13, 2010 at 3:35 AM, Petre Galan Petre.Galan at gmail.com wrote: ival should not be resolved through PyLong_AsLong, but through functionality/interface like PyNumber_Long +1, but I'd prefer it if PyNumber_Index were used, rather than PyNumber_Long. It shouldn't be possible to pass a Decimal instance to something expecting an integer argument. Oops, I misread the suggestion. Indeed, PyNumber_Index is the correct API function for this purpose. Cheers, Nick. No. The right interface is PyNumber_Long. The purpose of the PyNumber_Index (and nb_index slot) is as index in slicing. Petre ___ 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] Removing IDLE from the standard library
On 7/14/2010 4:10 AM, Georg Brandl wrote:
Sure, and if it was work time, we probably would do this ;). As it is
right now, this is volunteer time, and I would say that we're entitled
to do whatever helps us getting done the (not always exciting) work,
and our IRC crap talk, if that's what it is, happens to be among that.
Aha! IRC ('chat') is like a social hour or cocktail party, with multiple
simultaneous conversations. Some people must like such events and even
find relaxing. I tend to find them uncomfortable and a bit of a chore to
mentally process, at least until I can get deep enough into a
conversation with 1 or 2 people to tune everyone else out. So, while a
bit of business *might* get conducted, that is not the primary purpose.
So I can see that pushing to make it a business meeting would not be too
welcome. What I would like is an online sprint with a temporary
#python-triage channel, with at least one commit-developer present.
Pending that, is there any time of day when more people with commit
privileges are likely to be present.
The other problem I have is being dropped or timed out, and not
having/knowing a way to get auto-reconnected to the channel. Thus, I
could miss a response even if I do get one.
--
Terry Jan Reedy
___
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] Removing IDLE from the standard library
On Wed, 14 Jul 2010 12:34:27 -0400 Terry Reedy tjre...@udel.edu wrote: So I can see that pushing to make it a business meeting would not be too welcome. What I would like is an online sprint with a temporary #python-triage channel, with at least one commit-developer present. It should be noted that #python-dev is quite low-traffic. There is less than one message per minute on average, and not often more than one conversation at a time. Pending that, is there any time of day when more people with commit privileges are likely to be present. Generally any time of day, since different people are on different timezones. The other problem I have is being dropped or timed out, and not having/knowing a way to get auto-reconnected to the channel. Thus, I could miss a response even if I do get one. I never get drops or timeouts. I suppose any decent IRC client will handle connection issues for you. 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] Removing IDLE from the standard library
Terry Reedy wrote:
On 7/14/2010 4:10 AM, Georg Brandl wrote:
Sure, and if it was work time, we probably would do this ;). As it is
right now, this is volunteer time, and I would say that we're entitled
to do whatever helps us getting done the (not always exciting) work,
and our IRC crap talk, if that's what it is, happens to be among that.
Aha! IRC ('chat') is like a social hour or cocktail party, with multiple
simultaneous conversations. Some people must like such events and even
find relaxing. I tend to find them uncomfortable and a bit of a chore to
mentally process, at least until I can get deep enough into a
conversation with 1 or 2 people to tune everyone else out. So, while a
bit of business *might* get conducted, that is not the primary purpose.
So I can see that pushing to make it a business meeting would not be too
welcome. What I would like is an online sprint with a temporary
#python-triage channel, with at least one commit-developer present.
Pending that, is there any time of day when more people with commit
privileges are likely to be present.
The other problem I have is being dropped or timed out, and not
having/knowing a way to get auto-reconnected to the channel. Thus, I
could miss a response even if I do get one.
Speak to the twisted guys. It's about a line-and-a-half of code to run a
logger on an IRC channel.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video! http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.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] Removing IDLE from the standard library
On 7/14/2010 2:35 AM, Giampaolo Rodolà wrote: One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. Having that alone would be a great improvement. Yes, the same as tabs for browsing was. This is firstly an unlying gui widget set issue. Tk does not, as far as I know, have a tabbed document widget. Ttk has a new Notebook widget, with tabs. The second issue is whether, starting with 3.2, IDLE can require the availability of ttk, meaning tcl/tk 8.5+ or the Tile add-on. I opened http://bugs.python.org/issue9262 -- Terry Jan Reedy ___ 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] Removing IDLE from the standard library
On Wed, Jul 14, 2010 at 11:34, Terry Reedy tjre...@udel.edu wrote: On 7/14/2010 4:10 AM, Georg Brandl wrote: Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that. Pending that, is there any time of day when more people with commit privileges are likely to be present. There never seems to be a lack of committers online. There are plenty of us here in the US, along with numerous committers from a host of European countries and elsewhere, so committer availability tends to follow the sun. Knowing that you are in the US, I don't think you'll come across many dead-zones. ___ 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] Removing IDLE from the standard library
2010/7/14 Terry Reedy tjre...@udel.edu: On 7/14/2010 2:35 AM, Giampaolo Rodolà wrote: One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. Having that alone would be a great improvement. Yes, the same as tabs for browsing was. This is firstly an unlying gui widget set issue. Tk does not, as far as I know, have a tabbed document widget. Ttk has a new Notebook widget, with tabs. I have worked on this before, and I can tell you that simply changing to ttk widgets is the easiest part. My recommendation, that you are free to ignore (especially if you want to skip this previous work), is: as a first step change the EditWindow to act more like a EditPage. That is, you should be able to instantiate a EditWindow and include this new EditPage on it (as a child or something else that you may imagine). -- Terry Jan Reedy -- -- Guilherme H. Polo Goncalves ___ 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] Issue 2986: difflib.SequenceMatcher is partly broken
On 7/14/2010 9:45 AM, Nick Coghlan wrote: Code that sets the flag would behave the same on both 2.7.1+ and on 2.7.0, it would just fail to turn the heuristic off in 2.7.0. Antoine Pitrou pointed out on the tracker http://bugs.python.org/issue2986 that such code would *not* 'behave the same'. It would return different results (thus failing tests, if any). If, as would usually be the case, it *needs* the heuristic turned off to get sensible results, it would fail silently and deceptively. He thinks it better to fail noisily with an exception. Any code that depends on an x.y.z bugfix for proper operation and does not include conditional workaround for prior releases, will fail when run on prior releases. Whether the failure is a bad result (silent) or bad exception (noisy) usually depends on what the buggy behavior was. This case is an exception in that a. There is no workaround. b. A complete fix requires some api change. c. We have a choice of changes; some make failures on previous x.y releases silent (as they have been), others make them noisy -- without doing anything extra to make them noisy[*]. d. Hence we have a choice of failure mode. Hence the exceptional debate. [*] For the normal case of bad behavior for some input, we change the code to give the correct behavior. Raising an exception with previous releases would require extra conditional code. Here, by the nature of heuristic, there is no completely correct fix except to be able to turn it off. (If there were a correct deterministic rule, it would not be a heuristic ;=). The mechanism for turning it off might or might not raise an exception 'for free', with no added code for that. -- Terry Jan Reedy ___ 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] Include datetime.py in stdlib or not?
On Tue, Jul 13, 2010 at 3:52 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: .. and import _strptime had to be moved from function level to module level after class definitions due to circular dependency of _strptime on datetime. This turned out to be not such a great idea. Importing _strptime at the module level even after all datetime initializations does not work because of another circular dependency: _strptime imports calendar which imports calendar which imports datetime. New patch is at http://bugs.python.org/file17978/issue9206c.diff ___ 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] python-checkins replies
On Wed, Jul 14, 2010 at 01:36, Eric Smith e...@trueblade.com wrote: On 7/14/2010 4:21 AM, Georg Brandl wrote: Am 13.07.2010 22:29, schrieb Brett Cannon: Given how high traffic python-checkins is I don't consider that a reasonable place to send follow-up and nor do I consider it the responsibility of committers to monitor it. As you said earlier this *isn't* in our standard dev procedures and nor do I think it should be. If you can't find an email address then either python-comitters or python-dev would be a better place to send feedback. Maybe reply-to on the checkin messages could be set to python-dev. Not sure if that's a mailman feature, though. I think this would be a good idea. It would be nice to have on-topic traffic here. :-) Or python-committers since this is discussing code already checked in and thus is somewhat committer-specific. This also has the perk of being easier to spot (don't know about the rest of you but my python-committers filter makes those emails much more obvious than python-dev traffic). I think I've suggested this once, but it met some resistance IIRC (it supposedly made our development exclusive). That's why I think it should go on python-dev. If the code hadn't been checked in and you were asking what do you think of solving this by using the following code, I think you'd put it on python-dev. Actually, I probably wouldn't. =) When it gets to explicit code, a design decision has been made, so I do not need to worry about involving the general public in some low-level technical discussion that won't impact them. I'd want the discussion of an actual checkin to occur in that same venue. Right, which is why I want python-committers. Otherwise it's just a glorified commit lock when we are cutting releases. I'm still +1 on the idea though, and +1 on python-committers. That said, I'm +1 on the idea, but only +0 on python-dev. +1 on python-committers, +0 on python-dev. ___ 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] Peculiar import code in pickle.py
On Wed, Jul 14, 2010 at 05:15, Nick Coghlan ncogh...@gmail.com wrote: On Wed, Jul 14, 2010 at 9:05 PM, Steve Holden st...@holdenweb.com wrote: I have stopped fixing bugs related to this in import.c because of the annoying issues it causes and I expect the correct approach to gain traction at some point (plus get importlib bootstrapped in so I don't have to care about import.c anymore). It's only a matter of time until someone decides to provide a C implementation of importlib ;-) A C accelerated version of importlib would probably be an awful lot cleaner than the current import implementation. While the import code isn't quite the mess that we sometimes make it out to be (it does basically work after all, and most of the problems lie in dim dark corners that 99% of developers will never get close to), but it has definitely suffered from an accumulation of features on top of a core approach that has been pushed far beyond what it was originally designed to support. So my dream is to finally get full compatibility for importlib in 3.3 (probably won't hit 3.2 as it requires me changing marshal.loads to take a file path argument) and then try to bootstrap it in. Now bootstrapping can be done with actually a minimal amount of C code as I can simply make the bytecode for importlib a literal in C, get that loaded, and then import importlib as found on the file system to allow people to override things. But obviously I could also identify the true bottlenecks through profiling and provide acceleration where useful. Trick is being reasonable about this so as to not put other VMs at a disadvantage by making the bootstrap solution too difficult to implement. That said, I believe the limiting factor in import speed is likely to remain the number of stat calls and other filesystem operations, so it will be interesting to find out just how significant a slowdown there is between import.c and importlib. If I'm right about the real source of bottlenecks in import performance, the difference may be surprisingly small. So I started writing benchmark code in anticipation of needing to prove a minimal performance difference to justify bootstrapping importlib. Right now it only compares importing from sys.modules and built-in modules. You can run it with ``./python.exe -m importlib.test.benchmark``. If you add a `-b` option that will use the built-in __import__ implementation. I still need to benchmark loading source, bytecode, writing bytecode, and loading extensions. Maybe I will finish writing the benchmark code as the thing I do while at EuroPython (that and finally getting to reviewing http://bugs.python.org/issue2919 so that cProfile and profile can merge, unless someone beats me to it, in which case I would be grateful =). ___ 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] Removing IDLE from the standard library
On 7/14/2010 12:58 PM, Antoine Pitrou wrote: On Wed, 14 Jul 2010 12:34:27 -0400 Terry Reedytjre...@udel.edu wrote: So I can see that pushing to make it a business meeting would not be too welcome. What I would like is an online sprint with a temporary #python-triage channel, with at least one commit-developer present. It should be noted that #python-dev is quite low-traffic. There is less than one message per minute on average, and not often more than one conversation at a time. I will take a look. The other problem I have is being dropped or timed out, and not having/knowing a way to get auto-reconnected to the channel. Thus, I could miss a response even if I do get one. I never get drops or timeouts. I suppose any decent IRC client will handle connection issues for you. Is Chatzilla not decent, or is there a better Windows client. I have it set to reconnect when disconnected and to 'msg NickServe identify' when connected, but I do not see any way to wait for that to complete before issuing 'join #python'. I found a box under #python for 'rejoin when kicked' but I do not know if that will work for disconnections. -- Terry Jan Reedy ___ 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] importlib
On Wed, 14 Jul 2010 12:33:55 -0700 Brett Cannon br...@python.org wrote: So I started writing benchmark code in anticipation of needing to prove a minimal performance difference to justify bootstrapping importlib. Right now it only compares importing from sys.modules and built-in modules. You can run it with ``./python.exe -m importlib.test.benchmark``. If you add a `-b` option that will use the built-in __import__ implementation. In what unit are the numbers? In any case, here my results under a Linux system: $ ./python -m importlib.test.benchmark sys.modules [ 323782 326183 326667 ] best is 326667 Built-in module [ 33600 33693 33610 ] best is 33693 $ ./python -m importlib.test.benchmark -b sys.modules [ 1297640 1315366 1292283 ] best is 1315366 Built-in module [ 58180 57708 58057 ] best is 58180 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] Removing IDLE from the standard library
2010/7/14 Guilherme Polo ggp...@gmail.com: 2010/7/14 Terry Reedy tjre...@udel.edu: On 7/14/2010 2:35 AM, Giampaolo Rodolà wrote: One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. Having that alone would be a great improvement. Yes, the same as tabs for browsing was. This is firstly an unlying gui widget set issue. Tk does not, as far as I know, have a tabbed document widget. Ttk has a new Notebook widget, with tabs. I have worked on this before, and I can tell you that simply changing to ttk widgets is the easiest part. My recommendation, that you are free to ignore (especially if you want to skip this previous work), is: as a first step change the EditWindow to act more like a EditPage. That is, you should be able to instantiate a EditWindow and include this new EditPage on it (as a child or something else that you may imagine). -- Terry Jan Reedy -- -- Guilherme H. Polo Goncalves ___ 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/g.rodola%40gmail.com http://code.google.com/p/python-ttk/wiki/Screenshots Modified IDLE screenshots look impressive. Has Ttk (or something similar) ever been considered for inclusion? I think the problem here is more Tkinter itself rather than IDLE. Does spending energies on working on something (IDLE) based on such an old and features-limited module as Tkinter really worth the effort? Some major lacks like tabbed browsing can be fixed somehow but there always will be a big impediment deriving from using such an old graphic library which can't provide all the facilities offered by wx, gtk, etc... Maybe it would be better to first upgrade/improve Tkinter somehow; provide a gui toolkit that is *really* competitive, then start to seriously work on IDLE. My 2 cents --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ 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] Issue 2986: difflib.SequenceMatcher is partly broken
[Steven D'Aprano] 4. I normally dislike global flags, but this is one time it might be less-worse than the alternatives. Modify SequenceMatcher to test for the value of a global flag, defaulting to False if it doesn't exist. ... The flag will only exist if the caller explicitly creates it: import difflib difflib.disable_heuristic = True ... A module global is a non-starter for me (for all the usual reasons about the potentially horrid sociopathic consequences of one piece of an app changing behavior for the entire app - fine if it's a small app wholly understood by the user, potential nightmares if it's a large app nobody understands 0.3 wink). [Nick Coghlan] Why make it a global? A property on the SequenceMatcher object should be able to do the right thing. ... The pragmatic drawback is that the heuristics we're trying to disable typically execute _during_ SequenceMatcher instance construction. That's why it makes most sense to convey the information to the constructor. Setting a property after the instance is created is typically too late (unless several other SequenceMatcher methods are rewritten to delay analyzing the second sequence). A flag on the object rather than a per-call flag may actually be the better API here anyway. The call in question here is the constructor (__init__), so there's no real difference between on the object and per call in this case. ___ 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] Removing IDLE from the standard library
http://docs.python.org/dev/whatsnew/2.7.html#ttk-themed-widgets-for-tk Sorry, I realized just now that ttk is already included in Python 2.7 and 3.2. 2010/7/14 Giampaolo Rodolà g.rod...@gmail.com: 2010/7/14 Guilherme Polo ggp...@gmail.com: 2010/7/14 Terry Reedy tjre...@udel.edu: On 7/14/2010 2:35 AM, Giampaolo Rodolà wrote: One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. Having that alone would be a great improvement. Yes, the same as tabs for browsing was. This is firstly an unlying gui widget set issue. Tk does not, as far as I know, have a tabbed document widget. Ttk has a new Notebook widget, with tabs. I have worked on this before, and I can tell you that simply changing to ttk widgets is the easiest part. My recommendation, that you are free to ignore (especially if you want to skip this previous work), is: as a first step change the EditWindow to act more like a EditPage. That is, you should be able to instantiate a EditWindow and include this new EditPage on it (as a child or something else that you may imagine). -- Terry Jan Reedy -- -- Guilherme H. Polo Goncalves ___ 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/g.rodola%40gmail.com http://code.google.com/p/python-ttk/wiki/Screenshots Modified IDLE screenshots look impressive. Has Ttk (or something similar) ever been considered for inclusion? I think the problem here is more Tkinter itself rather than IDLE. Does spending energies on working on something (IDLE) based on such an old and features-limited module as Tkinter really worth the effort? Some major lacks like tabbed browsing can be fixed somehow but there always will be a big impediment deriving from using such an old graphic library which can't provide all the facilities offered by wx, gtk, etc... Maybe it would be better to first upgrade/improve Tkinter somehow; provide a gui toolkit that is *really* competitive, then start to seriously work on IDLE. My 2 cents --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ 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] notifications form Hg to python-checkins
On 14 July 2010 18:26, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Wed, Jul 14, 2010 at 10:15, Georg Brandl g.bra...@gmx.net wrote: I also don't think we will see pushes like Tarek's 100+ one very often for Python. Usually changes will be bug fixes, and unless the committer is offline I expect them to be pushed immediately. Depends. If we do feature branches in separate clones, the merges for those can potentially push large numbers of csets at once. Presumably, we could push some more complexity into the hook, and have it send emails per-group for groups of 5 and larger and per-cset for smaller groups. No, I think we agreed to put the (first line of the) commit message there, which I think tells potential reviewers much better if they want to look at that changeset. Not sure there was actual consensus on that, but I still stand behind this point. If development work was done in named branches, the hook could send one email per branch that was delivered, and to be safe, one email per changeset added to a main feature branch. Tim Delaney ___ 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] str(memoryview('abc')) != 'abc' in Python 2.7
Is this intended or should I open a bug report for it:
m = memoryview('abc')
m == 'abc'
True
str(m) == 'abc'
False
str(m)
'memory at 0x2b2bb6ee26d8'
I would have expected str(m) == 'abc'.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 15 2010)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK 3 days to go
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
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] More C API abstraction for user defined types
On Wed, Jul 14, 2010 at 11:50 PM, Petre Galan petre.ga...@gmail.com wrote: No. The right interface is PyNumber_Long. The purpose of the PyNumber_Index (and nb_index slot) is as index in slicing. Allowing other objects to say I'm a real integer, treat me as one is exactly what the nb_index slot is for (see PEP 357). The use as an index in slicing was just the primary initial use case and the one that was chosen as the name for the new slot because nb_int was already taken for the lossy transformation. Indexing is not (and never has been) intended to be the only use case. ___ 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] python-checkins replies
On Thu, Jul 15, 2010 at 5:22 AM, Brett Cannon br...@python.org wrote: Actually, I probably wouldn't. =) When it gets to explicit code, a design decision has been made, so I do not need to worry about involving the general public in some low-level technical discussion that won't impact them. Yep, that's my perspective as well. If my post-commit comments are more significant than typo fixes and internal naming suggestions, I'll take them back to python-dev manually. So for me, +1 on python-committers, +0 on python-dev or the status quo. 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] Removing IDLE from the standard library
Giampaolo Rodolà wrote: One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. While tabs seem to work well for web browsing, I'm not so sure about using them for source editing. Often I want to display two or more files side by side, which can't be done if they're in different tabs of the same window. -- 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] Issue 2986: difflib.SequenceMatcher is partly broken
On Thu, Jul 15, 2010 at 6:40 AM, Tim Peters tim.pet...@gmail.com wrote: The call in question here is the constructor (__init__), so there's no real difference between on the object and per call in this case. You're right, I was misremembering how SequenceMatcher works. Terry's summary of the situation seems correct to me - adding a new flag to the constructor signature would mean we're taking a silent failure (the heuristic makes my code give the wrong answer on 2.7.0) and making it a noisy failure (my code needs to be able to turn the heuristic off to get the right answer, so it will fail noisily on 2.7.0). That's a far cry from the True/False mistake. 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] Removing IDLE from the standard library
On Thu, Jul 15, 2010 at 9:26 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Giampaolo Rodolà wrote: One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. While tabs seem to work well for web browsing, I'm not so sure about using them for source editing. Often I want to display two or more files side by side, which can't be done if they're in different tabs of the same window. I use tabbed editors all the time (Kate, Notepad++) and find them to be excellent. Tastes will obviously vary though, since there are even people out there that use vim and emacs voluntarily ;) 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] How to spell PyInstance_NewRaw in py3k?
I am reposting the same question again because it seems to have gone unnoticed. Antoine Pitrou and I had a brief discussion on the tracker, but did not reach an agreement on whether a more elaborate code is needed to replace PyInstance_NewRaw than a simple type-tp_alloc() call. I have reviewed the patch again and I am convinced that this issue comes into play only when 3.x loads 2.x pickles that contain instances of classic classes. (Specifically, this code is used to process INST and OBJ pickle opcodes that are not produced by 3.x.) This means that Antoine's concern that tomorrow [object_new()] may entail additional operations is not valid - there is no tomorrow for 2.x. :-) This also means that the type cannot inherit from anything other than object and thus cannot have funny tp_flags or tp_alloc that does not create a usable object. I would like to commit the patch as presented. If a corner case is discovered later where type-tp_alloc() is not sufficient, we can deal with it then. On Mon, Jun 28, 2010 at 3:59 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: Issue #5180 [1] presented an interesting challenge: how to unpickle instances of old-style classes when a pickle created with 2.x is loaded in 3.x python? The problem is that pickle protocol requires that unpickled instances be created without calling the __init__ method. This is necessary because pickle file may not contain information about how __init__ method should be invoked. Instead, implementations are required to bypass __init__ and populate instance's __dict__ directly using data found in the pickle. Pure python implementation uses the following trick that happens to work in 3.x: class Empty: pass pickled = Empty() pickled.__class__ = Pickled This of course, creates a new-style class in 3.x, but if 3.x version of Pickled behaves similarly to its 2.x predecessor, it should work. The cPickle implementation, on the other hand uses 2.x C API which is not available in 3.x. Namely, the PyInstance_NewRaw function. In order to fix the bug described in issue #5180, I had to emulate PyInstance_NewRaw using type-tp_alloc. I considered an rejected the idea to use tp_new instead. [2] Is this the right way to proceed? The patch is attached to the issue. [3] [1] http://bugs.python.org/issue5180 [2] http://bugs.python.org/issue5180#msg108846 [3] http://bugs.python.org/file17792/issue5180.diff ___ 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] str(memoryview('abc')) != 'abc' in Python 2.7
I wouldn't assume so - memoryview is meant to eventually support more than just 1-D views of contiguous memory (see PEP 3118), so that conversion doesn't seem intuitive to me. 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] Issue 2986: difflib.SequenceMatcher is partly broken
[Nick Coghlan] You're right, I was misremembering how SequenceMatcher works. Terry's summary of the situation seems correct to me - adding a new flag to the constructor signature would mean we're taking a silent failure (the heuristic makes my code give the wrong answer on 2.7.0) and making it a noisy failure (my code needs to be able to turn the heuristic off to get the right answer, so it will fail noisily on 2.7.0). Yup - exactly so. That's a far cry from the True/False mistake. Which I'm sure refers to introducing True and False builtins in a bugfix release. That was _almost_ as bad as the sometimes-hated heuristic I added to SequenceMatcher ;-) Me, I like fail noisily on 2.7.0 for this case - practicality beats purity, especially when so few people and programs are likely to be affected by the backwards-incompatible-but-only-for-those-who-need-to-use-it SequenceMatcher constructor signature change. ___ 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] versioned .so files for Python 3.2
On Jun 25, 2010, at 08:35 AM, Nick Coghlan wrote: I like the idea, but I think summarising the rest of this discussion in its own (relatively short) PEP would be good (there are a few things that are tricky - exact versioning scheme, PEP 384 forward compatibility, impact on distutils, articulating the benefits for distro packaging, etc). The first draft of PEP 3149 is ready for review. http://www.python.org/dev/peps/pep-3149/ Plain text attached here for your convenience. Comments, suggestions as always are welcome. Thanks to everyone who participated in the original discussion. -Barry PEP: 3149 Title: ABI version tagged .so files Version: $Revision: 81577 $ Last-Modified: $Date: 2010-05-27 19:54:25 -0400 (Thu, 27 May 2010) $ Author: Barry Warsaw ba...@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2010-07-09 Python-Version: 3.2 Post-History: 2010-07-14 Resolution: TBD Abstract PEP 3147 [1]_ described an extension to Python's import machinery that improved the sharing of Python source code, by allowing more than one byte compilation file (.pyc) to be co-located with each source file. This PEP defines an adjunct feature which allows the co-location of extension module files (.so) in a similar manner. This optional, build-time feature will enable downstream distributions of Python to more easily provide more than one Python major version at a time. Background == PEP 3147 defined the file system layout for a pure-Python package, where multiple versions of Python are available on the system. For example, where the `alpha` package containing source modules `one.py` and `two.py` exist on a system with Python 3.2 and 3.3, the post-byte compilation file system layout would be:: alpha/ __pycache__/ __init__.cpython-32.pyc __init__.cpython-33.pyc one.cpython-32.pyc one.cpython-33.pyc two.cpython-32.pyc two.cpython-33.pyc __init__.py one.py two.py For packages with extension modules, a similar differentiation is needed for the module's .so files. Extension modules compiled for different Python major versions are incompatible with each other due to changes in the ABI. While PEP 384 [2]_ defines a stable ABI, it will minimize, but not eliminate extension module incompatibilities between Python major versions. Thus a mechanism for discriminating extension module file names is proposed. Rationale = Linux distributions such as Ubuntu [3]_ and Debian [4]_ provide more than one Python version at the same time to their users. For example, Ubuntu 9.10 Karmic Koala users can install Python 2.5, 2.6, and 3.1, with Python 2.6 being the default. In order to share as much as possible between the available Python versions, these distributions install third party (i.e. non-standard library) packages into `/usr/share/pyshared` and symlink to them from `/usr/lib/pythonX.Y/dist-packages`. The symlinks exist because in a pre-PEP 3147 world (i.e Python 3.2), the `.pyc` files resulting from byte compilation by the various installed Pythons will name collide with each other. For Python versions = 3.2, all pure-Python packages can be shared, because the `.pyc` files will no longer cause file system naming conflicts. Eliminating these symlinks makes for a simpler, more robust Python distribution. A similar situation arises with shared library extensions. Because extension modules are typically named `foo.so` for a `foo` extension module, these would also name collide if `foo` was provided for more than one Python version. There are several approaches that could be taken to avoid this, which will be explored below, but this PEP proposes a fairly simple compile-time option to allow extension modules to live in the same file system directory and avoid any name collisions. Proposal A new configure option is added for building Python, called `--with-so-abi-tag`. This takes as an argument a unique, but arbitrary string, e.g.:: ./configure --with-so-abi-tag=cpython-32 This string is passed into the `Makefile` and affects two aspects of the Python build. First, it is compiled into `Python/dynload_shlib.c` where it defines some additional `.so` file names to search for when importing extension modules. Second, it modifies the `Makefile`'s `$SO` variable, which in turn controls the `distutils` module's default filename when compiling extension modules. When `--with-so-abi-tag` is not given to `configure` nothing changes in the way the Python executable is built, or acts. Thus, this configure switch is completely optional and has no effect if not used. What this allows is for distributions that want to distinguish among extension modules built for different versions of Python, but shared in the same file system path, to arrange for `.so` names that are unique and non-colliding. For example, let's say Python 3.2 was built with::
Re: [Python-Dev] Removing IDLE from the standard library
2010/7/14 Greg Ewing greg.ew...@canterbury.ac.nz: Giampaolo Rodolà wrote: One of the main problems with IDLE is the lack of tabs for editing multiple files within the same window. While tabs seem to work well for web browsing, I'm not so sure about using them for source editing. Often I want to display two or more files side by side, which can't be done if they're in different tabs of the same window. Adding tabs doesn't necessarily mean a single window, you should be able to continue using multiple windows with single tabs if that is your preference. -- Greg -- -- Guilherme H. Polo Goncalves ___ 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] Removing IDLE from the standard library
Guilherme Polo writes: Adding tabs doesn't necessarily mean a single window, you should be able to continue using multiple windows with single tabs if that is your preference. But it's very important to be able to *move* tabs across windows or panes. For example, in XEmacs this is a somewhat frequent pattern for me: C-x C-f /some/long/path/foo.c# edit foo.c # work for a while ... oops, need to see what's up with foo.h C-x C-f foo.h# look Ma, no path! # want to see both simultaneously to work on several prototypes in succession C-x 5 b foo.c# pull up foo.c in a new X # window, use mouse to position That's quite painless. In many apps, however, you would have to select the foo.c tab, close it, bring up a new window, and open foo.c using the long path (presumably with a file browser interface, but often enough the default directory is wherever you started the editor, not most recently used file). Recent Files may help, but even there some apps don't register a file with Recent Files unless it's been changed. Since these considerations are somewhat subtle, I think it's worth mentioning for your consideration. Eg, it's *not* clear to me that Recent Files should contain every file you've looked at, but if it doesn't, it has the bad effect described above. So if you're not registering a file with recent files, there should be some other shortcut way to move its display (eg, in a tab) across windows. N.B. While I personally love Emacsen (so there, Nick Coghlan!), I don't recommend modeling anything in IDLE on Emacs UIs, which were designed by a guy with RSI who couldn't pay rent (until after he got the MacArthur) let alone buy a 640x480-graphics-capable monitor. :-) ___ 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] Removing IDLE from the standard library
Stephen J. Turnbull: But it's very important to be able to *move* tabs across windows or panes. ... In many apps, however, you would have to select the foo.c tab, close it, bring up a new window, and open foo.c using the long path (presumably with a file browser interface, but often enough the default directory is wherever you started the editor, not most recently used file). The common GUI technique is to drag a tab from one window into another window. Drag onto the desktop for a new top level window. This is supported by, among others, Firefox; Chrome; gedit; and GNOME Terminal. Neil ___ 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
