Re: "Data blocks" syntax specification draft

[Ian Kelly]

On Wed, May 23, 2018 at 12:49 AM, Steven D'Aprano
 wrote:
> On Tue, 22 May 2018 09:43:55 -0600, Ian Kelly wrote:
>
>> In other words, the rule is not really as simple as "commas make
>> tuples". I stand by what I wrote.
>
> Being pedantic is great, but if you're going to be pedantic, it pays to
> be *absolutely correctly* pedantic *wink*
>
> Chris is right to say "commas make tuples", and never implied that making
> tuples is *all* that commas do. That would be an absurd thing for him to
> say. Fortunately he didn't :-)
>
> If your comment had been posed as an addition to Chris' comment ("By the
> by, commas also do this that and the other...") then it would have been
> unobjectionable. But by posing it as a correction ("Although, if the rule
> were really as simple ...") you left yourself wide-open to be criticised
> in turn for failing to be pedantic *enough*.

I don't understand why you read that as a correction and not as an
addition. I never said that Chris was *wrong*. I read my comment as
implying that he was correct, and also that there was more to it.
Maybe you are the one who is being overly pedantic.

> Of course commas can be used elsewhere, just as the use of "if" in if
> statements doesn't prevent us from using that same token in the ternary
> if operator.
>
> In the context of the discussion (namely, the mistaken belief that tuples
> are created by parentheses, which we can often leave out) pointing out
> that commas are *also* used as separators in import statements, lists,
> dicts, function parameter lists etc adds noise but no insight to the
> understanding of tuples.

Then you misunderstood my post. My point was not that commas are also
used for other purposes, but that there are other special cases beyond
the empty tuple where commas alone are insufficient and parentheses
are required to create a tuple.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Abdur-Rahmaan Janhangeer]

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

Comments, suggestions are welcome.
>

nice effort

well as far as i've seen, it is more suited as a data standard than a
direct python integration

why?

same as why do we write .json files, xml files, csv files apart as,
in-source you want to emphasize logic, not data

if it works well and is adopted by nice projects etc, then it might make
it's way into py's support by that way

the only downside to a tab-based standard is readability unless you assure
more or less constant word length. same reasons the guys in here explained
to me why we should not align equal signs. if readability is not an issue,
then xml might be your friend

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 07:47, Steven D'Aprano wrote:

On Tue, 22 May 2018 18:51:30 +0100, bartc wrote:


On 22/05/2018 15:25, Chris Angelico wrote:

[...]

The tuple has nothing to do with the parentheses, except for the
special case of the empty tuple. It's the comma.


No? Take these:

   a = (10,20,30)
   a = [10,20,30]
   a = {10,20,30}

If you print type(a) after each, only one of them is a tuple - the one
with the round brackets.


You haven't done enough testing. All you have done is found that "round
brackets give a tuple, other brackets don't". But you need to test what
happens if you take away the brackets to be sure that it is the round
brackets which create the tuple:

 a = 10, 20, 30  # take away the ()

You still get a tuple. Taking away the [] and {} also give tuples.


If ... is a comma-separated sequence of (2 or more) expressions, then:

 Enclosed with: It yields:

 {...} brackets Set (or dict with key:value items)
 [...] brackets List
 (...) brackets Tuple
  ...  (no) bracketsTuple

Each ... contains commas. But it is what surrounds ..., or that doesn't 
surround ..., that determines what the construction yields. The commas 
are not specific to tuples.



What happens if you add extra brackets?

 a = ((10, 20, 30))  # tuple
 b = ([10, 20, 30])  # list
 c = ({10, 20, 30})  # set


0 items within the list:

()Empty tuple
[]Empty list
{}Empty dict

1 item within the list

(x)   Yields x
[x]   List of one item
{x}   Set of one item

Because () is used for normal bracketing of expression terms, it 
requires this special form to denote a tuple:


(x,)  Tuple of one item

which can ALSO be used to form one element lists, sets and dicts.


What if we take away the commas but leave the brackets? If "brackets make
tuples", then the commas ought to be optional.

 a = (10 20 30)  # SyntaxError


This will be a syntax error with [] and {} as well. I never said the 
commas were optional, only that the resulting type depends on bracketing 
(see above)



The comma is just generally used to separate expressions, it's not
specific to tuples.


Nobody said it was specific to tuples. That would be an absurd thing to
say. What was said is that the comma is what makes tuples, not the
brackets.


Suppose you were parsing Python source, had just processed a term of an 
expression, and the next token was a comma. What came before the term 
may have been (, {, [ or nothing. What comes next, would you call:


  readtuplesequence()

or:

  readexprsequence()

or:

  readexprsequence(type_of_sequence) # ie. tuple, list etc

(assume recursive descent parser). Since they have to accomplish the 
same thing (read series of comma-separated terms), what would be the 
advantage in having a separate routine just for tuples?



--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 07:03, Chris Angelico wrote:

On Wed, May 23, 2018 at 3:32 PM, Christian Gollwitzer  wrote:



I'd think that the definitive answer is in the grammar, because that is what
is used to build the Python parser:

 https://docs.python.org/3/reference/grammar.html

Actually, I'm a bit surprised that tuple, list etc. does not appear there as
a non-terminal. It is a bit hard to find, and it seems that "atom:" is the
starting point for parsing tuples, lists etc.



The grammar's a bit hard to read for this sort of thing, as the only
hint of semantic meaning is in the labels at the beginning. For
example, there's a "dictorsetmaker" entry that grammatically could be
a dict comp or a set comp; distinguishing them is the job of other
parts of the code.


Looking at all the instances of "','" (and there are plenty), none of 
them are tied to anything to do with tuples. Actually 'tuple' doesn't 
appear at all.


'dict' does, presumably because a dict-constructor is different 
syntactically in requiring key:value pairs.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Wed, 23 May 2018 03:02:48 -0600, Ian Kelly wrote:

> Maybe you are the one who is being overly pedantic.

I resemble that remark!



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Steven D'Aprano]

On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:

[...]
>> You haven't done enough testing. All you have done is found that "round
>> brackets give a tuple, other brackets don't". But you need to test what
>> happens if you take away the brackets to be sure that it is the round
>> brackets which create the tuple:
>> 
>>  a = 10, 20, 30  # take away the ()
>> 
>> You still get a tuple. Taking away the [] and {} also give tuples.
> 
> If ... is a comma-separated sequence of (2 or more) expressions, then:
> 
>   Enclosed with: It yields:
> 
>   {...} brackets Set (or dict with key:value items)
>   [...] brackets List
>   (...) brackets Tuple
>...  (no) bracketsTuple

Indeed.

> Each ... contains commas. But it is what surrounds ..., or that doesn't
> surround ..., that determines what the construction yields. The commas
> are not specific to tuples.

Nobody said that they were. You are arguing against a strawman. The 
brackets are not part of tuple syntax. They are sometimes needed for 
grouping, when some other grammatical construct would otherwise take 
precedence. That is all.


>> What happens if you add extra brackets?
>> 
>>  a = ((10, 20, 30))  # tuple
>>  b = ([10, 20, 30])  # list
>>  c = ({10, 20, 30})  # set
> 
> 0 items within the list:
> 
> ()Empty tuple
> []Empty list
> {}Empty dict

Aye ... as we've acknowledged numerous times now, the empty tuple *is* a 
genuine special case, one which *does* rely on an empty pair of round 
brackets.



> 1 item within the list
> 
> (x)   Yields x

Exactly! There is no comma, therefore, there is no tuple.

> [x]   List of one item
> {x}   Set of one item

Neither of these require commas, since you don't need a separator to 
separate a single item. The square brackets *do* specify that the item is 
a list; the curly brackets *do* specify a dict or set. The round brackets 
DO NOT specify a tuple (except in the empty tuple case).

No comma, no tuple, no matter how emphatically you insert round brackets 
around the item.


> Because () is used for normal bracketing of expression terms, it
> requires this special form to denote a tuple:
> 
> (x,)  Tuple of one item

Incorrect. Yet again, you have failed to do enough testing. No special 
form is required. Only a comma:

py> x = 1,
py> type(x)


It isn't enough to test examples which confirm a hypothesis. You need to 
test examples which also refute it, and see if your hypothesis survives 
the challenge.

Certainly commas are used as separators. They're used as separators in 
many different contexts: import statements, function calls, function 
declarations, class declarations, except statements, list displays, etc. 
We don't dispute that or deny it.

But in the context of "tuple displays" (the official terminology for 
tuple so-called "literal" syntax), the brackets are not part of the tuple 
display. It is the commas that tell the interpreter that the result is a 
tuple:

https://docs.python.org/3/reference/expressions.html#expression-lists

Because commas are used as separators in so many places, there is often a 
clash between one part of the grammar that uses commas and their use in 
tuples, requiring us to disambiguate the syntax with brackets.

https://docs.python.org/3/reference/expressions.html#parenthesized-forms


> which can ALSO be used to form one element lists, sets and dicts.

But *unlike* one-element lists, sets and dicts, where the comma is 
optional, it is *required* for tuples.


[...]
> Suppose you were parsing Python source, had just processed a term of an
> expression, and the next token was a comma. What came before the term
> may have been (, {, [ or nothing. What comes next, would you call:
[...]

I don't even understand what point you think you are making here. But it 
really doesn't matter. Ultimately, the grammar and documentation trumps 
any hypotheses we might have about what the language is doing, and they 
are absolutely clear about what is going on:


https://docs.python.org/3/reference/expressions.html#expression-lists
https://docs.python.org/3/reference/expressions.html#parenthesized-forms


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: "Data blocks" syntax specification draft

[Dan Strohl via Python-list]

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 reding the 
old thread due to some of the more heated conversations in there.

> 
> Though hard-coded knock-out is also very useful, e.g. for this:
> 
> data = /// s4
> First line indented more (8 spaces)
> second - less (4 spaces)
> rest code
> 
> So this will preserve formatting.
> 

True, but in everything, there is a balance between flexibility and complexity. 
 Nothing else in python (that I can think of) forces people to use 4 spaces, 
that's merely a style thing.  If I want to use 2 spaces, I can, I've seen 
modules that use 3 spaces for indenting and it works fine.  So, the flexibility 
of adding the ability to further indent the first line seems to me to be 
outweighed by the added complexity of this being "different".

> 
> >> data = /// "???"
> >> ??? abc foo bar
> >> ???
> >>
> >> - defines indent character by string: crazy idea but why not.
> >>
> >
> > Nope, don't like this one... It's far enough from Python normal that
> > it seems unlikely to not get through, and (personally at least), I struggle 
> > to
> see the benefit.
> 
> Heh, that was merely joke - but OTOH one could use it for hard-coded indent
> sequences:
> 

Yeah, I get it (now  ), I would caution against making jokes in the 
middle of an already controversial thread.  When they are missed, they tend to 
be used against your suggestion.


> data = /// ""
> First line indented more (8 spaces)
> second - less (4 spaces)
> rest code
> 
> A bit sloppy look, but it generalizes some uses. But granted - I don't see 
> much
> real applications besides than space and tab indented block anyway - so it's
> under question.
> 
> 
> >> Language  parameter, e.g.:
> >> data = /// t1."yaml"
> >>
> >> -this can be reserved for future usage by code analysis tools or
> >> dynamic syntax highlighting.
> >>
> >
> > I can see where this might be interesting, but again, I just don't see
> > the need,
> 
> I think you're right  - if need a directive for some analysis tool then one 
> can
> make for example a consideration to precede the whole statement with a
> directive, say in a comment:
> 
> # lang "yaml"
> data = /// t
> first line
> last line
> rest
> 
> 

Again, you're complicating the thought without really providing enough benefit 
to it to justify the complication.   Something to keep in mind when you look at 
most languages, the simpler the language primitives the better, added 
flexibility can (and should) be added later in modules and functions.  But 
primitives should have as few caveats as possible, they should work pretty much 
anywhere with very little needed documentation.  To me, the idea of an indented 
TQS idea (data-string, data block, whatever) Is interesting.  Extra features 
are fine, but when they start making it "more complex" to use, then you should 
back off.

> 
> 
> Also I am thinking about this - there might be one useful 'hack".
> One could even allow single-line usage, e.g.; (with a semicolon)
> 
> data = /// s2:  first line
> 
> - so this would start parsing just after colon :
> "pretending it is block.
> This may be not so fat-fingered-proof and 'inconsistent', but in the end of 
> the
> day, might be a win actually.
> 
> 

If you are thinking about this road, what about instead making another reserved 
word and approaching it like class or def, for example;

datablock data:
first line
second line

Then you can also add functions without "breaking" python approaches like:

datablock data(foo, bar, blah):
First line
Second line

(*having thrown this out, I don’t know the parser/compiler well enough to know 
if this would cause more problems or not).

Being honest, I'm not sure that even these would be enough to get it added 
without a stronger case, but the further you stray from the python norms, the 
less likely it is to even get consideration.  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Chris Angelico]

On Wed, May 23, 2018 at 11:11 PM, Steven D'Aprano
 wrote:
> On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:
>> 0 items within the list:
>>
>> ()Empty tuple
>> []Empty list
>> {}Empty dict
>
> Aye ... as we've acknowledged numerous times now, the empty tuple *is* a
> genuine special case, one which *does* rely on an empty pair of round
> brackets.

We actually have THREE special cases and only two types that follow
the general case. Here's the general case:

List of three: [1, 2, 3] or [1, 2, 3,]
List of two: [1, 2] or [1, 2,]
List of one: [1] or [1,]
List of zero: []

Dict of three: {1:1, 2:2, 3:3} or {1:1, 2:2, 3:3,}
Dict of two: {1:1, 2:2} or {1:1, 2:2,}
Dict of one: {1:1} or {1:1,}
Dict of zero: {}

Perfect! Now let's try that with other types.

Tuple of three: 1, 2, 3 or 1, 2, 3,
Tuple of two: 1, 2 or 1, 2,
Tuple of one: 1, # no other way to do it
Tuple of zero: ()

Set of three: {1, 2, 3} or {1, 2, 3,}
Set of two: {1, 2} or {1, 2,}
Set of one: {1} or {1,}
Set of zero: set()

The empty set and empty tuple are special, as is the single-element
tuple (you can't omit the comma). So, yes, there are definitely
special cases in the grammar, and they come about because practicality
beats purity. If we wanted perfectly clean grammar with no special
cases, we'd probably have to use two-character bracketings, to ensure
that everything is uniquely spellable, and there'd be no omitting them
from tuples - so it really WOULD be the bracketing characters that
define a tuple. But what would we gain? Very little. A few less
special cases, maybe, in return for needing to write more verbose
syntax for every literal/display type.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Usenet Gateway (was: Spam levels.)

[Peter J. Holzer]

On 2018-05-23 10:00:56 -0400, Dennis Lee Bieber wrote:
> On Wed, 23 May 2018 08:01:35 +0200, dieter  declaimed
> the following:
> 
> >Maybe something went wrong with the integration of your NTTP server
> >with the Gmane one?
> 
>   GMANE doesn't (to my knowledge) peer to NNTP servers. It provides an
> NNTP interface to archives of /mailing lists/.

I was quite sure that it did, but it is likely that I mis-remember.

I looked into the newsgroup and there are indeed no messages injected by
gmane. Messages posted to gmane are sent to the mailinglist and (like
all other messages from the mailinglist) injected into usenet through
the gateway at uni-berlin.de.

It seems that this gateway changes all message-ids to 
 

Although the message ids look like they are generated by the mailing
list software (they contain "mailman" and "python-list"), they are only
in the usenet postings, not in the messages sent to mailing list
subscriberts, so I think it must be the gateway that generates these
ids.

(I checked this for a few recent messages from the mailing list). 

This is what I thought I saw gmane doing, so it is very likely that I
was mistaken and that it the gateway at uni-berlin.de all along.

I apologize for attributing the error to Gmane.

Are the persons running the gateway reading this list? Could you please
fix this? Changing message-ids is an absolute no-no.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Target WSGI script cannot be loaded as Python module.

[John Gordon]

In <34bc9890-90c9-473d-bd26-3f62264aa...@googlegroups.com> 
=?UTF-8?B?zp3Or866zr/Pgg==?=  writes:

> I have both python installed in parallel.
> python2.7 and python3.6

> I have installed the modules as

> pip3.6 install bottle bottle-pymysql geopip2
> and they were installed successfully.

Is your web server using Python 2 or Python 3 to execute WSGI?

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway (was: Spam levels.)

[Abdur-Rahmaan Janhangeer]

can someone explain to me why the mailing list (spam free) is not used by
everybody?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway (was: Spam levels.)

[Gene Heskett]

On Wednesday 23 May 2018 11:20:34 Abdur-Rahmaan Janhangeer wrote:

> can someone explain to me why the mailing list (spam free) is not used
> by everybody?
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ

Brain damaged by facebook, AOL, M$, Google, yahoo yadda yadda into 
thinking that webmail and forums are the only game in town?

They can run them thru their browser, and never were taught any 
different. My own ISP is so brain washed by imap users, that fetchmail 
is not allowed to delete what its has pulled, so I have to login to the 
webmail interface every day with a browser and delete by hand, those 
messages I've allready read with kmail. Its a time sink, and a right 
pain in the ass but thats how it is. With fetchmail/procmail/clamav and 
spamassassin handling the incoming mail, I am reduced to hitting the 
plus key to go to the next unread msg, select the reply mode if I reply, 
edit the response, and a ctrl+return sends it. You can't get it any 
simpler than that. Computers were sold to us as a way to do some of our 
work, but mention how my computer does all that for me and those folks 
are totally aghast at the thought of actually getting the computer to do 
it for them.  I ran out of sympathy for those folks nearly 2 decades 
ago, when I had a full house Amiga doing all that for me.

So I lurk here, hoping some python know how might stick to me, and issue 
a rant when I feel its needed. Sorry, but your post was a trigger, so I 
went into rant mode.

Take care now.  And enjoy the list but be aware that at times the spam is 
replaced with snarky stuff. Much of it well earned.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Indented multi-line strings (was: "Data blocks" syntax specification draft)

[Peter J. Holzer]

On 2018-05-22 23:25:36 +, Dan Strohl via Python-list wrote:
> > So, e.g. this:
> > 
> > data = /// s4
> > first line
> > last line
> > the rest python code
> > 
> > - will parse the block and knock out leading 4 spaces.
> > i.e. if the first line has 5 leading spaces then 1 space will be left in 
> > the string.
> > Block parsing terminates when the next line does not satisfy the indent
> > sequence (4 spaces in this case).
> > Another obvious type: tabs:
> 
> OK, I CAN see this as a potentially useful suggestion.  There are a
> number of times where I would like to define a large chunk of text,
> but using tqs and having it suddenly move to the left is painful
> visually.  Right now, I tend to either a) do it anyway, b) do it in a
> separate module and import the variables, or c) do it and parse the
> string to remove the extra spaces.

Agreed.


> Personally though, I would not hard code it to knock out 4 leading
> spaces.   I would have it handle spaces the same was that the existing
> parser does, if there are 4 spaces indending the next line, then it
> removes 4 spaces, if there are 6 spaces, it removes 6 spaces, etc...
> ignoring additional spaces within the data-string object.  Once it
> hits a line that has the same number if indenting spaces as the
> initial token, the data-string object is finished.

How about this?

x = 
Here is a multi-line string
with
  indentation.


This would be equivalent to 

x = 'Here is a multi-line string\nwith\n  indentation.'

Rules:

 * The leading and trailing  must be aligned vertically.
 * The contents of the string must be indented at least as far as the
   delimiters (and with consistent tabs/spaces).
   This leading white space is ignored.
 * All the leading white space beyond this 'left edge' is preserved.
 * The newlines after the leading  and before the trailing  are
   ignored, all the others preserved. (I thought about preserving the
   trailing newline, but it is easier to add one than remove one.)

hp


-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 14:11, Steven D'Aprano wrote:

On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:

(x,)  Tuple of one item


Incorrect. Yet again, you have failed to do enough testing. No special
form is required. Only a comma:

py> x = 1,
py> type(x)


It isn't enough to test examples which confirm a hypothesis. You need to
test examples which also refute it, and see if your hypothesis survives
the challenge.


I use this trailing comma scheme in my own own languages too. The reason 
is simple, it is to distinguish between these two:


  (x) Ordinary bracketed expression
  (x) A list (in my case) of one item.

That is not needed for one less item: (), or one more: (x,y). Like 
Python, that trailing comma is not needed for [x] (I don't have a {...} 
constructor).


In both languages, it's just a hack to get around a syntax clash in the 
language.


I don't say however, that the comma is the defining feature of a list.

Comma is used to separate items of /any/ kind of list, and that trailing 
comma is used when there is an ambiguity or a conflict.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)

[Dan Strohl via Python-list]

> 
> > Personally though, I would not hard code it to knock out 4 leading
> > spaces.   I would have it handle spaces the same was that the existing
> > parser does, if there are 4 spaces indending the next line, then it
> > removes 4 spaces, if there are 6 spaces, it removes 6 spaces, etc...
> > ignoring additional spaces within the data-string object.  Once it
> > hits a line that has the same number if indenting spaces as the
> > initial token, the data-string object is finished.
> 
> How about this?
> 
> x = 
> Here is a multi-line string
> with
>   indentation.
> 
> 
> This would be equivalent to
> 
> x = 'Here is a multi-line string\nwith\n  indentation.'
> 

Looks right to me, I don't know if the quad quote overloads the ' and " 
character too much, but I'm not against it.


> Rules:
> 
>  * The leading and trailing  must be aligned vertically.
>  * The contents of the string must be indented at least as far as the
>delimiters (and with consistent tabs/spaces).
>This leading white space is ignored.
>  * All the leading white space beyond this 'left edge' is preserved.
>  * The newlines after the leading  and before the trailing  are
>ignored, all the others preserved. (I thought about preserving the
>trailing newline, but it is easier to add one than remove one.)
> 
> hp
> 
> 


These sound good to me.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[bartc]

On 23/05/2018 14:56, Chris Angelico wrote:


Perfect! Now let's try that with other types.

Tuple of three: 1, 2, 3 or 1, 2, 3,

Not requiring any bracketing is poor IMO.

If you wanted the tuple to co-exist with any other thing in an 
expression, rather than being the only thing the expression comprises, 
then you will run into problems. Try adding two tuples:


  1, 2, 3 + 4, 5, 6

This in fact gives you 1,2,7,5,6 rather than 5,7,9. (I don't know if 
tuples can actually be added like this, but the point is clear.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Target WSGI script cannot be loaded as Python module.

[Νίκος]

Τη Τετάρτη, 23 Μαΐου 2018 - 6:18:13 μ.μ. UTC+3, ο χρήστης John Gordon έγραψε:

> Is your web server using Python 2 or Python 3 to execute WSGI?

I really dont knwo that detail.
How can i check that?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Chris Green]

Abdur-Rahmaan Janhangeer  wrote:
> can someone explain to me why the mailing list (spam free) is not used by
> everybody?
> 
Because the Usenet/NNTP interface (with a good newsreader) is so much
better! :-)

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Indented multi-line strings

[Mikhail V]

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 reding 
> the old thread due to some of the more heated conversations in there.
>
>>
>> Though hard-coded knock-out is also very useful, e.g. for this:
>>
>> data = /// s4
>> First line indented more (8 spaces)
>> second - less (4 spaces)
>> rest code
>>
>> So this will preserve formatting.
>>

> True, but in everything, there is a balance between
> flexibility and complexity. Nothing else in python
> (that I can think of) forces people to use 4 spaces,
> that's merely a style thing.  If I want to use 2 spaces,
> I can, I've seen modules that use 3 spaces for
> indenting and it works fine.  So, the flexibility of
> adding the ability to further indent the first line seems
> to me to be outweighed by the added complexity
> of this being "different".

I think we might have a misunderstanding here.
I admit I have tendency to use false terms sometimes -
in this case I did not mean "hard-coded", but rather with
parameter which is taken by the parser.

Namely the proposal is to use 'de-dention' parameter in
such form:

data = /// sN # and
data = /// tN

Where N - is the amount of characters, spaces (s) or
tabs (t).
This should cover most use cases.
It implies of course that the user should know himself
what he is doing.

More concrete example:

def func():
foobar
data = /// s2
  first line
  last line
foobar

will store same data as:
data = "first linelast line"

(assuming of course no trailing spaces were
in original lines)

So obviously the minimal amount in a parameter is 1,
otherwise it will not work at all.

That's actually it. I am inclining to opinion that no
further parameters are necessary, but of course
there might be few other common use case.
IOW it would be not correct to totally disregard
considering some additional options.



>> # lang "yaml"
>> data = /// t
>> first line
>> last line
>> rest
>
> Again, you're complicating the thought without really
> [...] primitives should have as few caveats as possible.
> [...] Extra features are fine, but when they start making
> it "more complex" to use, then you should back off.>

I 100% agree with you. In this case it is better to concentrate
on the most 'low-level' behaviour.


>> Also I am thinking about this - there might be one useful 'hack".
>> One could even allow single-line usage, e.g.; (with a semicolon)
>>
>> data = /// s2:  first line
>>
>> - so this would start parsing just after colon :
>> "pretending it is block.
>> This may be not so fat-fingered-proof and 'inconsistent', but in the end of 
>> the
>> day, might be a win actually.
>>
>>
>
> If you are thinking about this road, what about
> instead making another reserved word and
> approaching it like class or def, for example;
>
> datablock data:
> first line
> second line

Well it looks ok, but traditionally it is forbidden to introduce
any new keywords, unless it is absolutely necessary.


M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

[Ian Kelly]

On Wed, May 23, 2018 at 10:25 AM, Peter J. Holzer  wrote:
> How about this?
>
> x = 
> Here is a multi-line string
> with
>   indentation.
> 
>
> This would be equivalent to
>
> x = 'Here is a multi-line string\nwith\n  indentation.'
>
> Rules:
>
>  * The leading and trailing  must be aligned vertically.

Ick, why? What's wrong with letting the trailing delimiter be at the
end of a line, or the beginning with no indentation?

>  * The contents of the string must be indented at least as far as the
>delimiters (and with consistent tabs/spaces).
>This leading white space is ignored.
>  * All the leading white space beyond this 'left edge' is preserved.
>  * The newlines after the leading  and before the trailing  are
>ignored, all the others preserved. (I thought about preserving the
>trailing newline, but it is easier to add one than remove one.)

How about we instead just use the rules from PEP 257 so that there
aren't two different sets of multi-line string indentation rules to
have to remember?

https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation

Also, how about using a string prefix character instead of making
quad-quote meaningful? Apart from being hard to visually distinguish
from triple-quote, this would break existing triple-quote strings that
happen to start with the quote character, e.g What?' she asked.'''

I don't know if 'i' would be the right prefix character for this, but
it's unused and is short for 'indented':

b = i'''
Here is a multi-line string
with indentation, which is
determined from the second
line.'''
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting Unicode decode error using lxml.iterparse

[Stefan Behnel]

dieter schrieb am 23.05.2018 um 08:25:
> If the encoding is not specified, "lxml" will try to determine it
> and finally defaults to "utf-8" (which seems to be the correct encoding
> for your case).

Being an XML parser, it does not do that. XML parsers are designed to
reject non-wellformed content, and that includes anything that cannot be
decoded.

In short, if no encoding is specified, then it's UTF-8, but if there is an
XML declaration that specifies that encoding, then it uses that encoding.

Here, the encoding is specifed as UTF-8, so that's what the parser uses.

Note, however, that the library that the OP uses is not lxml but xml.etree,
i.e. the ElementTree XML support in the standard library.

Stefan

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting Unicode decode error using lxml.iterparse

[Stefan Behnel]

digi...@gmail.com schrieb am 23.05.2018 um 00:56:
> I'm trying to read my iTunes library in Python using iterparse. My current 
> stub is:
> 
>  Snip 
> 
> import sys
> import datetime
> import xml.etree.ElementTree as ET
> import argparse
> import re
> 
> class Library:
> 
> unmarshallers = {
> # collections
> "array": lambda x: [v.text for v in x],
> "dict": lambda x:
> dict((x[i].text, x[i+1].text) for i in range(0, len(x), 2)),
> "key": lambda x: x.text or "",
> 
> # simple types
> "string": lambda x: x.text or "",
> "data": lambda x: base64.decodestring(x.text or ""),
> "date": lambda x: datetime.datetime(*map(int, re.findall("\d+", 
> x.text))),
> "true": lambda x: True,
> "false": lambda x: False,
> "real": lambda x: float(x.text),
> "integer": lambda x: int(x.text)
> }
> 
> def load(self, file):
> print('Starting...')
> parser = ET.iterparse(file)
> for action, elem in parser:
> unmarshal = self.unmarshallers.get(elem.tag)
> if unmarshal:
> data = unmarshal(elem)
> elem.clear()
> elem.text = data
> print(elem.text)
> elif elem.tag != "plist":
> raise IOError("unknown plist type: %r" % elem.tag)
> return parser.root[0].text
> 
> def __init__(self, infile):
> self.root = self.load(infile)
> 
> if __name__ == "__main__":
> parser = argparse.ArgumentParser(description = "Parse an iTunes library 
> file to a set of CSV files suitable for import to a database.")
> parser.add_argument('infile', nargs='?', type=argparse.FileType('r'), 
> default=sys.stdin)
> args=parser.parse_args()
> print('Infile = ', args.infile)
> library = Library(args.infile)
> 
> 
> My input file (reduced to home in on the error) is:
> 
> 
>  snip -
> 
> 
> 
> 
>   
>   15078
>   
>   NamePart 2. The Death Of Enkidu. 
> Skon Přitele Mého Mne Zdeptal Težče
>   
>   
> 
> 
> 
>  snip 
> 
> 
> 
> 
> 
>   
>   15078
>   
>   NamePart 2. The Death Of Enkidu. 
> Skon Přitele Mého Mne Zdeptal Težče
>   
>   
> 
> 
> 
> 
> 
> I'm getting an error on one part of the XML:
> 
> 
>  File "C:\Users\digit\Anaconda3\lib\encodings\cp1252.py", line 23, in decode
> return codecs.charmap_decode(input,self.errors,decoding_table)[0]
> 
> UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 202: 
> character maps to 
> 
> 
> I suspect the issue is that it's using cp1252.py, which I don't think is 
> UTF-8 as specified in the XML prolog. Is this an iterparse problem, or am I 
> using it wrongly?

You are not showing enough of the stack trace to properly diagnose this
problem, but seeing your code, my educated guess is that the problem is the
encoding of the file *path name* and not the *content* of the XML file.
I.e. it probably cannot even open the file.

Stefan

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Indented multi-line strings (was: "Data blocks" syntax specification draft)

[Dan Strohl via Python-list]

> 
> How about we instead just use the rules from PEP 257 so that there aren't two
> different sets of multi-line string indentation rules to have to remember?
> 
> https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation
> 


I like that, better to be closer to the existing standards. One could then see 
this as an extension of the doc-strings.

> Also, how about using a string prefix character instead of making quad-quote
> meaningful? Apart from being hard to visually distinguish from triple-quote,
> this would break existing triple-quote strings that happen to start with the
> quote character, e.g What?' she asked.'''
> 
> I don't know if 'i' would be the right prefix character for this, but it's 
> unused
> and is short for 'indented':
> 

Or go with a different character (or set of characters) altogether... like $, 
\, ~, ^, < ? (good catch on it  catching on hello' I am not in this''', I 
forgot about that behavior)

I'm not against a prefix character, just throwing out alternatives. (though, to 
me, the 'i' indicated int)


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings (was: "Data blocks" syntax specification draft)

[Chris Angelico]

On Thu, May 24, 2018 at 3:08 AM, Ian Kelly  wrote:
> I don't know if 'i' would be the right prefix character for this, but
> it's unused and is short for 'indented':
>
> b = i'''
> Here is a multi-line string
> with indentation, which is
> determined from the second
> line.'''

Since this doesn't change the way the string is parsed, it doesn't
actually NEED to be a prefix letter. I'd like to see this instead:

b = '''
Here is a multi-line string
with indentation, which is
determined from the second
line.'''.dedent()

Implemented as a string method, it would be completely syntactically
forwards and backwards compatible, and could be easily documented
(s.dedent() <=> textwrap.dedent(s)). And methods on literals are open
to being optimized, as there's no way to mess with imports or
anything.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Ned Batchelder]

On 5/23/18 12:03 PM, Gene Heskett wrote:

On Wednesday 23 May 2018 11:20:34 Abdur-Rahmaan Janhangeer wrote:


can someone explain to me why the mailing list (spam free) is not used
by everybody?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

Brain damaged by facebook, AOL, M$, Google, yahoo yadda yadda into
thinking that webmail and forums are the only game in town?




Please avoid accusing others of being brain damaged, even if it was 
meant in a humorous context. :(


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway (was: Spam levels.)

[Grant Edwards]

On 2018-05-23, Abdur-Rahmaan Janhangeer  wrote:

> can someone explain to me why the mailing list (spam free) is not used by
> everybody?

 1) I perfer the user-interface offered by my NNTP client (slrn).

 2) I don't want to archive many years worth of dozens of mailing
lists (I let gmane do that).

-- 
Grant Edwards   grant.b.edwardsYow! I have many CHARTS
  at   and DIAGRAMS..
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to handle captcha through machanize module or any module

[MRAB]

On 2018-05-23 06:22, SACHIN CHAVAN wrote:

On Wednesday, December 18, 2013 at 6:26:17 PM UTC+5:30, Jai wrote:

please do replay how to handle captcha through machanize module


I have the same issue, nothing find a solution yet!

The purpose of captcha is to ensure that talking to a human, not a bot. 
It does that by presenting a task that's impossible, or at least 
extremely difficult, to do, so it's not surprising that you haven't 
found a solution.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Grant Edwards]

On 2018-05-23, Chris Green  wrote:
> Abdur-Rahmaan Janhangeer  wrote:
>> can someone explain to me why the mailing list (spam free) is not used by
>> everybody?
>
> Because the Usenet/NNTP interface (with a good newsreader) is so much
> better! :-)

Yes.  NNTP and NNTP clients were designed from the ground up to deal
with ongoing discussions shared by large groups of people posting lots
of messages, and they're _very_ good at.

Email was designed for one person sending one message to another.

Over the years, people have cobbled together bits and pieces and
features to try to make it work for shared discussions. As a result,
mailing lists mostly work (especially for low-volume "groups") and are
pretty decent compared to "web forums" and other such wastes of
electrons.

But IMO email pales in comparison to NNTP when there are more than a
few messages per day per group.

-- 
Grant Edwards   grant.b.edwardsYow! ... I have read the
  at   INSTRUCTIONS ...
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to handle captcha through machanize module or any module

[Chris Angelico]

On Thu, May 24, 2018 at 4:01 AM, MRAB  wrote:
> On 2018-05-23 06:22, SACHIN CHAVAN wrote:
>>
>> On Wednesday, December 18, 2013 at 6:26:17 PM UTC+5:30, Jai wrote:
>>>
>>> please do replay how to handle captcha through machanize module
>>
>>
>> I have the same issue, nothing find a solution yet!
>>
> The purpose of captcha is to ensure that talking to a human, not a bot. It
> does that by presenting a task that's impossible, or at least extremely
> difficult, to do, so it's not surprising that you haven't found a solution.

Obligatory XKCD: https://xkcd.com/810/ (caution, language - contains a
precision F-strike)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 8:08 PM, Mikhail V  wrote:
> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:

> data = /// sN # and
> data = /// tN
>
> Where N - is the amount of characters, spaces (s) or
> tabs (t).
> This should cover most use cases.
> It implies of course that the user should know himself
> what he is doing.
>
> More concrete example:
>
> def func():
> foobar
> data = /// s2
>   first line
>   last line
> foobar
>
> will store same data as:
> data = "first linelast line"

oops, I meant it to be:
data = "first line\nlast line"

sorry for possible confusion

>
> (assuming of course no trailing spaces were
> in original lines)
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: "Data blocks" syntax specification draft

[Schachner, Joseph]

I understand that the /// data representation is meant to emphasize data 
structure (and de-emphasize existing Python syntax for that purpose).  It's 
already been discussed that Python can export to pickle format, JSON, csv, XML 
and possibly others I can't think of right now.  So having a data 
representation format is not a foreign concept.

All I want to say is that I don't really feel that there is a need for another 
data representation.  Also, even if we leave out parentheses, "/// a,b,c" is 9 
characters, whereas "(a,b,c)" is 7 characters. And "a,b,c" is only 5 
characters.  I think I would actually prefer the usual Python syntax, because 
to me it is clear (I already know Python) and typing fewer characters to 
achieve the same result appeals to me.

Perhaps I just don't value the benefit of this data representation technique, 
or perhaps there really is a benefit that I didn't get. If so forgive me.  But 
I do think that a good exposition of the benefit obtained by using this data 
representation will need to be made, or you may find that there are many other 
people like me.

--- Joseph S.



-Original Message-
From: Chris Angelico  
Sent: Wednesday, May 23, 2018 9:56 AM
To: Python 
Subject: Re: "Data blocks" syntax specification draft

On Wed, May 23, 2018 at 11:11 PM, Steven D'Aprano 
 wrote:
> On Wed, 23 May 2018 11:10:33 +0100, bartc wrote:
>> 0 items within the list:
>>
>> ()Empty tuple
>> []Empty list
>> {}Empty dict
>
> Aye ... as we've acknowledged numerous times now, the empty tuple *is* 
> a genuine special case, one which *does* rely on an empty pair of 
> round brackets.

We actually have THREE special cases and only two types that follow the general 
case. Here's the general case:

List of three: [1, 2, 3] or [1, 2, 3,]
List of two: [1, 2] or [1, 2,]
List of one: [1] or [1,]
List of zero: []

Dict of three: {1:1, 2:2, 3:3} or {1:1, 2:2, 3:3,} Dict of two: {1:1, 2:2} or 
{1:1, 2:2,} Dict of one: {1:1} or {1:1,} Dict of zero: {}

Perfect! Now let's try that with other types.

Tuple of three: 1, 2, 3 or 1, 2, 3,
Tuple of two: 1, 2 or 1, 2,
Tuple of one: 1, # no other way to do it Tuple of zero: ()

Set of three: {1, 2, 3} or {1, 2, 3,}
Set of two: {1, 2} or {1, 2,}
Set of one: {1} or {1,}
Set of zero: set()

The empty set and empty tuple are special, as is the single-element tuple (you 
can't omit the comma). So, yes, there are definitely special cases in the 
grammar, and they come about because practicality beats purity. If we wanted 
perfectly clean grammar with no special cases, we'd probably have to use 
two-character bracketings, to ensure that everything is uniquely spellable, and 
there'd be no omitting them from tuples - so it really WOULD be the bracketing 
characters that define a tuple. But what would we gain? Very little. A few less 
special cases, maybe, in return for needing to write more verbose syntax for 
every literal/display type.

ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: best way to remove leading zeros from a tuple like string

[Dan Stromberg]

On Sun, May 20, 2018 at 12:54 PM,   wrote:
> Lets say I have the following tuple like string.
>   (128, 020, 008, 255)
>
> What is the best way to to remove leading zeroes and end up with the 
> following.
>   (128, 20, 8, 255)-- I do not care about spaces
>
> This is the solution I came up with
> s = "(128, 020, 008, 255)"
> v = s.replace ("(", "")
> v = v.replace (")", "")
> vv = ",".join([str(int(i)) for i in v.split(",")])
> final = "(" + vv + ")"

I actually like your solution pretty well - especially the splitting
on "," and applying int() to the pieces. If you want a simple regex
solution though, the following should work on Python 1.5 through
3.7b3:

$ pythons --command 'import re; print("(" + re.sub("(\(| )0*", "",
"(128, 020, 008, 255)"))'
below cmd output started 2018 Wed May 23 01:23:00 PM PDT
/usr/local/cpython-1.0/bin/python (1.0.1) bad
Traceback (innermost last):
  File "", line 1
ImportError: No module named re
/usr/local/cpython-1.1/bin/python (1.1) bad
Traceback (innermost last):
  File "", line 1, in ?
ImportError: No module named re
/usr/local/cpython-1.2/bin/python (1.2) bad
Traceback (innermost last):
  File "", line 1, in ?
ImportError: No module named re
/usr/local/cpython-1.3/bin/python (1.3) bad
Traceback (innermost last):
  File "", line 1, in ?
ImportError: No module named re
/usr/local/cpython-1.4/bin/python (1.4) bad
Traceback (innermost last):
  File "", line 1, in ?
ImportError: No module named re
/usr/local/cpython-1.5/bin/python (1.5.2) good (128,20,8,255)
/usr/local/cpython-1.6/bin/python (1.6.1) good (128,20,8,255)
/usr/local/cpython-2.0/bin/python (2.0.1) good (128,20,8,255)
/usr/local/cpython-2.1/bin/python (2.1.0) good (128,20,8,255)
/usr/local/cpython-2.2/bin/python (2.2.0) good (128,20,8,255)
/usr/local/cpython-2.3/bin/python (2.3.0) good (128,20,8,255)
/usr/local/cpython-2.4/bin/python (2.4.0) good (128,20,8,255)
/usr/local/cpython-2.5/bin/python (2.5.6) good (128,20,8,255)
/usr/local/cpython-2.6/bin/python (2.6.9) good (128,20,8,255)
/usr/local/cpython-2.7/bin/python (2.7.13) good (128,20,8,255)
/usr/local/cpython-3.0/bin/python (3.0.1) good (128,20,8,255)
/usr/local/cpython-3.1/bin/python (3.1.5) good (128,20,8,255)
/usr/local/cpython-3.2/bin/python (3.2.5) good (128,20,8,255)
/usr/local/cpython-3.3/bin/python (3.3.3) good (128,20,8,255)
/usr/local/cpython-3.4/bin/python (3.4.2) good (128,20,8,255)
/usr/local/cpython-3.5/bin/python (3.5.0) good (128,20,8,255)
/usr/local/cpython-3.6/bin/python (3.6.0) good (128,20,8,255)
/usr/local/cpython-3.7/bin/python (3.7.0b3) good (128,20,8,255)
/usr/local/jython-2.7/bin/jython (2.7.0) good (128,20,8,255)
/usr/local/pypy-5.10.0/bin/pypy (2.7.13) good (128,20,8,255)
/usr/local/pypy-5.3.1/bin/pypy (2.7.10) good (128,20,8,255)
/usr/local/pypy-5.9.0/bin/pypy (2.7.13) good (128,20,8,255)
/usr/local/pypy-6.0.0/bin/pypy (2.7.13) good (128,20,8,255)
/usr/local/pypy3-5.10.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-5.5.0/bin/pypy3 (3.3.5) good (128,20,8,255)
/usr/local/pypy3-5.8.0-with-lzma-fixes/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-5.8.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-5.9.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/pypy3-6.0.0/bin/pypy3 (3.5.3) good (128,20,8,255)
/usr/local/micropython-git-2017-06-16/bin/micropython (3.4.0) good
(128,20,8,255)

HTH
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[MRAB]

On 2018-05-23 19:36, Mikhail V wrote:

On Wed, May 23, 2018 at 8:08 PM, Mikhail V  wrote:

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:



data = /// sN # and
data = /// tN

Where N - is the amount of characters, spaces (s) or
tabs (t).
This should cover most use cases.
It implies of course that the user should know himself
what he is doing.

More concrete example:

def func():
foobar
data = /// s2
  first line
  last line
foobar

will store same data as:
data = "first linelast line"


oops, I meant it to be:
data = "first line\nlast line"

sorry for possible confusion



(assuming of course no trailing spaces were
in original lines)



Instead of the "s2", etc:

def func():
foobar
data = >> :
  first line
  last line
foobar

Leading indentation to the level of the first line would be stripped.

As the last line also ends with '\n', the result should be 'first 
line\nlast line\n'.


If you want additional indentation, then provide a string literal:

def func():
foobar
data = >> '':
  first line
  last line
foobar

for 'first line\nlast line\n' or:

def func():
foobar
data = >> '\t':
  first line
  last line
foobar

for '\tfirst line\n\tlast line\n'.
--
https://mail.python.org/mailman/listinfo/python-list

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[Dan Stromberg]

On Sat, May 19, 2018 at 3:58 PM,   wrote:
> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  wrote:
>> > It does auto-detect it as cp1252- look at the files in the traceback and
>> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
>> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
>>
>> Thanks a lot ! utf-8 and latin1 were accepted !
>
> hello i am having same issue..i believe the code is written in python 2 and i 
> am running python 3.6..i tried at the interpreter..f =
> open(filename, encoding="utf-8" and also latin-1..but then when i run my file 
> i still get the error...also my line is at 7414..how do you find this 
> line??...is it better to try to run the file .py in python 2??..thnxz

As suggested by others, if this is a text file, request the encoding
from the person who created it.  chardet can't really autodetect all
encodings, and neither can guessing encodings in a more manual way -
though if there's no one to ask, sometimes chardet is better than not
reading the file :)

Or, if the file is not text, if you want to treat it as a binary blob:

$ pythons --command 'file_ = open("/usr/local/pypy3-6.0.0/bin/pypy3",
"rb"); data = file_.read(); print(type(data)); file_.close()'
below cmd output started 2018 Wed May 23 01:43:35 PM PDT
/usr/local/cpython-1.0/bin/python (1.0.1) good 
/usr/local/cpython-1.1/bin/python (1.1) good 
/usr/local/cpython-1.2/bin/python (1.2) good 
/usr/local/cpython-1.3/bin/python (1.3) good 
/usr/local/cpython-1.4/bin/python (1.4) good 
/usr/local/cpython-1.5/bin/python (1.5.2) good 
/usr/local/cpython-1.6/bin/python (1.6.1) good 
/usr/local/cpython-2.0/bin/python (2.0.1) good 
/usr/local/cpython-2.1/bin/python (2.1.0) good 
/usr/local/cpython-2.2/bin/python (2.2.0) good 
/usr/local/cpython-2.3/bin/python (2.3.0) good 
/usr/local/cpython-2.4/bin/python (2.4.0) good 
/usr/local/cpython-2.5/bin/python (2.5.6) good 
/usr/local/cpython-2.6/bin/python (2.6.9) good 
/usr/local/cpython-2.7/bin/python (2.7.13) good 
/usr/local/cpython-3.0/bin/python (3.0.1) good 
/usr/local/cpython-3.1/bin/python (3.1.5) good 
/usr/local/cpython-3.2/bin/python (3.2.5) good 
/usr/local/cpython-3.3/bin/python (3.3.3) good 
/usr/local/cpython-3.4/bin/python (3.4.2) good 
/usr/local/cpython-3.5/bin/python (3.5.0) good 
/usr/local/cpython-3.6/bin/python (3.6.0) good 
/usr/local/cpython-3.7/bin/python (3.7.0b3) good 
/usr/local/jython-2.7/bin/jython (2.7.0) good 
/usr/local/pypy-5.10.0/bin/pypy (2.7.13) good 
/usr/local/pypy-5.3.1/bin/pypy (2.7.10) good 
/usr/local/pypy-5.9.0/bin/pypy (2.7.13) good 
/usr/local/pypy-6.0.0/bin/pypy (2.7.13) good 
/usr/local/pypy3-5.10.0/bin/pypy3 (3.5.3) good 
/usr/local/pypy3-5.5.0/bin/pypy3 (3.3.5) good 
/usr/local/pypy3-5.8.0-with-lzma-fixes/bin/pypy3 (3.5.3) good 
/usr/local/pypy3-5.8.0/bin/pypy3 (3.5.3) good 
/usr/local/pypy3-5.9.0/bin/pypy3 (3.5.3) good 
/usr/local/pypy3-6.0.0/bin/pypy3 (3.5.3) good 
/usr/local/micropython-git-2017-06-16/bin/micropython (3.4.0) good


HTH
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Bob van der Poel]

On Wed, May 23, 2018 at 1:45 PM, MRAB  wrote:

> On 2018-05-23 19:36, Mikhail V wrote:
>
>> On Wed, May 23, 2018 at 8:08 PM, Mikhail V  wrote:
>>
>>> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:
>>>
>>
>> data = /// sN # and
>>> data = /// tN
>>>
>>> Where N - is the amount of characters, spaces (s) or
>>> tabs (t).
>>> This should cover most use cases.
>>> It implies of course that the user should know himself
>>> what he is doing.
>>>
>>> More concrete example:
>>>
>>> def func():
>>> foobar
>>> data = /// s2
>>>   first line
>>>   last line
>>> foobar
>>>
>>> will store same data as:
>>> data = "first linelast line"
>>>
>>
>> oops, I meant it to be:
>> data = "first line\nlast line"
>>
>> sorry for possible confusion
>>
>>
>>> (assuming of course no trailing spaces were
>>> in original lines)
>>>
>>
>> Instead of the "s2", etc:
>
> def func():
> foobar
> data = >> :
>   first line
>   last line
> foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> As the last line also ends with '\n', the result should be 'first
> line\nlast line\n'.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
> foobar
> data = >> '':
>   first line
>   last line
> foobar
>
> for 'first line\nlast line\n' or:
>
> def func():
> foobar
> data = >> '\t':
>   first line
>   last line
> foobar
>
> for '\tfirst line\n\tlast line\n'.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

I think this is getting way too complex to fix a problem which doesn't
exist.

-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[Chris Angelico]

On Thu, May 24, 2018 at 6:48 AM, Dan Stromberg  wrote:
> On Sat, May 19, 2018 at 3:58 PM,   wrote:
>> On Thursday, 29 January 2009 12:09:29 UTC-5, Anjanesh Lekshminarayanan  
>> wrote:
>>> > It does auto-detect it as cp1252- look at the files in the traceback and
>>> > you'll see lib\encodings\cp1252.py. Since cp1252 seems to be the wrong
>>> > encoding, try opening it as utf-8 or latin1 and see if that fixes it.
>>>
>>> Thanks a lot ! utf-8 and latin1 were accepted !
>>
>> hello i am having same issue..i believe the code is written in python 2 and 
>> i am running python 3.6..i tried at the interpreter..f =
>> open(filename, encoding="utf-8" and also latin-1..but then when i run my 
>> file i still get the error...also my line is at 7414..how do you find this 
>> line??...is it better to try to run the file .py in python 2??..thnxz
>
> As suggested by others, if this is a text file, request the encoding
> from the person who created it.  chardet can't really autodetect all
> encodings, and neither can guessing encodings in a more manual way -
> though if there's no one to ask, sometimes chardet is better than not
> reading the file :)

Yep. And if chardet says it's MacCyrillic, it's probably actually
Codepage 1256 - that's been my experience.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting Unicode decode error using lxml.iterparse

[Peter Otten]

digi...@gmail.com wrote:

> I'm trying to read my iTunes library in Python using iterparse. My current
> stub is:

> parser.add_argument('infile', nargs='?',
> type=argparse.FileType('r'), default=sys.stdin)

> I'm getting an error on one part of the XML:
> 
> 
>  File "C:\Users\digit\Anaconda3\lib\encodings\cp1252.py", line 23, in
>  decode
> return codecs.charmap_decode(input,self.errors,decoding_table)[0]
> 
> UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position
> 202: character maps to 

> I suspect the issue is that it's using cp1252.py, which I don't think is
> UTF-8 as specified in the XML prolog. Is this an iterparse problem, or am
> I using it wrongly?

The wrong encoding is specified implicitly in argparse.FileType("r"). Try 
FileType("rb") or FileType("r", encoding="utf-8") instead (my personal 
approach is to avoid FileType completely).


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: decorat{or,ion}

[Mike McClain]

On Mon, May 21, 2018 at 09:11:02AM +0200, dieter wrote:
< lots if good info snipped >

Hi dieter,
I'm still working my way through the info you posted
and making sense of it (mostly)
but didn't want to wait any longer to say 'Thanks.'

Thanks,
Mike
--
Even duct tape can't fix stupid ... But it can muffle the sound.
-- 
https://mail.python.org/mailman/listinfo/python-list

how to get INDEX count, or last number of Index

[asa32sd23]

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a 
function that gives me last number of index

thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[Rob Gaddi]

On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a 
function that gives me last number of index

thanks



Not sure I'm following your question; len(s)-1 is much faster than 
enumerating over the string just to get the last index.


If what you want is the current index, though, you can look at the 
enumerate function


s='kitti'
for i, c in enumerate(s):
print(i, ':', c)

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[asa32sd23]

On Wednesday, May 23, 2018 at 5:56:26 PM UTC-4, Rob Gaddi wrote:
> On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:
> > s = "kitti"
> > 
> > 0,1,2,3,4
> > k,i,t,t,i
> > 
> > how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a 
> > function that gives me last number of index
> > 
> > thanks
> > 
> 
> Not sure I'm following your question; len(s)-1 is much faster than 
> enumerating over the string just to get the last index.
> 
> If what you want is the current index, though, you can look at the 
> enumerate function
> 
> s='kitti'
> for i, c in enumerate(s):
>  print(i, ':', c)
> 
> -- 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

hi Rob,

you understand my question. Im new to Python so thought maybe there is a 
function that returns the last value of the index. BUT if len(s) -1 is the 
answer. ill go with that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[bartc]

On 23/05/2018 22:51, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a 
function that gives me last number of index


Not for that trivial task. But you can create your own:

 def upb(x): return len(x)-1 # 'upb' means 'upper-bound'

 print (upb("kitti"))# output: 4
--
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[asa32sd23]

On Wednesday, May 23, 2018 at 5:51:42 PM UTC-4, asa3...@gmail.com wrote:
> s = "kitti"
> 
> 0,1,2,3,4
> k,i,t,t,i
> 
> how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a 
> function that gives me last number of index
> 
> thanks

thanks, it seems just a len(s) -1 is the right way to return it. thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[Mark Lawrence]

On 23/05/18 22:56, Rob Gaddi wrote:

On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1, but i assume there 
is a function that gives me last number of index


thanks



Not sure I'm following your question; len(s)-1 is much faster than 
enumerating over the string just to get the last index.




-1 is even faster.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Gene Heskett]

On Wednesday 23 May 2018 12:45:57 Chris Green wrote:

> Abdur-Rahmaan Janhangeer  wrote:
> > can someone explain to me why the mailing list (spam free) is not
> > used by everybody?
>
> Because the Usenet/NNTP interface (with a good newsreader) is so much
> better! :-)
>
> --
> Chris Green
> ·

You are stating an opinion, but no facts to back it up, so describe your 
environment that makes you write that, please.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Chris Green]

Gene Heskett  wrote:
> On Wednesday 23 May 2018 12:45:57 Chris Green wrote:
> 
> > Abdur-Rahmaan Janhangeer  wrote:
> > > can someone explain to me why the mailing list (spam free) is not
> > > used by everybody?
> >
> > Because the Usenet/NNTP interface (with a good newsreader) is so much
> > better! :-)
> >
> 
> You are stating an opinion, but no facts to back it up, so describe your 
> environment that makes you write that, please.
> 
Well from other comments here it seems I'm not alone but anyway:-

Proper threading etc. is built in

It's automatically archived and one can search back through
threads for old postings, this is by design not an add on.

Kill files and other similar filtering abilities are part of the
user interface

Automatic handling of new messages and a means to say "I've read
everything here".

I'm sure there's more

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Alan Bawden]

Gene Heskett  writes:

> You are stating an opinion, but no facts to back it up, so describe your 
> environment that makes you write that, please.

If he describes his environment and why he likes it, will that be a
"fact"?  Or will you dismiss that as just another "opinion"?

You asked:

> can someone explain to me why the mailing list (spam free) is not used by
> everybody?

And the fact is that in many people's opinions, "the Usenet/NNTP interface
(with a good newsreader) is so much better!"  That _is_ the answer to your
question.

I'm using Gnus myself, and I find that for a list/group like this, it works
better than any mail client I have ever used.  The threading support is
excellent.  And the scoring system lets me not only filter out the spam,
but it also lets me tune out the people I think are idiots, who would show
up even on the mailing list.

That's just my opinion, of course.  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

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 line
> foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
> foobar
> data = >> '':
>   first line
>   last line
> foobar

Such approach has its benefits.
and ">>" looks nice.

So the benefit here is that you make it more
compact - no parameters needed.
But as you see, it just cannot parse the text in
case of positive indent.
Or otherwise I need to edit the text and then, if say I want
to paste it back elsewhere - edit again. This small nuance can
get in the way.
Also semantically - I find it a bit of implication - it's something
automatic.


> As the last line also ends with '\n', the result should be 'first line\nlast
> line\n'.

Sorry, I can't see how this would be beneficial?
This would mean every string will have trailing \n.
Even if it is one word.
Maybe it could help in some cases, for example
if you write a code generator and then append to
a file consequently.
But in general I disagree with this approach.

Also it is counter-intuitive - for example if I open a
text editor and type "a", save it and then read it with
python script - then I get only "a" but not "a\n".

But maybe I am missing something.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[Terry Reedy]

On 5/23/2018 5:56 PM, Rob Gaddi wrote:

On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1,


Use -1, which is the same as len(s)-1 but faster.

>>> s = 'kitty'
>>> s[len(s)-1]
'y'
>>> s[-1]
'y'


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[Terry Reedy]

On 5/23/2018 6:07 PM, asa32s...@gmail.com wrote:

On Wednesday, May 23, 2018 at 5:51:42 PM UTC-4, asa3...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1, but i assume there is a 
function that gives me last number of index

thanks


thanks, it seems just a len(s) -1 is the right way to return it. thanks


No it is not.  Just use -1

>>> s = 'kitty'
>>> s[len(s)-1]
'y'
>>> s[-1]
'y'

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: how to handle captcha through machanize module or any module

[Ben Finney]

Jai  writes:

> please do replay how to handle captcha through machanize module 

Step 1: ‘import mechanize’.

Step 2: be an actual human, and interact manually with the CAPTCHA.

If you are attempting to fool a CAPTCHA with an automated tool, you are
entering an arms race against those who design the CAPTCHA to *prevent*
exactly what you're doing.

Any technique someone can describe to fool the CAPTCHA, will most likely
already be considered as part of the design of the more effective
CAPTCHAs, and so the technique will still not actually work reliably.

So, there is no general answer, other than to stop thinking that's a
race that you can win.

-- 
 \ “DRM doesn't inconvenience [lawbreakers] — indeed, over time it |
  `\ trains law-abiding users to become [lawbreakers] out of sheer |
_o__)frustration.” —Charles Stross, 2010-05-09 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

how to return last condition if other 2 not met?

[asa32sd23]

i want to check/return for 3 conditions, it loops shortest str and finds diff 
in other
1. if difference is immediate before end of range, return index, exit
2. if string length is same and index loop is done, return 'identical'
3. if neither of above is found. it means the short loop ended and every letter 
was same so next letter of longer str is the diff, just return idex+1
but my last print statement always print. not sure how to end this

[code]
str1= "kitti cat"
str2= 'kitti catt'
lenStr1= len(str1)
lenStr2= len(str2)

#find shortest str and loop range with this one
if lenStr1 >= lenStr2:
str= str2
else:
str= str1

# loop each character of shortest string, compare to same index of longer string
# if any difference, exit and return index of difference
for idx in range(len(str)):
a= str1[idx]
b= str2[idx]
if a != b:  #immeditely exit, since non-match found
print(idx)
break
else:
   if len(str1) == len(str2) and idx == len(str1)-1: #if no difference 
print 'identical'
print("identical")
break

print(idx+1)
[/code]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Usenet Gateway

[Gene Heskett]

On Wednesday 23 May 2018 19:24:52 Alan Bawden wrote:

> Gene Heskett  writes:
> > You are stating an opinion, but no facts to back it up, so describe
> > your environment that makes you write that, please.
>
> If he describes his environment and why he likes it, will that be a
> "fact"?  Or will you dismiss that as just another "opinion"?
>
> You asked:
> > can someone explain to me why the mailing list (spam free) is not
> > used by everybody?
>
I did not ask that, somebody's quoting is miss adjusted.

> And the fact is that in many people's opinions, "the Usenet/NNTP
> interface (with a good newsreader) is so much better!"  That _is_ the
> answer to your question.

But it wasn't my question.

> I'm using Gnus myself, and I find that for a list/group like this, it
> works better than any mail client I have ever used.  The threading
> support is excellent.  And the scoring system lets me not only filter
> out the spam, but it also lets me tune out the people I think are
> idiots, who would show up even on the mailing list.
>
> That's just my opinion, of course.

Whereas I use kmail, with background helpers that do 99% of the work for 
me. It can search, thread, and all those things that a news reader like 
gnus or slrn can do. kmail is quite configurable, but note this is not 
the new kmail from kde, its the old kmail that TDE uses. Forked from the 
KDE-3.5 repo several years ago, with the emphasis since on fixing bugs 
that Ingo K. had no interest in fixing. In 2018 now, its Just Works(TM). 
But development continues to make it even more stable.

And of course thats just my opinion too. :) 

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[bartc]

On 24/05/2018 00:44, Terry Reedy wrote:

On 5/23/2018 5:56 PM, Rob Gaddi wrote:

On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1,


Use -1, which is the same as len(s)-1 but faster.


This illustrates one problem with having a example sequence of values 
being identical to the indices of those values.


I would have used 10,20,30,40,50 so there could be no such mix-up.

Because I assumed here that the OP wanted the index of the last value, 
the '4' they said they wanted, not the last value itself which would be 'i'.


And actually, the subject line seems to confirm that.

In that case, using a '-1' index won't work.

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[bartc]

On 24/05/2018 01:46, bartc wrote:

On 24/05/2018 00:44, Terry Reedy wrote:

On 5/23/2018 5:56 PM, Rob Gaddi wrote:

On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1,


Use -1, which is the same as len(s)-1 but faster.


This illustrates one problem with having a example sequence of values 
being identical to the indices of those values.


I would have used 10,20,30,40,50 so there could be no such mix-up.


Hmm, although my observation is valid, that's not the case here, as the 
0,1,2,3,4 /are/ the indices! Not the list of values of which they are 
trying to access the '4', and which /could/ be obtained with the -1 
index some people are talking about, that added to the confusion.


--
https://mail.python.org/mailman/listinfo/python-list

Re: how to return last condition if other 2 not met?

[MRAB]

On 2018-05-24 00:57, asa32s...@gmail.com wrote:

i want to check/return for 3 conditions, it loops shortest str and finds diff 
in other
1. if difference is immediate before end of range, return index, exit
2. if string length is same and index loop is done, return 'identical'
3. if neither of above is found. it means the short loop ended and every letter 
was same so next letter of longer str is the diff, just return idex+1
but my last print statement always print. not sure how to end this

[code]
str1= "kitti cat"
str2= 'kitti catt'
lenStr1= len(str1)
lenStr2= len(str2)

#find shortest str and loop range with this one
if lenStr1 >= lenStr2:
 str= str2
else:
 str= str1
 
# loop each character of shortest string, compare to same index of longer string

# if any difference, exit and return index of difference
for idx in range(len(str)):
 a= str1[idx]
 b= str2[idx]
 if a != b:  #immeditely exit, since non-match found
 print(idx)
 break
 else:
if len(str1) == len(str2) and idx == len(str1)-1: #if no difference 
print 'identical'
 print("identical")
 break

print(idx+1)
[/code]

The 'for' loop (and also the 'while' loop) can have an 'else' clause, 
which is run if it didn't break out of the loop:


for idx in range(len(str)):
# body of loop
...
else:
# didn't break out of the loop
print(idx+1)
--
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[Cameron Simpson]

On 23May2018 23:14, Mark Lawrence  wrote:

On 23/05/18 22:56, Rob Gaddi wrote:

On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1, but i assume 
there is a function that gives me last number of index




Not sure I'm following your question; len(s)-1 is much faster than 
enumerating over the string just to get the last index.


-1 is even faster.


For fetching the last element, sure. But possibly the OP needs to know the 
actual index. Example use case:


 chars = []
 last_per_char = {}
 for char in "some string here with letters and stuff":
   chars.append(char)
   last_per_char[char] = len(chars) - 1

That's only slightly contrived, but there are plenty of real world situations 
where you accrue data and need to know the absolute position of the latest 
instance of particular records.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: how to get INDEX count, or last number of Index

[Terry Reedy]

On 5/23/2018 8:46 PM, bartc wrote:

On 24/05/2018 00:44, Terry Reedy wrote:

On 5/23/2018 5:56 PM, Rob Gaddi wrote:

On 05/23/2018 02:51 PM, asa32s...@gmail.com wrote:

s = "kitti"

0,1,2,3,4
k,i,t,t,i

how do i retrieve '4'. i know i can do a len(s)-1,


Use -1, which is the same as len(s)-1 but faster.


This illustrates one problem with having a example sequence of values 
being identical to the indices of those values.


I would have used 10,20,30,40,50 so there could be no such mix-up.

Because I assumed here that the OP wanted the index of the last value, 
the '4' they said they wanted, not the last value itself which would be 
'i'.


And actually, the subject line seems to confirm that.

In that case, using a '-1' index won't work.


You snipped the code that shows that -1 does work to fetch the last 
character.


>>> s = 'kitty'
>>> s[len(s)-1]
'y'
>>> s[-1]
'y'



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

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 line
>>   last line
>> foobar
>>
>> for 'first line\nlast line\n' or:
>>
>> def func():
>> foobar
>> data = >> '\t':
>>   first line
>>   last line
>> foobar
>>
>> for '\tfirst line\n\tlast line\n'.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> I think this is getting way too complex to fix a problem which doesn't
> exist.

@Bob
It is not clear at all about which issue are you writing the comment.
Also not clear to whom is it addressed (me or MRAB).

Please - can you be specific and respectful.

And a general note - It is hard to support the conversation when the
amount of rational content becomes low.
May be it surprises you but I _read_ the comments and try to
understand them.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to return last condition if other 2 not met?

[asa32sd23]

On Wednesday, May 23, 2018 at 8:55:59 PM UTC-4, MRAB wrote:
> On 2018-05-24 00:57, asa32s...@gmail.com wrote:
> > i want to check/return for 3 conditions, it loops shortest str and finds 
> > diff in other
> > 1. if difference is immediate before end of range, return index, exit
> > 2. if string length is same and index loop is done, return 'identical'
> > 3. if neither of above is found. it means the short loop ended and every 
> > letter was same so next letter of longer str is the diff, just return idex+1
> > but my last print statement always print. not sure how to end this
> > 
> > [code]
> > str1= "kitti cat"
> > str2= 'kitti catt'
> > lenStr1= len(str1)
> > lenStr2= len(str2)
> > 
> > #find shortest str and loop range with this one
> > if lenStr1 >= lenStr2:
> >  str= str2
> > else:
> >  str= str1
> >  
> > # loop each character of shortest string, compare to same index of longer 
> > string
> > # if any difference, exit and return index of difference
> > for idx in range(len(str)):
> >  a= str1[idx]
> >  b= str2[idx]
> >  if a != b:  #immeditely exit, since non-match found
> >  print(idx)
> >  break
> >  else:
> > if len(str1) == len(str2) and idx == len(str1)-1: #if no difference 
> > print 'identical'
> >  print("identical")
> >  break
> > 
> > print(idx+1)
> > [/code]
> > 
> The 'for' loop (and also the 'while' loop) can have an 'else' clause, 
> which is run if it didn't break out of the loop:
> 
> for idx in range(len(str)):
>  # body of loop
>  ...
> else:
>  # didn't break out of the loop
>  print(idx+1)
-

thats what it was... thank you!! i was stuck in the same thought process and 
couldnt see it
-- 
https://mail.python.org/mailman/listinfo/python-list