[issue30061] Check if PyObject_Size() raised an error

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +xiang.zhang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29651] Inconsistent/undocumented urlsplit/urlparse behavior on invalid inputs

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +1263

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29651] Inconsistent/undocumented urlsplit/urlparse behavior on invalid inputs

[Howie Benefiel]

Howie Benefiel added the comment:

I'm going to make a note in the documentation. I should have a PR for it in 
about 1 day.

--
nosy: +Howie Benefiel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python and the need for speed

[Steve D'Aprano]

On Fri, 14 Apr 2017 12:13 pm, Steve D'Aprano wrote:

> There are a bazillion ugly, unreadable, unproductive but slow languages if
> you want them:

Er, I mean *fast*.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: "Goto" statement in Python

[Rustom Mody]

On Friday, April 14, 2017 at 7:15:11 AM UTC+5:30, 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.
> 
> Dear gods, have I fallen back in time to 1975 again?

Good that you start with the suggestion that we are not in 1975



> Features should not be judged solely on their usefulness to the best 1% of
> programmers using the feature in the best possible way. You also need to
> consider the lesser mortals, the below-average 50% of programmers who will
> use the feature in sub-optimal if not outright terrible ways.
> 
> GOTOs are far to easy to abuse. The harm that they do is outweighed a
> thousand times by the rare positive use. Most languages do well to avoid
> GOTO, even if that means that there are one or two rare uses that have to
> be written slightly sub-optimally for the lack.

That sounds very 1970s to me.

With the languages that I (and presumably you) grew up with using gotos was
too easy; not using was hard or impossible.
The most structured was Pascal which set out to be ornery by making one declare
labels. With everything else — Fortran-IV, Basic, assembler — it was next to 
impossible.

Cut to 2017 and take a random 20 year old brought up on 
python/java/ruby/javascript/haskell

Where/how would he have learnt to use gotos?

In short: In 1968 "Goto statement considered harmful" was a necessary viewpoint.
Today its a quasi-religious bias without basis.

Personal Note: Much of the direction that my programming/teaching has taken in
the last 30 years can be traced to a statement made by a teacher when I was 
graduating:

“What the goto does to control-structure, the assignment does to data-structure”
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Rustom Mody]

On Friday, April 14, 2017 at 7:03:24 AM UTC+5:30, Steve D'Aprano wrote:
> On Fri, 14 Apr 2017 04:09 am, Rustom Mody wrote:

> > [Sorry its a vague memory of something I read more than a decade ago that
> > [I cant
> > trace again]
> > Some unknown Cobol programmer talking about Dijkstra:
> > 
> > Dijkstra used his enormous prestige to destroy Cobol.
> > We lost a great deal
> > What did he gain?
> > Ok so Cobol's control constructs are below par
> > But do any of its modern successors have its data-describing properties?
> > [the PIC clause]
> 
> If PIC is so great, why do no other languages have it?
> 
> That's a serious question, not a rhetorical question.

Dunno enough about Cobol and that ecosystem to make a useful comment
However your question is really two:
1. Whats good about Cobol's PIC?
2. Why dont other languages have it/that benefit?

1st as I said I dont feel qualified to answer
2nd is ridiculous. Because of collective stupidity:
- Species go extinct
- Garbage fills the oceans
- Fukushima fallout reaches Canada
- And in general good, valuable things die out
> 
> "Imminent Death Of Cobol Predicted. Again."
> 
> When the sun finally expands into a supergiant in five billion years,
> destroying the earth, the last survivors to die will be COBOL-programming
> cockroaches and Keith Richards.

> > Maybe that's a response to similar violent, unnecessary barbs from
> > Dijkstra?
> 
> "Violent"?
> 
> Are you one of those people who think that calling a person an idiot is
> morally indistinguishable from beating them into a coma?
> 
> "Sticks and stones will break my bones, but that's nothing to the harm
> caused by a few mean words."

You are treating violence as literal physical violence.
Thats backwards. Ultimately all violence is moral
Else an orthopaedic sawing off a knee to replace or a dentist yanking out a 
molar would be felons
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and the need for speed

[Rustom Mody]

On Friday, April 14, 2017 at 7:43:22 AM UTC+5:30, Steve D'Aprano wrote:
> On Wed, 12 Apr 2017 07:56 pm, bart wrote:
> 
> > The problem is also the language encouraging people to use high-level but
> > inefficient methods, as the emphasis is on productivity and readability**
> > rather than performance. 
> 
> I'm sorry, but that is in no way "the problem".
> 
> Emphasising productivity and readability is not a problem. It is a feature.
> 
> There are a bazillion ugly, unreadable, unproductive but slow languages if
> you want them:
> 
> C, C++, C#, Objective C, Lisp, Scheme, Fortran, Java, Rust, D, Ada ...

C and Fortran in the slow-set??
I'd say you are typing too fast :D
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29694] race condition in pathlib mkdir with flags parents=True

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

I merged Armin's PR and backported tp 3.5 and 3.6.
Closing this now.
Thanks all :)

--
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29694] race condition in pathlib mkdir with flags parents=True

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset d7abeb7024b9755c291c29bdc8c4494246e975ad by Mariatta in branch 
'3.5':
[3.5] bpo-29694: race condition in pathlib mkdir with flags parents=True 
(GH-1089). (GH-1127)
https://github.com/python/cpython/commit/d7abeb7024b9755c291c29bdc8c4494246e975ad


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29694] race condition in pathlib mkdir with flags parents=True

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset cbc46afa59dcc43c2c8c90ae7a0a0dc404325a89 by Mariatta in branch 
'3.6':
[3.6] bpo-29694: race condition in pathlib mkdir with flags parents=True 
(GH-1089). (GH-1126)
https://github.com/python/cpython/commit/cbc46afa59dcc43c2c8c90ae7a0a0dc404325a89


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python and the need for speed

[Steve D'Aprano]

On Wed, 12 Apr 2017 07:56 pm, bart4...@gmail.com wrote:

> The problem is also the language encouraging people to use high-level but
> inefficient methods, as the emphasis is on productivity and readability**
> rather than performance. 

I'm sorry, but that is in no way "the problem".

Emphasising productivity and readability is not a problem. It is a feature.

There are a bazillion ugly, unreadable, unproductive but slow languages if
you want them:

C, C++, C#, Objective C, Lisp, Scheme, Fortran, Java, Rust, D, Ada ...

(although of course aficionados of each language will disagree about it
being unproductive; whatever rocks your boat). That's fine. If you want
fast code, you can get it.

Python's emphasis on readability and productivity is not a cross to bear, it
is not a bug, or a design mistake, or a problem. It is an intentional
trade-off.

While it is certainly true that faster Python is welcome, and that there may
be ways of getting it without giving up on the essential Pythonness of the
language, if speed is your number one concern, maybe Python was the wrong
choice of language for you.

Just like if you care most about program correctness, type-safety and
correctness proofs, choosing C is probably the wrong decision.



[...]
> (** Although I find code full of class definitions, one-liners, decorators
> and all the other esoterics, incomprehensive. I'm sure I'm not the only
> one, so perhaps readability isn't too much of a priority either.)

Classes and decorators are not esoteric. You sound like an old man who
complains about this new-fangled "telephone", and how things were so much
better when we had messenger boys to deliver messages anywhere in the city.

I'm not sure what you consider incomprehensible about "one liners", surely
it depends on what the one liner does. These are pretty clear to me:

# The archetypal "Hello World!" program is a one-liner.
print("Hello World!")

# One liner to calculate the sum of the first 50 cubes.
total = sum(i**3 for i in range(50))



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue29880] python3.6 install readline ,and then cpython exit

[Berker Peksag]

Changes by Berker Peksag :


--
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29694] race condition in pathlib mkdir with flags parents=True

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +1262

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29694] race condition in pathlib mkdir with flags parents=True

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +1261

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Steve D'Aprano]

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.

Dear gods, have I fallen back in time to 1975 again?

The Goto Wars are over, and the structured programming camp won the war
decisively.

Are functions/procedures *technically* slower than GOTOs? Yes. So what?
You're nano-optimizing the wrong thing: you're saving a microsecond of
runtime at the cost of a megasecond of development and maintenance time.

At the point that you say "Function calls ... are rather more heavyweight"
the whole argument becomes farcical. Function calls are so prevalent in
modern structured programming (whether you write in procedural, functional
or object-oriented style, or a combination of all three) that saving one or
two function calls isn't even a micro-optimization, especially not in a
high-level language.

To save any meaningful time, you would need to return to the bad-old-days of
unmaintainable unstructured spaghetti code.

This debate about the usefulness of GOTO in modern languages reminds me of
the sort of people who will drive around the city for an hour looking to
save 0.1 cent on the cost of petrol (gasoline for Americans).


> 'goto' would be one easy-to-execute byte-code; no variables, objects or
> types to worry about. If implemented properly (with the byte-code
> compiler using a dedicated name-space for labels) there would be no name
> lookups.

I don't care much about the implementation of GOTO. I care a lot about the
code written that includes GOTOs.

Are there reasonable uses for GOTO? Perhaps. There are semi-structured
restricted versions of GOTO, like exceptions, break and return, but an
unrestricted GOTO where you can jump anywhere in the program is a terrible
feature for anything but the smallest, most trivial programs. To be even
*close* to safe, you have to restrict GOTO considerably. At the very
minimum, you need two restrictions:

- cannot jump into the middle of a procedure or function;

- cannot jump immediately out of a procedure or function without 
  cleaning up the stack and other handling.


Even that's not enough for some. Donald Knuth, who supports the use of GOTO
under some circumstances, maintains that any program using GOTOs should
have the invariant that its flow chart can be drawn with all forward
branches on the left, all backward branches on the right, and no branches
crossing each other.

Features should not be judged solely on their usefulness to the best 1% of
programmers using the feature in the best possible way. You also need to
consider the lesser mortals, the below-average 50% of programmers who will
use the feature in sub-optimal if not outright terrible ways.

GOTOs are far to easy to abuse. The harm that they do is outweighed a
thousand times by the rare positive use. Most languages do well to avoid
GOTO, even if that means that there are one or two rare uses that have to
be written slightly sub-optimally for the lack.


> Function calls, returns and generators are rather more heavyweight in
> comparison.

And enormously better.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Steve D'Aprano]

On Fri, 14 Apr 2017 04:09 am, Rustom Mody wrote:

> On Thursday, April 13, 2017 at 11:14:15 PM UTC+5:30, Steve D'Aprano wrote:
>> Meyer's "Considered Harmful Essays Considered Harmful" essay is
>> hypocritical junk, and should be considered harmful.
> 
> Your view.

Well duh :-)


> Here's an alternative.
> [Sorry its a vague memory of something I read more than a decade ago that
> [I cant
> trace again]
> Some unknown Cobol programmer talking about Dijkstra:
> 
> Dijkstra used his enormous prestige to destroy Cobol.

"Imminent Death Of Cobol Predicted. Again."

When the sun finally expands into a supergiant in five billion years,
destroying the earth, the last survivors to die will be COBOL-programming
cockroaches and Keith Richards.


> We lost a great deal
> What did he gain?
> Ok so Cobol's control constructs are below par
> But do any of its modern successors have its data-describing properties?
> [the PIC clause]

If PIC is so great, why do no other languages have it?

That's a serious question, not a rhetorical question.



> Or consider(!) Alan Kay's statement: "Arrogance in computer science is
> measured in nanodijktras"

Indeed. What's your point? Because that sounds awfully like an ad hominem
fallacy. Dijkstra was arrogant, therefore he must be wrong.


> Maybe that's a response to similar violent, unnecessary barbs from
> Dijkstra?

"Violent"?

Are you one of those people who think that calling a person an idiot is
morally indistinguishable from beating them into a coma?

"Sticks and stones will break my bones, but that's nothing to the harm
caused by a few mean words."




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset 947629916a5ecb1f6f6792e9b9234e084c5bf274 by Mariatta in branch 
'master':
bpo-29869: Add Nevada Sanchez to Misc/ACKS (GH-1125)
https://github.com/python/cpython/commit/947629916a5ecb1f6f6792e9b9234e084c5bf274


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

PR has been merged and backported to 3.6.
I also added Nevada Sanchez to Misc/ACKS.
Thanks all :)

--
resolution:  -> fixed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +1260

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

RE: Namedtuples: some unexpected inconveniences

[Deborah Swanson]

Roel Schroeven wrote, on Thursday, April 13, 2017 5:26 PM
> 
> Gregory Ewing schreef op 13/04/2017 9:34:
> > Deborah Swanson wrote:
> >> Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
> >>
> >>> Personally I would immediately discard the header row 
> once and for 
> >>> all, not again and again on every operation.
> >> Well, perhaps, but I need the header row to stay in place to write 
> >> the list to a csv when I'm done
> > 
> > That's no problem, just write the header row separately.
> > 
> > Do this at the beginning:
> > 
> >header = [Record._make(fieldnames)]
> >records = [Record._make(row) for row in rows]
> > 
> > and then to write out the file:
> > 
> >writer = csv.writer(outputfile)
> >writer.writerow(header)
> >writer.writerows(records)
> 
> I don't even think there's any need to store the field names anywhere 
> else than in fieldnames. So unless I'm missing something, 
> just do this 
> at the beginning:
> 
>  fieldnames = next(rows)
>  Record = namedtuple("Record", fieldnames)
>  records = [Record._make(row) for row in rows]
> 
> and this at the end:
> 
>  writer = csv.writer(outputfile)
>  writer.writerow(fieldnames) # or writer.writerow(Record._fields)
>  writer.writerows(records)
> 
> 
> -- 
> The saddest aspect of life right now is that science gathers 
> knowledge faster than society gathers wisdom.
>-- Isaac Asimov
> 
> Roel Schroeven

Thanks Roel. I'll try your version when I get the code reconstructed,
and that might take a few to several days. I'll try to get back to you
though on how it goes.

Read the previous messages if you want the sad story of what happened to
the original code.

Deborah

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

RE: Namedtuples: some unexpected inconveniences

[Deborah Swanson]

Gregory Ewing wrote, on Thursday, April 13, 2017 1:14 AM
> 
> Deborah Swanson wrote:
> > I don't exactly understand your point (2). If the 
> namedtuple does not 
> > have a label attribute, then getattr(record, label) will 
> get the error 
> > whether the name label holds the string 'label' or not.
> 
> You sound rather confused. Maybe the following interactive 
> session transcript will help.
> 
>  >>> from collections import namedtuple
>  >>> record = namedtuple('record', 'alpha,beta')
>  >>> r = record(1, 2)
>  >>> r
> record(alpha=1, beta=2)
>  >>> label = 'alpha'
>  >>> getattr(r, label)
> 1
>  >>> label = 'beta'
>  >>> getattr(r, label)
> 2
>  >>> label = 'gamma'
>  >>> getattr(r, label)
> Traceback (most recent call last):
>File "", line 1, in 
> AttributeError: 'record' object has no attribute 'gamma'
> 
> Can you see what's happening here? The expression
> 
> label
> 
> is being evaluated, and whatever string it evaluates to is 
> being used as the attribute name to look up.
> 
> Now, I'm not sure exactly what you were doing to get the 
> message "'record' object has no attribute 'label'". Here are 
> a few possible ways to get that effect:
> 
>  >>> r.label
> Traceback (most recent call last):
>File "", line 1, in 
> AttributeError: 'record' object has no attribute 'label'
> 
>  >>> getattr(r, 'label')
> Traceback (most recent call last):
>File "", line 1, in 
> AttributeError: 'record' object has no attribute 'label'
> 
>  >>> label = 'label'
>  >>> getattr(r, label)
> Traceback (most recent call last):
>File "", line 1, in 
> AttributeError: 'record' object has no attribute 'label'
> 
> Or maybe you did something else again. We would need to
> see your code in order to tell.
> 
> -- 
> Greg

And it's reproducing the code that's the roadblock to all of these
issues.

Rest assured I will get to the bottom of this, or at least come back
with the code to ask more questions about it and let you see what I had.
I want to see what's going on here too.

Might be a day or two though.

Deborah

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

RE: Namedtuples: some unexpected inconveniences

[Deborah Swanson]

Gregory Ewing wrote, on Thursday, April 13, 2017 12:34 AM
> 
> Deborah Swanson wrote:
> > Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
> > 
> >> Personally I would immediately discard the header row once and for 
> >> all, not again and again on every operation.
> > 
> > Well, perhaps, but I need the header row to stay in place 
> to write the 
> > list to a csv when I'm done
> 
> That's no problem, just write the header row separately.
> 
> Do this at the beginning:
> 
>header = [Record._make(fieldnames)]
>records = [Record._make(row) for row in rows]
> 
> and then to write out the file:
> 
>writer = csv.writer(outputfile)
>writer.writerow(header)
>writer.writerows(records)
> 
> > There might be a tiny performance edge in discarding the header row 
> > for the sort, but there would also be a hit to recreate it 
> at output 
> > time.
> 
> It's not about performance, it's about keeping the code as 
> clean and simple as you can, thus making it easier to 
> understand and maintain.
> 
> The general idea to take away from this is that it's almost 
> always best to arrange things so that a given collection 
> contains just one kind of data, so you can treat every 
> element of it in exactly the same way.
> 
> -- 
> Greg

That's good advice and I'll rewrite it that way, after I have the code I
started with to answer the other questions.

I certainly know I have a lot to learn about writing good code, and I
can see that what you're suggesting is much cleaner than what I had.

Thanks,
Deborah

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

RE: Namedtuples: some unexpected inconveniences

[Deborah Swanson]

Gregory Ewing wrote, on Thursday, April 13, 2017 12:36 AM
> 
> If you want to be able to update your rows, you may find
> this useful:
> 
https://pypi.python.org/pypi/recordclass

It's very similar to a namedtuple, but mutable. Looks like it should be
a drop-in replacement.

-- 
Greg

Thanks Greg, I'll definitely take a look at it

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

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Ian Kelly]

On Thu, Apr 13, 2017 at 12:51 PM, Nathan Ernst  wrote:
> Thank you for that Alan Kay quote. Brightened up my day. Since you also
> mentioned COBOL, and this is a thread about "goto", reminded me of the
> single most abhorrent thing I ever saw in COBOL (I had to convert a single
> COBOL batch process to ASP.Net as an intern back in 2003-4). "MOVE NEXT
> SENTENCE". What is this statement? An unlabelled goto. It literally jumps
> to the next period: "." in the source.
>
> Now, I'm fine with judicious use of goto with good labels. (and, I've only
> used goto maybe 3 or 4 times in a 15 year career), but a blocky construct
> like "MOVE NEXT SENTENCE" in a language that also has lots of (all-caps
> required) block statements to jump to a tiny on the screen period...that is
> just evil.

Yikes. I never took the time to learn COBOL, but that almost sounds
like something that you'd find in an esoteric language like INTERCAL.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Namedtuples: some unexpected inconveniences

[Deborah Swanson]

Gregory Ewing wrote, on Thursday, April 13, 2017 12:17 AM
> 
> Deborah Swanson wrote:
> > But I think you got it right in your last sentence below. 
> defaultdict 
> > copied them because they were immutable,
> 
> No, definitely not. A defaultdict will never take it upon 
> itself to copy an object you give it, either as a key or a value.
> 
> The copying, if any, must have occurred somewhere else, in
> code that you didn't show us.
> 
> Can you show us the actual code you used to attempt to
> update the namedtuples?
> 
> -- 
> Greg

As I just told Peter, I just discovered earlier today that all of that
code is lost, and it will take awhile to rewrite. And now I have several
reasons to do so.

I don't know how long it will take, but I will come back and produce the
code that gave me this behavior.

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

RE: Namedtuples: some unexpected inconveniences

[Deborah Swanson]

Peter Otten wrote, on Thursday, April 13, 2017 12:17 AM
> 
> Deborah Swanson wrote:
> 
> > Peter Otten wrote, on Wednesday, April 12, 2017 11:35 PM
> >> 
> >> Deborah Swanson wrote:
> >> 
> >> > It's a small point, but I suspect getattr(record, label)
> >> would still
> >> > fail, even if label's value is 'label' and only 'label', 
> but what's 
> >> > the point of having a variable if it will only ever have 
> just one 
> >> > value?
> >> 
> >> You are misunderstanding. Your getattr() call fails because you
have
> >> 
> >> label = "label"
> >> 
> >> burried somewhere in your code. As soon as you change that to
> >> 
> >> label = 
> >> 
> >> the error will go away.
> > 
> > 
> > Yes, the error goes away, but now getattr(record, label) is useless 
> > for processing field names, unless you want to write a line of code 
> > for each one. (I have 17 field names, and forget about passing label

> > to a function.)

Uh-oh, I boobooed and misread what you wrote here. 

> No, it's not useless:
> 
> >>> from collections import namedtuple
> >>> T = namedtuple("T", "foo bar baz")
> >>> t = T(1, 2, 3)
> >>> for name in t._fields:
> ... print(name, "=", getattr(t, name))
> ... 
> foo = 1
> bar = 2
> baz = 3

Wow. Ok, I can see that the specific circumstance I got the "object has
no attribute 'label' error was quite likely not due to using getattr()
with a variable for a namedtuple field name, and probably some other
factor was at work.

Unfortunately, when I shifted gears on the overall problem and abandoned
the strategy of making the group-by defaultdict, I renamed the project
file and started over, going back to the original list of namedtuples.
As a result, all the back versions of my code producing this error were
lost.

I've spent the better part of today rewriting the lost code, and I'm
nowhere near finished, and now my illness is ganging up on me again. So
anything further will have to wait til tomorrow.

I remain quite sure that at no point did I have the line

label = "label"

in my code, and I wouldn't even have thought of writing it because it's
so absurd in so many ways. Hopefully I can show you what I wrote soon,
and you can see for yourself.

> And as a special service here's a mutable datatype with sufficient 
> namedtuple compatibility to replicate the above snippet:
> 
> $ cat namedtuple_replacement.py
> def struct(name, wanted_columns):
> class Struct:
> _fields = __slots__ = wanted_columns.split()
> 
> def __init__(self, *args):
> names = self.__slots__
> if len(args) != len(names):
> raise ValueError
> for name, value in zip(names, args):
> setattr(self, name, value)
> 
> @classmethod
> def _make(cls, args):
> return cls(*args)
> 
> def __repr__(self):
> names = self.__slots__
> return "{}({})".format(
> self.__class__.__name__,
> ", ".join("{}={!r}".format(n, getattr(self, 
> n)) for n in 
> names)
> )
> 
> Struct.__name__ = name
> return Struct
> 
> T = struct("T", "foo bar baz")
> t = T(1, 2, 3)
> print(t)
> for name in t._fields:
> print(name, "=", getattr(t, name))
> t.bar = 42
> print(t)
> $ python3 namedtuple_replacement.py 
> T(foo=1, bar=2, baz=3)
> foo = 1
> bar = 2
> baz = 3
> T(foo=1, bar=42, baz=3)

Thank you for this datatype definition.

I won't take a serious look at it until I rewrite the code I lost and
get to the bottom of why getattr() got the attribute error, but once
that issue is resolved I will return to your mutable datatype with
namedtuple 
compatibility (to some extent, I gather).

I apologize for the delay, but your simple getattr() example above
demands that I find out why it wasn't working for me before moving on
with the rest of this. And that will take some time. Probably not the 3
weeks it took me to get to the point where I was consistently seeing the
error, but it will be awhile. I'll come back to address these issues and
your datatype when I've got code to show what I did. (For my own sanity,
if no other reason.)

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

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 4:59 PM, bartc  wrote:
> On 13/04/2017 22:58, Ian Kelly wrote:
>>
>> On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
>>  wrote:
>>>
>>> On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
>>> following:
>>>
 'goto' would be one easy-to-execute byte-code; no variables, objects or
 types to worry about. If implemented properly (with the byte-code
 compiler using a dedicated name-space for labels) there would be no name
 lookups.

>>>
>>> Only if GOTO is not allowed to break out of namespaces...
>>>
>>> NO GOTO from inside a function to some global catch-all
>>> handler...
>
>
> (That doesn't happen. No sane language would allow it, not on the user-side
> anyway.)

Well, you can do it in Assembly. And BASIC, if you count the primitive
GOSUB-type subroutines, though modern BASICs have real subroutines
that don't allow it.

>>> Once you permit uncontrolled/unlimited GOTO you have to be
>>> concerned
>>> with stack-frames and object life-times.
>>
>>
>> Even within a function you would still have to be concerned about a
>> goto from inside a try or with block to outside of that block, as the
>> finally block or the context manager's __exit__ still need to be
>> executed on the way out.
>
>
> So how does 'break' manage it? I assume break works from inside a try- or
> with-block.

Yes, it would have to work similarly to break, continue and return. I
didn't mean to imply that it was impossible, only that it's not quite
as simple as just modifying a program counter.

For reference, here's what break inside a try block compiles to:

>>> dis.dis("""
... while True:
... try:
... break
... finally:
... print("Bye")
... """)
  2   0 SETUP_LOOP  22 (to 24)

  3 >>2 SETUP_FINALLY6 (to 10)

  4   4 BREAK_LOOP
  6 POP_BLOCK
  8 LOAD_CONST   0 (None)

  6 >>   10 LOAD_NAME0 (print)
 12 LOAD_CONST   1 ('Bye')
 14 CALL_FUNCTION1
 16 POP_TOP
 18 END_FINALLY
 20 JUMP_ABSOLUTE2
 22 POP_BLOCK
>>   24 LOAD_CONST   0 (None)
 26 RETURN_VALUE
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Namedtuples: some unexpected inconveniences

[Roel Schroeven]

Gregory Ewing schreef op 13/04/2017 9:34:

Deborah Swanson wrote:

Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM


Personally I would immediately discard the header row once and for
all, not again and again on every operation.

Well, perhaps, but I need the header row to stay in place to write the
list to a csv when I'm done


That's no problem, just write the header row separately.

Do this at the beginning:

   header = [Record._make(fieldnames)]
   records = [Record._make(row) for row in rows]

and then to write out the file:

   writer = csv.writer(outputfile)
   writer.writerow(header)
   writer.writerows(records)


I don't even think there's any need to store the field names anywhere 
else than in fieldnames. So unless I'm missing something, just do this 
at the beginning:


fieldnames = next(rows)
Record = namedtuple("Record", fieldnames)
records = [Record._make(row) for row in rows]

and this at the end:

writer = csv.writer(outputfile)
writer.writerow(fieldnames) # or writer.writerow(Record._fields)
writer.writerows(records)


--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

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

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset 2cdf087d1fd48f7d0f95b5a0b31b9a624fa84751 by Mariatta in branch 
'3.6':
[3.6] bpo-29869: Allow underscores in numeric literals in lib2to3. (GH-1119) 
(GH-1122)
https://github.com/python/cpython/commit/2cdf087d1fd48f7d0f95b5a0b31b9a624fa84751


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +1259

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[bartc]

On 13/04/2017 22:58, Ian Kelly wrote:

On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
 wrote:

On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
following:


'goto' would be one easy-to-execute byte-code; no variables, objects or
types to worry about. If implemented properly (with the byte-code
compiler using a dedicated name-space for labels) there would be no name
lookups.



Only if GOTO is not allowed to break out of namespaces...

NO GOTO from inside a function to some global catch-all handler...


(That doesn't happen. No sane language would allow it, not on the 
user-side anyway.)



Once you permit uncontrolled/unlimited GOTO you have to be concerned
with stack-frames and object life-times.


Even within a function you would still have to be concerned about a
goto from inside a try or with block to outside of that block, as the
finally block or the context manager's __exit__ still need to be
executed on the way out.


So how does 'break' manage it? I assume break works from inside a try- 
or with-block.


Jumping /into/ such a block might be more tricky, but it is simple 
enough to not allow it.


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

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
 wrote:
> On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
> following:
>
>>'goto' would be one easy-to-execute byte-code; no variables, objects or
>>types to worry about. If implemented properly (with the byte-code
>>compiler using a dedicated name-space for labels) there would be no name
>>lookups.
>>
>
> Only if GOTO is not allowed to break out of namespaces...
>
> NO GOTO from inside a function to some global catch-all handler... No
> GOTO from a global scope into a non-global scope.
>
> Once you permit uncontrolled/unlimited GOTO you have to be concerned
> with stack-frames and object life-times.

Even within a function you would still have to be concerned about a
goto from inside a try or with block to outside of that block, as the
finally block or the context manager's __exit__ still need to be
executed on the way out.

Not to mention the time-honored tradition of using goto to jump INTO a
block, such as Duff's Device.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29999] repr() of ImportError misses keyword arguments name and path

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The patch also changes the repr of BaseException with a single argument. It no 
longer contains a trailing comma.

--
assignee:  -> serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28765] _sre.compile(): be more strict on types of indexgroup and groupindex

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Since _sre.compile is not a public API, and is called only with exact 
list/dict/tuple types in the stdlib, I prefer to ignore possible differences 
between base classes and subclasses. This makes the code cleaner.

Searching on GitHub shows that usages of _sre.compile() in third-party code are 
not compatible with current _sre.compile() since all arguments now are 
mandatory and indexgroup must be a tuple, not None.

--
assignee:  -> serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30067] _osx_support.py: misplaced flags in re.sub()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
keywords: +easy
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30067] _osx_support.py: misplaced flags in re.sub()

[Jakub Wilk]

New submission from Jakub Wilk:

Lib/_osx_support.py contains the following line:

flags = re.sub(r'-arch\s+\w+\s', ' ', flags, re.ASCII)

But the 4th re.sub() argument is the maximum number of substitutions, so this 
is equivalent to:

flags = re.sub(r'-arch\s+\w+\s', ' ', flags, count=256)

It was probably meant to be:

flags = re.sub(r'-arch\s+\w+\s', ' ', flags, flags=re.ASCII)


This bug was found using pydiatra:
http://jwilk.net/software/pydiatra

--
components: Library (Lib)
messages: 291631
nosy: jwilk
priority: normal
severity: normal
status: open
title: _osx_support.py: misplaced flags in re.sub()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29861] multiprocessing Pool keeps objects (tasks, args, results) alive too long

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
pull_requests: +1258

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29636] Specifying indent in the json.tool command

[Daniel Himmelstein]

Daniel Himmelstein added the comment:

@bob.ippolito thanks for pointing to jq as a reference implementation. I 
updated the pull request (https://git.io/vS9o8) to implement all of the 
relevant options. Currently, the PR supports the following mutually exclusive 
arguments:

--indent
--no-indent
--tab
--compact

These additions took 16 new lines of code in tool.py and 41 new lines of tests. 
However, I am happy to refactor the tests to be less repetitive if we choose to 
go forward with these changes.

@serhiy.storchaka I took a maximalist approach with respect to adding 
indentation options to GH #345. Although I know not all of the options may get 
merged, I thought we might as well work backwards.

However, the more I think about it, I do think every option above is a unique 
and valuable addition. I think that even with the changes, json.tool remains a 
lightweight wrapper json.load + json.dump.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Marko Rauhamaa]

Rob Gaddi :

> On 04/13/2017 08:26 AM, Marko Rauhamaa wrote:
>> I have occasionally felt the urge to try "goto" in my C code, but having
>> written it, I have taken it out. It just doesn't make the code look more
>> elegant or robust. Unlike "break" or "return," "goto" makes me uneasy
>> about variable scope and lifetime.
> [...]
> You see it all the time in kernel code or when doing I/O.  A pretty
> common pattern is:
>
>   int return_val = 1;
>   if (init_thing(x)) goto bk1;
>   if (init_thing(y)) goto bk2;
>   if (init_thing(z)) goto bk3;
>
>   do_things_with(x, y, z);
>   return_val = 0;
>
>   bk3:  cleanup_thing(z);
>   bk2:  cleanup_thing(y);
>   bk1:  cleanup_thing(x);
>   return return_val;

I know, but I still don't like it.


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

[issue29861] multiprocessing Pool keeps objects (tasks, args, results) alive too long

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, I can reproduce now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29861] multiprocessing Pool keeps objects (tasks, args, results) alive too long

[Antoine Pitrou]

Antoine Pitrou added the comment:

I can't reproduce here, on Ubuntu 16.04, after running the test 500 times.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16379] SQLite error code not exposed to python

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
versions: +Python 3.7 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29694] race condition in pathlib mkdir with flags parents=True

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
stage: test needed -> backport needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30065] Insufficient validation in _posixsubprocess.fork_exec()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

It is hard to reproduce (especially the second issue) since in all cases in the 
stdlib a list passed to fork_exec() is just created by sorted() and doesn't 
have other references. But if someone is so insane that passes int-like objects 
with non-idempotent __int__ as file descriptors his can get a crash in debug 
build (or mystical bugs in release build). Added tests utilizes this, but this 
unlikely happens in real code.

I have found this issue during analyzing usages of PyObject_Size(), 
PySequence_Size() and PyMapping_Size() in issue30061.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Nathan Ernst]

Thank you for that Alan Kay quote. Brightened up my day. Since you also
mentioned COBOL, and this is a thread about "goto", reminded me of the
single most abhorrent thing I ever saw in COBOL (I had to convert a single
COBOL batch process to ASP.Net as an intern back in 2003-4). "MOVE NEXT
SENTENCE". What is this statement? An unlabelled goto. It literally jumps
to the next period: "." in the source.

Now, I'm fine with judicious use of goto with good labels. (and, I've only
used goto maybe 3 or 4 times in a 15 year career), but a blocky construct
like "MOVE NEXT SENTENCE" in a language that also has lots of (all-caps
required) block statements to jump to a tiny on the screen period...that is
just evil.

On Thu, Apr 13, 2017 at 1:09 PM, Rustom Mody  wrote:

> On Thursday, April 13, 2017 at 11:14:15 PM UTC+5:30, Steve D'Aprano wrote:
> > Meyer's "Considered Harmful Essays Considered Harmful" essay is
> hypocritical
> > junk, and should be considered harmful.
>
> Your view.
> Here's an alternative.
> [Sorry its a vague memory of something I read more than a decade ago that
> I cant
> trace again]
> Some unknown Cobol programmer talking about Dijkstra:
>
> Dijkstra used his enormous prestige to destroy Cobol.
> We lost a great deal
> What did he gain?
> Ok so Cobol's control constructs are below par
> But do any of its modern successors have its data-describing properties?
> [the PIC clause]
>
> Or consider(!) Alan Kay's statement: "Arrogance in computer science is
> measured
> in nanodijktras"
> Maybe that's a response to similar violent, unnecessary barbs from
> Dijkstra?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30065] Insufficient validation in _posixsubprocess.fork_exec()

[Gregory P. Smith]

Gregory P. Smith added the comment:

nice find.  did anyone's code actually run into this issue?

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Check multiple file parms in single os.access?

[eryk sun]

On Thu, Apr 13, 2017 at 1:46 PM, Ben Bacarisse  wrote:
> James McMahon  writes:
>
>> Is there a way to mask the F_OK, R_OK, and W_OK in a single os.access
>> call? I'm guessing there must be, rather than doing this
>>
>> if ( os.access(fqfname,os.F_OK) and os.access(fqfname,os.R_OK) and
>> os.access(fqfname,os.W_OK)) :
>
> You can "or" together os.R_OK | os.W_OK into one call but you can can't

bitwise OR.

> do that with F_OK.  Mind you, I'm not sure that matters since I can't
> think of a case where you want to fail because os.F_OK fails but os.R_OK
> and os.W_OK succeeds.  In other words, why not just test for os.R_OK |
> os.W_OK?
>
> Note that despite using the "or" operation to construct the parameter,
> the test is an implied "and":
>
>   os.access(fqfname, os.R_OK | os.W_OK)
>
> is true only if both read and write access are permitted.

Note that os.access doesn't check file security on Windows. W_OK just
checks the read-only flag. Thus using try/except is really the only
possibility if you're on Windows and aren't using the Windows security
API.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Grant Edwards]

On 2017-04-13, Rob Gaddi  wrote:

> No, C doesn't support exception handling.  As a result, handling error 
> conditions in C is a huge pain for which (forward-only) goto is often, 
> while not the only remedy, the least painful one.

Indeed. That is almost the only place I use 'goto' in C, and the
almost the only place I see others use it.  Very occasionally, you see
a the error handling goto refactored into a backwards "goto retry":

this code

foo()
  {
  while (1)
{
  
  if ()
   goto error:
  
  return;

error:
  
}
  }

becomes

  foo()
  {
retry:
  
  if ()
{
   
   goto retry:
}
  
  }

I happen to find the latter easier to read.

Fortunately, Python doesn't need goto to deal with things like that.

> Or if you've really developed a need for self-harm, setjmp/longjmp.

I've tried to use setjmp/longjmp for error handling a few times.  It
never went well...

-- 
Grant Edwards   grant.b.edwardsYow! Catsup and Mustard all
  at   over the place!  It's the
  gmail.comHuman Hamburger!

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

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Larry Martell]

On Thu, Apr 13, 2017 at 2:09 PM, Rustom Mody  wrote:
> Or consider(!) Alan Kay's statement: "Arrogance in computer science is 
> measured
> in nanodijktras"

Completely unrelated but it reminded me about this bon mot about Niklaus Wirth:

Europeans tend to pronounce his name properly, as Nih-klaus Virt,
while Americans usually mangle it into something like Nickles Worth.
That has led to the programmer joke saying Europeans call him by name
while Americans call him by value.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29995] re.escape() escapes too much

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Rustom Mody]

On Thursday, April 13, 2017 at 11:14:15 PM UTC+5:30, Steve D'Aprano wrote:
> Meyer's "Considered Harmful Essays Considered Harmful" essay is hypocritical
> junk, and should be considered harmful.

Your view.
Here's an alternative.
[Sorry its a vague memory of something I read more than a decade ago that I cant
trace again]
Some unknown Cobol programmer talking about Dijkstra:

Dijkstra used his enormous prestige to destroy Cobol.
We lost a great deal
What did he gain?
Ok so Cobol's control constructs are below par
But do any of its modern successors have its data-describing properties?
[the PIC clause]

Or consider(!) Alan Kay's statement: "Arrogance in computer science is measured
in nanodijktras" 
Maybe that's a response to similar violent, unnecessary barbs from Dijkstra?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 19:38, Ian Kelly  wrote:
> On Thu, Apr 13, 2017 at 11:25 AM, Mikhail V  wrote:
>> On 13 April 2017 at 18:48, Ian Kelly  wrote:
>>> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
 Now I wonder, have we already collected *all* bells and whistles of Python
 in these two examples, or is there something else for expressing trivial 
 thing.
>>>
>>> Functions and exceptions are considered "bells and whistles"?
>>
>> You mean probably classes and exceptions? For me, indeed they are,
>> but it depends.
>
> No, I meant functions (the first example) and exceptions (the second example).
>
>> And breaking the code into def() chunks that are not
>> functions but just chunks... I don't know, looks bad.
>
> I don't know what you mean by this. There is no such thing as a "def()
> chunk" that is not a function.

I mean that in my example I have consequent code and Rob takes a part of the
code and puts it in a function. And this is just a part of code, I don't need
here anything to wrap or return and don't want to scroll up and down and
collect it all in my brain back into original sequence. Therefore I've called
it abstract art.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29995] re.escape() escapes too much

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 5908300e4b0891fc5ab8bd24fba8fac72012eaa7 by Serhiy Storchaka in 
branch 'master':
bpo-29995: re.escape() now escapes only special characters. (#1007)
https://github.com/python/cpython/commit/5908300e4b0891fc5ab8bd24fba8fac72012eaa7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29694] race condition in pathlib mkdir with flags parents=True

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset 22a594a0047d7706537ff2ac676cdc0f1dcb329c by Mariatta (Armin Rigo) 
in branch 'master':
bpo-29694: race condition in pathlib mkdir with flags parents=True (GH-1089)
https://github.com/python/cpython/commit/22a594a0047d7706537ff2ac676cdc0f1dcb329c


--
nosy: +Mariatta

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Rustom Mody]

On Thursday, April 13, 2017 at 11:19:38 PM UTC+5:30, Ian wrote:
> On Thu, Apr 13, 2017 at 11:39 AM, Rustom Mody wrote:
> > My broader point (vive la Trump) was that if we learn to actively tolerate
> > people with views wildly far from ours, the world would be a better place.
> 
> I fail to see how my comment "Functions and exceptions are considered
> 'bells and whistles'?" suggests intolerance on my part.

It was not directed specifically at you but at the overall quality of responses
that Mikhail is receiving for his (to me admittedly) outlandish views
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 11:39 AM, Rustom Mody  wrote:
> My broader point (vive la Trump) was that if we learn to actively tolerate
> people with views wildly far from ours, the world would be a better place.

I fail to see how my comment "Functions and exceptions are considered
'bells and whistles'?" suggests intolerance on my part.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rob Gaddi]

On 04/13/2017 08:26 AM, Marko Rauhamaa wrote:

Chris Angelico :


Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.


I have occasionally felt the urge to try "goto" in my C code, but having
written it, I have taken it out. It just doesn't make the code look more
elegant or robust. Unlike "break" or "return," "goto" makes me uneasy
about variable scope and lifetime.

Maybe it would work in some state machine implementation. Some 30 years
ago I wrote a compiler. The parser came out nicer with methodical use of
"goto," but even then, I used a parsing-specific macro to wrap it.


Marko



You see it all the time in kernel code or when doing I/O.  A pretty 
common pattern is:


  int return_val = 1;
  if (init_thing(x)) goto bk1;
  if (init_thing(y)) goto bk2;
  if (init_thing(z)) goto bk3;

  do_things_with(x, y, z);
  return_val = 0;

  bk3:  cleanup_thing(z);
  bk2:  cleanup_thing(y);
  bk1:  cleanup_thing(x);
  return return_val;

But the point is, in Python we have context managers and exceptions and 
classes, all of which serve to allow you to not have to explicitly lay 
out how to wind yourself step-by-step back out of the situation you've 
gotten yourself into.


--
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: Python and the need for speed

[MRAB]

On 2017-04-13 09:08, Steven D'Aprano wrote:

On Wed, 12 Apr 2017 16:30:38 -0700, bart4858 wrote:


(Although I think Python would have difficulty in turning x+=1 into a
single opcode, if using normal object references and a shared object
model.)


You know, since Python actually exists and isn't just a hypothetical
language, we can find out what it actually does, not just guess :-)



import dis
code = compile("x += 1", "", "single")
dis.dis(code)

   1   0 LOAD_NAME0 (x)
   3 LOAD_CONST   0 (1)
   6 INPLACE_ADD
   7 STORE_NAME   0 (x)
  10 LOAD_CONST   1 (None)
  13 RETURN_VALUE


There's an op-code for looking up the name 'x', another to push the
constant 1 on the stack, an op-code for "INPLACE_ADD", followed by an op-
code for STORE_NAME again.

In principle, we could replace the LOAD_CONST and INPLACE_ADD with a
single op-code that combines the two. Whether that would speed anything
up is another question.

Is it possible to skip the STORE_NAME op-code? If you knew *for sure*
that the target (x) was a mutable object which implemented += using an in-
place mutation, then you could, but the only built-in where that applies
is list so even if you could guarantee x was a list, it hardly seems
worth the bother.

If the reference to be stored by STORE_NAME is the same as the reference 
returned by LOAD_NAME, then STORE_NAME could be omitted.


That would just mean remembering that address.

I'm still trying to think whether it's ever possible to lose all 
references to the object when INPLACE_ADD is called, leading to the 
object having been garbage-collected by the time it returns.

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

Goto Considered Harmful [was Re: Python and the need for speed]

[Steve D'Aprano]

On Wed, 12 Apr 2017 10:44 am, 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.

Indeed. The problem is that it is abused far more often than it is used
correctly -- or at least it was, back in the days when people routinely
used GOTO. People don't abuse GOTO much these days only because most
languages don't encourage, or even allow, GOTO.


> Constructs like 'break', 'continue' or 'next' in languages like Python or
> C/C++ are goto's with implied labels.

They are *restricted* and *structured* jumps, which is not the same thing as
an *unrestricted and unstructured* GOTO.

In much the same way that hiring a private security guard is not quite the
same thing as declaring martial law and telling the soldiers they have
carte blanche to shoot to kill for any reason at all.


> As Mikhail said, goto's can be great to break out of nested loops (only a
> handful of languages support named 'breaks').

I have to ask... 

if named breaks are so great, why don't more languages support them?


> People need to stop drinking "X is considered harmful." 

That's one opinion.


> Even Dijkstra 
> later lamented that his "Goto considered harmful" paper was misinterpreted
> and misrepresented as advocating that goto should never be used.

Citation required.

1987 was pretty much the last gasp of the unstructured programming paradigm,
the last time that anyone made a serious case for it. Frank Rubin responded
to Dijkstra's famous letter with a response

"GOTO Considered Harmful Considered Harmful"

Unfortunately, his response was not so much a refutation of Dijkstra, but
the last desperate and failed defence of an all-but-dead programming style.

Dijkstra responded to Rubin in an especially cranky (and rather pedantic and
arrogant manner). You can read his response here:

https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1009.html

Bottom line: Rubin's code was buggy, and the problem he posed could be
solved without GOTO.

More on the history of Dijkstra's letter here:

https://blog.codinghorror.com/id-consider-that-harmful-too/

and a connection to Python:

http://joshuah.scripts.mit.edu/blog/?p=195



> Additionally, I'd recommend everyone read '"Considered Harmful" Essays
> Considered Harmful': http://meyerweb.com/eric/comment/chech.html

The author makes a number of dogmatic claims without offering a shred of
evidence for any of them. He expects us to simply believe on his say-so
alone that "Considered Harmful" essays are counter-productive to their own
cause, a clear and obvious case of "concern trolling" if I've ever seen
one.

His essay is full of weasel words and unsupported opinions masquerading as
facts:

* Considered Harmful essays "often" inflame the debate (how often? 1% 
  of the time or 99% of the time? how do you know?)

* supporters of the opposing view are "more likely" to dig in and 
  defend their position (how much more like? how do you know?)

* Considered Harmful essays have "a strong tendency to alienate neutral
  parties" (how strong? how do you know?)

and he contradicts himself: Considered Harmful essays are "boring cliches"
that nobody bothers to read or pay any attention to.

Strangely enough, despite Considered Harmful being a boring, counter-
productive cliche that harms your own cause, the author Eric Meyer chose to
write one himself. Recognising this contradiction, he tries to pass it off
as a joke.

And what is his cause? To argue against a strawman, that Considered Harmful
essays cannot and do not "engage in reasoned debate". They don't? Says who?
Why can't a paper that draws a firm and opinionated conclusion (as Meyer
himself does) also be reasoned?

Meyer himself doesn't sit on the fence. He argues against Considered Harmful
essays. Not very convincingly, but he does take a position against them.
Why doesn't he follow his own advice, and describe the strengths and
weaknesses of Considered Harmful essays?

So there's one rule for Meyer, and everyone else should write wishy-washy
fence-sitting essays that draw no firm conclusions.

Meyer states that a "benefits and weaknesses" essay will allow people
to "more readily find a compromise solution" without questioning whether or
not a compromise solution is either possible or desirable. For example:

- A language cannot compromise on the question of whether to allow 
  COMEFROM: it either supports that *deliberately awful* language
  misfeature, or it doesn't. 

- Even if a compromise position is *possible*, that doesn't mean that
  one is desirable. Should array indexing start at 0 or 1, or shall
  we compromise with 0.5? 

Meyer implicitly assumes that technical questions are won by "reasoned
debate", which goes against the history of science and technology and in
fact all of human history. Very few questions can be resolved by mere
facts. Rather, they are resolved by *persuasion*, and despite Meyer's
concern-trolling, it 

Re: "Goto" statement in Python

[Rustom Mody]

On Thursday, April 13, 2017 at 10:56:53 PM UTC+5:30, Rob Gaddi wrote:
> On 04/13/2017 10:13 AM, Rustom Mody wrote:
> > On Thursday, April 13, 2017 at 10:19:33 PM UTC+5:30, Ian wrote:
> >> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> >>> Now I wonder, have we already collected *all* bells and whistles of Python
> >>> in these two examples, or is there something else for expressing trivial 
> >>> thing.
> >>
> >> Functions and exceptions are considered "bells and whistles"?
> >
> > People's tastes differ… violently on
> > - food
> > - music
> > - opposite sex
> >
> > What to do??
> > Ask Trump?
> > [I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]
> >
> > I wonder if you noticed that you classed functions together with 
> > exceptions...
> > presumably as basic elements.
> > And that the bedrock of much contemporary computer technology — 
> > linux-kernel,
> > even (C)Python itself, viz C — does not support one of these
> >
> 
> No, C doesn't support exception handling.  As a result, handling error 
> conditions in C is a huge pain for which (forward-only) goto is often, 
> while not the only remedy, the least painful one.  Or if you've really 
> developed a need for self-harm, setjmp/longjmp.  Or, as is more 
> frequently the case in code in the wild, error conditions simply don't 
> get checked for and come as a surprise and/or segfault later on.
> 
> Python is a radically higher level language than C.  Python supports 
> different structures than C, largely and specifically so that you don't 
> have to do things in some of the error-prone ways you would do them in 
> C.  Therefore, a given task should be solved differently in Python than 
> in C.

You are answering to a different issue than I was: Sure C and python are done
differently [your point]
I was saying that if Mikhail finds exceptions (and as he later explained 
classes) as a heavy-duty solution to a control-flow issue, he has a point

> 
> I try very hard to write Python when I write Python, and to write C when 
> I write C.  And to write through the tears when I write C++.

C++ has exceptions but no gc
Haskell has gc (like python) but no exceptions
So that suggests that while desirable, both are not in the bare-minimum set

My broader point (vive la Trump) was that if we learn to actively tolerate 
people with views wildly far from ours, the world would be a better place.

So what would I say to (people like) Mikhail?
"Here's the sources mate! Fork it! And cheers!"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 11:25 AM, Mikhail V  wrote:
> On 13 April 2017 at 18:48, Ian Kelly  wrote:
>> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
>>> Now I wonder, have we already collected *all* bells and whistles of Python
>>> in these two examples, or is there something else for expressing trivial 
>>> thing.
>>
>> Functions and exceptions are considered "bells and whistles"?
>
> You mean probably classes and exceptions? For me, indeed they are,
> but it depends.

No, I meant functions (the first example) and exceptions (the second example).

> And breaking the code into def() chunks that are not
> functions but just chunks... I don't know, looks bad.

I don't know what you mean by this. There is no such thing as a "def()
chunk" that is not a function.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 11:13 AM, Rustom Mody  wrote:
> What to do??
> Ask Trump?
> [I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]

Not even close. Whatever one's opinion may be of Trump, he hasn't
murdered millions of people.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset a6e395dffadf8c5124903c01ad69fefa36b1a935 by Mariatta (Nevada 
Sanchez) in branch 'master':
bpo-29869: Allow underscores in numeric literals in lib2to3. (GH-1119)
https://github.com/python/cpython/commit/a6e395dffadf8c5124903c01ad69fefa36b1a935


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Rob Gaddi]

On 04/13/2017 10:13 AM, Rustom Mody wrote:

On Thursday, April 13, 2017 at 10:19:33 PM UTC+5:30, Ian wrote:

On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:

Now I wonder, have we already collected *all* bells and whistles of Python
in these two examples, or is there something else for expressing trivial thing.


Functions and exceptions are considered "bells and whistles"?


People's tastes differ… violently on
- food
- music
- opposite sex

What to do??
Ask Trump?
[I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]

I wonder if you noticed that you classed functions together with exceptions...
presumably as basic elements.
And that the bedrock of much contemporary computer technology — linux-kernel,
even (C)Python itself, viz C — does not support one of these



No, C doesn't support exception handling.  As a result, handling error 
conditions in C is a huge pain for which (forward-only) goto is often, 
while not the only remedy, the least painful one.  Or if you've really 
developed a need for self-harm, setjmp/longjmp.  Or, as is more 
frequently the case in code in the wild, error conditions simply don't 
get checked for and come as a surprise and/or segfault later on.


Python is a radically higher level language than C.  Python supports 
different structures than C, largely and specifically so that you don't 
have to do things in some of the error-prone ways you would do them in 
C.  Therefore, a given task should be solved differently in Python than 
in C.


I try very hard to write Python when I write Python, and to write C when 
I write C.  And to write through the tears when I write 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: "Goto" statement in Python

[Thomas Nyberg]

On 04/12/2017 04:42 PM, Mikhail V wrote:
> For me it looks clear and I'd say easy to comprehend,
> Main critic would be obviously that it is not
> a good, *scalable application*, but quite often I don't
> even have this in mind, and just want to express a
> step-by-step direct instructions.

I think that scalability is the only objectively reasonable (at least as
far as this kind of argument could be objective) argument against gotos.
They're not fundamentally a bad idea (the people who put them into
certain languages weren't stupid after all), but they do seem to create
a maintenance and complexity burden as the codebase grows. But if you're
talking one off single scripts as your example, I think you can safely
use many habits considered bad by most. That's simply not the scenario
where gotos create a problem.

There are of course many different ways you can get around using them,
but there are certainly cases where that's exactly what you want and a
substitute will always be a substitute and it may feel lacking. It's
just a matter of taste really.

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

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 18:48, Ian Kelly  wrote:
> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
>> Now I wonder, have we already collected *all* bells and whistles of Python
>> in these two examples, or is there something else for expressing trivial 
>> thing.
>
> Functions and exceptions are considered "bells and whistles"?

You mean probably classes and exceptions? For me, indeed they are,
but it depends.

And breaking the code into def() chunks that are not
functions but just chunks... I don't know, looks bad.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 13/04/2017 16:03, Ian Kelly wrote:

On Thu, Apr 13, 2017 at 8:52 AM, bartc  wrote:

On 13/04/2017 15:35, Chris Angelico wrote:

Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.



It might be a better idea to have a multi-level loop break then. This would
also be an absolute jump byte-code.


This has previously been proposed and rejected:
https://www.python.org/dev/peps/pep-3136/


Poorly presented I think with, what, five possible ways of adding it?


Rejection notice:
https://mail.python.org/pipermail/python-3000/2007-July/008663.html


Rejected because it would only occur in complex code? That's just where 
it would help!


I think it should be in for completeness, and to avoid this bug in the 
language; start with:


 for i in range(n):
break;

break inside a loop; that's currently allowed. Now for reasons of logic, 
that break is put inside an 'if' branch:


 for i in range(n):
if cond:
   break;

The break still works. But if, for any reason at all, that break ended 
up inside a nested loop instead of a nested if:


 for i in range(n):
while cond:
   break;

Now it no longer works as expected. The break has been 'captured' by the 
new loop.


(IME most breaks from loops are either from the innermost loop, or from 
the outermost one. For these two cases, you don't need naming, labelling 
or numbering of loops. Just 'break [inner]' or 'break outer'.)


--
bartc

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

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Nevada Sanchez]

Changes by Nevada Sanchez :


--
pull_requests: +1257

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Rustom Mody]

On Thursday, April 13, 2017 at 10:19:33 PM UTC+5:30, Ian wrote:
> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> > Now I wonder, have we already collected *all* bells and whistles of Python
> > in these two examples, or is there something else for expressing trivial 
> > thing.
> 
> Functions and exceptions are considered "bells and whistles"?

People's tastes differ… violently on
- food
- music
- opposite sex

What to do??
Ask Trump?
[I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]

I wonder if you noticed that you classed functions together with exceptions...
presumably as basic elements.
And that the bedrock of much contemporary computer technology — linux-kernel,
even (C)Python itself, viz C — does not support one of these
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> Now I wonder, have we already collected *all* bells and whistles of Python
> in these two examples, or is there something else for expressing trivial 
> thing.

Functions and exceptions are considered "bells and whistles"?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 53ad68434ce914defcc1b734cce4b9b4d79ca3fc by Serhiy Storchaka in 
branch '2.7':
bpo-30021: Add examples for re.escape(). (#1048) (#1118)
https://github.com/python/cpython/commit/53ad68434ce914defcc1b734cce4b9b4d79ca3fc


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset e2cf9a918439006fb27f67c1939d0370886650e7 by Serhiy Storchaka in 
branch '3.5':
bpo-30021: Add examples for re.escape(). (#1048) (#1116)
https://github.com/python/cpython/commit/e2cf9a918439006fb27f67c1939d0370886650e7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 936633282220768a6fec9bd6bb53ee9e3ec354df by Serhiy Storchaka in 
branch '3.6':
bpo-30021: Add examples for re.escape(). (#1048) (#1115)
https://github.com/python/cpython/commit/936633282220768a6fec9bd6bb53ee9e3ec354df


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1256

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21301] pathlib missing Path.expandvars(env=os.environ)

[Berker Peksag]

Changes by Berker Peksag :


--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1255

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Mikhail V]

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; S=' + S)
>
> try:
>   message = finder()
>   print(message)
>   log += message
> except ValueError as e:
>   print(e)
>

Mother of God... This is like placing some abstract art into a gallery
of monumentalism art.
I am upset and need some healing therapy now.
I'll stay here  for a while:
https://www.pinterest.com/soren19/arqbrt/


On 13 April 2017 at 13:31, alister  wrote:
>
> I expect you could simulate most of these with a custom exception
> for example break from nested loop:
>
> class GoTo(Exception):
> pass
>
> try:
> for i in range(100):
> print i
> for j in range (50):
> print j
> if i*j>60:
> raise GoTo
> except GoTo:
> print "Exit Early"
> print "end of loop"
>

Now I wonder, have we already collected *all* bells and whistles of Python
in these two examples, or is there something else for expressing trivial thing.


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

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +1254

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30021] Add examples for re.escape()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 8fc7bc2b7631ee819ee614e47b6f44bacebe1574 by Serhiy Storchaka in 
branch 'master':
bpo-30021: Add examples for re.escape(). (#1048)
https://github.com/python/cpython/commit/8fc7bc2b7631ee819ee614e47b6f44bacebe1574


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Visit All URLs with selenium python

[John Gordon]

In <43f70312-83ba-457e-a83f-7b46e5d2a...@googlegroups.com> Nicole 
 writes:

> it just visit first url not all .. Can anybody help how to fix that..

Have you tried some basic debugging, for example printing p_links to
verify that it contains what you expected, and then printing each
url in the loop?

-- 
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

Pylint 1.7.0 was released

[Claudiu Popa]

Hey folks,

We just released a new version of Pylint, 1.7.0, after a long period
of time since the last release.

You can find more details about what's new in this release over here:
https://pylint.readthedocs.io/en/latest/whatsnew/1.7.html


Thanks and enjoy,
Claudiu
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29869] Underscores in numeric literals not supported in lib2to3.

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Nevada Sanchez, please create your PR against the master branch.
Once that is merged, we will backport it to the 3.6 branch.

Thanks :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: "Goto" statement in Python

[Marko Rauhamaa]

Chris Angelico :

> Personally, I can't remember the last time I yearned for "goto" in
> Python, and the only times I've ever wished for it or used it in other
> languages have been multi-loop breaks or "for...else" blocks. And
> neither is very frequent.

I have occasionally felt the urge to try "goto" in my C code, but having
written it, I have taken it out. It just doesn't make the code look more
elegant or robust. Unlike "break" or "return," "goto" makes me uneasy
about variable scope and lifetime.

Maybe it would work in some state machine implementation. Some 30 years
ago I wrote a compiler. The parser came out nicer with methodical use of
"goto," but even then, I used a parsing-specific macro to wrap it.


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

Re: Calling dunder methods manually

[eryk sun]

On Thu, Apr 13, 2017 at 8:24 AM, Chris Warrick  wrote:
> On 13 April 2017 at 09:43, eryk sun  wrote:
>> The functions in the operator module implement abstract behavior (e.g.
>> PyNumber_Add in CPython):
>>
>> >>> operator.__add__(C(), D())
>> 42
>
> Those functions also do not need underscores — operator.add is a
> prettier way to achieve the same result.

I debated myself about which one to use in the example. The dunder
aliases were added for completeness, to clarify the relationship to
the corresponding special method, and I suppose to make it simpler to
dynamically call them. I opted to use the explicit name, even though
it's an alias because it seemed to make the example more consistent.
Normally I would call operator.add.
-- 
https://mail.python.org/mailman/listinfo/python-list

[no subject]

[David Shi via Python-list]

Which VCF reader has been well tested and proven to be robust?
Looking forward to hearing from you.
Regards.
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 8:52 AM, bartc  wrote:
> On 13/04/2017 15:35, Chris Angelico wrote:
>> Personally, I can't remember the last time I yearned for "goto" in
>> Python, and the only times I've ever wished for it or used it in other
>> languages have been multi-loop breaks or "for...else" blocks. And
>> neither is very frequent.
>
>
> It might be a better idea to have a multi-level loop break then. This would
> also be an absolute jump byte-code.

This has previously been proposed and rejected:
https://www.python.org/dev/peps/pep-3136/
Rejection notice:
https://mail.python.org/pipermail/python-3000/2007-July/008663.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 13/04/2017 15:35, Chris Angelico wrote:

On Thu, Apr 13, 2017 at 9:31 PM, alister  wrote:

I expect you could simulate most of these with a custom exception
for example break from nested loop:

class GoTo(Exception):
pass

try:
for i in range(100):
print i
for j in range (50):
print j
if i*j>60:
raise GoTo
except GoTo:
print "Exit Early"
print "end of loop"


Or you could turn it into a function and "return". Or if you feel like
it, you could turn the nested loops into a generator, then iterate
over it and break when you need to.


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.


'goto' would be one easy-to-execute byte-code; no variables, objects or 
types to worry about. If implemented properly (with the byte-code 
compiler using a dedicated name-space for labels) there would be no name 
lookups.


Function calls, returns and generators are rather more heavyweight in 
comparison.


 There are many things you CAN do,

but to the true goto-aficionado, none of them is as clean.

Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.


It might be a better idea to have a multi-level loop break then. This 
would also be an absolute jump byte-code.


--
bartc



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

Re: "Goto" statement in Python

[Chris Angelico]

On Thu, Apr 13, 2017 at 9:31 PM, alister  wrote:
> I expect you could simulate most of these with a custom exception
> for example break from nested loop:
>
> class GoTo(Exception):
> pass
>
> try:
> for i in range(100):
> print i
> for j in range (50):
> print j
> if i*j>60:
> raise GoTo
> except GoTo:
> print "Exit Early"
> print "end of loop"

Or you could turn it into a function and "return". Or if you feel like
it, you could turn the nested loops into a generator, then iterate
over it and break when you need to. There are many things you CAN do,
but to the true goto-aficionado, none of them is as clean.

Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.

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

[issue27200] make doctest in CPython has failures

[Berker Peksag]

Berker Peksag added the comment:


New changeset 7b2491a6aa5cdc1f8f9e3fd9df91f29ee69aa982 by Berker Peksag (Marco 
Buttu) in branch 'master':
bpo-27200: Fix pathlib, ssl, turtle and weakref doctests (GH-616)
https://github.com/python/cpython/commit/7b2491a6aa5cdc1f8f9e3fd9df91f29ee69aa982


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

HOT LIST

[Jack]

Hi  

Hope you doing great!
Greeting from Niche Soft Solutions.
 
I would like to present our topnotch consultants currently available.
Please have a look at the below hot list of Niche Soft Solutions and mail your 
Direct Client requirements to j...@nichesoftsolutions.com
 
Please add my Email ID to your mailing list and send the requirements on daily 
basis
You can reach me at 503-536-2043
 
 
 
Name
Technology
Experience
Visa status
Current Location
Relocation
Tapasya
.Net & Data Analyst
10+
H1B
CO
OPEN
Malika
Java
9+
H1B
CA
OPEN
Vinoth
Data Stage Developer
7+
H1B
MI
OPEN
Sumathi
QA Tester
8+
H1B
CT
OPEN
Rahul
People Soft
8+
H1B
CA
OPEN
Laxman
Java
10+
H1B
VA
VA
Pooja Gosh
WebMethod Developer
7+
H1B
CA
OPEN
Rashi
Guidewire Developer
8+
H1B
TX
OPEN
Shabeer
WebMethod Developer
7+
H1B
NC
OPEN



With Regards
   Jack
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30036] The bugs website doesn't use httpS by default

[Berker Peksag]

Berker Peksag added the comment:

I've changed the bugs.p.o link to use HTTPS at python.org.

--
nosy: +berker.peksag

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Check multiple file parms in single os.access?

[Ben Bacarisse]

James McMahon  writes:

> Hello. Am a Python newbie. I have researched and found examples how we can
> check existence, readability, and write-ability on a given fully-qualified
> filename for the current python script user. Evidently os.access is the way
> to go, wrapped in some additional try and catch logic that helps insulate
> us from changes in file state after our os.access checks.

I'm not sure what you are saying here but I think it relates to a point
I was going to make...  In general, I'd say that testing for access is
not the way to go.  It is almost always better simply to try the
operations you need to do and deal with the failures as they occur.  The
bottom line is that you can't be sure the operation will work even if
os.access said it should a few moments ago.

> I understand that os.stat() calls can be relatively expensive. I
> assume likewise for os.access(). Since I'm going to apply my Python
> permission check script within a NiFi ExecuteScript processor handling
> many flowfiles, I seek any and all performance optimizations I
> possibly can.
>
> Is there a way to mask the F_OK, R_OK, and W_OK in a single os.access
> call? I'm guessing there must be, rather than doing this
>
> if ( os.access(fqfname,os.F_OK) and os.access(fqfname,os.R_OK) and
> os.access(fqfname,os.W_OK)) :

You can "or" together os.R_OK | os.W_OK into one call but you can can't
do that with F_OK.  Mind you, I'm not sure that matters since I can't
think of a case where you want to fail because os.F_OK fails but os.R_OK
and os.W_OK succeeds.  In other words, why not just test for os.R_OK |
os.W_OK?

Note that despite using the "or" operation to construct the parameter,
the test is an implied "and":

  os.access(fqfname, os.R_OK | os.W_OK)

is true only if both read and write access are permitted.

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

[issue30066] anaconda3::traitsu::NotImplementedError

[Berker Peksag]

Berker Peksag added the comment:

Please report this to either traits or traitsui developers. This issue tracker 
is for issues with CPython and its standard library, not for third-party 
modules on PyPI.

--
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python and the need for speed

[Marko Rauhamaa]

Steve D'Aprano :

> On Thu, 13 Apr 2017 07:00 pm, Marko Rauhamaa wrote:
>> Thing is, the moment you start thrashing, the game is over.
>
> Indeed. But swapping != thrashing.
>
> For what it's worth, three of the five sys admins I work with prefer
> not to use swap space on the Linux desktops they build. I'm not sure
> what their opinion is about servers. I *think* they would be okay with
> it if the server was using SSD rather than spinning metal.

Not sure if this is still valid:

   Still today Flash RAM cells built in SSDs have a limited lifespan.
   Every write (not read) cycle or better every erasure wears a memory
   cell and at some time it will stop working.

   https://askubuntu.com/questions/652337/why-no-swap-partition
   s-on-ssd-drives>


I really don't see much point with swap space nowadays, anyway.
Especially as it comes to production servers, you should reserve enough
RAM for worst-case needs. And make sure you really need that much RAM;
you probably don't.


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

[issue29791] print documentation: flush is also a keyword argument

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the report!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29791] print documentation: flush is also a keyword argument

[Berker Peksag]

Berker Peksag added the comment:


New changeset 119d94ad37a99ecb0b8329467d04cd9d909e310e by Berker Peksag in 
branch '3.6':
bpo-29791: Clarify that flush is keyword-only argument (GH-1093)
https://github.com/python/cpython/commit/119d94ad37a99ecb0b8329467d04cd9d909e310e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29791] print documentation: flush is also a keyword argument

[Berker Peksag]

Berker Peksag added the comment:


New changeset df9783720e40773e7854d2f4e4cfc93f0a2c08b8 by Berker Peksag in 
branch '3.5':
bpo-29791: Clarify that flush is keyword-only argument (GH-1093)
https://github.com/python/cpython/commit/df9783720e40773e7854d2f4e4cfc93f0a2c08b8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30066] anaconda3::traitsu::NotImplementedError

[leopoldo]

New submission from leopoldo:

the code below crash when run on anaconda3



import traits.api as trapi
import traitsui.api as trui

from traits.api import HasTraits, Str, Range, Enum

class Person(HasTraits):
name = Str('Jane Doe')
age = Range(low=0)
gender = Enum('female', 'male')

person = Person(age=30)

from traitsui.api import Item, RangeEditor, View

person_view = View(
Item('name'),
Item('gender'),
Item('age', editor=RangeEditor(mode='spinner')),
buttons=['OK', 'Cancel'],
resizable=True,
)


person.configure_traits(view=person_view)
---
NotImplementedError   Traceback (most recent call last)
 in ()
> 1 person.configure_traits(view=person_view)

/home/leopoldo/anaconda3/lib/python3.6/site-packages/traits/has_traits.py in 
configure_traits(self, filename, view, kind, edit, context, handler, id, 
scrollable, **args)
   2169 context = self
   2170 rc = toolkit().view_application( context, self.trait_view( 
view ),
-> 2171kind, handler, id, 
scrollable, args )
   2172 if rc and (filename is not None):
   2173 fd = None

/home/leopoldo/anaconda3/lib/python3.6/site-packages/traitsui/toolkit.py in 
view_application(self, context, view, kind, handler, id, scrollable, args)
289 
290 """
--> 291 raise NotImplementedError
292 
293 
#---

NotImplementedError:

--
messages: 291611
nosy: leopoldotosi
priority: normal
severity: normal
status: open
title: anaconda3::traitsu::NotImplementedError
type: crash
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com