Re: [Python-Dev] Bluetooth 4.0 support in "socket" module
On Mon, Jul 14, 2014 at 10:30 AM, Skip Montanaro wrote: > On Mon, Jul 14, 2014 at 8:57 AM, Tim Tisdall wrote: > > Is there some online documentation with guidelines on how to contribute? > > http://lmgtfy.com/?q=contribute+to+python This response is unacceptable. Tim: check out https://docs.python.org/devguide/ and perhaps look at the core-mentorship[0] mailing list while coming up with your first contributions. It's a good first step to getting some guidance on the process and getting some eyes on your early patches. [0] https://mail.python.org/mailman/listinfo/core-mentorship/ ___ 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] Sad status of Python 3.x buildbots
On Tue, Sep 2, 2014 at 5:53 PM, Nick Coghlan wrote: > > On 3 Sep 2014 08:15, "Victor Stinner" wrote: > > > > x86 RHEL 6 3.x: TestReadline.test_init() fails, issue #19884. I don't > > have to this platform, I don't know how to fix it. > > Sorry, I haven't been a very good maintainer for that buildbot (the main > reason it never graduated to the "stable" list). If you send me your public > SSH key, I can add it (I think - if not, I can ask Luke to do it). > Alternatively, CentOS 6 may exhibit the same problem. > > From a completely different perspective, does anyone have experience with > using BuildBot with OpenStack hosted clients? We may be able to take > advantage of the PSF's new(ish) Rackspace infrastructure to provide more > stable test VMs. > Is this a Buildbot feature (as in Buildbot master spins up VMs fresh for a test run, or something), or do you just want to spin up a bunch of VMs, give access, and we configure them the same as we do today? ___ 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] Status of C compilers for Python on Windows
On Thu, Oct 9, 2014 at 7:29 PM, Victor Stinner wrote: > Hi, > > Windows is not the primary target of Python developers, probably > because most of them work on Linux. Official Python binaries are > currently built by Microsoft Visual Studio. Even if Python developers > get free licenses thanks for Microsoft, I would prefer to use an open > source compiler if it would be possible. So *anyone* can build Python > from scatch. I don't like the requirement of having a license to build > Python. The free version (Visual Studio Express) only supports 32-bit > and doesn't support PGO build (Profile-Guided Optimizations, which are > disabled if I remember correctly because of compiler bugs). > > I know that it's hard to replace Visual Studio. I don't want to do it > right now, but I would like to discuss that with you. Although I'm not very active around here much anymore, I was primarily working on Windows things within the last few years. While we have a lot of Windows users, we don't have a lot of Windows contributors. The huge amount of churn necessary to make a change away from VS, or the more likely move to make it possible to support both VS and , seems like a large amount of work that doesn't turn up much of a benefit. Especially for a platform with constrained developer availability, working software trumps all, so I don't expect that a project like this is going to see the regular contributors shifting their focus away from improving Python as it is. With that said, I do see the benefit of being able to build Python with a free compiler. It would be great for us to be able to say it's always built with free tools, but I'm not sure who's going to make this happen... ___ 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] Move selected documentation repos to PSF BitBucket account?
On Sun, Nov 23, 2014 at 5:57 PM, Steven D'Aprano wrote: > On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: > >> But I strongly believe that if we want to do the right thing for the >> long term, we should switch to GitHub. > > Encouraging a software, or social, monopoly is never the right thing for > the long term. > > http://nedbatchelder.com/blog/201405/github_monoculture.html > > >> I promise you that once the pain of the switch is over you will feel >> much better about it. I am also convinced that we'll get more >> contributions this way. > > I'm sure that we'll get *more* contributions, but will they be *better* > contributions? > > I know that there are people who think that mailing lists are old and > passe, and that we should shift discussion to a social media site like > Reddit. If we did, we'd probably get twenty times as many comments, and > the average quality would probably plummet. More is not necessarily a > good thing. If we need to ensure that we're getting better contributions than we are now, then we should be interviewing committers, rejecting newcomers (or the opposite, multiplying core-mentors by 100), and running this like a business. I've written some crappy code that got committed, so I should probably be fired. Enabling our community to be active contributors is an important thing. Give them a means to level up and we'll all be better off from it. ___ 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 2.x and 3.x use survey, 2014 edition
On Tue, Dec 16, 2014 at 2:15 PM, Skip Montanaro wrote: > > On Tue, Dec 16, 2014 at 1:58 PM, Marko Rauhamaa wrote: >> >> IMO, you should consider forking your library code for Python2 and >> Python3. > > > I don't get the idea that Brett Cannon agrees with you: > > http://nothingbutsnark.svbtle.com/commentary-on-getting-your-code-to-run-on-python-23 > > While he doesn't explicitly say so, I got the distinct impression reading > his recent blog post that he supports one source, not forked sources. > > In the absence to evidence to the contrary, I think of Brett as the most > expert developer in the porting space. I'm a few inches shorter than Brett, but having done several sizable ports, dual-source has never even on the table. I would prefer the "run 2to3 at installation time" option before maintaining two versions (which I do not prefer at all in reality). ___ 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] Compile Python on Windows (OpenSSL)
On Tue, Jan 13, 2015 at 4:04 PM, Victor Stinner wrote: > Hi, > > To compile Python on Windows, there are a few information in the > Developer Guide: > https://docs.python.org/devguide/setup.html#windows-compiling > > Python 3.5 now requires Visual Studio 2010 *SP1*, or newer Visual Studio: > http://bugs.python.org/issue22919#msg233637 > > I found PCbuild\readme.txt which is not mentionned in the devguide :-/ > https://hg.python.org/cpython/file/56f717235c45/PCbuild/readme.txt > (at least not on the Windows section of the setup page) > > I found some clues to build OpenSSL to be able to build the Python ssl > module, but I still have issues. > > Is there a more complete documentation? > > I found how to install svn.exe, perl.exe and nasm.exe, but not how to > install nmake.exe. I don't know the command to build OpenSSL. For nmake, are you running this in a regular Command Prompt or in the Visual Studio Command Prompt? The latter sets the right environment to point you to some tools that VS installs, including nmake. ___ 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] Compile Python on Windows (OpenSSL)
On Tue, Jan 13, 2015 at 4:36 PM, Victor Stinner wrote: > 2015-01-13 23:18 GMT+01:00 Steve Dower : >> Technically, Python 3.5 requires Visual Studio 2015 > > For me, it's *very* difficult to find how to install Visual Studio. > There are many different websites and web pages which mention Visual > Studio with a lot of versions and "flavors" (Express, Community, > Ultimate, etc.). > > Visual Studio 2015 was not released yet :-/ > > My VM has only a disk of 40 GB. Only 12 GB are free. I already have VS > 2008 Express and VS 2010 Express installed. I understood that > "Ultimate" includes a *lot* of things, not only a C compiler. > > I found a "free" Visual Studio which is in fact Visual Studio 2013 > Community and I read that it's not free. > > I sent an email to Brian Curtin to ask to renew my MSDN account. He > didn't reply yet. I saw that and will send it on, but it's still going to take some time to process - usually a week or so. In the meantime, the first result searching for Visual Studio 2015 came up with http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs.aspx, which seems to give you VS2015. I haven't tried to run it since I'm not on Windows at the moment, but it looks correct. ___ 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] development
On Wednesday, January 28, 2015, Alan Armour wrote: > can you guys develop an audio kit that works around jackd or on windows > directx? and tutorials to write synthesizers. and drum machines like a > tr-606 with triggers ( I want to trigger a drum synth like the March > UDS(Soviet) Coolest drum synth EVER. > > > Also, I think you should have a way to write assembler functions to really > optimize speed and have a table and stuff for assembler learning for all > cpus and stuff. even asm graphics and audio would be super useful in some > instances. > That's not how this works. If you would like to write all of that code and allow it to mature in the wild while building a following around it and ensuring it is the best of its kind and a general enough solution to be included in the Python standard library, inclusion of that could be discussed in the future. ___ 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] Why does pip upgrade to a random version?
On Wed, Feb 4, 2015 at 1:04 PM, Martin Thoma wrote: > Could somebody please have a look at the following SO question? It seems as > if I might have found a bug in pip: > http://stackoverflow.com/q/28282671/562769 > > TL;DR of the SO question: > I executed `$ sudo pip install hwrt --upgrade` mutiple times and got a - > seemingly random - version of hwrt installed. Try the pip mailing list: https://groups.google.com/forum/#!forum/pypa-dev ___ 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 7
On Fri, Mar 20, 2015 at 7:54 PM, Neil Girdhar wrote:
> If ever someone wants to clean up the repository to conform to PEP 7, I
> wrote a program that catches a couple hundred PEP 7 violations in ./Python
> alone (1400 in the whole codebase):
>
> import os
> import re
>
> def grep(path, regex):
> reg_obj = re.compile(regex, re.M)
> res = []
> for root, dirs, fnames in os.walk(path):
> for fname in fnames:
> if fname.endswith('.c'):
> path = os.path.join(root, fname)
> with open(path) as f:
> data = f.read()
> for m in reg_obj.finditer(data):
> line_number = sum(c == '\n'
> for c in data[:m.start()]) + 1
> res.append("{}: {}".format(path, line_number))
> return res
>
> for pattern in [
> r'^\s*\|\|',
> r'^\s*\&\&',
> r'} else {',
> r'\ ]:
> print("Searching for", pattern)
> print("\n".join(grep('.', pattern)))
>
> In my experience, it was hard to write PEP 7 conforming code when the
> surrounding code is inconsistent.
You can usually change surrounding code within reason if you want to
add conforming code of your own, but there's little value and high
risk in any mass change just to apply the style guidelines.
___
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 7
On Fri, Mar 20, 2015 at 10:02 PM, Neil Girdhar wrote: > The code reviews I got asked me to revert PEP 7 changes. I can understand > that, but then logically someone should go ahead and clean up the code. > It's not "high risk" if you just check for whitespace equivalence of the > source code and binary equivalence of the compiled code. The value is for > people who are new to the codebase. There are a lot of areas of the C code that aren't explicitly or directly tested, so yes, a lot of changes are high risk, especially in bulk. While a one time change while checking binary equivalence would do it, it's also a huge amount of churn just to follow a guideline. Without an automated checker for the guidelines, if things get in they just get in, and sometimes you can modify them while making improvements to the code, but sometimes it depends on what exactly you're doing as well. On top of this, we already disallow mass PEP 8 changes to avoid the churn there as well, and it took a good bit of convincing for another semi-recent mass change (although I can't remember the topic, but it was deemed safe enough to make). Another common issue with mass code churn like this is that it affects tooling, such as `hg blame` ___ 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 7
On Fri, Mar 20, 2015 at 10:57 PM, Guido van Rossum wrote: > Neil, you have no idea. Please back off. I wouldn't go that far. Wanting a quality code base certainly isn't a bad thing, but there's a lot more progress to be made by working with what's there and being as mindful as possible of the guidelines moving forward. After all, they're guidelines, not rules. ___ 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] version of freshly built 2.7 python
On Thu, Apr 2, 2015 at 10:19 PM, Ethan Furman wrote: > On 04/02, Alexander Walters wrote: >> On 4/2/2015 21:29, Ethan Furman wrote: >>> >>> I just built the latest version of Python 2.7 on my development machine -- >>> or so I thought. When I invoke it, I get: >>> >>>Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) >>> >>> Why am I not seeing 2.7.9? >> >> Are you building from mercurial or a source tarball? > > Mercurial: > > ethan@code:~/source/python/python2.7$ hg parent > changeset: 90450:1beb3e0507fa > branch: 2.7 > parent: 90434:b428b803f71f > user:Zachary Ware > date:Thu Apr 24 13:20:27 2014 -0500 > files: Lib/test/test_itertools.py > description: > Issue #21346: Fix typos in test_itertools. Patch by Brian Kearns. That's almost a year old. Update it? ___ 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] Do we need to sign Windows files with GnuPG?
On Fri, Apr 3, 2015 at 7:25 AM, Paul Moore wrote: > On 3 April 2015 at 10:56, Larry Hastings wrote: >> My Windows development days are firmly behind me. So I don't really have an >> opinion here. So I put it to you, Windows Python developers: do you care >> about GnuPG signatures on Windows-specific files? Or do you not care? > > I don't have a very strong security background, so take my views with > a pinch of saly, but I see Authenticode as a way of being sure that > what I *run* is "OK". Whereas a GPG signature lets me check that the > content of a file is as intended. So there are benefits to both, and I > thing we should continue to provide GPG signatures. (Disclaimer: I've > never in my life actually *checked* a GPG signature for a file...) I haven't been on Windows in a bit, but this is my understanding/expectation as well. ___ 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] Reorganize Python categories (Core, Library, ...)?
On Wed, Oct 4, 2017 at 5:52 AM, Victor Stinner wrote: > Hi, > > Python uses a few categories to group bugs (on bugs.python.org) and > NEWS entries (in the Python changelog). List used by the blurb tool: > > #.. section: Security > #.. section: Core and Builtins > #.. section: Library > #.. section: Documentation > #.. section: Tests > #.. section: Build > #.. section: Windows > #.. section: macOS > #.. section: IDLE > #.. section: Tools/Demos > #.. section: C API > > My problem is that almost all changes go into "Library" category. When > I read long changelogs, it's sometimes hard to identify quickly the > context (ex: impacted modules) of a change. > > It's also hard to find open bugs of a specific module on > bugs.python.org, since almost all bugs are in the very generic > "Library" category. Using full text returns "false positives". > > I would prefer to see more specific categories like: > > * Buildbots: only issues specific to buildbots > I would expect anything listed under buildbot to be about infrastructure changes related to the running of build machines. I think what you're getting at are the bugs that appear on build machines that weren't otherwise caught during the development of a recent change. In the end those are still just bugs in code, so I'm not sure I would group them at such a high level. Wouldn't this be a better use of the priority field? ___ 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] Why is Python for Windows compiled with MSVC?
On Thu, Feb 1, 2018 at 4:19 AM, Oleg Sivokon wrote: > > > so why shouldn’t the one with the most users? > > Because it makes compilation difficult, and cross-compilatin completely > impossible? Why is it difficult: a package maintainer needs to (1) buy MS > Windows (2) create a special workflow for compiling on a different > machine. This is both costly and inconsistent with free-as-in-freedom... > It makes cross-compilation impossible because libraries produced by any > tool that can run on all target platforms are incompatible with Python > binaries on MS Windows. > > Again, many languages (i.e. projects similar in size an purpose to > CPython) took a different approach: they use GNU compilers to be able to > compile cross-platform. This is true for Ruby and Go at least. I would > need to investigate further, but I think these two examples should be > enough. > They should be enough for *what*, though? You can tell people what everyone else is doing, but the difference between that and what we have is someone's time and effort. > I’m likely biased because I work there and I’m the main intermediary with > python-dev, but these days Microsoft is one of the strongest supporters of > CPython. We employ the most core developers of any private company and we > all are allowed work time to contribute, we provide full access to our > development tools and platforms to all core developers and some prominent > projects, we’ve made fixes, enhancements and releases or core products such > as the CRT, MSVC, Visual Studio, Visual Studio Code, and Azure SPECIFICALLY > to support CPython development and users. As far as I know, ALL the Windows > buildbots are running on Azure subscriptions that Microsoft provides > (though managed by some awesome volunteers). You’ll see us at PyCon US > under the biggest banner and we’ll have a booth filled with engineers and > not recruiters. Crash reports from thousands of opted-in users come into > our systems and have directly lead to both CPython and Windows bug fixes. > > Oh, so this is the real reason... well, corporate interests are hard to > argue against. But, this is an interesting statistic nevertheless. Thanks > for letting me know. I think that's a mischaracterization of the situation. The MS toolchain was chosen some time long before I (or Steve) got involved, and when I upgraded us from VS2008 to VS2010 for 3.3 ~6 years ago I had several messages similar to this thread. As much as Steve is unlikely to do the work to initiate and maintain support of these other tools—whether due to his employer's interests or his own—I too was unlikely to do work like this thread is asking. In fact, the chances I would have done it were zero because I was sitting on my couch upgrading our Visual Studio versions because it let me do better stuff at my day job, though I was always open to review patches that supported alternatives without major disruption. However, they never came. I suspect the same could be said of Martin and anyone else working in this area prior to that, because nothing has really changed. Like the previous times this sort of question has come up—and really, for any question on this list—it ultimately turns into a matter of how much the solution is wanted and how much effort people are willing to give to make it happen. Historically, the former has had small amounts, and the latter has had much smaller amounts. Without a change there I don't think one will materialize in a released version of Python. Brian ___ 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] Drop/deprecate Tkinter?
On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > As https://bugs.python.org/issue33257 and > https://bugs.python.org/issue33316 showed, Tkinter is broken, for both > Py2 and Py3, with both threaded and non-threaded Tcl, since 2002 at > least, and no-one gives a damn. > > This seems to be a testament that very few people are actually > interested in or are using it. > > If that's so, there's no use keeping it in the standard library -- if > anything, because there's not enough incentive and/or resources to > support it. And to avoid screwing people (=me) up when they have the > foolishness to think they can rely on it in their projects -- nowhere in > the docs it is said that the module is only partly functional. For the future, this is not how you communicate with the development mailing list of any open source software project. I would suggest reading https://www.python.org/psf/codeofconduct/ for some pointers on how people typically behave around here in particular. > ___ 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] Drop/deprecate Tkinter?
On Wed, May 2, 2018 at 5:37 PM Antoine Pitrou wrote: > On Wed, 2 May 2018 23:28:22 +0200 > Antoine Pitrou wrote: > > On Wed, 02 May 2018 21:24:07 +0000 > > Brian Curtin wrote: > > > On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via Python-Dev < > > > python-dev@python.org> wrote: > > > > > > > As https://bugs.python.org/issue33257 and > > > > https://bugs.python.org/issue33316 showed, Tkinter is broken, for > both > > > > Py2 and Py3, with both threaded and non-threaded Tcl, since 2002 at > > > > least, and no-one gives a damn. > > > > > > > > This seems to be a testament that very few people are actually > > > > interested in or are using it. > > > > > > > > If that's so, there's no use keeping it in the standard library -- if > > > > anything, because there's not enough incentive and/or resources to > > > > support it. And to avoid screwing people (=me) up when they have the > > > > foolishness to think they can rely on it in their projects -- > nowhere in > > > > the docs it is said that the module is only partly functional. > > > > > > > > > For the future, this is not how you communicate with the development > > > mailing list of any open source software project. I would suggest > reading > > > https://www.python.org/psf/codeofconduct/ for some pointers on how > people > > > typically behave around here in particular. > > > > Perhaps it would be more constructive to address the OP's point than to > > play speech police. > > To elaborate a bit: the OP, while angry, produced both a detailed > analysis *and* a PR. It's normal to be angry when an advertised > feature doesn't work and it makes you lose hours of work (or, even, > forces you to a wholesale redesign). Producing a detailed analysis and a > PR is more than most people will ever do. > It may be normal to be angry when something doesn't work the way it should, but analyzing and creating a PR aren't the gateway to normalizing this behavior. Sending thousands of people this type of email isn't how it works. To address their point: no, next topic. ___ 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] Dealing with tone in an email
On Thu, May 3, 2018 at 2:45 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> On 03.05.2018 21:31, Brett Cannon wrote:
>
>
>
> On Thu, 3 May 2018 at 01:27 Paul Moore wrote:
>
>> On 3 May 2018 at 03:26, Steven D'Aprano wrote:
>>
>> >> Will all due respect, it's sometimes unpredictable what kind of wording
>> >> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> >> there that doesn't exist in other cultures. To me, "not give a damn"
>> >> reads like a familiar version of "not care about something", but
>> >> apparently it can be offensive.
>> >
>> > I'm Anglo-Saxon[1], and honestly I believe that it is thin-skinned to
>> > the point of ludicrousness to say that "no-one gives a damn" is an
>> > insult. This isn't 1939 when Clark Gable's famous line "Frankly my dear,
>> > I don't give a damn" was considered shocking. Its 2018 and to not give a
>> > damn is a more forceful way of saying that people don't care, that they
>> > are indifferent.
>>
>> Sigh. That's not what I was saying at all. I was trying to point out
>> that Antoine's claim that people should ignore the rhetoric and that
>> complaining about the attitude was unreasonable, was in itself unfair.
>> People have a right to point out that a mail like the OP's was badly
>> worded.
>>
>> > With respect to Paul, I literally cannot imagine why he thinks that
>> > *anyone*, not even the tkinter maintainers or developers themselves,
>> > ought to feel *offended* by Ivan's words.
>>
>> Personally, they didn't offend me. I don't pretend to know how others
>> might take them. But they *did* annoy me. I'm frankly sick of people
>> (not on this list) complaining that people who work on projects in
>> their own time, free of charge, "don't care enough" or "are ignoring
>> my requirement". We all do it, to an extent, and it's natural to get
>> frustrated, but the onus is on the person asking for help to be polite
>> and fair. And maybe this response was the one where I finally let that
>> frustration show through. I may read less email for a week or two,
>> just to get a break.
>>
>
> I had the same response as Paul: annoyed. And while Ivan thought he was
> using "emotional language to drive the point home that it's not some
> nitpick", it actually had the reverse effect on me and caused me not to
> care because I don't need to invite annoyance into my life when putting in
> my personal time into something.
>
> No one is saying people can't be upset and if you are ever upset there's
> something wrong; we're human beings after all. But those of us speaking up
> about the tone are saying that you can also wait until you're not so upset
> to write an email. This was never going to be resolved in an hour, so
> waiting an hour until you're in a better place to write an email that
> wasn't quite so inflammatory seems like a reasonable thing to ask.
>
> Let me express things right from the horse's mouth.
>
> The sole purpose of the tone was to not let the mesage be flat-out ignored.
> I had my neutral-toned, to-the-point messages to mailing lists flat-out
> ignored one too many times for reasons that I can only guess about.
> This time, the situation was too important to let that happen.
>
> Whatever anyone may think of this, it worked. I got my message through,
> and got the feedback on the topic that I needed to proceed in resolving the
> problem that caused it.
> I seriously doubt I could achieve that with a neutral-toned message just
> stating the facts: dry facts would not show ppl how this could be important
> ("ah, just another n00b struggling with Tkinter basics" or something).
>
As I said on the other thread, that doesn't make it any more acceptable as
over time it normalizes the behavior. If enough people want results—because
yes, sometimes things break, it's not fun, and sometimes things don't
receive response in the most timely fashion—they'll take that tone and
sometimes get what they want. Eventually it'll work enough that it becomes
more acceptable to behave that way, and eventually the people who are
willing to accept that type of behavior will be gone.
___
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] Single-file Python executables (was: Computed Goto dispatch for Python 2)
On Thu, May 28, 2015 at 11:23 AM, Chris Barker wrote: > I'm confused: > > Doesn't py2exe (optionally) create a single file executable? > > And py2app on the Mac creates an application bundle, but that is > more-or-less the equivalent on OS-X (you may not even be able to have a > single file executable that can access the Window Manager, for instance) > > Depending on what extra packages you need, py2exe's single file doesn't > always work, but last I tried, it worked for a fair bit (I think all of the > stdlib). > > I don't know what PyInstaller or others create. And I have no idea if there > is a linux option -- but it seems like the standard of practice for an > application for linux is a bunch of files scattered over the system anyway > :-) > > Yes, the resulting exe is pretty big, but it does try to include only those > modules and packages that are used, and that kind of optimization could be > improved in any case. > > So is something different being asked for here? > > Barry Warsaw wrote: >>> I do think single-file executables are an important piece to Python's >>> long-term competitiveness. > > Really? It seems to me that desktop development is dying. What are the > critical use-cases for a single file executable? Donald mentioned one earlier: command line utilities. I want a single CLI I can deploy to my customers that doesn't make them have to install Python or even know it's Python at all. My users write code in all types of languages on all OSes, but I should be able to produce one thing that they can all use. Donald himself initiated the CLI in particular I'm talking about, but Go is picking up steam here as we have other utilities that quickly solved the "write one thing, every user can run it immediately, no one knows/cares what it's written in" When I worked on Ubuntu One, I was the Windows guy responsible for making sure the end-user experience was the same there as it was on Ubuntu. On Ubuntu we were a part of the base install and didn't have to worry about much. On Windows we had none of that, not even the C runtime, so we had some pre-installer work to do, and then a bunch of py2exe hacking to make everything play nicely and transparently. ___ 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 quick word on top posting
On Monday, July 20, 2015, Emile van Sebille wrote: > Your +infinity could have easily been top posted -- particularly when > there's no in-line comments that require context. > > just-because-I'm-on-what-feels-like-a-300-baud-connection-ly yr's, > > Emile > > > On 7/19/2015 2:16 PM, Mark Lawrence wrote: > >> On 19/07/2015 22:06, Brett Cannon wrote: >> > > > > There is absolutely no reason we can't keep discussions cordial, >>> friendly, and on-point on this list and prevent this sort of debacle >>> from occurring again. >>> >>> >> +infinity >> > Empty replies like a fake vote should just not occur in general. That's not usually an issue on this list, but I see many others plagued by such responses and hope we never end up on that path (especially people +1'ing a +1...). Remember that not only do we need to keep emails to the characteristics Brett mentioned for the sake of having a healthy discussion list, we should strive to keep the noise as close to zero as possible as mails sent to this list reach *a lot* of people. ___ 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] Benchmark results across all major Python implementations
On Monday, November 16, 2015, Brett Cannon > wrote:
>
>
> On Mon, 16 Nov 2015 at 12:24 Maciej Fijalkowski wrote:
>
>> Hi Brett
>>
>> Any thoughts on improving the benchmark set (I think all of
>> {cpython,pypy,pyston} introduced new benchmarks to the set).
>>
>
> We should probably start a mailing list
>
There is/was a sp...@python.org list.
> "speed.python.org" becoming a thing is generally stopped on "noone
>> cares enough to set it up".
>>
>
> Oh, I know. I didn't say this could be considered wishful thinking since I
> know I have enough on my plate to prevent me from making it happen.
>
There was a grant given years ago to improve some of this stuff but I don't
believe the work ever saw the light of day.
___
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] Benchmark results across all major Python implementations
On Monday, November 16, 2015, Brett Cannon > wrote:
>
>
> On Mon, 16 Nov 2015 at 12:24 Maciej Fijalkowski wrote:
>
>> Hi Brett
>>
>> Any thoughts on improving the benchmark set (I think all of
>> {cpython,pypy,pyston} introduced new benchmarks to the set).
>>
>
> We should probably start a mailing list
>
There is/was a sp...@python.org list.
> "speed.python.org" becoming a thing is generally stopped on "noone
>> cares enough to set it up".
>>
>
> Oh, I know. I didn't say this could be considered wishful thinking since I
> know I have enough on my plate to prevent me from making it happen.
>
There was a grant given years ago to improve some of this stuff but I don't
believe the work ever saw the light of day.
___
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] I hope this won't be my last comment here ~ yet it may well be...
On Thursday, April 21, 2016, Burkhard Meier wrote: > Please do allow me to share my humble experiences of being a software > professional on a Windows platform. > > Almost 20 years. > > You know what; when I tried out 'sugar Linux' or Peppermint,,,the "admin' > dude kicked me out 5 times in one sole eve, > > Maybe this is just *me*.. > > You know what: I did have my time with this *open source community*... > > I was just asking a sincere question. > > C'mon > > This was rather very ridiculous. > > > As someone who spent many years as a Windows user and several years as a contributor to the Windows build here, if you have constructive thoughts to share on Python-on-Windows, please share them...but I can't decipher what any of this message is actually about. Additionally, you may want to try the python-list mailing list. ___ 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-checkins] cpython (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On Sun, Nov 3, 2013 at 8:54 PM, Terry Reedy wrote: > On 11/3/2013 11:48 PM, terry.reedy wrote: >> >> http://hg.python.org/cpython/rev/cced7981ec4d >> changeset: 86908:cced7981ec4d >> branch: 2.7 >> user:Terry Jan Reedy >> date:Sun Nov 03 23:37:54 2013 -0500 >> summary: >>Issue #X: Fix test_idle so that idlelib test cases are actually run >> under test.regrtest on 2.7. > > > This message is the one included with the patch by Ned Daily. Because a > message *was* included (not normal), hg import committed the patch > immediately, without giving me a chance to edit the patch or message. As far > as I know, there is no way I could have edited the message after the commit. > If there was, let me know. Besides what Zach mentions, most of the time you probably want to "hg import --no-commit ", run it, test it, then commit it with whatever message you want. ___ 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] NTPath or WindowsPath?
On Sat, Nov 16, 2013 at 2:50 PM, Serhiy Storchaka wrote: > 16.11.13 21:15, Antoine Pitrou написав(ла): > >> In a (private) discussion about PEP 428 and pathlib, Guido proposed >> that maybe NTPath should be renamed to WindowsPath, since the name is >> more likely to stay relevant in the middle term. What do you think? > > > What about nturl2path, os.name, sysconfig.get_scheme_names()? What about them? ___ 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 0404 and VS 2010
On Wed, Nov 20, 2013 at 5:36 PM, Christian Tismer wrote: > Hey Barry, > > > On 20.11.13 23:30, Barry Warsaw wrote: >> >> On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote: >> >>> Many customers are forced to stick with Python 2.X because of other >>> products, >>> but they require a Python 2.X version which can be compiled using Visual >>> Studio 2010 or better. This is considered an improvement and not a bug >>> fix, >>> where I disagree. >> >> I'm not so sure about that. Python 2.7 can still get patches to help >> extend >> its useful life by allowing it to be built with newer compiler suites. I >> believe this has already been done for various Linux compilers. I see no >> non-technical reason why Python 2.7 can't be taught how to build with VS >> 2010 >> or newer. Details are subject to RM approval, IMHO. >> >>> I have created a very clean Python 2.7.6+ based CPython with the >>> Stackless >>> additions, that compiles with VS 2010, using the adapted project >>> structure >>> of Python 3.3.X, and I want to publish that on the Stackless website as >>> the >>> official "Stackless Python 2.8". If you consider Stackless as official >>> ;-) . >>> >>> This compiler change is currently the only deviation from CPython 2.7, >>> but we may support a few easy back-ports on customer demand. We don'd add >>> any random stuff, of course. >> >> I think you're just going to confuse everyone if you call it "Stackless >> Python >> 2.8" and it will do more harm than good. > > > Barry, that's a good thing! This way I have a chance to get my build in at > all. > And that's the question, after re-thinking: > > Where can I check my change in, if it is going to be accepted as a valid > 2.7 bug fix (concerning VS 2008 as a bug, that is is)? If you do end up checking something in, I think it should be a backport of the 3.x VS2010 work, rather than contributing your own patch starting from 2.7. Otherwise any differences in the way you did things could cause pain while merging changes between the branches. ___ 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] Running the unit test as root/administrator
On Tue, Dec 3, 2013 at 8:14 PM, Ryan Gonzalez wrote: > Just don't run it on Windows... > Not helpful. I'm in meetings/training/traveling all week, but I'll get another Windows build slave up within the next few days. I used to have a spare desktop box that ran a build slave as admin so it would exercise the os.symlink code, but I moved, then the box died, etc. ___ 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] 2.x vs 3.x survey results
On Sun, Jan 5, 2014 at 3:08 AM, Lennart Regebro wrote: > On Sun, Jan 5, 2014 at 5:20 AM, John Yeuk Hon Wong > wrote: >> I think it helps Luca and many others (including myself) if there is a >> reference of the difference between 2.7 and Python 3.3+. > > Not specifically for 2.7 and 3.3, no. This is a fairly complete list: > > http://python3porting.com/differences.html > >> There are PEPs and books, but is there any such long list of references? >> >> If not, should we start investing in one? I know the basic one such as >> xrange and range, items vs iteritems, izip vs zip that sort of uniform >> syntax/library inclusion difference. >> >> If there is such reference available? > > I'm honestly despairing that people still don't know that there is a > free book on the topic. I have no idea how to increase the knowledge > on this point. I think we collectively need better SEO, or something like that. Python 3 would be in a better place if people actually knew the current state of things, versus asking people on "Hacker News". I constantly see people claiming they are stuck on Python 2 until NumPy, SciPy, and matplotlib are ported. Many of these people state they would love to use Python 3 if it weren't for those projects. However, those projects have all been ported -- and the first two have been available for several years now. The same goes for differences documents. I think 15 of us have written such documents, most of which cross-reference the other documents. Somehow very few people seem to know about any of them. ___ 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] Enable Hostname and Certificate Chain Validation
On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong wrote: > On 1/22/14 8:16 AM, Nick Coghlan wrote: >> >> Which is exactly the way most non-web-specialists working inside the >> comfort of corporate and academic firewalls will react to a change that >> breaks their access to internal applications, where self-signed certs and >> improperly configured internal CAs are endemic (of course, that's assuming >> they're using HTTPS at all, which I admit is an optimistic assumption). > > The number of people who are using 3.4+ in these environments is probably > very very low to be honest. I don't have a number to prove, but in that > environment people are more likely to still be using 2.6+. I think a > deprecation in 2.7+ would be nice, but forward we should just enable it by > default. > > When requests changed property calls (e.g. requests.json) to callable > instead of an attribute(from requests.json to requests.json()), I was > shocked. I had to figure out by Googling it. I found out from github > issue > > I think a hard fail is somehow necessary. > > Also, a lot of people overlook at deprecation warnings. They either don't > care or don't see it. I see a lot of deprecation warnings in the older > applications I write, but I can careless until it breaks. So as we moving > forward, we can break it. For those stuck behind, deprecation is the right > approach. They're disabled by default, so a lot of people simply don't know they exist because they also don't read the documentation. ___ 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] str.rreplace
On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence wrote: > On 24/01/2014 17:19, Ram Rachum wrote: >> >> Hmm, on one hand I understand the need for the separation between >> python-dev and python-list, but on the other hand I don't think >> python-list is a good place to discuss Python, the language. >> >> I now looked at the 17 most recent python-list threads. Out of them: >> >> - 58% are about third-party packages. >> - 17% are off-topic (not even programming related) >> - 11% are 2-vs-3 discussions >> - 5% are job offers. >> - 5% (which is just one thread out of 17) is about Python the language. >> > > > I'm extremely impressed by your knowledge of statistics, it must have taken > you many man years of effort to analyse all 17 threads in such detail. > > >> So can you understand why someone would be reluctant to start a >> discussion in python-list about Python the language there? Especially if >> this is the same place where beginners might ask newbies questions about >> Python? (So not only are actual Python questions just 5% of the content, >> non-newbie questions are just a subset of that 5%.) >> >> it's full of people asking about third-party Python packages, or asking >> newbie questions. >> > > How terrible, fancy having the audacity to ask about third party packages or > newbie questions on the *MAIN* Python mailing list. There's yet another > reason to bring back the death penalty in the UK. Please adjust the tone of your messages if you are going to use this mailing list. ___ 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] str.rreplace
On Fri, Jan 24, 2014 at 4:50 PM, Mark Lawrence wrote: > On 24/01/2014 22:44, Brian Curtin wrote: >> >> On Fri, Jan 24, 2014 at 11:40 AM, Mark Lawrence >> wrote: >>> >>> On 24/01/2014 17:19, Ram Rachum wrote: >>>> >>>> >>>> Hmm, on one hand I understand the need for the separation between >>>> python-dev and python-list, but on the other hand I don't think >>>> python-list is a good place to discuss Python, the language. >>>> >>>> I now looked at the 17 most recent python-list threads. Out of them: >>>> >>>>- 58% are about third-party packages. >>>>- 17% are off-topic (not even programming related) >>>>- 11% are 2-vs-3 discussions >>>>- 5% are job offers. >>>>- 5% (which is just one thread out of 17) is about Python the >>>> language. >>>> >>> >>> >>> I'm extremely impressed by your knowledge of statistics, it must have >>> taken >>> you many man years of effort to analyse all 17 threads in such detail. >>> >>> >>>> So can you understand why someone would be reluctant to start a >>>> discussion in python-list about Python the language there? Especially if >>>> this is the same place where beginners might ask newbies questions about >>>> Python? (So not only are actual Python questions just 5% of the content, >>>> non-newbie questions are just a subset of that 5%.) >>>> >>>> it's full of people asking about third-party Python packages, or asking >>>> newbie questions. >>>> >>> >>> How terrible, fancy having the audacity to ask about third party packages >>> or >>> newbie questions on the *MAIN* Python mailing list. There's yet another >>> reason to bring back the death penalty in the UK. >> >> >> Please adjust the tone of your messages if you are going to use this >> mailing list. >> > > I'm sorry but I do not understand, please explain what is wrong with an > extremely heavy dose of sarcasm. There's a real discussion going on and you're just responding to throw around sarcasm. People aren't going to come to this list if you're just going to give them snarky replies. It's not helping. ___ 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] Fwd: [python-tulip] Need help to finish asyncio documentation
On Sat, Feb 8, 2014 at 6:00 PM, MRAB wrote: > On 2014-02-08 23:32, Guido van Rossum wrote: >> >> We could really use more help reviewing and finishing asyncio's docs! >> > Some spelling mistakes: > > http://docs.python.org/dev/library/asyncio.html > mimicks > > http://docs.python.org/dev/library/asyncio-task.html > returing > nummber > > http://docs.python.org/dev/library/asyncio-protocol.html > correspondong > > http://docs.python.org/dev/library/asyncio-stream.html > Sublclass > > http://docs.python.org/dev/library/asyncio-subprocess.html > subproces > signale Fixed: http://hg.python.org/cpython/rev/3cfaeb788e00 - thanks! ___ 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] Getting Introduced with the Community and Looking forward to Contribute to the Project as part of Gsoc 2014
On Sun, Feb 9, 2014 at 10:34 AM, Nitika wrote: > I had got myself aware of the source to some extent and had forked on my > github account. The python source isn't forked in your github. A Github mirror of the Mercurial repository (hg.python.org) is available at https://github.com/python/cpython ___ 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 4: don't remove anything, don't break backward compatibility
On Mon, Mar 10, 2014 at 8:55 AM, Victor Stinner wrote: > For example, I propose to release the next major Python version (3.5) > with the version 4.0 but without removing anything. People put a lot of weight behind version numbers, often much more than they should. Jumping to 4.0 would be a PR nightmare and would ultimately hurt this project as more people decide that switching to another language will solve their problem better than jumping from 2.x to 4.0. People already think 2.7 to 3.4 is enough of a burden. Please do not do this. ___ 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] Whats New in 3.4 is pretty much done...
On Thu, Mar 13, 2014 at 8:29 PM, Terry Reedy wrote: > On 3/13/2014 7:34 AM, Stephen J. Turnbull wrote: >> >> Christian Heimes writes: >> >> > But I don't want it to sound like an advert... Suggestions? >> >> Not to worry. It *can't* be an advert -- it's all true, and there are >> no irrelevant half-naked glistening bodies. (Former newts in the pond >> don't count.) >> >> Seriously, while "expect a clean build" is not "news" for Python, > > > It is for a Windows repository build. I just rebuilt: 3.3 gives lots of > warning from multiple files; 3.4 none. > > >> Accompanied by an open invitation for reports to >> the contrary, that's hardly like a commercial. > > > Now that no warnings is a serious goal for 3.4+, I will report them should > they recur. If we're at no warnings, and no warnings is a serious goal, warnings should be errors. ___ 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 2.7.7. on Windows
On Mon, Apr 28, 2014 at 3:07 PM, Mike Miller wrote: > > On 04/29/2014 05:12 AM, Steve Dower wrote: >> >> This would be an incredibly painful change that would surprise and hurt a >> lot of >> people. > > > Hi, I think "incredibly painful" is overstating the case a bit. ;) We're > talking about an installer default, a setting that would still be changeable > as it always has, that by definition only will affect brand new installs. > > >> Yes, it is possible for a non-admin user to install arbitrary packages >> into a >> place where an admin user may inadvertently run it, thereby providing >> escalation >> of privilege. On the other hand, that applies to a lot of development >> tools, >> especially since most users on Windows these days are actually limited >> administrators - ANYTHING they install could run when they elevate a >> certain >> process. > > > None of Microsoft's Dev tools install to C:\, rather to ProgramFiles. The > fact that another security issue may exist is not a good justification for > creating additional. > > >> On the other hand, Python from python.org is a tool that should only be >> installed by those who are prepared to manage it. On Windows it is easy >> enough >> to have a second, secured copy for your admin scripts and an unsecured >> copy for >> non-admin tasks. > > > This sounds like the perspective of someone highly technical, forgetting > that new users will be installing python as well and vastly outnumber us. > "Normal people" need help to avoid security issues. > > Microsoft's guidelines on where to install software are clear, and don't > make exceptions that "tools" should be installed to the root of the drive to > bypass file system permissions, for convenience. > > >> I'm not sure what change you are proposing here... doesn't the installer >> already >> have an option to add to PATH? I'm sure I keep disabling it. > > > No, it does not. Unless it got slipped in when I wasn't looking. > > It should be an option though, I think everyone would agree. The option to add the current install to your path was added 3.3. >> "python.exe" on my PATH because I have 10+ versions installed at any one >> time. I > > > Remember, python-dev's are not the target users of this package, and are a > rather minuscule fraction of the user base. Knowing which Python you want on your path and that you want it on your path at all is somewhat of an advanced usage. While beginners do want to just open up cmd and type "python" and have it work, there are better ways to accomplish that which don't involve system-wide path manipulation or installation changes. Several PC manufacturers have been known to use Python for various system utilities, which is how Python sometimes ends up in the path on your grandma's Dell*. Even for a beginner who just wants "python" to work, we need to be careful to not wreck their entire system by helping them get our fresh Python install to show up. A more reasonable way to help beginners would be to create a shortcut somewhere that starts up cmd with a modified path. They can do whatever they want to do within that context without modifying their entire system. If they learn that they later want their system-wide path manipulated, they can do that within the installer or will known how to do that themselves. * watch Dave Beazley's PyCon 2014 talk for a good story involving one of those manufacturer installed Pythons: https://www.youtube.com/watch?v=RZ4Sn-Y7AP8 ___ 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 2.7.7. on Windows
On Mon, Apr 28, 2014 at 7:04 PM, Steve Dower wrote: >> Mike Miller wrote: >> On 04/29/2014 05:12 AM, Steve Dower wrote: >>> This would be an incredibly painful change that would surprise and >>> hurt a lot of people. >> >> Hi, I think "incredibly painful" is overstating the case a bit. ;) We're >> talking >> about an installer default, a setting that would still be changeable as it >> always has, that by definition only will affect brand new installs. > > Good point about it only affecting new installs, though that still > constitutes a lot of installs. > >>> Yes, it is possible for a non-admin user to install arbitrary packages >>> into a place where an admin user may inadvertently run it, thereby >>> providing escalation of privilege. On the other hand, that applies to >>> a lot of development tools, especially since most users on Windows >>> these days are actually limited administrators - ANYTHING they install >>> could run when they elevate a certain process. >> >> None of Microsoft's Dev tools install to C:\, rather to ProgramFiles. The >> fact >> that another security issue may exist is not a good justification for >> creating >> additional. > > The fact that the mitigations are well known by the people who have to worry > about them is a good justification for not creating a compatibility issue. > It's easy for IT admins to install Python in a way that the files are > read-only, the .pyc and .pyo files are already there, and user site packages > will be used by default (I think that last one is easy?). The good IT admins > even know that they need to do this - perhaps we can help educate the bad > admins? (FWIW, if you have admin privileges on your own machine, YOU are the > IT admin. Are you a good one or a bad one?) > >>> On the other hand, Python from python.org is a tool that should only >>> be installed by those who are prepared to manage it. On Windows it is >>> easy enough to have a second, secured copy for your admin scripts and >>> an unsecured copy for non-admin tasks. >> >> This sounds like the perspective of someone highly technical, forgetting that >> new users will be installing python as well and vastly outnumber us. "Normal >> people" need help to avoid security issues. > > One place where mitigations are added are the distributions (Canopy, > Anaconda, etc.). These packages redistribute Python and install to different > locations with different permissions (I'm not promising that they all do it > properly, but they have the opportunity to do so). The reference > implementation of CPython is typically not the best option for "normal > people", who are much better served by one of these bundles. > >> Microsoft's guidelines on where to install software are clear, and don't make >> exceptions that "tools" should be installed to the root of the drive to >> bypass >> file system permissions, for convenience. > > I'm well aware of the guidelines, hence the practicality vs. purity comment. > I'm fairly certain that the installation to the root was originally about > ease of command-line access rather than bypassing permissions - the > permissions probably didn't exist for the first few versions of Python > (Python for DOS obviously didn't care... maybe it's always been about > backwards compatibility?) > > At this point, installing into the root is about not breaking everyone who > *knows* that Python installs into the root directory and always has. > >>> I'm not sure what change you are proposing here... doesn't the >>> installer already have an option to add to PATH? I'm sure I keep disabling >>> it. >> >> No, it does not. Unless it got slipped in when I wasn't looking. >> >> It should be an option though, I think everyone would agree. > > Thanks Brett for pointing out that it arrived in Python 3. I'm sure it would > be an acceptable addition to 2.7.7, though you'd need to get it in before RC > and you'd also need to find someone who is keen and able to keep making 2.7 > installers for Windows. Right now, we don't have anyone who is both. If it's an acceptable change to the release manager (Benjamin?), and if there's actually time before the RC (I don't know when it is planned), I am willing to backport my 3.3 change to get this in the 2.7 installer. However, I'm not currently setup to make release installers -- I think I need a signing certificate or something like that. ___ 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] Tix version needed to build 2.7 Windows installer?
This is mostly a question for Martin, but perhaps someone else would also know. I'm trying to build the 2.7 installers so I can backport the path option from 3.3, but I can't seem to figure out which version of Tix is necessary to have a complete build. So far any of them on http://svn.python.org/projects/external don't appear to be configured to work with the combination of tcl and tk that are used on 2.7, per the buildbot external scripts. It's another issue that Tix isn't even downloaded by the scripts, but I'll do it manually right now just to get this going. Any tips? ___ 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] Tix version needed to build 2.7 Windows installer?
On Fri, May 9, 2014 at 12:00 PM, Zachary Ware wrote: > On Thu, May 8, 2014 at 4:20 PM, Zachary Ware > wrote: >> I updated the 2.7 buildbot scripts to pull in Tcl/Tk 8.5.15 a couple >> of weeks ago (see http://bugs.python.org/issue21303), but hadn't >> gotten anything done with Tix yet. It should just need python.mak >> updated to point to Tcl/Tk 8.5.15; it's on my list to get fixed as >> soon as I can. > > Tix for 2.7 is now > http://svn.python.org/projects/external/tix-8.4.3.5. You can build it > with this monster of a command, run from tix-8.4.3.5\win: > > nmake -f python.mak DEBUG=0 MACHINE=IX86 COMPILERFLAGS=-DWINVER=0x0500 > TCL_DIR=..\..\tcl-8.5.15.0 TK_DIR=..\..\tk-8.5.15.0 > INSTALL_DIR=..\..\tcltk all > > Use "install" instead of "all" after building to install it to > ..\..\tcltk. Set DEBUG and MACHINE as needed; DEBUG does not need to > be set if you're building Release, but MACHINE always has to be set so > that Tix uses the right build dir for Tk (IX86 for 32-bit, AMD64 for > 64-bit). Awesome, thanks! So I now have a fully working setup, at least for 32-bit, and have backported the Path option from 3.3 (http://hg.python.org/cpython/rev/a9d34685ec47). I ran into an issue with win32com getting a 64-bit installer built but didn't have time to look into it yet. If anyone wants to try a 2.7 installer with that Path option, here's a copy: http://briancurtin.com/python-dev/python-2.7.msi (this is not signed, it'll warn you about that). ___ 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] Questions regarding Windows buildbots
On Mon, May 12, 2014 at 5:16 PM, Claudiu Popa wrote: > Hello! > > I'm working on a patch for issue bugs.python.org/issue8579 (Add > missing tests for FlushKey, LoadKey, and SaveKey in winreg). This > issue requires the SeBackupPrivilege in order to use LoadKey and > SaveKey. While acquiring the privilege > isn't very complicated using ctypes, it fails with > ERROR_NOT_ALL_ASSIGNED (1300) when the > user has Administrative privileges, but it's not an Administrator, > problem which can be eluded by > running the script with elevated privileges. This leads me to a couple > of questions: > > - should a Windows test be skipped if it can't acquire a certain privilege? Yes. Check out any of the os.symlink tests - they're currently skipped when the symlink privilege isn't held. > - If we can acquire the privilege by elevating our process, does the > Windows buildbots have UAC > enabled and if so, how's the notification setting configured? For > instance, elevating a process will > trigger a new UAC window with the message "Do you want to allow the > following program from an unknown publisher to make changes to this > computer?" on the recommended configuration, but this doesn't happen > when the configuration is set to "Never notify". That probably depends on how each machine is setup. If they happen to get blocked on any individual slave, we'll just have to ask the owner to change that setting. Currently there are no Windows build slaves running as administrator. I used to have one but the machine died and I never replaced it. I also said a few months ago that I would get one setup again, but that hasn't happened yet. I can get a new machine up and running but probably not until next week as I'm at a conference. ___ 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] Download Counts (was: Language Summit notes)
On Fri, Apr 18, 2014 at 1:31 PM, Antoine Pitrou wrote: > I don't think we have recent download numbers since the Website > overhaul (do we?), but Python 3 isn't an "experimental concept > language" anymore (it hasn't been since 3.3 or 3.2, I'd say). Using the old logs, which are still good through 2013, I've found the following: The first year of a release series (month of final release month + 12mos): 2.6.x - 10.3 Million 2.7.x - 10.26M 3.2.x - 5.84M 3.3.x - 13.1M 2013 downloads (out of 34.79M across all possible versions): 2.6.x - 1.9M 2.7.x - 14.3M 3.2.x - 1.03M 3.3.x - 13.85M 3.3 had a big first year of availability (Oct '12-'13), and throughout 2013 it represented 48% of those versions listed above. ___ 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] Download Counts (was: Language Summit notes)
On May 28, 2014 12:49 PM, "Brian Curtin" wrote: > > On Fri, Apr 18, 2014 at 1:31 PM, Antoine Pitrou wrote: > > I don't think we have recent download numbers since the Website > > overhaul (do we?), but Python 3 isn't an "experimental concept > > language" anymore (it hasn't been since 3.3 or 3.2, I'd say). > > Using the old logs, which are still good through 2013, I've found the following: > > The first year of a release series (month of final release month + 12mos): > 2.6.x - 10.3 Million > 2.7.x - 10.26M > 3.2.x - 5.84M > 3.3.x - 13.1M > > 2013 downloads (out of 34.79M across all possible versions): > 2.6.x - 1.9M > 2.7.x - 14.3M > 3.2.x - 1.03M > 3.3.x - 13.85M > > 3.3 had a big first year of availability (Oct '12-'13), and throughout > 2013 it represented 48% of those versions listed above. Sorry for not being explicit: these are download counts for Windows installers. ___ 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] Download Counts (was: Language Summit notes)
On May 28, 2014 4:06 PM, "Eli Bendersky" wrote: > > > > > On Wed, May 28, 2014 at 11:10 AM, Guido van Rossum wrote: >> >> Is the Windows/Mac ratio still 70/30, with Linux in the single digits? >> > > Most Linux installs go through package managers which don't count here, no? I'll have to run something for the other non-Windows files, but the single digit Linux downloads he meant are the tarballs. We'll (probably) never know the true counts in the Linux world because of how pervasive Python is within basically every distro, but that's also likely the case on Mac. With Windows, since you must download Python it to use it, the numbers we see are probably the most useful on their own. I'm giving a talk at PyCon Russia that covers some of these numbers, so I'll probably try to dig up more and turn it into a blog post. ___ 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] Moving Python 3.5 on Windows to a new compiler
On Fri, Jun 6, 2014 at 8:22 PM, Zachary Ware wrote: > On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower > wrote: >> Thoughts/comments/concerns? > > My only concern is support for elderly versions of Windows, in > particular: XP. I seem to recall the last "let's update our MSVC > version" discussion dying off because of XP support. Even though MS > has abandoned it, I'm not sure whether we can yet. > > If that's a non-issue, or if we can actually drop XP support, I'm all for it. Extended support ended in April of this year, so I think we should put XP as unsupported for 3.5 in PEP 11 - http://legacy.python.org/dev/peps/pep-0011/ I seem to remember that we were waiting for this anyway. ___ 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] Moving Python 3.5 on Windows to a new compiler
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote: > On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower wrote: >> Chris Angelico wrote: >>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower >>> wrote: What this means for Python is that C extensions for Python 3.5 and later can be built using any version of MSVC from 14.0 and later. >>> >>> Oh, if only this had been available for 2.7!! Actually... this means that >>> 14.0 would be a good target for a compiler change for 2.7.x, if such a >>> change is ever acceptable. >> >> Maybe, but I doubt it will ever be acceptable :) > > Well, there were discussions. Since Python 2.7's support is far > exceeding the Microsoft promise of support for the compiler it was > built on, there's going to be a problem, one way or the other. I don't > know how that's going to end up being resolved. We're going to have to change it at some point, otherwise we're going to have people in 2018 scrambling to find VS2008, which will be 35 versions too old by then. No matter what we do here, we're going to have a tough PR situation, but we have to make something workable. I'd rather cause a hassle than outright kill extensions. I would probably prefer we aim for VS 14 for 3.5, and then explore making the same change for the 2.7.x release that comes after 3.5.0 comes out. Lessons learned and all that. ___ 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] Moving Python 3.5 on Windows to a new compiler
On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg wrote: > On 06.06.2014 20:25, Brian Curtin wrote: >> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote: >>> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower >>> wrote: >>>> Chris Angelico wrote: >>>>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower >>>>> wrote: >>>>>> What this means for Python is that C extensions for Python 3.5 and later >>>>>> can be built using any version of MSVC from 14.0 and later. >>>>> >>>>> Oh, if only this had been available for 2.7!! Actually... this means that >>>>> 14.0 would be a good target for a compiler change for 2.7.x, if such a >>>>> change is ever acceptable. >>>> >>>> Maybe, but I doubt it will ever be acceptable :) >>> >>> Well, there were discussions. Since Python 2.7's support is far >>> exceeding the Microsoft promise of support for the compiler it was >>> built on, there's going to be a problem, one way or the other. I don't >>> know how that's going to end up being resolved. >> >> We're going to have to change it at some point, otherwise we're going >> to have people in 2018 scrambling to find VS2008, which will be 35 >> versions too old by then. No matter what we do here, we're going to >> have a tough PR situation, but we have to make something workable. I'd >> rather cause a hassle than outright kill extensions. >> >> I would probably prefer we aim for VS 14 for 3.5, and then explore >> making the same change for the 2.7.x release that comes after 3.5.0 >> comes out. Lessons learned and all that. > > Are you sure that's an option ? Changing the compiler the stock > Python from python.org is built with will most likely render > existing Python extensions built for 2.7.x with x < (release that comes > after 3.5.0) broken, so users and installation tools will end up > having to pay close attention to the patch level version of Python > they are using... which is something we wanted to avoid after > we ran into this situation with 1.5.1 and 1.5.2 a few years ago. None of the options are particularly good, but yes, I think that's an option we have to consider. We're supporting 2.7.x for 6 more years on a compiler that is already 6 years old. Something less than awesome for everyone involved is going to have to happen to make that possible. ___ 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] Moving Python 3.5 on Windows to a new compiler
On Fri, Jun 6, 2014 at 10:56 PM, wrote: > On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote: > >> None of the options are particularly good, but yes, I think that's an >> option we have to consider. We're supporting 2.7.x for 6 more years on >> a compiler that is already 6 years old. > > Surely that is infinitely less desirable than simply bumping the minor > version? It's definitely not desirable, but "simply" bumping the minor version is not A Thing. ___ 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] Moving Python 3.5 on Windows to a new compiler
On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft wrote: > > On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote: > >> On Fri, Jun 6, 2014 at 10:56 PM, wrote: >>> On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote: >>> >>>> None of the options are particularly good, but yes, I think that's an >>>> option we have to consider. We're supporting 2.7.x for 6 more years on >>>> a compiler that is already 6 years old. >>> >>> Surely that is infinitely less desirable than simply bumping the minor >>> version? >> >> It's definitely not desirable, but "simply" bumping the minor version >> is not A Thing. > > Why? I mean even if it’s the same thing as 2.7 just with an updated > compiler that seems like a better answer than having to deal with > 2.7.whatever suddenly breaking all C exts. Because then we have to maintain 2.8 at a time when no one even wants to maintain 2.7? ___ 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] Moving Python 3.5 on Windows to a new compiler
On Fri, Jun 6, 2014 at 11:42 PM, wrote: > On Sat, Jun 07, 2014 at 05:33:45AM +1000, Chris Angelico wrote: > >> > Is it really any difference in maintenance if you just stop applying >> > updates to 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a >> > new compiler then there should be no functional difference between >> > doing that and doing a 2.7.whatever except all of the tooling that >> > relies on the compiler not to change in micro releases won’t >> > suddenly break and freak out. > >> If the only difference between 2.7 and 2.8 is the compiler used on >> Windows, what happens on Linux and other platforms? A Python 2.8 would >> have to be materially different from Python 2.7, not just binarily >> incompatible on one platform. > > Grrmph, that's fair. Perhaps a final alternative is simply continuing > the 2.7 series with a stale compiler, as a kind of carrot on a stick to > encourage users to upgrade? Gating 2.7 life on the natural decline of > its supported compiler/related ecosystem seems somehow quite a gradual > and natural demise.. :) Adding features into 3.x is already not enough of a carrot on the stick for many users. Intentionally leaving 2.7 on a dead compiler is like beating them with the stick. ___ 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] Moving Python 3.5 on Windows to a new compiler
On Jun 6, 2014 6:01 PM, "Sturla Molden" wrote: > > Brian Curtin wrote: > > > Adding features into 3.x is already not enough of a carrot on the > > stick for many users. Intentionally leaving 2.7 on a dead compiler is > > like beating them with the stick. > > Those who want to build extensions on Windows will just use MinGW > (currently GCC 2.8.2) instead. Well we're certainly not going to assume such a thing. I know people do that, but many don't (I never have). ___ 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] Moving Python 3.5 on Windows to a new compiler
On Jun 6, 2014 6:33 PM, "Sturla Molden" wrote: > > Brian Curtin wrote: > > > Well we're certainly not going to assume such a thing. I know people do > > that, but many don't (I never have). > > If Python 2.7 users are left with a dead compiler on Windows, they will > find a solution. For example, Enthought is already bundling their Python > distribution with gcc 2.8.1 on Windows. Again, not something I think we should depend on. A lot of people use python.org installers. ___ 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] subprocess shell=True on Windows doesn't escape ^ character
On Wed, Jun 11, 2014 at 9:43 PM, Ethan Furman wrote: > On 06/11/2014 07:12 PM, Chris Angelico wrote: >> >> On Thu, Jun 12, 2014 at 12:07 PM, Chris Angelico wrote: >>> >>> ISTM what you want is not shell=True, but a separate function that >>> follows the system policy for translating a command name into a >>> path-to-binary. That's something that, AFAIK, doesn't currently exist >>> in the Python 2 stdlib, but Python 3 has shutil.which(). If there's a >>> PyPI backport of that for Py2, you should be able to use that to >>> figure out the command name, and then avoid shell=False. >> >> >> Huh. Next time, Chris, search the web before you post. Via a >> StackOverflow post, learned about distutils.spawn.find_executable(). > > > --> import sys > --> sys.executable > '/usr/bin/python' For finding the Python executable, yes, but the discussion and example are about a 2.x version of shutil.which ___ 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] Helping with Documentation
On Mon, Oct 29, 2018 at 9:36 AM Kenneth Reitz wrote: > Hello all, > > > > I’d like to become a core contributor to Python, by contributing polish to > its documentation (adding missing pieces, modernize it a bit in spots, add > more usage examples (itertools), etc). > > > > Is anyone already working on this, and if so, can I join forces with you? > I don't know of any specific or active documentation focus right now (save for translation, which is mostly what doc-sig has been about lately), but giving the docs love has been on my todo list for quite a while now with tiny efforts here or there. Your general idea sounds good enough to just go for it and put up PRs. Feel free to add me as a reviewer—@briancurtin—and I'll help get things merged. ___ 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] Re: Steering Council update for February
On Tue, Mar 9, 2021 at 17:54 Chris Angelico wrote: > On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw > wrote: > > > > > Does 'master' confuse people? > > > > There's a general movement to replace language from common programming > practises that derive from, or are associated with, the dehumanization of > people. Such as master and slave, as well as whitelist and blacklist. > > > > Is that *actually* the origin of the term in this context, or is it > the "master", the pristine, the original from which copies are made? > There's no "slave" branch anywhere in the git repository. > > I detest these changes that create churn and don't actually solve any > problems. They allow people to feel good about themselves for having > "made a change", while actually making no useful change whatsoever > (are disadvantaged people's lives going to be improved by this > rename?). What next? Are we going to crack down on any courses that > proclaim to help you to "master the Python language"? Does that, too, > have to be renamed? What an unfortunate response, but feel free to find something else to do after the change has been made. > ___ 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/MH573FZ7NH4THZAF2LXHINIXFFRAFYAN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is the Python review process flawed?
On Tue, Jun 29, 2021 at 10:38 AM wrote: > I just stumbled upon the following issue and subsequent pull request. It > is a very small bugfix. There is currently a bug in Python and this pull > request fixes it. It's not a new feature or an enhancement, it is a bugfix! > Yet, it doesn't get reviewed, nor merged. And this has been going on since > March 2017. Why not just merge this? It's not like it's huge or obstructing > or obfuscating the current code base? There's always time to write an > improvement or a complete rewrite of this module feature later for an > upcoming minor release. But if there is currently a bug in Python and the > bugfix is available - why doesn't it get merged? > > https://github.com/python/cpython/pull/4819 For starters, the PR is closed in favor of another issue that has reviews and a discussion, but even the smallest change like that requires a lot out of a reviewer. Looking at that change, I don't personally know that it's correct, so I'd have to take the time to figure out that it's correct. It includes no tests, so I certainly don't trust that it's correct, so it looks incomplete to me. Time is irrelevant here—there's no need to rush things because a change appears small. What if that one line change is even more wrong than before? I have merge access and if I just said "ah it's a small PR and it's been open for a while, I'll just merge it for them," any change to Python has the possibility to affect a huge amount of people. When I got the shutil.which feature merged, the PR had been open for I believe 11 years and it was mostly complete in the initial patch outside of a few small issues, and the change itself wasn't a lot of code. To just have merged it because it was open for 11 years would have been the wrong thing to do. It needed to cover some things it didn't initially cover, it needed tests and documentation, and it wasn't merged until it was completed and properly reviewed. If this doesn't get fixed, doesn't that mean the Python review process is > flawed? Sure, Python is an open source project and many people just work in > their free time. But this doesn't really apply here, does it? The bugfix is > available. Only a review is required. All this is happening while new > features get added to Python with every new minor version. While the bug is > allowed to live there. Please help me understand how this can happen. > "Only a review is required" is vastly understating the value of code reviews. Almost anybody can write a one line fix, but is it the right fix? Does it cover all of the cases it needs to? Is adding "manager_owned=False" correct or should something else actually be done? Who knows and is available to understand the impacts of this change? So does this mean the review process is flawed? I would say no, the _review process_ is maybe working as expected—the linked PR was incomplete and wasn't merged, another PR has come up, and there's discussion on it including a comment about tests and one about familiarizing with the code. The process of finding humans who are willing and able to do this work—currently for free—is possibly broken, possibly working as expected, and overall is a significantly harder problem to fix than most anything involved with open source software. I love Python. No hard feelings. But this is really bugging me and I can't > help but feel disappointed. > The good thing is that you paid nothing for this, so being disappointed is something you can fix. If you would like more value out of it or to speed up the process, you can provide your own reviews. Reviewing code is immensely valuable and helps so many people—the core developers, the users, and yourself. Alternatively, paying people to do the reviews is also possible. ___ > 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/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/ > 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/5PYTF4BEKS3H2AZX6ZQXKIQM5SYTOH7H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Stale PR
Before looking at the code, my first question would be about the description: "I kinda ran out of time, i suspect more testing is due." If you were out of time then it's probably not done and maybe lacks the tests you initially thought it did, so did you find the time and/or is the PR done? On Tue, Jul 6, 2021 at 10:07 AM Yair Frid wrote: > Hello, a few months ago i created this PR: > https://github.com/python/cpython/pull/24181 > Which has since gone stale, I would really like it to be reviewed before i > continue fixing other issues as i do not want to have to deal with a > backlog of PRs > Thanks in advance, Yair. > ___ > 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/TYZH5DQJUBRMEPAR5N2I5VDGHNG7Y6SU/ > 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/PQSY3JH7VVAWUMFAODZ3KAIXQFPP4VVB/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Built with VS2012 Express for desktop
On Tue, Feb 19, 2013 at 12:37 PM, rahul garg wrote: > Hi. > > I downloaded Python 3.3 source, opened up the solution in VS2012 Express for > Desktop and built the "python" subproject using "Release" and "x64" > configurations. I now have a "python.exe" in the PCBuild/amd64 subfolder > that appears to be working as far as i can see. > > I have a few questions: > a) Is there a test suite that I can run to verify that the build is working > fine? Last I checked there are some issues, but most of the tests should pass. You would run "PCBuild\python.exe -m test" from the top level of your checkout to see this. It's also covered at http://docs.python.org/devguide/ > b) I now intend to build some extensions (such as NumPy). Not sure if this > is the right list, but would I need to modify something in distutils to get > it working with VS2012? Yes. You'll probably need to point distutils to the correct batch file that sets up a VS2012 build environment. ___ 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] Python Language Summit at PyCon: Agenda
On Wed, Feb 27, 2013 at 10:51 AM, Michael Foord wrote: > Hello all, > > PyCon, and the Python Language Summit, is nearly upon us. We have a good > number of people confirmed to attend. If you are intending to come to the > language summit but haven't let me know please do so. > > The agenda of topics for discussion so far includes the following: > > * A report on pypy status - Maciej and Armin > * Jython and IronPython status reports - Dino / Frank > * Packaging (Doug Hellmann and Monty Taylor at least) > * Cleaning up interpreter initialisation (both in hopes of finding areas > to rationalise and hence speed things up, as well as making things > more embedding friendly). Nick Coghlan > * Adding new async capabilities to the standard library (Guido) > * cffi and the standard library - Maciej > * flufl.enum and the standard library - Barry Warsaw > * The argument clinic - Larry Hastings > > If you have other items you'd like to discuss please let me know and I can > add them to the agenda. I'll take detailed notes again this year. Within a few days of the end of the conference I'll post a write-up to blog.python.org and this list to keep everyone informed. ___ 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] Introducing Electronic Contributor Agreements
The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose. ___ 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] Introducing Electronic Contributor Agreements
On Mon, Mar 4, 2013 at 11:02 AM, Skip Montanaro wrote: > > > On Mon, Mar 4, 2013 at 10:30 AM, Brian Curtin wrote: >> >> The full announcement is at >> http://blog.python.org/2013/03/introducing-electronic-contributor.html, >> but a summary follows. >> ... > > > Brian, > > Do you want old-timers like me who have a wet-signed fax gathering dust in a > box at PSF World Headquarters to execute the electronic contributor > agreement? While not strictly necessary, I suspect it might be nice for you > to have all agreements in a common form. I'll check on that, but I don't think it's necessary since the gathered data is no different. ___ 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] VC++ 2008 Express Edition now locked away?
On Wed, Mar 6, 2013 at 10:55 AM, Chris Angelico wrote: > Is there any plan for future Python versions to use a free compiler on > Windows? That would eliminate this issue, but presumably would create > others. No plan, although there are at times patches/issues floating around to add some level of support for MinGW (or something like it) in addition to Microsoft's compiler. ___ 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 in the stdlib
On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel wrote: > That would be a blow to educators, but also Windows users: while the CLI > works very nicely in unices, that's not the case with the win32 console > which is as best as I can describe it a complete turd, making IDLE a > very nice proposition there (I never use IDLE on Linux or OSX, but do > all the time in Windows). Can you explain this a bit more? I've been using the CLI python.exe on Windows, Mac, and Linux for years and I don't know what you're talking about. ___ 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] Google Summer of Code - Organization Deadline Approaching - March 29
Just an FYI that there are under 3 days to apply to Google Summer of Code for mentoring organizations: http://www.google-melange.com/gsoc/homepage/google/gsoc2013. The student application deadline is later on in May. If you run a project that is interested in applying under the Python umbrella organization, contact Terri Oda at te...@zone12.com Is anyone here interested in leading CPython through GSOC? Anyone have potential students to get involved, or interested in being a mentor? ___ 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] Destructors and Closing of File Objects
On Fri, Apr 12, 2013 at 12:04 AM, Nikolaus Rath wrote: > [ Note: I already asked this on > http://stackoverflow.com/questions/15917502 but didn't get any > satisfactory answers] Sorry, but that's not a reason to repost your question to this list. If you have to ask somewhere else, it would be python-list, aka, comp.lang.python. ___ 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] I cannot create bug reports
On Wed, Apr 24, 2013 at 1:55 PM, Daniel Wong wrote: > Thank you. That was the problem. > > I feel kind of stupid now. In my defense, the error message could have been > more helpful, and requesting the bug creation form could have thrown up a > login error instead of showing up blank. File another bug? Bugs about the bug tracker go to http://psf.upfronthosting.co.za/roundup/meta/ ___ 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] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong
On Fri, May 3, 2013 at 3:23 PM, Paul Moore wrote: > I would propose that the behaviour of the launcher on Windows should be > changed when it encounters specifically the hashbang line #!/usr/bin/env > python. In that case, it should search PATH for a copy of python.exe, and if > it finds one, use that. If there is no python.exe on PATH, it should fall > back to the same version of Python as would have been used if the line were > #!/usr/bin/python. > > This will mean that scripts written with #!/usr/bin/env python will behave > the same on Unix and Windows in the presence of activated virtualenvs. > > Would people be happy with this change? If so I will open an issue on > bugs.python.org. I can look at producing a patch, as well. Sounds reasonable to me. ___ 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] Any script to create the installation pacakge of Python 3.3.1 on Windows and *NIX?
On Wed, May 8, 2013 at 7:37 PM, Jianfeng Mao wrote: > To Python-Dev committers: > > > > I am working on a project to embed a slightly customized Python interpreter > in our own software. For easy installation and setup, we want to be able to > do the standard Python installation as part of the installation of our > product. So far I have successfully customized and built Python 3.3.1 > (including the subprojects) on Windows but I can’t find anything in the > source distribution to allow me package the binaries/modules etc into a MSI > just like the one on the download page on python.org. So I am asking for > information regarding how to package Python build for installation on both > Windows and *NIX platforms. Your help will be greatly appreciated. See Tools/msi/msi.py for the Windows MSI builder. ___ 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] make a Windows installation package (.msi) for Python 3.3
On Fri, May 10, 2013 at 12:31 PM, Jianfeng Mao wrote: > To Python Windows Release Managers: > > > > My name is Jianfeng Mao and I am a software developer at the U2 group in > Rocket Software (http://u2.rocketsoftware.com/). I am currently working on > a project to embed a slightly customized Python interpreter in our product. > For easy installation and setup, we hope to be able to do the standard > Python installation during the installation of our software. Basically I > want to create a .msi file that can be called to install the full Python if > the user needs this new feature. Brian Curtin (br...@python.org) pointed me > to Tools/msi/msi.py for the Windows MSI builder. I tried to follow the > instructions in the README but couldn’t make it to work after a few twists > and turns. Brian mentioned that few people needs to do this and only > release managers handle the packaging of Python. I have listed the steps I > have done in my attempt to create the .msi file. Please let me know if I > have missed anything or done anything wrong. > > > > > > 1. hg clone http://hg.python.org/cpython > > 2. cd cpython > > 3. hg update 3.3 > > 4. cd tools\buildbot, edit build.bat to change the configuration from > Debug to Releaes; edit external.bat, change DEBUG=1 to DEBUG=0 > > 5. go back to cpython\ and run tools\buildbot\build.bat > > 6. cd PC, then do ‘nmake –f icons.mak’ > > 7. cd ..\tools\msi > > 8. c:\python27\python msi.py > > > > WARNING: nm did not run successfully - libpythonXX.a not built > > cl /O2 /D WIN32 /D NDEBUG /D _WINDOWS /MT /W3 /c msisupport.c > > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for > 80x86 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > msisupport.c > > link.exe /OUT:msisupport.dll /INCREMENTAL:NO /NOLOGO /DLL > /SUBSYSTEM:WIN > > DOWS /OPT:REF /OPT:ICF msisupport.obj msi.lib kernel32.lib > >Creating library msisupport.lib and object msisupport.exp > > Traceback (most recent call last): > > File "msi.py", line 1336, in > > add_files(db) > > File "msi.py", line 961, in add_files > > generate_license() > > File "msi.py", line 914, in generate_license > > raise ValueError, "Could not find "+srcdir+"/../"+pat > > ValueError: Could not find C:\temp\cpython/../tcl8* I'm in an airport and on a Mac right now so I can't test it, but IIRC you just need to adjust the script to look for tcl-8* and not tcl8* on line 908 of msi.py. You'll probably have to do the same for tk. If you come across other exceptions about tcl, tk, or other dependencies, it's likely that the paths are just incorrect. There may be a patch for this on bugs.python.org because I know I've gone through it. ___ 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] First post
On Tue, May 14, 2013 at 10:22 AM, Carlos Nepomuceno wrote: > Hi guys! This is my first post on this list. > > I'd like have your opinion on how to safely implement WSGI on a production > server. > > My benchmarks show no performance differences between our PHP and Python > environments. I'm using mod_wsgi v3.4 with Apache 2.4. > > Is that ok or can it get faster? > > Thanks in advance. Hi - this list is about the development of Python. For user questions, python-list is a better place to ask this. ___ 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] 2.7.5 baking
On Wed, May 15, 2013 at 1:07 PM, Georg Brandl wrote: > Am 15.05.2013 09:55, schrieb M.-A. Lemburg: >> On 12.05.2013 06:03, Benjamin Peterson wrote: >>> The long anticipated "emergency" 2.7.5 release has now been tagged. It >>> will be publicly announced as binaries arrive. >>> >>> Originally, I was just going to cherrypick regression fixes onto the >>> 2.7.4 release and release those as 2.7.5. I started to this but ran >>> into some conflicts. Since we don't have buildbot testing of release >>> branches, I decided it would be best to just cut from the maintenance >>> branch. >> >> Has the release been postponed ? >> >> I don't see it on http://www.python.org/download/ >> >> Incidentally, the schedule already lists 2.7.5 as released on >> 2013-05-12 (http://www.python.org/dev/peps/pep-0373/) and >> the release calendar on 2013-05-11: >> https://www.google.com/calendar/feeds/b6v58qvojllt0i6ql654r1v...@group.calendar.google.com/public/basic?orderby=starttime&sortorder=descending >> :-) >> > > We're still waiting for the Windows binaries. > > I think I will publish the source and Mac releases on the website now > and make a note that Windows is coming shortly. I'm going to get started building the MSIs this evening. I'm looking into how I can obtain a code signing certificate, otherwise we'd potentially be shipping unsigned security releases...*ducks* > Has anybody heard from Martin recently? I hope he's well and just > overworked... I asked some folks on the infrastructure team and the last they heard from him was 11 April. ___ 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] Dash
On Jul 18, 2013 1:46 PM, "Serhiy Storchaka" wrote: > > 18.07.13 20:48, Guido van Rossum написав(ла): > >> I believe there are only a few places where en-dashes should be used, >> for most things you should use either em-dash or hyphen. Consult your >> trusted typography source (for US English, please, punctuation >> preferences vary by locale). E.g. Google for "em dash en dash". > > > Currently Python documentation in most cases uses en-dashes. Should we replace them to em-dashes? Should we remove spaces around dashes? > > Or we should replace a half-dozen of em-dashes found in Python documentation to en-dashes? > > I believe all hypens used in place of dash should be replaced to dash (but to en- or em- dash?) in any case. Besides visual consistency in a couple of places, is there a reason to care enough to make a wholesale change? ___ 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] Building a Faster Python
On Sun, Jul 21, 2013 at 6:46 PM, Ben Hoyt wrote: >> PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. > > That's very cool -- a significant improvement. Is this the kind of change > that could go into 2.7.6 binaries? > > As a Windows user, it makes me wonder if compiling with the latest version > of the Microsoft compiler would improve things similarly? (Though updating > project files to that is almost certainly a bigger project than the gcc > update.) I think I have a 3.3 build on VS2012 somewhere - maybe I'll refresh it for default/3.4 and run the same benchmarks on it. The changes couldn't go into 2.7 as far as I'm aware, at least when it comes to changing Visual Studio versions. ___ 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] [Python-checkins] cpython: Fix #18530. Remove extra stat call from posixpath.ismount
On Mon, Jul 22, 2013 at 6:36 PM, Victor Stinner wrote: > Could you please keep the comment "# A symlink can never be a mount point" ? > It is useful. (I didn't know that, I'm not a windows developer.) I don't think that's specific to Windows, but I added it back in d6213012d87b. ___ 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] Python 3 as a Default in Linux Distros
On Wed, Jul 24, 2013 at 10:56 AM, Lennart Regebro wrote: > On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro wrote: >> On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote: >>> - Should we point /usr/bin/python to Python 3 when we make the move? >> >> No. > > To be more explicit. I think it's perfectly fine to not provide a > /usr/bin/python at all, but I think pointing it to Python 3 will > provide unhelpful error messages. -1. For one example, this is going to add non-productive and potentially confusing steps before any educator can use Python to teach anything. ___ 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] Official github mirror for CPython?
On Thu, Jul 25, 2013 at 9:37 AM, Christian Heimes wrote: > Am 25.07.2013 16:29, schrieb Eli Bendersky: >> Hi all, >> >> I've been looking for a Github mirror for Python, and found two: >> >> * https://github.com/python-git/python has a lot of forks/watches/starts >> but seems to be very out of date (last updated 4 years ago) >> * https://github.com/python-mirror/python doesn't appear to be very >> popular but is updated daily >> >> Are some of you the owners of these repositories? Should we consolidate >> to a single "semi-official" mirror? > > +1 > > Does the PSF have an official account on github? We have one on bitbucket... I don't remember who runs this, and I thought I was in it (maybe just on BB), but: https://github.com/python ___ 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] PEP 8 modernisation
On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy wrote: > On 8/1/2013 11:03 AM, Alexander Shorin wrote: >> >> ...and, if so, why lambda's?(: Without backward compatibility point I >> see that they are getting "unofficially" deprecated and their usage is >> dishonoured. > > > Please stop both the top-posting and the FUD. Top posting doesn't matter. The end. ___ 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] PEP 8 modernisation
On Thu, Aug 1, 2013 at 3:44 PM, Brian Curtin wrote: > On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy wrote: >> On 8/1/2013 11:03 AM, Alexander Shorin wrote: >>> >>> ...and, if so, why lambda's?(: Without backward compatibility point I >>> see that they are getting "unofficially" deprecated and their usage is >>> dishonoured. >> >> >> Please stop both the top-posting and the FUD. > > Top posting doesn't matter. > > The end. Actually, quick expansion on this before moving along: if you're going to call someone out for top posting, you can't ignore the many high profile people who do it every time and single out the newcomer. That's why I said something. Sorry for the OT. ___ 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] when to fix cross-version bugs?
On Fri, Sep 6, 2013 at 9:51 AM, Ethan Furman wrote: > I recently committed a fix for unicodeobject.c so that the %d, %i, and %u > format specifiers always output values (otherwise, in subclasses, the str() > was used instead). > > Should this be fixed in 3.3 as well? > > What guidelines determine when a bug is fixed in previous versions? If it's a bug in that version and the version is accepting bug fixes, i.e., not in security mode, go for it. This includes crossing the 2/3 boundary if applicable. ___ 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] Support for marking limited API elements in C API docs
On Sat, Oct 12, 2013 at 3:17 PM, Serhiy Storchaka wrote:
> 12.10.13 22:56, Antoine Pitrou написав(ла):
>
>> On Sat, 12 Oct 2013 21:19:16 +0200
>> Georg Brandl wrote:
>>>
>>> Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
12.10.13 21:04, Georg Brandl написав(ла):
>
> in light of the recent thread about PEPs not forming part of the docs,
> I've just pushed a change that allows to document C API elements
> not part of the limited API as such. It is done like this:
>
> ... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
> :notlimited:
>
> I have not yet begun adding these to the documents; if someone wants to
> help with this I am glad for volunteers.
Why this is needed? The limited API is unstable and only developers of
CPython can use it (but they can look in headers).
>>>
>>>
>>> Well, I may be reading PEP 384 wrongly, but the point is exactly to have
>>> a
>>> *stable* API for *non-core* developers to rely upon, so that they can
>>> build
>>> extensions that don't need to be recompiled for every version of Python.
>>
>>
>> This is true.
>>
>> However, I find the proposed markup not very enlightening :-)
>> I would prefer if "limited" APIs where marked with a :stableabi: tag.
>>
>> ("limited API" is really a bad synonym for "stable ABI" IMO)
>
>
> Why not limited private API should be documented at all besides sources?
Code is not documentation.
___
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] Top python roles
There are a lot more than "guys" on this list, and it's for the development of the Python language, not for recruiting. Please take this elsewhere. On Fri, Feb 3, 2017 at 20:10 Marta Daglow wrote: > Hi Guys, > > > > How are you guys? > > > > I’ve just gotten off the phone with a top engineering leader from a > wonderful company in SF and they are looking for someone with python > expertise. > > > > They are looking to hire many people in the range of $100 – 160K. > > > > Warm Regards, > > > > Marta > ___ > 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/brian%40python.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
Re: [Python-Dev] Exact date of Python 2 EOL?
On Thu, Mar 23, 2017 at 12:19 PM, Barry Warsaw wrote: > On Mar 23, 2017, at 09:41 AM, Victor Stinner wrote: > >>Can we pick an official date? > > Benjamin should pick the date and update PEP 373. Not to start a bikeshed (calendarshed?), but how about 8 February 2020, or 2/8 as some in the US would write it? ___ 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 553: Built-in debug()
On Wed, Sep 6, 2017 at 10:46 AM, Guido van Rossum wrote: > IIRC they indeed insinuate debug() into the builtins. My suggestion is > also breakpoint(). > I'm also a bigger fan of the `breakpoint` name. `debug` as a name is already pretty widely used, plus breakpoint is more specific in naming what's actually going to happen. sys.breakpoint_hook() and sys.__breakpoint_hook__ seem reasonable ___ 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] Re: Increase of Spammy PRs and PR reviews
On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann wrote: > On 1/30/22 04:45, Inada Naoki wrote: > > On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel > wrote: > > > Some people may do "approval without review" to make their "Profile" > > page richer, because GitHub counts it as a contribution. > > Creating spam issues or pull requests can be reported as spam very > > easily. But "approve without review" is hard to be reported as spam. > > So approving random issue is the most easy way to earn contributions > > without reported as spam. > > Whnever there are metrics, some will find a way to game the system to > make theirs look better - this certainly isn't limited to github, or to > tech, or in any way a recent thing. > Certainly true, and I think this is more of a social problem than a technical one. If people are giving out review approvals to get more points, you (where 'you' is a person with some privileges on the repo) can click "dismiss review" and get rid of the noise, at least within that PR. Maybe they still get points for the review, I'm not sure. Taking away the ability for non-core contributors to offer official review approvals to stop people like that only harms the people actually trying to do good work. Gaming the system doesn't end up working well in the end anyway. The first time the gamers try to get a job interview and can't explain how they'd do a code review—something GitHub says they've done hundreds or thousands of times—the whole thing will fail. ___ 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/R3YU44XPWLBUWVLSYTTTWJZCSRRCB67F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
I was using points in a more generic sense, making your "contribution activity overview" look nicer—I wasn't sure if "points" was an actual thing or not, so maybe I'm speaking out of turn. Mine shows 70% of my actions are code review, then issues, commits, and PRs are 10% each. On Mon, Jan 31, 2022 at 9:40 AM Guido van Rossum wrote: > Where does it say that a review gives you points? The GitHub blog post I > saw about the subject only mentions commits. > > On Mon, Jan 31, 2022 at 8:16 AM Brian Curtin wrote: > >> On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann wrote: >> >>> On 1/30/22 04:45, Inada Naoki wrote: >>> > On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel < >>> iritkatr...@googlemail.com> wrote: >>> >>> > Some people may do "approval without review" to make their "Profile" >>> > page richer, because GitHub counts it as a contribution. >>> > Creating spam issues or pull requests can be reported as spam very >>> > easily. But "approve without review" is hard to be reported as spam. >>> > So approving random issue is the most easy way to earn contributions >>> > without reported as spam. >>> >>> Whnever there are metrics, some will find a way to game the system to >>> make theirs look better - this certainly isn't limited to github, or to >>> tech, or in any way a recent thing. >>> >> >> Certainly true, and I think this is more of a social problem than a >> technical one. If people are giving out review approvals to get more >> points, you (where 'you' is a person with some privileges on the repo) can >> click "dismiss review" and get rid of the noise, at least within that PR. >> Maybe they still get points for the review, I'm not sure. Taking away the >> ability for non-core contributors to offer official review approvals to >> stop people like that only harms the people actually trying to do good work. >> >> Gaming the system doesn't end up working well in the end anyway. The >> first time the gamers try to get a job interview and can't explain how >> they'd do a code review—something GitHub says they've done hundreds or >> thousands of times—the whole thing will fail. >> ___ >> 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/R3YU44XPWLBUWVLSYTTTWJZCSRRCB67F/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > ___ 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/3Q7GEGI7JOCAEA7VNK7NVDSX2I43LFWD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] Python 2.7.18, the end of an era
On Tue, Apr 21, 2020 at 7:31 AM Larry Hastings wrote: > On 4/20/20 8:06 AM, Benjamin Peterson wrote: > > I'm eudaemonic to announce the immediate availability of Python 2.7.18. [...] > Over all those years, CPython's core developers and contributors sedulously > applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3 > branches diverged. > > > I'm glad you're enjoying your new thesaurus! > I'm glad he was able to keep up the ebullience so long. He was jocund about 2.7.0rc2 around this time ten years ago. ___ 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/JWYWGC7CO7FZP7KVGZO3VHLCTBRGCUWP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion
Hey Team, Has this workgroup started yet? If not, can I help get it going, or if so, is there a mailing list or place where things are happening? Brian Curtin On Sun, Aug 9, 2020 at 12:58 Carol Willing wrote: > Hi folks, > > Thanks for the interest. I apologize for the delay in getting this > workgroup started. I'm happy that there is strong interest in working on > documentation and improving it for all users. > > I will do my best to get the workgroup charter drafted this week and then > open an interest list for initial workgroup members. > > Luciano, I agree that rewriting asyncio docs and typing are helpful > improvements and welcome your contributions to accessible and high quality > docs. > > Warmly, > > Carol > > On Sun, Aug 9, 2020 at 9:21 AM Luciano Ramalho > wrote: > >> I am also interested in helping with making Python's documentation >> more user friendly. >> >> Yuri Selivanov's rewrite of the asyncio documentation was brilliant. >> We need more of that. >> >> My recent contribution to Python's doc doesn't compare with >> Selivanov's awesome rewrite, but it involved reorganizing existing >> documentation. >> >> The typing module chapter in the library reference is comprehensive, >> and the top 1/3 of it has good narrative explanations to the core >> concepts. But the remaining 2/3 of the content is in a single section >> titled "Classes, functions, and decorators" that covers more than 70 >> objects, and there's no apparent ordering. >> >> With the help of Guido, I split that section in subsections, and >> arranged the entries within the subsections by relevance to most >> users—subjective, yes, but not too harmful if we made bad calls, >> because now there are fewer entries per subsection. >> >> Before: >> https://docs.python.org/3.8/library/typing.html >> >> After: >> https://docs.python.org/3.10/library/typing.html >> >> Cheers, >> >> Luciano >> >> On Sun, Aug 9, 2020 at 12:43 PM Mats Wichmann wrote: >> > >> > On 8/5/20 10:43 AM, Dominic Davis-Foster wrote: >> > > Hi Carol, >> > > >> > > I was wondering if you've been able to set up the workgroup yet? I'd >> certainly be interested in participating the there's an opportunity. >> > > >> > > >> > > Stay safe >> > > >> > > Dom >> > >> > Indeed, I was wondering if there were any updates - I'm also interested >> > in participating. >> > >> > -- mats >> > ___ >> > 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/MRV5SQCC2GC6MLIUCSPJZL3AQCXVDUEG/ >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> >> -- >> 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/P6S4Q3H6VOXVJTXX4UCRRYDCIDLC2M4C/ >> 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/ZTIK4R7HNPV2HZJ6TJHONGCCYUOSL5CW/ > 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/MCGGPWD5C66IG3ITL2SOROYW62CQTKBJ/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Suggestion: new 3 release with backwards compatibility
On Tue, Jan 5, 2010 at 10:10, Juan Fernando Herrera J. wrote: > How about a new python 3 release with (possibly partial) backwards > compatibility with 2.6? I'm a big 3 fan, but I'm dismayed at the way major > software hasn't been ported to it. I'm eager to use 3, but paradoxically, > the 3 release makes me rather stuck with 2.6. Excuse me if this has been > suggested in the past. > > The proper route to take, in my opinion, is to see what 2.x libraries you are using that are not 3.x compatible, run 2to3 on them, then run their test suite, and see where you get. Submit a patch or two to the library and see what happens -- it at least gets the wheels in motion. I'm sure everyone out there would like to dive into supporting 3.x, but it's tough to prioritize when you are up to your eyeballs with 2.x bugs in your tracker. Look at Twisted ( http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-the-migration-to-python-3) -- over 1000 issues, ~5 developers -- 3.x support won't be here tomorrow, but it's on the horizon. ___ 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] bug triage
On Wed, Jan 6, 2010 at 06:57, Nick Coghlan wrote: > I believe someone (Daniel Diniz, maybe?) did do a pass over those some > time in the last 12 months, so most of the obviously irrelevant ones > that are that old should already be gone. Not to say it isn't worth > doing another pass, just saying not to get disheartened if there aren't > many that can be readily closed. > > There are at least a few still kicking around just because they're > difficult to deal with (there's an ancient one to do with one of the > ways circular imports can fail that I occasionally go back and reread > before moving on to something more tractable). > > Cheers, > Nick. > On the topic of bugs that can be readily closed (literally), I've recently come across a number of issues which appear to be sitting in a patch or review stage, but their patches have been committed and the issue remains open. What is the best course of action there? I'd just go ahead and close the issue myself but I don't have tracker privileges. I'm willing to help out with another Daniel Diniz-esque triage sweep if that would help. Brian ___ 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] bug triage
On Wed, Jan 6, 2010 at 19:28, Brett Cannon wrote: > > > On Wed, Jan 6, 2010 at 17:22, R. David Murray wrote: > >> >> On Wed, 06 Jan 2010 11:03:32 -0800, Brett Cannon wrote: >> > On Wed, Jan 6, 2010 at 06:57, Brian Curtin >> wrote: >> > > On the topic of bugs that can be readily closed (literally), I've >> recently >> > > come across a number of issues which appear to be sitting in a patch >> or >> > > review stage, but their patches have been committed and the issue >> remains >> > > open. What is the best course of action there? I'd just go ahead and >> close >> > > the issue myself but I don't have tracker privileges. >> > > >> > > >> > If a core developer is willing to step forward and vouch for you to get >> > tracker privileges then I will give them to you. We are trying to give >> out >> > tracker privs w/ less time than required to get commit privileges. So as >> > long as you have helped out on a few issues in a positive and correct >> way >> > that should be enough to get one of the regulars who perform triage to >> > notice. >> > >> > -Brett >> >> I've done a quick scan of issues Brian is nosy on to refresh my >> memory, and I'd say he's definitely been making positive contributions. >> I'm willing to volunteer to keep an eye on his triage work for a while >> if you grant him tracker privs. >> >> > Done for the username brian.curtin (email doesn't match the one Brian > emailed from so do let me know, Brian if this is the right username). > Welcome aboard! > > Yep, that's the one. Thanks! ___ 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] topics I plan to discuss at the language summit
On Sun, Jan 10, 2010 at 14:25, Brett Cannon wrote: > * any changes needed to the issue tracker to help with the workflow? (stage > field seems like a failed experiment and we now have several effective > triage people who can help w/ guiding changes) > > -Brett > I think it would be interesting to see how people are using the tracker, or how they want to be using it. For example, there are currently over 1500 open issues with no stage set, some of which seemingly haven't been read by anyone at all. Would a properly set stage field save issues from falling into a black hole? Food for thought: according to the last tracker summary, there are over 1000 open issues with a patch, and issues stay open an average of 700 days (median 450). Brian ___ 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] topics I plan to discuss at the language summit
On Tue, Jan 12, 2010 at 04:20, Antoine Pitrou wrote: > Le Mon, 11 Jan 2010 19:57:46 -0600, Brian Curtin a écrit : > > > > For example, there are currently over > > 1500 open issues with no stage set, some of which seemingly haven't been > > read by anyone at all. > > I think most issues /have/ been read. It's just that for many of them, > nobody is interested enough in or feels competent enough for fixing them. > > > Would a properly set stage field save issues from > > falling into a black hole? > > I don't think this has anything to do with properly setting the stage > field. We just have limited time and manpower. Perhaps one of our goals > should be to reach out more to potential contributors. Agreed, I didn't mean to place blame on the stage field, I just ran with how I view that field since it was mentioned. When I'm thinking in "code-writing developer mode" (tm), I'm more likely to go to issues which have a stage so I know what I'm going into -- what needs to be worked on. When I'm in project cleanup mode, I go by stageless issues -- what is necessary for this to begin or end work. Maybe others work differently...software projects take all kinds :-) Anyways, sorry for the off-topic. If this is a summit worthy discussion, cool. ___ 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] Bazaar branches available (again) on Launchpad
On Tue, Jan 19, 2010 at 21:43, David Lyon wrote: > > Being honest, if wonderful libraries like Sphinx and Mercurial > and Git and BZR can't make it into the stdlib, then there is > no hope for even newer code to get in there. > I'm not entirely sure I see why the inclusion of a SCM into the stdlib is necessary. Just because pieces of software are mature and proven in their fields doesn't mean we should add them, or that them *not* being in the stdlib should be a basis for other projects making it in. ___ 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] Python 2.6.5
On Tue, Feb 9, 2010 at 06:45, anatoly techtonik wrote: > On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou > wrote: > > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : > >> > >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this > >> one - http://bugs.python.org/issue6608 Is it ok to release new > versions > >> that are known to crash? > > > > I've changed this issue to release blocker. What are the other issues? > > I've basically run a query to get all "crash" type issues for Python 2.6 > > http://bugs.python.org/iss...@search_text=&title=&@columns=title&id=&@columns=id&stage=&creation=&creator=&activity=&@columns=activity&@sort=activity&actor=&nosy=&type=1&components=&versions=1&dependencies=&assignee=&keywords=&priority=&@group=priority&status=1&@columns=status&resolution=&nosy_count=&message_count=&@pagesize=50&@startwith=0&@queryname=&@old-queryname=&@action=search > > There are 65 entries and among them I can additionally confirm: > http://bugs.python.org/issue3720 > http://bugs.python.org/issue7788 > http://bugs.python.org/issue5765 > > -- > anatoly t. > > After taking a quick look, at least 14 of them were misreported as crashes. ___ 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] setUpClass and setUpModule in unittest
On Tue, Feb 9, 2010 at 12:29, Olemis Lang wrote: > On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord > wrote: > > I'm pretty sure I can introduce setUpClass and setUpModule without > breaking > > compatibility with existing unittest extensions or backwards > compatibility > > issues > > Is it possible to use the names `BeforeClass` and `AfterClass` (just > to be make it look similar to JUnit naming conventions ;o) ? > -- > Regards, > > Olemis. > -1. setUp/tearDown is already well established here so I think it should follow the same convention. ___ 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] deprecated stuff in standard library
On Fri, Feb 19, 2010 at 08:40, Sjoerd Mullender wrote: > On 2010-02-19 14:10, Guido van Rossum wrote: > > Isn't mhlib itself deprecated? (It's gone in Py3k.) > > I wouldn't like that, but it is beside my point. If a module is > deprecated, then it should not be used in released code. > If mhlib is deprecated, it doesn't tell you about it. mhlib uses > multifile and multifile does tell you it is deprecated, and that is > pretty annoying. > > I see the deprecation warning upon importing mhlib in 2.6 and trunk (with -Wd). ___ 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] contributor to committer
On Wed, Feb 24, 2010 at 18:48, Antoine Pitrou wrote: > Le Wed, 24 Feb 2010 12:13:10 +, Florent Xicluna a écrit : > > Hello, > > > > I am a semi-regular contributor for Python: I have contributed many > > patches since end of last year, some of them were reviewed by Antoine. > > Semi-regular is quite humble. You have been cranking out patches at a > higher frequency than almost any of us in the last 3 months. We are > exhausted of reviewing and (most of the time) committing your patches :) > (fortunately, your work happens to be of consistently good quality) > > Regards > > Antoine. > > Sometimes it seems like half of the tracker updates are Florent's. Semi-regular is quite the understatement. ___ 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] argparse ugliness
On Fri, Mar 5, 2010 at 12:51, Neal Becker wrote:
> I generally enjoy argparse, but one thing I find rather
> ugly and unpythonic.
>
>parser.add_argument ('--plot', action='store_true')
>
> Specifying the argument 'action' as a string is IMO ugly.
>
What else would you propose?
FWIW, this is the same in optparse.
___
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] Tracker reviews workflow and flags
On Fri, Mar 19, 2010 at 03:09, anatoly techtonik wrote: > I want to push some of my patches before 2.7 and use 5-1 rule for > that, but I can't come up with any review workflow other than mailing > status of my comments to the issues here. I can't mark issues in any > way. How about giving users ability to set flags or keywords? Maybe > entering a separate field like "Review status"? > We already have "Patch Review" as a stage, and "needs review" as a flag, which I feel is more than enough. If you don't have the privileges to modify an issue, you can always comment on the issue with something like "can this issue be set to the patch review stage?" Someone will probably take a look at it and set it accordingly. Real world example with issue8151. It is an issue with a trivial patch > in it. Everything what is needed is to dispatch it to stable `commit > queue` and port to trunk. It is not 'easy' - it is 'trivial', but I > have no means to mark it as 'easy' either, so even this trivial fix > lies in tracker for three days waiting for review. > Given that we have hundreds of issues with patches waiting for review, three days isn't so bad :) As with any project, there are only so many people and so much time to get the work done. > About 'easy' flag: > "6 easyThis is an easy task (e.g. suitable for GHOP or bug day > beginners)" > It seems that it is for the issue that requires a patch, but if the > patch is already there and nobody wants to commit it - what should I > do? > Post a comment on the issue asking what the status is. If an approved patch has been sitting for a few weeks, make a comment. If it has been there for a few days, I'd let it slide but keep it on your radar. > > Finally, review queue proposal. > To follow 5-1 rule, I need to review 5 issues, before mine is > reviewed, so I need some help from tracker. > 1. I lack expertise in certain areas (C/C++, Mac OS, etc.), so I would > like to hide some issues under "Needs review" query, so they won't > bother me (if too many people marked issues in this way - the stats > may become a good reason for highly professional bug party) > There already exists a component field which has Macintosh as an option, so you could filter on that. Same goes for Windows. Drilling down to the language(s) involved in the issue feels like just another step that would get limited use. I do see what you are saying, though, because I'm sure it's frustrating to want to look out there for a nice pure-Python issue, then the first 10 issues you click on require C code (or vice versa). > 2. I need ability to set "Needs review" flag back. Some issues were > once reviewed, but since then they've got modified and need further > comments. The need the review again. That means pushed back _into the > end_ of patch queue. > I don't think the "needs review" flag gets unset, but if it has been unset manually and you've made changes, you can ask for another review. If you can get the changes made quickly, you might be able to get the previous reviewer to look at it again while it's still fresh in their mind. > 3. Setting bug dependency by users. Often nobody wants to care about > issue, because it is just too long, there is much irrelevant comments > and nobody has time to read it. We don't have personal digg-like > comment filters to cope with the amount of text to be brain-loaded. > But it is possible to refactor such issue thread into separate > digestable issue/issues. > > > P.S. About personal comment filters if anybody is interested in that. > Digg-like +1, -1 are good for voting, but for filtering it would be > nice to: 1. have several filters for different aspects of the thread, > 2. have JS filter by marking individual phrases in comments and adding > ranges to filter using jquery / ajax > > This way reviews will be more fun and easy. > -- > anatoly t. > I think that would take away from the goal of fixing the issue. Even some -1 comments could contain helpful information, but you might have to explicitly click on that hidden comment to find out. ___ 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] Tracker opened/closed issue list: missing?
On Sat, Mar 20, 2010 at 11:02, Terry Reedy wrote: > I did not receive the usual Friday tracker post on issues opened and closed > during the past week. > Did anyone else? > I am reading via gmane. > > Terry Jan Reedy > I actually haven't seen that mail in a few weeks (subscribed to the list via my gmail account). ___ 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
