Re: [Python-Dev] Surely "nullable" is a reasonable name?
Hi! On Mon, Aug 04, 2014 at 05:12:47PM +1000, Larry Hastings wrote: > "nullable=True", which means "also accept None > for this parameter". This was originally intended for use with > strings (compare the "s" and "z" format units for PyArg_ParseTuple), > however it looks like we'll have a use for "nullable ints" in the > ongoing Argument Clinic conversion work. > > Several people have said they found the name "nullable" surprising, > suggesting I use another name like "allow_none" or "noneable". I, > in turn, find their surprise surprising; "nullable" is a term long > associated with exactly this concept. It's used in C# and SQL, and > the term even has its own Wikipedia page: > > http://en.wikipedia.org/wiki/Nullable_type In my very humble opinion, "nullable" is ok, but "allow_none" is better. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] https:bugs.python.org -- Untrusted Connection (Firefox)
On Mon, Aug 18, 2014 at 04:12:22PM -0400, Terry Reedy wrote:
> Firefox does not want to connect to https:bugs.python.org.
Works for me (FF 31).
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] https:bugs.python.org -- Untrusted Connection (Firefox)
On Mon, Aug 18, 2014 at 03:26:48PM -0500, Ian Cordasco wrote: > On Mon, Aug 18, 2014 at 3:22 PM, Benjamin Peterson > wrote: > > It uses a CACert certificate, which your system probably doesn't trust. > > > > On Mon, Aug 18, 2014, at 13:12, Terry Reedy wrote: > >> Firefox does not want to connect to https:bugs.python.org. Plain > >> bugs.python.org works fine. Has the certificate expired? > > Benjamin that looks accurate. I see the same thing as Terry (on > Firefox 31) and the reason is: > > bugs.python.org uses an invalid security certificate. The certificate > is not trusted because no issuer chain was provided. (Error code: > sec_error_unknown_issuer) Aha, I see now -- the signing certificate is CAcert, which I've installed manually. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
Hi! On Thu, Aug 21, 2014 at 02:52:19PM +1000, Cameron Simpson wrote: > Oh, and I reject Nick's characterisation of POSIX as "broken". It's > perfectly internally consistent. It just doesn't match what he > wants. (Indeed, what I want, and I'm a long time UNIX fanboy.) > > Cheers, > Cameron Simpson +1 from another Unix fanboy. Like an old wine, Unix becomes better with years! ;-) Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Thu, Aug 21, 2014 at 05:00:02PM -0700, Glenn Linderman wrote: > On 8/21/2014 3:42 PM, Paul Moore wrote: > >I wonder how badly a Unix system would break if you specified UTF16 as > >the system encoding...? > > Does Unix even support UTF-16 as an encoding? As an encoding of file's content? Certainly yes. As a locale encoding? Definitely no. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Thu, Aug 21, 2014 at 05:30:14PM -0700, Chris Barker - NOAA Federal wrote: > This brings up the other key problem. If file names are (almost) > arbitrary bytes, how do you write one to/read one from a text file > with a particular encoding? ( or for that matter display it on a > terminal) There is no such thing as an encoding of text files. So we just write those bytes to the file or output them to the terminal. I often do that. My filesystems are full of files with names and content in at least 3 different encodings - koi8-r, utf-8 and cp1251. So I open a terminal with koi8 or utf-8 locale and fonts and some file always look weird. But however weird they are it's possible to work with them. The bigger problem is line feeds. A filename with linefeeds can be put to a text file, but cannot be read back. So one has to transform such names. Usually s/\\//g and s/\n/\\n/g is enough. (-: > And people still want to say posix isn't broken in this regard? Not at all! And broken or not broken it's what I (for many different reasons) prefer to use for my desktops, servers, notebooks, routers and smartphones, so if Python would stand on my way I'd rather switch to a different tools. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
Hi! On Sat, Aug 23, 2014 at 01:19:14AM +1000, Steven D'Aprano wrote: > On Fri, Aug 22, 2014 at 04:42:29AM +0200, Oleg Broytman wrote: > > On Thu, Aug 21, 2014 at 05:30:14PM -0700, Chris Barker - NOAA Federal > > wrote: > > > This brings up the other key problem. If file names are (almost) > > > arbitrary bytes, how do you write one to/read one from a text file > > > with a particular encoding? ( or for that matter display it on a > > > terminal) > > > >There is no such thing as an encoding of text files. > > I don't understand this comment. It seems to me that *text* files have > to have an encoding, otherwise you can't interpret the contents as text. What encoding does have a text file (an HTML, to be precise) with text in utf-8, ads in cp1251 (ad blocks were included from different files) and comments in koi8-r? Well, I must admit the HTML was rather an exception, but having a text file with some strange characters (binary strings, or paragraphs in different encodings) is not that exceptional. > Files, of course, only contain bytes, but to be treated as bytes you > need some way of transforming byte N to char C (or multiple bytes to C), > which is an encoding. But you don't need to treat the entire file in one encoding. Strange characters are clearly visible so you can interpret them differently. I am very much trained to distinguish koi8, cp1251 and utf-8 texts; I cannot translate them mentally but I can recognize them. > Perhaps you just mean that encodings are not recorded in the text file > itself? Yes, that too. > To answer Chris' question, you typically cannot include arbitrary > bytes in text files, and displaying them to the user is likewise > problematic As a person who view utf-8 files in koi8 fonts (and vice versa) every day I'd argue. (-: Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Fri, Aug 22, 2014 at 09:37:13AM -0700, Glenn Linderman wrote: > On 8/22/2014 8:51 AM, Oleg Broytman wrote: > >What encoding does have a text file (an HTML, to be precise) with > >text in utf-8, ads in cp1251 (ad blocks were included from different > >files) and comments in koi8-r? > >Well, I must admit the HTML was rather an exception, but having a > >text file with some strange characters (binary strings, or paragraphs > >in different encodings) is not that exceptional. > That's not a text file. That's a binary file containing (hopefully > delimited, and documented) sections of encoded text in different > encodings. Allow me to disagree. For me, this is a text file which I can (and do) view with a pager, edit with a text editor, list on a console, search with grep and so on. If it is not a text file by strict Python3 standards then these standards are too strict for me. Either I find a simple workaround in Python3 to work with such texts or find a different tool. I cannot avoid such files because my reality is much more complex than strict text/binary dichotomy in Python3. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Fri, Aug 22, 2014 at 10:09:21AM -0700, Glenn Linderman
wrote:
> On 8/22/2014 9:52 AM, Oleg Broytman wrote:
> >On Fri, Aug 22, 2014 at 09:37:13AM -0700, Glenn Linderman
> > wrote:
> >>On 8/22/2014 8:51 AM, Oleg Broytman wrote:
> >>>What encoding does have a text file (an HTML, to be precise) with
> >>>text in utf-8, ads in cp1251 (ad blocks were included from different
> >>>files) and comments in koi8-r?
> >>>Well, I must admit the HTML was rather an exception, but having a
> >>>text file with some strange characters (binary strings, or paragraphs
> >>>in different encodings) is not that exceptional.
> >>That's not a text file. That's a binary file containing (hopefully
> >>delimited, and documented) sections of encoded text in different
> >>encodings.
> >Allow me to disagree. For me, this is a text file which I can (and
> >do) view with a pager, edit with a text editor, list on a console,
> >search with grep and so on. If it is not a text file by strict Python3
> >standards then these standards are too strict for me. Either I find a
> >simple workaround in Python3 to work with such texts or find a different
> >tool. I cannot avoid such files because my reality is much more complex
> >than strict text/binary dichotomy in Python3.
>
> I was not declaring your file not to be a "text file" from any
> definition obtained from Python3 documentation, just from a common
> sense definition of "text file".
And in my opinion those files are perfect text. The files consist of
lines separated by EOL characters (not necessary EOL characters of my OS
because it could be a text file produced in a different OS), lines
consist of words and words of characters.
> Looking at it from Python3, though, it is clear that when opening a
> file in "text" mode, an encoding may be specified or will be
> assumed. That is one encoding, applying to the whole file, not 3
> encodings, with declarations on when to switch between them. So I
> think, in general, Python3 assumes or defines a definition of text
> file that matches my "common sense" definition.
I don't have problems with Python3 text. I have problems with Python3
trying to get rid of byte strings and treating bytes as strict non-text.
> On the other hand, Python3 provides various facilities for working
> with such files.
>
> The first I'll mention is the one that follows from my description
> of what your file really is: Python3 allows opening files in binary
> mode, and then decoding various sections of it using whatever
> encoding you like, using the bytes.decode() operation on various
> sections of the file. Determination of which sections are in which
> encodings is beyond the scope of this description of the technique,
> and is application dependent.
This is perhaps the most promising approach. If I can open a text
file in binary mode, iterate it line by line, split every line of
non-ascii bytes with .split() and process them that'd satisfy my needs.
But still there are dragons. If I read a filename from such file I
read it as bytes, not str, so I can only use low-level APIs to
manipulate with those filenames. Pity.
Let see a perfectly normal situation I am quite often in. A person
sent me a directory full of MP3 files. The transport doesn't matter; it
could be FTP, or rsync, or a zip file sent by email, or bittorrent. What
matters is that filenames and content are in alien encodings. Most often
it's cp1251 (the encoding used in Russian Windows) but can be koi8 or
utf8. There is a playlist among the files -- a text file that lists MP3
files, every file on a single line; usually with full paths
("C:\Audio\some.mp3").
Now I want to read filenames from the file and process the filenames
(strip paths) and files (verify existing of files, or renumber the files
or extract ID3 tags [Russian ID3 tags, whatever ID3 standard says, are
also in cp1251 of utf-8 encoding]...whatever). I don't know the encoding
of the playlist but I know it corresponds to the encoding of filenames
so I can expect those files exist on my filesystem; they have strangely
looking unreadable names but they exist.
Just a small example of why I do want to process filenames from a
text file in an alien encoding. Without knowing the encoding in advance.
> The second is to specify an error handler, that, like you, is
> trained to recognize the other encodings and convert them
> appropriately. I'm not aware that such an error handler has been or
> could be written, myself not having your training.
>
> The third is to specify the UTF-8 with the surrogate escape error
> handler. This allows non-UTF-8 codes to be loaded into memory
Re: [Python-Dev] Bytes path support
On Fri, Aug 22, 2014 at 01:17:44PM -0700, Glenn Linderman wrote: > >in cp1251 of utf-8 encoding > > "cp1251 of utf-8 encoding" is non-sensical. Either it is cp1251 or > it is utf-8, but it is not both. Maybe you meant "or" instead of > "of". But of course! Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Fri, Aug 22, 2014 at 11:53:01AM -0700, Chris Barker wrote: > Back in the day, paths were "just strings", and that worked OK with > py2 strings, because you could put arbitrary bytes in them. But the "py2 > strings were perfect" folks seem to not acknowledge that while they are > nice for matching the posix filename model, they were a pain in the neck > when you needed to do somethign else like write them in to a JSON file or > something. This is the core of the problem. Python2 favors Unix model but Windows people pays the price. Python3 reverses that and I'm still thinking if I want to pay the new price. > So will using a surrogate-escape error handling with pathlib make all this > just work? I'm involved in developing and maintaining a few big commercial projects that will hardly be ported to Python3. So I'm stuck with Python2 for many years and I haven't tried Python3. May be I should try a small personal project, but certainly not this year. May be the next one... Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Sat, Aug 23, 2014 at 07:04:20AM +1000, Chris Angelico wrote: > On Sat, Aug 23, 2014 at 6:17 AM, Glenn Linderman > wrote: > > "cp1251 of utf-8 encoding" is non-sensical. Either it is cp1251 or it is > > utf-8, but it is not both. Maybe you meant "or" instead of "of". > > I'd assume "or" meant there, rather than "of", it's a common typo. > > Not sure why 1251, specifically This is the encoding of Russian Windows. Files and emails in Russia are mostly in cp1251 encoding; something like 60-70%, I think. The second popular encoding is cp866 (Russian DOS); it's used by Windows as OEM encoding. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Sat, Aug 23, 2014 at 06:02:06PM +0900, "Stephen J. Turnbull" wrote: > And that's the big problem with Oleg's complaint, too. It's not at > all clear what he wants The first thing is I want to understand why people continue to refer to Unix was as "broken". Better yet, to persuade them it's not. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
On Sat, Aug 23, 2014 at 07:14:47PM +0900, "Stephen J. Turnbull" wrote: > I cannot believe you are going to find a better environment for > dealing with these issues than Python 3. Well, that's may be. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
Hi! On Sat, Aug 23, 2014 at 06:40:37PM +0100, Paul Moore wrote: > On 23 August 2014 16:15, Oleg Broytman wrote: > > On Sat, Aug 23, 2014 at 06:02:06PM +0900, "Stephen J. Turnbull" > > wrote: > >> And that's the big problem with Oleg's complaint, too. It's not at > >> all clear what he wants > > > >The first thing is I want to understand why people continue to refer > > to Unix was as "broken". Better yet, to persuade them it's not. "Unix was" => "Unix way" > Generally, it seems to be mostly a reaction to the repeated claims > that Python, or Windows, or whatever, is "broken". Ah, if that's the only problem I certainly can live with that. My problem is that it *seems* this anti-Unix attitude infiltrates Python core development. I very much hope I'm wrong and it really isn't. > Unix advocates (not > yourself) are prone to declaring anything *other* than the Unix model > as "broken", so it's tempting to give them a taste of their own > medicine. Sorry for that (to the extent that I was one of the people > doing so). You didn't see me in my younger years. I surely was one of those Windows bashers. Please take my apology. > Rhetoric aside, none of Unix, Windows or Python are "broken". They > just react in different ways to fundamentally difficult edge cases. > > But expecting Python (a cross-platform language) to prefer the Unix > model is putting all the pain on non-Unix users of Python, which I > don't feel is reasonable. Let's all compromise a little. > > Paul > > PS The key thing *I* think is a problem with the Unix behaviour is > that it treats filenames as bytes rather than Unicode. People name > files using *characters*. So every filename is semantically text, in > the mind of the person who created it. Unix enforces a transformation > to bytes, but does not retain the encoding of those bytes. So > information about the original author's intent is lost. But that's a > historical fact, baked into Unix at a low level. Whether that's > "broken" or just "something to deal with" is not important to me. The problem is hardly specific to Unix. Despite Joel Spolsky's "There Ain't No Such Thing As Plain Text" people create text files all the time. Without specifying an encoding. And put filenames into those text files (audio playlists, like .m3u and .pls are just text files with pathnames). Unix takes the idea that everything is text and a stream of bytes to its extreme. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Bytes path support
Hi! Thank you very much, Nick, for long and detailed explanation! On Sun, Aug 24, 2014 at 01:27:55PM +1000, Nick Coghlan wrote: > On 24 August 2014 04:37, Oleg Broytman wrote: > > On Sat, Aug 23, 2014 at 06:40:37PM +0100, Paul Moore > > wrote: > >> Generally, it seems to be mostly a reaction to the repeated claims > >> that Python, or Windows, or whatever, is "broken". > > > >Ah, if that's the only problem I certainly can live with that. My > > problem is that it *seems* this anti-Unix attitude infiltrates Python > > core development. I very much hope I'm wrong and it really isn't. > > The POSIX locale based approach to handling encodings is genuinely > broken - it's almost as broken as code pages are on Windows. The > fundamental flaw is that locales encourage *bilingual* computing: > handling English plus one other language correctly. Given a global > internet, bilingual computing *is a fundamentally broken approach*. We > need multilingual computing (any human language, all the time), and > that means Unicode. > > As some examples of where bilingual computing breaks down: > > * My NFS client and server may have different locale settings > * My FTP client and server may have different locale settings > * My SSH client and server may have different locale settings > * I save a file locally and send it to someone with a different locale setting > * I attempt to access a Windows share from a Linux client (or vice-versa) > * I clone my POSIX hosted git or Mercurial repository on a Windows client > * I have to connect my Linux client to a Windows Active Directory > domain (or vice-versa) > * I have to interoperate between native code and JVM code > > The entire computing industry is currently struggling with this > monolingual (ASCII/Extended ASCII/EBCDIC/etc) -> bilingual (locale > encoding/code pages) -> multilingual (Unicode) transition. It's been > going on for decades, and it's still going to be quite some time > before we're done. > > The POSIX world is slowly clawing its way towards a multilingual model > that actually works: UTF-8 > Windows (including the CLR) and the JVM adopted a different > multilingual model, but still one that actually works: UTF-16-LE > > POSIX is hampered by legacy ASCII defaults in various subsystems (most > notably the default locale) and the assumption that system metadata is > "just bytes" (an assumption that breaks down as soon as you have to > hand that metadata over to another machine that may have different > locale settings) > Windows is hampered by the fact they kept the old 8-bit APIs around > for backwards compatibility purposes, so applications using those APIs > are still only bilingual (at best) rather than multilingual. > JVM and CLR applications will at least handle the Basic Multilingual > Plane (UCS-2) correctly, but may not correctly handle code points > beyond the 16-bit boundary (this is the "Python narrow builds don't > handle Unicode correctly" problem that was resolved for Python 3.3+ by > PEP 393) > > Individual users (including some organisations) may have the luxury of > saying "well, all my clients and all my servers are POSIX, so I don't > care about interoperability with other platforms". As the providers of > a cross-platform runtime environment, we don't have that luxury - we > need to figure out how to get *all* the major platforms playing nice > with each other, regardless of whether they chose UTF-8 or UTF-16-LE > as the basis for their approach towards providing multilingual > computing environments. > > Historically, that question of cross platform interoperability for > open source software has been handled in a few different ways: > > * Don't really interoperate with anybody, reinvent all the wheels (the JVM > way) > * Emulate POSIX on Windows (the Cygwin/MinGW way) > * Let the application developer figure it out (the Python 2 way) > > The first approach is inordinately expensive - it took the resources > of Sun in its heyday to make it possible, and it effectively locks the > JVM out of certain kinds of computing (e.g. it's hard to do array > oriented programming in JVM languages, because the CPU and GPU > vectorisation features aren't readily accessible). > > The second approach prevents the creation of truly native Windows > applications, which makes it uncompelling as a way of attracting > Windows users - it sends a clear signal that the project doesn't > *really* care about supporting Windows as a platform, but instead only > grudgingly accepts that there are Windows users out there that might > like to use their s
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
Hi! On Mon, Sep 01, 2014 at 08:32:27PM -0500, Skip Montanaro wrote: > I got the same in Chrome on my Mac. > > Skip > On Sep 1, 2014 8:00 PM, "John Wong" wrote: > > > As of today I still am getting untrusted cert thought I would re-ping to > > see if there is an ETA. The signing certificate is still CAcert. One can install their root certificate from http://www.cacert.org/index.php?id=3 Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] https:bugs.python.org -- Untrusted Connection (Firefox)
On Tue, Sep 02, 2014 at 04:14:25PM -0400, Terry Reedy wrote: > On 9/2/2014 1:49 AM, Oleg Broytman wrote: > >On Mon, Sep 01, 2014 at 08:32:27PM -0500, Skip Montanaro > > wrote: > >>I got the same in Chrome on my Mac. > >> > >>Skip > >>On Sep 1, 2014 8:00 PM, "John Wong" wrote: > >> > >>>As of today I still am getting untrusted cert thought I would re-ping to > >>>see if there is an ETA. > > > >The signing certificate is still CAcert. One can install their root > >certificate from http://www.cacert.org/index.php?id=3 > > This seems not to work for Firefox. "Windows installer package for > browsers that use the Windows certificate store (for example > Internet Explorer, Chrome on Windows and Safari on Windows)" > > I installed it anyway, closed and reopened Firefox (but not > rebooted) and https://bugs.python.org still gives Untrusted message. Did you install it in the Firefox own certificate manager? http://wiki.cacert.org/FAQ/BrowserClients#Mozilla_Firefox "Firefox uses it's own Certificate Manager. So even if your Windows (and other Microsoft) applications already use a root certificate Firefox still might not." Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] https://docs.python.org/3/using/index.html not linking correctly
Hi! On Mon, Oct 20, 2014 at 04:01:02PM -0400, Terry Reedy wrote: > If I go to https://docs.python.org/3/using/index.html and click on > any of the TOC entries, I get 'connecting' indefinitely. This > problem seems unique to this file. I tried several other index files > and clicking am entry brings up the corresponding page almost > immediately. > > -- > Terry Jan Reedy Works for me. I clicked "2. Using Python on Unix platforms" and got to https://docs.python.org/3/using/unix.html without any problem. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] https://docs.python.org/3/using/index.html not linking correctly
On Tue, Oct 21, 2014 at 12:29:45AM +0100, MRAB wrote: > On 2014-10-21 00:09, Eli Bendersky wrote: > > > >On Mon, Oct 20, 2014 at 1:01 PM, Terry Reedy ><mailto:tjre...@udel.edu>> wrote: > > > >If I go to https://docs.python.org/3/using/index.html and click on > >any of the TOC entries, I get 'connecting' indefinitely. This > >problem seems unique to this file. I tried several other index files > >and clicking am entry brings up the corresponding page almost > >immediately. > > > >Works fine for me, Terry, in both Chrome and Firefox. Could be something > >in your browser/caching? Try "private mode" or whatever that's called in > >your browser of choice. > > > Just tried the first link: > > https://docs.python.org/3/using/cmdline.html > > I also get 'Connecting' indefinitely. > > So I tested the link here: > > http://www.downforeveryoneorjustme.com/ > > It said: "It's not just you! http://https looks down from here." I think this is a limitation of isup.me: it doesn't like https:// URLs -- either use http:// or no protocol prefix at all. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 481 - Migrate Some Supporting Repositories to Git and Github
Hi! On Mon, Dec 01, 2014 at 10:42:16AM -0600, Wes Turner wrote: > Here's a roundup of tools links, to make sure we're all on the same page: Very nice! > Is there an issue ticket or a wiki page that supports > Markdown/ReStructuredText, > where I could put this? Which URI do we assign to this artifact? There are already pages https://wiki.python.org/moin/Git and https://wiki.python.org/moin/Mercurial . You can create an additional page and reference it on that pages. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, Dec 01, 2014 at 03:52:21PM -0500, Terry Reedy wrote: > On 12/1/2014 11:42 AM, Wes Turner wrote: > >Is there an issue ticket or a wiki page that supports > > https://wiki.python.org/moin/ > > >Markdown/ReStructuredText, > > whoops, I am not sure what moin uses. Let's see... https://wiki.python.org/moin/?action=raw Seems like reST. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Google search labels Python 2.7 docs as Python 3.4
On Thu, Jan 01, 2015 at 01:49:52AM -0600, Wes Turner wrote: > Might one or more sitemap.xml files be useful here, if theoretically > unnecessary? > > * https://github.com/vladris/tinkerer-contrib/blob/master/sitemap/sitemap.py > * https://en.wikipedia.org/wiki/Sitemaps I'd rather recommend http://goog-sitemapgen.sourceforge.net/ Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Unicode literals in Python 2.7
On Wed, Apr 29, 2015 at 09:40:43AM -0700, Guido van Rossum wrote: > I suspect the interactive session is *not* always in UTF8. It probably > depends on the keyboard mapping of your terminal emulator. I imagine in > Windows it's the current code page. Even worse: in w32 it can be an OEM codepage. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] No tags in semi-official github mirror of cpython repository.
Hi! On Sat, May 16, 2015 at 11:45:38AM +0900, INADA Naoki wrote: > I foud "semi official github mirror" of cpython. > https://github.com/python/cpython > > I want to use it as upstream of our project (Translating docs in Japanese). > But it doesn't have tags. > > Is the repository stable enough for forking project like us? Or should we > use mercurial? > Could you mirror tags too? If you prefer to use git for development instead of mercurial, like I do, you can try some hg-to-git gateways. I tried hg-fast-export and git-remote-hg and found the latter to be much better. See https://github.com/felipec/git-remote-hg and https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives > Thanks > -- > INADA Naoki Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 559 - built-in noop()
On Sat, Sep 09, 2017 at 02:33:18PM -0700, Victor Stinner wrote: > I was able to find a real keyboard, so here is a more complete code: > --- > class Noop: > def __call__(self, *args, **kw): > return self > def __enter__(self, *args, **kw): > return self > def __exit__(self, *args): > return > def __repr__(self): > return 'nope' > --- > > Example: > --- > noop = Noop() > print(noop) > print(noop()) > with noop() as nope: > print(nope) > with noop as well: > print(well) > --- > > Output: > --- > nope > nope > nope > nope > --- > > IHMO the real question is if we need a Noop.nope() method? Yep. It must return self so one can chain as many calls as she wants. > Victor Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Scrapy Question
Hello. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Fri, Oct 13, 2017 at 08:28:29PM +0530, Kishore Kumar Alajangi wrote: > Hi Experts, > > Could someone guide me how to use the code in below question(Link). > https://stackoverflow.com/questions/46711909/extract-urls-recursively-from-website-archives-in-scrapy > > Thanks, > KK. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 561: Distributing and Packaging Type Information
Hi! On Thu, Oct 26, 2017 at 03:42:19PM -0700, Ethan Smith wrote: > Post-History: Not sure if postings to python-ideas count, but Post-History: 10-Sep-2017, 12-Sep-2017, 26-Oct-2017 Refs: https://mail.python.org/pipermail/python-ideas/2017-September/047015.html https://mail.python.org/pipermail/python-ideas/2017-September/047083.html > This PEP adds a new item to the > ``*.distinfo/METADATA`` file *.dist-info/ Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 561: Distributing and Packaging Type Information
On Thu, Oct 26, 2017 at 04:48:23PM -0700, Mariatta Wijaya wrote: > > > > Not sure if postings to python-ideas count, > > PEP 1 says: > > Post-History is used to record the dates of when new versions of the PEP > are posted to python-list and/or python-dev. That's was added in 2003: https://hg.python.org/peps/annotate/96614829c145/pep-0001.txt https://github.com/python/peps/commit/0a690292ffe2cdc547dbad3bdbdb46672012b536 I don't remember if python-ideas has already been created. ;-) > So, no ? I'm not so sure. :-) > Mariatta Wijaya Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 561: Distributing and Packaging Type Information
Proposed pull request: https://github.com/python/peps/pull/441 On Thu, Oct 26, 2017 at 05:21:57PM -0700, Mariatta Wijaya wrote: > Ok I created an issue https://github.com/python/peps/issues/440, maybe > someone can work on updating the wordings in PEP 1 and PEP 12. > Thanks :) > > Mariatta Wijaya > > On Thu, Oct 26, 2017 at 5:03 PM, Guido van Rossum > wrote: > > > I think python-ideas does count here. Many PEPs evolve mostly there. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Convert Sqlite Function from cx_Oracle
Hello.
This mailing list is to work on developing Python (adding new
features to Python itself and fixing bugs); if you're having problems
learning, understanding or using Python, please find another forum.
Probably python-list/comp.lang.python mailing list/news group is the
best place; there are Python developers who participate in it; you may
get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.
On Mon, Oct 30, 2017 at 05:41:20PM -0200, Carlos Eugenio
wrote:
> ==
> SQLITE3 Function
>
> def get_db():
> def dict_factory(cursor, row):
> d = {}
> for idx, col in enumerate(cursor.description):
> d[col[0]] = row[idx]
> return d
>
> db = getattr(g, '_database', None)
> if db is None:
> db = g._database = sqlite3.connect(DATABASE)
> db.row_factory = dict_factory
> return db
>
>
> I try this form but isnt ok . Can I help me ?
>
>
> import cx_Oracle
> con = cx_Oracle.connect('/@xxx/xxx')
>
> cur = con.cursor()
> cur.execute("select * from test")
>
> desc = [d[0] for d in cur.description]
>
> result = [dict(zip(dec,line))for line in cur]
>
> print (result)
>
> cur.close()
>
> --
> Carlos Eug??nio
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Proposal: go back to enabling DeprecationWarning by default
On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov wrote: > Big +1 from me. The whole point of DeprecationWarnings is to be > visible The whole point of DeprecationWarnings is to be visible to developers while in reality they will be visible to users -- and what the users would do with the warnings? > Yury Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Deprecate PEP 370 Per user site-packages directory?
Hi! On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes wrote: > Hi, > > PEP 370 [1] was my first PEP that got accepted. I created it exactly one > decade and two days ago for Python 2.6 and 3.0. Back then we didn't have > virtual environment support in Python. Ian Bicking had just started to > create the virtualenv project a couple of months earlier. > > Fast forward 10 years... > > Nowadays Python has venv in the standard library. The user-specific > site-packages directory is no longer that useful. Can I disagree? > I would even say it's > causing more trouble than it's worth. For example it's common for system > script to use "#!/usr/bin/python3" shebang without -s or -I option. System scripts are run under user root which seldom has user-specific site-packages so why worry? > I propose to deprecate the feature and remove it in Python 4.0. > > Regards, > Christian > > [1] https://www.python.org/dev/peps/pep-0370/ Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Deprecate PEP 370 Per user site-packages directory?
On Sat, Jan 13, 2018 at 07:18:41PM +0100, Christian Heimes wrote: > On 2018-01-13 19:04, Random832 wrote: > > On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote: > >> Hi, > >> > >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one > >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have > >> virtual environment support in Python. Ian Bicking had just started to > >> create the virtualenv project a couple of months earlier. > >> > >> Fast forward 10 years... > >> > >> Nowadays Python has venv in the standard library. The user-specific > >> site-packages directory is no longer that useful. I would even say it's > >> causing more trouble than it's worth. For example it's common for system > >> script to use "#!/usr/bin/python3" shebang without -s or -I option. > >> > >> I propose to deprecate the feature and remove it in Python 4.0. > > > > Where would pip install --user put packages, and how would one run scripts > > that require those packages? Right now these things Just Work; I've never > > had to learn how to use virtual environments. > > I see two option: > > 1) "pip install --user" is no longer supported. You have to learn how to > use virtual envs. It's really easy: "python3 -m venv path; path/bin/pip > install package". I've learned virtual envs and use them every day. I also use ``pip install --user``. Different use cases. Virtual envs are for development, ``pip install --user`` for deployment. > Christian Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Deprecate PEP 370 Per user site-packages directory?
On Sat, Jan 13, 2018 at 09:00:07PM +0100, Christian Heimes wrote: > On 2018-01-13 20:08, Oleg Broytman wrote: > > Hi! > > > > On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes > > wrote: > >> Hi, > >> > >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one > >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have > >> virtual environment support in Python. Ian Bicking had just started to > >> create the virtualenv project a couple of months earlier. > >> > >> Fast forward 10 years... > >> > >> Nowadays Python has venv in the standard library. The user-specific > >> site-packages directory is no longer that useful. > > > >Can I disagree? > > > >> I would even say it's > >> causing more trouble than it's worth. For example it's common for system > >> script to use "#!/usr/bin/python3" shebang without -s or -I option. > > > >System scripts are run under user root which seldom has user-specific > > site-packages so why worry? > > You'd be surprised how many tools and programs are using Python these > days. Certainly not. I wrote or helped to write a lot of them myself. :-) > You can easily break important user programs by installing a > package with --user. Under root? Probably. Then don't do that -- or do not allow system Python to import user-specific site-packages (i.e., distinguish system Python from normal Python running under user root). But for a non-root user user-specific site-packages is quite a convenient thing. Please don't remove it. > Christian Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3
On Sun, Jan 14, 2018 at 02:16:53AM +, Brett Cannon wrote: > My guess is we either move to containers on Travis, see if we can manually > install -- through apt or something -- a newer version of OpenSSL OpenSSL 1.0.2 cannot be installed with apt on Trusty but I think it can be compiled from sources. > -Brett Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Positional-only parameters in Python
On Wed, Jan 17, 2018 at 08:29:16AM -0800, Ethan Furman wrote: >def some_func(a, b, /, this, that, *, the_other): ># some stuff > > Everything before the slash is positional-only, between the slash and star > is positional-or-keyword, and after the star is keyword-only. Is there syntax to combine def some_func(a, b, /, *, the_other): ??? May be def some_func(a, b, /*, the_other): ??? > And slash is > certainly no uglier than star. ;) I tend to agree. Both are absolutely but equally ugly. :-( > -- > ~Ethan~ Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Positional-only parameters in Python
Hi! A few minor corrections below. On Sun, Jan 21, 2018 at 01:59:49PM +, Mario Corchero wrote: > Author: Larry Hastings , Pablo Galindo > , Mario Corchero ^ Add a space or a few here - this is the way for line wrapping in long headers. > introduces an asymetry on how parameter behavior is declared. Also, as the `\` \ -> / Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?
On Mon, Jan 22, 2018 at 02:33:01AM -0800, Larry Hastings wrote: > All ... CI tests fail in > the same way, reporting this error: > >The command "pyenv global system 3.5" failed and exited with 1 during . Seems there is a slow workaround (install python 3.5): https://github.com/travis-ci/travis-ci/issues/8363#issuecomment-354857845 which python3.5 || (pyenv install 3.5.4 && pyenv use system 3.5.4) > //arry/ Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Guido's Python 1.0.0 Announcement from 27 Jan 1994
On Sat, Jan 27, 2018 at 08:58:54AM -0800, Senthil Kumaran wrote: > Someone in HackerNews shared the Guido's Python 1.0.0 announcement from 27 > Jan 1994. That is, on this day, 20 years ago. 24 years ago, no? (-: > https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ > > > It is very entertaining to read. > > * Guido was the release manager, which is now taken up by other core-dev > volunteers. > > * Announcement highlighted *readable* syntax. > > * The announcement takes a dig at Perl and Bash. While Bourne shell is > still very relevant and might continue for a long time, we recognize the > difference is use cases for Bash and Python. > > * Documentation was LaTeX and PostScript. HTML was not very popular in those times! :-))) > * Error-free builds on SGI IRIX 4 and 5, Sun SunOS 4 and Solaris 2, HP-UX, > DEC Ultrix and OSF/1, IBM AIX, and SCO ODT 3.0. :-) We no longer have them. We now have Linux, Linux, and Linux. And best of all, Linux! ;-) > * You used WWW viewer to view the documentation and got the files via FTP. > > Fun times! Cheers to Guido and everyone contributing to Python. > > Thanks, > Senthil Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Guido's Python 1.0.0 Announcement from 27 Jan 1994
On Sat, Jan 27, 2018 at 10:28:52PM +0200, Simon Cross
wrote:
> We need a PPP!
Playful Python Party?!
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How is the GitHub workflow working for people?
On Fri, Feb 23, 2018 at 08:12:13AM -0500, Wes Turner
wrote:
> A pre-commit hook with flake8
The problem now is not how to configure git with flake8 (et al) but
how to configure flake8 (and other tools) to minimize the noise with the
current codebase.
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Better support for consuming vendored packages
Hi! On Thu, Mar 22, 2018 at 09:58:07AM -0700, Gregory Szorc wrote: > Not all consumers of Python packages wish to consume Python packages in the > common `pip install ` IMO `pip` is for developers. To package and distribute end-user applications there are rpm, dpkg/deb, PyInstaller, cx_Freeze, py2exe (+ installer like NSIS or InnoSetup), py2app, etc... Most of them pack a copy of Python interpreter and necessary parts of stdlib, so there is no problem with `sys.path` and wrong imports. > Gregory Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Better support for consuming vendored packages
On Thu, Mar 22, 2018 at 12:30:02PM -0700, Barry Warsaw wrote: > Developers are mostly going to use pip, and maybe a requirements.txt, +virtual envs to avoid problems with global site-packages. IMO virtualenv for development and frozen app for distribution solve the problem much better than vendoring. > Cheers, > -Barry Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 572: Assignment Expressions
On Wed, Apr 18, 2018 at 09:26:17PM +, "Gregory P. Smith" wrote: > On Wed, Apr 18, 2018 at 11:04 AM Barry Warsaw wrote: > > Since I can???t have ???>>??? or ???<>??? back, I propose ???===???. > > 8 of course. to "match" what merge conflict markers look like. ;) Sorry for being pedantic, but git conflict markers are 7 in length. > -gps Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 startup time - daemon
On Fri, May 11, 2018 at 07:38:05AM -0700, Chris Barker - NOAA Federal via Python-Dev wrote: > Could one make a little startup utility that, when invoked the first > time, starts up a raw python interpreter, keeps it running somewhere, > and then forks it to run the actual python code. > > Then every invocation after that would make a new fork. Used to be implemented (and discussed in this list) many times. Just a few examples: http://readyexec.sourceforge.net/ https://blogs.gnome.org/johan/2007/01/18/introducing-python-launcher/ Proven to be hard and never gain any traction. a) you don't want the daemon to import all possible modules so you need to run a separate copy of the daemon for every Python version, every user and every client program; b) you need to find "your" daemon - using TCP? unix sockets? named pipes? b) need to redirect stdio to/from the daemon; c) need to redirect signals and exceptions; d) have problems with elevated privileges (how do you elevate the daemon if the client was started with `sudo -H`?); e) not portable (there is a popular GUI that cannot fork). > -CHB > Sent from my iPhone Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 startup time
On Mon, May 14, 2018 at 12:26:19PM -0400, Chris Barker via Python-Dev wrote: > With regard to forking -- is there another way? I don't have the expertise > to have any idea if this is possible, but: > > start up python > > capture the entire runtime image as a single binary blob. > could that blob be simply loaded into memory and run? Like emacs unexec? https://www.google.com/search?q=emacs+unexec > -CHB > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] The history of PyXML
On Mon, May 28, 2018 at 03:09:46PM +0300, Serhiy Storchaka wrote: > 25.05.18 05:09, Jan Claeys пише: > > On Thu, 2018-05-17 at 15:18 +0300, Serhiy Storchaka wrote: > > > Does anyone has the full copy of the PyXML repository, with the > > > complete history? > > > > > > This library was included in Python 2.1 as the xml package and is > > > not maintained as a separate project since 2004. It's home on > > > SourceForge was removed. I have found sources of the last PyXML > > > version (0.8.4), but without history. > > > > > > > Did you try asking SourceForge if they still have a backup copy? > > No, I didn't. I first tried to ask whether any of active Python core > developers were involved in developing of PyXML and kept some history. I > even don't know whether PyXML used any VCS served by SourceForge, or just > published tarballs. They had been using CVS: https://web.archive.org/web/20151113082010/http://sourceforge.net/p/pyxml/code/ CVS repo web viewer shows some subdirectories but it seems there is no sources. I also failed to rsync from their CVS pserver and I doubt they have a backup -- SF stopped supporting CVS long ago. Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman wrote:
> PEP: XXX
> Title: Collecting information about git
HTMLized version: http://phdru.name/Software/Python/PEPs/pep-git.html
git repo: http://git.phdru.name/?p=pep-git.git;a=summary
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] PEP: Collecting information about git
PEP: XXX Title: Collecting information about git Version: $Revision$ Last-Modified: $Date$ Author: Oleg Broytman Status: Draft Type: Informational Content-Type: text/x-rst Created: 01-Jun-2015 Post-History: 12-Sep-2015 Abstract This Informational PEP collects information about git. There is, of course, a lot of documentation for git, so the PEP concentrates on more complex (and more related to Python development) issues, scenarios and examples. The plan is to extend the PEP in the future collecting information about equivalence of Mercurial and git scenarios to help migrating Python development from Mercurial to git. The author of the PEP doesn't currently plan to write a Process PEP on migration Python development from Mercurial to git. Documentation = Git is accompanied with a lot of documentation, both online and offline. Documentation for starters -- Git Tutorial: `part 1 <https://www.kernel.org/pub/software/scm/git/docs/gittutorial.html>`_, `part 2 <https://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html>`_. `Git User's manual <https://www.kernel.org/pub/software/scm/git/docs/user-manual.html>`_. `Everyday GIT With 20 Commands Or So <https://www.kernel.org/pub/software/scm/git/docs/everyday.html>`_. `Git workflows <https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_. Advanced documentation -- `Git Magic <http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html>`_, with a number of translations. `Pro Git <https://git-scm.com/book>`_. The Book about git. Buy it at Amazon or download in PDF, mobi, or ePub form. It has translations to many different languages. Download Russian translation from `GArik <https://github.com/GArik/progit/wiki>`_. `Git Wiki <https://git.wiki.kernel.org/index.php/Main_Page>`_. Offline documentation - Git has builtin help: run ``git help $TOPIC``. For example, run ``git help git`` or ``git help help``. Quick start === Download and installation - Unix users: `download and install using your package manager <https://git-scm.com/download/linux>`_. Microsoft Windows: download `git-for-windows <https://github.com/git-for-windows/git/releases>`_ or `msysGit <https://github.com/msysgit/msysgit/releases>`_. MacOS X: use git installed with `XCode <https://developer.apple.com/xcode/downloads/>`_ or download from `MacPorts <https://www.macports.org/ports.php?by=name&substr=git>`_ or `git-osx-installer <http://sourceforge.net/projects/git-osx-installer/files/>`_ or install git with `Homebrew <http://brew.sh/>`_: ``brew install git``. `git-cola <https://git-cola.github.io/index.html>`_ is a Git GUI written in Python and GPL licensed. Linux, Windows, MacOS X. `TortoiseGit <https://tortoisegit.org/>`_ is a Windows Shell Interface to Git based on TortoiseSVN; open source. Initial configuration - This simple code is often appears in documentation, but it is important so let repeat it here. Git stores author and committer names/emails in every commit, so configure your real name and preferred email:: $ git config --global user.name "User Name" $ git config --global user.email user.n...@example.org Examples in this PEP Examples of git commands in this PEP use the following approach. It is supposed that you, the user, works with a local repository named ``python`` that has an upstream remote repo named ``origin``. Your local repo has two branches ``v1`` and ``master``. For most examples the currently checked out branch is ``master``. That is, it's assumed you have done something like that:: $ git clone https://git.python.org/python.git $ cd python $ git branch v1 origin/v1 The first command clones remote repository into local directory `python``, creates a new local branch master, sets remotes/origin/master as its upstream remote-tracking branch and checks it out into the working directory. The last command creates a new local branch v1 and sets remotes/origin/v1 as its upstream remote-tracking branch. The same result can be achieved with commands:: $ git clone -b v1 https://git.python.org/python.git $ cd python $ git checkout --track origin/master The last command creates a new local branch master, sets remotes/origin/master as its upstream remote-tracking branch and checks it out into the working directory. Branches and branches = Git terminology can be a bit misleading. Take, for example, the term "branch". In git it has two meanings. A branch is a directed line of commits (possibly with merges). And a branch is a label or a pointer assigned to a line of commits. It is important to distinguish when you talk about commits and when about their labels. Lines of commi
Re: [Python-Dev] PEP: Collecting information about git
Hi! I will add the URL with the following paragraph: Python Developer's Guide also has a chapter `Mercurial for git developers <https://docs.python.org/devguide/gitdevs.html>`_ that documents a few differences between git and hg. Thanks! On Sat, Sep 12, 2015 at 03:12:13PM +, Brett Cannon wrote: > I have not had a chance to read Oleg's PEP, but the devguide has the > reverse docs at https://docs.python.org/devguide/gitdevs.html so we have > the VCS docs down pat. :) > > On Sat, Sep 12, 2015, 06:59 Oleg Broytman wrote: > > PEP: XXX > > Title: Collecting information about git Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
On Sat, Sep 12, 2015 at 08:29:10AM -0700, Guido van Rossum wrote: > I have only skimmed the first half but it looks really good. Thank you! > On Sat, Sep 12, 2015 at 8:12 AM, Brett Cannon wrote: > > > I have not had a chance to read Oleg's PEP, but the devguide has the > > reverse docs at https://docs.python.org/devguide/gitdevs.html so we have > > the VCS docs down pat. :) > > > > On Sat, Sep 12, 2015, 06:59 Oleg Broytman wrote: > > > >> PEP: XXX > >> Title: Collecting information about git Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
On Sat, Sep 12, 2015 at 02:02:15PM -0400, PJ Eby wrote: > On Sat, Sep 12, 2015 at 9:54 AM, Oleg Broytman wrote: > > The plan is to extend the PEP in the future collecting information > > about equivalence of Mercurial and git scenarios to help migrating > > Python development from Mercurial to git. > > I couldn't find any previous discussion about this, but I figure I > should mention: > > If the motivation here is to get away from the often-awful bitbucket > to the friendlier and more-popular Github, then it might be useful to > know that hg-git works beautifully with Github. I have over a dozen > open source projects on Github that I manage entirely using hg command > lines without having yet touched git at all. Even the forks and pull > requests I've done of others' projects on Github worked just fine, so > long as I remember to use hg bookmarks instead of hg branches. > > It's possible there are things you can't do with Mercurial on Github, > but I haven't encountered one thus far. My motivation is to help people switch from hg to git without caring of any particular hosting. Actually I prefer Python development to use self-hosting with Kalithea, pagure or gitlab at git.python.org (with official, semi-official and unofficial mirrors all over the Net). There are too many things that I personally can do with git but can't do with hg. Because of that I switched all my development from hg to git and I am willing to help those who want to follow. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
Hi! On Sun, Sep 13, 2015 at 09:14:58AM +1000, Tim Delaney wrote: > On 13 September 2015 at 04:42, Oleg Broytman wrote: > > >There are too many things that I personally can do with git but can't > > do with hg. Because of that I switched all my development from hg to git > > and I am willing to help those who want to follow. > > Slightly off-topic, but personally I'd love to know what those are. I've > yet to find anything in Git that I haven't been able to do at least as well > with Mercurial (or an extension), and there are things Mercurial > supports that I use extensively (in particular named branches and phases) > where the concept doesn't even exist in Git. I started to learn Mercurial at the end of 2008 and made the first commit at January of 2009. Global named branches was one of the (mis)features that I disliked from the very beginning. One top-level .hgignore file instead of proper per-directory ignore files. Two-commits tagging -- the tag is committed in a different commit from the commit it tags. Repositories to pull from and push to must be related -- they must be (in)direct clones of one root repo. There were also things that I wanted but didn't really understand what I wanted -- I switched to Mercurial from CVS and SVN and didn't fully understand the real power of distributed VCS. I was the only developer of the project, the project was not very big: $ du -sh third-party .hg . 2.4M third-party 2.2M .hg 6.2M . and didn't require intensive development so instead of named branches I decided to go with two separate clones, old and new, and use ``hg transplant`` to copy occasional commits from the old clone to the new one. Somewhere at the end of 2011 my management moved me to a different project. They use git for development so I started to learn git (i.e., Mercurial had 3 years start). I am a slow thinker so it took me about a year to master git, another year to appreciate it and at the third year I fell in love with it. The project is much bigger: $ du -sh libs/third-party third-party .git . 24M libs/third-party 46M third-party 48M .git 20M . and development is much more intensive -- there are many developers, many clones, many subprojects, many submodules, third-party libraries and programs, many branches with merges. Git fixed all the problems I had with hg. Its branching model suits my understanding of branches much better. With git we can have per-directory .gitignore and .gitattributes. Lightweight and annotated tags point exactly to the commits they tag. Ability to pull and push between unrelated repos. I learned commit editing and found that it was the thing I wanted so badly in hg. When I started Mercurial was at version 1.7 and there was no commit editing at all; there was ``hg rollback`` but it only could undo one transaction. Later Mercurial learned commit editing, unwillingly perhaps, but git is still better at it: ``git add -p`` allows me to review and edit patches before commit while ``hg record`` commits immediately. Git is powerful. Even now, at version 3.1 ``hg help log`` lists about a dozen of options; ``git help log`` gives me about 60 pages of documentation. I do not use all of them but I very much like ``git log --decorate``, ``--graph``, ``--grep=`` (and all related search options, especially ``-G``), ``--pretty``, ``--oneline``, ``--encoding=`` (I often use koi8-r instead of utf-8), ``--color`` and ``--word-diff``. I like ``git grep``, especially in the form ``git grep -Ovim``. I don't know what are the equivalent commands for ``git commit -c HEAD~`` or ``git diff --name-only``. Git has a lot of good documentation. A few months ago I converted those two clones from hg to git using git-remote-hg, merged them into one repository as branches, did a null-merge and from that point I have been using proper branches and merges for development. I stopped using Mercurial and I think I will not come back. As I stopped using Mercurial I do not understand what phases are. they are phases of commit according to what? To the origin (let me borrow the word from git terminology)? Mercurial, for sure, has some advantages. It is written in Python. That's important. That's important for ideological reasons. That's also important because hg runs natively under Windows, it even has code for working with case-insensitive filesystems. There are Mercurial Queues. There are also small advantages like better polished command-line interface and ability to shorten command names and options to a unique prefix. > Tim Delaney Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
Hello! On Sun, Sep 13, 2015 at 02:10:42PM -0400, Barry Warsaw wrote: > One of the things I think is missing from most git documentation, is an > effective workflow for handling multiple branches. Thank you for the good question! I doubt there One True Way, so the core team will choose one of the existing ways or develop their own. I can recommend three sources of information. First, gitworkflows (``git help workflows``): https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html The chapter "MANAGING BRANCHES" describes how the very git developers do that and what they recommend as the best practice. Second, the corresponding chapters in ProGit: https://git-scm.com/book/en/Git-Branching-Branching-Workflows https://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project Both gitworkflows and The Book are linked from the PEP and I don't think there is a need to copy texts from the docs to the PEP. The third source of information is not mentioned in the PEP, though. I have to think where to put it. It is well-known git-flow article: http://nvie.com/posts/a-successful-git-branching-model/ It has very detaild rules on creating and managing mainline branches, topic branches and bugfix branches. To support the flow at the software level the author implemented ``git flow`` extension: https://github.com/nvie/gitflow See an example at http://alblue.bandlem.com/2011/11/git-tip-of-week-git-flow.html Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] peps: Move 13 -> 103
On Tue, Sep 15, 2015 at 12:17:00PM +0300, Serhiy Storchaka wrote: > On 15.09.15 04:21, barry.warsaw wrote: > >https://hg.python.org/peps/rev/e275c4cd4b44 > >changeset: 6059:e275c4cd4b44 > >user:Barry Warsaw > >date:Mon Sep 14 21:21:40 2015 -0400 > >summary: > > Move 13 -> 103 > > > >files: > > pep-0103.rst | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > >diff --git a/pep-0013.rst b/pep-0103.rst > >rename from pep-0013.rst > >rename to pep-0103.rst > > Is it due to superstition? It's because I suggested the PEP doesn't deserve to be listed among the top Process PEPs. Mine PEP is just Informational, so a number like 103 seems to suits it better. Barry agreed. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
Hello! On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman wrote: > Title: Collecting information about git The PEP is assigned number 103: https://www.python.org/dev/peps/pep-0103/ I added a section "Branching models". Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson wrote: > This looks like good information, but why is it a PEP? If anything, the > devguide was probably be more appropriate. But even that's strange > considering we don't use git at the moment. Exactly because the core team doesn't use git the information doesn't belong to the current revision of Developer's Guide. > On Sat, Sep 12, 2015, at 06:56, Oleg Broytman wrote: > > On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman > > wrote: > > > PEP: 103 > > > Title: Collecting information about git Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
On Tue, Sep 15, 2015 at 08:32:33PM +0200, Georg Brandl wrote: > Fair enough. Still strange to read this PEP with the explicit caveat of > "The author of the PEP doesn't currently plan to write a Process PEP on > migration Python development from Mercurial to git." I am not a member of the core team, I certainly cannot write such a Process PEP. But I very much hope to see one and help if I can. > Georg > > On 09/15/2015 08:22 PM, Guido van Rossum wrote: > > For one, because *I* have been a (moderate) advocate for switching to git > > and > > GitHub. > > > > On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl > <mailto:g.bra...@gmx.net>> wrote: > > > > On 09/15/2015 08:02 PM, Oleg Broytman wrote: > > > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson > > mailto:benja...@python.org>> wrote: > > >> This looks like good information, but why is it a PEP? If anything, > > the > > >> devguide was probably be more appropriate. But even that's strange > > >> considering we don't use git at the moment. > > > > > >Exactly because the core team doesn't use git the information > > doesn't > > > belong to the current revision of Developer's Guide. > > > > And if it doesn't propose to make the core team use git, why is it a > > PEP? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
On Tue, Sep 15, 2015 at 10:41:54PM +0100, Larry Hastings wrote: > > I don't follow. Because you're an advocate of Python switching to > git and GitHub, we should have a git tutorial committed as a Python > Enhancement Proposal? > > I'm not attempting to stir up a conversation about git vs hg. I > only question the idea that a git tutorial should be a PEP, when it > has literally nothing to do with enhancing Python. There are There are PEPs that enhance development process but not Python itself. I consider the PEP one of those. > countless other venues through which Oleg could publish this > information--a blog, a wiki, or even a series of postings to this > newsgroup. I would encourage him to withdraw the PEP and publish > through one of those. > > > //arry/ > > On 09/15/2015 07:22 PM, Guido van Rossum wrote: > >For one, because *I* have been a (moderate) advocate for switching > >to git and GitHub. > > > >On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl ><mailto:g.bra...@gmx.net>> wrote: > > > >On 09/15/2015 08:02 PM, Oleg Broytman wrote: > >> On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson > >mailto:benja...@python.org>> wrote: > >>> This looks like good information, but why is it a PEP? If > >anything, the > >>> devguide was probably be more appropriate. But even that's strange > >>> considering we don't use git at the moment. > >> > >>Exactly because the core team doesn't use git the information > >doesn't > >> belong to the current revision of Developer's Guide. > > > >And if it doesn't propose to make the core team use git, why is it > >a PEP? > > > >Georg > >-- > >--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>) Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: Collecting information about git
Hi!
On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler
wrote:
> Hi! I work on Mercurial. I???ve got some inline responses, but I want to
> summarize and put this in context for those without much energy for the topic.
Thank you!
> There are a lot of reasons to prefer one tool over another. Common ones are
> familiarity, simplicity, and power.
Add here documentation, speed, availability of extensions and
3rd-party tools, hosting options (both locally installable and web
services).
> Oleg Broytman phdru.name> writes:
> > With git we can have
> > per-directory .gitignore and .gitattributes.
No per-directory .hgignore? Never? Quite useful in a big project
where subproject live in subdirectories and are developed by separate
teams.
> > tags point exactly to the commits they tag.
>
> I'm chalking these up to personal taste, but know that the tagging behavior
> of git vs hg is a very complicated tradeoff. Mercurial chose a path that
> makes tags audit-able in the future, whereas in Git a tag could disappear
> and it'd be hard to prove.
I think signed tags can help.
> >I learned commit editing and found that it was the thing I wanted so
> > badly in hg. When I started Mercurial was at version 1.7 and there was
> > no commit editing at all; there was ``hg rollback`` but it only could
> > undo one transaction.
>
> Please forget rollback exists. It's dangerous, and we're hiding it from new
> users for a reason. :)
Sure, I forgot them many years ago. ;-)
> > ``git add -p``
> > allows me to review and edit patches before commit while ``hg record``
> > commits immediately.
>
> FWIW, I totally *get* wanting a staging area. That said, other than the
> staging area, record (aka commit --interactive) and git add -p are identical
> functionality-wise.
Functionality-wise - yes, but staging area still makes the process
much more convenient.
> > ``git log --grep=`` (and all related search options,
> > especially ``-G``)
>
> Remember how I mentioned revsets replace a lot of Git command line flags?
> This is an example. hg help -r 'grep(foo)'.
$ hg help -r 'grep(foo)'
hg help: option -r not recognized
hg help [-ec] [TOPIC]
> See also `hg help revsets`,
> which are a very rich query system for revision history usable throughout
> mercurial rather than only in log.
What is the flag for case-insensitive grep()? For git log -Gregex?
> > I don't
> > know what are the equivalent commands for ``git commit -c HEAD~``
>
> hg commit --amend, or use hg histedit (which is like rebase -i)
No, they are not the same. AFAIK there are no equivalent options for
``git commit -Cc``.
> >Git has a lot of good documentation.
>
> Honestly so does Mercurial.
It is harder to find. Mine installation has bash completion that
doesn't know "revsets" and "templates" though the help pages are there.
Actually it doesn't know much at all:
$ hg help [TAB][TAB]
add cat graft log record summary
addremove clone grepmanifestrecover tag
annotatecommit heads merge remove tags
archive config helpoutgoingrename tip
backout copyidentifyparents resolve transplant
bisect diffimport paths revert unbundle
bookmarks export incomingphase rollbackupdate
branch fetch initpullrootverify
branchesforget l5 pushserve version
bundle gloglocate qrecord status
$ git help [TAB][TAB]
Display all 180 possibilities? (y or n)
Another sign of git complexity. Sigh. :-(
> >As I stopped using Mercurial I do not understand what phases are.
> > they are phases of commit according to what? To the origin (let me
> > borrow the word from git terminology)?
>
> Commits seen in the main public repository are marked as public, and
> Mercurial refuses to edit them. Most history rewriting woes happen when
> people rewrite widely shared history and force push the new version.
> Disallowing non-fast-forward push on the server prevents the rewriting from
> propagating unintentionally. Phases proactively prevent users from shooting
> themselves in the foot.
>
> More details here https://www.logilab.org/blogentry/88203
Thanks. I think upstream remote-tracking branches in git are rather
similar. If one's afraid of rewriting published history she should never
rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
good enough.
The biggest difference here is that git doesn't stop one to rebase
beyond @{upstream}.
Oleg.
--
Oleg Broytman
Re: [Python-Dev] PEP: Collecting information about git
On Wed, Sep 16, 2015 at 07:27:12PM +1000, Chris Angelico
wrote:
> On Wed, Sep 16, 2015 at 7:20 PM, Oleg Broytman wrote:
> >Thanks. I think upstream remote-tracking branches in git are rather
> > similar. If one's afraid of rewriting published history she should never
> > rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
> > good enough.
> >The biggest difference here is that git doesn't stop one to rebase
> > beyond @{upstream}.
>
> Incidentally, "git rebase -i" with no argument defaults to rebasing
> everything unpushed, which is exactly what you're talking about. But
> yes, it's perfectly possible to rebase more than that, which I've done
> extremely rarely but sufficiently often to appreciate it. Yes, there
> are consequences. All magic comes with a price. But sometimes those
> consequences are worth accepting.
PEP 103 talks about consequences and price a lot, perhaps too much. :-)
> With git, there are infinite workflows possible - you aren't forced to
> have a concept of "central server" and "clients" the way you would
> with SVN. Mercurial's called a DVCS too, so presumably it's possible
> to operate on a pure-peering model with no central server at all; how
> does that tie in with the inability to alter some commits?
Good question! In git, when you assign an upstream remote-tracking
branch (manually or automatically when cloning an existing repo) you're
essentially declare that remote the public repository on a per-branch
basis.
But certainly there are distributed development scenarios where there
are no upstream remote-tracking branches at all. For example, I develop
SQLObject using two private clones (clean backup repo and dirty working
repo) and three public clones at Gitlab, GutHub and SourceForge. They
are all equal, none of them is the upstream. I don't even have
``origin`` remote - the origin was in Subversion.
> ChrisA
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Very old git mirror under github user "python-git"
On Tue, Feb 16, 2016 at 09:16:56AM +1300, Greg Ewing wrote: > Mathieu Dupuy wrote: > >A python representative (like Guido himself) should contact Github to > >obtain coordinates of the owner... > > ...and then order a drone strike on him? Yes, and then pry the repo from his cold dead fingers. Well, I hope prying can be done without striking first. ;-) > -- > Greg Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Defining a path protocol
On Wed, Apr 06, 2016 at 11:54:08AM -0700, Ethan Furman wrote: > On 04/06/2016 11:32 AM, Brett Cannon wrote: > >On Wed, 6 Apr 2016 at 11:06 Ethan Furman wrote: > >>On 04/06/2016 10:26 AM, Brett Cannon wrote: > > >>>Now we need clear details. :) Some open questions are: > >>> > >>> 1. Name: __path__, __fspath__, or something else? > >> > >>__fspath__ > > > >+1 for __path__, +0 for __fspath__ (I don't know how widespread the > >notion that "fs" means "file system" is). > > Maybe __os_path__ then? I would rather be explicit about the type of path > we are dealing with -- who knows if we won't have __url_path__ in the future > (besides Guido, of course ;) __pathstr__? __urlstr__? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Challenge: Please break this! (a.k.a restricted mode revisited)
On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano wrote: > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > > wrote: > > > I haven't looked at your sandbox but for a different approach try this > > > one: > > > > > > L = [None] > > > L.extend(iter(L)) > > > > > > On my Linux machine that doesn't just crash Python. > > > > For the record: don't try this if you have unsaved files open on your > > computer, because you will lose them. When I typed these two lines > > into the Py3.5 interactive prompt, it completely and totally froze > > Windows to the point that nothing would respond and I had to resort to > > the old trick of holding the power button down for five seconds to > > forcibly shut the computer down. > > > I think this might improve matters: > > http://bugs.python.org/issue26351 > > although I must admit I don't understand why the entire OS is effected. Memory exhaustion? > -- > Steve Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Challenge: Please break this! (a.k.a restricted mode revisited)
On Mon, Apr 11, 2016 at 12:42:47AM -0500, Wes Turner wrote: > On Sun, Apr 10, 2016 at 10:50 PM, Oleg Broytman wrote: > > > On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano < > > st...@pearwood.info> wrote: > > > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > > > > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > > > > wrote: > > > > > I haven't looked at your sandbox but for a different approach try > > this one: > > > > > > > > > > L = [None] > > > > > L.extend(iter(L)) > > > > > > > > > > On my Linux machine that doesn't just crash Python. > > > > > > > > For the record: don't try this if you have unsaved files open on your > > > > computer, because you will lose them. When I typed these two lines > > > > into the Py3.5 interactive prompt, it completely and totally froze > > > > Windows to the point that nothing would respond and I had to resort to > > > > the old trick of holding the power button down for five seconds to > > > > forcibly shut the computer down. > > > > > > > > > I think this might improve matters: > > > > > > http://bugs.python.org/issue26351 > > > > > > although I must admit I don't understand why the entire OS is effected. > > > >Memory exhaustion? > > * > https://docs.docker.com/compose/compose-file/#cpu-shares-cpu-quota-cpuset-domainname-hostname-ipc-mac-address-mem-limit-memswap-limit-privileged-read-only-restart-stdin-open-tty-user-working-dir > > * https://github.com/jupyter/dockerspawner/blob/master/systemuser/Dockerfile I think memory control groups in Linux can be used to limit memory usage. I have mem. c. g. configured and I'll try to find time to experiment with the code above. > > > -- > > > Steve Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Challenge: Please break this! (a.k.a restricted mode revisited)
On Mon, Apr 11, 2016 at 08:06:34AM +0200, Oleg Broytman wrote: > On Mon, Apr 11, 2016 at 12:42:47AM -0500, Wes Turner > wrote: > > On Sun, Apr 10, 2016 at 10:50 PM, Oleg Broytman wrote: > > > > > On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano < > > > st...@pearwood.info> wrote: > > > > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > > > > > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > > > > > wrote: > > > > > > I haven't looked at your sandbox but for a different approach try > > > this one: > > > > > > > > > > > > L = [None] > > > > > > L.extend(iter(L)) > > > > > > > > > > > > On my Linux machine that doesn't just crash Python. > > > > > > > > > > For the record: don't try this if you have unsaved files open on your > > > > > computer, because you will lose them. When I typed these two lines > > > > > into the Py3.5 interactive prompt, it completely and totally froze > > > > > Windows to the point that nothing would respond and I had to resort to > > > > > the old trick of holding the power button down for five seconds to > > > > > forcibly shut the computer down. > > > > > > > > > > > > I think this might improve matters: > > > > > > > > http://bugs.python.org/issue26351 > > > > > > > > although I must admit I don't understand why the entire OS is effected. > > > > > >Memory exhaustion? > > * > > https://docs.docker.com/compose/compose-file/#cpu-shares-cpu-quota-cpuset-domainname-hostname-ipc-mac-address-mem-limit-memswap-limit-privileged-read-only-restart-stdin-open-tty-user-working-dir > > > > * https://github.com/jupyter/dockerspawner/blob/master/systemuser/Dockerfile > >I think memory control groups in Linux can be used to limit memory > usage. I have mem. c. g. configured and I'll try to find time to > experiment with the code above. With limited memory it was fast: $ ulimit -d 5 -m 8 -s 1 -v 10 $ python Python 2.7.9 (default, Mar 1 2015, 18:22:53) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> L = [None] >>> L.extend(iter(L)) Traceback (most recent call last): File "", line 1, in MemoryError Memory control groups don't help because they don't limit virtual memory so the process simply starts thrashing. > > > > -- > > > > Steve Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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
Hi! On Mon, Nov 04, 2013 at 03:56:25AM -0500, Terry Reedy wrote: > The one > thing I tried but could not do was to directly change status 'A' > back to '?'. hg forget file Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah wrote: > Bonus points for any other directory name that is > more self-descriptive. ;) Argument Clinic is a PyArg_Parse* preprocessor, AFAIU. Why not call the directory "pyargprep", "pyargparsers" or such? Or may be "aclinic-output"? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 3 niggle: None < 1 raises TypeError
On Fri, Feb 14, 2014 at 09:54:35PM +1100, Chris Angelico
wrote:
> So definitely SQL's handling of NULL should not be any sort of guide
> as regards Python's treatment of None.
Why not? Just make the order different for CPython and PyPy, Cython
and Jython. ;-)
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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
Hi! On Mon, Mar 10, 2014 at 04:49:44PM +, Brett Cannon wrote: > I think it got lost in email threading, but Barry pointed out that Guido > famously hates double digit version numbers (as do I, probably partially > because he does after all these years =). There is one minor annoyance with double digits: $ ls -l total 16 drwx-- 2 phd phd 4096 Mar 10 21:42 3.1 drwx-- 2 phd phd 4096 Mar 10 21:42 3.10 drwx-- 2 phd phd 4096 Mar 10 21:42 3.2 ... ... drwx-- 2 phd phd 4096 Mar 10 21:42 4.0 Other than that I don't see any problem, and don't see any need to jump from 3.9 to 4.0. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 04:37:45PM +, Brett Cannon wrote: > On Mon Mar 10 2014 at 12:08:55 PM, Victor Stinner > wrote: > > > >> I suggest to wait less than 8 years > > >> for Python 4. > > > > > > Why? What's special about 8 years? > > > > It's the time between Python 2.0 and 3.0. > > But I'm willing to bet that's going to be an anomaly. Python 3 came into > existence when it did so we didn't wait too long for Python 2 to get even > more of a foothold; the expectation is that long-term more non-Python 2 > code will be written than not. There's no rush on Python 4 since there are > no plans to try and tweak something as drastic as str/bytes. Well, the entire discussion is about "please don't do major changes -- we've got enough already". Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 09:47:32PM +0200, Serhiy Storchaka wrote: > 10.03.14 19:44, Oleg Broytman написав(ла): > >There is one minor annoyance with double digits: > > > >$ ls -l > >total 16 > >drwx-- 2 phd phd 4096 Mar 10 21:42 3.1 > >drwx-- 2 phd phd 4096 Mar 10 21:42 3.10 > >drwx-- 2 phd phd 4096 Mar 10 21:42 3.2 > >... ... > >drwx-- 2 phd phd 4096 Mar 10 21:42 4.0 > > ls -lv Not every filemanager can do that. Not even every ls: $ uname -a FreeBSD 9.2-RELEASE $ man ls | grep -F -- -v Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: fix #21076: turn signal module constants into enums
On Fri, Apr 04, 2014 at 05:08:37PM +0200, Giampaolo Rodola' wrote: > Sorry for the troubles. :( > I committed this because it worked on my local copy of Python 3.5 but after > I tried a brand new "hg clone" it didnt. make distclean was not enough? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] pip: cdecimal an externally hosted file and may be unreliable [sic]
On Fri, May 09, 2014 at 06:09:28AM -0700, Ethan Furman wrote: > On 05/08/2014 02:02 PM, Paul Moore wrote: > Well, I do host a small handful of modules on PyPI, but I can say that some > of my pain points are: > > - getting a good name: the obvious ones are taken, so the search > begins to find a name that is not taken and yet still feels at > least somewhat appropriate: > > my OO path module ended up being called strpath (dumb name); > eventually changed to antipathy > > my script param line parser is called scription (okay name) > > my enum backport is called enum34 (blah) > > my dbf package is called dbf (lucky lucky lucky!) For many reasons I avoid github/gitorious/bitbucket, but there is one thing they do right -- two-levels namespaces. "Namespaces are one honking great idea -- let's do more of those!" Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 patch levels turning two digit
On Sun, Jun 22, 2014 at 06:34:23AM +1000, Chris Angelico
wrote:
> Do you know where this problematic code is?
In many places:
https://encrypted.google.com/search?q=%22sys.version[%3A3]%22
https://encrypted.google.com/search?q=%22sys.version[%3A5]%22
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Finding Guido's replacement
Hi! On Mon, Jul 23, 2018 at 11:47:25AM +0300, Yury Selivanov wrote: > On Sun, Jul 22, 2018 at 11:18 PM Chris Angelico wrote: > > > > > * Lately, all Guido's actions have been to benefit his employer, not > > the Common Pythonista. We have proof of this from reliable reporting > > sources such as Twitter and social media. > > This accusation is ridiculous and not appreciated. Yury, the entire message from Chris was a joke. Of bad taste, in my opinion. And I also didn't get initially that it was a joke, it took me a few minutes to understand. > Yury > -- > Yury Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Finding Guido's replacement
On Mon, Jul 23, 2018 at 08:37:05PM +1000, Chris Angelico wrote: > On Mon, Jul 23, 2018 at 7:07 PM, Oleg Broytman wrote: > > I also didn't get initially that it was a joke, it took me > > a few minutes to understand. > > If the reference to PEP 401 didn't tip you off and you don't recognize > the references to famous Battle Royale games, then perhaps the fact > that I called social media "reliable" might have been a good hint that > I wasn't being entirely serious? I was sure you've been serious until I got to the last paragraph. > ChrisA Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Problem in importing python packages under python 3.6 environment
Hello. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See https://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Thu, Aug 09, 2018 at 06:15:49PM +0530, "Poornima .D." wrote: > Hi All, > > > I have limited knowledge on python development. I am trying to write a > test application which needs to import from many packages across > mutliple directories. > > > I tried using an environment variable and appending to sys.path variable so > that import Class methods works. > > > I am trying to replace the above logic by below syntax. > > > from directory.fileName import ClassName > > > But this syntax does not work. Please let me know any solution for this > issue. Not enough information to answer. To ask such a question you'd better prepare a simple exmaple that doesn't work -- just a few small files and directories. Learn about Python modules/packagaes at https://docs.python.org/3/tutorial/modules.html especially paying attention to The Module Search Path: https://docs.python.org/3/tutorial/modules.html#the-module-search-path Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] pyOpengl text render
Hello.
This mailing list is to work on developing Python (adding new
features to Python itself and fixing bugs); if you're having problems
learning, understanding or using Python, please find another forum.
Probably python-list/comp.lang.python mailing list/news group is the
best place; there are Python developers who participate in it; you may
get a faster, and probably more complete, answer there. See
https://www.python.org/community/ for other lists/news groups/fora.
Thank you for understanding.
On Mon, Sep 03, 2018 at 09:43:35PM +0600, Md Abu Talha
wrote:
> How can I rendered text using python and opengl? please help
https://www.google.com/search?hl=en&pws=0&q=python+opengl+render+text
https://stackoverflow.com/search?q=%5Bpython%5D+%5Bopengl%5D+render+text
Oleg.
--
Oleg Broytmanhttps://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Inclusion of lz4 bindings in stdlib?
On Thu, Nov 29, 2018 at 09:36:51AM -0500, Benjamin Peterson
wrote:
> - stdlib modules become a permanent maintenance burden to CPython core
> developers.
Add ditributions maintainers here.
Oleg.
--
Oleg Broytmanhttps://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Add more SyntaxWarnings?
On Wed, Jan 30, 2019 at 07:12:21PM +0100, Stefan Behnel wrote: > > I have a vague recollection that a certain computer system (Amiga?) had a > > 'why' command. If it reported an error, you could type "why" and it would > > give you more details. > > > > I suspect that all that was happening was that when the error occurred it > > would store the additional details somewhere that the 'why' command would > > simply retrieve. > > So ??? are you suggesting to use the webbrowser module inside of the REPL to > look up the exception message of the previously printed stack trace in > stack overflow when a user types "why()"? > > I faintly recall someone implementing something in that direction. It's > probably in some package on PyPI. It doesn't have to be all web. Compare how ``help()`` works at the python REPL, ``pydoc name`` at the command line, and ``pydoc -p`` + a browser. > Stefan Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 594: Removing dead batteries from the standard library
``http.server`` is used in ``pydoc``: https://github.com/python/cpython/blob/ccb7ca728e09b307f9e9fd36ec40353137e68a3b/Lib/pydoc.py#L2236 On Tue, May 21, 2019 at 10:12:50AM -0700, Guido van Rossum wrote: > I still like http.server for quick temporary hacks where I want to be able > to point a browser at some code I wrote 5 minutes ago and that I plan to > discard in an hour. Usually it's running at localhost:8000. Remembering how > to use Django, flask or Tornado seems overkill for that purpose. > > On Tue, May 21, 2019 at 9:39 AM Glenn Linderman > wrote: > > > On 5/20/2019 2:20 PM, Christian Heimes wrote: > > > > On 20/05/2019 23.12, Andrew Svetlov wrote: > > > > socketserver.py is also questionable > > > > I briefly though about the module, but didn't consider it for removal. The > > http.server, xmlrpc.server, and logging configuration server are > > implemented on top of the socketserver. I don't want to remove the > > socketserver module without a suitable replacement for http.server in the > > standard library. > > > > > > But http.server could be on the remove list too... it gets mighty little > > support, has very little functionality, and implements a CGI interface > > (although that also has very little functionality), and you have the CGI > > tools on the remove list, rendering the CGI interface implemented by > > http.server less easily usable. > > > > Further, it doesn't directly support https:, and browsers are > > removing/reducing support for http:. > > > > I can't speak to xmlrpc or logging configuration. > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him/his **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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: why is not 64-bit installer the default download link for Windows?
On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com wrote: > Why don't we check the architecture using js and provide the appropriate > version? Because the downloading computer is not necessary the installation target. Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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/GHFN5GVXPU7RPA7MLOPFNWXBPSKBIGUF/
[Python-Dev] Re: In what tense should the changelog be written?
On Fri, Apr 30, 2021 at 09:43:44AM +0300, Serhiy Storchaka wrote: > 30.04.21 05:57, Larry Hastings пише: > > When one writes one's "blurb" for the changelog, in what tense should it > > be? > > See the previous discussion on this topic: > https://mail.python.org/archives/list/python-dev@python.org/thread/C342Y73LALVFLI2ACFB3SH6ZDT2YTGPC/ > . > > I always use "fixed", "removed", "added" when describe changes following > the rule formulated by Oleg Broytman: > > > I use past tense to describe what I did on the code, and present > > simple to describe what the new code does when running. Thanks, Serhiy, for reminding! I said this about git commit messages, not NEWS items. And even for commit messages I changed my style to be imperative. The widely known advice about git commit messages is: the subject should be a continuation of "When applied this commit will..." So I now use "Implement a feature", "Fix a bug", "Update docs". Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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/6BBFXPC6O6XBCYCN2ZBLHPF2NGR4UEGJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Windows buildbots may be broken
On Tue, Aug 03, 2021 at 06:29:43AM -0700, Senthil Kumaran wrote: > On Fri, Jul 30, 2021 at 02:28:08PM +, Jason R. Coombs wrote: > > > If you run such a buildbot, please consider running this command on > > your repo to bypass the issue: > > > > git rm -r :/ ; git checkout HEAD -- :/ > > > > You may want to consider adding this command after every update to the > > repo to avoid the stale state. > > What does this do? Especially the first command. Is this Windows specific? Git specific. It means "remove every file and directory recursively starting from the root of the repository". ``-r`` means recursive; ``:/`` is a "magic" git-specific path "root of the repo". The second command checks out everything from the HEAD commit back to the filesystem. > -- > Senthil Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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/NUIO4JPCFFJZJVZHWANBKWMPULHTK3P5/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Built with VS2012 Express for desktop
Hello. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Tue, Feb 19, 2013 at 01:37:15PM -0500, rahul garg wrote: > a) Is there a test suite that I can run to verify that the build is working > fine? http://docs.python.org/3.3/library/test.html Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Built with VS2012 Express for desktop
On Wed, Feb 20, 2013 at 08:23:19AM +0100, Antoine Pitrou wrote: > On Tue, 19 Feb 2013 20:37:36 -0800 > Eli Bendersky wrote: > > On Tue, Feb 19, 2013 at 10:50 AM, Oleg Broytman wrote: > > Oleg, lately I have the feeling you're getting too automatic with this > > template response. > > +1. This isn't the python-robots mailing-list. Ok, I'll stop. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Built with VS2012 Express for desktop
On Wed, Feb 20, 2013 at 10:54:06AM +0100, Antoine Pitrou wrote: > Le Wed, 20 Feb 2013 13:09:13 +0400, > Oleg Broytman a ??crit : > > On Wed, Feb 20, 2013 at 08:23:19AM +0100, Antoine Pitrou > > wrote: > > > On Tue, 19 Feb 2013 20:37:36 -0800 > > > Eli Bendersky wrote: > > > > On Tue, Feb 19, 2013 at 10:50 AM, Oleg Broytman > > > > wrote: Oleg, lately I have the feeling you're getting too > > > > automatic with this template response. > > > > > > +1. This isn't the python-robots mailing-list. > > > >Ok, I'll stop. > > Thanks! Perhaps we may have to become more automatic if some day we are > flooded with newbie messages on the list, but this isn't the case > currently. That was the case when I started. > Moreover, the original message here was a build question that probably > wouldn't receive any meaningful answer on python-list, which makes it > suitable for python-dev. You are right. I am sorry. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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 Thu, Mar 21, 2013 at 02:19:33PM -0700, Mark Janssen wrote: > The *only* thing I find "ugly" about it is that it doesn't have a > white-on-black color scheme. Look at any hacker console and you won't find > a white screen. Call me a bad hacker or not hacker at all -- I hate black backgrounds. My windows are always black-on-lightgrey, sometimes on dark grey, never black. I have been spending 16 hours a day at the screen for last 25 years -- and never understood black background. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] casefolding in pathlib (PEP 428)
On Thu, Apr 11, 2013 at 02:11:21PM -0700, Guido van Rossum
wrote:
> - the case-folding algorithm on some filesystems is burned into the
> disk when the disk is formatted
Into the partition, I guess, not the physical disc?
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] casefolding in pathlib (PEP 428)
On Fri, Apr 12, 2013 at 09:29:44AM +1200, Robert Collins wrote: > On 12 April 2013 09:18, Oleg Broytman wrote: > > On Thu, Apr 11, 2013 at 02:11:21PM -0700, Guido van Rossum > > wrote: > >> - the case-folding algorithm on some filesystems is burned into the > >> disk when the disk is formatted > > > >Into the partition, I guess, not the physical disc? > > CDROMs - Joliet IIRC - so yes, physical disc. Ah, I've completely forgotten about that one. I was thinking in terms of filesystems. Thank you for reminding! Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Why can't I encode/decode base64 without importing a module?
On Mon, Apr 22, 2013 at 09:50:14AM -0400, Devin Jeanpierre
wrote:
> unicode_escape doesn't make any sense anymore -- python code is text,
> not bytes, so why does 'abc'.encode('unicode_escape') return bytes?
AFAIU the situation is simple: unicode.encode(encoding) returns
bytes, bytes.decode(encoding) returns unicode, and neither
unicode.decode() nor bytes.encode() exist.
Transformations like base64 and bz2 are nor encoding/decoding -- they
are bytes/bytes or unicode/unicode transformations.
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] Problem with pydoc script in PEP 405 venvs
On Mon, Jun 17, 2013 at 06:37:49PM +, Vinay Sajip wrote: > @echo off > __VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())" I think you want to pass command line arguments: @echo off __VENV_PYTHON__ -c "import sys, pydoc; sys.exit(pydoc.cli())" %1 %2 %3 %4 %5 %6 %7 %8 %9 Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] End of the mystery "@README.txt Mercurial bug"
On Tue, Jun 25, 2013 at 10:11:04PM -0400, "Eric V. Smith"
wrote:
> On 6/25/2013 9:33 PM, Senthil Kumaran wrote:
> >
> >
> >
> > On Tue, Jun 25, 2013 at 5:58 PM, Benjamin Peterson > <mailto:benja...@python.org>> wrote:
> >
> > 2013/6/25 Victor Stinner > <mailto:victor.stin...@gmail.com>>:
> > > And then I ran "make distclean"...
> >
> > You've left us hanging...
> >
> >
> > Yeah, the final part is here: http://bz.selenic.com/show_bug.cgi?id=3954#c4
> > But still I have question as why hg complained about @README in the
> > first place.
> > Also, I hope make distclean is not working "inside" .hg folder.
>
> I think that's exactly what's happening.
>
> >From the bug report:
>
> find $(srcdir) '(' -name '*.fdc' -o -name '*~' \
> -o -name '[@,#]*' -o -name '*.old' \
> -o -name '*.orig' -o -name '*.rej' \
> -o -name '*.bak' ')' \
> -exec rm -f {} ';'
>
> Will find files beginning with '@' inside subdirectories of $(srcdir)/.hg.
>
> Just this week I saw someone use the logical equivalent of:
>
> find $(srcdir)/* ...
>
> to avoid this problem. It won't expand the .hg top-level directory.
Or find \( -type d -name .hg -prune \) -o ...
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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] End of the mystery "@README.txt Mercurial bug"
On Wed, Jun 26, 2013 at 08:18:27AM -0400, "Eric V. Smith" wrote: > >>> find $(srcdir)/* ... > >>> > >>> to avoid this problem. It won't expand the .hg top-level directory. > >> > >>Or find \( -type d -name .hg -prune \) -o ... > > I'm torn. Yours is more obvious, but we'd likely need to add .svn, .git, How many of those dot-files/directories are there beside .*ignore? > etc. Maybe find $(srcdir)/[a-zA-Z]* ... would be good enough to ignore > all dot directories/files? On the other hand yes, I think it'd be enough. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Add function to signal module for getting main thread id
On Fri, Aug 30, 2013 at 12:24:07PM +0300, Andrew Svetlov wrote: > Main thread is slightly different from others. > Signals can be subscribed from main thread only. > Tulip has special logic for main thread. > In application code we can explicitly know which thread is executed, > main or not. > But from library it's not easy. > Tulip uses check like > threading.current_thread().name == 'MainThread' > This approach has a problem: thread name is writable attribute and can > be changed by user code. You can test threading.current_thread().__class__ is threading._MainThread or threading.current_thread().ident == threading._MainThread.ident > My proposition is to add function like get_mainthread_id() -> int > which return ident for main thread threading._MainThread.ident ? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft wrote: > > On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote: > > I used to use myOpenID and became my own provider using poit[1]. > > These days I seldom use OpenID -- there are too few sites that allow > > full-featured login with OpenID. The future lies in OAuth 2.0. > > The Auth in OAuth stands for Authorization not Authentication. There is no authorization without authentication, so OAuth certainly performs authentication: http://oauth.net/core/1.0a/#anchor9 , http://tools.ietf.org/html/rfc5849#section-3 Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 07:31:59PM +0200, Jesus Cea wrote: > I just received an email from my OpenID provider, "myOpenID", saying > that they drop OpenID service next February. I wonder what other > OpenID providers are used by other python-dev fellows. > > What are you using?. bugs.python.org admins could share some data? > > I agree than OpenID is (quite) dead, but I rather prefer OpenID to use > user/pass. I have big hopes for Mozilla Persona, looking forward > Python infrastructure support :). > > PS: I use "http://www.jcea.es/"; as my OpenID identity, and I delegate > the actual service to "myOpenID". I can switch delegation trivially. I used to use myOpenID and became my own provider using poit[1]. These days I seldom use OpenID -- there are too few sites that allow full-featured login with OpenID. The future lies in OAuth 2.0. 1. http://yangman.ca/poit/ Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Offtopic: OpenID Providers
On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft wrote: > Persona is the logical successor to OpenID. OpenID lived a short life and died a quiet death. I'm afraid Persona wouldn't live even that much. Dead-born idea, in my so humble opinion. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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
