Mailman 3 February 2013 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists … [View More]now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich [View Less]

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 21, 2020

Feb. 21, 2020

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int … [View More]

14 20

while conditional in list comprehension ??
by Wolfgang Maier Feb. 21, 2014

Feb. 21, 2014

Dear all, I guess this is so obvious that someone must have suggested it before: in list comprehensions you can currently exclude items based on the if conditional, e.g.: [n for n in range(1,1000) if n % 4 == 0] Why not extend this filtering by allowing a while statement in addition to if, as in: [n for n in range(1,1000) while n < 400] Trivial effect, I agree, in this example since you could achieve the same by using range(1,400), but I hope you get the point. This intuitively … [View More]

19 70

format specifier for "not bytes"
by Daniel Holth July 5, 2013

July 5, 2013

While I was implementing JSON-JWS (JSON web signatures), a format which in Python 3 has to go from bytes > unicode > bytes > unicode several times in its construction, I notice I wrote a lot of bugs: "sha256=b'abcdef1234'" When I meant to say: "sha256=abcdef1234" Everything worked perfectly on Python 3 because the verifying code also generated the sha256=b'abcdef1234' as a comparison. I would have never noticed at all unless I had tried to verify the Python 3 output with Python 2. … [View More]

8 17

frozenset literals
by Hua Lu May 21, 2013

May 21, 2013

This is similar to another proposal: http://mail.python.org/pipermail/python-3000/2008-January/011798.html Anyway, I was using ast.literal_eval and attempted to use frozenset({...}) as a key in a dictionary, which failed, because frozenset isn't a literal (though putting frozenset in the environment would be a security risk). I am currently working around this with tuples, but I'd like a literal for representing frozensets as well. I also use frozensets elsewhere in the code in ways similar to … [View More]

15 31

hexdump
by anatoly techtonik April 29, 2013

April 29, 2013

Just an idea of usability fix for Python 3. hexdump module (function or bytes method is better) as simple, easy and intuitive way for dumping binary data when writing programs in Python. hexdump(bytes) - produce human readable dump of binary data, byte-by-byte representation, separated by space, 16-byte rows Rationale: 1. Debug. Generic binary data can't be output to console. A separate helper is needed to print, log or store its value in human readable format in database. This takes … [View More]time. 2. Usability. binascii is ugly: name is not intuitive any more, there are a lot of functions, and it is not clear how it relates to unicode. 3. Serialization. It is convenient to have format that can be displayed in a text editor. Simple tools encourage people to use them. Practical example: >>> print(b) � � � �� >>> b '\xe6\xb0\x08\x04\xe7\x9e\x08\x04\xe7\xbc\x08\x04\xe7\xd5\x08\x04\xe7\xe4\x08\x04\xe6\xb0\x08\x04\xe7\xf0\x08\x04\xe7\xff\x08\x04\xe8\x0b\x08\x04\xe8\x1a\x08\x04\xe6\xb0\x08\x04\xe6\xb0\x08\x04' >>> print(binascii.hexlify(data)) e6b00804e79e0804e7bc0804e7d50804e7e40804e6b00804e7f00804e7ff0804e80b0804e81a0804e6b00804e6b00804 >>> >>> data = hexdump(b) >>> print(data) E6 B0 08 04 E7 9E 08 04 E7 BC 08 04 E7 D5 08 04 E7 E4 08 04 E6 B0 08 04 E7 F0 08 04 E7 FF 08 04 E8 0B 08 04 E8 1A 08 04 E6 B0 08 04 E6 B0 08 04 >>> >>> # achieving the same output with binascii is overcomplicated >>> data_lines = [binascii.hexlify(b)[i:min(i+32, len(binascii.hexlify(b)))] for i in xrange(0, len(binascii.hexlify(b)), 32)] >>> data_lines = [' '.join(l[i:min(i+2, len(l))] for i in xrange(0, len(l), 2)).upper() for l in data_lines] >>> print('\n'.join(data_lines)) E6 B0 08 04 E7 9E 08 04 E7 BC 08 04 E7 D5 08 04 E7 E4 08 04 E6 B0 08 04 E7 F0 08 04 E7 FF 08 04 E8 0B 08 04 E8 1A 08 04 E6 B0 08 04 E6 B0 08 04 On the other side, getting rather useless binascii output from hexdump() is quite trivial: >>> data.replace(' ','').replace('\n','').lower() 'e6b00804e79e0804e7bc0804e7d50804e7e40804e6b00804e7f00804e7ff0804e80b0804e81a0804e6b00804e6b00804' But more practical, for example, would be counting offset from hexdump: >>> print( ''.join( '%05x: %s\n' % (i*16,l) for i,l in enumerate(hexdump(b).split('\n')))) Etc. Conclusion: By providing better building blocks on basic level Python will become a better tool for more useful tasks. References: [1] http://stackoverflow.com/questions/2340319/python-3-1-1-string-to-hex [2] http://en.wikipedia.org/wiki/Hex_dump -- anatoly t. [View Less]

8 10

Poll about -h,--help options
by anatoly techtonik April 13, 2013

April 13, 2013

Hi, Is it interesting to know if people expect -h to work as a --help equivalent by default? As it directly affects best practices of using Python in command line, can we run such poll on python.org? I thought that this stuff is obvious, but it appears that it is not, so I'd like to see this usability study - it will be interesting for the Python community to know itself better. -- anatoly t.

7 7

argparse - add support for environment variables
by Miki Tebeka March 27, 2013

March 27, 2013

Greetings, The usual way of resolving configuration is command line -> environment -> default. Currently argparse supports only command line -> default, I'd like to suggest an optional "env" keyword to add_argument that will also resolve from environment. (And also optional env dictionary to the ArgumentParser __init__ method [or to parse_args], which will default to os.environ). Example: [spam.py] parser = ArgumentParser() parser.add_argument('--spam', env='SPAM',… [View More]

3 4

OrderedDict for kwargs and class statement namespace
by Eric Snow March 2, 2013

March 2, 2013

Just wanted to put out some feelers for the feasibility of these two features: * have the **kwargs param be an OrderedDict rather than a dict * have class definitions happen relative to an OrderedDict by default rather than a dict, and still overridable by a metaclass's __prepare__(). Both of these will need OrderedDict in C, which is getting close (issue #16991). -eric

10 28

range
by Wolfgang Maier Feb. 28, 2013

Feb. 28, 2013

Dear all, what do you think about allowing the use of operators on ranges? I thought of things like: a = range(1,10) b = range(5,12) intersect = a & b # equivalent to intersect = range(5,10) merge = a | b # equivalent to merge = range(1,12) to make this work in more complex cases, like: a = range(1,10) b = range(12,15) merge = a | b # equivalent to sth. like range(range(1,10),range(12,15)) maybe range nesting would be desirable, but the full sequence of values of such … [View More]

9 13

iterable.__unpack__ method
by Alex Stewart Feb. 27, 2013

Feb. 27, 2013

So when putting together my enum implementation I came up against something I've run into a couple of times in a few different situations, and I thought warranted some discussion as its own proposal: There are times where it would be extremely convenient if there was a way when unpacking an object (using the "a, b, c = foo" notation) for that object to know how many values it needed to provide. I would like to propose the following: When the unpack notation is used, the interpreter will … [View More]

20 46

easier subprocess piping and redirection
by Timo Kluck Feb. 27, 2013

Feb. 27, 2013

Dear python enthousiasts, While replacing some of my bash scripts by python scripts, I found the following useful. I wrote a small utility module that allows piping input and output in a very similar way to how you do it in bash. The major advantage over just using shell=True is that this does not expose us to the latter's security risks and quoting hazards. The major advantage of using a pipe instead of just manually feeding the output of one process to the other is that with a pipe, it … [View More]

3 3

Add lookahead iterator (peeker) to itertools
by Terry Reedy Feb. 26, 2013

Feb. 26, 2013

An iterator iter represents the remainder of some collection, concrete or not, finite or not. If the remainder is not empty, its .__next__ method selects one object, mutates iter to represent the reduced remainder (now possibly empty), and returns the one item. At various times, people have asked for the ability to determine whether an iterator is exhausted, whether a next() call will return or raise. If it will return, people have also asked for the ability to peek at what the return … [View More]would be, without disturbing what the return will be. For instance, on the 'iterable.__unpack__ method' Alex Stewart today wrote: > The problem is that there is no standard way to query an iterator > to find out if it has more data available without automatically > consuming that next data element in the rocess. It turns out that there is a solution that gives the ability to both test emptiness (in the standard way) and peek ahead, without modifying the iterator protocol. It merely require a wrapper iterator, much like the ones in itertools. I have posted one before and give my current version below. Does anyone else this should be added to itertools? It seems to not be completely obvious to everyone, is more complex that some of the existing itertools, and cannot be composed from them either. (Nor can it be written as a generator function.) Any of the names can be changed. Perhaps the class should be 'peek' and the lookahead object something else. The sentinel should be read-only if possible. I considered whether the peek object should be read-only, but someone would say that they *want* be able to replace the next object to be yielded. Peeking into an exhausted iterable could raise instead of returning the sentinel, but I don't know if that would be more useful. ---------------- class lookahead(): "Wrap iterator with lookahead to both peek and test exhausted" _NONE = object() def __init__(self, iterable): self._it = iter(iterable) self._set_peek() def __iter__(self): return self def __next__(self): ret = self.peek self._set_peek() return ret def _set_peek(self): try: self.peek = next(self._it) except StopIteration: self.peek = self._NONE def __bool__(self): return self.peek is not self._NONE def test_lookahead(): it = lookahead('abc') while it: a = it.peek b = next(it) print('next:', b, '; is peek:', a is b ) test_lookahead() -------------------- >>> next: a ; is peek: True next: b ; is peek: True next: c ; is peek: True -- Terry Jan Reedy [View Less]

12 25

FileCookieJar (and concrete implementations).
by Demian Brecht Feb. 26, 2013

Feb. 26, 2013

Context: http://bugs.python.org/issue16942 (my patch, changing FileCookieJar to be an abc, defining the interfaces for *FileCookieJar). This pertains to Terry's question about whether or not it makes sense that an abstract base class extends a concrete class. After putting in a little thought, he's right. It doesn't make sense. After further thought, I'm relatively confident that the hierarchy as it stands should be changed. Currently what's implemented in the stdlib looks like this: … [View More]

1 0

Adding a safe alternative to pickle in the standard library
by Devin Jeanpierre Feb. 25, 2013

Feb. 25, 2013

I've been noticing a lot of security-related issues being discussed in the Python world since the Ruby YAML problemcame out. Is it time to consider adding an alternative to pickle that is safe(r) by default? Pickle is usable in situations few other things are, because it can handle cyclic references and virtually any python object. The only stdlib alternative I'm aware of is json, which can do neither of those things. (Or at least, not without significant extra serialization code.) I would … [View More]

15 43

My wishlist for Tulip
by Giampaolo Rodolà Feb. 25, 2013

Feb. 25, 2013

I understand it's still beta but anyways, here's my little wish list for Tulip. * provide a 'demo' / 'example' directory containing very simple scripts showing the most basic usages such as: - echo_tcp_client.py - echo_tcp_server.py - echo_tcp_server_w_timeout.py (same as echo_server.py but also disconnects the client after a certain time of inactivity) - echo_tcp_ssl_client.py - echo_tcp_ssl_server.py - echo_udp_client.py - echo_udp_server.py * move all *test*.py scripts in a separate '… [View More]

4 7

Yet another enum proposal :)
by Alex Stewart Feb. 23, 2013

Feb. 23, 2013

Ok, so at the risk of muddying the waters even more, I've put together yet another possible way to do enums, and would be interested to hear comments.. Based on the list of required/desired/undesired properties laid out in the enum PEP thread, I believe a lot of the back and forth to date has been due to the fact that all of the proposed implementations fall short of fulfilling at least some of the desired properties for a general-purpose enum implementation in different ways. I've put … [View More]together something based on ideas from Tim's, Barry's, other things thrown out in discussion, and a few of my own which I think comes closer to ticking off most of the boxes. (The code and some examples are available at https://github.com/foogod/pyenum) Enums/groups are defined by creating subclasses of Enum, similarly to Barry's implementation. The distinction is that the base "Enum" class does not have any associated values (they're just singleton objects with names). At a basic level, the values themselves are defined like so: class Color (Enum): RED = __ GREEN = __ BLUE = __ As has been (quite correctly) pointed out before, the single-underscore (_) has a well-established meaning in most circles related to gettext/etc, so for this application I picked the next best thing, the double-underscore (__) instead. I think this is reasonably mnemonic as a "fill in the blank" placeholder, and also not unduly verbose. One advantage of using __ over, say, ellipsis (...) is that since it involves a name resolution, we can add (just a little!) magic to generate distinct __ objects on each reference, so, for example, the following actually works as the user probably expects it to: class Color (Enum): RED = CRIMSON = __ BLUE = __ (RED and CRIMSON actually become aliases referring to the same enum value, but BLUE is a different enum value) One other rather notable advantage to __ is that we can define a special multiplication behavior for it which allows us to make the syntax much more compact: class Color (Enum): RED, GREEN, BLUE, ORANGE, VIOLET, BEIGE, ULTRAVIOLET, ULTRABEIGE = __ * 8 (as an aside, I have an idea about how we might be able to get rid of the "* 8" altogether, but it requires a different (I think generally useful) change to the language which I will propose separately) Each enum value is actually an instance of its defining class, so you can determine what type of enum something is with simple inheritance checks: >>> isinstance(Color.RED, Color) True For enums which need to have int values, we can use IntEnum instead of Enum: class Errno (IntEnum): EPERM = 1 ENOENT = 2 ESRCH = 3 EINTR = 4 (Technically, IntEnum is just a special case of the more generic TypeEnum class: class IntEnum (TypeEnum, basetype=int): pass ..which means that theoretically you could define enums based on (almost) any base type (examples.py has an example using floats)) Anyway, as expected, enums have reasonable strs/reprs, and can be easily translated to/from base values using traditional "casting" syntax: >>> Errno.EPERM <__main__.Errno.EPERM (1)> >>> str(Errno.EPERM) 'EPERM' >>> int(Errno.EPERM) 1 >>> Errno(1) <__main__.Errno.EPERM (1)> You can also lookup enums by name using index notation: >>> Errno['EPERM'] <__main__.Errno.EPERM (1)> It's actually worth noting here that TypeEnums are actually subclasses of their basetype, so IntEnums are also ints, and can be used as drop-in replacements for any existing code which is expecting an int argument. They can also be compared directly as if they were ints: if exc.errno == Errno.EPERM: do_something() TypeEnums enforce uniqueness: >>> class Foo (IntEnum): ... A = 1 ... B = 1 ... Traceback (most recent call last): File "<stdin>", line 1, in <module> ... ValueError: Duplicate enum value: 1 However, you can define "aliases" for enums, if you want to: >>> class Foo (IntEnum): ... A = 1 ... B = A ... >>> Foo.A <__main__.Foo.A (1)> >>> Foo.B <__main__.Foo.A (1)> Of course, pure (valueless) Enum instances are logical singletons (i.e. they only compare equal to themselves), so there's no potential for duplication there. Finally, a special feature of __ is that it can also be called with parameters to create enum values with docstrings or other metadata: >>> class Errno (IntEnum): ... EPERM = __(1, doc="Permission denied") ... >>> Errno.EPERM.__doc__ 'Permission denied' >>> class Color (Enum): ... RED = __(doc="The color red", rgb=(1., 0., 0.)) ... >>> Color.RED.__doc__ 'The color red' >>> Color.RED.rgb (1.0, 0.0, 0.0) A few other notable properties: - Enum values are hashable, so they can be used as dict keys, etc. - Though enum values will compare equal to their associated basetype values (Errno.EPERM == 1), enum values from different classes never compare equal to each other (Foo.A != Errno.EPERM). This prevents enum-aware code from accidentally mistaking one enum for a completely different enum (with a completely different meaning) simply because they map to the same int value. - Using the class constructor does not create new enums, it just returns the existing singleton enum associated with the passed value (Errno(1) returns Errno.EPERM, not a new Errno). If there is no predefined enum matching that value, a ValueError is raised, thus using the constructor is basically a "cast" operation, and only works within the supported range of values. (New enum values can be created using the .new() method on the class, however, if desired) So... thoughts? --Alex [View Less]

4 10

PEP for enum library type?
by Eli Bendersky Feb. 23, 2013

Feb. 23, 2013

Hi all, The ideas thrown around and Tim's prototype in the thread "constant/enum type in stdlib" show that it's possible to use some metaclass magic to implement very convenient syntax for enums, while only including them in the stdlib (no language changes): from enum import Enum class Color(Enum): RED, BLUE, GREEN I'm, for one, convinced that with this in hand we should *not* add special syntax for enums, since the gains would be minimal over the above proposal. While the parallel … [View More]

25 72

Re: [Python-ideas] PEP for enum library type?
by Alex Stewart Feb. 22, 2013

Feb. 22, 2013

Hi all, Sorry to jump into this discussion so late, but I just finished reading through this thread and had a few thoughts.. (Sorry this message is a bit long. TL;DR: Please check the list of required/desired/undesired properties at the end and let me know if I've gotten anything seriously wrong with my interpretation of the discussion thus far) It seems to me that this particular thread started out as a call to step away from existing implementations and take a look at this issue from the … [View More]direction of "what do we want/need" instead, but then it quickly got sidetracked back into discussing all the details of various existing/proposed implementations. I'd like to try to take a step back (again) for a minute and raise the question: What do we actually want to get out of this whole endeavor? First of all, as I see it, there are two main (and fairly distinct) use cases for enums in Python: 1. Predefined "unique values" for passing around within Python code 2. API-defined constants for interacting with non-Python libraries, etc (i.e. C defines/enums that need to be represented in Python, or database field values, etc) In non-Python code, typically enums have always been represented under the covers as ints, and therefore must be passed back and forth as numbers. The fact that they have an integer value, however, is purely an implementation artifact. It comes from the fact that C and some other languages don't have a rich enough type system to properly make enums their own distinct types, but Python does not have this limitation, and I think we should be careful not to constrain the way we do things within Python just because of the limitations of other languages. Where possible I believe we should conceptually be thinking of enums not as "sequences of ints" but more as "collections of singletons". That is, they are simply objects, with a defined name and type, which compare equal to themselves but not to others, and are generally related to others by some sort of grouping mechanism (and the same name always maps to the same object). In this context, the idea of assigning a "value" to an enum makes little sense and is arguably completely unnecessary. (and if we eliminate this aspect, it mitigates many of the issues that have been brought up about evaluation order and accidental duplication, in addition to potentially making the base design a lot simpler) Obviously, the second use case does require an association between enums and (typically int) values, but that could be viewed as simply a special case of the larger definition of "enums", rather than the other way around. I do think one thing worth noting, however, is that (at least in my experience) the cases which require associating names with values pretty much also always require that every name has a specific value, so the value for each and every enum within the group should probably be being defined explicitly anyway (I have encountered very few cases where it's actually useful to mix-and-match "I care about this value but I don't care about those ones"). It doesn't seem unreasonable, therefore, to define two different categories of enums: one that has no concept of "value" (for pure-Python), and one which does have associated values but all values have to be specified explicitly (for the "mapping constants" case). On a related note, to be honest, I'm not really sure I can think of any realistic use cases for "string enums" (or really anything other than ints in general). Does anybody have an example of where this would actually be useful as opposed to just using "pure" (valueless) enums (which would already have string names)? Anyway, in the interest of trying to get the discussion back onto more theoretical ground, I also wanted to try to summarize the more general thoughts/impressions I've gleaned from the discussions up to this point. From what I can tell, these are some of the properties that there seems to be some general consensus enums probably should or shouldn't have: Required properties (without these, any implementation is not generally useful, or is at least something different than an "enum"): 1. Enums must be groupable in some way (i.e. "Colors", or "Error values") 2. Enums within the same group must not compare equal to each other (unless two names are intentionally defined to map to the same enum (i.e. "aliases")) 3. (Within reason and the limitations of Python) Once defined, an enum's properties (i.e. its name, identity, group membership, relationships to other objects, etc) must be treated as immutable (i.e. not change out from under the programmer unexpectedly). Conceptually they should be considered to be "constants". Desirable properties (which ones are more or less desirable will vary for different people, but from what I've heard I think everybody sorta agrees that all of these could be good things as long as they don't cause other problems): 1. Enums should represent themselves (str/repr) by symbolic names, not as ints, etc. 2. Enums from different groups should preferably not compare equal to each other (even if they have the same associated int value). 3. It should be possible to determine what group an enum belongs to. 4. Enums/groups should be definable inline using a fairly simple Python syntax. 5. It should also be relatively easy to define enums/groups programmatically. 6. By default, enums should be referenceable as relatively simple identifiers (i.e. no need for quoting, function-calls, etc, just variables/attributes/etc) 7. If the programmer doesn't care about the value of an enum, she shouldn't have to explicitly state a meaningless value. 8. (If an enum does have an associated value) it should be easy to compare with and/or convert back and forth between enums and values (so that they can be used with existing APIs). 9. It would be nice to be able to associate docstrings, and possibly other metadata with enums. Undesirable properties: 1. Enum syntax should not be "too magic". (In particular, it's pretty clear at this point that creating new enums as a side-effect of name lookups (even as convenient as it does make the syntax) is ultimately not gonna fly) 2. The syntax for defining enums should not be so onerous or verbose that it's significantly harder to use than the existing idioms people are already using. 3. The syntax for defining enums should not be so alien that it will completely baffle programmers who are already used to typical Python constructs. 4. It shouldn't be necessary to quote enum names when defining them (since they won't be quoted when they're used) I want to check: Is this a valid summary of things? Anything I missed, or do people have substantial objections to any of the required/desirable/undesirable points I mentioned? Obviously, it may not be possible to achieve all of the desirable properties at the same time, but I think it's useful to start with an idea of what we'd ideally like, and then we can sit down and see how close we can actually get to it.. (Actually, on pondering these properties, I've started to put together a slightly different enum implementation which I think has some potential (it's somewhat a cross between Barry's and Tim's with a couple of ideas of my own). I think I'll flesh it out a little more and then put it up for comment as a separate thread, if people don't mind..) --Alex [View Less]

7 16

Fwd: argparse - add support for environment variables
by Ian Cordasco Feb. 22, 2013

Feb. 22, 2013

---------- Forwarded message ---------- From: Ian Cordasco <graffatcolmingov(a)gmail.com> Date: Tue, Feb 19, 2013 at 11:35 AM Subject: Re: [Python-ideas] argparse - add support for environment variables To: Miki Tebeka <miki.tebeka(a)gmail.com> Cc: python-ideas(a)googlegroups.com Why not: parser.add_argument('--spam', default=os.environ.get('SPAM', 7)) This way if SPAM isn't set, your default is 7. If spam is set, your default becomes that. On Tue, Feb 19, 2013 at 11:03 AM, … [View More]

11 13

Functions and Unbound methods
by robert2682 Feb. 22, 2013

Feb. 22, 2013

Hi, I'm new; greetings all! I'm not sure if this is a bug or feature, but it confused me so I thought I'd raise the issue. class a: def b (self): pass foo = ('Hello', b) class c(a): def d(self): t = type (self. __class__. foo [1]) print t t = type (self. __class__. b) print t e = c () e. d() prints <type 'function'> for the first print, and it seems to me it should be an instancemethod I'm trying to something like this class EditPage: … [View More]

3 2

Re: [Python-ideas] Functions and Unbound methods
by robert2682 Feb. 21, 2013

Feb. 21, 2013

Hi, > Hi, > > I'm new; greetings all! > > I'm not sure if this is a bug or feature, but it confused me so I thought > I'd raise the issue. > > > class a: > def b (self): > pass > > foo = ('Hello', b) > > class c(a): > def d(self): > t = type (self. __class__. foo [1]) > print t > t = type (self. __class__. b) > print t > > e = c () > e. d() > > prints <type 'function'&… [View More]

1 0

Introducing PEP 434 -- IDLE Enhancement Exception for All Branches
by Todd Rovito Feb. 21, 2013

Feb. 21, 2013

Please see http://www.python.org/dev/peps/pep-0434/ for the complete PEP. The idea for the PEP was generated because a right click menu was added to IDLE in Python 2.7 this started a debate about bug fix VS enhancement see the PEP references for more information. IDLE has many patches that already exist but are difficult to get committed. This PEP is designed to make it easier to bring IDLE up to speed with modern GUI standards. The PEP is not perfect some issues that need to be solved: -How … [View More]

10 16

capturing the origin of objects
by Eric Snow Feb. 19, 2013

Feb. 19, 2013

With the removal of unbound methods in Python 3, introspecting the class on which a method was defined is not so simple. Python 3.3 gives us __qualname__ for classes and functions (see PEP 3155), which helps somewhat by giving us a string composed at compile-time. However, I was considering something a little more powerful. I propose that what would have formerly been an unbound method get a new attribute, __origin__. It will be bound to class where the method is defined. Motivation ========… [View More]== One motivator for this proposal is http://bugs.python.org/issue15582, allowing inspect.getdoc() to "inherit" docstrings. Without a concrete connection between a method and the "origin" class, dynamically determining the docstring is basically a non-starter. The __origin__ attribute would help. Extended Idea ============= The name, __origin__, is a bit generic to accommodate the possible extension of the proposal to other objects: * f.__origin__ (the module or function (nested) where the function was defined) * cls.__origin__ (the module, class (nested), or function where the class was defined) * code.__origin__ (the function for which the code object was originally created) * module.__origin__ (a.k.a. module.__file__) For functions and classes defined in a function, __origin__ would be bound to the function rather than the locals or the code object. For modules, __origin__ is more accurate in the cases that the module was generated from something other than a file. It would still be a string, though. Also, we currently have a convention of setting __module__ to the name of the module rather than the module itself. Whether to break with that convention for __origin__ is an open question which relates to how __origin__ would be used. Conceivably, each use case for __origin__ could be covered by a name more specific to the object, e.g. module.__file__. However, having the one name would help make the purpose clear and consistent. Objections ========== The downside of binding the objects to __origin__ is in memory usage and, particularly, in ref-counts/reference-cycles. I expect that this is where the biggest objections will lie. However, my understanding is that this is less of an issue now than it used to be. If need be, weakref proxies could address some of the concerns. The status quo has a gap in the case of "unbound" methods and of code objects, though __qualname__ does offer an improvement for methods. The actual use case I have relates strictly to those methods. Having something like __origin__ for those methods, at least, would be helpful. -eric [View Less]

1 0

A subclassing API for named tuples?
by Nick Coghlan Feb. 19, 2013

Feb. 19, 2013

An exchange with Antoine in one of the enum threads sparked a thought. A recurring suggestion for collections.namedtuple is that it would be nice to be able to define them like this (as it not only avoids having to repeat the class name, but also allows them to play nicely with pickle and other name-based reference mechanisms): class MyTuple(collections.NamedTuple): __fields__ = "a b c d e".split() However, one of Raymond's long standing objections to such a design for namedtuple … [View More]is the ugliness of people having to remember to include the right __slots__ definition to ensure it doesn't add any storage overhead above and beyond that for the underlying tuple. For the intended use case as a replacement for short tuples, an unused dict per instance is a *big* wasted overhead, so that concern can't be dismissed as premature optimisation: >>> import sys >>> class Slots(tuple): __slots__ = () ... >>> class InstanceDict(tuple): pass ... >>> sys.getsizeof(tuple([1, 2, 3])) 72 >>> x = Slots([1, 2, 3]) >>> sys.getsizeof(x) 72 >>> y = InstanceDict([1, 2, 3]) >>> sys.getsizeof(y) # All good, right? 72 >>> sys.getsizeof(y.__dict__) # Yeah, not so much... 96 However, the thought that occurred to me is that the right metaclass definition allows the default behaviour of __slots__ to be flipped, so that you get "__slots__ = ()" defined in your class namespace automatically, and you have to write "del __slots__" to get normal class behaviour back: >>> class SlotsMeta(type): ... def __prepare__(cls, *args, **kwds): ... return dict(__slots__=()) ... >>> class SlotsByDefault(metaclass = SlotsMeta): pass ... >>> class Slots(tuple, SlotsByDefault): pass ... >>> class InstanceDict(tuple, SlotsByDefault): del __slots__ ... >>> sys.getsizeof(Slots([1, 2, 3])) 72 >>> Slots().__dict__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Slots' object has no attribute '__dict__' >>> sys.getsizeof(InstanceDict([1, 2, 3])) 72 >>> sys.getsizeof(InstanceDict([1, 2, 3]).__dict__) 96 So, what do people think? Too much magic? Or just the right amount to allow a cleaner syntax for named tuple definitions, without inadvertently encouraging people to do bad things to their memory usage? (Note: for backwards compatibility reasons, we couldn't use a custom metaclass for the classes returned by the existing collections namedtuple API. However, we could certainly provide a distinct collections.NamedTuple type which used a custom metaclass to behave this way). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia [View Less]

9 22