Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Correctly merging #9319 into 3.3?
On Mon, 25 Apr 2011 04:47:03 +0200 Jesus Cea wrote: > > And yes, I fully realized that I should try to compile locally first. > Dealing with this unexpected merge when merging my own patch was... > unexpected, and the code seemed sensible enough. You should *always* recompile and run the affected tests before checking in a change. Even if the changes look "trivial". By trying to save a little time on your side your may lose a lot of other people's time. > Do we have some hat-of-shame I should wear because breaking the build? :). The tests are still broken it seems: == ERROR: test_issue9319 (test.test_imp.ImportTests) -- Traceback (most recent call last): File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_imp.py", line 181, in test_issue9319 imp.find_module, "test/badsyntax_pep3120") File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/case.py", line 574, in assertRaises callableObj(*args, **kwargs) ImportError: No module named 'test/badsyntax_pep3120' Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
Sorry if I am asking the obvious, but why are the aliases of set types not included in the 'types' module? I thought for a moment that they are just classes, but no, they introduce themselves as built-in types, just like any other standard Python type. > print type(set([1, 2, 4])) > print type(frozenset([3, 5])) Is it intentional, or is there some meaning behind this? If not, shouldn't they be added to the module? Regards, Bartosz Tarnowski --- Darmowy program do wypełniania PIT: http://linkint.pl/f2931 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
On Mon, 25 Apr 2011 14:04:35 +0200 haael wrote: > > Sorry if I am asking the obvious, but why are the aliases of set types not > included in the 'types' module? Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means: >>> dir(types) ['BuiltinFunctionType', 'BuiltinMethodType', 'CodeType', 'FrameType', 'FunctionType', 'GeneratorType', 'GetSetDescriptorType', 'LambdaType', 'MemberDescriptorType', 'MethodType', 'ModuleType', 'TracebackType', '__builtins__', '__cached__', '__doc__', '__file__', '__name__', '__package__'] Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
On Mon, Apr 25, 2011 at 8:04 AM, haael wrote: > Sorry if I am asking the obvious, but why are the aliases of set types not > included in the 'types' module? I thought for a moment that they are just > classes, but no, they introduce themselves as built-in types, just like any > other standard Python type. The types module pre-dates the time when classes were actually types in their own right, and many of the built-in constructors, like "float", "int", and "list", were simply functions. When that was the case: >>> import types >>> types.IntType == int False For types that have always been types, there's no corresponding entry in the types module, nor is there any need for any, since the type itself is already accessible. -Fred -- Fred L. Drake, Jr. "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means: OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least. Regards, Bartosz Tarnowski - Ksiegowa radzi: Jak zaÅozyc firme w 15 minut? http://linkint.pl/f2968 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
2011/4/25 haael : > >> Because there's no reason to include them, since they are already in >> the root (builtins) namespace. >> >> You'll notice that in Python 3, the "types" module only contains types >> which are not obviously accessed through easier means: > > > OK, makes sense, but in this case it would be handy to have some list of all > possible built-in types. I was just creating one and I nearly missed sets. > If an entry in 'types' module is too much, there should be some > comprehensive list in the documentation at least. http://docs.python.org/dev/library/stdtypes -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Correctly merging #9319 into 3.3?
Le lundi 25 avril 2011 à 04:47 +0200, Jesus Cea a écrit : > If a patch in 3.2 is not applicable in 3.3, a "null merge" should be > done. Correct. Sorry, I forgot that. And yes, the 3.2 fix was not applicable to 3.3, that's why I forgot to merge. > If not, next developer tring to merge will find some other > unrelated code to merge, and she doesn't have the context knowledge to > know what to do :-) Hum, you may read the history of the issue to decide what to do, or ask the commiter to do the merge. > In this case, I merged code that doesn't actually compile, breaking the > build for 20 minutes :-). He he, it was a trap! When you touch one of my commit, all buildbots turn red! :-) > Do we have some hat-of-shame I should wear because breaking the build? :). Don't worry, it doesn't matter if you quickly fix your mistake. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Drop OS/2 and VMS support?
Le mardi 19 avril 2011 à 23:21 +0200, "Martin v. Löwis" a écrit : > > Well, not "remove" directly, but plan to remove it using the PEP 11 > > procedure (mark OS/2 and VMS as unsupported, and remove the code in > > Python 3.4). > > I think the PEP 11 procedure is just right for this. It *is* a call > for maintainers, so if any user is interested in ongoing support, > they should step forward. > > Having then also blog posts about these pending deprecations sounds > fine to me - also adding them to the 3.2.x release pages would be > appropriate (IMO). It's important that we give users due notice, but > lacking any actual contribution, we should also be able to remove > the code eventually. > > So please go ahead and add them to PEP 11. Ok, I added OS/2 and VMS to the PEP 11. I also opened any issue to remember that I should do something to raise an error on build. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
On 02:01 pm, [email protected] wrote: Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means: OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least. Maybe this is what you're after? pprint([t for t in object.__subclasses__() if t.__module__ == '__builtin__']) [, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ] Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Syntax quirk
>>> type (3.) >>> 3..__class__ >>> type(3) >>> 3.__class__ File "", line 1 3.__class__ ^ SyntaxError: invalid syntax Superficially the last example ought to be legal syntax (and return ). Is it an oversight which could be fixed in a straightforward way, or are there reasons why it can't? I have tested this with Python 2.5 and Python 3.2. Best wishes Rob Cliffe ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax quirk
On Mon, Apr 25, 2011 at 1:21 PM, Rob Cliffe wrote: .. 3.__class__ > File "", line 1 > 3.__class__ > ^ > SyntaxError: invalid syntax > > Superficially the last example ought to be legal syntax (and return 'int'>). If it was valid, then >>> 3.e+7 would have to raise an attribute error instead of >>> 3.e+7 3000.0 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax quirk
On Tue, Apr 26, 2011 at 3:21 AM, Rob Cliffe wrote: type (3.) > 3..__class__ > type(3) > 3.__class__ > File "", line 1 > 3.__class__ > ^ > SyntaxError: invalid syntax > > Superficially the last example ought to be legal syntax (and return 'int'>). > Is it an oversight which could be fixed in a straightforward way, or are > there reasons why it can't? The parser (or is it the lexer? I never remember which it is that has the problem in this case) can't handle it - it sees the first "." and expects a floating point value. It's hard to disambiguate due to 3.e10 and the like being valid floating point numbers, while 3..e10 has to be an attribute access. You have to use whitespace or parentheses to eliminate the ambiguity: 3. __class__ (3).__class__ Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax quirk
On 4/25/2011 1:21 PM, Rob Cliffe wrote: >>> type (3.) >>> 3..__class__ >>> type(3) >>> 3.__class__ File "", line 1 3.__class__ ^ SyntaxError: invalid syntax Superficially the last example ought to be legal syntax (and return ). You are a more sophisticated parser than Python, which is limited to LL(1) parsing. (No that is not in the manual, but it is a known design consraint.) Is it an oversight which could be fixed in a straightforward way, or are there reasons why it can't? This sort of question as to why Python is the way it is really belongs on python-list. 3.x is parsed as (3.)x (float 3. followed by x) which is invalid syntax unless 'x' is a digit(s). You automatically back up and reparse as 3(.x) 3 .0 is a syntax error. 3 .__class__ is int. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means: OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least. Maybe this is what you're after? pprint([t for t in object.__subclasses__() if t.__module__ == '__builtin__']) [, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ] Jean-Paul Yes, something like that, but without abstract types like 'basestring'. If abstract types were OK, it would suffice to use 'object'. The use case is designing protocols that export Python objects to outer world, 'pickle' is an example. One needs to typecase through all built-in Python types and handle them in some way. Nevertheless, my problem is solved. Thank you. Regards, Bartosz Tarnowski --- Darmowy program do wypeÅniania PIT: http://linkint.pl/f2931 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Why doesn't `functools.total_ordering` use the existing ordering methods?
Hello, Today I was trying to use `total_ordering` for the first time. I was expecting that in order to implement e.g. `x > y` it would do `not x < y and not x == y`, assuming that `__lt__` and `__eq__` are defined. But I see it just does `y < x`, which is problematic. For example if you have a class that is decorated by `total_ordering`, and implements only `__lt__` and `__eq__`, then trying to do `x < y` will result in infinite recursion. Why not have `total_ordering` work in the way I suggested? Ram. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Drop OS/2 and VMS support?
> Ok, I added OS/2 and VMS to the PEP 11. I also opened any issue to > remember that I should do something to raise an error on build. For OS/2, I propose to syntactically break the makefile; anybody trying to build it should then run into that, and a) can easily overcome the limitation (probably to then run into more severe problems), and b) consider taking over maintenance if they are interested For VMS, I *think* the build process is configure-based (but I may misremember); if so, adding an exit into configure.in would be appropriate. Else an #error in a central header file may do as well. Or perhaps we could always use the #error if we can trust that compilers will honor it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why doesn't `functools.total_ordering` use the existing ordering methods?
On Apr 25, 2011, at 11:43 AM, cool-RR wrote:
> Today I was trying to use `total_ordering` for the first time. I was
> expecting that in order to implement e.g. `x > y` it would do `not x < y and
> not x == y`, assuming that `__lt__` and `__eq__` are defined.
This was fixed. The current code has:
convert = {
'__lt__': [('__gt__', lambda self, other: not (self < other or self ==
other)),
('__le__', lambda self, other: self < other or self ==
other),
('__ge__', lambda self, other: not self < other)],
'__le__': [('__ge__', lambda self, other: not self <= other or self ==
other),
('__lt__', lambda self, other: self <= other and not self ==
other),
('__gt__', lambda self, other: not self <= other)],
'__gt__': [('__lt__', lambda self, other: not (self > other or self ==
other)),
('__ge__', lambda self, other: self > other or self ==
other),
('__le__', lambda self, other: not self > other)],
'__ge__': [('__le__', lambda self, other: (not self >= other) or self
== other),
('__gt__', lambda self, other: self >= other and not self ==
other),
('__lt__', lambda self, other: not self >= other)]
}
> Why not have `total_ordering` work in the way I suggested?
To avoid needless posts, you should use the tracker.
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
