Mailman 3 June 2013 - Python-ideas

Re: [Python-ideas] Allow using ** twice
by Vernon D. Cole 07 Jun '13

07 Jun '13

On Thu, Jun 6, 2013 at 12:47 PM, <python-ideas-request(a)python.org> wrote: > > Does it? All the languages which only allow += on immutable values (e.g. > Java, C, Javascript) obviously don't mutate anything. Eh? It's been twenty years or so since I programmed C for a living, but I seem to remember that a C variable is actually only a handy label for a memory location, and that therefore *everything* is mutable -- even when it shouldn't be. And += was invariably implemented in machine language by a two-argument add straight to that memory location. Some of the early C compilers would even allow you to use a literal on the left side, like "2 += 3" which would change the value of the literal '2' to become five. Made for some interesting bugs! Ignoring all of that, if + worked on dictionaries, I would expect that duplicate keys would receive the value from the right-hand argument, and that the operation would create a new dictionary. (and I think it would be a great +1 idea.) -- Vernon Cole

3 3

applying the PSF Code of Conduct to this mailing list
by Brett Cannon 06 Jun '13

06 Jun '13

Titus and I have discussed it and we have decided to apply the PSF's Code of Conduct (http://hg.python.org/coc) to this mailing list. In a nutshell everyone should be open, respectful, and considerate to each other, i.e. don't be rude. If you think someone is not following the CoC, either publicly let them know you think they are not (obviously do this politely; publicly notifying someone is to help others on the list understand what may be considered inappropriate behaviour, not to chastise them in front of a crowd) or email python-ideas-owner@ privately with a link to the email in question from the archives and we will handle it w/o disclosing who brought forward the complaint. Anyone found repeatedly not following the CoC will be banned from the list. You can always ask to be allowed back on based on the discretion of the list owners. Because this is a new policy, no one is starting with any strikes against them. Everyone is assumed to have been polite and on good terms up to this point. In the 6.5 year history of this list there is possibly only one instance where this would have really come into play in removing someone from this list so this isn't expected to be used very often. But we felt we wanted something in place to remind folks that we expect all subscribers to be respectful of one another and to have something to use as a guideline for removals if it came to that.

11 22

without(str(bytes))
by Daniel Holth 06 Jun '13

06 Jun '13

Can I have a context manager that disables str(bytes) just for part of my code, the same as python -bb? with bb: serialize_something()

6 7

PEP 443 - multiple types registered
by João Bernardo 06 Jun '13

06 Jun '13

I was reading the recently accepted PEP 443 and this is one of the examples: @fun.register(float) @fun.register(Decimal) def fun_num(arg, verbose=False): if verbose: print("Half of your number:", end=" ") print(arg / 2) Wouldn't a tuple of types be more suitable? I mean, programatically you will not apply the decorators from a list, but define the function and then write a loop: for t in some_types: fun.register(t, fun_num) which is less pleasant for the eyes. I would rather do: @fun.register((float, Decimal)) def fun_num(arg, verbose=False): ... This makes a lot of sense when you think that Python functions and constructs dealing with types usually also deal with tuples of types. E.g: isinstance(foo, (Bar, Baz)) except (Foo, Bar) as baz: Last thought: People are used with decorators returning a decorated function. This is not the case here... For some, it may be confusing at first. João Bernardo

6 7

Re: [Python-ideas] PEP 426, YAML in the stdlib and implementation discovery
by Calvin Spealman 06 Jun '13

06 Jun '13

Right, "This specific idea isn't worth its specific costs in exchange for its specific benefits" is the same as "lets give up!" On Tue, Jun 4, 2013 at 7:29 AM, Philipp A. <flying-sheep(a)web.de> wrote: > 2013/6/4 Calvin Spealman <ironfroggy(a)gmail.com> > >> At this point I would argue against any new modules by default. How does >> the cost and liability of yaml in the standard library make up for such a >> ring benefit as excluding one little line from my requirements.txt? >> > how about we stop innovating completely and just give up python? there’s > so many languages out there, i can’t see the cost and liability of > maintaining python outweigh the small benefit of not using java. > > in other words: are you serious? > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

9 20

Status of PyYAML - Re: Proposal for closing ticket pyyaml/issue/11
by Kirill Simonov 05 Jun '13

05 Jun '13

Hi Stefan, I'm cross-posting this to the python-ideas list. Regarding the status of PyYAML -- after 10 releases over 6 years, I consider it stable enough so that I don't need to pay much attention to it anymore. I'm migrating the project, including the issues database, from Trac to Bitbucket, but haven't finished it yet since Bitbucket added issues import/export API only a month ago and I didn't have a change to look at it. On discussion on python-ideas, I looked through it, but I'm not sure how I could contribute. Does it make sense to have YAML support in stdlib? Definitely, the format is popular enough and has some unique advantages over other options. But to the next question, how it should be done, I don't have a good answer. Would you include PyYAML+libyaml directly into the stdlib? It's a big chunk of C, Python and Pyrex/Cython code and I doubt core developers are willing to accept it. Besides, PyYAML API was designed for Python 2.3 and may feel outdated for Python 3.5. So you need to rewrite low-level parsing and emitting code to C+Python API and design a new high-level extension API, but who's going to do all this work? Thanks, Kirill On 06/05/2013 01:43 AM, Stefan Drees wrote: > Hi Kirill, > > as we have interesting discussions w.r.t. YAML and the python stdlib, I > thought you might be interested to know. > > Vinay Sajip was so nice, as to point to an open ticket at [1] as sample > and asked (in other words) "if this project is alive and well" ;-) > (he also noted that there """are 65 open issues of type "defect" > relating to PyYAML, and 15 such relating to libyaml.""" c.f. [2] > > As it seems to be unclear how and where issues are handled for PyYAML > and libyaml (TRAC on pyyaml.org or bitbucket repo?) I spent some minutes > to remove the common fairy tale that "arbitrary JSON (with unique keys) > is automatic correctly parseable YAML" and wrote[3]. > > Maybe you can use some of the wording at [3], to close the ticket and > also others in relation to this misconception, that YAML = JSON and > unique keys. > > I personally would really enjoy, if you could participate in these > discussions on python-ideas as it would certainly be beneficial, to read > your opinions and advice based on your experiences. > > Please consider it at least. It would be great! > > References: > > [1]: https://bitbucket.org/xi/pyyaml/issue/11/valid-json-not-being-loaded > [2]: http://mail.python.org/pipermail/python-ideas/2013-June/021088.html > [3]: http://mail.python.org/pipermail/python-ideas/2013-June/021095.html > > All the best, > Stefan.

2 1

Timing hefty or long-running blocks of code
by Steven D'Aprano 05 Jun '13

05 Jun '13

The timeit module is great for timing small code snippets, but it is rather inconvenient for timing larger blocks of code. It's also over-kill: under normal circumstances, there is little need for the heroic measures timeit goes through to accurately time long-running code. When people want to time something that doesn't require timeit, they have to write their own timer boilerplate: from time import time t = time() do_this() do_that() print(time() - t) Although only a few lines of boilerplate, this has a few problems, the biggest two being: * the user has to decide which of the many clocks provided by Python is suitable (hint: time.time is not necessarily the best); * this is inconvenient at the interactive interpreter, since the timer is started before the code being typed has been entered. I propose a context manager in the timeit module: with Stopwatch(): do_this() do_that() => results are automatically printed, or available for programmatic access I have had a recipe for this on ActiveState for about 18 months, where it is relatively popular: http://code.activestate.com/recipes/577896-benchmark-code-with-the-with-sta… and I have extensively used it interactively, in Python 2.6 through 3.3 inclusive. The latest version can be found here: https://code.google.com/p/my-startup-file/source/browse/timer.py This solves the two problems listed above: * the Stopwatch can use the most appropriate timer by default, and allow the user to override it if they so choose; * the Stopwatch will not start until the with-block is actually entered. Is there interest in seeing this in the standard library? -- Steven

6 8

PEP 426, YAML in the stdlib and implementation discovery
by Philipp A. 04 Jun '13

04 Jun '13

Hi, reading PEP 426<http://www.python.org/dev/peps/pep-0426/#switching-to-a-json-compatible-for…>, I made a connection to a (IMHO) longstanding issue: YAML not being in the stdlib. I’m no big fan of JSON, because it’s so strict and comparatively verbose compared with YAML. I just think YAML is more pythonic, and a better choice for any kind of human-written data format. So i devised 3 ideas: 1. *YAML in the stdlib* The stdlib shouldn’t get more C code; that’s what I’ve gathered. So let’s put a pure-python implementation of YAML into the stdlib. Let’s also strictly define the API and make it secure-by-naming™. What i mean is let’s use the safe load function that doesn’t instantiate user-defined classes (in PyYAML called “safe_load”) as default load function “load”, and call the unsafe one by a longer, explicit name (e.g. “unsafe_load” or “extended_load” or something) Let’s base the parser on generators, since generators are cool, easy to debug, and allow us to emit and test the token stream (other than e.g. the HTML parser we have) 2. *Implementation discovery* People want fast parsing. That’s incompatible with a pure python implementation. So let’s define (or use, if there is one I’m not aware of) a discovery mechanism that allows implementations of certain APIs to register themselves as such. Let “import yaml” use this mechanism to import a compatible 3rd party implementation in preference to the stdlib one Let’s define a property of the implementation that tells the user which implementation he’s using, and a way to select a specific implementation (Although that’s probably easily done by just not doing “import yaml”, but “import std_yaml” or “import pyyaml2”) 3. Allow YAML to be used besides JSON as metadata like in PEP 426. (so including either pymeta.yaml or pymeta.json makes a valid package) I don’t propose that we exclusively use YAML, but only because I think that PEP 426 shouldn’t be hindered from being implemented ASAP by waiting for a new std-library to be ready. What do you think? Is there a reason for not including a YAML lib that i didn’t cover? Is there a reason JSON is used other than YAML not being in the stdlib?

19 39

Re: [Python-ideas] PEP 426, YAML in the stdlib and implementation discovery
by Calvin Spealman 04 Jun '13

04 Jun '13

On Tue, Jun 4, 2013 at 8:38 AM, Paul Moore <p.f.moore(a)gmail.com> wrote: > On 4 June 2013 12:26, Calvin Spealman <ironfroggy(a)gmail.com> wrote: > >> At this point I would argue against any new modules by default. How does >> the cost and liability of yaml in the standard library make up for such a >> ring benefit as excluding one little line from my requirements.txt? > > > Windows users without compilers can't "just add one little line". IIRC, > Windows users *with* compilers have to fiddle around with dependent > libraries in a messy way. Users without compilers working on prerelease > versions of Python can't find prebuilt binaries anyway. Corporate > environments may not allow 3rd party libraries. Some environments require > pure-python (non-stdlib) code. Etc, etc. > The proposal was about adding, explicitly, only a pure-python YAML library, so the compiler and binary related arguments don't apply here. Also, the fact that we don't have practical packaging solutions to this is something that, hopefully, we'll fix and so I think, until then, adding new modules should be scrutinized with the question: Are we just doing this to get around packaging limitations? New modules have a pretty high bar to adoption in any case. Let's not make > it impossibly high by assuming (wrongly) that there are no difficulties > involved in external dependencies. > > Paul. > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

1 0

iterator/stream-based JSON API
by Daniel Holth 04 Jun '13

04 Jun '13

When will the stdlib get a decent iterator/stream-based JSON API? For example automated packaging tools may be parsing a lot of JSON but ignoring most of it, and it would be lovely to say "if key not in interesting: skip_without_parsing()". Or to go straight from parse to domain objects without putting the whole thing in an intermediate dict. http://code.google.com/p/jsonpull/ is a nice looking but woefully undocumented Java one, and https://crate.io/packages/ijson/ is one with a much different API that is for Python.

6 9