[Python-Dev] ABCs and MRO
2009/3/2 Benjamin Peterson : > 2009/3/1 Paul Moore : >> >> Is it worth getting simplegeneric exposed in 3.1 >> (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd >> like to see it hit 3.1. The patch is against trunk (for 2.7) at the >> moment, I'm not sure what the process would be for forward-porting it >> (do I generate a new patch against the py3k branch, or should it be >> applied to trunk and merged in?) > > Patches to the trunk are fine. OK, thanks. > As for the actual feature, I don't think it should hold up releases. Fair enough. The key problem with the patch is that ABCs do not play well with the type of introspection required to implement a generic function - namely enumeration of the superclasses of a class. The MRO of the class is fine for normal inheritance, but for ABCs it is possible to register classes which don't inherit from the ABC, so that you have a situation where issubclass (C, MyABC) can be true without MyABC being in C.__mro__: >>> import abc >>> class MyABC(object): ... __metaclass__ = abc.ABCMeta ... >>> class C(object): ... pass ... >>> MyABC.register(C) >>> issubclass(C, MyABC) True >>> C.__mro__ (, ) >>> More generally, there is NO WAY to determine the list of classes for which issubclass(C, x) is true. This could be considered a limitation of, or a bug in, ABCs, I don't have a particular opinion on that, but it does mean that no code which relies on being able to traverse the class inheritance graph will see ABCs. One particular case of this is (any implementation I can think of, of) generic functions. In my view, this implies one of the following: 1) It should be a documented limitation of such code that it doesn't work with ABCs (and conversely, this limitation of ABCs should be documented in the ABC documentation) 2) Generic functions, and any other code requiring this type of introspection, is essentially useless unless it can support ABCs, and should not be used in the light of this limitation. 3) This is a bug in ABCs and should be fixed. 4) Something else I didn't think of :-) In my view, (2) is an unreasonable position to take, given the fact that (as I understand it) ABCs are supposed to be largely optional and shouldn't affect code that doesn't care about them... It's not clear to me how (3) should be addressed. Adding a slot to all classes to hold a list of ABCs they are registered against seems to be a large overhead for a relatively rarely used feature. I guess having a global registry of ABC registrations could work, but it seems clumsy. Any other suggestions? The problem with (1) is that it simply acknowledges the issue, but doesn't actually fix it. Nick Coghlan has commented (in the tracker) that he feels that the limitation is significant (enough to push him from +1 to -0 on the feature). I have created an issue in the tracker - http://bugs.python.org/issue5405. In my view, it's fairly critical, but I've refrained from setting a high priority as that may just be my vested interest talking :-) I'd appreciate it if someone could comment (either here or on the tracker item) on what the correct way forward should be. If the answer is "fix the ABC bug", then I'll have a look but I'm not sure if I can do it without help - any assistance would be appreciated. Paul. ___ 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] test_io fails on test_1686475
On Mar, 02 2009 at 00:13AM, Amaury Forgeot d'Arc wrote: > Hello, > > On Sun, Mar 1, 2009 at 23:04, Cesare Di Mauro > wrote: >> Running the test suite with Python 2.6.1 32 bit (compiled in DEBUG mode >> with Visual Studio Express Edition 2008) on Vista x64, I've got an assert >> error: >> >> test_1686475 (__main__.StatAttributeTests) ... Assertion failed: >> (__int64)(int)((in / 1000) - secs_between_epochs) == ((in / 1000) >> - secs_between_epochs), file ..\Modules\posixmodule.c, line 790 >> >> I have no idea about this failure. Any hint? > > The failing assertion comes from this code in posixmodule.c: > > /* XXX Win32 supports time stamps past 2038; we currently don't */ > *time_out = Py_SAFE_DOWNCAST((in / 1000) - secs_between_epochs, > __int64, int); > > the test (btw, it's in test_os.py) is trying > os.stat(r"c:\pagefile.sys") > > Can you please check the three time stamps of this file (creation, > update, access)? > You are right. The last modified timestamp had 2099 as year value (the maximum that I can set on Windows), because of some tests with dates which I made at the time. However, they are correct timestamps for Windows files, so I think that at least the API on posixmodule.c should not fail when working with them. I don't know if there's a way to handle them correctly. Also may be that test_os.py need to be changed in some way, because the pagefile can be put in any partition, and there are Windows installations which lack it, because the virtual memory can be disabled too. Cheers Cesare ___ 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 do I get commit access?
s...@pobox.com wrote: Christian> CPython has a stricter policy than most other Python related Christian> projects. Indeed. I'd be willing to grant you checkin privileges for SpamBayes simply because because Christian recognized you and you seem willing to roll up your sleeves. Do you do Windows? The irony that Thunderbird put this in my spam folder based on its heuristics is not lost on me ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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] test_io fails on test_1686475
Cesare Di Mauro wrote: > However, they are correct timestamps for Windows files, so I think that at > least > the API on posixmodule.c should not fail when working with them. I don't know > if > there's a way to handle them correctly. Use 64-bit time values (which is highly unlikely to ever be the case for CPython on a 32-bit OS). 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
[Python-Dev] ABCs and simplegeneric use case
2009/3/1 Nick Coghlan : > As much as I'd like to get a simple generic implementation into > functools, the lack of support for ABCs still bothers me (despite my > last post about that on the tracker item). I'd be a -0 on it going in as > is, but if someone can figure out a clever way of supporting ABCs > without completing killing the invocation speed for generics, that would > go up to a +1. Nick, Armin Ronacher pointed out that it's not likely to be possible to enumerate ABCs even in theory, as ABCs can do semantic checks (e.g. checking for the presence of special methods like __iter__) without needing either inheritance or explicit registration. As you had a genuine use case for simplegeneric, how badly does this limitation damage it? Paul. ___ 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
Raymond Hettinger rcn.com> writes: > > Guido, I'm recommending this PEP for acceptance. Given you were bitten by it in your own unit tests (the "eval(repr()) does not maintain ordering" problem pointed by Georg), I think it would be better to reconsider the current __eq__ behaviour, and make it ordering-aware. 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
[Python-Dev] help-tkinter
Dear Sir, I have a fortran-95 code for my own mathematical application . and also I have the *.exe fiel for the same. when I double click it , it will run. I want to make a GUI for it by using TKinter and run the program through the button on GUI. Could you please send the syntax for the same? Thanks in advance for your help. Thanks. Regards Ramesh___ 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] Integrate BeautifulSoup into stdlib?
I haven't seen a lot of discussion on this - maybe I didn't search hard enough - but what are people's thoughts on including BeautifulSoup in stdlib? It's small, fast, and pretty widely-liked by the people who know about it. Someone mentioned that web scraping needs are infrequent. My argument is that people ask questions about them less because they feel they can just reinvent the wheel really easily using urllib and regexes. It seems like this is similar to the CSV problem from a while back actually, with everyone implementing their own parsers. We do have HTMLParser, but that doesn't handle malformed pages well, and just isn't as nice as BeautifulSoup. In a not-entirely-unrelated vein, has there been any discussion on just throwing all of Mechanize into stdlib? BeautifulSoup: http://www.crummy.com/software/BeautifulSoup/ mechanize: http://wwwsearch.sourceforge.net/mechanize/ Regards, Vaibhav Mallya ___ 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] executable
Hello, I want to ask if it is possible to link a program written in python to a database and also on how to make a program written in python executable. Regards ___ 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] executable
2009/3/2 toks teewey : > Hello, > > I want to ask if it is possible to link a program written in python to a > database and also on how > to make a program written in python executable. This list is for the development of Python, not language questions. Please mail python-l...@python.org -- 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] Integrate BeautifulSoup into stdlib?
On Mon, Mar 2, 2009 at 04:23, Vaibhav Mallya wrote: > I haven't seen a lot of discussion on this - maybe I didn't search hard > enough - but what are people's thoughts on including BeautifulSoup in > stdlib? It's small, fast, and pretty widely-liked by the people who know > about it. Someone mentioned that web scraping needs are infrequent. My > argument is that people ask questions about them less because they feel they > can just reinvent the wheel really easily using urllib and regexes. It seems > like this is similar to the CSV problem from a while back actually, with > everyone implementing their own parsers. > > We do have HTMLParser, but that doesn't handle malformed pages well, and > just isn't as nice as BeautifulSoup. > > In a not-entirely-unrelated vein, has there been any discussion on just > throwing all of Mechanize into stdlib? Discussions of including modules in the standard library only occurs when the module creators step forward to offer to support the modules. To my knowledge neither the creators of BeautifulSoup or Mechanize have come forward to offer to manage the code in Python's standard library. -Brett ___ 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] help-tkinter
ramesh nayak wrote: > Dear Sir, > I have a fortran-95 code for my own mathematical application . > > and also I have the *.exe fiel for the same. when I double click it , it > will run. > > I want to make a GUI for it by using TKinter and run the program through > the button on GUI. > > Could you please send the syntax for the same? > This list is for the development *of* Python. Your question would be better addressed to comp.lang.python (python-list at python dot org). There are many people on that list who will be able to help you. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 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] How do I get commit access?
>> Indeed. I'd be willing to grant you checkin privileges for SpamBayes >> simply because because Christian recognized you and you seem willing >> to roll up your sleeves. Do you do Windows? Chris> The irony that Thunderbird put this in my spam folder based on Chris> its heuristics is not lost on me ;-) So, when can you start? :-) S ___ 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 do I get commit access?
s...@pobox.com wrote: >> Indeed. I'd be willing to grant you checkin privileges for SpamBayes >> simply because because Christian recognized you and you seem willing >> to roll up your sleeves. Do you do Windows? Chris> The irony that Thunderbird put this in my spam folder based on Chris> its heuristics is not lost on me ;-) So, when can you start? :-) When the test and patch attached to this issue get committed: http://bugs.python.org/issue4308 Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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] ABCs and MRO
At 10:41 AM 3/2/2009 +, Paul Moore wrote: 2009/3/2 Benjamin Peterson : > 2009/3/1 Paul Moore : >> >> Is it worth getting simplegeneric exposed in 3.1 >> (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd >> like to see it hit 3.1. The patch is against trunk (for 2.7) at the >> moment, I'm not sure what the process would be for forward-porting it >> (do I generate a new patch against the py3k branch, or should it be >> applied to trunk and merged in?) By the way guys, are you aware of: http://pypi.python.org/pypi/simplegeneric There might be a bit of name confusion by exposing pkgutils' internal simplegeneric there. Perhaps it should be called "trivialgeneric", as it's even tinier than simplegeneric. ;-) The key problem with the patch is that ABCs do not play well with the type of introspection required to implement a generic function - namely enumeration of the superclasses of a class. The MRO of the class is fine for normal inheritance, but for ABCs it is possible to register classes which don't inherit from the ABC, so that you have a situation where issubclass (C, MyABC) can be true without MyABC being in C.__mro__: >>> import abc >>> class MyABC(object): ... __metaclass__ = abc.ABCMeta ... >>> class C(object): ... pass ... >>> MyABC.register(C) >>> issubclass(C, MyABC) True >>> C.__mro__ (, ) >>> More generally, there is NO WAY to determine the list of classes for which issubclass(C, x) is true. This could be considered a limitation of, or a bug in, ABCs, I don't have a particular opinion on that, but it does mean that no code which relies on being able to traverse the class inheritance graph will see ABCs. One particular case of this is (any implementation I can think of, of) generic functions. In my view, this implies one of the following: 1) It should be a documented limitation of such code that it doesn't work with ABCs (and conversely, this limitation of ABCs should be documented in the ABC documentation) 2) Generic functions, and any other code requiring this type of introspection, is essentially useless unless it can support ABCs, and should not be used in the light of this limitation. 3) This is a bug in ABCs and should be fixed. 4) Something else I didn't think of :-) In my view, (2) is an unreasonable position to take, given the fact that (as I understand it) ABCs are supposed to be largely optional and shouldn't affect code that doesn't care about them... It's not clear to me how (3) should be addressed. Adding a slot to all classes to hold a list of ABCs they are registered against seems to be a large overhead for a relatively rarely used feature. I guess having a global registry of ABC registrations could work, but it seems clumsy. Any other suggestions? This isn't really a new problem; if you base your generic function methods off of interfaces implemented by a type or instance, you have the same basic issues. For systems that use a cache based on object type (like Guido's tuple-dispatch prototype, and my enhanced version in PEAK-Rules), the actual lookup is not a big deal. You have a type-based test and you cache the result for the type. PEAK-Rules' predicate dispatching is a bit more complex, because you need a rather more complex type test; the tree generator has to look at whether a type test is an ABC, and effectively translate it to "oldstyleisinstance(arg, ABC) or not oldstyleisinstance(arg, ABC) and ABC.__instancecheck__(arg)". (Where oldstyleisinstance represents an __instancecheck__-free version of isinstance.) This isn't a major problem either, just a bit of a bore/pain to implement. The hairier issue for these types of systems is method precedence, though. Since __mro__'s have to be consistently ordered, you can straightforwardly determine whether one class is "more specific" than another in a static way. But with dynamic registration, the question could be more complex. Personally, I'd like to see some way to subscribe to changes in ABC registration, so that generic functions or other tools can update their caches. With that feature, you might even be able to implement full ABC support for simplegeneric, by treating ABC registrations as equivalent to mass registration of the ABC's registrants. That is, if "AnABC.register(X)" and "afunc.register(AnABC, meth)" then "afunc.register(X, meth)". So each time AnABC gets a new registrant, you automatically register the ABC method for the new registrant, as long as there's not already a method registered for that specific type. That would probably be sufficient for what simplegeneric is doing. ___ 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] ABCs and MRO
Paul Moore wrote: 2009/3/2 Benjamin Peterson : 2009/3/1 Paul Moore : Is it worth getting simplegeneric exposed in 3.1 (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd like to see it hit 3.1. The patch is against trunk (for 2.7) at the moment, I'm not sure what the process would be for forward-porting it (do I generate a new patch against the py3k branch, or should it be applied to trunk and merged in?) Patches to the trunk are fine. OK, thanks. As for the actual feature, I don't think it should hold up releases. Fair enough. Given that the purpose of 2.7 is a) maintenance of existing code (which can include minor new features for existing facilities), and b) easing conversion of code to 3.1 I am puzzled at the idea of adding a new facility to 2.7 that would not be in 3.1+. It would lock code into 2.7+ and counter purpose b). The key problem with the patch is that ABCs do not play well with the type of introspection required to implement a generic function - namely enumeration of the superclasses of a class. The MRO of the class is fine for normal inheritance, but for ABCs it is possible to register classes which don't inherit from the ABC, so that you have a situation where issubclass (C, MyABC) can be true without MyABC being in C.__mro__: I have no idea of what the solution should be other than your proposed 'document the limitations', but someone who has moved on to 3.x and is only interested in generics would find it frustrating to be denied them because of the existence of something else they are not using. 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] test_io fails on test_1686475
On Mon, Mar 2, 2009 at 13:25, Nick Coghlan wrote: > Cesare Di Mauro wrote: >> However, they are correct timestamps for Windows files, so I think that at >> least >> the API on posixmodule.c should not fail when working with them. I don't >> know if >> there's a way to handle them correctly. > > Use 64-bit time values (which is highly unlikely to ever be the case for > CPython on a 32-bit OS). 64bit time_t is the default since VS2005. See the patch at http://bugs.python.org/issue4379 -- Amaury Forgeot d'Arc ___ 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
[Antoine Pitrou] Given you were bitten by it in your own unit tests (the "eval(repr()) does not maintain ordering" problem pointed by Georg), Completely unrelated. The original test passed because the arbitrarily ordered data in the regular dict happened to match the order added in a regular dict because I didn't shuffle the keys. There was no direct dict-to-ordered dictcomparison. Had the __eq__ method been defined differently, the test still would have passed (had a false positive). I think it would be better to reconsider the current __eq__ behaviour, and make it ordering-aware. If someone wants to explicitly ask for an order-sensitive comparison, the docs give a clear, simple example of how to do that. Otherwise, it's best to leave regular dict equality in-place because OrderedDicts need to be substitutable anywhere dicts are used and some of those places may make the assumption that order insensitive compares are being used. Also, the PEP outlines another issue with trying to make comparisons order sensitive. It leads to weirdness with ordereddict-to-dict comparisons making a behavior shift based on the type of one of the two inputs. It's just asking for problems and it introduces an unnecessary difference from regular dicts. Given that either choice will be surprising to someone, we opted for the simplest API with the fewest special cases and made sure the choice was clearly noted in the docs. Raymond ___ 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] ABCs and MRO
2009/3/2 P.J. Eby :
> By the way guys, are you aware of:
>
> http://pypi.python.org/pypi/simplegeneric
Yes. It has been mentioned, and I am certainly aware of both it and
RuleDispatch.
> There might be a bit of name confusion by exposing pkgutils' internal
> simplegeneric there. Perhaps it should be called "trivialgeneric", as it's
> even tinier than simplegeneric. ;-)
:-)
The problem is that any discussion of more than the bare minimum
functionality regularly results in people's heads exploding. Most
specifically, Guido usually ends up hating the whole idea when it gets
too complex. I'd rather stick with the most basic (and frankly,
useful) aspects and avoid the headaches and messy explosions :-)
> This isn't really a new problem; if you base your generic function methods
> off of interfaces implemented by a type or instance, you have the same basic
> issues.
[...]
See? You just made my head hurt :-)
> Personally, I'd like to see some way to subscribe to changes in ABC
> registration, so that generic functions or other tools can update their
> caches. With that feature, you might even be able to implement full ABC
> support for simplegeneric, by treating ABC registrations as equivalent to
> mass registration of the ABC's registrants.
But the issue is that the __subclasshook__ method allows things to be
virtual subclasses of an ABC without either being a real subclass,
*or* being explicitly registered. There simply is no way to answer the
question "which ABCs does this class implement" and get such ABCs
reported in the answer.
Consider:
class MyABC:
__metaclass__ = ABCMeta
@classmethod
def __subclasshook__(cls, C):
if cls is MyABC:
if any("foo" in B.__dict__ for B in C.__mro__):
return True
return NotImplemented
class C(object):
def foo(self):
pass
c = C()
Here, isinstance(c, MyABC) is True. But if f is a generic function
with a registered implementation for MyABC, the only way I can see of
ensuring that f(c) calls that implementation, would be to test
isinstance(c, ImlCls) for all ImplCls for which there is a registered
implementation. There'd need to be a cache of results of some form, to
avoid a serious performance penalty, and it's not entirely obvious
what the definition of "best fit" would be.
That may be what you just said. :-)
But regardless, this is getting beyond what I'd describe as "simple",
and certainly is beyond any remit of tweaking pkgutil.simplegeneric to
make it public.
So either pkgutil.simplegeneric is useful with current (ignoring ABC)
semantics, or it isn't suitable for exposure. If the latter, someone
will have to propose a more complete implementation for the stdlib,
which is something that traditionally is doomed to failure :-(
So I don't intend to extend the functionality of
pkgutil.simplegeneric, and I await a decision on whether or not the
patch as it stands can go in. If the decision is that the current
implementation isn't powerful enough to be of any use, I'd suggest
that you propose your simplegeneric implementation for the stdlib
(enhancing it to handle the ABC issue, if it doesn't already). Or we
continue managing without generic functions in the stdlib, and the
pprint rewrite which started all this off, goes ahead with an adhoc
approach to extensibility.
Paul.
___
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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raymond, +1 on adding this to the stdlib. I especially like the idea of being able to use an ordered dict in a class's namespace. I might be able use something like that to make my enum package simpler (which currently requires assignment of the name to the integer sort order). I wanted to point out that the email package uses an ordered dictionary in its Message implementation. Messages present a dictionary-like API for its headers. I don't think I'd be able to use odicts though for this because of other semantic differences, e.g. multiple keys are allowed (though only visible through the non-mapping interface) and KeyError is never raised (like a defaultdict with a __missing__() returning None). Note though that Message's odict-like implementation is about as horribly gross as it can be: it's just a list with linear searching for key lookup. Messages should not have a billion headers. ;) Have you or Armin considered the possibility of wanting both the defaultdict and odict behavior in, say a mixin subclass? Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSawRPXEjvBPtnXfVAQIunwQAlty1Gk3EByWK1fwOaN7+X/eC4QN4YpJL MxWy5l/So3zUM/ofu32kLEjnBLmZOZFp28ExP5QTgse6c0VzNIGP9s6JrZeeAZ7s uYk+EPChLw2GWuFgLQERpHnX9MA3XpCMbv+SheuqBROs31I7L/TCbDISk3+nOjtA LngNgWVlKW4= =glyD -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] PEP 372 -- Adding an ordered directory t o collectionsready for pronouncement
Raymond Hettinger rcn.com> writes: > Completely unrelated. The original test passed because the arbitrarily > ordered data in the regular dict happened to match the order added in > a regular dict because I didn't shuffle the keys. Well, I may be mistaken, but it seems your test_copying (in od5.diff) still fails to check that ordering is preserved after a copy. Unless it's not part of the contract, but then the datatype would really be ill-designed IMO. > If someone wants to explicitly ask for an order-sensitive comparison, > the docs give a clear, simple example of how to do that. That's not the point. The point is that it's not enabled by default, which is rather awkward since the whole point of the OrderedDict is that it is ordering-sensitive. Right now, equality of ordering-sensitive datatypes (e.g. list) is ordering-sensitive by default. And equality of ordering-insensitive datatypes (e.g. set) is ordering-insensitive by default. > Otherwise, > it's best to leave regular dict equality in-place because OrderedDicts > need to be substitutable anywhere dicts are used and some of those > places may make the assumption that order insensitive compares are > being used. You seem to imply that it is more important for __eq__ to work intuitively between a non-OrderedDict and an OrderedDict, than it is to work intuitively between two OrderedDicts. It doesn't look like a common principle in Python. Witness: >>> list(range(3)) == set(range(3)) False >>> list(range(3)) == tuple(range(3)) False >>> 1 == Decimal(1) True >>> 1 == 1.0 True >>> 1.0 == Decimal(1) False IMO, comparison between different types should be "best effort", and not at the price of making comparison between values of the same type less intuitive. > It's just asking > for problems and it introduces an unnecessary difference > from regular dicts. What you call an "unnecessary difference" seems to be the whole motivation for introducing OrderedDicts. I see no point in trying to mitigate that difference if the new type is to be genuinely useful. > Given that either choice will be surprising to someone, we opted > for the simplest API with the fewest special cases But the current __eq__ does look like a special case, given the intended semantics of the new datatype. Not having a special case would imply having an ordering-sensitive comparison. 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
[Antoine Pitrou] You seem to imply that it is more important for __eq__ to work intuitively between a non-OrderedDict and an OrderedDict, than it is to work intuitively between two OrderedDicts. Yes. When Armin and I worked through this, it became clear that he had multiple use cases where ordered dicts needed to be used in places that had been originally designed to expect regular dicts. That was also the reason for subclassing dict. Otherwise, we would have just made a standalone class that defined all the mapping methods. I don't think we going to convince you and that's okay. We don't have to agree on every design decision. There were some reasons for either approach and we picked the one that best fit Armin's use cases, that was simplest, that introduced the fewest special rules, and did not create a Liskov violation. The choice was clearly documented and an alternative was provided for people that needed it. Outside of your differing judgment on the __eq__ method, are you basically happy with the ordered dict PEP? Raymond ___ 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
On Mon, Mar 2, 2009 at 9:39 AM, Raymond Hettinger wrote: > > [Antoine Pitrou] >> >> You seem to imply that it is more important for __eq__ to work intuitively >> between a non-OrderedDict and an OrderedDict, than it is to work >> intuitively >> between two OrderedDicts. > > Yes. When Armin and I worked through this, it became clear that > he had multiple use cases where ordered dicts needed to be used > in places that had been originally designed to expect regular dicts. > That was also the reason for subclassing dict. Otherwise, we would > have just made a standalone class that defined all the mapping methods. > > I don't think we going to convince you and that's okay. We don't > have to agree on every design decision. There were some reasons > for either approach and we picked the one that best fit Armin's use > cases, that was simplest, that introduced the fewest special rules, > and did not create a Liskov violation. The choice was clearly > documented and an alternative was provided for people that > needed it. But you'll have to convince me, and so far I agree with Antoine that doing the comparison without taking the order into account feels really weird. I also think that comparing an odict to a dict with the same items and expecting them to be the same feels wrong. It is not needed to invoke Liskov: Liskov cares about the signature, not about the computed value. There is no rule that says you are not allowed to override odict.__eq__ so that it returns False in cases where Mapping.__eq__ returns True. I would propose the following formal specification for odict.__eq__: def __eq__(self, other): if not isinstance(other, odict): return NotImplemented # Give other a chance; defaults to False return list(self.items()) == list(other.items()) Obviously an actual implementation can do something more complex instead of the last line, like: for a, b in zip(self.items(), other.items()): if a != b: return False return True > Outside of your differing judgment on the __eq__ method, are you > basically happy with the ordered dict PEP? I am. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] ABCs and MRO
On Mon, Mar 2, 2009 at 2:41 AM, Paul Moore wrote: > ... > More generally, there is NO WAY to determine the list of classes for > which issubclass(C, x) is true. > > This could be considered a limitation of, or a bug in, ABCs, I don't > have a particular opinion on that, but it does mean that no code which > relies on being able to traverse the class inheritance graph will see > ABCs. One particular case of this is (any implementation I can think > of, of) generic functions. > > In my view, this implies one of the following: > > 1) It should be a documented limitation of such code that it doesn't > work with ABCs (and conversely, this limitation of ABCs should be > documented in the ABC documentation) > 2) Generic functions, and any other code requiring this type of > introspection, is essentially useless unless it can support ABCs, and > should not be used in the light of this limitation. > 3) This is a bug in ABCs and should be fixed. > 4) Something else I didn't think of :-) I tend to think it's a bug in ABCs. You seem to have thought of several possible ways to fix it, and I don't have strong preferences between them. One way to deal with __subclasscheck__ definitions other than ABCMeta.__subclasscheck__ would be to make the "someone registered a subclass" interface public in addition to the "tell me when someone registers a subclass" interface. Then other __subclasscheck__ definitions could call the "someone registered a subclass" method when the class is defined if they want to be usable with generic functions. You can get something similar to the mro by checking whether ABCs are subclasses of each other. Jeffrey ___ 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 do I get commit access?
On Mon, Mar 2, 2009 at 7:26 AM, Chris Withers wrote: > s...@pobox.com wrote: >> >> >> Indeed. I'd be willing to grant you checkin privileges for >> SpamBayes >> >> simply because because Christian recognized you and you seem willing >> >> to roll up your sleeves. Do you do Windows? >> >> Chris> The irony that Thunderbird put this in my spam folder based on >> Chris> its heuristics is not lost on me ;-) >> >> So, when can you start? :-) > > When the test and patch attached to this issue get committed: > > http://bugs.python.org/issue4308 I'd like to jump in and vouch for Chris. I've known him for many years and while we haven't worked closely I expect he'd be a valuable contributor. So +1 from me for giving Chris commit privileges for core Python. (Chris, I assume you'll go through an apprentice phase where you'll be letting another committer review your changes before you commit them yourself. Rietveld at codereview.appspot.com should be helpful for getting your code reviewed. (Just use upload.py instead of the Create Issue form. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
But you'll have to convince me, Okay, here's one stab at it. If it doesn't take, I give in. ISTM, either way is right depending on your point of view and what you're trying do at the time. My judgment tips in favor of not specializing the __eq__ method. But it is not lost on me why one might think that something that iterates in a specified order would also make an order sensitive comparison. Liskov cares about the signature, not about the computed value. That wasn't my understanding. I thought it was entirely about computed values, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T." Or phrased differently, "In class hierarchies, it should be possible to treat a specialized object as if it were a base class object." In this case, Armin wants to be able to pass in an ordered dictionary to functions that weren't designed with ordered dicts in mind (config parser, json/yaml parsers, nose, unittest, etc.). Those functions should be able to assume that all the usual dictionary properties are still true. In particular, those functions may make internal comparisons to a regular dict (perhaps as a cached value) and would expect those comparisons to succeed. > I would propose the following formal specification for odict.__eq__: def __eq__(self, other): if not isinstance(other, odict): return NotImplemented # Give other a chance; defaults to False return list(self.items()) == list(other.items()) If I haven't convinced you, then I would be happy to put this in. Outside of your differing judgment on the __eq__ method, are you basically happy with the ordered dict PEP? I am. Once you've decided on __eq__, can I mark the PEP as approved? Raymond ___ 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
On Mon, Mar 2, 2009 at 11:20 AM, Raymond Hettinger wrote: >> But you'll have to convince me, > > Okay, here's one stab at it. If it doesn't take, I give in. > ISTM, either way is right depending on your point of view and what > you're trying do at the time. My judgment tips in favor of not > specializing the __eq__ method. Comparing dicts is relatively uncommon. So we'd have to find and look at use cases to decide. > But it is not lost on me why > one might think that something that iterates in a specified order > would also make an order sensitive comparison. My hunch is that not taking the ordering into account is going to confuse people who consciously use odicts and bother to compare them. I expect this is going to be a FAQ, no matter how much you try to document it -- especially since the concept of an odict is so simple and the API so clean that most people will not bother reading *any* docs. I expect this to be the most common use case. Use cases where people compare mappings knowing they may have different concrete types are probably exceedingly rare, and if I was doing that I wouldn't rely on __eq__ not being overridden -- IOW I'd either explicitly invoke Mapping.__eq__(a, b) or write the equivalent code myself. The third class of use case is people comparing dicts not thinking much about the possibility of there being a subclass that overrides __eq__, and being surprised by the substitution of an odict. This seems to be the use case you favor; to me it seems pretty rare too. To convince me otherwise you'd have to find a common use case that does this *and* is likely to encounter an odict in real life. >> Liskov cares about the signature, not about the computed value. > > That wasn't my understanding. I thought it was entirely about computed > values, "Let q(x) be a property provable about objects x of type T. Then > q(y) should be true for objects y of type S where S is a subtype of T." Or > phrased differently, "In class hierarchies, it should be possible to treat a > specialized object as if it were a base class object." This strict interpretation is violated all the time in OO programming; consider e.g. the common overriding of object.__repr__. (In fact, even the definition of dict.__eq__ overriding object.__eq__ would validate it.) AFAIK a more common use of the term in OO languages is about signatures only: if a method of class C accepts an argument of type T, then you shouldn't override that method in a class D derived from C to require an argument type S which is a subtype of T. (This is also known as Contravariance. Read the section on Design by contract in http://en.wikipedia.org/wiki/Liskov_substitution_principle.) > In this case, Armin wants to be able to pass in an ordered dictionary to > functions that weren't designed with ordered dicts in mind (config parser, > json/yaml parsers, nose, unittest, etc.). Those functions should be able to > assume that all the usual dictionary properties are still true. In > particular, those functions may make internal comparisons to a regular dict > (perhaps as a cached value) and would expect those comparisons to succeed. That's a hypothetical use case. Have you found any real code that uses __eq__ on dicts in this matter? >> I would propose the following formal specification for odict.__eq__: >> >> def __eq__(self, other): >> if not isinstance(other, odict): >> return NotImplemented # Give other a chance; defaults to False >> return list(self.items()) == list(other.items()) > > > If I haven't convinced you, then I would be happy to put this in. Great. >>> Outside of your differing judgment on the __eq__ method, are you >>> basically happy with the ordered dict PEP? > >> I am. > > Once you've decided on __eq__, can I mark the PEP as approved? Yes. (With the caveat that I haven't read it very closely, but the basic spec seems sound apart from the __eq__ issue.) Hm, I wonder if you should spec odict.__repr__ (and hence odict.__str__). It would be confusing if an odict's repr() were the same as a plain dict's. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 372 -- Adding an ordered directory tocollectionsready for pronouncement
[Me] In this case, Armin wants to be able to pass in an ordered dictionary to functions that weren't designed with ordered dicts in mind (config parser, json/yaml parsers, nose, unittest, etc.). Those functions should be able to assume that all the usual dictionary properties are still true. In particular, those functions may make internal comparisons to a regular dict (perhaps as a cached value) and would expect those comparisons to succeed. One other thought: I was intending to modify namedtuple's _asdict() method to return an OrderedDict but don't want to break any existing code that relies on the returned object having an order insensitive comparison. A object that currently returns a dict should be able to return an OrderedDict without breaking anything. The proposed change precludes this possibility as well as the ones mentioned above. Raymond ___ 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] PEP 372 -- Adding an ordered directory tocollectionsready for pronouncement
On Mon, Mar 2, 2009 at 11:47 AM, Raymond Hettinger wrote: > [Me] >> >> In this case, Armin wants to be able to pass in an ordered dictionary to >> functions that weren't designed with ordered dicts in mind (config parser, >> json/yaml parsers, nose, unittest, etc.). Those functions should be able to >> assume that all the usual dictionary properties are still true. In >> particular, those functions may make internal comparisons to a regular dict >> (perhaps as a cached value) and would expect those comparisons to succeed. > > One other thought: I was intending to modify namedtuple's _asdict() method > to return an OrderedDict but don't want to break any existing code that > relies on the returned object having an order insensitive comparison. But do you know if any code that relies on that? Have you ever written any yourself? If you really worry about this so much you could not make this change, or you'd have to return a custom subclass of odict that overrides __eq__ again. > A object that currently returns a dict should be able to return an > OrderedDict without breaking anything. The proposed change precludes this > possibility as well as the ones mentioned above. Well, such are the joys of strict backwards compatibility. If something works fine with a dict today, there's no strong need to return an odict tomorrow. You could always add a new API that returns an odict. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 372 -- Adding an ordered directory to collectionsready for pronouncement
> This strict interpretation is violated all the time in OO programming; > consider e.g. the common overriding of object.__repr__. (In fact, even > the definition of dict.__eq__ overriding object.__eq__ would validate > it.) AFAIK a more common use of the term in OO languages is about > signatures only: Slightly off-topic: I think what matters in reality is a difficult-to-formulate *specification* of the behavior of the operation also. I.e. not /all/ provable properties of the base implementation need to be maintained, but only those occurring in the specification of the base operation. Applications using the base then can only rely on the *specified* properties of the operations they use, and there you get substitutability. Of course, what properties are part of the specification is an ongoing discussion for many class hierarchies, in many languages (see e.g. the relationship between __eq__ and __hash__). Beyond transitivity and consistency with __hash__ (which is irrelevant here), I don't think odict.__eq__ should be restricted to behave the same as dict.__eq__. 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] PEP 372 -- Adding an ordered directory tocollectionsready for pronouncement
Compromise? def __eq__(self, other): if isinstance(other, OrderedDict): return all(map(operator.eq, self.items(), other.items())) if isinstance(other, Mapping): return dict.__eq__(self, other) return NotImplemented # Give other a chance; defaults to False OrderedDict-to-OrderedDict comparisons are order sensitive -- matching your intuition OrderedDict-to-OtherMappings -- allow me and Armin to have our substitutability for dicts. Raymond ___ 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] ABCs and simplegeneric use case
Paul Moore wrote: > 2009/3/1 Nick Coghlan : >> As much as I'd like to get a simple generic implementation into >> functools, the lack of support for ABCs still bothers me (despite my >> last post about that on the tracker item). I'd be a -0 on it going in as >> is, but if someone can figure out a clever way of supporting ABCs >> without completing killing the invocation speed for generics, that would >> go up to a +1. > > Nick, > Armin Ronacher pointed out that it's not likely to be possible to > enumerate ABCs even in theory, as ABCs can do semantic checks (e.g. > checking for the presence of special methods like __iter__) without > needing either inheritance or explicit registration. > > As you had a genuine use case for simplegeneric, how badly does this > limitation damage it? That's a very good point that Armin raises (i.e. that enumerating the ABCs a given class implements is impossible even in theory, let alone in practice). It is actually enough to put me back to the perspective that I posted on the tracker item: the failure to inherit generic function implementations when a class doesn't actually have the ABC in its MRO is similar in nature to the failure to inherit the ABCs own method implementations. It still bugs me a little, but I'll get over it :) 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] PEP 372 -- Adding an ordered directory tocollectionsready for pronouncement
On Mon, Mar 2, 2009 at 12:07 PM, Raymond Hettinger wrote: > Compromise? > > def __eq__(self, other): > if isinstance(other, OrderedDict): > return all(map(operator.eq, self.items(), other.items())) > if isinstance(other, Mapping): > return dict.__eq__(self, other) > return NotImplemented # Give other a chance; defaults to False > > OrderedDict-to-OrderedDict comparisons are order sensitive -- matching your > intuition > OrderedDict-to-OtherMappings -- allow me and Armin to have our > substitutability for dicts. This sounds fair. Note that dict.__eq__ actually returns NotImplemented if not isinstance(other, dict) so you could tighten the test to isinstance(other, dict) if you wanted to. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 372 -- Adding an ordered directory tocollectionsready for pronouncement
[GvR] This sounds fair. Note that dict.__eq__ actually returns NotImplemented if not isinstance(other, dict) so you could tighten the test to isinstance(other, dict) if you wanted to. Okay. Done deal. Raymond ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
2009/3/1 Armin Ronacher : > Hi everybody, > > PEP 372 was modified so that it provides a simpler API (only the dict API > to be exact) and it was decided to start with a Python-only implementation > and replace it with a C version later if necessary. > > Annotated changes from earlier versions of the PEP: > > - the extra API for ordered dict was dropped to keep the interface > simple and clean. Future versions can still be expanded but it's > impossible to drop features later on. > > - To keep the implementation simple 3.1 / 2.7 will ship with a > Python-only version of the class. It can still be rewritten in > C if it turns out to be too slow or thread safety is required. > > The corresponding issue in the tracker: http://bugs.python.org/issue5397 > Link to the PEP: http://www.python.org/dev/peps/pep-0372/ > > Anything else that should be done? Have you considered naming? I would think that "odict" or "ordereddict" would be more consistent with other collections names especially "defaultdict". -- 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] ABCs and MRO
Terry Reedy wrote: >>> As for the actual feature, I don't think it should hold up releases. >> >> Fair enough. > > Given that the purpose of 2.7 is > a) maintenance of existing code (which can include minor new features > for existing facilities), and > b) easing conversion of code to 3.1 > I am puzzled at the idea of adding a new facility to 2.7 that would not > be in 3.1+. It would lock code into 2.7+ and counter purpose b). It's possible we will end up in a situation where 3.0 and 3.1 are both aligned with 2.6, while 2.7 aligns with 3.2. That's particularly so with only 6 months or so between 3.0 and 3.1, while I currently expect the gap between 2.6 and 2.7 to be closer to the traditional 18 months. Of course, it will depend on how the relative timing of the releases plays out in practice :) 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] ABCs and MRO
2009/3/2 Jeffrey Yasskin : > I tend to think it's a bug in ABCs. You seem to have thought of > several possible ways to fix it, and I don't have strong preferences > between them. I've discussed ways of fixing simplegeneric, but not of fixing the issue with ABCs. I'm not sure the ABC "issue" is fixable - after all, it's by design that ABCs can implement __issubclass__ and "magically" become superclasses of arbitrary classes as a result. I'm not happy about fixing simplegeneric, though, as the whole point was just to expose an existing implementation, because it might be generally useful. If we start expanding and enhancing it, there are better implementations already available on PyPI (better in the sense of having seen real-world use). And if they don't handle ABCs, then that might indicate that needing to handle ABCs isn't as vital as this discussion would seem to imply (but I have no real-world data myself to make such a claim). > One way to deal with __subclasscheck__ definitions other than > ABCMeta.__subclasscheck__ would be to make the "someone registered a > subclass" interface public in addition to the "tell me when someone > registers a subclass" interface. Then other __subclasscheck__ > definitions could call the "someone registered a subclass" method when > the class is defined if they want to be usable with generic functions. I'm not sure I follow this. Can you clarify? My intuition is that *no* notification hook can deal with ABCs that code arbitrary checks in their __subclasscheck__ method (so there's no registration involved, particular classes just "magically" become subclasses). > You can get something similar to the mro by checking whether ABCs are > subclasses of each other. The key point about the MRO is that you get it just from the initial class, via __mro__. You're not checking if another class is *in* the MRO, but rather you're *generating* the list of classes in the MRO. Paul. ___ 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] draft 3.1 release schedule
Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively]. These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP files are executed with each restart. This allows loading frequently used packages, personal utilities, etc. automatically at each restart. I consider this a very important problem in IDLE, especially when using it to teach. I would really like to see them in 3.1. The patch is already there; someone just has to do whatever gets done with patches to validate it and check it in. It's not a lot of code changes. ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Benjamin Peterson schrieb: > 2009/3/1 Armin Ronacher : >> Hi everybody, >> >> PEP 372 was modified so that it provides a simpler API (only the dict API >> to be exact) and it was decided to start with a Python-only implementation >> and replace it with a C version later if necessary. >> >> Annotated changes from earlier versions of the PEP: >> >> - the extra API for ordered dict was dropped to keep the interface >>simple and clean. Future versions can still be expanded but it's >>impossible to drop features later on. >> >> - To keep the implementation simple 3.1 / 2.7 will ship with a >>Python-only version of the class. It can still be rewritten in >>C if it turns out to be too slow or thread safety is required. >> >> The corresponding issue in the tracker: http://bugs.python.org/issue5397 >> Link to the PEP: http://www.python.org/dev/peps/pep-0372/ >> >> Anything else that should be done? > > Have you considered naming? I would think that "odict" or > "ordereddict" would be more consistent with other collections names > especially "defaultdict". We're already quite inconsistent with type name casing in the collections module, so it wouldn't matter so much. (Though I'd find symmetry with defaultdict pleasing as well.) 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] PEP 372 -- Adding an ordered directory t ocollectionsready for pronouncement
Hi, Guido van Rossum python.org> writes: > This sounds fair. Note that dict.__eq__ actually returns > NotImplemented if not isinstance(other, dict) so you could tighten the > test to isinstance(other, dict) if you wanted to. I'm actually very happy with that decision. The original PEP was doing exactly that and I still think it makes more sense. [sorry Raymond :)] Regards, Armin ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Mon, Mar 2, 2009 at 1:28 PM, Georg Brandl wrote: > Benjamin Peterson schrieb: >> 2009/3/1 Armin Ronacher : >>> Hi everybody, >>> >>> PEP 372 was modified so that it provides a simpler API (only the dict API >>> to be exact) and it was decided to start with a Python-only implementation >>> and replace it with a C version later if necessary. >>> >>> Annotated changes from earlier versions of the PEP: >>> >>> - the extra API for ordered dict was dropped to keep the interface >>> simple and clean. Future versions can still be expanded but it's >>> impossible to drop features later on. >>> >>> - To keep the implementation simple 3.1 / 2.7 will ship with a >>> Python-only version of the class. It can still be rewritten in >>> C if it turns out to be too slow or thread safety is required. >>> >>> The corresponding issue in the tracker: http://bugs.python.org/issue5397 >>> Link to the PEP: http://www.python.org/dev/peps/pep-0372/ >>> >>> Anything else that should be done? >> >> Have you considered naming? I would think that "odict" or >> "ordereddict" would be more consistent with other collections names >> especially "defaultdict". > > We're already quite inconsistent with type name casing in the collections > module, so it wouldn't matter so much. (Though I'd find symmetry with > defaultdict pleasing as well.) +1 for odict. Somehow I thought that was the name proposed by the PEP. :-( -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Hi, Georg Brandl gmx.net> writes: > We're already quite inconsistent with type name casing in the collections > module, so it wouldn't matter so much. (Though I'd find symmetry with > defaultdict pleasing as well.) We either have the way to be consistent with defaultdict and dict or with Counter, MutableMapping etc. I think it's a bit too chaotic already to make a fair decision here. If we seriously consider a C implementation it would probably be a good idea to call it `odict`. C-Classes are usually lower cased as far as I can see. Regards, Armin ___ 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] ABCs and MRO
At 09:14 PM 3/2/2009 +, Paul Moore wrote: 2009/3/2 Jeffrey Yasskin : > I tend to think it's a bug in ABCs. You seem to have thought of > several possible ways to fix it, and I don't have strong preferences > between them. I've discussed ways of fixing simplegeneric, but not of fixing the issue with ABCs. I'm not sure the ABC "issue" is fixable - after all, it's by design that ABCs can implement __issubclass__ and "magically" become superclasses of arbitrary classes as a result. I'm not happy about fixing simplegeneric, though, as the whole point was just to expose an existing implementation, because it might be generally useful. If we start expanding and enhancing it, there are better implementations already available on PyPI (better in the sense of having seen real-world use). And if they don't handle ABCs, then that might indicate that needing to handle ABCs isn't as vital as this discussion would seem to imply (but I have no real-world data myself to make such a claim). I would say it's mainly an annoyance, as long as you have a way to access the method registered for a given ABC, because then you can explicitly register it for types that are being dynamically detected. Now, how widespread an annoyance/FAQ issue it'll be, will depend on: 1. whether the stdlib itself is using GF's and 2. whether those GF's are meaningfully used against ABCs, and 3. how common it is for classes to be "implicit subclasses" of one of those ABCs *and* used with one of those GFs. This sounds like a lot of conditions that have to line up, for it to become an (easily worked-around) annoyance. My inclination is simply to document that it works on explicit type relationships, and note that ABC's and other exotic users of __*check__ methods may require explicit method registrations to work correctly. ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Benjamin Peterson wrote: > 2009/3/1 Armin Ronacher : [...] >> The corresponding issue in the tracker: http://bugs.python.org/issue5397 >> Link to the PEP: http://www.python.org/dev/peps/pep-0372/ >> >> Anything else that should be done? > > Have you considered naming? I would think that "odict" or > "ordereddict" would be more consistent with other collections names > especially "defaultdict". > Surely that's just a thinko in the subject line? The PEP specifies "ordered dictionary" and nobody has been talking about "directories". regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
2009/3/2 Armin Ronacher : > Hi, > > Georg Brandl gmx.net> writes: > >> We're already quite inconsistent with type name casing in the collections >> module, so it wouldn't matter so much. (Though I'd find symmetry with >> defaultdict pleasing as well.) > We either have the way to be consistent with defaultdict and dict or with > Counter, MutableMapping etc. I think "normal" class names are fine for ABCs, but I brought it up because the other dictionary class in collections had a all lowername. > > I think it's a bit too chaotic already to make a fair decision here. If we > seriously consider a C implementation it would probably be a good idea to call > it `odict`. C-Classes are usually lower cased as far as I can see. I don't implementation language should determine naming. -- 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Guido van Rossum python.org> writes: > +1 for odict. Somehow I thought that was the name proposed by the PEP. It originally was, Raymond wanted to change it. I would still vote for odict if that's still possible :) Regards, Armin ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Steve Holden holdenweb.com> writes: > Surely that's just a thinko in the subject line? The PEP specifies > "ordered dictionary" and nobody has been talking about "directories". Actually, the initial version of the PEP had that typo in the topic. Guess I copy pasted wrong again: http://www.google.com/search?q=%22adding+an+ordered+directory%22 Regards, Armin ___ 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] PEP 372 -- Adding an ordered directory tocollections ready for pronouncement
My preference is OrderedDict. That says that it is a pure python class like Counter, UserDict, UserList, MutableMapping and other collections classes. It is clear and explicit in its intention and doesn't make you try to remember what the o in odict stands for. Raymond ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On 02/03/2009 22:28, Georg Brandl wrote: We're already quite inconsistent with type name casing in the collections module, so it wouldn't matter so much. (Though I'd find symmetry with defaultdict pleasing as well.) Since the odict naming is already so prevalent in the wild, it seems to me like that would be the best candidate. (Plus, it's shorter!) /bikeshedding 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] PEP 372 -- Adding an ordered directory tocollections ready for pronouncement
2009/3/2 Raymond Hettinger : > My preference is OrderedDict. > That says that it is a pure python class like Counter, UserDict, UserList, > MutableMapping and other collections classes. I don't understand why implementation language should have any significance in naming. Classes should be able to be implemented in any language transparently. > It is clear and explicit in its intention and doesn't make you try to > remember what the o in odict stands for. I agree and that's why I propose "ordereddict" -- 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
/bikeshedding Yes. Also we need to paint it green with pink polka dots :-) ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Guido van Rossum wrote: > +1 for odict. Somehow I thought that was the name proposed by the PEP. :-( The examples in the PEP used 'odict' (until recently), but the patch was for OrderedDict. I don't personally mind either way. 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Raymond Hettinger wrote: >> /bikeshedding > > Yes. Also we need to paint it green with pink polka dots :-) Or should that be pink with green polka dots? ;) 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] draft 3.1 release schedule
> Would whoever is responsible for IDLE please take a look at the patches > I submitted for Python 2 & 3 [tracker IDs 5233 and 5234 respectively]. > These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP > files are executed with each restart. This allows loading frequently > used packages, personal utilities, etc. automatically at each restart. I > consider this a very important problem in IDLE, especially when using it > to teach. Just to put this into perspective: I personally don't see that as a very important problem. I didn't know IDLESTARTUP existed, and I use PYTHONSTARTUP only for the command line (to setup readline and history). I think there are many more open issues that are *way* more important. This is not to say that the patch should not applied - I haven't even looked at it. It's just a warning that, if no other committer feels this is as important as you fell it is, it may not be committed reviewed and committed before 3.1. 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
[Nick Coghlan] The examples in the PEP used 'odict' (until recently), but the patch was for OrderedDict. As an experiment, try walking down the hall asking a few programmers who aren't in this conversion what they think collections.odict() is? Is it a class or function? What does it do? Can the English as second language folks guess what the o stands for? Is it a builtin or pure python? My guess is that the experiment will be informative. When we use the class, we typically only spell-out the constructor once while actually using the returned object many times. So, have we really saved any typing? In the context of other applications, which is clearer? json.loads(jtext, object_pairs_hook=odict) config = ConfigParser(dict_type=odict) or json.loads(jtext, object_pairs_hook=OrderedDict) config = ConfigParser(dict_type=OrderedDict) I find the former to be non-communicative. Raymond ___ 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] PEP 372 -- Adding an ordered directory t o collections ready for pronouncement
Raymond Hettinger rcn.com> writes: > > [Nick Coghlan] > > The examples in the PEP used 'odict' (until recently), but the patch was > > for OrderedDict. > > As an experiment, try walking down the hall asking a few programmers who aren't in this conversion what they > think > collections.odict() is? I second that odict is too terse, and it's also a recipe for subtle typos. I think that both ordereddict and OrderedDict can't go wrong. 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
> Is it a class or function? What does it do? Can the English as second > language folks guess what the o stands for? Is it a builtin or pure > python? My guess is that the experiment will be informative. I'll do that tomorrow (if I manage to remember). My guess is that "ordered dictionary" is as descriptive to them as "odict" or "blonzo" (well, perhaps they do recognize the "dictionary" part of it, and manage not to confuse it with "directory"). As for the "ordered" part, my guess is that most people will suggest that it means "sorted" (native speakers or not). 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] PEP 372 -- Adding an ordered directory t o collections ready for pronouncement
Hi, Raymond Hettinger rcn.com> writes: > When we use the class, we typically only spell-out the constructor > once while actually using the returned > object many times. So, > have we really saved any typing? I'm fine with the typed out name as well, but I still would prefer lowercase to stay consistent with defaultdict/dict. Unfortunately PEP 8 never really took off naming-wise, so we're mostly following the "reuse the naming scheme from existing code in the same module" rule, and I think there lowercase wins, thanks to defaultdict. Regards, Armin ___ 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] first 3.1 alpha this Saturday
Hi everyone! The first alpha of 3.1 will be coming out this Saturday, so I would appreciate you not breaking anything too egregiously. :) If you think some thing should hold up the release, mark the issue a release blocker or contact me by email or "gutworth" on #python-dev. I have been talking with Antoine about io in C implementation. We would like to merge the branch before Saturday, so it can get some real world testing. io-c, however, hasn't received much through review. Would somebody have time to go through a diff on Rietveld? On Saturday, I will try to start doing the release around 16:00 UTC. -- 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
2009/3/2 Armin Ronacher : > Hi, > > Raymond Hettinger rcn.com> writes: >> When we use the class, we typically only spell-out the constructor >> once while actually using the returned >> object many times. So, >> have we really saved any typing? > I'm fine with the typed out name as well, but I still would prefer lowercase > to > stay consistent with defaultdict/dict. +1 -- 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Unfortunately PEP 8 never really took off naming-wise, so we're mostly following the "reuse the naming scheme from existing code in the same module" rule, and I think there lowercase wins, thanks to defaultdict. Traditionally, the all lowercase name referred to a C type. The other classes in collections are named Counter, UserDict, UserList, UserString, MutableMapping, etc. Besides, the lowercase/uppercase distinction helps us distinguish functions from classes. This is the way I've see every Python book do it since the dawn of time. Raymond ___ 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] Interpreter crash in test_strftime?
Hello everybody, I'm trying the current py3k under a Windows virtual machine (with VS Express 2008), and the interpreter crashes in test_strftime in test_datetime.py. Has anyone been getting something like that? (not being a Windows user, it's a bit hard for me to investigate what's wrong) 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] Instructions on using git mirror
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 27, 2009, at 5:24 PM, Brett Cannon wrote: Where's a good place for this? I'm thinking three bullets under "Core Development" on this page: http://wiki.python.org/moin/ I've now moved the Bazaar instructions to the wiki. See * http://wiki.python.org/moin/FrontPage * http://wiki.python.org/moin/Bazaar Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSaxsjXEjvBPtnXfVAQIqpQP9HHXHzbXG5D51QeKr3B9F4AppINrznndC Jam/IN+zuy+nm0T8Tq41rCqywuQm5Cj5+oBI6U5pQj58nQ6YAJzBYuJ1/mmRZOYv 0fTzIt0OEVvzodHdqDiHYMxNDB/JyKFdx/BInbRWSdXJFc+4C+2pd618ywahP7YU y0m9Xo3fXA0= =GD1M -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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hettinger wrote: > >> Unfortunately PEP 8 never really took off naming-wise, so we're mostly >> following >> the "reuse the naming scheme from existing code in the same module" rule, >> and I >> think there lowercase wins, thanks to defaultdict. > > Traditionally, the all lowercase name referred to a C type. The other > classes in > collections are named Counter, UserDict, UserList, UserString, > MutableMapping, etc. > Besides, the lowercase/uppercase distinction helps us distinguish functions > from classes. > This is the way I've see every Python book do it since the dawn of time. Then they're all wrong. In 3.0 we're moving away from this, e.g. cPickle is gone, so is cStringIO. The implementation language should not shine through. *Maybe* the "built-in status" should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. In a sense defaultdict is the odd one out here, since these are things you import from some module, they're not built-in. Maybe it should be renamed to NamedDict? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Interpreter crash in test_strftime?
On Tue, Mar 3, 2009 at 00:19, Antoine Pitrou wrote: > Hello everybody, > > I'm trying the current py3k under a Windows virtual machine (with VS Express > 2008), and the interpreter crashes in test_strftime in test_datetime.py. > Has anyone been getting something like that? > > (not being a Windows user, it's a bit hard for me to investigate what's wrong) Let me guess: it a RuntimeError, "Invalid format directive", when calling strftime. CRT assertions where enabled a few weeks ago (issue4804) It may be a bad merge from trunk to the py3k branch. -- Amaury Forgeot d'Arc ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
[GvR] *Maybe* the "built-in status" should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). That makes sense. Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. FWIW, namedtuple() is a factory function that creates a class, it isn't a class itself. There are no instances of namedtuple(). Most functions are all lowercase. Don't know if that applies to factory functions too. Raymond ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Hi, Guido van Rossum python.org> writes: > Anyway, it seems the collections module in particular is already > internally inconsistent -- NamedTuple vs. defaultdict. In a sense > defaultdict is the odd one out here, since these are things you import > from some module, they're not built-in. Maybe it should be renamed to > NamedDict? I suppose you mean "DefaultDict". That would actually be the best solution. Then the module would be consistent and the new ordered dict version would go by the name "OrderedDict". Regards, Armin PS.: so is datetime.datetime a builtin then? :) ___ 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] Interpreter crash in test_strftime?
Hi Amaury, Le mardi 03 mars 2009 à 00:39 +0100, Amaury Forgeot d'Arc a écrit : > > > > I'm trying the current py3k under a Windows virtual machine (with VS Express > > 2008), and the interpreter crashes in test_strftime in test_datetime.py. > > Has anyone been getting something like that? > > > > (not being a Windows user, it's a bit hard for me to investigate what's > > wrong) > > Let me guess: it a RuntimeError, "Invalid format directive", when > calling strftime. I don't know. I've built in release mode, and I only get a window proposing me to send the crash information to Microsoft... (I must mention that I recently upgraded that VM to XP SP3) 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger wrote: > [GvR] >> >> *Maybe* the "built-in status" should guide the >> capitalization, so only built-in types are lowercase (str, int, dict >> etc.). > > That makes sense. > > >> Anyway, it seems the collections module in particular is already >> internally inconsistent -- NamedTuple vs. defaultdict. > > FWIW, namedtuple() is a factory function that creates a class, it isn't > a class itself. There are no instances of namedtuple(). Most functions > are all lowercase. Don't know if that applies to factory functions too. This is unfortunately ambiguous; e.g. threading.Lock() is a factory function too. Anyways, I was mistaken about this example; I should have pointed to Counter and the UserXxx classes in collections.py. On Mon, Mar 2, 2009 at 3:44 PM, Armin Ronacher I suppose you mean "DefaultDict". Yes, I've been distracted. :-( > That would actually be the best solution. > Then the module would be consistent and the new ordered dict version would go > by > the name "OrderedDict". OK. > PS.: so is datetime.datetime a builtin then? :) Another historic accident. Like socket.socket. :-( -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Interpreter crash in test_strftime?
On Tue, Mar 3, 2009 at 00:47, Antoine Pitrou wrote: > > Hi Amaury, > > Le mardi 03 mars 2009 à 00:39 +0100, Amaury Forgeot d'Arc a écrit : >> > >> > I'm trying the current py3k under a Windows virtual machine (with VS >> > Express >> > 2008), and the interpreter crashes in test_strftime in test_datetime.py. >> > Has anyone been getting something like that? >> > >> > (not being a Windows user, it's a bit hard for me to investigate what's >> > wrong) >> >> Let me guess: it a RuntimeError, "Invalid format directive", when >> calling strftime. > > I don't know. I've built in release mode, and I only get a window > proposing me to send the crash information to Microsoft... > (I must mention that I recently upgraded that VM to XP SP3) This should be fixed with r70114. -- Amaury Forgeot d'Arc ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Quick question? Is PEP 8 still current for what is being done in Py3.x? I just took a quick look and it says: Class Names Almost without exception, class names use the CapWords convention. Classes for internal use have a leading underscore in addition. - Original Message - From: "Guido van Rossum" To: "Raymond Hettinger" Cc: ; "Armin Ronacher" Sent: Monday, March 02, 2009 3:38 PM Subject: Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hettinger wrote: Unfortunately PEP 8 never really took off naming-wise, so we're mostly following the "reuse the naming scheme from existing code in the same module" rule, and I think there lowercase wins, thanks to defaultdict. Traditionally, the all lowercase name referred to a C type. The other classes in collections are named Counter, UserDict, UserList, UserString, MutableMapping, etc. Besides, the lowercase/uppercase distinction helps us distinguish functions from classes. This is the way I've see every Python book do it since the dawn of time. Then they're all wrong. In 3.0 we're moving away from this, e.g. cPickle is gone, so is cStringIO. The implementation language should not shine through. *Maybe* the "built-in status" should guide the capitalization, so only built-in types are lowercase (str, int, dict etc.). Anyway, it seems the collections module in particular is already internally inconsistent -- NamedTuple vs. defaultdict. In a sense defaultdict is the odd one out here, since these are things you import from some module, they're not built-in. Maybe it should be renamed to NamedDict? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Mon, Mar 2, 2009 at 3:52 PM, Raymond Hettinger wrote: > Quick question? Is PEP 8 still current for what is being done in Py3.x? > I just took a quick look and it says: > > Class Names > > Almost without exception, class names use the CapWords convention. > Classes for internal use have a leading underscore in addition. Yes, this is still the rule for new classes. I am *not* (have never been) in favor of a hasty overhaul of established APIs. Some of these were fixed for 3.0 (e.g. cPickle). The rest will just be deviant forever. Not a big deal as long as the number is fixed and limit. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
Guido van Rossum wrote: > On Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger wrote: >> [GvR] >>> *Maybe* the "built-in status" should guide the >>> capitalization, so only built-in types are lowercase (str, int, dict >>> etc.). >> That makes sense. >> >> >>> Anyway, it seems the collections module in particular is already >>> internally inconsistent -- NamedTuple vs. defaultdict. >> FWIW, namedtuple() is a factory function that creates a class, it isn't >> a class itself. There are no instances of namedtuple(). Most functions >> are all lowercase. Don't know if that applies to factory functions too. > > This is unfortunately ambiguous; e.g. threading.Lock() is a factory > function too. Anyways, I was mistaken about this example; I should > have pointed to Counter and the UserXxx classes in collections.py. > > On Mon, Mar 2, 2009 at 3:44 PM, Armin Ronacher > I suppose you mean "DefaultDict". > > Yes, I've been distracted. :-( > >> That would actually be the best solution. >> Then the module would be consistent and the new ordered dict version would >> go by >> the name "OrderedDict". > > OK. > >> PS.: so is datetime.datetime a builtin then? :) > > Another historic accident. Like socket.socket. :-( > A pity this stuff wasn't addressed for 3.0. Way too late now, though. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 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] first 3.1 alpha this Saturday
Benjamin Peterson python.org> writes: > > I have been talking with Antoine about io in C implementation. We > would like to merge the branch before Saturday, so it can get some > real world testing. io-c, however, hasn't received much through > review. Would somebody have time to go through a diff on Rietveld? For people who want to take a look, the review is at: http://codereview.appspot.com/22061 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] Interpreter crash in test_strftime?
Amaury Forgeot d'Arc gmail.com> writes: > > This should be fixed with r70114. Indeed, thanks! 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Mon, 02 Mar 2009 14:36:32 -0800, Raymond Hettinger wrote: > [Nick Coghlan] >> The examples in the PEP used 'odict' (until recently), but the patch >> was for OrderedDict. > > As an experiment, try walking down the hall asking a few programmers who > aren't in this conversion what they think collections.odict() is? > Is it a class or function? What does it do? Can the English as second > language folks guess what the o stands for? Is it a builtin or pure > python? My guess is that the experiment will be informative. Just today, I was talking with a colleague (which is learning Python right now) about "ordered dict". His first thought was a dictionary that, when iterated, would return keys in sorted order. I beleive he was partly misguided by his knowledge of C++. C++ has always had std::map which returns sorted data upon iteration (it's a binary tree); they're now adding std::unordered_map (and std::unordered_set), to be implemented with a hash table. So, if you come from C++, it's easy to mistake the meaning of an ordered dict. This said, I don't have a specific suggestion, but I would stay with lowercase-only for simmetry with defaultdict. -- Giovanni Bajo Develer S.r.l. http://www.develer.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] ABCs and MRO
Nick Coghlan wrote: Terry Reedy wrote: As for the actual feature, I don't think it should hold up releases. Fair enough. Given that the purpose of 2.7 is a) maintenance of existing code (which can include minor new features for existing facilities), and b) easing conversion of code to 3.1 I am puzzled at the idea of adding a new facility to 2.7 that would not be in 3.1+. It would lock code into 2.7+ and counter purpose b). It's possible we will end up in a situation where 3.0 and 3.1 are both aligned with 2.6, while 2.7 aligns with 3.2. That's particularly so with only 6 months or so between 3.0 and 3.1, while I currently expect the gap between 2.6 and 2.7 to be closer to the traditional 18 months. OK, that suggests that the new feature should only be committed, if ever, to 2.7 after 3.1, when it can also be committed to 3.2 at the same time. ___ 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] [ANN] EuroPython 2009 – Open for Registration and Reminder of Participation!
On behalf of the EuroPython 2009 organisation it is my privilege and honour to announce that EuroPython 2009 is open for registration! EuroPython is the conference for the communities around Python, including the Django, Zope and Plone communities. This year's conference will be held in Birmingham, UK from Monday 30th June to Monday 2nd July 2009. Preceding the conference, on Saturday 28th June and Sunday 29th June, are the tutorial days, which can be attended separately. We have a special extra early bird rate, just 95 GBP for the conference and 70 GBP for the tutorials. Be quick, this offer only last untill the 14th of March! For your convenience we negotiated special hotel prices, you can book your conference and hotels all at ones. Register at http://www.europython.eu/registration/ . Talks & Themes We already received a number of very interesting talks, why not add yours? Go to http://www.europython.eu/talks/cfp/ for this year's themes and submissions criteria, the deadline is on 5th April 2009. Other Talks, Activities and Events Have you got something which does not fit the above? Visit http://www.europython.eu/talks/ . Help Us Out We could use a hand, any contribution is welcome, please take a look at http://www.europython.eu/contact/ . Sponsors An unique opportunity to affiliate with the prestigious EuroPython conference! http://www.europython.eu/sponsors/ Spread the Word Improve our publicity by distributing this announcement in your corner of the community, coordinating this with the organizers is highly appreciated. http://www.europython.eu/contact/ General Information For more information about the conference, please visit http://www.europython.eu/ . Looking forward to see you! The EuroPython Team ___ 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
