Re: [Python-Dev] Surely "nullable" is a reasonable name?
On Mon, Aug 4, 2014 at 10:12 AM, Larry Hastings wrote: > > It's my contention that "nullable" is the correct name. But I've been asked > to bring up the topic for discussion, to see if a consensus forms around > this or around some other name. > > Let the bike-shedding begin, > > > /arry +1 for some form of "allow None" rather than "nullable". - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] List insert at index that is well out of range - behaves like append
On Mon, Sep 15, 2014 at 6:18 AM, Harish Tech wrote: > I had a list > > a = [1, 2, 3] > > when I did > > a.insert(100, 100) > > [1, 2, 3, 100] > > as list was originally of size 4 and I was trying to insert value at index > 100 , it behaved like append instead of throwing any errors as I was trying > to insert in an index that did not even existed . > > > Should it not throw > > > IndexError: list assignment index out of range > > > exception as it throws when I attempt doing > > > a[100] = 100 > > Question : 1. Any idea Why has it been designed to silently handle this > instead of informing the user with an exception ? > > > Personal Opinion : Lets see how other dynamic languages behave in such a > situation : Ruby : > > > > a = [1, 2] > > > a[100] = 100 > > > a > > => [1, 2, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, > nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 100] > > The way ruby handles this is pretty clear and sounds meaningful (and this is > how I expected to behave and it behaved as per my expectation) at least to > me . So what I felt was either it should throw exception or do the way ruby > handles it . > > > Is ruby way of handling not the obvious way ? > > I even raised it in stackoverflow > http://stackoverflow.com/questions/25840177/list-insert-at-index-that-is-well-out-of-range-behaves-like-append > > and got some responses . Hello Harish, The appropriate place to ask questions like this is python-list [1], or perhaps Stack Overflow. If you meant to suggest changing the behavior of Python in such cases, you should first discuss this on python-list, and then post a clearly written suggestion to python-ideas [2]. This list, python-dev, is used for discussing the development *of* the Python language. See the "Python Mailing Lists" page [3] for more information. Regards, - Tal Einat ..[1]: http://mail.python.org/mailman/listinfo/python-list ..[2]: http://mail.python.org/mailman/listinfo/python-ideas ..[3]: https://www.python.org/community/lists/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Surely "nullable" is a reasonable name?
On Sun, Apr 19, 2015 at 11:19 AM, Larry Hastings wrote:
>
>
> On 08/07/2014 09:41 PM, Larry Hastings wrote:
>
> Well! It's rare that the core dev community is so consistent in its
> opinion. I still think "nullable" is totally appropriate, but I'll change
> it to "allow_none".
>
>
> (reviving eight-month-old thread)
>
> In case anybody here is still interested in arguing about this: the Clinic
> API may be shifting a bit here. What follows is a quick refresher course on
> Argument Clinic, followed by a discussion of the proposed new API.
>
> Here's an Argument Clinic declaration of a parameter:
> s: str()
> The parameter is called "s", and it's specifying a converter function called
> "str" which handles converting string parameters. The str() converter
> itself accepts parameters; since the parameters all have default values,
> they're all optional. By default, str() maps directly to the "s" format
> unit for PyArg_ParseTuple(), as it does here.
>
> Currently str() (and a couple other converter functions) accepts a parameter
> called "types". "types" is specified as a string, and contains an unordered
> set of whitespace-separated strings representing the Python types of the
> values this (Clinic) parameter should accept. The default value of "types"
> for str() is "str"; the following declaration is equivalent to the
> declaration above:
> s: str(types="str")
> Other legal values for the "types" parameter for the str converter include
> "bytes bytearray str" and "robuffer str". Internally the types parameter is
> converted into a set of strings; passing it in as a string is a nicety for
> the caller's benefit. (It also means that the strings "robuffer str" and
> "str robuffer" are considered equivalent.)
>
> There's a second parameter, currently called "nullable", but I was supposed
> to rename it "allow_none", so I'll use that name here. If you pass in
> "allow_none=True" to a converter, it means "this (Clinic) parameter should
> accept the Python value None". So, to map to the format unit "z", you would
> specify:
> s: str(allow_none=True)
>
> And to map to the format unit "z#", you would specify:
> s: str(types="robuffer str", allow_none=True, length=True)
>
>
> In hindsight this is all a bit silly. I propose what I think is a much
> better API below.
>
> We should rename "types" to "accept". "accept" should takes a set of types;
> these types specify the types of Python objects the Clinic parameter should
> accept. For the funny pseudo-types needed in some Clinic declarations
> ("buffer", "robuffer", and "rwbuffer"), Clinic provides empty class
> declarations so these behave like types too.
>
> accept={str} is the default for the str() converter. If you want to map to
> format unit "z", you would write this:
> s: str(accept={str, NoneType})
> (In case you haven't seen it before: NoneType = type(None). I don't think
> the name is registered anywhere officially in the standard library... but
> that's the name.)
>
> The upside of this approach:
>
> Way, way more obvious to the casual reader. "types" was always meant as an
> unordered collection of types, but I felt specifying it with strings was
> unwieldy and made for poor reading ({'str', 'robuffer'}). Passing it in as
> a single string which I internally split and put in a set() was a bad
> compromise. But the semantics of this whitespace-delimited string were a
> bit unclear, even to the experienced Clinic hacker. This set-of-types
> version maps exactly to what the parameter was always meant to accept in the
> first place. As with any other code, people will read Clinic declarations
> far, far more often than they will write them, so optimizing for clarity is
> paramount.
> Zen: "There should be one (and preferably only one) obvious way to do it."
> We have a way of specifying the types this parameter should accept;
> "allow_none" adds a second.
> Zen: "Special cases aren't special enough to break the rules". "allow_none"
> was really just a special case of one possible type for "types".
>
>
> The downside of this approach:
>
> You have to know what the default accept= set is for each converter.
> Luckily this is not onerous; there are only four converters that need an
> "accept" parameter, and their default values are all simple:
>
> int(accept={int})
> str(accept={str})
> Py_UNICODE(accept={str})
> Py_buffer(accept={buffer})
>
> I suggest this is only a (minor) problem when writing a Clinic
> declaration. It doesn't affect later readability, which is much more
> important.
>
> It means repeating yourself a little. If you just want to say "I want to
> accept None too", you have to redundantly specify the default type(s)
> accepted by the converter function. In practice, it's really only redundant
> for four or five format units, and they're not the frequently-used ones.
> Right now I only see three uses of nullable for the built-in format units
> (there are two more
Re: [Python-Dev] Surely "nullable" is a reasonable name?
On Tue, Apr 21, 2015 at 8:31 PM, Larry Hastings wrote:
>
> On 04/21/2015 04:50 AM, Tal Einat wrote:
>
> As for the default set of accepted types for various convertors, if we
> could choose any syntax we liked, something like "accept=+{NoneType}"
> would be much better IMO.
>
>
> In theory Argument Clinic could use any syntax it likes. In practice, under
> the covers we tease out one or two bits of non-Python syntax, then run
> ast.parse over it. Saved us a lot of work.
>
> "s: accept={str,NoneType}" is a legal Python parameter declaration; "s:
> accept+={NoneType}" is not. If I could figure out a clean way to hack in
> support for += I'll support it. Otherwise you'll be forced to spell it out.
Actually, I wrote "accept=+{NoneType}" - note the plus is *after* the
equal sign. This is a valid Python assignment expression. (The unary
addition operator is not defined for sets, however.)
- Tal Einat
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Surely "nullable" is a reasonable name?
On Sat, Apr 25, 2015 at 10:58 AM, Larry Hastings wrote:
>
> On 04/24/2015 09:45 PM, Nick Coghlan wrote:
>
> Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
>
>
> Not exactly. The way I figure it, the best way to achieve this with unary
> plus is to ast.parse it (as we currently do) and then modify the parse tree.
> That works but it's kind of messy.
>
> My main objection to this notation is that that set objects don't support +.
> The union operator for sets is |.
>
> I've prototyped a hack allowing
> str(accept|={NoneType})
> I used the tokenize module to tokenize, modify, and untokenize the converter
> invocation. Works fine. And since augmented assignment is (otherwise)
> illegal in expressions, it's totally unambiguous. I think if we do it at all
> it should be with that notation.
We're deep into bike-shedding territory at this point, but I prefer
Nick's suggestion of using the Ellipses for this. It's the simplest
and most obvious syntax suggested so far.
- Tal
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac popups running make test
On Sun, May 10, 2015 at 5:07 PM, Brett Cannon wrote: > > > On Sun, May 10, 2015 at 10:04 AM Skip Montanaro > wrote: > >> I haven't run the test suite in awhile. I am in the midst of running it >> on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup: >> >> >> >> I assume this is testing some server listening on localhost. Is this a >> new thing, either with the Python test suite or with Mac OS X? (I'd >> normally be hidden behind a NAT firewall, but at the moment I am on a >> miserable public connection in a Peet's Coffee, so it takes on slightly >> more importance...) >> > > It's not new. > Indeed, I've run into this as well. > >> I've also seen the Crash Reporter pop up many times, but as far as I >> could tell, in all cases the test suite output told me it was expected. >> Perhaps tests which listen for network connections should also mention >> that, at least on Macs? >> > > Wouldn't hurt. Just requires tracking down which test(s) triggers it > (might be more than one and I don't know if answering that popup applies > for the rest of the test execution or once per test if you use -j). > If anyone starts working on this, let me know if I can help, e.g. trying things on my own Mac. - Tal ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac popups running make test
On Sun, May 10, 2015 at 9:07 PM, Carol Willing < willi...@willingconsulting.com> wrote: > > On 5/10/15 10:29 AM, Tal Einat wrote: > > On Sun, May 10, 2015 at 5:07 PM, Brett Cannon wrote: > >> >> >> On Sun, May 10, 2015 at 10:04 AM Skip Montanaro >> wrote: >> >>> I haven't run the test suite in awhile. I am in the midst of running it >>> on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup: >>> >>> >>> >>> I assume this is testing some server listening on localhost. Is this a >>> new thing, either with the Python test suite or with Mac OS X? (I'd >>> normally be hidden behind a NAT firewall, but at the moment I am on a >>> miserable public connection in a Peet's Coffee, so it takes on slightly >>> more importance...) >>> >> >> It's not new. >> > > Indeed, I've run into this as well. > > >> >>> I've also seen the Crash Reporter pop up many times, but as far as I >>> could tell, in all cases the test suite output told me it was expected. >>> Perhaps tests which listen for network connections should also mention >>> that, at least on Macs? >>> >> >> Wouldn't hurt. Just requires tracking down which test(s) triggers it >> (might be more than one and I don't know if answering that popup applies >> for the rest of the test execution or once per test if you use -j). >> > > If anyone starts working on this, let me know if I can help, e.g. trying > things on my own Mac. > >I believe that the message has to do with OS X's sandboxing > implementation and the setting of the sandbox's entitlement keys. Here's an > Apple doc: > https://developer.apple.com/library/ios/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW9 > > I'm unaware of a way to work around this other than using Apple's code > signing or adjusting target build settings in XCode :( If anyone knows a > good way to workaround or manually set permission (other than clicking the > Allow button), I would be interested. > I was reading about this a few weeks ago an recall finding a way to ad-hoc sign the built python executable. Here's a link below. I haven't tried this, though, and don't know if it would work with a python executable rather than a proper OSX app. If it does work, it would be useful to add this as a tool and/or mention it in the developer docs. http://apple.stackexchange.com/a/121010 - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac popups running make test
On Tue, May 12, 2015 at 4:14 PM, Skip Montanaro wrote: > > > Twice now, I've gotten this popup: ... > > Let me improve my request, as it seems there is some confusion about > what I want. I'm specifically not asking that the popups not be > displayed. I don't mind dismissing them. When they appear, I would, > however, like to glance over at the stream of messages emitted by the > test runner and see a message about it being expected. It seems that > the tests which can trigger the crash reporter do this. In my case, the popups appear but then disappear within a fraction of a second, and this happens about 10-20 times when running the full test suite. So I don't have a chance to interact with the popups, and this causes test failures. Also, when running a large suite of tests, I may not be looking at the screen by the time these popups appear. I wouldn't want the tests to fail nor would I want the test run to stall. I can't test this right now, but does disabling the "network" resource avoid these popups? Though even if it does we'll still need a way to run network-related tests on OSX. Regards, - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sat, May 23, 2015 at 1:34 AM, Berker Peksağ wrote: > > On Sat, May 23, 2015 at 12:53 AM, Chris Barker wrote: > > On Fri, May 22, 2015 at 2:33 PM, Larry Hastings wrote: > >> > >> On 05/22/2015 02:29 PM, Chris Barker wrote: > >> > >> Is it too late to get the isclose() code (PEP 485) into 3.5? > > > > ... > >> > >> Hopefully you can find a core dev familiar enough with the issues > >> involved that they can (quickly!) guide it through the process of getting > >> it > >> checked in. > > > > Ping! Anyone willing to sponsor this? > > ... > > * The C implementation should be in Modules/mathmodule.c > * Tests should be in Lib/test/test_math.py > * Documentation should be in Doc/library/math.rst > * Add an entry to Doc/whatsnew/3.5.rst > * If I remember correctly, we don't need the Python implementation and its > tests I'll happily review the patch once it's on the bug tracker as Berker described. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sat, May 23, 2015 at 4:25 PM, Nick Coghlan wrote: > On 23 May 2015 at 19:29, Tal Einat wrote: >> On Sat, May 23, 2015 at 1:34 AM, Berker Peksağ >> wrote: >>> >>> * The C implementation should be in Modules/mathmodule.c >>> * Tests should be in Lib/test/test_math.py >>> * Documentation should be in Doc/library/math.rst >>> * Add an entry to Doc/whatsnew/3.5.rst >>> * If I remember correctly, we don't need the Python implementation and its >>> tests >> >> I'll happily review the patch once it's on the bug tracker as Berker >> described. > > I filed http://bugs.python.org/issue24270 to track this, but there's a > fair bit of work to be done to integrate the changes into the existing > math module's code, tests and documentation. Done. Patch attached to the issue. Awaiting review! - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sun, May 24, 2015 at 6:40 PM, Chris Barker wrote: > > What do folks think about adding one to cmath as well, while we are at it? > It should be pretty straightforward -- I could focus what time I have to do > that. I prefer focusing on getting math.isclose() in before tackling cmath.isclose(), though it would indeed be very straightforward given the work already done. Larry has stated he's willing to make an exception to the "no new features" rule for this, so I think we should have time to get the cmath version in for 3.5 even if we wait a few days with it. So if you have time, I'd prefer that you thoroughly review the patch. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 485: math.isclose()
On Mon, May 25, 2015 at 7:53 AM, Chris Barker wrote: > I don't think I have permissions to comment on the issue,so I'm posting > here. If there is a way for me to post to the issue, someone let me know... You just need to register on the issue tracker. On bugs.python.org, there is a "register" link under the "User" section on the navigation bar. > In the issue (http://bugs.python.org/issue24270) Tal wrote > > [...] > > """ > Should we just leave things as they are and remove mention of complex > values from the PEP (it isn't mentioned in the docs)? > """ > I'll update the PEP. If we're going to add a separate complex version of isclose() to the cmath module, then you should probably leave the PEP as it is. While we're on the subject of the PEP, is there a reason that the cmath version should accept complex values for the tolerances? I'd expect it to accept only floats, and I think that allowing complex values would be more confusing than useful. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 485: math.isclose()
On Mon, May 25, 2015 at 9:45 AM, Chris Barker wrote: > And a few comments on the patch ( I have not idea how to patch a patch...) > Is there a branch somewhere with this patch applied? Not at the moment. But if you click the "review" link next to the patch on the tracker then you can leave comments "inside" the patch, and we can discuss them there directly. For future reference, that's the preferred place for these type of comments. I'll work your comment into a revised version of the patch and have it up later today. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do people like the early 3.5 branch?
On Wed, Jun 17, 2015 at 2:26 AM, Larry Hastings wrote: > > > A quick look through the checkin logs suggests that there's literally > nothing happening in 3.6 right now. All the checkins are merges. > > Is anyone expecting to do work in 3.6 soon? Or did the early branch just > create a bunch of make-work for everybody? Work on Argument Clinic conversion is continuing (slowly) on the default branch, without interfering with the 3.5 release process. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] raw_input prompt not printed on sys.stderr
On Mon, Jul 6, 2015 at 11:45 PM, Clement Rouault wrote: > Hi, > > While playing with non-standard sys.stdout/stderr, I noticed that the > prompt of raw_input was printed on stderr (not sys.stderr) (see > Parser/myreadline.c:120). > > I found an issue (http://bugs.python.org/issue1927) from 2008 talking > about changing stderr to stdout. But nobody in the thread seems > bothered by the use of stdout/err over the ones in the sys module. > > So, is there any good reason I might not be aware of that justifies > the use of stderr over sys.stderr ? See issue #24402: input() uses sys.__stdout__ instead of sys.stdout for prompt That issue was deemed probably a bug, and includes a simple patch which appears to fix the issue (without tests). - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 10:05 AM, Larry Hastings wrote: > > Okay, I'm taking a poll. I will total your answers and take the result... > strongly under advisement. ;-) +1 for #5, +0.5 for #4, -1 for the rest. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Argument Clinic: Bug? self converters are not preserved when cloning functions
Hi, I'm working on converting Objects/bytearray.c and Objects/bytes.c. For bytes, the strip methods need a "self converter" so that they get a PyBytesObject* instead of PyObject*. However, having set this in bytes.strip and "cloning" that clinic definition for bytes.lstrip and bytes.rstrip, it appears that the self converter wasn't set on lstrip and rstrip. Removing the cloning and copying the argument definitions resolved the issue. Is this a bug? - Tal ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A Friendly IDLE
On Thu, Apr 10, 2014 at 12:42 AM, Terry Reedy wrote: > On 4/9/2014 12:25 AM, adnanume...@gmail.com wrote: > Python-list, python-ideas, or idle-dev lists might have been better places to > put this, but here are my responses. I'm adding idle-dev, where this belongs. Further discussion should take place there rather than on python-dev. >> 3. >> In Python Shell Save & Save As menus are enable and using them we >> can save shell text as python script (.py) that never executes again >> on IDLE. I recommends to either disable this option or save shell >> text as plain text. I made a little try to disable this and succeed. > > > We will not disable being able to save the shell window. > http://bugs.python.org/issue11838 is about saving in runnable form. If IDLE saves the shell history to a file with a .py extension by default, that is indeed confusing. It is useful to be able to save the history to a file, but it shouldn't have a .py extension. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 10:18 AM, Chris Withers wrote: > A couple of others that have raised some consternation; what are the > technical reasons for this pattern being bad: > > if len(seq) > if not len(seq) > > ...or, for me, the rather ugly: > > if 0 != len(seq) > > Likewise, these: > > if greeting == True: > if greeting is True: As far as I know that reason for these examples being frowned upon is that they are needlessly redundant. This is not just a matter of minimalism or style; it's a matter of readability. If you're relying on the "len()" call to fail if "seq" isn't a container (for example, if it's None), the code for that should be separate and more explicit. Regarding "if something == True", that's only the same as "if greeting" if greeting is assumed to be a boolean value. If so, it is better (for readability) to use a descriptive variable name: "if should_greet:". Otherwise (e.g. if greeting could also be None) it is reasonable to check if it is equal to a specific value (with a short comment explaining this point!). Also, there's no end to how much comparison to True one can do: if (greeting == True) == True if ((greeting == True) == True) == True Considering that, IMO it makes sense to just avoid such comparisons altogether. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
On Thu, Apr 24, 2014 at 4:59 PM, Barry Warsaw wrote: > I will say this: the original preference for underscore_names in PEP 8 was > spurred by user studies some of our early non-native English speaking users > conducted many years ago. We learned that it was more difficult for many of > them to parse mixedCase names than underscore_names. I'm afraid I probably no > longer have references to those studies, but the difference was pronounced, > IIRC, and I think it's easy to see why. Underscores can be scanned by the eye > as spaces, while I'd hypothesize that the brain has to do more work to read > mixedCase names. I speak two languages as mother tongues - English and Hebrew. Hebrew has no capital letters (and is also right-to-left) and is the spoken and written language in the parts of Israel where I've lived most of my life. Perhaps because of this, I do find that capital letters don't quite "jump out" for me and therefore I find mixedCase and CamelCase harder to grok at a quick glance than under_score_names. - Tal ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Minor clean-ups for heapq.
On Tue, May 27, 2014 at 2:45 PM, Michael Urman wrote:
> On Tue, May 27, 2014 at 4:05 AM, Chris Angelico wrote:
>> On Tue, May 27, 2014 at 6:58 PM, Serhiy Storchaka
>> wrote:
>>> 26.05.14 10:59, raymond.hettinger написав(ла):
+result = [(elem, i) for i, elem in zip(range(n), it)]
>>>
>>>
>>> Perhaps it is worth to add simple comment explaining why this is not
>>> equivalent to just list(zip(it, range(n))). Otherwise it can be
>>> unintentionally "optimized" in future.
>>>
>>
>> Where is the difference? I'm very much puzzled now. My first thought
>> was based on differing-length iterables in zip, but the docs say it
>> stops at the shortest of its args.
>
> Due to how zip stops, it leaves the longer iterable in different places:
>
it = iter(string.ascii_letters); list(zip(range(3), it)); next(it)
> [(0, 'a'), (1, 'b'), (2, 'c')]
> 'd'
it = iter(string.ascii_letters); list(zip(it, range(3))); next(it)
> [('a', 0), ('b', 1), ('c', 2)]
> 'e'
>
> This seems like a potentially nasty gotcha, but I'm unclear what real
> use cases would be impacted.
If that's the issue, a comment explaining it should definitely be added.
We could also use islice(enumerate(it), n)) to avoid the confusion.
- Tal
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Raspberry Pi Buildbot
Is there one? If not, would you like me to set one up? I've got one at home with Raspbian installed not doing anything, it could easily run a buildslave. Poking around on buildbot.python.org/all/builders, I can only see one ARM buildbot[1], and it's just called "ARM v7". I also found this python-dev thread[2] along with a blog.python.org blog post[3] from 2012, which mentioned that Trent Nelson would be receiving a Raspberry Pi and setting up a buildslave on it. But I can't find mention of it on buildbot.python.org. So I can't tell what the current state is. If anyone is interested, just let me know! .. [1]: http://buildbot.python.org/all/builders/ARMv7%203.x .. [2]: http://thread.gmane.org/gmane.comp.python.devel/136388 .. [3]: http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev for MAC OS X
On Fri, Jun 13, 2014 at 12:21 PM, Pedro Helou wrote: > Hey, > > does anybody know how to install the python-dev headers and libraries for > MAC OS X? Hi, This list is for discussing the development *of* Python, not *with* Python. Please ask on the python list, python-l...@python.org (more info here[1]) or on the #python channel on the Freenode IRC server. StackOverflow is also a good place to search for information and ask questions. But while we're on the subject, on OSX I recommend using a binary package manager such as Homebrew[2] or Macports[3] for this. I have had good experiences using Homebrew. Good luck, - Tal Einat .. [1]: https://mail.python.org/mailman/listinfo/python-list .. [2]: http://brew.sh/ .. [3]: http://www.macports.org/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Collecting stories about beginning contribution
Hi everyone, (FYI, I'm cross-posting this from core-mentorship. If you'd like to reply, please do so there.) Following the recent discussion on core-mentorship about beginning contribution, the difficulties it entails and how to improve the situation, I'd like to start a process of improving the situation. As a first step, I'd like to collect as many stories about beginning to contribute to Python. This includes stories about failures to do so; in fact, those would be most useful! I'm intentionally leaving this very open; I'd like to hear anything people have to tell about their experiences, with as little guidance as possible. Specifically, at this point, I'm not (yet) looking for specific suggestions for how to improve the situation. So, following Guido's call (on core-mentorship) to publicly post such stories, please help us collect as many such accounts as possible! Post your own stories, and more importantly, reach out to others who could share their own stories and ask them to do so! Those who feel that posting publicly would require too much work, or just don't feel comfortable doing so, are invited to write to me personally; I'll use the information anonymously if asked to. Regards, - Tal Einat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BPORL4SFXSYXQEBPM7FWXOF7E7BUFW4I/
[Python-Dev] Ideas for improving the contribution experience
(Context: Continuing to prepare for the core dev sprint next week. Since
the sprint is near, *I'd greatly appreciate any quick comments, feedback
and ideas!*)
Following up my collection of past beginning contributor experiences, I've
collected these experiences in a dedicated GitHub repo[1] and written a
(subjective!) summary of main themes that I recognize in the stories, which
I've also included in the repo[2].
A "TL;DR" bullet list of those main themes:
* Slow/no responsiveness
* Long, slow process
* Hard to find where to contribute
* Mentorship helps a lot, but is scarce
* A lot to learn to get started
* It's intimidating
More specifically, something that has come up often is that maintaining
momentum for new contributors is crucial for them to become long-term
contributors. Most often, this comes up in relation to the first two
points: Suggestions or PRs are completely receive no attention at all
("ignored") or stop receiving attention at some point ("lost to the void").
Unfortunately, the probability of this is pretty high for any issue/PR, so
for a new contributor this is almost guaranteed to happen while working on
one of their first few contributions. I've seen this happen many times, and
have found that I have to personally follow promising contributors' work to
ensure that this doesn't happen to them. I've also seen contributors learn
to actively seek out core devs when these situations arise, which is often
a successful tactic, but shouldn't be necessary so often.
Now, this is in large part a result of the fact that us core devs are not a
very large group, made up almost entirely of volunteers working on this in
their spare time. Last I checked, the total amount of paid development time
dedicated to developing Python is less than 3 full-time (i.e. ~100 hours a
week).
The situation being problematic is clear enough that the PSF had concrete
plans to hire paid developers to review issues and PRs. However, those
plans have been put on hold indefinitely, since the PSF's funding has
shrunk dramatically since the COVID-19 outbreak (no PyCon!).
So, what can be done? Besides raising more funds (see a note on this
below), I think we can find ways to reduce how often issues/PRs become
"stalled". Here are some ideas:
1. *Generate reminders for reviewers when an issue or PR becomes "stalled'
due to them.* Personally, I've found that both b.p.o. and GitHub make it
relatively hard to remember to follow up on all of the many issues/PRs
you've taken part in reviewing. It takes considerable attention and
discipline to do so consistently, and reminders like these would have
helped me. Many (many!) times, all it took to get an issue/PR moving
forward (or closed) was a simple "ping?" comment.
2. *Generate reminders for contributors when an issue or PR becomes
"stalled" due to them.* Similar to the above, but I consider these separate.
3. *Advertise something like a "2-for-1" standing offer for reviews.* This
would give contributors an "official", acceptable way to get attention for
their issue/PR, other than "begging" for attention on a mailing list. There
are good ways for new contributors to be of significant help despite being
new to the project, such as checking whether old bugs are still relevant,
searching for duplicate issues, or applying old patches to the current code
and creating a PR. (This would be similar to Martin v. Löwis's 5-for-1
offer in 2012[3], which had little success but lead to some interesting
followup discussion[4]).
4. *Encourage core devs to dedicate some of their time to working through
issues/PRs which are "ignored" or "stalled".* This would require first
generating reliable lists of issues/PRs in such states. This could be in
various forms, such as predefined GitHub/b.p.o. queries, a dedicated
web-page, a periodic message similar to b.p.o.'s "weekly summary" email, or
dedicated tags/labels for issues/PRs. (Perhaps prioritize "stalled" over
"ignored".)
- Tal Einat
[1]: https://github.com/taleinat/python-contribution-feedback
[2]:
https://github.com/taleinat/python-contribution-feedback/blob/master/Takeaways%20-%20October%202020.md
[3]:
https://mail.python.org/archives/list/python-dev@python.org/message/7DLUN4Y7P77BSDW5YRWQQGVB3KVOY2M3/
[4]:
https://mail.python.org/archives/list/python-dev@python.org/thread/N4MMHXXOAL77UJLO264PCTCRJLAIKBC6/#N4MMHXXOAL77UJLO264PCTCRJLAIKBC6
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/AYSE65DUJFMFY5F7GJZSZDD252UWQENE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: os.scandir bug in Windows?
Interesting! Indeed, please create an issue and post a link here.
>From a quick look at the code, I can't see any obvious bugs here, the info
seems to be coming directly from FindNextFileW. This will likely require
some more digging.
On Sun, Oct 18, 2020 at 7:37 AM Gregory P. Smith wrote:
> Could you please file this as an issue on bugs.python.org?
>
> Thanks!
> -Greg
>
>
> On Sat, Oct 17, 2020 at 7:25 PM Rob Cliffe via Python-Dev <
> python-dev@python.org> wrote:
>
>>
>> TLDR: In os.scandir directory entries, atime is always a copy of mtime
>> rather than the actual access time.
>>
>> Demo program: Windows 10, Python 3.8.3:
>>
>> # osscandirtest.py
>> import time, os
>> with open('Test', 'w') as f: f.write('Anything\n') # Write to a file
>> time.sleep(10)
>> with open('Test', 'r') as f: f.readline() # Read the file
>> print(os.stat('Test'))
>> for DirEntry in os.scandir('.'):
>> if DirEntry.name == 'Test':
>> stat = DirEntry.stat()
>> print(f'scandir DirEntry {stat.st_ctime=} {stat.st_mtime=}
>> {stat.st_atime=}')
>>
>> Sample output:
>>
>> os.stat_result(st_mode=33206, st_ino=8162774324687317,
>> st_dev=2230120362, st_nlink=1, st_uid=0,
>> st_gid=0, st_size=10, st_atime=1600631381, st_mtime=1600631371,
>> st_ctime=1600631262)
>> scandir DirEntry stat.st_ctime=1600631262.951019
>> stat.st_mtime=1600631371.7062848 stat.st_atime=1600631371.7062848
>>
>> For os.stat, atime is 10 seconds more than mtime, as would be expected.
>> But for os.scandir, atime is a copy of mtime.
>> ISTM that this is a bug, and in fact recently it stopped me from using
>> os.scandir in a program where I needed the access timestamp. No big
>> deal, but ...
>> If it is a feature for some reason, presumably it should be documented.
>>
>> Best wishes
>> Rob Cliffe
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/RIKQAXZVUAQBLECFMNN2PUOH322B2BYD/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/INJBNXRKOBYFGFJ7CLHNJKVQQKU6X6NM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WAVJFASQWS7RDMZEHI4AHQMJ74COQO7O/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Ideas for improving the contribution experience
On Mon, Oct 19, 2020 at 9:24 PM Brett Cannon wrote: > I think the other way to help is to really lean into automation so > reviewing is even lighterweight than it is now. Now this can be as simple > as to remind people when they need to regenerate a file like 'configure' > via a status check, simply telling people when their PR failed a status > check, or go as far as try to automate PEP 7/8 stuff. > > Or another way to put it is to try and use automation to help make PRs > more self-service so that there's less required from a human being to do. > A huge +1 from me! Besides efficiency, I like that kind of automation because it makes our checking of these things more consistent and official. Another reason is that it allows contributors to be more independent in their work, rather than waiting for someone else to explain what they have to do. I've avoided mentioning code style until now since I remembered it being a bit of a touchy subject a few years ago when I recall it coming up. Personally I think that the benefits of being able to automate styling and style checking far outweigh the negatives that were brought up at the time. Brett, if you'd like to open that can of worms, I'd be willing to help. - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BWW76MVDUDC6MDZKU4HSJ4NFOPR3JY23/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Thu, May 13, 2021 at 4:31 PM Eric V. Smith wrote: > > I do think a python-wide standard for this would be helpful, but I don't > see how to change existing code given backward compatibility constraints. While we're on the subject, these sentinels also don't compare properly using `is` after pickling and unpickling. I think it's worth considering making the sentinels in the stdlib all have good reprs and support pickling+unpickling. What would be the potential backwards-compatibility issues with changing the implementation of these existing sentinel values? - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KKDZ5TW6WXSQDE2YPOU6X5JXEU264HBS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Thu, May 13, 2021 at 7:44 PM Ethan Furman wrote:
>
> Consider me complaining. ;-)
+1
> An actual Sentinel class would be helpful:
>
> >>> class Sentinel:
> ... def __init__(self, repr):
> ... self.repr = repr
> ... def __repr__(self):
> ... return self.repr
> ...
>
> >>> MISSING = Sentinel('MISSING')
> >>> MISSING
> MISSING
>
> >>> implicit = Sentinel('')
> >>> implicit
>
Here is my suggestion (also posted on the related bpo-44123), which is
also simple, ensures a single instance is used, even considering
multi-threading and pickling, and has a better repr:
class Sentinel:
def __new__(cls, *args, **kwargs):
raise TypeError(f'{cls.__qualname__} cannot be instantiated')
class MISSING(Sentinel):
pass
- Tal
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/URFRF634732GRICGLRPGJEJON2BYQZM4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Thu, May 13, 2021 at 8:46 PM Eric V. Smith wrote:
>
>
> On 5/13/2021 1:39 PM, Tal Einat wrote:
> > Here is my suggestion (also posted on the related bpo-44123), which is
> > also simple, ensures a single instance is used, even considering
> > multi-threading and pickling, and has a better repr:
> >
> > class Sentinel:
> > def __new__(cls, *args, **kwargs):
> > raise TypeError(f'{cls.__qualname__} cannot be instantiated')
> >
> > class MISSING(Sentinel):
> > pass
>
> >>> MISSING
>
>
> I think a repr of just "MISSING", or maybe "dataclasses.MISSING" would
> be better.
The repr uses whatever module the class is defined in, so we'd get:
>>> from dataclasses import MISSING
>>> MISSING
We could override that to something even cleaner with a meta-class. For example:
class Sentinel(type):
@classmethod
def __prepare__(cls, name, bases, **kwds):
d = super().__prepare__(name, bases, **kwds)
def __new__(cls_, *args, **kwargs):
raise TypeError(f'{cls_!r} is a sentinel and cannot be
instantiated')
d.update(__new__=__new__)
return d
def __repr__(cls):
return f'{cls.__module__}.{cls.__qualname__}'
Which results in:
>>> from dataclasses import MISSING
>>> MISSING
dataclasses.MISSING
>>> type(MISSING)
>>> MISSING()
Traceback (most recent call last): ...
TypeError: dataclasses.MISSING is a sentinel and cannot be instantiated
- Tal
- Tal
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ECYFQWPBQPRN4ZKDU6WNPPAG3Y5XZ2BD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Fri, May 14, 2021 at 12:45 PM Steve Dower wrote: > > On 14May2021 0622, micro codery wrote: > > > > There was a discussion a while back ( a year or so?? ) on > > Python-ideas that introduced the idea of having more "sentinel-like" > > singletons in Python -- right now, we only have None. > > > > Not quite true, we also have Ellipsis, which already has a nice repr > > that both reads easily and still follows the convention of eval(repr(x)) > > == x. It also is already safe from instantiation, survives pickle > > round-trip and is multi-thread safe. > > So long as you are not dealing with scientific projects, it seems a > > quick (if dirty) solution to having a sentinel that is not None. > > I don't think using "..." to indicate "some currently unknown or > unspecified value" is dirty at all, it seems perfectly consistent with > how we use it in English (and indexing in scientific projects, for that > matter, where it tends to imply "figure out the rest for me"). > > All that's really missing is some kind of endorsement (from python-dev, > presumably in the docs) that it's okay to use it as a default parameter > value. I can't think of any reason you'd need to accept Ellipsis as a > *specified* value that wouldn't also apply to any other kind of shared > sentinel. I'll try to organize my thoughts a bit here. This is a bit long, welcome to skip to the final sentence for the "tl;dr". Features one may want for a sentinel: 1. Unique from other objects 2. Globally unique, i.e. unique from other such sentinels (no consensus here) 3. Clear repr (the original subject of this thread) - significant since these often appear in function signatures 4. Survives pickling round-trip (I brought this up since I was bitten by this once, but others have mentioned that this is usually irrelevant) 5. Can be given a clear type signature (this was brought up on twitter[1]) - significant since without this nobody can add full type signatures even if they want to The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is what I've been using for years, and I now think that it isn't good enough. This not having a nice repr is what started this thread. I'd also personally prefer something simple, ideally without a new class or module. There are several simple idioms using existing features that seem like good options, so let's review those: 1. Ellipsis, a.k.a. `...`. This has all of the features outlined above except #2. My main issue with using Ellipsis for this is that it could be surprising and confusing for devs first encountering such use, and could be relatively awkward to figure out. 2. An instance of a one-off class. dataclasses.MISSING is an example of this. It is defined thus: class _MISSING: pass MISSING = _MISSING() Besides failing #4 (surviving pickle round-trips), its repr isn't great: . That is easily overcome by implementing __repr__. 3. A one-off class: class MISSING: pass This has all of the above features except #5: having a clear type signature (since its type is type). Using a class as a value this way could be surprising, though. It's repr also isn't great: . 4. A value of an single-valued enum, for example (from [1]): class _UNSET(enum.Enum): token = enum.auto() This has all of the features above and is simple, just requiring a comment to explain what it is. It's repr is a bit awkward though: >>> repr(_UNSET.token) '<_UNSET.token: 1>' All of these are in use by some developers, though not necessarily in the stdlib. None is perfect, though all are probably good enough. Since pickling is likely not relevant in most cases, I'm currently in favor of #2 making sure to implement a nice __repr__. - Tal [1] https://twitter.com/nolar/status/1392962447166877697 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BYLTDD72RZUUKVRJL6TTSWF35JD3FL47/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
I've created a poll on this subject: https://discuss.python.org/t/sentinel-values-in-the-stdlib/8810 On Fri, May 14, 2021 at 10:33 PM Tal Einat wrote: > > On Fri, May 14, 2021 at 12:45 PM Steve Dower wrote: > > > > On 14May2021 0622, micro codery wrote: > > > > > > There was a discussion a while back ( a year or so?? ) on > > > Python-ideas that introduced the idea of having more "sentinel-like" > > > singletons in Python -- right now, we only have None. > > > > > > Not quite true, we also have Ellipsis, which already has a nice repr > > > that both reads easily and still follows the convention of eval(repr(x)) > > > == x. It also is already safe from instantiation, survives pickle > > > round-trip and is multi-thread safe. > > > So long as you are not dealing with scientific projects, it seems a > > > quick (if dirty) solution to having a sentinel that is not None. > > > > I don't think using "..." to indicate "some currently unknown or > > unspecified value" is dirty at all, it seems perfectly consistent with > > how we use it in English (and indexing in scientific projects, for that > > matter, where it tends to imply "figure out the rest for me"). > > > > All that's really missing is some kind of endorsement (from python-dev, > > presumably in the docs) that it's okay to use it as a default parameter > > value. I can't think of any reason you'd need to accept Ellipsis as a > > *specified* value that wouldn't also apply to any other kind of shared > > sentinel. > > I'll try to organize my thoughts a bit here. This is a bit long, > welcome to skip to the final sentence for the "tl;dr". > > Features one may want for a sentinel: > 1. Unique from other objects > 2. Globally unique, i.e. unique from other such sentinels (no consensus here) > 3. Clear repr (the original subject of this thread) - significant > since these often appear in function signatures > 4. Survives pickling round-trip (I brought this up since I was bitten > by this once, but others have mentioned that this is usually > irrelevant) > 5. Can be given a clear type signature (this was brought up on > twitter[1]) - significant since without this nobody can add full type > signatures even if they want to > > The common `SENTINEL = object()` idiom fails #3, #4 and #5. This is > what I've been using for years, and I now think that it isn't good > enough. This not having a nice repr is what started this thread. > > I'd also personally prefer something simple, ideally without a new > class or module. > > There are several simple idioms using existing features that seem like > good options, so let's review those: > > 1. Ellipsis, a.k.a. `...`. This has all of the features outlined above > except #2. My main issue with using Ellipsis for this is that it could > be surprising and confusing for devs first encountering such use, and > could be relatively awkward to figure out. > > 2. An instance of a one-off class. dataclasses.MISSING is an example > of this. It is defined thus: > > class _MISSING: > pass > MISSING = _MISSING() > > Besides failing #4 (surviving pickle round-trips), its repr isn't > great: . That is easily > overcome by implementing __repr__. > > 3. A one-off class: > > class MISSING: pass > > This has all of the above features except #5: having a clear type > signature (since its type is type). Using a class as a value this way > could be surprising, though. It's repr also isn't great: 'dataclasses._MISSING'>. > > 4. A value of an single-valued enum, for example (from [1]): > > class _UNSET(enum.Enum): > token = enum.auto() > > This has all of the features above and is simple, just requiring a > comment to explain what it is. It's repr is a bit awkward though: > > >>> repr(_UNSET.token) > '<_UNSET.token: 1>' > > > All of these are in use by some developers, though not necessarily in > the stdlib. None is perfect, though all are probably good enough. > Since pickling is likely not relevant in most cases, I'm currently in > favor of #2 making sure to implement a nice __repr__. > > - Tal > > [1] https://twitter.com/nolar/status/1392962447166877697 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/77ZBKCJQTG2OFY2WUL33OSJ6H3J57AEP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Sat, May 15, 2021 at 2:09 AM David Mertz wrote: > > I think it's more future-looking to allow pickle round-tripping. I tend to agree. > Just add a ._uuid attribute and have object equality follow equality of that > attribute. There's no reason to expose that in the .__repr__, but it would be > inspectable in concept. I think it's worth preserving the idiom of comparing sentinels using `is`, as we do for `None` and other existing sentinel values. It's relatively easy to do, such as by using a single-value Enum or by using a class with a custom __new__. - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XNYLOHY46BWLRXVLPL5RNTLBE6JG5OEX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Thu, May 20, 2021 at 10:37 PM David Mertz wrote:
>
> The scenario I'm thinking about is like this:
>
> (base) 84-tmp % python
> Python 3.9.1 (default, Dec 11 2020, 14:32:07)
> [GCC 7.3.0] :: Anaconda, Inc. on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pickle
> >>> cheap_sentinel = object()
> >>> id(cheap_sentinel)
> 140469343429632
> >>> pickle.dump(cheap_sentinel, open('sentinel.pkl', 'wb'))
>
> (base) 85-tmp % python
> Python 3.9.1 (default, Dec 11 2020, 14:32:07)
> [GCC 7.3.0] :: Anaconda, Inc. on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pickle
> >>> cheap_sentinel = object()
> >>> id(cheap_sentinel)
> 139852505814016
> >>> id(pickle.load(open('sentinel.pkl', 'rb')))
> 139852505813968
>
> It would be pleasant if there were a way to make "cheap_sentinel" be the same
> thing—either by equality or by identity—betweeen those two runs of the
> interpreter.
>
> None or Ellipsis have that property, of course. So do, for example,
> integers, at least by equality if not identity (yes, of course, we might get
> identity by interning, but it's not guaranteed).
There are several ways of achieving this for other sentinel values,
some of which have been mentioned earlier in this thread. Some
examples are:
1. a value from a single-valued enum
2. a class object (not an instance)
3. a singleton class with a carefully implemented __new__ which always
returns the same instance
- Tal Einat
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RJXU7F6LYVJ4C4N4EPVA3A5F3QRGK253/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Fri, May 21, 2021 at 5:33 PM Luciano Ramalho wrote: > > For the hard cases, I will read the upcoming 46-page "PEP 973: > Parameterized Sentinel Factory Factory API" ;-) I put up an early draft of a PEP on a branch in the PEPs repo: https://github.com/python/peps/blob/sentinels/pep-.rst (Note: This link will break once the temporary branch is deleted.) I wrote it to summarize the discussions, organize my thoughts and explore the options. I stopped working on it late at night and sent a link to a few people to get some opinions. I didn’t intend to make it public yet, but it was noticed and replied to on the discuss.python.org thread where I put up the poll [1], so the cat is out of the proverbial bag now… Luciano, your wish is granted! ;) - Tal Einat [1] https://discuss.python.org/t/sentinel-values-in-the-stdlib/8810/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U3N7XG5WJASMGKLIBXIE4SS6TSWLQQU2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Mon, May 24, 2021 at 3:30 AM Luciano Ramalho wrote:
>
> On Sun, May 23, 2021 at 3:37 AM Tal Einat wrote:
> > I put up an early draft of a PEP on a branch in the PEPs repo:
> > https://github.com/python/peps/blob/sentinels/pep-.rst
>
> Thanks for that PEP, Tal. Good ideas and recap there.
>
> I think repr= should have a default: the name of the class within <>:
> .
>
> Sentinels don't have state or any other data besides a name, so I
> would prefer not to force users to create a class just so they can
> instantiate it.
>
> Why not just this?
>
> NotGiven = sentinel('')
I'm seriously considering that now. The issues I ran into with this
approach are perhaps not actually problematic.
> On the other hand, if the user must create a class, the class itself
> should be the sentinel. Class objects are already singletons, so that
> makes sense.
>
> Here is a possible class-based API:
>
> class NotGiven(Sentinel):
> pass
>
> That's it. Now I can use NotGiven as the sentinel, and its default
> repr is .
>
> Behind the scenes we can have a SentinelMeta metaclass with all the
> magic that could be required--including the default __repr__ method.
>
> What do you think?
One issue with that is that such sentinels don't have their own class,
so you can't write a strict type signature, such as `Union[str,
NotGivenType]`.
Another issue is that having these objects be classes, rather than
normal instances of classes, could be surprising and confusing.
For those two reasons, for now, I think generating a unique object
with its own unique class is preferable.
> Sorry about my detour into the rejected idea of a factory function.
Please don't apologize! I put those ideas in the "Rejected Ideas"
section mostly to have them written down with a summary of the
considerations related to them. They shouldn't be considered finally
rejected unless and until the PEP is finished and accepted.
- Tal
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/HL74JC3OF7Y3F5RDYVACAFODL4E3CBI6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Mon, May 24, 2021 at 4:10 AM MRAB wrote: > > On 2021-05-24 01:37, Luciano Ramalho wrote: > > Now I can use NotGiven as the sentinel, and its default repr is . > > > The repr of other singletons are the names of those singletons, eg. > "None", so why "" instead of "NotGiven"? Yea, that's up in the air. The common suggestions are either "NotGiven", "" or "mymodule.NotGiven". The first makes sense for builtins like None and Ellipses, but I'm not sure a function signature like foo(bar=NotGiven) is very clear. With the factory function pattern there's no need for a default, so this may become a non-issue, and I may remove the recommendation for which form to use. - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WMS3CLQ765HAN3WCQKCL2XSSJUNP45LY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Mon, May 24, 2021 at 6:04 AM Christopher Barker wrote: > > 1) “Add a single new sentinel value, e.g. MISSING or Sentinel” (under > rejected) > > I was one of the proponent of that -- but not as an alternative to having a > stadardars way to create unique sentinels, but as an addition. That's kind of > orthogonal to the PEP, but it would still be nice to have it at the same time. > > Why? There was a fair bit of discussion as to why you would not want to > require everyone to use MISSING (dataclasses, in particular), but I still > think better for the readability of everyone's code for the common case(s?) > to use the same singleton, if they can. The way I see it, there are several clear motivations to implement one of these and make that the recommended way of defining sentinels. The further benefit of having both is less clear to me. Also, there's this in the Zen of Python: "There should be one-- and preferably only one --obvious way to do it." This strengthens my feeling that having two recommended ways of defining sentinel values, in addition to the existing None, would be undesirable. > 2) couldn't a factory function simply return a sentinel subclass? Maybe I'm > missing something, but I can't see why that would require stack frame > inspection. It seems better for each sentinel to have its own class, which makes it possible to write strict type signatures and allows better static code analysis. It also makes handling copying and unpickling simple. > But frankly Luciano's idea of a base class that can be subclassed seems the > most startightford to me. Yes, and it's what I originally suggested near the beginning of this thread :) - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WP5HKBQGW255SEV3O5FULRKEHJOT2CM6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
Following the continued discussion, I'm currently in favor of a simple
interface using a factory function, i.e. NotGiven = sentinel('NotGiven').
I've created a new GitHub repo with a reference implementation. It also
includes a second version of the draft PEP, addresses some of the
additional points brought up in the latest parts of this discussion.
https://github.com/taleinat/python-stdlib-sentinels
- Tal
On Mon, May 24, 2021 at 5:28 PM Tal Einat wrote:
> On Mon, May 24, 2021 at 3:30 AM Luciano Ramalho
> wrote:
> >
> > On Sun, May 23, 2021 at 3:37 AM Tal Einat wrote:
> > > I put up an early draft of a PEP on a branch in the PEPs repo:
> > > https://github.com/python/peps/blob/sentinels/pep-.rst
> >
> > Thanks for that PEP, Tal. Good ideas and recap there.
> >
> > I think repr= should have a default: the name of the class within <>:
> > .
> >
> > Sentinels don't have state or any other data besides a name, so I
> > would prefer not to force users to create a class just so they can
> > instantiate it.
> >
> > Why not just this?
> >
> > NotGiven = sentinel('')
>
> I'm seriously considering that now. The issues I ran into with this
> approach are perhaps not actually problematic.
>
> > On the other hand, if the user must create a class, the class itself
> > should be the sentinel. Class objects are already singletons, so that
> > makes sense.
> >
> > Here is a possible class-based API:
> >
> > class NotGiven(Sentinel):
> > pass
> >
> > That's it. Now I can use NotGiven as the sentinel, and its default
> > repr is .
> >
> > Behind the scenes we can have a SentinelMeta metaclass with all the
> > magic that could be required--including the default __repr__ method.
> >
> > What do you think?
>
> One issue with that is that such sentinels don't have their own class,
> so you can't write a strict type signature, such as `Union[str,
> NotGivenType]`.
>
> Another issue is that having these objects be classes, rather than
> normal instances of classes, could be surprising and confusing.
>
> For those two reasons, for now, I think generating a unique object
> with its own unique class is preferable.
>
> > Sorry about my detour into the rejected idea of a factory function.
>
> Please don't apologize! I put those ideas in the "Rejected Ideas"
> section mostly to have them written down with a summary of the
> considerations related to them. They shouldn't be considered finally
> rejected unless and until the PEP is finished and accepted.
>
> - Tal
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WVUIDCPLQULT4THEQ3CXNARZIUSF4C2U/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
Thanks for this, Luciano! My main issue with using class objects is that such use of them would be unusual and potentially confusing. I think that is important in general, and doubly so for something I suggest adding to the stdlib. Additionally, I very much would like for each sentinel object to have its own dedicated class, to allow writing strict function type signatures. Once one adds that to a meta-class or class decorator, the complexity of the implementation approaches what I currently have for a sentinel() function. At that point, I can't see a clear advantage for such an approach. - Tal On Mon, May 24, 2021 at 7:31 PM Luciano Ramalho wrote: > On Mon, May 24, 2021 at 11:44 AM Tal Einat wrote: > > > But frankly Luciano's idea of a base class that can be subclassed > seems the most startightford to me. > > > > Yes, and it's what I originally suggested near the beginning of this > thread :) > > I am sorry to have missed your previous e-mail with a base class for > sentinels, @Tal. I support that idea. > > In fact, if we have a SentinelMeta metaclass, and a Sentinel base > class built from SentinelMeta, the Sentinel class can be used directly > as a sentinel without the need for subclassing—if the application does > not require a custom sentinel. If it does, then the user can subclass > Sentinel. > > The SentinelMeta could be private, to discourage misuse. > > This is my implementation, after learning from @Tal's code: > > > https://github.com/fluentpython/example-code-2e/blob/master/25-class-metaprog/sentinel/sentinel.py > > Since having a Sentinel base class is desirable for ease of use, I > think it is simpler to code the __new__ method in it, instead of > coding metaclass logic to inject __new__ in the class namespace. > > Best, > > Luciano > > > > -- > Luciano Ramalho > | Author of Fluent Python (O'Reilly, 2015) > | http://shop.oreilly.com/product/0636920032519.do > | Technical Principal at ThoughtWorks > | Twitter: @ramalhoorg > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HGG43Y5IM5HVCEERA3ZFM6II6W2G6Y5H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Tue, May 25, 2021 at 11:25 AM Pascal Chambon wrote:
>
> Hello, and thanks for the PEP,
>
> I feel like the 3-lines declaration of a new sentinel would discourage a
> bit its adoption compared to just "sentinel = object()"
I now tend to agree. The new version of the draft PEP proposes a
simpler interface: NotGiven = sentinel('NotGiven')
> From what I understand from the PEP, if new classes are defined inside
> the closure of a factory function, some Python implementations would
> have trouble copying/pickling them?
The reference implementations I propose take care of this. I'll make
sure that everything works in popular alternate implementations such
as PyPy.
> Would it be doable to have a single Sentinel class, whose instances
> store their representation and some autogenerated UUID, and which
> automatically return internally stored singletons (depending on this
> UUID) when called multiple times or unpickled ?
> This would require some __new__() and unpickling magic, but nothing too
> CPython-specific (or am I missing something?).
That's certainly doable, and I believe that there are existing
implementations of sentinels that use this method. But since classes
are singletons, and it's simple to make a class that always returns
the same object, there's no need for setting a UUID and implementing
custom pickling logic as you suggest.
Another drawback of this approach is that each sentinel value wouldn't
have its own dedicated type.
- Tal
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/SPIN5YYO2R6SU4FTKW2IEQY23KBTGYHR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Tue, May 25, 2021 at 10:09 PM Eric Nieuwland
wrote:
>
>
> To add to the suggestions already given in this thread I dug into code I
> wrote some time ago. Offered as an inspiration.
>
> === missing.py ===
>
> from typing import Any
>
> def MISSING(klass: Any) -> Any: """ create a sentinel to indicate a missing
> instance of a class :param klass: the class of which an instance is missing
> :return: missing class object """ g = globals() missing_klass_name =
> f"_MISSING_{klass.__module__}_{klass.__name__}_MISSING_" if
> missing_klass_name not in g: g[missing_klass_name] = type(
> missing_klass_name, (klass,), { "__repr__": lambda x:
> f"MISSING({klass.__name__})", } ) return g[missing_klass_name]()
>
> ===
>
> and as a demo:
>
> === demo_missing.py ===
>
> import pickle
>
> from missing import MISSING
>
> x = MISSING(str) y = "bar" print(f"{x!r} == {y!r}: {x == y}") print(f"{x!r}
> is {y!r}: {x is y}") # MISSING(str) == 'bar': False # MISSING(str) is 'bar':
> False
>
> with open("object.pickled", "wb") as f: pickle.dump(x, f) with
> open("object.pickled", "rb") as f: y = pickle.load(f) print(f"{x!r} == {y!r}:
> {x == y}") print(f"{x!r} is {y!r}: {x is y}") # MISSING(str) == MISSING(str):
> True # MISSING(str) is MISSING(str): False
>
> def foo(a: int = MISSING(int), b: int = MISSING(int)): print(f"{a=}
> {isinstance(a, int)}") print(f"{b=} {isinstance(b, int)}") print(f"{a!r} ==
> {b!r}: {a == b}") print(f"{a!r} is {b!r}: {a is b}")
>
> foo() # a=MISSING(int) True # b=MISSING(int) True # MISSING(int) ==
> MISSING(int): True # MISSING(int) is MISSING(int): False
>
> foo(1) # a=1 True # b=MISSING(int) True # 1 == MISSING(int): False # 1 is
> MISSING(int): False
>
> class Test: ...
>
> t = MISSING(Test) print(f"{t=}") # t=MISSING(Test)
>
> ===
Wow, that's... terribly clever. Thanks for sharing this!
- Tal
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/AEUHYDXJF3PVGGZ5WET5AMLKNO3STQJP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 661: Sentinel Values
Hi, I have prepared a PEP proposing adding a stdlib function for defining sentinel values. You can find the PEP here: https://www.python.org/dev/peps/pep-0661/ The discussion is happening in the discourse server: https://discuss.python.org/t/pep-661-sentinel-values/9126 To avoid splitting the discussion, *please redirect your comments there* instead of replying to this thread. Have a nice week, - Tal Einat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3QNLVLSMVSQ5MGLXRIQ5QM4BA5OJCVEN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?
I have a spare RPi zero that I could try to set up as a buildbot. Would that be useful? On Tue, Jan 4, 2022 at 10:59 AM Antoine Pitrou wrote: > On Mon, 3 Jan 2022 22:40:25 -0800 > "Gregory P. Smith" wrote: > > > > rerunning a mere few of those in --rigorous mode for more runs does not > > significantly improve the stddev so I'm not going to let that finish. > > The one benchmark that is bigint-heavy is pidigits AFAIK, so you might > want to re-run that one if you want a more rigorous confirmation that > there is no regression. > > > my recommendation: proceed with removing 15-bit bignum digit support. > > 30-bit only future with simpler better code here we come. > > Sounds reasonable to me as well. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/MRE5HF3XRKJBEHF3YJNGXWXECLX7GQGG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FPYXF33EKE23AUYPALAOKDLGKE7LGUGX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Inline links in Misc/NEWS entries
I suggest slightly expanding the part about NEWS formatting in the dev guide, and specifically have the example include appropriate uses of roles, and a link to the list of available roles. https://devguide.python.org/committing/#what-s-new-and-news-entries On Thu, Aug 15, 2019 at 3:39 AM Kyle Stanley wrote: > > Also, for IDLE, news entries to idlelib/NEWS.txt > > where markup, as opposed to unicode, is noise. > > Interesting, I actually wasn't aware of the distinction for idlelib/NEWS. > I can imagine that Sphinx constructs such as :func:, :meth:, and :class: > would not be nearly as useful there. However, I can imagine reST being > occasionally useful. > > Based on a recent feature that was added to the IDLE, I could imagine > explicit inline reST links being somewhat useful for something like this: > > Add support for displaying line numbers. See `IDLE Options menu < > https://docs.python.org/3/library/idle.html#options-menu-shell-and-editor > >`_. > > The inline link would appear to readers as "IDLE Options menu" and allow > them to click on it to navigate to the corresponding documentation for more > information on the feature. > > > Bottom line: I would rather a knowledgeable editor prettify the blurbs > > in a consistent manner after I am done with them. To me, this is a > > place where specializations pays. > > I completely agree. I was mainly addressing situations where PR authors > were rejecting or disregarding suggestions to add the markup in the news > entry from those who are knowledgeable of the Sphinx constructs/roles. It > wouldn't be reasonable to expect all PR authors to be able to properly > utilize every supported markup feature. > > This is a rare occurrence, but I've had it happen a couple of times > recently. Based on the responses so far, it likely occurred due to some > developers not being aware that Misc/NEWS supported Sphinx roles and some > of the basic features of reST. That's completely understandable if it's a > newer feature. > > Hopefully this discussion and any potential updates to the devguide will > improve awareness of the feature, and provide instructions on when it's > appropriate to utilize. > > Thanks, > Kyle Stanley > > On Wed, Aug 14, 2019 at 3:31 AM Terry Reedy wrote: > >> On 8/13/2019 6:31 PM, Kyle Stanley wrote: >> >> > The primary purpose of me creating this topic was because there seems >> to >> > be some sentiment that it's perfectly fine to exclusively use plaintext >> > in the news entries. Especially in cases where authors have rejected >> > suggestions to adding the Sphinx markup in their PRs. There seems to be >> > some sentiment that it's perfectly fine to exclusively use plaintext in >> > every news entry. Personally, I think it's a bit more nuanced, and that >> > the links can sometimes be very helpful for readers. >> >> Beyond what Ned said, (news markup is relatively new), people may be >> uncertain what is allowed and when appropriate. Also, there is some >> situation for me where markup seems to be a nuisance and looks like it >> is introducing an error. So I have changed unicode quotes and removed >> some rst markup. Also, for IDLE, news entries to idlelib/NEWS.txt. >> where markup, as opposed to unicode, is noise. >> >> Bottom line: I would rather a knowledgeable editor prettify the blurbs >> in a consistent manner after I am done with them. To me, this is a >> place where specializations pays. >> >> -- >> Terry Jan Reedy >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/53QDMBQHW2S6F7JI4YSGAYYKJOVOIFQF/ >> > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/K5TXWQ7ARKDV73MNEIED35PZDAL6T2L2/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DZSQL4MYVHFQENLGQK2QLNNZKSYF33CJ/
[Python-Dev] Re: The Python 2 death march
On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder wrote: > > I'm not looking forward to answering questions from the public about why > the PSF is writing dire and specific warnings like "We have decided that > January 1, 2020, will be the day that we sunset Python 2," while the > core devs are planning a release four months after that. It won't help > Python's credibility, and may convince some people that they don't have > to take the date seriously.. To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no longer receive fixes for any *new* bugs or security issues, nor other improvements. I would expect that be the time of the code freeze for the first release candidate, not the time of the final release. While we will still fix issues *introduced in 2.7.18 since 2.7.17* before the final 2.7.18 release, we won't address any other bugs or security issues and won't backport anything *new* from 3.x. (I may have some details not exactly correct here, but I hope the gist is correct.) I'm sure the wording could be improved, but generally this seems entirely reasonable to me. - Tal Einat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KSU2A5SDGDHCLPKA7BSW2PH5OIZVUOCB/
[Python-Dev] Re: Feature Request: Python Pipes: Incluye sspipe module
Hi Jaun,
With installing 3rd party libraries being very easy thanks to pip, PyPI,
wheels etc., the bar for inclusion in the stdlib is higher than it was
before: being generally useful is usually not enough. Mostly, there needs
to be a specific reason why a library *needs* to be in the stdlib rather
than simply up on PyPI.
For example, some stdlib libraries were added mainly so that they could be
used in the rest of the stdlib: unittest.mock and dataclasses come to mind
as examples.
IMO, it would be very unlikely that the devs would be convinced to add it
to the stdlib.
P.S. Posting to Python-Dev, Python-Ideas and creating an issue is excessive
and splits conversation, making it difficult to follow. In the future, such
proposals should begin by being posted only in Python-Ideas, please.
- Tal
On Sat, Sep 14, 2019 at 12:28 AM Juan Telleria wrote:
> Could sspipe module be included as part of Python's Standard Library?
> https://sspipe.github.io/
> https://github.com/sspipe/sspipe
> https://pypi.org/project/sspipe/
>
> sspipe allows to use syntax such as:
>
> from sspipe import p, px
> import numpy as np
> import pandas as pd
>
> (
> np.linspace(0, pi, 100)
> | p({'x': px, 'y': np.sin(px)})
> | p(pd.DataFrame)
> | px[px.x > px.y].head()
> | p(print, "Example 6: pandas and numpy support:\n", px)
> )
>
> The issue in Python's Bug Tracker is:
>
> https://bugs.python.org/issue38052
>
> Any Core Python Developer willing to support this PEP?
>
> Thank you,
>
> Juan Telleria
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/2MUGDTKV5CFRXZ5LKLIBW5XB7Y3QZV6A/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/DRSF6T3B3I4QWXBB4576VTUGCQRB7X6F/
[Python-Dev] Re: 4 first-time contributions that need core review.
I'm happy to do so in a couple of days when I'm back from vacation, though I imagine someone else will pick these up by then. On Tue, Oct 22, 2019, 21:54 Brandt Bucher wrote: > Hi all. There are a few *very simple* PRs from first-time contributors > that have been sitting un-core-reviewed for several weeks. > > https://github.com/python/cpython/pull/16680: bpo-38419: fix > "check-c-globals" path > https://github.com/python/cpython/pull/16678: bpo-38421: Update > email.utils documentation > https://github.com/python/cpython/pull/16557: bpo-38361: syslog: fixed > making default "ident" from sys.argv[0] > https://github.com/python/cpython/pull/16438: bpo-38293: Allow shallow > and deep copying of property objects > > I've reviewed them and they look good. If somebody has a small bit of time > to look at these, I'm sure the authors would appreciate it! > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/BT5QELS56DHDXUPQVU6NFBFXB3EAXHJ2/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7TH5PAIZYUZ2K35BGAYYN5DHLHMZJN7Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: EnHackathon 2019 - seeking core dev support
Hi Lewis, As I mentioned in our earlier conversation, I'd be happy to help! I'm in the UTC+2 timezone so hopefully I should be available for live support for most of your working hours. I suggest setting up a dedicated channel for online communication, e.g. an IRC channel or Zulip stream (with Zulip I'll also be available via my phone.) Please update ASAP regarding the exact dates so I can let you know when I'll be available and try to increase my availability during that period. I am unfortunately barely familiar with most of the interest areas you've mentioned, with unittest being the exception. I'll still be able to assist, but perhaps not as well as an expert on these would be. I suggest contacting the experts on the relevant library modules directly regarding this, mostly to ask what they think would be most helpful and whether they have any preferences or requests, but also regarding their availability to help before, during and after. - Tal Einat P.S. Apologies for the delayed reply, I'm working back through my email backlog after a vacation. On Sun, Oct 20, 2019 at 3:04 PM Lewis Gaul wrote: > Hi all, > > In early November this year I'll be leading the first ever Python > 'EnHackathon' at the Ensoft Cisco office - we anticipate having ~10 > first-time contributors, all with experience writing C and/or Python (and > training in both). We each have up to 5 days (per year) to contribute, with > my intention being to focus on contributing to CPython. We will be blogging > about our experience (probably using GitHub pages) - I'll send out the URL > when it's been set up. > > Having spoken to people about this at PyCon UK this year and emailed on > the core-mentorship mailing list, I'm posting here looking for any core > devs who would be happy to provide us with some guidance. I'm wary of PR > reviews being a blocker, and not wanting my co-contributors to feel > disheartened by issues they're working on not reaching a resolution. > > We're open to working on almost any area of CPython, although particular > areas of interest/familiarity might be: CPython core, re, unittest, > subprocess, asyncio, ctypes, typing. There would be scope for us to work in > small teams to work on more substantial issues if that is seen as a useful > way to contribute, otherwise we can start with some of the easier issues on > bpo. > > Would anyone here be willing to offer some support to help us reach our > full potential? Please don't hesitate to contact me if you're interested in > any way, or if you have any advice. > > If this year is a success there's a high probability we would look to do a > similar thing in future years (with the experience from this year already > in the bag)! > > Thanks, > Lewis > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZXCN2ISIS2QKUTGF3JODVPRWIS2Z773H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
On Wed, Oct 30, 2019, 09:43 Steve Holden wrote: > Since 3.7 it may be that dataclasses offer a cleaner implementation of the > functionality you suggest. > Actually, IMO in this case it would be more useful and fitting to use namedtuples rather than dataclasses, since CSV rows are naturally tuple-like, and it would be compatible with existing code written for the tuple-based interface. > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FTY5I2IEMYLM7PVZ6TPXFJKM6CLLN2I4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: EnHackathon 2019 - seeking core dev support
On Thu, Oct 31, 2019 at 3:30 PM Lewis Gaul wrote: > I'm happy to set up an EnHackathon channel - is IRC or Zulip preferred in > general? > I prefer Zulip since I can easily participate using my phone, as well as receive email notifications. It also makes searching and following previous discussion trivial, unlike with IRC. It would be reasonable to simply use the existing core/help Zulip stream for this purpose. - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GGXK2CSOJNXL2YAHXJBCANPJH33GXKOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Do not fallback to __trunc__ when convert to int
On Sat, Nov 2, 2019 at 1:54 PM Nick Coghlan wrote: > > > On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, wrote: > >> It seems a good idea to add __int__ to Fraction, but if you stop falling >> back to __trunc__, won't that cause backwards compatibility issues? I'd say >> looking for __trunc__ if the alternative is failing isn't so bad. >> > > Aye, converting a case where code is slower than it needs to be to an > outright failure isn't a good trade-off. > I find int() falling back to __trunc__() surprising, actually. Removing it will break backwards-compatibility, but implementing __int__() is an easy fix. Perhaps we could run a code search for classes implementing __trunc__ but not __int__? Speeding up int(str), as well as slightly simplifying the language, are rather good arguments in favor of this. - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NPUG2SJKNPCX6ECCVJY3W2RC4PXF6MLP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Following up stories about beginning contribution
Hello everyone, Following up my request for such stories in early August[1], I have received 10 such stories which may be shared publicly, and several more in private. As a first step, I've create a repository[2] with all of the publicly available stories, so that they are easily accessible and readable from a single location. I have made sure to collected written consent from all authors to use these stories publicly. Hence, everything there is published under the CC 4.0 license, with attribution to the original author and a link to the original post/message/tweet. *If any author is uncomfortable with these publication terms, please let me know ASAP!* My next step will be to read through the stories again recognize common and obviously critical problems or patterns. I'll publish those findings and plan to follow up with a structured survey in hope of collecting information and opinions specific to those issues from a larger number of people. Then, hopefully, we'll have a solid foundation for making improvements. .. [1]: https://mail.python.org/archives/list/core-mentors...@python.org/message/JSTTXJRLS2A6W5NCBDOHNW7RSRKVIL2F/ .. [2]: https://github.com/taleinat/python-contribution-feedback ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HYHVSPZTLCDMHWVA2P6T3ITVEQHPZQFR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Requesting PR review on locale module
Hi Cédric, Thanks for writing and sorry that you've experienced such a delay. Such occurrences are unfortunately rather common right now, though we're working on improving the situation. Stéphane Wirtel self-assigned that PR to himself a couple of months ago, but indeed hasn't followed it up after his requested changes were apparently addressed, despite a couple of "pings". The experts index[1] lists Marc-Andre Lemburg as the expert for the locale module, so perhaps he'd be interested in taking a look. I've CC-ed both Stéphane and Marc-Andre. [1] https://devguide.python.org/experts/ On Sun, Nov 17, 2019 at 2:06 PM Cédric Krier via Python-Dev < python-dev@python.org> wrote: > Hi, > > Few months ago, I submitted a PR [1] for the bpo [2] about locale.format > casting Decimal into float. Has someone some times to finish the review? > This change is blocking a bugfix on Tryton [3]. > > > [1] https://github.com/python/cpython/pull/15275 > [2] https://bugs.python.org/issue34311 > [3] https://bugs.tryton.org/issue8574 > > > Thanks, > -- > Cédric Krier - B2CK SPRL > Email/Jabber: cedric.kr...@b2ck.com > Tel: +32 472 54 46 59 > Website: http://www.b2ck.com/ > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/UOGIZADIK3EOLGPDDA2C525R63DULSDG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YY7SA2DASW5IUWIFF5RZ73IVU4UKOZHY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: thes mapping data type and thescfg cfg file module - review and suggestion request
Hi Dave, Thesaurus looks interesting and it is obvious that you've put a lot of effort into it! This list is for the discussion of the development *of* Python itself, however, rather than development *with* Python, so it's not an appropriate place for such posts. I suggest you post this on python-list and/or python-announce, to get this in front of a wider audience. - Tal Einat On Mon, Nov 18, 2019 at 7:17 AM Dave Cinege wrote: > If you are not aware: > > - Thesaurus is a mapping data type with recursive keypath map > and attribute aliasing. It is a subclass of dict() and is mostly > compatible as a general use dictionary replacement. > > - ThesaurusExtended is a subclass of Thesaurus providing additional > usability methods such as recursive key and value searching. > > - ThesaurusCfg is a subclass of ThesaurusExtended providing a nested > key configuration file parser and per key data coercion methods. > > The README.rsl will give a better idea: > https://git.cinege.com/thesaurus/ > > > After 7 years I might have reached the point of 'interesting' with > my Thesaurus and ThesaurusCfg modules. > > To anyone that is overly bored, I'd appreciate your terse review and > comments on how mundane and worthless they still actually are. :-) > > I'm primarily interested in suggestions to what I've done conceptually > here. While I'm not completely ashamed of the state of the Thesaurus > code, ThesaurusCfg is not far beyond the original few hours I slapped it > together one day in frustration. > > After considering suggestions I intend to make changes towards a formal > release. > > Thanks in advance, > > Dave > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/CTXKJUTTJKOS47T6XI2O6WU7EYVEQQ3N/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HZSR7QHEHW45H4K4KA3V3U6V4AN3NEV2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: thes mapping data type and thescfg cfg file module - review and suggestion request
On Mon, Nov 18, 2019 at 5:30 PM Dave Cinege wrote: > Hello Tal, > > Yes I understand that. I posted this here because it's been suggested by > those less in the know that Thesaurus and ThesaurusCfg (or some of the > the concepts contained in them) might have a place in the future mainline. > Ah, that's something else then. I didn't understand that from your original post. Thanks for clarifying! > Remember that Thesaurus is a data type and ThesaurusCfg is a alternative > to configparser. Additionally I could bring this full circle to > something that integrates with or provides an alternative to argparse. > (providing an integrated cfg file and command line argument solution > which currently does not exist.) > These days, thanks to pip and PyPI, anyone can publish libraries and it is easy for developers to find and use them if they like. There is no longer a need to add things to the stdlib just to make them widely available. On the other hand, bringing something into the stdlib means undertaking an obligation by the Python core devs to maintain it for a very long period of time. It also ties their releases to the Python release cycle, which is not appropriate for many libraries. Therefore, our current policy for additions to the standard library is to add as few things as possible. We've recently been adding to the standard library only in special cases, such as wanting to use something in the of the standard library. With Thesaurus I can't currently think of a reason for such special consideration. > I hope with this in mind this thread is considered on-topic and I'd > highly value any feedback from the 'serious people' on this list if they > should take a look. > We are, after all, a group of people developing a language named after Monty Python. You will find very few 'serious people' here! ;) - Tal Einat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CAMLWWX3A6KGCK7KEIXQAENIBO27VOOE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.
On Tue, Dec 3, 2019 at 6:23 PM Mark Shannon wrote: > Hi Everyone, > > I am proposing a new PEP, still in draft form, to impose a limit of one > million on various aspects of Python programs, such as the lines of code > per module. > > Any thoughts or feedback? > My two cents: I find the arguments for security (malicious code) and ease of implementation compelling. I find the point about efficiency, on the other hand, to be almost a red herring in this case. In other words, there are great reasons to consider this regardless of efficiency, and IMO those should guide this. I do find the 1 million limit low, especially for bytecode instructions and lines of code. I think 1 billion / 2^32 / 2^31 (we can choose the bikeshed color later) would be much more reasonable, and the effect on efficiency compared to 2^20 should be negligible. I like the idea of making these configurable, e.g. adding a compilation option to increase the limit to 10^18 / 2^64 / 2^63. Mark, I say go for it, write the draft PEP, and try to get a wider audience to tell whether they know of cases where these limits would have been hit. - Tal Einat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TWACAUZCTR4TANEI3DK5IKPG5RWJNJJM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Comparing UUID objects to strings: why not?
On Thu, Jan 23, 2020 at 8:15 PM Andrew Svetlov wrote:
>
> On Thu, Jan 23, 2020 at 5:46 PM Michael Anckaert via Python-Dev
> wrote:
> >
> > Hello everyone
> >
> > I have a usecase where I'm comparing a UUID instance with string quite
> > often. A case where I have to convert the UUID instance to a string
> > using str(uuid_obj), leading to redundant code:
> >
> > if str(uuid_obj) == uuid:
> > # do stuff...
> >
> > In my experience I can't find a case where you wouldn't want the
> > implicit conversion to string before comparing a UUID with string. So
> > I would like to propose improving the __eq__ method of UUID to:
> >
> > def __eq__(self, other):
> > if isinstance(other, UUID):
> > return self.int == other.int
> > elif isinstance(other, str):
> > return str(self) == other
> > return NotImplemented
> >
> > Based on my testing and experience I don't think this is a breaking
> > change and would be a meaningful change to the way UUID works. Of course
> > please don't hesitate to change my view or point out any flaws in my
> > reasoning.
> >
> > If other people support this change I'd start the work of creating an
> > issue and PR to get this change implemented.
>
> -1
> Implicit type casting leads to hidden errors very often.
I also tend to be against this change, for the same general reason
that Andrew gave, but let me try to put that into more concrete terms.
In the specific case of UUIDs in the uuid module, equivalent UUIDs can
be constructed in various ways using the UUID constructor, including
using different string formats. For example, the following strings are
considered equivalent UUIDs:
"00010203-0405-0607-0809-0a0b0c0d0e0f"
"{00010203-0405-0607-0809-0a0b0c0d0e0f}"
"000102030405060708090a0b0c0d0e0f"
"urn:uuid:00010203-0405-0607-0809-0a0b0c0d0e0f"
For more examples, see the uuid module's tests:
https://github.com/python/cpython/blob/7142df5ea23b4ce0efb72746b4b3b65414e8dcb1/Lib/test/test_uuid.py#L29
Using string comparison for UUIDs would be significantly different
than what comparing uuid.UUID objects does. Therefore, making
UUID.__eq__() fall back to string comparison would be confusing, IMO
much more so than it would be helpful.
- Tal Einat
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ZWS3EAQ55C3GUHRFPYHQWHG5O2OMDVWE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Three trivial PRs from first-timers in need of merging!
Thanks for bringing these to our attention Brandt! Mariatta merged the first PR a few hours ago, and I just merged the second PR now. The third PR looks good, but it would be good for someone with a bit more experience with our C code to take a quick glance before we merge it. - Tal Einat On Fri, Feb 21, 2020 at 8:49 AM Kyle Stanley wrote: > Thanks for bring attention to these PRs, Brandt! I think the second one > should be particularly uncontroversial, seeing as it's just applying PEP > 409 (raise from None) to an existing exception in an argparse unit test to > clean up some unhelpful context clutter in the traceback. > > On Thu, Feb 20, 2020 at 11:41 PM Brandt Bucher > wrote: > >> Hi everybody! >> >> I've found a handful of trivial PRs from new contributors that have gone >> un-core-reviewed since November. CLAs are signed, tests are passing, and >> I've verified the quality and correctness of each one. >> >> If anybody has a few spare minutes to merge these, I know that it would >> make the authors very happy! :) >> >> Clarify numeric padding behaviour in string formatting: >> - A helpful doc addition (just a few words). >> - https://github.com/python/cpython/pull/17036 >> >> argparse unittest tracebacks are confusing if an error is raised when not >> expected: >> - This just changes a "raise" to a "raise from None" in the argparse unit >> test machinery. >> - https://github.com/python/cpython/pull/17120 >> >> Reuse identifier of PREDICT macros as PREDICT_ID: >> - Unifies some shared naming logic in the ceval prediction macros (don't >> worry, it's simple). >> - https://github.com/python/cpython/pull/17155/files >> >> Thanks. >> >> Brandt >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/46U2H5U2BAACZZETIWJTAJAGXJSD6MKO/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PAOV4YWV4FJDM7WEOJ2DSMCO4XWHWFWZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VILCDKNHD5MTQ5TUTSVQARMBX3JMTFKJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python code coverage for integration Tests
Hello Magesh, This mailing list is for discussing the development of the Python language itself. For questions regarding developing with Python, please try other channels, such as the #python IRC channel on freenode <https://www.python.org/community/irc/> or the python-list <http://mail.python.org/mailman/listinfo/python-list> mailing list. Good luck, - Tal Einat On Fri, Jul 31, 2020 at 8:07 AM Magesh Sundar wrote: > Hi There, > > Which is the best tool to run the code coverage for python integration > tests? I tried running with Code Coverage but no data is getting collected > when I run my test using pytest command. > > Thanks, > sm > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/JJS3JTOW426UYRK7E2JOEWNSTUUWKLAF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LJ5NCIXFIJHHMGAWVL2IZ62Q2DMKWZ76/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pay for PR review and merging for VxWorks RTOS
Hi Peixing, It is certainly possible to add a buildbot without it breaking any of our CI. You're welcome to contact the mailing list for details: python-buildb...@python.org. - Tal On Mon, Aug 10, 2020 at 5:21 AM Xin, Peixing wrote: > Hi, Dong-hee: > > Thanks for your comments. > > If that is helpful for coredev's review, I can set it up. However, since > the porting to VxWorks has not been done, I am afraid that we are not > allowed to connect the Buildbot to avoid breaking the existing CI. Is it > possible just setting a Buildbot for reviewing use without connecting to CI? > > Thanks, > Peixing > > -Original Message- > From: Dong-hee Na > Sent: Friday, August 7, 2020 4:01 PM > To: Xin, Peixing > Cc: Kyle Stanley ; python-dev@python.org; Meng, Bin < > bin.m...@windriver.com>; Duan, Kun > Subject: Re: [Python-Dev] Re: Pay for PR review and merging for VxWorks > RTOS > > > Buildbot is also not a problem. > > The early issue from the core developer side, it would be helpful to > review if the Buildbot is supported by Wind River for VxWorks. > > 2020년 8월 6일 (목) 오후 1:16, Xin, Peixing 님이 작성: > > > > Hi, Stanley: > > > > > > > > Thanks for your comments. > > > > > > > > Almost all the patches are simple compatibility patch. But the > subprocess module is an exception. Like windows, VxWorks have no fork/exec > API provided. Instead, VxWorks uses rtpSpawn() to spawn a new process. So > we have to implement VxWorks’ own extension modules to support subprocess > module. However, this is not significant amount of codes, just around 500 > lines of C codes. Hopes any core dev could help to review and merge the > simple compatibility patches. If I can be granted the commit privileges, > that will be great. To ensure the quality, I will get the patches reviewed > enough well before merging. > > > > For long term support for VxWorks RTOS, I am an engineer from Wind > River. Wind River is willing to officially provide the support and I am > willing to be the maintainer. Buildbot is also not a problem. Once the > patches have been merging done, we will connect the buildbot for VxWorks. > > > > > > > > Thanks, > > > > Peixing > > > > > > > > From: Kyle Stanley > > Sent: Thursday, August 6, 2020 9:27 AM > > To: Xin, Peixing > > Cc: python-dev@python.org; Meng, Bin > > Subject: Re: [Python-Dev] Pay for PR review and merging for VxWorks > > RTOS > > > > > > > > What exactly does the PR involve? Is it a relatively simple > compatibility patch or something that adds significant amounts of > platform-specific code? The former can be reviewed (and potentially merged) > by any core dev knowledgeable in the areas being changed, but the latter > requires long-term support for the platform. > > > > > > > > In order to provide support for a new platform that we don't presently > have support for in CPython, it requires the following: > > > > > > > > 1) An existing core developer willing to provide long-term support for > the platform. Alternatively, someone else can be granted commit privileges, > for the purpose of maintaining that platform and fixing any issues that > come up in that CI that are specific to it. However, this is done on a > case-by-case basis, as it still requires a decent amount of trust with that > individual. > > > > > > > > 2) A stable buildbot provided, to test against new changes made to > CPython. > > > > > > > > The purpose of the above is to ensure that any substantial > platform-specific code added to CPython receives proper care; this is > opposed to a large addition of new code for a platform that has nobody to > take care of it when issues come up. Especially as a group of mostly > volunteers (and those paid by their employers to contribute), the latter > wouldn't be sustainable. I personally think it would be fantastic to have > official support for real-time OSs in CPython, but in this ecosystem, it > requires being able to place trust in someone that's willing and adequately > proficient in the related areas to provide long-term support for them. > > > > > > > > For more details, see PEP 11: > https://www.python.org/dev/peps/pep-0011/#supporting-platforms. > > > > > > > > > > > > On Wed, Aug 5, 2020 at 7:44 AM Xin, Peixing > wrote: > > > > Hi, Python developers: > > > > > > > > Anyone interested in PR review and merging for VxWorks RTOS? We can give > a proper pay for that. Contact me if you have interest. > > > > > > > > Thanks, > > > > Peixing > > > > > > > > ___ > > Python-Dev mailing list -- python-dev@python.org To unsubscribe send > > an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-dev@python.org/message/HA > > TTYX3BWEIPVVUL7FMSNSCFYOBPS6OD/ Code of Conduct: > > http://python.org/psf/codeofconduct/ > > > > ___ > > Python-Dev mailing list -- python-dev@python.or
[Python-Dev] Re: [python-committers] Thank you Larry Hastings!
On Mon, Oct 5, 2020 at 9:39 PM Barry Warsaw wrote: > > They say being a Python Release Manager is a thankless job, so the Python > Secret Underground (PSU), which emphatically does not exist, hereby > officially doesn’t thank Larry for his years of diligent service as the > Python 3.4 and 3.5 release manager. > > On the other hand, the Python Steering Council, Python Software Foundation, > and worldwide Python community, all of which emphatically *do* exist, all > extend our heartfelt thanks to Larry for his excellent stewardship of Python > 3.4 and 3.5! > > Python 3.4 and 3.5 were both pivotal releases. While the features of these > two releases are too numerous to mention here, they introduced such staples > as: > > * asyncio > * enum > * pathlib > * async and await keywords > * matrix multiplication operators > * typing and zipapp modules > > and so much more. For details, see: > > * https://docs.python.org/3/whatsnew/3.4.html > * https://docs.python.org/3/whatsnew/3.5.html > > Larry’s first official release of 3.4.0a1 was on 2013-08-03 and his last > Python 3.5.10 release was 2020-09-05. That’s 7 years of exemplary release > managing! > > Larry, from all of us, and from me personally, thank you so much for your > invaluable contributions to Python. Enjoy your retirement! > > Cheers, > -Barry (on behalf of the PSC and PSF) These praises are certainly very well deserved! You have my thanks as well, Larry. - Tal Einat ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SZVPDOXQA4KL7NUHB4CLLFLHL37BLQ22/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Changing Python's string search algorithms
On Wed, Oct 14, 2020 at 7:57 PM Tim Peters wrote: > > [Guido] > > Maybe someone reading this can finish the Wikipedia page on > > Two-Way Search? The code example trails off with a function with > > some incomprehensible remarks and then a TODO.. > > Yes, the Wikipedia page is worse than useless in its current state, > although some of the references it lists are helpful. This is a much > better summary: > > http://www-igm.univ-mlv.fr/~lecroq/string/node26.html#SECTION00260 > > but, I believe, still far too telegraphic. > > The original paper is by far the best account I've seen so far, with > complete code and exhaustive explanations and proofs. Even examples > ;-) > > But here's the thing: I don't believe this algorithm this _can_ be > reduced to an elevator pitch. Excruciating details appear to be > fundamental at every step, and I've seen nothing yet anywhere > approaching an "intuitive explanation" :-( What happens instead is > that you run it on the hardest cases you can dream up, and your jaw > drops in amazement :-) That sounds very interesting! I'll definitely be digging deeper into the algorithm, papers and proofs of the underlying "Critical Factorization" theorem. My goal would be to find a good way to explain them, ideally some kind of interactive article. Ideally that would also lead to better Wikipedia pages. I'd be happy to help with this project. I've done quite a bit of relevant work while developing my fuzzysearch[1] library. - Tal Einat [1] https://pypi.org/project/fuzzysearch/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HJQTATKMX7SOEUGI5XBVA6JQZKDFCBEH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Removing IDLE from the standard library
Hello, I would like to propose removing IDLE from the standard library. I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. In recent years IDLE has received negligible interest and attention from the Python community. During this time IDLE has slowly gone downhill. The documentation and tutorials grow increasingly out of date. Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. Bugs take months, and sometimes more than a year, to be solved. Features that have since become common-place, such as having a non-intrusive search box instead of a dialog, are obviously and painfully lacking, making IDLE feel clumsy and out-dated. For these reasons, I think it would be fitting to remove IDLE from the standard library. IDLE is no longer recommended to beginners, IMO rightfully so, and this was the main reason for its inclusion in the standard library. Furthermore, if there is little or no interest in developing and maintaining IDLE, it should be removed to avoid having buggy and badly supported software in the standard library. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
> I would like to propose removing IDLE from the standard library. > > I have been using IDLE since 2002 and have been doing my best to help > maintain and further develop IDLE since 2005. I'm surprised by the amount of interest this has raised already. To answer a few questions that were raised: In recent years I have worked up many patches, both bugfixes and new features and improvements. Getting any attention to these was non-trivial, and getting patches accepted (or an explanation why they are rejected in some cases) almost always took many months, sometimes years, and some are still unresolved. It has been very frustrating. When I ran into bugs I fixed them and submitted a patch. I have also done so for quite a few bugs reported by others. However, there are currently several bugs in the tracker which nobody is taking any notice of. IIRC most of the recent bugs are related to OSX or 64-bit Windows. To those who mention that IDLE is "okay" or "not going uphill", my grandfather would say "if you aren't running forwards, you are falling behind." You should know how IDLE looks to programmers seeing it for the first time -- IDLE's quirky and old-fashioned looks and interface are a major turnoff for new users. As a result I have stopped recommending it to coworkers, despite personally liking IDLE, instead recommending the basic command-line or IPython for interactive work, and any other IDE or text editor for development. I too prefer IDLE to the basic command line, and think that something like IDLE is well-suited for learning/teaching Python. I also think an interpreter with a nice GUI can be far superior to a text-only interpreter. However, I've mostly lost hope for IDLE, and am currently hoping that something else takes its place. The fact is that for many years little effort has gone into developing and maintaining IDLE, and I believe being tucked in a corner of the Python codebase is a major reason for this. I really don't see why IDLE has to be part of the standard library, what's wrong with IDLE being an externally maintained application? Yes, IDLE still works (mostly), but us few who continue to use it could do so even if it weren't part of the standard library. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Sun, Jul 11, 2010 at 12:03 PM, Ronald Oussoren wrote: > > On 11 Jul, 2010, at 10:57, Tal Einat wrote: >> >> When I ran into bugs I fixed them and submitted a patch. I have also >> done so for quite a few bugs reported by others. However, there are >> currently several bugs in the tracker which nobody is taking any >> notice of. IIRC most of the recent bugs are related to OSX or 64-bit >> Windows. > > The OSX issues al seem to be related to general Tk or Tkinter bugs > on OSX. I know to little about Tk and Tkinter to seriously work on > those. > > Ronald Perhaps, but the point is that these bugs remain. Certainly this isn't because just you, out of the entire Python development community, know little about Tk and Tkinter. Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native look&feel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
On Sun, Jul 11, 2010 at 11:57 AM, Tal Einat wrote: >> I would like to propose removing IDLE from the standard library. >> >> I have been using IDLE since 2002 and have been doing my best to help >> maintain and further develop IDLE since 2005. > > I'm surprised by the amount of interest this has raised already. To > answer a few questions that were raised: > > To those who mention that IDLE is "okay" or "not going uphill", my > grandfather would say "if you aren't running forwards, you are falling > behind." You should know how IDLE looks to programmers seeing it for > the first time -- IDLE's quirky and old-fashioned looks and interface > are a major turnoff for new users. As a result I have stopped > recommending it to coworkers, despite personally liking IDLE, instead > recommending the basic command-line or IPython for interactive work, > and any other IDE or text editor for development. > > I too prefer IDLE to the basic command line, and think that something > like IDLE is well-suited for learning/teaching Python. I also think an > interpreter with a nice GUI can be far superior to a text-only > interpreter. However, I've mostly lost hope for IDLE, and am currently > hoping that something else takes its place. > > The fact is that for many years little effort has gone into developing > and maintaining IDLE, and I believe being tucked in a corner of the > Python codebase is a major reason for this. I really don't see why > IDLE has to be part of the standard library, what's wrong with IDLE > being an externally maintained application? > > Yes, IDLE still works (mostly), but us few who continue to use it > could do so even if it weren't part of the standard library. Most of the responses up to this point have been strongly against my proposal. The main reason given is that it is nice to have a graphical IDE supported out-of-the-box with almost any Python installation. This is especially important for novice programmers and in teaching environments. I understand this sentiment, but I think that supplying a quirky IDE with many caveats, lacking documentation, some bugs and a partially working debugger ends up causing more confusion than good. Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response. Although several people say that they think having IDLE in the stdlib is important, the fact is that IDLE is considered quite unimportant by most of the Python community. Having IDLE in the stdlib may be convenient for a few people, but most never use it and don't care about it. I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. And for experienced Python developers, very few actually use IDLE, and those who do could easily install it if it weren't part of the stdlib. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
Guido van Rossum wrote: >David Beazley wrote: >> >>> I would like to propose removing IDLE from the standard library. >>> >> >> -1000. From the Python training department, I would like to say that this >> would be a horrible idea. > >Right. IDLE fits a niche. It's never going to be the world's best >Python development environment but it isn't the worst either, and it's >worth keeping around. > >There clearly are *some* folks who care enough about IDLE to submit >bug reports and fixes. How about we empower these people by giving at >least one of them commit privileges? IDLE development has often been >done by people who aren't otherwise contributing to the core, and we >surely should trust those folks with commit privileges. This would certainly be a great improvement on the current situation. However, I still think IDLE is not currently in a state that it should be suggested for use by beginners. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing IDLE from the standard library
Martin v. Löwis wrote: >> Initially (five years ago!) I tried to overcome these issues by >> improving IDLE, solving problems and adding a few key features. >> Without going into details, suffice to say that IDLE hasn't improved >> much since 2005 despite my efforts. For example, see >> http://bugs.python.org/issue1529142, where it took nearly 3 years to >> fix a major issue from the moment I posted the first workaround. For >> another example, see http://bugs.python.org/issue3068, where I posted >> a patch for an extension configuration dialog over two years ago, and >> it hasn't received as much as a sneeze in response. > > I can understand that this is frustrating, ... I am not writing this to vent my frustration, and have purposely avoided making that the issue. > ... but please understand that > this is not specific to your patches, or to IDLE. Many other patches on > bugs.python.org remain unreviewed for many years. That's because many of > the issues are really tricky, and there are very few people who both > have the time and the expertise to evaluate them. I am aware of the situation with regard to issue reviews, but I think with IDLE there is more going on. In other parts of the Python codebase, a workaround for a major usability issue wouldn't normally have taken nearly three years to resolve after a working patch was submitted. And a working, well-tested patch wouldn't normally have sat ignored for over two years. Well, perhaps these things happen occasionally, but with IDLE this is the norm. > FWIW, I don't consider a few months as a "long" time for a patch review. > At the moment, I'm personally able to perhaps review one issue per week > (sometimes less); at this rate, it'll take several years until I get > to everything. I'm not talking about a few months, I'm talking about at least six months in most cases, years in many cases, as in the examples I mentioned. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Glyph Lefkowitz wrote: > > On Jul 11, 2010, at 10:22 AM, Tal Einat wrote: > > The people who are actually *in* those environments seem to disagree with > you :). I think you underestimate the difficulty of getting software > installed and overestimate the demands of new Python users and students. > While I don't ever use IDLE if there's an alternative available, I have been > very grateful many times for its presence in environments where it was a > struggle even to say "install Python". A workable editor and graphical > shell is important, whatever its flaws. (And I think you exaggerate IDLE's > flaws just a bit.) I would like to note that I am one of those in those environments. I have used IDLE to teach Python to new users, and their opinion of IDLE (and Python as a consequence) wasn't great, precisely because of the bugs and quirks. Recently I have stopped recommending IDLE for beginners and have found that this avoids quite a few snags, which is significant. I have also been in environments where installing anything was problematic and having IDLE available out-of-the-box was supposed to be a clear win. I certainly used it, but all of my coworkers (experienced Pythonistas who have worked with IDLE before) ended up preferring the basic interpreter and text editors such as vim, despite my advocacy of IDLE, because they tired of IDLE's snags (e.g. the inability to run several instances in parallel). My point is that I don't think I am exaggerating IDLE's flaws. I'm not saying that it is no longer usable or useful, but I am saying that its current state is not "okay". - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Guilherme Polo wrote: > 2010/7/11 "Martin v. Löwis" : >>> In the 2009 Google Summer of Code I was the mentor for a Brazilian >>> student, Guilherme Polo, who completed and extended important >>> improvements to IDLE made during the previous year by David Scherer. >>> Given the somewhat official nature of this work, I assumed that these >>> needed improvements would make it into the standard distribution, but as >>> far as I know that hasn't happened. It would seem that if even this >>> "sponsored" project didn't impact the standard Python distribution, >>> something is broken in the procedures, and probably what is needed is, >>> as Guido says, that someone be given the authority to get improvements >>> to IDLE into the standard distribution. Making a significant change to >>> the update procedures is clearly needed. >> >> I don't think so; instead, the perception of authority needs to be >> adjusted (in the specific case). Guilherme could have committed these >> changes, but, for whatever reason, decided not to. Nor did his direct >> mentor (i.e. you) tell him to commit the changes, and neither did I. >> >>> Even if this needed change is made, there is also merit to Tai's >>> suggestion of creating a separate project, to encourage developers like >>> him to work together to improve IDLE, without having as a first priority >>> to worry about getting it into the standard distribution, but with the >>> clear understanding that this is the place to go for improvements to >>> migrate into the standard distribution. >> >> Again, Guilherme could commit his changes any time. >> >> Regards, >> Martin > > I think Martin has always supported me in some way and I really > appreciate that. But, maybe because I won commit privileges solely > based on GSoC work, I felt other developers wouldn't approve my > commits without previous discussion and that is the major reason for > not committing most of my patches. FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's project of the same name, in a sense). The idea was to have a fork of IDLE with new features which need to be tried out by "beta testers" to iron out all of the glitches before making it into the main version, like IDLE-fork back in the beginning of the decade. However I have utterly failed in promoting this project and getting "beta testers" on board, at least partially due to the lack of interest from the community (and admittedly my lack of PR skills). - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Hi Kurt, I'm glad you've joined this discussion. My point is that whatever the reason, for the past five years (at least) nearly every issue related to IDLE has taken years to be resolved, and many have still not been resolved. As a result the current state of IDLE is quite poor. To be perfectly clear, I'm am not blaming anyone for this. I just think this is something the development community should be more aware of and decide how to deal with. On Mon, Jul 12, 2010 at 12:20 PM, Kurt B. Kaiser wrote: > Particularly on Windows, there is an expectation that a contemporary > programming language comes with a GUI. Using the Windows Python shell > isn't very satisfactory, largely because of the poor file handling > capability in that environment. IDLE provides a simple solution, > suitable for beginners as well as experts. It provides one-keystroke > save/run in a fresh environment not associated with the GUI. I have run > IDLE inside IDLE (though I'm not positive that will work right now). > How many IDEs can do that? [snip] > On a netbook, screen space is at a premium, and a simple interface has > advantages. There are many IDEs listed on the wiki if people are > looking for the more complex style, but I'd suggest that they aren't > appropriate for beginners. And by beginners, I include elementary > school students. I agree that IDLE is great specifically thanks to its simplicity, and should be kept simple. I think something like IDLE can be great for teaching and learning Python (and other uses as well) and has a place in the stdlib. I'm simply not sure if IDLE in its current state is fit for this purpose. > I'm mystified about the comments that the GUI is ugly. It is minimal. > On XP, it looks exactly like an XP window with a simple menubar. Those > who haven't looked at it for awhile may not be aware of the recent > advances made by Tk in native look and feel. What is ugly? IDLE may be somewhat close to looking like a native application, but it is not quite there. Some examples: * Users expect to be able to copy/paste using the mouse via the right-click context menu, which is impossible in IDLE (in both shell and editor windows). * The selection jumping to the end of the line unexpectedly doesn't happen in any other GUI text editor. * The config dialog looks archaic. As for the native look&feel, this has still not been integrated into IDLE, though it seems now it will happen soon. This has already been discussed here. > IDLE works with "extensions". Plug-ins, if you will. The Option dialog > needs enhancement to support extension selection, and I believe there is > a patch to do that. More extensions would be a good thing. IDLE extensions are a pain to work with and badly supported. Installing an extension requires manually placing it in the idlelib directory and manually adding its config options to a certain text file in that directory. In practice nobody ever takes the effort to try installing an IDLE extension, such as my SearchBar extension. There has been discussion on improving this situation, but again this never actually happened. I tried to move this along with a patch which adds an extension config dialog, which has been sitting in the issue tracker ignored for two years. > Tal has made a couple of comments about not being able to run multiple > IDLEs at the same time, and he mentions > > http://bugs.python.org/issue1529142 > > This bug has been closed for over a year, and you can run as many IDLEs > as you like. You can run 2.7 and 3.x at the same time. I would have > expected Tal to know that. I clearly mentioned that as an example of a fix for a major usability issue which took three years to resolve after a workaround was first posted. It is worth noting that most people still don't use the versions of Python (and IDLE) where this fix has been integrated. > The reason that bug languished for two years was because first, it was a > bit of a hack, and second, Windows was problematic in that it reused > sockets and often left zombie subprocesses behind which couldn't be > killed except with the task manager. This causes real problems with > students - they lose confidence in the tool. > > Scherer and Weeble put together a patch using ephemeral ports which > nailed the problem, and I checked it in right away and > forward/backported it. True, but it took three whole years for this to happen. And this is for a glaring, annoying and limiting issue that nearly every user of IDLE has encountered. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. Löwis" wrote: >> My point is that I don't think I am exaggerating IDLE's flaws. I'm not >> saying that it is no longer usable or useful, but I am saying that its >> current state is not "okay". > > So can you produce a list of patches that you think can be accepted as-is? That's not a fair question! There have been several such patches, but most will likely need revision since they have been sitting around untouched for so long. And there would have been many more patches if the existing ones would have been addressed. Getting a few current patches accepted is not the reason I posted here. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis" wrote: >> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's >> project of the same name, in a sense). The idea was to have a fork of >> IDLE with new features which need to be tried out by "beta testers" to >> iron out all of the glitches before making it into the main version, >> like IDLE-fork back in the beginning of the decade. However I have >> utterly failed in promoting this project and getting "beta testers" on >> board, at least partially due to the lack of interest from the >> community (and admittedly my lack of PR skills). > > I think such a thing must inherently fail - precisely for these reasons. > > It's much better to release proposed new features along with Python, > and wait for feedback. Users won't start trying things out until after > the release. This is a general problem, and lead Barry Warsaw to believe > that "release candidates" are an utter waste of time. That's debatable, and I disagree. IDLE-fork was a great success, for example. If IDLE actually had many users today, certainly some of them would be interested in trying out a version with usability fixes and improvements. Waiting for a new release of Python can take over a year. Furthermore, backwards compatibility issues and support by third party libraries can delay migration to a newer version of Python even further. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
Kurt B. Kaiser wrote: >> Using Tkinter is a major reason that maintaining and further >> developing IDLE is difficult. For example, it took me many hours just >> to get a working Tkinter scrolled frame widget, having had to write it >> from scratch and struggle with the under-documented Canvas widget. >> Another example is that integration of the new ttk (a.k.a. Tile) >> widget set, which supports native look&feel on various platforms and >> adds modern widgets, has still not been integrated despite being >> available in Tk for years and despite considerable effort being >> invested into it. > > Tal, you've got some catching up to do, yourself. Tile went into Tk in > 8.5, two years ago. I was referring to the integration of the new ttk widgets into IDLE, which still hasn't happened despite two years having gone by. Sorry for not being clear on that point. - Tal Einat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
On Mon, Jul 12, 2010 at 6:11 PM, Kurt B. Kaiser wrote: > On Mon, Jul 12 2010, Tal Einat wrote: > >> On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. Löwis" >> wrote: >>>> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's >>>> project of the same name, in a sense). The idea was to have a fork of >>>> IDLE with new features which need to be tried out by "beta testers" to >>>> iron out all of the glitches before making it into the main version, >>>> like IDLE-fork back in the beginning of the decade. However I have >>>> utterly failed in promoting this project and getting "beta testers" on >>>> board, at least partially due to the lack of interest from the >>>> community (and admittedly my lack of PR skills). >>> >>> I think such a thing must inherently fail - precisely for these reasons. >>> >>> It's much better to release proposed new features along with Python, >>> and wait for feedback. Users won't start trying things out until after >>> the release. This is a general problem, and lead Barry Warsaw to believe >>> that "release candidates" are an utter waste of time. >> >> That's debatable, and I disagree. IDLE-fork was a great success, for example. > > We had major contributions from David Scherer, Guido, and Stephen Gava. > > But a key factor in its success was that I took it upon myself to keep > IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent > merges. Once the project was completed, I arranged with SF to move the > IDLEfork repository, including history, back into Python. > > This was not done with Noam's branch. As a result, it gradually drifted > to the point where it became essentially unmergable. Actually, Noam's branch was pretty much merged back as is -- that's where IDLE's auto-completion functionality came from. The later changes he made on that branch were never merged, as you mentioned, because Noam never bothered. I have been maintaining my own fork of IDLE for several years and manually keeping it in sync with IDLE (this was simple). The difference is that there was no single major new feature I was working on, such as the addition of a sub-process in IDLE-fork or Noam's addition of auto-completion. I was mostly making relatively minor fixes and changes which were not interrelated. I saw no reason to have them all merged back at once, so I posted patches as soon as I felt they were ready, and did the best I could to get them accepted. I eventually gave up on this process because every patch took far too long to be addressed and finally accepted or rejected, and I realized that most of the work I had done would never be merged back into the mainstream version of IDLE. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] IDLE contributors and committers
On Sat, Jul 17, 2010 at 2:47 PM, Steve Holden wrote: > On 7/17/2010 7:33 AM, Antoine Pitrou wrote: >> >> Hello, >> >> On Sun, 11 Jul 2010 02:05:22 +0300 >> Tal Einat wrote: >>> >>> I would like to propose removing IDLE from the standard library. >>> >>> I have been using IDLE since 2002 and have been doing my best to help >>> maintain and further develop IDLE since 2005. >> >> I haven't seen any conclusive statement or action to this thread. >> Without being an IDLE user myself (for good reason), I think that if >> IDLE should stay, active contributors such as Tal should be given commit >> access and enough free rein to maintain and improve it. >> >> Otherwise there's no reason to continue claiming that IDLE is important >> while discouraging such people's contributions. The current situation, >> where several core developers support IDLE's continued inclusion but >> none actually cares for the issues and patches in the tracker, is >> schizophrenic. >> > +1 > > There's no reason why Tal should be obstructed in his goal of making > IDLE at least acceptable again. It's fairly obvious thaat there aren't > any committers who have both the inclination /and/ the time to do this, > so adding Tal (and other interested parties) as a developer makes a lot > of sense. I would certainly accept this as a first step. Although I now use IDLE much less than I have in previous years, I would be willing to put in some time towards fixing the major current issues and integrating the few polished enhancements. However, in the long run just allowing "heavy" contributors such as myself commit rights won't be enough. There's definitely a need for one or more active maintainers of IDLE who can take care of incoming bug reports and patches. We may hope that at least one serious contributor who is given commit rights will take up this position naturally, but perhaps a more active approach would be beneficial? I also think that there is a need for a guiding hand for IDLE, as Guido is for Python. It took a bit of time until I "got" the goals and principles of IDLE (e.g. easy to learn, minimal and obvious interface) by having KBK explain them in detail and explain the drawbacks of certain proposed changes. Having some kind of central authority is especially important in order to keep IDLE on track because the active development of IDLE is slow and done by various contributors -- there is currently no central group of active developers making such decisions. This doesn't have to be one person who also takes care of bugs, patches and testing, it could be someone who is just readily available via the idle-dev mailing list and keeps up with development of IDLE. Going along these lines of thought, I reach my original conclusion: IDLE is somewhat a project of its own. Perhaps considering IDLE a daughter-project of Python is appropriate, and continuing to develop it as part of the Python codebase could be reasonable, if more active maintainers can be found. I certainly support continuing to package it as part of the standard distribution. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] datetime.date.today() raises "AttributeError: time"
For an unknown reason, datetime.date.today() began throwing a cryptic "AttributeError: time" exception. It took me a while to figure out that this was caused by an accidental overriding of the built-in 'time' module. Here's an example interactive session which shows the problem: [tal ~]$ touch time.py [tal ~]$ python Python 2.5.2 (r252:60911, Jul 17 2008, 10:47:50) [GCC 4.0.1 (Apple Inc. build 5484)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.__file__ 'time.py' >>> import datetime >>> datetime.date.today() Traceback (most recent call last): File "", line 1, in AttributeError: time >>> Here I used version 2.5.2, but I checked and this also happens on 2.6. It this desired behavior? At the very least the exception should be more detailed, perhaps to the point of suggesting the probable cause of the error (i.e. overriding the time module). - Tal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime.date.today() raises "AttributeError: time"
Steve Holden wrote: > Tal Einat wrote: >> It this desired behavior? >> >> At the very least the exception should be more detailed, perhaps to >> the point of suggesting the probable cause of the error (i.e. >> overriding the time module). >> > How is this different from any other case where you import a module with > a standard library name conflict, thereby confusing modules loaded later > standard library. Should we do the same for any error induced in such a way? The difference is that here the exception is generated directly in the C code so you don't get an intelligible traceback. The C code for datetime imports the time module via the Python C API. In other words, here a function from a module in the stdlib, datetime, barfs unexpectedly because I happen to have a file name time.py hanging around in some directory. There is no traceback and no intelligible exception message, just "AttributeError: time". I had to dig through datetime's C code to figure out which module was being imported via the Python C API, which turned out to be time. This is rare enough that I've never had something like this happen to me in seven years of heavy Python programming. - Tal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
