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 would be ok with {L} and {R} - easy on eye and easy to

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

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.

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

Paul Moore writes : If you discover any bugs while testing the new release, please report > them at https://github.com/pypa/pip/issues. Link not working (on pipermail archive -- remove the period on the end) https://github.com/pypa/pip/issues PS: was looking forward to PIP improvements on

Re: Simple graphic library for beginners

On Fri, Jan 12, 2018 at 10:38 AM, Paul Moore wrote: > On 12 January 2018 at 06:47, Steven D'Aprano > wrote: >> If pip is joined at the hip to a specific version of Python, I think that >> we ought to be able to specify the version

Simple graphic library for beginners

> > But the OP isn't looking for a full-blown GUI toolkit. I went back and > > re-read his post to be sure I wasn't misunderstanding. Therefore I > > don't think the suggestion to use wxPython or PyQt is that helpful. > > > > Do you have any other suggestions? > > > > Even Cairo is pretty

Goto

MRAB wrote: > It's OK for code that's close to the metal, but in high-level code? No. > Python has managed for >25 years without it, and I've yet to see a > convincing use-case. "convincing" is a broad term I think, especially for syntax proposals ;) I think often one wish to use it just to

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)

On Fri, Nov 24, 2017 at 11:26 PM, Richard Damon wrote: > > Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in > fact it is in XID_START) so should be available. > Hi Richard. U+2010 is SyntaxError. 5 days ago I made a proposal on python-ideas,

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)

On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico wrote: >> and in Python in particular, because they will be not only forced to learn >> some english, but also will have all 'pleasures' of multi-script editing. >> But wait, probably one can write python code in, say Arabic

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)

On Thu, Nov 23, 2017 at 8:15 PM, Chris Angelico wrote: > > Let's start with a simpler question. Which of these is better code? > > # == Option 1 > class ZipExhausted(Exception): > pass > > def zip_longest(*args, **kwds): > # zip_longest('ABCD', 'xy', fillvalue='-')

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

Thomas wrote: > > On 16/10/17 20:02, Pete Forman wrote: > > Thomas Jollans writes: > > ... > >>> If you do stick with a digest then check your newsreader for a feature > >>> to expand it. Then you can read and reply as if you were getting > >>> individual posts. > >>> > >> That exists? How does

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"

>>> Have you ever worked on a slow remote session where a GUI is >>> completely impracticable (or maybe even unavailable), and redrawing >>> the screen is too expensive to do all the time? >> >> So where does the redrawing happen? The machine youre sitting on (let's >> call it 'A') and send remote

The "loop and a half"

bartc wrote: >> Your job is to port an editor that people have been using for 30 years to >> Linux. The first thing you do is to change all the commands and shortcuts to >> match what is typical on Linux? So that no-one who was familiar with it as >> it was can actually use it? Chris Angelico

The "loop and a half"

bartc wrote: >> But as it happens, I could make computers talk to each when I was working >> with microprocessors, using home-made interfaces, rs232 or rs423. I wouldn't >> know how to do it now because it depends on other people's over-complex >> tech. Chris Angelico wrote: > I don't know if

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

Grapheme clusters, a.k.a.real characters

Marko Rauhamaa wrote: >What did you think of my concrete examples, then? (Say, finding >"Alvárez" with the regular expression "Alv[aá]rez".) I think that should match both "Alvarez" and "Alvárez" ...? But firstly, I feel like I need to _guess_ what ideas you are presenting. Unless I open up Vim

Grapheme clusters, a.k.a.real characters

On 2017-07-18, Steve D'Aprano wrote: > That's neither better nor worse than the system used by English and French, > where letters with dicritics are not distinct letters, but guides to > pronunciation. >_Neither system is right or wrong, or better than the

Grapheme clusters, a.k.a.real characters

ChrisA wrote: >Yep! Nobody would take any notice of the fact that you just put dots >on all those letters. It's not like it's going to make any difference >to anything. We're not dealing with matters of life and death here. >Oh wait.

Grapheme clusters, a.k.a.real characters

ChrisA wrote: >On Sun, Jul 16, 2017 at 2:33 PM, Rustom Mody wrote: >> Right now in an adjacent mailing list (debian) I see someone signed off with >> a >> >> grüß >> >> I guess the third character is a u with some ‘dirt’ >> Whats the fourth? >It's a "sharp S". or "Eszett", is a merge of two

Grapheme clusters, a.k.a.real characters

>> On Sat, 15 Jul 2017 05:50 pm, Marko Rauhamaa wrote: >>> Random access to code points is as uninteresting as random access to >>> UTF-8 bytes. I might want random access to the "Grapheme clusters, >>> a.k.a.real characters". >> >> What _real_ characters are you referring to? >> If your data has

Grapheme clusters, a.k.a.real characters

On Sat, 15 Jul 2017 05:50 pm, Marko Rauhamaa wrote: > Random access to code points is as uninteresting as random access to > UTF-8 bytes. > I might want random access to the "Grapheme clusters, a.k.a.real > characters". What _real_ characters are you referring to? If your data has "á" (U00E1),

Re: Scala considering significant indentation like Python

> The creator of Scala, Martin Odersky, has proposed introducing Python-like > significant indentation to Scala and getting rid of braces: > > I was playing for a while now with ways to make Scala's syntax >indentation-based. I always admired the neatness of Python syntax >and also found

Re: String escaping utility for Python (was: Rawest raw string literals)

On 23 April 2017 at 05:03, MRAB <pyt...@mrabarnett.plus.com> wrote: > On 2017-04-22 23:30, Mikhail V wrote: >> >> On 20 April 2017 at 23:54, MRAB <pyt...@mrabarnett.plus.com> wrote: >> > On 2017-04-20 22:03, Mikhail V wrote: >> >> >> >>

Re: String escaping utility for Python (was: Rawest raw string literals)

On 23 April 2017 at 02:33, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Apr 23, 2017 at 10:19 AM, Mikhail V <mikhail...@gmail.com> wrote: >> On 23 April 2017 at 00:48, Chris Angelico <ros...@gmail.com> wrote: >>> On Sun, Apr 23, 2017 at 8:30 AM, Mi

Re: String escaping utility for Python (was: Rawest raw string literals)

On 23 April 2017 at 00:48, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Apr 23, 2017 at 8:30 AM, Mikhail V <mikhail...@gmail.com> wrote: >> The purpose is simple: reduce manual work to escape special >> characters in string literals (and escape non-ASCII char

String escaping utility for Python (was: Rawest raw string literals)

On 20 April 2017 at 23:54, MRAB <pyt...@mrabarnett.plus.com> wrote: > On 2017-04-20 22:03, Mikhail V wrote: >> >> On 20 April 2017 at 22:43, Random832 <random...@fastmail.com> wrote: >>> [snip] >>> >>> The best solution I can think of is to hav

Re: Rawest raw string literals

On 20 April 2017 at 18:40, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > On 2017-04-20, Mikhail V <mikhail...@gmail.com> wrote: >> On 20 April 2017 at 17:59, Grant Edwards <grant.b.edwa...@gmail.com> wrote: >>> On 2017-04-20, Mikhail V <mikhail...@gmail.

Re: Rawest raw string literals

On 20 April 2017 at 22:43, Random832 wrote: > On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote: >> On 2017-04-20, MRAB wrote: >> > There _is_ a "universal solution"; it's called a Hollerith constant. :-) >> >> Wow, I haven't seen one of

Re: Rawest raw string literals

On 20 April 2017 at 19:27, Chris Angelico wrote: > On Fri, Apr 21, 2017 at 2:26 AM, wrote: >> I find this:- >> >> s = r"ffmpeg -i '\\server-01\D\SER_Bigl.mpg' " >> >> vastly superior. > > It's semantically different though. I don't know whether single

Re: Rawest raw string literals

On 20 April 2017 at 17:59, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > On 2017-04-20, Mikhail V <mikhail...@gmail.com> wrote: >> Quite often I need raw string literals for concatenating console commands. >> I want to input them exactly as they are in pytho

Re: Rawest raw string literals

On 20 April 2017 at 17:55, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V <mikhail...@gmail.com> wrote: >> What I think: why there is no some built-in function, for example like: >> s = raw("ffmpeg -i "\\server-01\D\SER_

Re: Rawest raw string literals

On 20 April 2017 at 17:44, Mikhail V <mikhail...@gmail.com> wrote: > Quite often I need raw string literals for concatenating console commands. > I want to input them exactly as they are in python sources. > > There is r"" string, but it is obviously not enough because

Rawest raw string literals

Quite often I need raw string literals for concatenating console commands. I want to input them exactly as they are in python sources. There is r"" string, but it is obviously not enough because e.g. this: s = r"ffmpeg -i "\\server-01\D\SER_Bigl.mpg" " is not valid. The closest I've found is

Re: Looping [was Re: Python and the need for speed]

On 17 April 2017 at 04:00, Steve D'Aprano wrote: > On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote: > >> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano >> declaimed the following: >> >>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:

Re: "Goto" statement in Python

On 14 April 2017 at 03:44, Steve D'Aprano wrote: > On Fri, 14 Apr 2017 12:52 am, bartc wrote: > >> I know this isn't the Python need-for-speed thread, but this is a >> classic example where the lack of one simple feature leads to using >> slower, more cumbersome ones.

Re: "Goto" statement in Python

On 13 April 2017 at 19:38, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Thu, Apr 13, 2017 at 11:25 AM, Mikhail V <mikhail...@gmail.com> wrote: >> On 13 April 2017 at 18:48, Ian Kelly <ian.g.ke...@gmail.com> wrote: >>> On Thu, Apr 13, 2017 at 10:23 AM, Mi

Re: "Goto" statement in Python

On 13 April 2017 at 18:48, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V <mikhail...@gmail.com> wrote: >> Now I wonder, have we already collected *all* bells and whistles of Python >> in these two examples, or is there something

Re: "Goto" statement in Python

On 13 April 2017 at 02:17, Rob Gaddi wrote: > > def finder: > for s in S: > if s == 'i': > return 'found on stage 1' > > S = S + ' hello world' > for s in S: > if s == 'd': > return 'found on stage 2' > > raise ValueError('not found;

"Goto" statement in Python

On 12 April 2017 at 02:44, Nathan Ernst wrote: > goto is a misunderstood and much misaligned creature. It is a very useful > feature, but like nearly any programming construct can be abused. > > Constructs like 'break', 'continue' or 'next' in languages like Python or >

Re: Python and the need for speed

On 12 April 2017 at 00:02, Rick Johnson <rantingrickjohn...@gmail.com> wrote: > On Monday, April 10, 2017 at 7:25:48 AM UTC-5, Mikhail V wrote: >> Still I miss some old school features in Python, e.g. >> "goto" statement would be very useful in some cases. >

Re: Python and the need for speed

On 11 April 2017 at 23:45, MRAB <pyt...@mrabarnett.plus.com> wrote: > On 2017-04-11 21:58, Mikhail V wrote: >> >> On 11 April 2017 at 16:56, Steve D'Aprano <steve+pyt...@pearwood.info> >> wrote: >>> >>> On Tue, 11 Apr 2017 07:56 pm, Br

Re: Pound sign problem

On 10 April 2017 at 15:17, David Shi via Python-list wrote: > In the data set, pound sign escape appears: > u'price_currency': u'\xa3', u'price_formatted': u'\xa3525,000', > When using table.to_csv after importing pandas as pd, an error message > persists as follows: >

Re: Python and the need for speed

On 11 April 2017 at 16:56, Steve D'Aprano wrote: > On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote: > >[...] > >> DropBox and >> Google seem to agree that there are no good solutions, since they are >> moving to Go. > > That's a good solution! Maybe we should be

Re: Python and the need for speed

On 10 April 2017 at 02:21, Gregory Ewing wrote: > > > > My take on the idea of making Python less dynamic in order > to improve speed is that you'll end up with a language that, > while it may superficially resemble Python, doesn't > really feel like Python. > >

Re: Text-mode apps (Was :Who are the "spacists"?)

On 3 April 2017 at 19:55, Steve D'Aprano wrote: > I didn't see you calling out Rick for his prejudice against those who aren't > American, his absurd belief that "most" people are satisfied with ASCII, Hmm... that is interesting. Everyone has some beliefs... If I

Re: Text-mode apps (Was :Who are the "spacists"?)

On 2 April 2017 at 02:01, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Apr 2, 2017 at 9:25 AM, Mikhail V <mikhail...@gmail.com> wrote: >> On 2 April 2017 at 00:22, Chris Angelico <ros...@gmail.com> wrote: >>> On Sun, Apr 2, 2017 at 8:16 AM, Mi

Re: Text-mode apps (Was :Who are the "spacists"?)

On 2 April 2017 at 00:22, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Apr 2, 2017 at 8:16 AM, Mikhail V <mikhail...@gmail.com> wrote: >> For multiple-alphabet rendering I will use some >> custom text format, e.g. with tags >>

  1   2   >