[Python-announce] pymssql 2.2.4 released

at: https://pymssql.readthedocs.io The sources, discussions and bug tracker: https://github.com/pymssql/pymssql. Below please see the changes since last announcement. Enjoy, Mikhail Version 2.2.4 - 2022-01-23 - Mikhail Terekhov = General

[issue46273] Document what asyncio.wait() and asyncio.as_completed() do if canceled.

New submission from Mikhail Terekhov : It is not clear from documentation what happens with awaitable objects when these are canceled. -- assignee: docs@python components: Documentation, asyncio messages: 409801 nosy: asvetlov, docs@python, termim, yselivanov priority: normal severity

[Python-announce] pymssql 2.2.3 released

at: https://pymssql.readthedocs.io The sources, discussions and bug tracker: https://github.com/pymssql/pymssql. Below please see the changes since last announcement. Enjoy, Mikhail Version 2.2.3 - 2021-12-21 - Mikhail Terekhov = General --- - Build

[issue44198] Add flags or function in pathlib.Path

New submission from Mikhail : Hello! This is a very useful feature when a Path-object gets a list (or generator, as it is now) of files/dirs in self.dir, I think. Right now this is the .iterdir() function, but sometimes you only need `dirs` of that path (for example, I really needed

[issue43654] IDLE: Applying settings disables tab completion

Mikhail added the comment: I also checked this behavior in Jython and IPython, and there errors are explicitly caused when putting/calling such values (I also checked on MicroPython online version, everything just hangs there). For IPython I created an issue on their Github, I'm thinking

[issue43654] IDLE: Applying settings disables tab completion

Mikhail added the comment: I did a little experiment, and it turned out that the problem is not in the IDLE, but inside Python itself. With this case, the same behavior remains inside the terminal version of Python, and IPython also produces a similar error

[issue43654] IDLE: Applying settings disables tab completion

Mikhail added the comment: Hello again! I found another kind of bug, where the autosupplement window doesn't show up. In order for the bug to occur, you need to put a non-string value into `locals()`. Example: ``` locals()['arg'] = 123 # or locals().setdefault('arg', 123) # ^ it's okay

[issue43654] IDLE: Applying settings disables tab completion

Change by Mikhail : -- nosy: +tetelevm ___ Python tracker <https://bugs.python.org/issue43654> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43647] Sudden crash displaying certain characters in tk widget

Mikhail added the comment: Yes, this is exactly the same problem as `issue42225`. I suspected it was a Tkinter problem, and also thought that Python might be under the hood catching C method call errors. But since you know about this problem, and in more detail than I have written here

[issue43647] Sudden crash on print() of some characters

Mikhail added the comment: I checked the behavior, and found out that it depends on the font. I have "Noto Sans Mono", and if I enter, for example, '\u2709', IDLE crashes. But if I put another font, for example 'Dejavu Mono', just a blank line is displayed. Also, if I output the

[issue43647] Sudden crash on print() of some characters

New submission from Mikhail : Hi! I'm not sure if it's an IDLE, library, Xserver or font error, but either way, IDLE is behaving incorrectly. I have installed 3.8 and 3.9 versions, and on both it works, I do not know about the others, but I suspect that on the others, this error also occurs

[issue42547] argparse: add_argument(... nargs='+', metavar=) does not work with positional arguments

Change by Mikhail Khvoinitsky : -- keywords: +patch pull_requests: +22485 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23617 ___ Python tracker <https://bugs.python.org/issu

[issue42547] argparse: add_argument(... nargs='+', metavar=) does not work with positional arguments

New submission from Mikhail Khvoinitsky : Example which works: parser.add_argument('--test', nargs='+', metavar=('TEST', 'TEST2')) Example which doesn't work: parser.add_argument('test', nargs='+', metavar=('TEST', 'TEST2')) it raises: Traceback (most recent call last

[issue41923] Add PEP 613 typing.TypeAlias to the standard library

Change by Mikhail Golubev : -- keywords: +patch nosy: +east825 nosy_count: 3.0 -> 4.0 pull_requests: +21535 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22532 ___ Python tracker <https://bugs.python.org/i

[issue41923] Add PEP 613 typing.TypeAlias to the standard library

New submission from Mikhail Golubev : TypeAlias is already included in typing_extensions package, making it available for pre-3.10 versions of Python. I'd like port this implementation to the upstream version of typing. -- components: Library (Lib) messages: 377890 nosy

[issue41882] CCompiler.has_function does not delete temporary files

Change by Mikhail Terekhov : -- keywords: +patch pull_requests: +21475 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22446 ___ Python tracker <https://bugs.python.org/issu

[issue41882] CCompiler.has_function does not delete temporary files

New submission from Mikhail Terekhov : CCompiler.has_function does not delete temporary files. Depending on the check result it leaves temporary C source, object and executable files. -- components: Distutils messages: 377646 nosy: dstufft, eric.araujo, termim priority: normal

[issue36794] asyncio.Lock documentation in Py3.8 lacks parts presented in documentation in Py3.6

New submission from Mikhail Gerasimov : Compare: https://docs.python.org/3.6/library/asyncio-sync.html#asyncio.Lock https://docs.python.org/3.8/library/asyncio-sync.html#asyncio.Lock First version is much more detailed. It allows to avoid confusions like one with unlocking order: https

[issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)

Change by Mikhail Terekhov : -- keywords: +patch pull_requests: +8167 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34335> ___ _

[issue32258] Rewrite asyncio docs to use async/await syntax

Change by Mikhail Terekhov : -- pull_requests: +8168 ___ Python tracker <https://bugs.python.org/issue32258> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)

New submission from Mikhail Terekhov : Couple of examples in in asyncio documentation mix @asyncio.coroutine decorator and await. -- components: asyncio messages: 323121 nosy: asvetlov, termim, yselivanov priority: normal severity: normal status: open title: Fix examples in asyncio

Kindness

Steven D'Aprano wrote: > Over the many months, I've tried defending Bart, engaging with him, > patiently explaining that his choices and our choices are not always the > same and that there's no objective "right" and "wrong" between them, > making subtle hints, and less subtle hints that he's

File names with slashes [was Re: error in os.chdir]

Steven D'Aprano wrote: > In Explorer and the open-file dialog of most applications, they will see > paths like this: > > directory\file name with spaces > > with the extension (.jpg, .pdf, .docx etc) suppressed. So by your > argument, Python needs to accept strings without quotes: > >

File names with slashes [was Re: error in os.chdir]

ChrisA wrote: > Mikhail V wrote: >> Yes, and the answer was a week ago: just put "r" before the string. >> r"C:\programs\util" >> >> And it worked till now. So why should I replace backslashes with >> forward slashes? >> There is one i

File names with slashes [was Re: error in os.chdir]

Joe Pfeiffer wrote: >> On Windows a path is e.g.: >> C:\programs\util\ >> So what is reasonable about using forward slashes? >> It happens to me that I need to copy-paste real paths like 100 times >> a day into scripts - do you propose to convert to forward slashes each time? > That's what

File names with slashes [was Re: error in os.chdir]

Greg wrote: > Mikhail V wrote: > > s= "\"s\"" -> > > s= {"s"} > > But now you need to find another way to represent set literals. I need to find? That comment was not about (current) Python but rather how I think string sho

File names with slashes [was Re: error in os.chdir]

[Chris A] > [Mikhail] > > So Imo default syntax should be something like: > > > > S = "A:{x41}B:{x42}" > > > > instead of backslashes and Co. > > So how do you represent brace characters in a string? \{ and \} just kidding :-D I wo

Re: File names with slashes [was Re: error in os.chdir]

[Richard Damon] > The one major issue with backslashes is that they are a special > character in string literals, so you either need to use raw literals a > remember the few cases they still act as special characters, or remember > to convert them to double back slashes, at a minimum for all the

File names with slashes [was Re: error in os.chdir]

[Steven D'Aprano] > (The same applies to Unix/Linux systems too, of course.) But while you're > using Python to manipulate files, you should use Python rules, and that > is "always use forward slashes". > > Is that reasonable? > > Under what circumstances would a user calling open(pathname) in

[issue33948] doc truncated lines in PDF

Mikhail added the comment: This file was taken from https://docs.python.org/3.7/archives/python-3.7.0rc1-docs-pdf-a4.zip Hashes CRC32: 327CF408 MD5: 7EBEB565C1EA7E52F366B5C734500FAC SHA-1: 09727C07C45965E4E43664B727E7CAECC4F3CD89 SHA-256

[issue33948] doc truncated lines in PDF

New submission from Mikhail : Hello, Python Team, In reference.pdf I came across truncated lines in Python syntax that are not wrapped and carried forward to the next line, but instead run across the right margin. Examples "2.3 Identifiers and keywords" line contains

Re: Raw string statement (proposal)

On Sat, May 26, 2018 at 10:21 PM, Chris Angelico wrote: > > I'm done. Argue with brick walls for the rest of eternity if you like. I see you like me, but I can reciprocate your feelings. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list --

Re: Raw string statement (proposal)

On Sat, May 26, 2018 at 7:10 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote: > >>> Here is a string assigned to name `s` using Python's current syntax: >>> >>> s = "some\ncharacte

Re: Raw string statement (proposal)

On Sat, May 26, 2018 at 10:55 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Sat, 26 May 2018 08:09:51 +0300, Mikhail V wrote: > >> On Fri, May 25, 2018 at 1:15 PM, bartc <b...@freeuk.com> wrote: > [...] >>> One problem here is how

Re: Raw string statement (proposal)

On Fri, May 25, 2018 at 1:15 PM, bartc <b...@freeuk.com> wrote: > On 25/05/2018 05:34, Mikhail V wrote: > > I had one big problem with your proposal, which is that I couldn't make head > or tail of your syntax. Such a thing should be immediately obvious. > > (In your

Raw string statement (proposal)

Hi. I've put some thoughts together, and need some feedback on this proposal. Main question is: Is it convincing? Is there any flaw? My own opinion - there IS something to chase. Still the justification for such syntax is hard. Raw string statement -- Issue - Vast

Re: Indented multi-line strings

On Wed, May 23, 2018 at 11:56 PM, Bob van der Poel wrote: > On Wed, May 23, 2018 at 1:45 PM, MRAB wrote: > >> If you want additional indentation, then provide a string literal: >> >> def func(): >> foobar >> data = >> '': >> first

Re: Indented multi-line strings

On Wed, May 23, 2018 at 11:45 PM, MRAB wrote: >>> def func(): >>> foobar >>> data = /// s2 >>> first line >>> last line >>> foobar >>> > Instead of the "s2", etc: > > def func(): > foobar > data = >> : > first line > last

Re: Indented multi-line strings

On Wed, May 23, 2018 at 8:08 PM, Mikhail V <mikhail...@gmail.com> wrote: > On Wed, May 23, 2018 at 4:19 PM, Dan Strohl <d.str...@f5.com> wrote: > data = /// sN # and > data = /// tN > > Where N - is the amount of characters, spaces (s) or > tabs (t). >

Indented multi-line strings

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl wrote: > First of all, I suggest splitting this into a separate proposal (new thread) > that way you will avoid confusion for people who are still considering the > older proposal, and for the (probably many) people who have stopped

Re: "Data blocks" syntax specification draft

On Wed, May 23, 2018 at 2:25 AM, Dan Strohl wrote: > >> >> Explanation: >> [here i'll use same symbol /// for the data entry point, but of course it >> can be >> changed if a better idea comes later. Also for now, just for simplicity - >> the rule >> is that the contents of a

Re: "Data blocks" syntax specification draft

On Tue, May 22, 2018 at 1:25 PM, bartc <b...@freeuk.com> wrote: > On 22/05/2018 03:49, Mikhail V wrote: >> >> On Mon, May 21, 2018 at 3:48 PM, bartc <b...@freeuk.com> wrote: >> >> # t >> # t >>11 22 33 >> > > Is

Re: "Data blocks" syntax specification draft

On Tue, May 22, 2018 at 9:01 AM, Christian Gollwitzer <aurio...@gmx.de> wrote: > Am 22.05.18 um 04:17 schrieb Mikhail V: >>> YAML comes to mind >> >> >> Actually plugging a data syntax in existing language is not a new idea. >> Though I don't know real su

Re: "Data blocks" syntax specification draft

On Mon, May 21, 2018 at 3:48 PM, bartc wrote: > > This is intended to be used inside actual Python programs? > > In that case code is normally displayed in fixed pitch, as it would normally > be viewed in a code editor, even if part of a document. > > But I have to say it looks

Re: "Data blocks" syntax specification draft

On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list wrote: > If a block of static data is large enough to start to be ugly, a common > approach is to load the data from some other file, in a language which is > designed around structured data. Maybe it is

Re: "Data blocks" syntax specification draft

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder <n...@nedbatchelder.com> wrote: > On 5/19/18 10:58 PM, Mikhail V wrote: >> >> I have made up a printable PDF with the current version >> of the syntax suggestion. >> >> https://github.com/Mikhail22/Do

Re: "Data blocks" syntax specification draft

On Mon, May 21, 2018 at 7:05 AM, Chris Angelico wrote: >>> Forcing us to download a PDF and then read it? Well, it's your >>> decision. My decision is that I cannot be bothered going to THAT much >>> effort to figure out what you're saying. >> >> THAT much effort to click two

Re: "Data blocks" syntax specification draft

On Mon, May 21, 2018 at 5:20 AM, Chris Angelico <ros...@gmail.com> wrote: > On Mon, May 21, 2018 at 8:28 AM, Mikhail V <mikhail...@gmail.com> wrote: >>> > >>> > Comments, suggestions are welcome. >>> > >>> >>> One comment.

Re: "Data blocks" syntax specification draft

On Mon, May 21, 2018 at 3:02 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Sun, May 20, 2018 at 4:28 PM, Mikhail V <mikhail...@gmail.com> wrote: >> "Markdown" is too vague - there dozens of markdown styles and >> also they include subsets of HTML. It is ju

"Data blocks" syntax specification draft

> > > > Comments, suggestions are welcome. > > > > One comment. > > I'm not interested in downloading a PDF. Can you rework your document > to be in a more textual format like Markdown or reStructuredText? > Since you're hosting on GitHub anyway, the rendering can be done > automatically. > >

"Data blocks" syntax specification draft

I have made up a printable PDF with the current version of the syntax suggestion. https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf After some of your comments I've made some further re-considerations, e.g. element separation should be now much simpler. A lot of examples

Re: Suggestion for a "data" object syntax

On Sat, May 12, 2018 at 5:38 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Fri, May 11, 2018 at 5:26 PM, Mikhail V <mikhail...@gmail.com> wrote: >> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: >>> On Thu, May 10, 2018 at 6:34

Re: Suggestion for a "data" object syntax

On Sat, May 12, 2018 at 7:54 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote: > >> it is just not a trivial task to find an optimal solution to this > > We already have an optimal solution to th

Re: Suggestion for a "data" object syntax

On Fri, May 11, 2018 at 9:39 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Mon, May 7, 2018 at 9:45 PM, Mikhail V <mikhail...@gmail.com> wrote: >> *Example 1. Multi-line strings* >> >> data === S : >> this is multi-line string >> e

Re: Suggestion for a "data" object syntax

On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhail...@gmail.com> wrote: >> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano >> <steve+comp.lang.pyt...@pearwood.info> wrote: >>> On

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote: > >> but I propose Tab-separated elements. > > We already have tab-separated elements in Python. It is allowed to use >

Re: seeking deeper (language theory) reason behind Python design choice

On Wed, May 9, 2018 at 8:50 AM, Chris Angelico wrote: > On Wed, May 9, 2018 at 3:36 PM, Ian Kelly wrote: >> >> while True: >> if we_are_done(): >> break >> # do some stuff >> ... >> if error_occurred(): >> break >>

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 3:14 AM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Mikhail V <mikhail...@gmail.com> writes: > >> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico <ros...@gmail.com> wrote: >> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mik

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 12:33 AM, Chris Angelico <ros...@gmail.com> wrote: > On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhail...@gmail.com> wrote: >> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <ros...@gmail.com> wrote: >>> On Tue, May 8, 2018 at 10:52

Re: Suggestion for a "data" object syntax

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <ros...@gmail.com> wrote: > On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhail...@gmail.com> wrote: >> Right? Your issues with tabs aside, I think it is impossible to ignore the >> the readability improvement. Not even spe

Re: Suggestion for a "data" object syntax

On Tue, May 8, 2018 at 6:20 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote: > >>> Last time you brought up this idea, you were told that it is ambiguous. >>> Using whitespace alone, it is imp

Re: Suggestion for a "data" object syntax

On Tue, May 8, 2018 at 10:15 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote: > >> *Example 3. Two-dimensional tuple.* >> >> data === T/T : >> 123"hello" >>

Suggestion for a "data" object syntax

Here is an idea for 'data object' a syntax. For me it is interesting, how would users find such syntax. I personally find that this should be attractive from users perspective. Main aim is more readable presenting of typical data chunks and some typical data types (tuples/lists) directly in code.

[issue33272] Which are reasonable reason for recursion limit in function _vformat of class Formatter lib string?

New submission from Mikhail <mikhail.v.gavri...@gmail.com>: The presence of the restriction of recursion prevent making nested conditions for the superformatter: https://github.com/ebrehault/superformatter for example: import string class SuperFormatter(string.Formatter): &quo

[issue33229] Documentation - io — Core tools for working with streams - seek()

Change by Mikhail Zakharov <zmey20...@yahoo.com>: -- stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.

[issue33229] Documentation - io — Core tools for working with streams - seek()

Mikhail Zakharov <zmey20...@yahoo.com> added the comment: OK, I got it. Sorry for disturbing you. The should be called like: io.SEEK_* -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33229] Documentation - io — Core tools for working with streams - seek()

Mikhail Zakharov <zmey20...@yahoo.com> added the comment: Seems in my, quite old 3.4.5 version, it doesn't work: $ python3 Python 3.4.5 (default, Jun 1 2017, 13:52:39) [GCC 4.4.7 20120313 (Red Hat 4.4.7-18)] on linux Type "help", "copyright", "credits" or &

[issue33229] Documentation - io — Core tools for working with streams - seek()

New submission from Mikhail Zakharov <zmey20...@yahoo.com>: Documentation for io.IOBase class and it's seek() method at https://docs.python.org/3/library/io.html mentions SEEK_* constants like: "SEEK_SET or 0 – start of the stream (the default); offset should be zero

Beta release of pip version 10

MRAB writes: > > UnicodeEncodeError: 'charmap' codec can't encode character > > > > when it meets a non-ascii char. > > > > e.g. tried this: > > pip search pygame > a.txt > > > Well, _I_ didn't get an error! > > One of the lines is: > > kundalini (0.4)- LրVE-like PyGame API > >

Beta release of pip version 10

Steven D'Aprano writes: >> >> PS: was looking forward to PIP improvements on Windows, on 9.0.3 still >> some issues. E.g. trying to redirect output from 'pip search ... > >> a.txt' gives a wall of errors. it's on Windows 10. > > > > Don't be shy, tell us what those errors are. You meant - don't

Beta release of pip version 10

iption too and that may be a lng list of packages). Mikhail -- https://mail.python.org/mailman/listinfo/python-list

Re: Simple graphic library for beginners

t an easy problem. So in this case pip shoud track the multiple versions each time I install another version of python. Mikhail -- https://mail.python.org/mailman/listinfo/python-list

Simple graphic library for beginners

PyQT is imo better option for noobs than Pygame. So here you have buttons and lots of OOP bloat as a consequence. Mikhail -- https://mail.python.org/mailman/listinfo/python-list

Goto

goto "end" "end" I know I can do it with "elif", but "elif" is just not my cup of tea. For this case goto provides symmetrical and explicit look, which I value a lot. Mikhail -- https://mail.python.org/mailman/listinfo/python-list

[issue32297] Few misspellings found in Python source code comments.

New submission from Mikhail Afanasev <meha...@gmail.com>: I have noticed few misspellings in Python source code comments while doing some research with the help of spelling and grammatic tools. I double checked all of them and corrected. There is just one docstring affected. All the

Re: Increasing the diversity of people who write Python

On Mon, Nov 27, 2017 at 8:09 PM, Alexandre Brault wrote: > A quick Google search turned up WinCompose. It defaults to Right-Alt for > its compose key, but that's configurable > > On 2017-11-27 02:05 PM, Paul Moore wrote: >> On 27 November 2017 at 18:13, Skip Montanaro

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

al on python-ideas, and we have already discussed many aspects including straw-man arguments about fonts,etc Mikhail -- https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

On Fri, Nov 24, 2017 at 9:08 PM, Chris Angelico <ros...@gmail.com> wrote: > On Sat, Nov 25, 2017 at 7:00 AM, Mikhail V <mikhail...@gmail.com> wrote: >> I agree that one should have more choices, but >> people still can't really choose many things. >> I can't ch

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

On Fri, Nov 24, 2017 at 5:37 PM, Chris Angelico <ros...@gmail.com> wrote: > On Sat, Nov 25, 2017 at 3:33 AM, Mikhail V <mikhail...@gmail.com> wrote: >> On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico <ros...@gmail.com> wrote: >> >>>> and in Python

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

oks. In textbooks at least I can help it by proper layout - separating them in tables, or putting in quotes or bold for inline usage. Mikhail -- https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

On Fri, Nov 24, 2017 at 4:13 AM, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Nov 24, 2017 at 1:44 PM, Mikhail V <mikhail...@gmail.com> wrote: >> From my above example, you could probably see that I prefer somewhat >> middle-sized identifiers, one-two syllable

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

On Thu, Nov 23, 2017 at 10:05 PM, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Nov 24, 2017 at 8:02 AM, Mikhail V <mikhail...@gmail.com> wrote: >> On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico <ros...@gmail.com> wrote: >>> On Fri, Nov 24, 2017 at 7:38

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V <mikhail...@gmail.com> wrote: >> I see you manually 'optimise' the look? >> I personally would end with something like this: >> >> def zip

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

But if you only ask which code of two looks better for me, then, probably Second, but it has some issues for me, e.g. "c" and "e" almost homoglyhs, too loose 'sieve'-like, short lines. Mikhail -- https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

On Thu, Nov 23, 2017 at 8:46 PM, Thomas Jollans <t...@tjol.eu> wrote: > On 23/11/17 19:42, Mikhail V wrote: >> I mean for a real practical situation - for example for an average >> Python programmer or someone who seeks a programmer job. >> And who does not have a 50

Benefits of unicode identifiers (was: Allow additional separator in identifiers)

Chris A wrote: >> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote: >> >>> Chris A wrote: >>> >>> Fortunately for the world, you're not the one who decided which >>> characters were permitted in Python identifiers. The ability to use >>>

Re: Allow additional separator character in variables

Chris A wrote: On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote: > > > Well, then there is some bitter irony in this, so it allows pretty > > much everything, > > but does not allow me to beautify code with hyphens. > > I can fully understand the wish to use n

Re: how to read in the newsreader

regular Usenet group. > > > > Does it set the References header correctly when replying? Hi Thomas, regarding the issue with my reply-to header you told me recently - Does this message looks ok in your threaded view now? Now I reply by the href of the message I looked up in pipermail

Lies in education [was Re: The "loop and a half"]

Bill wrote: > Mikhail V wrote: > > Python? Superior syntax for sure > > I believe that. What accounts for the popularity of PHP then? I can't tell for PHP for sure... As in many cases in software world, there is a principle of "who was the first there to solve some

Lies in education [was Re: The "loop and a half"]

> >> [...] I'm not here to "cast stones", I like Python. I just think > >> that you shouldn't cast stones at C/C++. > > Not while PHP exists. There aren't enough stones in the world... > > > > PHP seems (seemed?) popular for laying out web pages. Are their vastly > superior options? Python?

Keyboard Input [was: The "loop and a half"]

Chris Angelico wrote: > On Mon, Oct 9, 2017 at 7:05 PM, Mikhail V wrote: > > The first thing a developer should provide - the keys and mouse input > > should be > > *customizable* by the user. It is so by most serious application I have > > ever used. > > A

The "loop and a half"

it, even seldom, then certainly I want a GUI on it (not just to see a desktop wallpaper ;). > streaming the screen contents of a rich GUI around the world may be not > be possible for bandwidth or delay reasons. Sure, streaming video consumes a lot, but that is what one tries to avoid if under li

The "loop and a half"

lowercase letters with Shift is historically there just for the 'symmetry'. Obviously there is zero practical need for that in general case, so "probably no one else need this" is quite appropriate statement. > I have wanted to produce a lower-case letter by holding Shift. Ok, once in my

The "loop and a half"

n on 386 computers there was graphics and keybord input. That is definitely what I would want for editing files. Yes I've tried line by line eding back in DOS times and that really sucks. Mikhail -- https://mail.python.org/mailman/listinfo/python-list

[issue31678] Incorrect C Function name for timedelta

Change by Mironov Mikhail <phobos...@gmail.com>: -- keywords: +patch pull_requests: +3850 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31539] asyncio.sleep may sleep less time then it should

Mikhail Gerasimov added the comment: STINNER Victor, thanks for explanation! I don't know if this issue has practical disadvantages, but such behavior seems to be confusing, especially, since it can be reproduced with event_loop.time() and asyncio doc says nothing about resolution - https

[issue31539] asyncio.sleep may sleep less time then it should

New submission from Mikhail: Originally faced here: https://stackoverflow.com/q/46306660/1113207 Simple code to reproduce: import asyncio import time async def main(): while True: asyncio.ensure_future(asyncio.sleep(1)) t0 = time.time

Proposed new syntax

> > What would you expect this syntax to return? > > [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5] > Nice question BTW I'd suppose two possible outcomes: a) It will behave exactly the same as if there was "if" instead of "while" so [1, 2, 3, 4, 5]. b) It will return syntax error, because

Grapheme clusters, a.k.a.real characters

Steven D'Aprano wrote: >On Wed, 19 Jul 2017 10:34 am, Mikhail V wrote: >> Ok, in this narrow context I can also agree. >> But in slightly wider context that phrase may sound almost like: >> "neither geometrical shape is better than the other as a basis >> for a whe

Grapheme clusters, a.k.a.real characters

ChrisA wrote: >On Wed, Jul 19, 2017 at 6:05 AM, Mikhail V wrote: >> On 2017-07-18, Steve D'Aprano <steve+python at pearwood.info> wrote: >> >>> That's neither better nor worse than the system used by English and French, >>> where letters with dicriti

  1   2   3   >