Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

R. David Murray wrote: On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman wrote: Martin v. Löwis wrote: Am 26.02.2012 07:06, schrieb Nick Coghlan: On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote: >>>>> A small quibble: I'd like to see a benchmark of a 'u&#

Re: [Python-Dev] cpython: Close issue #6210: Implement PEP 409

Antoine Pitrou wrote: On Sun, 26 Feb 2012 09:02:59 +0100 nick.coghlan wrote: +def get_output(self, code, filename=None): +""" +Run the specified code in Python (in a new child process) and read the +output from the standard error or from a file (if filename is set).

Re: [Python-Dev] PEP 415: Implementing PEP 409 differently

Benjamin Peterson wrote: 2012/2/27 Ethan Furman : Benjamin Peterson wrote: 2012/2/26 Nick Coghlan : Thanks for writing that up. I'd be amenable if the PEP was clearly updated to say that ``raise exc from cause`` would change from being syntactic sugar for ``_hidden = exc; _hidden.__ca

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

Martin v. Löwis wrote: Eh? The 2.6 version would also be u('that'). That's the whole point of the idiom. You'll need a better counter argument than that. So the idea is to convert the existing 2.6 code to use parenthesis as well? (I obviously haven't read the PEP -- my apologies.) Well, if

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

Antoine Pitrou wrote: On Mon, 27 Feb 2012 13:09:24 -0800 Ethan Furman wrote: Martin v. Löwis wrote: Eh? The 2.6 version would also be u('that'). That's the whole point of the idiom. You'll need a better counter argument than that. So the idea is to convert the exis

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

Brian Curtin wrote: On Mon, Feb 27, 2012 at 17:15, Ethan Furman wrote: This is probably a dumb question, but why can't we add u'' back to 3.2? It seems an incredibly minor change, and we are not in security-only fix stage, are we? We don't add features to bug-fix r

[Python-Dev] Backporting PEP 414

Here's what I know: We don't add features to bug-fix releases. u'' is considered a feature. By not backporting to 3.1 and 3.2 we are not easing the migration pains from 2.x. Here's what I don't know: Why is readding u'' a feature and not a bug? (Just had a thought about this -- because the

Re: [Python-Dev] Non-string keys in type dict

PJ Eby wrote: Short version: AddOns are things you can use to dynamically extend instances -- a bit like the "decorator" in "decorator pattern" (not to be confused with Python decorators). Rather than synthesize a unique string as a dictionary key, I just used the AddOn classes themselves as

Re: [Python-Dev] Non-string keys in type dict

Nick Coghlan wrote: On Thu, Mar 8, 2012 at 11:42 AM, Benjamin Peterson wrote: 2012/3/7 Victor Stinner : Can't we simply raise an error if the dict contains non-string keys? Sounds okay to me. For 3.3, the most we can do is trigger a deprecation warning, since removing this feature *will* br

Re: [Python-Dev] Non-string keys in type dict

Guido van Rossum wrote: On Wed, Mar 7, 2012 at 11:43 PM, Ethan Furman wrote: Are you able to modify classes after class creation in Python 3? Without using a metaclass? Yes, by assignment to attributes. The __dict__ is a read-only proxy, but attribute assignment is allowed. (This is because

Re: [Python-Dev] Non-string keys in type dict

Guido van Rossum wrote: On Thu, Mar 8, 2012 at 8:22 AM, Ethan Furman wrote: Guido van Rossum wrote: On Wed, Mar 7, 2012 at 11:43 PM, Ethan Furman wrote: Are you able to modify classes after class creation in Python 3? Without using a metaclass? Yes, by assignment to attributes. The

Re: [Python-Dev] [Python-checkins] cpython: Close #14205: dict lookup raises a RuntimeError if the dict is modified during

Victor Stinner wrote: On 09/03/2012 22:32, Jim Jewett wrote: I do not believe the change set below is valid. As I read it, the new test verifies that one particular type of Nasty key will provoke a RuntimeError -- but that particular type already did so, by hitting the recursion limit. (It doe

[Python-Dev] im_func: implementation detail?

How does someone know if something in CPython is an implementation detail or not? In the case of im_func, I think it is (an implementation detail), and another person thinks it is part of the language spec. That all implementations must have. ~Ethan~

Re: [Python-Dev] PEP czar for PEP 3144?

Nick Coghlan wrote: Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case. Having only one function return a list instead of an iterator seems questionable. Depending on the

Re: [Python-Dev] PEP czar for PEP 3144?

Guido van Rossum wrote: On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote: Nick Coghlan wrote: Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case. Having only one

Re: [Python-Dev] PEP 405 (built-in virtualenv) status

Carl Meyer wrote: The bulk of the work in PEP 405 is aimed towards a rather different goal from yours - to be able to share an installed Python's copy of the standard library among a number of virtual environments. This is the purpose of the "home" key in pyvenv.cfg and the added sys.base_prefix

Re: [Python-Dev] PEP czar for PEP 3144?

Guido van Rossum wrote: On Mon, Mar 19, 2012 at 1:13 PM, Ethan Furman wrote: Nothing wrong in and of itself. It just seems to me that if we have several functions that deal with ip addresses/networks/etc, and all but one return iterators, that one is going to be a pain... 'Which one retu

Re: [Python-Dev] PEP czar for PEP 3144?

Greg Ewing wrote: Guido van Rossum wrote: I personally like having 'iter' in the name (e.g. iterkeys() -- note that we dropped this in Py3k because it's no longer an iterator, it's a dict view now. But I don't want to promote that style for ipaddr.py. +1 from me too on having all methods that

Re: [Python-Dev] Playing with a new theme for the docs

Guido van Rossum wrote: On Wed, Mar 21, 2012 at 7:18 AM, Ned Batchelder wrote: The challenge for the maintainer of the docs site is to choose a good design that most people will see. We're bound to disagree on what that design should be, and I suggest that probably none of us are designer enou

Re: [Python-Dev] New PEP

Huan Do wrote: *Hi, I am a graduating Berkeley student that loves python and would like to propose an enhancement to python. My proposal introduces a concept of slicing generator. For instance, if one does x[:] it returns a list which is a copy of x. Sometimes programmers would want to iterat

Re: [Python-Dev] Playing with a new theme for the docs

Glenn Linderman wrote: After looking at both a while, my suggestions would be: 1. Preserve the collapsability of the TOC, but possible enhance its recognizability with an X in the upper right of the TOC sidebar, as well as the << in the middle. 2. Make the header fixed, so that the bread cr

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)

Given the cost of the change, and the advent of the PEP-397 Launcher, I also vote -1. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/pyth

Re: [Python-Dev] Playing with a new theme for the docs

Glenn Linderman wrote: On 3/26/2012 10:19 AM, R. David Murray wrote: Like Philip, I have *one* window. My window manager (ratpoison) is more like 'screen' for X: you *can* split the window up, but it is *much* more useful to have only one window visible at a time, most of the time. I'm amaz

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

Georg Brandl wrote: On 25.03.2012 21:11, Steven D'Aprano wrote: Georg Brandl wrote: Thanks everyone for the overwhelmingly positive feedback. I've committed the new design to 3.2 and 3.3 for now, and it will be live for the 3.3 docs momentarily (3.2 isn't rebuilt at the moment until 3.2.3 fin

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

Georg Brandl wrote: Here's another try, mainly with default browser font size, more contrast and collapsible sidebar again: http://www.python.org/~gbrandl/build/html2/ I've also added a little questionable gimmick to the sidebar (when you collapse it and expand it again, the content is shown at

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

Antoine Pitrou wrote: On Mon, 26 Mar 2012 12:25:20 -0700 Ethan Furman wrote: Georg Brandl wrote: On 25.03.2012 21:11, Steven D'Aprano wrote: Georg Brandl wrote: Thanks everyone for the overwhelmingly positive feedback. I've committed the new design to 3.2 and 3.3 for now, and

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

Antoine Pitrou wrote: On Sun, 25 Mar 2012 08:34:44 +0200 Also I think there should be some jquery animation when collapsing/expanding. Please, no. I don't need my technical web pages singing and dancing for me. ;) ~Ethan~ ___ Python-Dev mailing l

Re: [Python-Dev] PEP 418: Add monotonic clock

Nick Coghlan wrote: The 3.3 time module would then be left with three interfaces: time.time() # Highest resolution timer available time.monotonic() # I'm not yet convinced we need the "raw" parameter but don't much mind either way time.try_monotonic() # Monotonic is preferred, but non-monotonic

Re: [Python-Dev] PEP 418: Add monotonic clock

Yury Selivanov wrote: On 2012-03-27, at 9:23 AM, Nick Coghlan wrote: time.try_monotonic() # Monotonic is preferred, but non-monotonic presents a tolerable risk This function seems unnecessary. It's easy to implement it when required in your application, hence I don't think it is worth adding

[Python-Dev] OT: single directory development [was Re: Playing with a new theme for the docs]

PJ Eby wrote: Really? I've been doing "dump the app in a directory" since 1998 or so on various *nix platforms. And when distutils came along, I set up a user-specific cfg to install in the same directory. ISTR a 5-line pydistutils.cfg is sufficient to make everything go into to a particular

[Python-Dev] OT: refusal to listen and learn [was Re: Issue 14417: consequences of new dict runtime error]

Etienne Robillard wrote: your reasoning is pathetic at best. i pass... Thanks for the tip :-) The Python Developer list is for the discussion of developing Python, not for teaching basic programming. You are being rude, and a smiley does not make you less rude. I am adding you to my kill-fi

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Lennart Regebro wrote: On Tue, Apr 3, 2012 at 08:03, Cameron Simpson wrote: clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC) If the symbol names are not the horribleness, can you qualify what API you would like more? Well, get_clock(monotonic=True, highres=True) would be a vast im

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Cameron Simpson wrote: get_clock already has two arguments - you can optionally hand it a clock list - that's used by monotonic_clock() and hires_clock(). def get_clock(*flags, *, clocklist=None): ''' Return a Clock based on the supplied `flags`. The returned clock shall have all th

Re: [Python-Dev] PEP 418: rename time.monotonic() to time.steady()?

Cameron Simpson wrote: Sigh. They're different things! For all that "steady" is a slightly vague term, steady and hires and monotonic are independent concepts. Of course a lot of high quality clocks will embody hires and ideally steady or monotonic. This kind of offer-just-one-thing embedded pol

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Lennart Regebro wrote: On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote: What's unclear about returning None if no clocks match? Nothing, but having to check error values on return functions are not what you typically do in Python. Usually, Python functions that fail raise an error. P

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Oleg Broytman wrote: On Wed, Apr 04, 2012 at 05:47:16PM +0200, Lennart Regebro wrote: On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote: What's unclear about returning None if no clocks match? Nothing, but having to check error values on return functions are not what you typically

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Georg Brandl wrote: Am 04.04.2012 18:18, schrieb Ethan Furman: Lennart Regebro wrote: On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote: What's unclear about returning None if no clocks match? Nothing, but having to check error values on return functions are not what you typically

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Oleg Broytman wrote: On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote: Oleg Broytman wrote: . Pythonic equivalent of "get_clock(THIS) or get_clok(THAT)" is for flag in (THIS, THAT): try: clock = get_clock(flag) except: pass else:

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Cameron Simpson wrote: On 04Apr2012 22:23, PJ Eby wrote: | On Apr 4, 2012 7:28 PM, "Victor Stinner" wrote: | > More details why it's hard to define such function and why I dropped | > it from the PEP. | > | > If someone wants to propose again such function ("monotonic or | > fallback to system"

Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Victor Stinner wrote: I changed time.monotonic() to not fallback to the system clock exactly for this reason: Python cannot guess what the developer expects, or how the developer will use the clock. Which is exactly why I like Cameron Simpson's approach to selecting a clock -- let the develope

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Oleg Broytman wrote: On Wed, Apr 04, 2012 at 12:52:00PM -0700, Ethan Furman wrote: Forced? I do not use Python to be forced to use one style of programming over another. Then it's strange you are using Python with its strict syntax (case-sensitivity, forced indents), ubiquitous excep

Re: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Oleg Broytman wrote: On Thu, Apr 05, 2012 at 11:56:00AM -0700, Ethan Furman wrote: It's only an error if it's documented that way and, more importantly, thought of that way. The re module is a good example: if it can't find what you're looking for it returns None -- i

Re: [Python-Dev] an alternative to embedding policy in PEP 418

Oleg Broytman wrote: On Fri, Apr 06, 2012 at 11:57:20AM +0900, "Stephen J. Turnbull" wrote: What I want to know is why you're willing to assert that absence of a clock of a particular configuration is an Exception, when that absence clearly documented to be a common case? An error or not

Re: [Python-Dev] an alternative to embedding policy in PEP 418

Lennart Regebro wrote: On Fri, Apr 6, 2012 at 00:17, Cameron Simpson wrote: Good point, but the same does for using flags. If you don't pass in the MONOTONIC flag, what happens? Only reading the documentation will tell you. As such this, if anything, is an indication that the get_clock() API

[Python-Dev] __hash__ documentation

http://bugs.python.org/issue14617 Patch attached to issue. ~Ethan~ ___ 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-archi

Re: [Python-Dev] __hash__ documentation

Brian Curtin wrote: On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: Those who follow the bug tracker will see the issue and act accordingly. How does one follow the bug tracker? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http

Re: [Python-Dev] __hash__ documentation

Brian Curtin wrote: On Wed, Apr 18, 2012 at 13:07, Ethan Furman wrote: http://bugs.python.org/issue14617 Patch attached to issue. Can I request that you not immediately post issues to python-dev? Those who follow the bug tracker will see the issue and act accordingly. (unless I missed some

Re: [Python-Dev] [Python-checkins] cpython (3.2): don't use a slot wrapper from a different special method (closes #14658)

Mark Shannon wrote: Benjamin Peterson wrote: 2012/4/24 Mark Shannon : I'm not happy with this fix. It's not perfect, but it's an improvement. Admittedly code like: class S(str): __getattr__ = str.__add__ s = S('a') print(S.b) My typo, should be: print(s.b) (Instance not class) is a l

[Python-Dev] netiquette on py-dev

Okay, advice please. When responding to posts, should the poster to whom I am responding be listed as well as python-dev, or should my responses just go to python-dev? I see both ways occuring, and am not sure if one or the other is preferred. As a reference point, on python-list I almost nev

[Python-Dev] doc change for weakref

I'd like to make a slight doc change for weakref to state (more or less): weakrefs are not invalidated when the strong refs are gone, but rather when garbage collection reclaims the object Should this be accurate for all implementations, or should it be more along the lines of: we

Re: [Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

Nick Coghlan wrote: On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote: The reason for wanting this to be transparent is that 1) if you forget the redundant class-decorator, mixin, or metaclass, stuff will silently not work, Why would it silently not work? What's preventing you from having decorator

Re: [Python-Dev] Updated PEP 362 (Function Signature Object)

Yury Selivanov wrote: We can implement the __eq__ operator though. +1 ___ 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-a

Re: [Python-Dev] Import semantics?

Dan Stromberg wrote: On Fri, Jun 8, 2012 at 3:16 PM, Ethan Furman wrote: Dan Stromberg wrote: Did the import semantics change in cpython 3.3a4? I used to be able to import treap.py even though I had a treap directory in my cwd. With 3.3a4, I have to rename the treap directory to see treap.py

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

Terry Reedy wrote: http://bugs.python.org/issue12982 Currently, cpython requires the -O flag to *read* .pyo files as well as the write them. This is a nuisance to people who receive them from others, without the source. The originator of the issue quotes the following from the doc (without gi

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

Alexandre Zani wrote: On Tue, Jun 12, 2012 at 11:41 AM, Ethan Furman wrote: Terry Reedy wrote: http://bugs.python.org/issue12982 Currently, cpython requires the -O flag to *read* .pyo files as well as the write them. This is a nuisance to people who receive them from others, without the

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

Brett Cannon wrote: On Tue, Jun 12, 2012 at 2:16 PM, Terry Reedy wrote: http://bugs.python.org/__issue12982 Currently, cpython requires the -O flag to *read* .pyo files as well as the write them. This is a nuisance to people who receive them from others, wit

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

Toshio Kuratomi wrote: On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote: OK, but you didn't answer the question :). If I understand correctly, everything you said applies to *writing* the bytecode, not reading it. So, is there any reason to not use the .pyo file (if that's all t

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

R. David Murray wrote: On Wed, 13 Jun 2012 20:46:50 +0200, Antoine Pitrou wrote: On Wed, 13 Jun 2012 11:20:24 -0700 Toshio Kuratomi wrote: On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote: OK, but you didn't answer the question :). If I understand correctly, everything you sa

Re: [Python-Dev] #12982: Should -O be required to *read* .pyo files?

Steven D'Aprano wrote: On Wed, Jun 13, 2012 at 03:13:54PM -0400, R. David Murray wrote: Again, a program that depends on asserts is buggy. As Ethan pointed out we are asking about the case where someone is *deliberately* setting the .pyo file up to be run as the "normal" case. You can't be s

Re: [Python-Dev] PEP 362 Third Revision

Brett Cannon wrote: On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov > wrote: [SNIP] Let's consider replacement of 'Parameter.is_*' set of attributes with a single 'Parameter.kind' attribute, which will have the following possible values: 'posi

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: On 2012-06-14, at 11:24 AM, Brett Cannon wrote: On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov wrote: [SNIP] Let's consider replacement of 'Parameter.is_*' set of attributes with a single 'Parameter.kind' attribute, which will have the following possible values: 'pos

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ It's possible to test Signatures for equality. Two signatures are equal when they have equal parameters and return annotations. Possibly a dumb question, but do the parameter n

Re: [Python-Dev] PEP 362 Third Revision

Alexandre Zani wrote: I don't think it really breaks TOOWTDI because you're talking about two use-cases. In one case, you're checking if something is a particular kind of parameter. In the other case, you're doing some sort of dict-based dispatch. I also think is_args etc is cleaner to use when d

Re: [Python-Dev] PEP 362 Third Revision

Antoine Pitrou wrote: On Thu, 14 Jun 2012 09:32:59 -0700 Benjamin Peterson wrote: How about adding 'kind' and keeping 'is_*' attributes, but making them read-only dynamic properties, i.e.: class Parameter: ... @property def is_vararg(self): return self.kind == 'v

Re: [Python-Dev] PEP 362 Third Revision

Yury Selivanov wrote: I'll amend the PEP this evening to replace 'is_args', 'is_kwargs', and 'is_keyword_only' with a 'kind' attribute, with possible values: 'positional', 'vararg', 'varkw', 'kwonly'. Parameter class will have four constants, respectively: class Parameter: KIND_PO

Re: [Python-Dev] PEP 362 Third Revision

Nick Coghlan wrote: I like the idea of a kind attribute, I don't like the current names for the possible values. At the very least, "positional only" needs to be supported to handle nameless parameters in C functions (or those that unpack *args internally) The level of abbreviation used also

Re: [Python-Dev] PEP 362: 4th edition

Yury Selivanov wrote: On 2012-06-18, at 4:25 PM, Guido van Rossum wrote: On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov wrote: The rationale is that sometimes you need to modify signatures. For instance, in decorators. A decorator should make a modified copy, not modify it in place (since

Re: [Python-Dev] PEP 362 minor nits

Jim Jewett wrote: 48 * parameters : OrderedDict 49 An ordered mapping of parameters' names to the corresponding 50 Parameter objects (keyword-only arguments are in the same order 51 as listed in ``code.co_varnames``). Are you really sure you want to promise the keywor

Re: [Python-Dev] pep 362 - 5th edition

Yury Selivanov wrote: Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ Summary: 1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'. __copy__ creates a shallow copy of Signature, shallow copying its Parameters as well. 2. 'Signature.fo

Re: [Python-Dev] pep 362 - 5th edition

Yury Selivanov wrote: On 2012-06-19, at 11:55 AM, Ethan Furman wrote: Yury Selivanov wrote: Hello, The new revision of PEP 362 has been posted: http://www.python.org/dev/peps/pep-0362/ Summary: 1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'. __copy__ cr

Re: [Python-Dev] Status of packaging in 3.3

Éric Araujo wrote: This leaves (d), after long reflection, as my preferred choice, even though I disliked the idea at first (and I fully expect Tarek to feel the same way). Thanks for reading; please express your opinion (especially Tarek as d2 project lead, Georg as RM and Guido as BDFL).

[Python-Dev] Feature Freeze

Does the feature freeze affect documentation enhancements? If it does, can somebody review (and commit! :) issues: http://bugs.python.org/issue14954 http://bugs.python.org/issue14617 Thanks! (And if not necessary before the feature freeze, sorry for the noise.) ~Ethan~ ___

Re: [Python-Dev] A Desperate Plea For Introspection (aka: BDFAP Needed)

Guido van Rossum wrote: On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov wrote: On 2012-06-22, at 3:18 PM, Guido van Rossum wrote: On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov wrote: Yes, I meant optional. Would 'name(arg1, *, [arg2])' be better? Hardly, because that's not valid synta

Re: [Python-Dev] A Desperate Plea For Introspection (aka: BDFAP Needed)

Yury Selivanov wrote: On 2012-06-22, at 3:47 PM, Ethan Furman wrote: Guido van Rossum wrote: On Fri, Jun 22, 2012 at 12:24 PM, Yury Selivanov wrote: On 2012-06-22, at 3:18 PM, Guido van Rossum wrote: On Fri, Jun 22, 2012 at 12:10 PM, Yury Selivanov wrote: Yes, I meant optional. Would

Re: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging

Chris McDonough wrote: People typically look for code on PyPI that solves a problem, and branding in namespacing there is usually confusing. E.g. there are many highly-general useful things in both the zope When I search PyPI I ignore anything with djange, zope, etc., as I have zero interest

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

M Stefan wrote: Also, what would iter([1,2,3]).__length_hint__() return? 3 or unknown? If 3, then the semantics of l=[1,2,3]; l += iter(l) will change (infinite loop without __length_hint__ vs. list of 6 elements with __length_hint__). What __length_hint__ returns is irrelevant -- it's only a

Re: [Python-Dev] Doc/ACKS and Misc/ACKS

Brian Curtin wrote: On Mon, Jul 23, 2012 at 1:28 PM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/07/12 19:30, Eli Bendersky wrote: That said, we could probably merge Doc/ACKS and Misc/ACKS (*). There doesn't seem to be any strong argument for separating doc contributi

Re: [Python-Dev] hg.python.org should default to defaut, not 2.7

Ned Deily wrote: In article , Terry Reedy wrote: If one goes to http://hg.python.org/cpython/ and clicks 'browse', it defaults to 2.7, not to default (now 3.3). Moreover, there is no indication that it is defaulting to an old branch rather than current default, as one might reasonably expec

Re: [Python-Dev] hg.python.org should default to defaut, not 2.7

Antoine Pitrou wrote: On Thu, 30 Aug 2012 13:34:56 -0700 Ethan Furman wrote: Ned Deily wrote: Terry Reedy wrote: If one goes to http://hg.python.org/cpython/ and clicks 'browse', it defaults to 2.7, not to default (now 3.3). Moreover, there is no indication that it is defaulting

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

Steven D'Aprano wrote: On 20/09/12 22:59, Mark Dickinson wrote: On Thu, Sep 20, 2012 at 1:21 PM, Nick Coghlan wrote: +1 for using the unqualified "argument" in these error messages to mean "positional or keyword argument" (inspect.Parameter spells it out as POSITIONAL_OR_KEYWORD, but the full

Re: [Python-Dev] TypeError: f() missing 1 required positional argument: 'x'

Steven D'Aprano wrote: I would like to see error messages reserve the terms: 1) "positional" for explicitly positional-only parameters; 2) "keyword" for explicitly keyword-only parameters; +1 ___ Python-Dev mailing list Python-Dev@python.org http://m

Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3

Mark Lawrence wrote: On 24/09/2012 07:18, Georg Brandl wrote: [snip impressive list of improvements] Yes, but apart from all that, what have the python devs ever done for us? Nothing :) I'll take that kind of nothing any day of the week! ;) ~Ethan~ __

Re: [Python-Dev] Stdlib and timezones, again

Matthias Klose wrote: On 30.09.2012 20:18, Gregory P. Smith wrote: priority: 1) api call supplying tz data to the process. 2) pytzdata module if it exists 3) tz data from the underlying operating system 4) error. I disagree on this order, at least for Linux systems. the tzdata database

Re: [Python-Dev] Proposed schedule for Python 3.4

Nick Coghlan wrote: On Wed, Oct 3, 2012 at 8:58 PM, Brian Curtin wrote: This doesn't answer the question of the users wanting the alphas earlier, but they're certainly more than largely ignored... The webstats in April 2012 show 5628 downloads of 3.3a1 and 4946 downloads of 3.3a2 Windows insta

Re: [Python-Dev] performance of {} versus dict()

MRAB wrote: On 2012-11-14 20:53, Mark Adam wrote: On Wed, Nov 14, 2012 at 1:37 PM, Xavier Morel wrote: On 2012-11-14, at 19:54 , Mark Adam wrote: Merging of two dicts is done with dict.update. No, dict.update merges one dict (or two) into a third one. No. I think you need to read the do

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

On 01/28/2013 04:17 PM, Ralf Schmitt wrote: Guido van Rossum writes: On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt wrote: Guido van Rossum writes: Yeah, so the answer to all this is that 3rd party libraries know better than to mess with global settings. Right. But why make it configurabl

Re: [Python-Dev] Why does Signature.from_function() have to check the type of its argument?

On 02/10/2013 01:46 PM, PJ Eby wrote: How about you return FunctionType as your __class__ attribute? ;-) Your type() will still be different, but isinstance() also considers the __class__ if it's different from the type(). (At least it does in 2.x, I've not tried it in any 3.x versions yet...)

[Python-Dev] Re: SC 2020 recommendation for PEP 634

On 12/7/20 11:29 AM, Brett Cannon wrote: After much deliberation, the 2020 SC will be making a recommendation to the 2021 SC to accept PEP 634 (although this was not a unanimous decision). This seems very odd. The Steering Council is elected to make decisions, but it feels like the current SC

[Python-Dev] [slightly OT] cryptographically strong random.SystemRandom()

Greetings! A question [1] has arisen about the viability of `random.SystemRandom` in Pythons before and after the secrets module was introduced (3.5 I think) -- specifically does it give independent and uniform discrete distribution for cryptographic purposes across CPython 3.x version

[Python-Dev] Re: RFC for PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

On 7/21/21 5:33 AM, Nick Coghlan wrote: > I don't have any substantive comments on what you're proposing (aside > from "Yes, that sounds reasonable to me"), so my comments below are > just some minor suggested clarifications for the PEP text. Thanks, PEP updated. -- ~Ethan~

<    11   12   13   14   15   16