Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 5:54 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> Question: How do you get a reference to a Ruby function? Or are they
>> not first-class objects?
>
>
> They're not first-class. So, you can't.
>

Ahh, that explains it. Great. So how do you build higher-order
functions? Or don't you?

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Stephen Hansen]

On Mon, Mar 26, 2018, at 2:19 PM, Rick Johnson wrote:
>Sure, the behavior that Steven
> uncovered is odd, but it could be that Maz harbors a strong
> disliking for undisciplined pupils, and thus, he designed
> and placed this little trap in the hopes the pain it induced
> might encourage the petulant little meat-heads to follow
> some sensible styling rules.

My god, I've been away from this list for quite awhile, but we're still 
entertaining this fool? 

-- 
Stephen Hansen
  m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:

> On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote:
>> Rick, you're supposedly familiar with Ruby. And yet, you didn't notice
>> that your supposed "fix" didn't touch any executable code, all it did
>> was modify the strings being printed.
> 
> Because the goal was to *UN-OBFUSCATE* the code, not to provide a
> solution for the problem _you_ created.

Printing a string and calling a function is obfuscated code? Deary me.

And besides, while I'm more than happy to take (undeserved) credit for 
all the things Ruby gets right, I draw the line at being blamed for Ruby 
misfeatures like parens-less function calls, and the inconsistent 
behaviour they lead to.


>> Because of this "fix", the printed strings no longer match the code
>> being executed, but the strange, inconsistent behaviour still occurs.
> 
> The supposed "inconsistent behavior" here has absolutely nothing to do
> with Ruby, no, it's all on _you_. _YOU_ are the one who created a
> non-sensical function 

I love watching you trying to squirm your way out of admitting that you 
screwed up. Returning the input plus two is nonsensical is it?

Thank the gods I didn't add *three*, your head probably would have 
exploded in confusion.


> with a single char name; and _YOU_ are the one who
> placed a call to that function in the middle of an expression, which, on
> first glance, looks to be a common numeric addition or string
> concatenation. There are no syntactical clues that `a` is a function.

As I said, don't blame me for Ruby's poor design.

By the way, there are precisely the same number of clues that:

a

is a function as there are for:

super

in Ruby. But you know that, because you were vehemently defending the use 
of super with no parens and why it isn't inconsistent for it to do 
something completely different from super() with parens.


> Thus, it is _YOU_ who is to blame for the supposed "unexpected output".
> 
> Ruby followed the rules.
> 
> But you didn't.

So now you're claiming I hacked the Ruby interpreter to support non-
standard code? I can smell the desperation in you from the other side of 
the planet.

Rick, nothing I did was illegal Ruby code. Everything I did was 100% 
following the rules of the Ruby language.

But you know that. I'm just enjoying watching you trying to weasel out of 
acknowledging that you massive screwed up by editing the strings instead 
of the function calls.

I look forward to reading your increasingly desperate claims that it was 
not only intentional but the correct thing to do.




-- 
Steve

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

Re: please test the new PyPI (now in beta)

[Steven D'Aprano]

On Mon, 26 Mar 2018 18:16:26 -0400, Sumana Harihareswara wrote:

> The new Python Package Index at https://pypi.org is now in beta.
> 
> This means the site is robust, but we anticipate needing more user
> testing and changes before it is "production-ready" and can fully
> replace https://pypi.python.org . We hope to complete the transition
> before the end of April 2018.

Ah, excellent, we can finally get rid of the unending nightmare that was 
the nice, clean, readable PyPI design and replace it with something full 
of unnecessary swaths of bold colours and low-contrast light-blue text on 
blue background. Yay!

By the way, on the search page:

https://pypi.org/search/


it says "Enter a search query above, or select a filter from the list of 
classifiers on the left" but there is no such filter or list of 
classifiers.




-- 
Steve

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

Re: Entering a very large number

[Steven D'Aprano]

On Mon, 26 Mar 2018 23:49:07 -0400, Richard Damon wrote:

> The bigger issue is that these sort of micro-measurements aren't
> actually that good at measuring real quantitative performance costs.
> They can often give qualitative indications, but the way modern
> computers work, processing environment is extremely important in
> performance, so these sorts of isolated measure can often be misleading.
> The problem is that if you measure operation a, and then measure
> operation b, if you think that doing a then b in the loop that you will
> get a time of a+b, you will quite often be significantly wrong, as cache
> performance can drastically affect things. Thus you really need to do
> performance testing as part of a practical sized exercise, not a micro
> one, in order to get a real measurement.


I think that is so well said, and so important, that I'm replying to the 
post just to quote it even though I have nothing substantial to add to it.




-- 
Steve

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

Re: please test the new PyPI (now in beta)

[Paul Moore]

On 27 March 2018 at 09:35, Steven D'Aprano
 wrote:
> On Mon, 26 Mar 2018 18:16:26 -0400, Sumana Harihareswara wrote:
>
>> The new Python Package Index at https://pypi.org is now in beta.
>>
>> This means the site is robust, but we anticipate needing more user
>> testing and changes before it is "production-ready" and can fully
>> replace https://pypi.python.org . We hope to complete the transition
>> before the end of April 2018.
>
> Ah, excellent, we can finally get rid of the unending nightmare that was
> the nice, clean, readable PyPI design and replace it with something full
> of unnecessary swaths of bold colours and low-contrast light-blue text on
> blue background. Yay!
>
> By the way, on the search page:
>
> https://pypi.org/search/
>
>
> it says "Enter a search query above, or select a filter from the list of
> classifiers on the left" but there is no such filter or list of
> classifiers.

Do you not get the section

"""

Filter Projects

By Programming Language
By License
By Framework
...
"""

on the left of the page? Or is it just that it's not clear that this
is what's meant by "the list of classifiers"? It did take me a moment
to realise that "classifiers" meant this - maybe a less technical
term[1] like "filters" would help here? You could raise an issue on
https://github.com/pypa/warehouse/issues if you think it's worth
changing. (Same is true of your comment about the site design,
although I suspect it's a bit late for that to be changed in the
immediate future - the site design has been basically unchanged since
very early in the redesign. Personally, I agree it's a bit "in your
face", but not bad enough that I felt it was worth flagging as an
issue).

Paul

[1] "Classifiers" is what the relevant package metadata is called, but
it's not exactly what the average user would refer to that data as.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Paul Moore]

On 27 March 2018 at 10:48, Paul Moore  wrote:
> Same is true of your comment about the site design,
> although I suspect it's a bit late for that to be changed in the
> immediate future - the site design has been basically unchanged since
> very early in the redesign. Personally, I agree it's a bit "in your
> face", but not bad enough that I felt it was worth flagging as an
> issue.

Digging into this further, the design work on the Warehouse site has
been ongoing since late 2015, and there was an extensive user testing
phase, so honestly, I think it's too late to be arguing that the site
design is a problem now. One of the design goals was to integrate
better with the python.org website, so if you don't like the blue
theme, you should probably take it up with them first :-)

Paul

PS I just realised, what I was seeing as "in your face" was the red
"this is a test instance" banner - and that's in your face by design!
You'd have thought I would have realised this earlier, but what can I
say? Once I dismissed that banner, the page looks fine to me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[Steven D'Aprano]

On Tue, 27 Mar 2018 10:48:15 +0100, Paul Moore wrote:

>> By the way, on the search page:
>>
>> https://pypi.org/search/
>>
>>
>> it says "Enter a search query above, or select a filter from the list
>> of classifiers on the left" but there is no such filter or list of
>> classifiers.
> 
> Do you not get the section
> 
> """
> 
> Filter Projects
> 
> By Programming Language
> By License
> By Framework
> ...
> """
> 
> on the left of the page? 

There's nothing on the left of the page. It has:

(pypi logo) (search projects text box)

("Enter a search query..." with examples)

(Add filter button)


then the blue footer with "Get Help", "About PyPI", etc.



-- 
Steve

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

Re: please test the new PyPI (now in beta)

[Tim Golden]

On 27/03/2018 11:06, Steven D'Aprano wrote:

On Tue, 27 Mar 2018 10:48:15 +0100, Paul Moore wrote:


By the way, on the search page:

https://pypi.org/search/


it says "Enter a search query above, or select a filter from the list
of classifiers on the left" but there is no such filter or list of
classifiers.


Do you not get the section

"""

Filter Projects

By Programming Language
By License
By Framework
...
"""

on the left of the page?


There's nothing on the left of the page. It has:

(pypi logo) (search projects text box)

("Enter a search query..." with examples)

(Add filter button)


then the blue footer with "Get Help", "About PyPI", etc.


I imagine the Classifiers are being injected by JS. I know from previous 
comments of Steven's that he's not a fan of this particular approach to 
web page construction.


But whether I'm right or not, commenting snarkily about the design of 
pypi.org on *this* list doesn't seem particularly useful. Feel free to 
take it up on any of the forums where the work is actually being done by 
the people who are actually doing it, and who have been doing so for 
quite a while now.


Either they'll take note of your concerns and act, or they'll decline to 
agree with your point of view. In either case, talking about it here 
seems fruitless.


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

Re: please test the new PyPI (now in beta)

[Wolfgang Maier]

For me, that's a window width issue. The sidebar with the filters only 
shows when the window is wide enough. Unfortunately, the text mentioning 
it doesn't change, so this should be fixed.



On 03/27/2018 12:06 PM, Steven D'Aprano wrote:

On Tue, 27 Mar 2018 10:48:15 +0100, Paul Moore wrote:


By the way, on the search page:

https://pypi.org/search/


it says "Enter a search query above, or select a filter from the list
of classifiers on the left" but there is no such filter or list of
classifiers.


Do you not get the section

"""

Filter Projects

By Programming Language
By License
By Framework
...
"""

on the left of the page?


There's nothing on the left of the page. It has:

(pypi logo) (search projects text box)

("Enter a search query..." with examples)

(Add filter button)


then the blue footer with "Get Help", "About PyPI", etc.





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

Re: To super or not to super (Re: Accessing parent objects)

[Antoon Pardon]

On 27-03-18 08:21, Gregory Ewing wrote:
> The idea that super() is *always* the right way to call
> inherited methods in a multiple inheritance environment
> seems to have been raised by some people to the level
> of religous dogma.
>
> I don't buy it. In order for it to work, the following
> two conditions must hold:
>
> 1) All the methods involved have "additive" behaviour,
> i.e. the correct thing to do is always to call *all*
> versions of the method with the same arguments.

This doesn't follow. The idea in the first paragraph
expresses that if you need to call an inherrited method
you must do it by using super. It doesn't express that
you always need to call inherrited methods. 

>
> 2) It doesn't matter what order they're called in.
>
> The trouble is, those conditions don't always hold.
> Often when overriding a method, you want to do something
> *instead* of what the base method does.

I don't understand your point here. If your method
doesn't call the inherited method, it doesn't matter that
it doesn't do so by not using super or by not using
the parent class explicitly.

> Or you want to
> do something additional, but the base method must be
> called *first*.

You mean actually first or just before excuting the rest of
the code in this method?
>
> In those situations, there's no way to guarantee that
> the right thing will happen by using super().
>
> On the other hand, explicit inherited method calls give
> you precise control over what happens and what order it
> happens in, with no chance of it being messed up by
> someone ineriting from you.

I doubt that unless you don't mind multiple calls
to the same inherrited methods now and then.

>
> Yes, diamonds can be a problem. You can mitigate that
> by (1) avoiding diamonds; 

In that case we just don't need inherritance. We
can solve it all by using composition instead of
inheritance.

> (2) if you can't avoid
> diamonds, avoid putting methods in the apex class that
> get called as inherited methods;

That means we can't use any standard library class as the
apex class.


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

Re: please test the new PyPI (now in beta)

[Steven D'Aprano]

On Tue, 27 Mar 2018 11:03:00 +0100, Paul Moore wrote:

> Digging into this further, the design work on the Warehouse site has
> been ongoing since late 2015, and there was an extensive user testing
> phase,

Oh? What did they test the user for?

Whatever it was, it was a pity they didn't test them for good taste 
before letting them approve the current design.

(And yes, I hate the front page of the main python.org site too. At least 
the documentation pages are nice.)

There's no point in raising a tracker issue. The web developers are 
invested in the design, they've spent months working on it, its their 
baby. Then there's the whole "sunk cost" thing, "we just spent a small 
fortune redesigning the site, reverting means we wasted it".

And the fact that *by definition* the process is biased towards change 
whether it is needed or not. If the decision-makers didn't think change 
was wanted, they wouldn't have started the process in the first place. 
And no matter how cheap the price, "leave well enough alone" was never 
going to be the winning proposal.

So anyone (like me) who likes the old design is going to be pushing crap 
uphill with a straw, *even* if our opinion had been asked early in the 
process.


> PS I just realised, what I was seeing as "in your face" was the red
> "this is a test instance" banner - and that's in your face by design!
> You'd have thought I would have realised this earlier, but what can I
> say? Once I dismissed that banner, the page looks fine to me.

Too much bold blue space.

Too much low-contrast pale blue text and icons on blue background.

Too much unneeded frippery, like on the home page, which each of the 
featured projects has a box around it (why?) and an identical icon of a 
pale-grey cube.

(Presumably the cube is meant to symbolise the interconnectedness of all 
life in the cosmos, and it is faded pale grey in order to signify the 
ephemeral nature of software.)

Too many (*one* is too many) instances of the stupid design fashion for 
putting *active UI elements* in pale grey, the better to make them look 
inactive. E.g. the text in search boxes.

Speaking of which... oh the irony... in the 1980s, I had Mac with a 9-
inch (23 cm) screen, and that was enough real estate to put the 
instructions outside of the search field:

Search for: [  ]  ( Find )

and still have a roomy search field AND an actual Find button. 
(Presumably for people who couldn't push the Enter key).

Today, I was using a monitor the size of one of the smaller European 
countries. Three quarters of the active window was either covered in ads 
or blank, and yet most webpages have a microscopically small search field 
with a grammatically ambiguous command, apparently grey-out and inactive, 
in the search box itself:

[ Search ]

Yay for progress!

As an extra bonus, even when searching is not reliant on Javascript, 
mangling the text in the search box often is, so unless I'm extra 
careful, whenever I want to search for (say) "aardvarks", I invariably 
end up searching for "searaardvarksch".

At least the new PyPI search box is better than that. They get a point.




-- 
Steve

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

Re: please test the new PyPI (now in beta)

[Chris Angelico]

On Tue, Mar 27, 2018 at 9:49 PM, Steven D'Aprano
 wrote:
> As an extra bonus, even when searching is not reliant on Javascript,
> mangling the text in the search box often is, so unless I'm extra
> careful, whenever I want to search for (say) "aardvarks", I invariably
> end up searching for "searaardvarksch".
>
> At least the new PyPI search box is better than that. They get a point.
>

"Mangling the text" should never be necessary. The HTML5  tag
has a 'placeholder' attribute for a reason.

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

Re: please test the new PyPI (now in beta)

[Steven D'Aprano]

On Tue, 27 Mar 2018 22:25:44 +1100, Chris Angelico wrote:

> On Tue, Mar 27, 2018 at 9:49 PM, Steven D'Aprano
>  wrote:
>> As an extra bonus, even when searching is not reliant on Javascript,
>> mangling the text in the search box often is, so unless I'm extra
>> careful, whenever I want to search for (say) "aardvarks", I invariably
>> end up searching for "searaardvarksch".
>>
>> At least the new PyPI search box is better than that. They get a point.
>>
>>
> "Mangling the text" should never be necessary. The HTML5  tag has
> a 'placeholder' attribute for a reason.


You're assuming the page is using HTML5. I've used a lot of these that 
did it in Javascript, and didn't degrade gracefully if Javascript was 
disabled.



-- 
Steve

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote:
> Chris Angelico wrote:
> > Question: How do you get a reference to a Ruby function? Or are they
> > not first-class objects?
>
> They're not first-class. So, you can't.

If Chris means: "how do you get a reference to a Ruby
function object", then yes, it _is_ possible! Consider the
following:

## Ruby 1.9 ##
rb> def print_name(name); puts "Your name is #{name.inspect}"; end
rb> print_name("Chris")
"Chris"

In this case, since the function `print-name` was defined
outside of an class definition, Ruby will add the function
as a method of `Object` (Ruby is more purist about OOP than
Python). So, to get a reference to the function object
(which is now a method of `Object`!), all we need to do is
call a method named "method" ("gigity") and pass it the name
of the method as a string:

rb> Object.method("print_name")
#
rb> Object.method("print_name").call("Meathead")
Your name is "Meathead"

PS: Greg, please inform Chris that Google is his friend. ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

[no subject]

[kevon harris]

Unable to pull up IDLE after downloading Python 3.6.4

Sent from Mail for Windows 10

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

condition.acquire vs lock.acquire

[jayshankar nair via Python-list]

Hi,
Is condition.acquire(threading.Condition()) similar to 
lock.acquire(threading.Lock). Does both of get access to the lock. Can i use 
condition.wait,notify with lock.acquire or i have to use condition.wait, notify 
with condition.acquire.
cond.acquire()  // can i replace with lock.acquire

   while count[ipID]> 1:
  cond.wait()
   if ipID == 0:
  time.sleep(10)


   count[ipID] = count[ipID] + 1


   cond.release() // can i replace with lock.release

Thanks,Jayshankar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 3:24:48 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:

> Printing a string and calling a function is obfuscated code? Deary me.

When the programmer can't be bothered to invent names more
descriptive than `a` and `b`, why yes, yes it is.

> And besides, while I'm more than happy to take (undeserved)
> credit for all the things Ruby gets right, I draw the line
> at being blamed for Ruby misfeatures like parens-less
> function calls, and the inconsistent behaviour they lead
> to.

What version are you testing this "misfeature" on?
Personally, I'm using 1.9, so i have no idea if the
"misfeature" has been repaired or not. The latest stab;e
release is 2.5.0. There have been a ton of changes since
1.9!

> > > Because of this "fix", the printed strings no longer
> > > match the code being executed, but the strange,
> > > inconsistent behaviour still occurs.
> > 
> > The supposed "inconsistent behavior" here has absolutely
> > nothing to do with Ruby, no, it's all on _you_. _YOU_ are
> > the one who created a non-sensical function
> 
> I love watching you trying to squirm your way out of
> admitting that you screwed up. Returning the input plus two
> is nonsensical is it?

When the function is named `a`, why yes, yes it is!

> As I said, don't blame me for Ruby's poor design.  By the
> way, there are precisely the same number of clues that:  a
> is a function as there are for:  super  in Ruby. But you
> know that, because you were vehemently defending the use of
> super with no parens and why it isn't inconsistent for it
> to do something completely different from super() with
> parens.

Okay, Mr. "Language Designer"... how do _you_ propose to
implement Ruby's super in a way that provides these same
three distinct forms:

(1) implicit passing of args: `super`
(2) explicit passing if args: `super(arg1, arg2, ..., argN)`
(3) no arg passing: `super()`

Let's hear it! And don't forget to make your design
consistent with func/meth calls, even though super is not a
func at all -- but i digress!

> So now you're claiming I hacked the Ruby interpreter to
> support non- standard code? I can smell the desperation in
> you from the other side of the planet.  Rick, nothing I did
> was illegal Ruby code. Everything I did was 100% following
> the rules of the Ruby language.

The rules you violated were _style_ and _sanity_ rules.
Every wise programmer knows that readability dictates one
space on each side of an operator:

YES: a + b
NO: a+b
NO: a+ b
NO: a +b
HELL NO: a+   b

Ruby is punishing you for your petulant behavior. And if i
were you, i'd be kissing Matz's backside for only giving you
a "surprising result". Because if *I* were the creator of
Ruby, i'd have Ruby format your hard-drive for doing _less_.

But i look forward to your proposed solutions to Ruby's so-
called "broken expressions and inconsistent super". Oh guru,
please enlighten us with your language design wisdom.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (no subject)

[Rick Johnson]

On Tuesday, March 27, 2018 at 7:19:53 AM UTC-5, kevon harris wrote:
> Unable to pull up IDLE after downloading Python 3.6.4
> 
> Sent from Mail for Windows 10

What OS?

On Windows running Python2.X, IDLE is located @ '/Python2X/Lib/idlelib/idle.pyw'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String Formatting with new .format()

[Ganesh Pal]

>
>
> Or maybe they're not giving the same result. I'm a little confused here.
>
>
 Thanks  Chris, for the reply they appear to give the same result .
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 11:00 PM, Rick Johnson
 wrote:
> On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote:
>> Chris Angelico wrote:
>> > Question: How do you get a reference to a Ruby function? Or are they
>> > not first-class objects?
>>
>> They're not first-class. So, you can't.
>
> If Chris means: "how do you get a reference to a Ruby
> function object", then yes, it _is_ possible! Consider the
> following:
>
> ## Ruby 1.9 ##
> rb> def print_name(name); puts "Your name is #{name.inspect}"; end
> rb> print_name("Chris")
> "Chris"
>
> In this case, since the function `print-name` was defined
> outside of an class definition, Ruby will add the function
> as a method of `Object` (Ruby is more purist about OOP than
> Python). So, to get a reference to the function object
> (which is now a method of `Object`!), all we need to do is
> call a method named "method" ("gigity") and pass it the name
> of the method as a string:
>
> rb> Object.method("print_name")
> #
> rb> Object.method("print_name").call("Meathead")
> Your name is "Meathead"
>
> PS: Greg, please inform Chris that Google is his friend. ;-)

Cool, so Greg was right: you can't get a reference to a method or
function. You need magic to simulate it.

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

Re: (unknown)

[Terry Reedy]

On 3/27/2018 3:27 AM, kevon harris wrote:

Unable to pull up IDLE after downloading Python 3.6.4


What did you download?
How did you install after downloading?
Can you run 3.6 after installing?
How did you try to run IDLE?
Can you use Command Prompt?

--
Terry Jan Reedy

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

Re: please test the new PyPI (now in beta)

[Chris Angelico]

On Tue, Mar 27, 2018 at 10:50 PM, Steven D'Aprano
 wrote:
> On Tue, 27 Mar 2018 22:25:44 +1100, Chris Angelico wrote:
>
>> On Tue, Mar 27, 2018 at 9:49 PM, Steven D'Aprano
>>  wrote:
>>> As an extra bonus, even when searching is not reliant on Javascript,
>>> mangling the text in the search box often is, so unless I'm extra
>>> careful, whenever I want to search for (say) "aardvarks", I invariably
>>> end up searching for "searaardvarksch".
>>>
>>> At least the new PyPI search box is better than that. They get a point.
>>>
>>>
>> "Mangling the text" should never be necessary. The HTML5  tag has
>> a 'placeholder' attribute for a reason.
>
>
> You're assuming the page is using HTML5. I've used a lot of these that
> did it in Javascript, and didn't degrade gracefully if Javascript was
> disabled.
>

Any time you see something that requires JavaScript for this, you know
you've found a web site that dates back to... uhh, actually I don't
know. I only have versioning info on MDN back as far as HTML 4.01 ergo
1999, and the placeholder attribute is there. Of course, that doesn't
mean everyone *used* it, but it was certainly available.

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

Re: please test the new PyPI (now in beta)

[Bill Deegan]

The back ground blue on the pypi page is the highlight blue on the
python.org page, they should change the color to match to background
python.org color.

-Bill




On Tue, Mar 27, 2018 at 7:50 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Tue, 27 Mar 2018 22:25:44 +1100, Chris Angelico wrote:
>
> > On Tue, Mar 27, 2018 at 9:49 PM, Steven D'Aprano
> >  wrote:
> >> As an extra bonus, even when searching is not reliant on Javascript,
> >> mangling the text in the search box often is, so unless I'm extra
> >> careful, whenever I want to search for (say) "aardvarks", I invariably
> >> end up searching for "searaardvarksch".
> >>
> >> At least the new PyPI search box is better than that. They get a point.
> >>
> >>
> > "Mangling the text" should never be necessary. The HTML5  tag has
> > a 'placeholder' attribute for a reason.
>
>
> You're assuming the page is using HTML5. I've used a lot of these that
> did it in Javascript, and didn't degrade gracefully if Javascript was
> disabled.
>
>
>
> --
> Steve
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Pep8 for long pattern

[Ganesh Pal]

Hello Python friends,

How do I split the below regex , so that it fits within the  character
limit of 79 words


pattern =  [
r'(?P([0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',

r'(?P(owner:\s+[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',
'.']

I am using Python 2.7 + Linux

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pep8 for long pattern

[Paul Moore]

Use re.X - see https://docs.python.org/3.6/library/re.html#re.X for details.

On 27 March 2018 at 15:17, Ganesh Pal  wrote:
> Hello Python friends,
>
> How do I split the below regex , so that it fits within the  character
> limit of 79 words
>
>
> pattern =  [
> r'(?P([0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',
>
> r'(?P(owner:\s+[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',
> '.']
>
> I am using Python 2.7 + Linux
>
> Regards,
> Ganesh
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pep8 for long pattern

[Serhiy Storchaka]

27.03.18 17:17, Ganesh Pal пише:

How do I split the below regex , so that it fits within the  character
limit of 79 words


pattern =  [
r'(?P([0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',

r'(?P(owner:\s+[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',
 '.']


For example:

pattern =  [
r'(?P('
r'[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:'
r':HEAD))',
r'(?P(owner:\s+'
r'[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:'
r':HEAD))',
'.']

Or just use fixed number repetition:

pattern =  [
r'(?P((?:[0-9a-fA-F]+:){5}:HEAD))',
r'(?P(owner:\s+(?:[0-9a-fA-F]+:){5}:HEAD))',
'.']

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

Re: To super or not to super (Re: Accessing parent objects)

[Ian Kelly]

On Tue, Mar 27, 2018 at 12:21 AM, Gregory Ewing
 wrote:
> The idea that super() is *always* the right way to call
> inherited methods in a multiple inheritance environment
> seems to have been raised by some people to the level
> of religous dogma.
>
> I don't buy it. In order for it to work, the following
> two conditions must hold:
>
> 1) All the methods involved have "additive" behaviour,
> i.e. the correct thing to do is always to call *all*
> versions of the method with the same arguments.

I would argue that this is just good OO design. Inheritance with
subtractive behavior violates the Liskov substitution principle.

> 2) It doesn't matter what order they're called in.

This is simply not true. The Python MRO is very specific about the
order they will be called in, and it obeys some important rules:

1) Monotonicity - If the MRO of class C has class B1 before B2, then
the MRO of any subclass of C must also have B1 before B2.

2) Local precedence ordering - If C inherits directly from B1 and B2
in that order, then its MRO must have B1 before B2.

The algorithm used is also precisely specified, so in cases where
these rules would permit more than one possible ordering, the actual
MRO can be determined by running the algorithm.

> The trouble is, those conditions don't always hold.
> Often when overriding a method, you want to do something
> *instead* of what the base method does.

As noted above, unless the method or class is abstract then this
violates LSP. If the method is abstract and does nothing, then just
call it. If the method is abstract and raises an exception, then
that's a little more tricky. Ideally, don't write abstract methods
that raise NotImplementedError unless they're not intended to be used
with multiple inheritance.

If you really need to though, you can solve this by creating a guard
class that implements the method and does nothing, ending the super
call chain. Then just make sure that at least one subclass in the
multiple inheritance diagram inherits from the guard class rather than
the original class.

> Or you want to
> do something additional, but the base method must be
> called *first*.

I don't see why this is a problem; you can easily do other things
before calling super().

> On the other hand, explicit inherited method calls give
> you precise control over what happens and what order it
> happens in, with no chance of it being messed up by
> someone ineriting from you.

Unless they create a diamond in the process. Also, note even without
using super, the MRO is still used when deciding which version of an
inherited method to call if the subclass does not directly define it.
So you may end up accidentally creating a class structure that uses
one order for some methods and a different order for others. Using
super ensures that your calls follow the MRO.

> Yes, diamonds can be a problem. You can mitigate that
> by (1) avoiding diamonds;

Which can only be accomplished by not using multiple inheritance at all.

> (2) if you can't avoid
> diamonds, avoid putting methods in the apex class that
> get called as inherited methods;

Then what purpose does the apex class serve?

> (3) if you can't avoid
> either of those, as far as I can tell the situation is
> intractable and you need to rethink your design.

Or you can use super.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To super or not to super (Re: Accessing parent objects)

[Ian Kelly]

On Tue, Mar 27, 2018 at 8:47 AM, Ian Kelly  wrote:
> On Tue, Mar 27, 2018 at 12:21 AM, Gregory Ewing
>  wrote:
>> The trouble is, those conditions don't always hold.
>> Often when overriding a method, you want to do something
>> *instead* of what the base method does.
>
> As noted above, unless the method or class is abstract then this
> violates LSP. If the method is abstract and does nothing, then just
> call it. If the method is abstract and raises an exception, then
> that's a little more tricky. Ideally, don't write abstract methods
> that raise NotImplementedError unless they're not intended to be used
> with multiple inheritance.
>
> If you really need to though, you can solve this by creating a guard
> class that implements the method and does nothing, ending the super
> call chain. Then just make sure that at least one subclass in the
> multiple inheritance diagram inherits from the guard class rather than
> the original class.

Er, this should say "make sure that every subclass ... inherits from
the guard class ..." since we want to make sure that nothing else ends
up between the guard class and the original class.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (unknown)

[Grant Edwards]

On 2018-03-27, kevon harris  wrote:

> Unable to pull up IDLE after downloading Python 3.6.4

Ah.  What happens when you push down instead of pull up?

> Sent from Mail for Windows 10

Sent from mutt for Gentoo Linux 

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

Re: To super or not to super (Re: Accessing parent objects)

[Steven D'Aprano]

On Tue, 27 Mar 2018 19:21:38 +1300, Gregory Ewing wrote:

> The idea that super() is *always* the right way to call inherited
> methods in a multiple inheritance environment seems to have been raised
> by some people to the level of religous dogma.

"Always"?

Well, you could always avoid super() by reinventing the wheel and 
creating your own (slow, buggy) method of dealing with inheritance in a 
MI environment.

*wink*

Since I've been the one hammering the idea that super is necessary to do 
MI correctly in Python, you're probably referring to me in your "dogma" 
comment.

I should say that in my defence I'm not talking about the case where you 
are expert enough to know when and how to break the rules, and have 
absolute and total control of what classes subclass yours.

Please forgive: I naturally always think of writing classes for public 
consumption, and tend to forget that sometimes people write classes for 
themselves or a small team ruled by a leader with an iron fist :-)

So I guess that if you are in a position to control who and what 
subclasses your class, and are prepared to blame the subclass for any 
inheritance bugs ("we didn't say doing that was supported"), then you can 
do whatever you like and super is not necessary.

Comments on your additional points below:


> I don't buy it. In order for it to work, the following two conditions
> must hold:
> 
> 1) All the methods involved have "additive" behaviour, i.e. the correct
> thing to do is always to call *all* versions of the method with the same
> arguments.
> 
> 2) It doesn't matter what order they're called in.

I think that the first condition may be a requirement of all cooperative 
MI, and I think the second one is wrong.

In the most general case, of course order matters: if class A reads to a 
file, and class B deletes it, then you can't call B first then A. That's 
the nature of inheritance, whether multiple or single. There may be 
*some* tasks that can be performed in whatever arbitrary method you think 
of, but they're surely a small minority.


> The trouble is, those conditions don't always hold. Often when
> overriding a method, you want to do something *instead* of what the base
> method does. 

That is the definition of "overriding": when you don't call the 
superclass at all, but entirely override its behaviour.


> Or you want to do something additional, but the base method
> must be called *first*.

That's not a problem. There's no restriction on when you call super:

def method(self, arg):
super().method(arg)
# do my stuff second


def method(self, arg):
# do my stuff first
super().method(arg)


are both perfectly legitimate.


But suppose I subclass two classes, Spam and Eggs. Why would I subclass 
both of them if I didn't want to inherit *both* their behaviour?

I can certainly envisage situations where I want to override both 
classes, e.g the __repr__ of the subclass probably doesn't want to call 
either Spam.__repr__ or Eggs.__repr__. But of course that's easy: just 
don't call super in the subclass' __repr__.

I don't think it is very controversial that there are methods which we 
don't want to inherit from the superclasses, such as __repr__, so I shall 
ignore them. They're not the "interesting" methods that include the 
"business logic" of your class.

So let's just ignore anything that you want to *override* (i.e. don't 
call the superclass methods at all) and only consider those you want to 
*overload*.

If you push me into a corner, I suppose I will have to say that in 
principle, I might want to inherit Spam.foo but not Eggs.foo. But 
honestly, that feels dirty: it breaks the Liskov Substitution principle.

https://en.wikipedia.org/wiki/Liskov_substitution_principle


So given three classes and an instance:

class Spam: ...
class Eggs: ...
class Breakfast(Spam, Eggs): ...

obj = Breakfast()

anyone using obj should be entitled to expect that obj.foo meets the 
contracts provided by *both* Spam and Eggs. After all, obj is an Eggs 
instance: if obj.foo doesn't call Eggs.foo, that's going to break 
anything that expects that isinstance(obj, Eggs) implies that obj obeys 
Eggs' contracts.

So you better have a damn good reason for inconsistently overloading 
methods in this way, and your callers better understand exactly why 
you're threatening to break their code if they rely on Eggs contracts.

(I'm not talking about Eiffel-style Design-By-Contract contracts here, 
but the more informal contracts offered by class interfaces.)


So I think that the moment you start talking about picking and choosing 
which superclass methods you inherit from, you're in "Hey hold my beer 
while I try something, I saw it in a cartoon but I'm pretty sure it will 
work" territory.

Or possibly even in the "tequila plus handguns" zone.

But hey, consenting adults and all that, so if you really know what 
you're doing, go for it. Who needs all ten toes?

*wink*


[...]
> In those situations,

Re: Pep8 for long pattern

[Michael Torrie]

On 03/27/2018 08:17 AM, Ganesh Pal wrote:
> Hello Python friends,
> 
> How do I split the below regex , so that it fits within the  character
> limit of 79 words
> 
> 
> pattern =  [
> r'(?P([0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',
> 
> r'(?P(owner:\s+[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+:[0-9a-fA-F]+::HEAD))',
> '.']
> 
> I am using Python 2.7 + Linux

I like Serhiy's idea of using fixed number repetition to shorten the
expressions and make them more readable.  Now it could be that in
general a long regular expression is a bad idea (maybe a simple split()
is the way to go instead).  But when it's exactly what you need, why do
you need to shoehorn the expression into 79 characters?  Seems pointless
in a case like this. PEP8 is a guideline, not an absolute rule.  It's
okay to bend it a bit in cases like this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String Formatting with new .format()

[Michael Torrie]

On 03/26/2018 09:37 AM, Ganesh Pal wrote:
> Hi Team,
> 
> Just a quick suggestion, on string formatting with .format() which of the
> below is better , given both give the same result .

No they don't. Look more closely at the output.

 attempts = 1
 msg2 = "Hello"
 print "Retry attempt:{0} for error:{1}".format(attempts,msg2)
> Retry attempt:1 for error:Hello
^
> 
> OR
> 
 attempts = 1
 msg2 = "Hello"
 print "Retry attempt:{0} for error:{0}".format(attempts,msg2)
> Retry attempt:1 for error:1
^^
The second example places the same argument 0 in two places in your
string.  This is not what you want, I don't think.

> PS : This is the silly question but I wanted to know if it really makes any
> difference

What makes any difference?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re:

[Dan Stromberg]

Please at least skim http://www.catb.org/esr/faqs/smart-questions.html

On Tue, Mar 27, 2018 at 12:27 AM, kevon harris  wrote:
> Unable to pull up IDLE after downloading Python 3.6.4
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
[...]
> Cool, so Greg was right: you can't get a reference to a
> method or function. You need magic to simulate it.

Since when did utilizing a method to request a specific
value become some sort of magic?

Do you consider this to be magic?

os.lstdir('C:\\')

What about this?

''.join(map(chr, [109, 101, 97, 116, 32, 104, 101, 97, 100]))

Even though i prefer Python's way better, the implicit
return of Python function references is far more "magical"
than making an explicit call to a method will ever be.

Python Zen Says: "Explicit is better than implicit"

Hmm, i suppose Python's constancy is overrated[1]. 

[1] Which is merely a nice way of saying: "It's a lie!".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Wed, Mar 28, 2018 at 3:28 AM, Rick Johnson
 wrote:
> On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
> [...]
>> Cool, so Greg was right: you can't get a reference to a
>> method or function. You need magic to simulate it.
>
> Since when did utilizing a method to request a specific
> value become some sort of magic?
>
> Do you consider this to be magic?
>
> os.lstdir('C:\\')

That requests the "lstdir" method of the "os" object, most likely a
module. And then it calls that. Nope, not magic. When you use the name
"os", you get the object referenced by that name. When you put a dot
after an object, you get an attribute of that object. When you put
parentheses after an object, you call it. Why would it be magic?

> What about this?
>
> ''.join(map(chr, [109, 101, 97, 116, 32, 104, 101, 97, 100]))
>

You have a string literal, and you get a method off that object.
Etcetera. Why are you suggesting that this is magic?

> Even though i prefer Python's way better, the implicit
> return of Python function references is far more "magical"
> than making an explicit call to a method will ever be.
>
> Python Zen Says: "Explicit is better than implicit"

Yep, one of the most misunderstood lines in the zen. "Explicit" means
"stuff I like", and "implicit" means "stuff I don't like". Or at
least, that's how I see this used.

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 11:35:31 AM UTC-5, Chris Angelico wrote:
> Why are you suggesting that this is magic?

_You_ are the one who leveled the accusation that Ruby's
methodology for fetching a function reference (a la):

Object.method(meth-name-here)

is "magic". I'm merely requesting that you defend _your_
accusation. That's all.

> Yep, one of the most misunderstood lines in the zen.
> "Explicit" means "stuff I like", and "implicit" means
> "stuff I don't like". Or at least, that's how I see this
> used.

Perhaps (and unfortunately) some folks in this community
interpret the zen as you claim, however, the words explicit
and implicit have clear definitions, and thus, to ascribe
them to personal "likes" is a miscarriage of both
comprehension and objectivity.
-- 
https://mail.python.org/mailman/listinfo/python-list

testfixtures 6.0.0 released!

[Chris Withers]

Hi All,

I'm pleased to announce the release of testfixtures 6.0.0 featuring the 
following:


 * |compare()|
   
will
   now handle objects that do not natively support equality or
   inequality and will treat these objects as equal if they are of the
   same type and have the same attributes as found using|vars()|
   or|__slots__|.
   This is a change in behaviour which, while it could conceivably
   cause tests that are currently failing to pass, should not cause any
   currently passing tests to start failing.
 * Add support for writing to the|stdin|of|MockPopen|
   
instances.
 * The default behaviour of|MockPopen|
   
can
   now be controlled by providing a callable.
 * |LogCapture.actual()|
   
is
   now part of the documented public interface.
 * Add|LogCapture.check_present()|
   
to
   help with assertions about a sub-set of messages logged along with
   those that are logged in a non-deterministic order.
 * |Comparison|
   
now
   supports objects with|__slots__|.
 * Added|ShouldAssert|
   
as
   a simpler tool for testing test helpers.
 * Changed the internals of the various decorators testfixtures
   provides such that they can be used in conjunction
   with|unittest.mock.patch()|
   on
   the same test method or function.
 * Changed the internals of|ShouldRaise|
   
and|Comparison|
   
to
   make use of|compare()|
   
and
   so provide nested comparisons with better feedback. This finally
   allows|ShouldRaise|
   
to
   deal with Django’s|ValidationError|
   
.
 * Added handling of self-referential structures to|compare()|
   
by
   treating all but the first occurence as equal. Another change needed
   to support Django’s insane|ValidationError|
   
.

Thanks to Hamish Downer and Tim Davies for their work on|MockPopen| 
.


Thanks to Wim Glenn and Daniel Fortunov for their help reviewing some of 
the more major changes.


The package is on PyPI and a full list of all the links to docs, issue 
trackers and the like can be found here:


https://github.com/Simplistix/testfixtures

Any questions, please do ask on the Testing in Python list or on the 
Simplistix open source mailing list...


cheers,

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

Re: Pep8 for long pattern

[Dan Stromberg]

On Tue, Mar 27, 2018 at 8:18 AM, Michael Torrie  wrote:
> But when it's exactly what you need, why do
> you need to shoehorn the expression into 79 characters?  Seems pointless
> in a case like this. PEP8 is a guideline, not an absolute rule.  It's
> okay to bend it a bit in cases like this.

I think PEP8 specifying a max of 80 columns is very silly.

Even an old VT220 terminal could do 132 columns.

My understanding is that PEP8 requires 80 columns because a tiny,
tiny, tiny minority of Python developers wanted to be able to put 3
editors next to each other horizontally, without wrapping.

I like to check my code with pycodestyle, but I always override that
dang 80 column requirement.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Chris Angelico wrote:

Ahh, that explains it. Great. So how do you build higher-order
functions? Or don't you?


You don't, exactly. You have to pass around objects
with a method to invoke when you want to "call" them.

Ruby has a code-block syntax that helps with this
somewhat, but I don't think you can invoke one with
the same syntax that you use for calling a method.

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Rick Johnson wrote:

rb> Object.method("print_name").call("Meathead")


Yes, but the point is that you have to have to use a different
syntax to call it. This is like having to say

   f.__call__(arg)

in Python instead of just

   f(arg)

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

Re: please test the new PyPI (now in beta)

[Gregory Ewing]

Paul Moore wrote:

maybe a less technical
term[1] like "filters" would help here?


Categories?

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

Re: please test the new PyPI (now in beta)

[Ian Kelly]

On Mon, Mar 26, 2018 at 4:16 PM, Sumana Harihareswara  
wrote:
> The new Python Package Index at https://pypi.org is now in beta.
>
> This means the site is robust, but we anticipate needing more user
> testing and changes before it is "production-ready" and can fully
> replace https://pypi.python.org . We hope to complete the transition
> before the end of April 2018.
>
> We're still working to ensure the new codebase and infrastructure are
> reliable. So please don't rely on it (yet) unless you can handle the
> occasional minor outage.
>
> But we want you to try the new PyPI, test it, and tell us if you have
> any problems. During the beta, we'll have IRC and Twitter livechats to
> hear from you:

For me, the category filters alone are a killer feature over the old
PyPI. I think it's also a plus to the Python community overall that
PyPI not look to newcomers like something that was designed in the 90s
and then abandoned.

I agree with Steven about the unnecessary boxes around every single
package, though. The presentation of the list of packages could be
*much* denser while keeping the same readability, which would also
make the page more usable by reducing the amount of scrolling needed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Welcome to the "Python-list" mailing list

[nadir musallam]

Dear All,

Kind reminder on the below please, if there is a separate mailing list for 
installation problems I’d appreciate if you’d let me know.

Warm regards,

Nadir

Sent from my iPhone

On Mar 26, 2018, at 8:40 PM, nadir musallam 
mailto:nadir_musal...@hotmail.com>> wrote:


Dear All,


I have tried installing Python3.6.4 on my computer as I am eager to begin a new 
career in data analytics. However I am running in to some problems when 
attempting to set up the software. I have downloaded Dev C++ software as per 
your recommendation earlier but still getting the same error when trying to 
launch the program. Your assistance would be very much appreciated. I hope this 
time I followed the proper instructions for the emailing list as it is not my 
intention to offend anyone.

Below is the updated log file for your reference:


[1D14:0FEC][2018-03-26T09:09:13]i001: Burn v3.10.3.3007, Windows v10.0 (Build 
16299: Service Pack 0), path: 
C:\Users\DELL\AppData\Local\Temp\{38A48442-951B-485A-BF38-8B6263D4F87D}\.cr\python-3.6.4-amd64-webinstall.exe
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'ActionLikeInstalling' to value 'Installing'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'ActionLikeInstallation' to value 'Setup'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'ShortVersion' to value '3.6'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'ShortVersionNoDot' to value '36'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 'WinVer' to 
value '3.6'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'WinVerNoDot' to value '36'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'InstallAllUsers' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'InstallLauncherAllUsers' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 'TargetDir' 
to value ''
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'DefaultAllUsersTargetDir' to value '[ProgramFiles64Folder]Python[WinVerNoDot]'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'TargetPlatform' to value 'x64'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'DefaultJustForMeTargetDir' to value 
'[LocalAppDataFolder]Programs\Python\Python[WinVerNoDot]'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'OptionalFeaturesRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstalledFeatures'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'TargetDirRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstallPath'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'DefaultCustomTargetDir' to value ''
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'InstallAllUsersState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'InstallLauncherAllUsersState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'TargetDirState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'CustomBrowseButtonState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_core' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_exe' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_dev' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_lib' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_test' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_doc' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_tools' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_tcltk' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_pip' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_launcher' to value '1'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing string variable 
'Include_launcherState' to value 'enabled'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_symbols' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'Include_debug' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'LauncherOnly' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'DetectedLauncher' to value '0'
[1D14:0FEC][2018-03-26T09:09:13]i000: Initializing numeric variable 
'DetectedOldLauncher' to value '0'
[1D14:0FEC][2018-0

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 4:47:05 PM UTC-5, Gregory Ewing wrote:
> Rick Johnson wrote:
> > rb> Object.method("print_name").call("Meathead")
>
> Yes, but the point is that you have to have to use a different
> syntax to call it. This is like having to say
>
> f.__call__(arg)
>
> in Python instead of just
>
> f(arg)

You _can_ call a Ruby func/method directly by name, and i've
already demonstrated that fact. For example, the following is
perfectly legit (although untested):

def f(arg)
nil
end
f("arg")

And here is the equivalent code in Python (notice the
similarities):

def f(arg):
pass
f("arg")

The only difference is when you want to make a call from a
_reference_, which, as you and i well know, is not the most
common way func/meths are called (these are rare).

Here is Ruby 1.9:

ref = Object.method("f")
ref.call("arg")

And the Python equivalent:

ref = f
ref("arg")

NOTE: Of course, the "Python equivalent" assumes `f` is in
the current module space, whereas in Ruby, Object is
available _everywhere_.

As you can see, there is nothing "magical" about the Ruby
code. Sure, one could claim it is more onerous (and i would
agree). But to claim it is "magic" (as Chris did) is absurd.

PS: I must stress again that i am using Ruby version 1.9 and
have been for many years. I must also stress there have been
many changes in the Ruby language since 1.9 and i have not
kept up with them. So, it may be possible to do `ref("arg")`
in the newer versions. The point is, before anyone accuses
Ruby of not doing X, Y or Z -- they really should go read
the docs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pep8 for long pattern

[Rick Johnson]

On Tuesday, March 27, 2018 at 4:02:37 PM UTC-5, Dan Stromberg wrote:
> On Tue, Mar 27, 2018 at 8:18 AM, Michael Torrie  wrote:
> > But when it's exactly what you need, why do you need to
> > shoehorn the expression into 79 characters?  Seems
> > pointless in a case like this. PEP8 is a guideline, not an
> > absolute rule.  It's okay to bend it a bit in cases like
> > this.
> 
> I think PEP8 specifying a max of 80 columns is very silly.
> Even an old VT220 terminal could do 132 columns.

And just think how many columns you could do with 1pt font!
And while i admit i enjoy coding with my nose pressed
against the monitor as much as the next "guyal"[1], just uh,
be sure to keep a good optometrist on retainer, eh pal?

> My understanding is that PEP8 requires 80 columns because a
> tiny, tiny, tiny minority of Python developers wanted to be
> able to put 3 editors next to each other horizontally,
> without wrapping.

Stacking horizontal windows three deep is all the rage, but
the reason has more to do with easy reading. Long lines are
difficult to read. And when your eyes do a linefeed at the
end of a 200 character long line, there's no guarantee
you'll end up starting on the next line. Sometimes you'll
find yourself three lines down, while others, back at the
start of the same line. And that's annoying.

> I like to check my code with pycodestyle, but I always
> override that dang 80 column requirement.

Certainly your decision. But please do try to maintain as
much of PEP8 as you can tolerate. Most of it (~75%) is
really good advice.

[1] "guy" and/or "gal" = "guyal"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
> On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
[...]
> > Cool, so Greg was right: you can't get a reference to a method or
> > function. You need magic to simulate it.
>
> Since when did utilizing a method to request a specific value become
> some sort of magic?

Since it requires a special method that has super powers no method you 
can write yourself can do.

Can you write a pure-Ruby method that does the same thing as 
Object.method, using only standard, public parts of the Ruby API? No 
special debugger hooks or "subject to change without warning" internal 
APIs or other private implementation details.

I don't believe you can.

If you can emulate Object.method, without calling Object.method either 
directly or indirectly, then it is not magic.

But if you can't, then it relies on private, esoteric knowledge of the 
Ruby internals not available to anyone else. In other words, magic.



[...]
> Even though i prefer Python's way better, the implicit return of Python
> function references is far more "magical" than making an explicit call
> to a method will ever be.

Let's say you have an object, lassie = Dog(). How do you get access to 
her tail? Do you use dot syntax:

lassie.tail

or do you call some sort of special "attribute access method"?

lassie.attribute("tail")


Of course you use the first. How is dot attribute syntax "implicit"? The 
dot for attribute access is right there, as is the name of the attribute.

None of this changes one iota if we write `lassie.bark` instead of 
`lassie.tail`. There's nothing "implicit" about it, it is as explicit as 
you can possibly get: use the dot attribute access (pseudo)operator to 
get a reference to the attribute, regardless of whether that attribute is 
a tail or a method.

The difference with Ruby is that they treat methods as a distinct kind of 
thing to other members, even though they use the same syntax (dot) for 
both. Yay for inconsistency!

Ruby attributes are always private. You must write accessor getter and 
setter methods if you want to access them from outside the instance or 
class. But once you have those accessors, you can use lassie.tail to 
access the member (attribute) tail, and lassie.bark to *call* the method. 
There is no member "bark" because methods aren't values.

That means to get access to a first-class value of the bark method, you 
need a special function, Object.method, which uses magic to wrap the 
method in an ordinary Ruby object. That's not needed in Python, because 
methods already are ordinary Python objects.



-- 
Steve

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

Re: Welcome to the "Python-list" mailing list

[Terry Reedy]

On 3/27/2018 11:06 AM, nadir musallam wrote:


I have tried installing Python3.6.4 on my computer as I am eager to begin a


What exactly did you do?

new career in data analytics. However I am running in to some problems when attempting to set up the software. I have downloaded Dev C++ software as per 


I don't know what Dev C++ software you installed.  Visual Studio C++? 
You do not need anything other than the python.org installer to install 
and run Python.



your recommendation earlier but still getting the same error when trying to 
launch the program.


The log file shows no errors.  What did you actually do and what error 
did you see.  Either copy and paste or copy by hand.



Your assistance would be very much appreciated. I hope this time I followed the 
proper instructions for the emailing list as it is not my intention to offend 
anyone.


You post made it to python-list, where I read it.


--
Terry Jan Reedy

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
[...]
> > Since when did utilizing a method to request a specific
> > value become some sort of magic?
>
> Since it requires a special method that has super powers no
> method you can write yourself can do.

That's hilarious. I guess you never called __init__? LOL!

> Can you write a pure-Ruby method that does the same thing
> as Object.method, using only standard, public parts of the
> Ruby API? No special debugger hooks or "subject to change
> without warning" internal APIs or other private
> implementation details.

I'm not your personal tutor, Steven. And i'm not about to
waste one second of my time writing a solution to a non-
problem. Ruby already provides a well-known mechanism to
retrieve the method object. If you seek assistance, why
don't you go over the Ruby-list and ask them for help. I'm
sure they'd be very eager to help after hearing all the nice
things you've said about Ruby.

> > Even though i prefer Python's way better, the implicit
> > return of Python function references is far more "magical"
> > than making an explicit call to a method will ever be.
>
> Let's say you have an object, lassie = Dog(). How do you
> get access to her tail? Do you use dot syntax:
>
> lassie.tail

I dunno, because you failed to provide a class definition
for `Dog`, so i have nothing to go on save this horrid
explanation of yours. It'd be like me asking you to list the
contents of my refrigerator. Listen, post a code sample and
then i'll comment on it. Until then, don't expect me to read
your mind.

> [snip: more questions about some mysterious Dog class
> (probably stored at Area 51!)]
>
> Ruby attributes are always private.

Indeed. Unlike Python, Ruby is a pure OO language, and thus,
demands that public attributes must be explicitly made
public. Think of Ruby as existing somewhere between Python
and Java. Ruby tries to be as pure about OOP as it can
without becoming as onerous as Java. So yeah, you can safely
assume that Python and Ruby are not the same language
(surprising, i know!)

> You must write accessor getter and setter methods if you
> want to access them from outside the instance or class.

Yes. Unlike Python, Ruby doesn't believe in the philosophy
of "consenting adults" (where privatization of attributes
and methods is done using something as ridiculously brittle
as leading underscores [insert laugh track here]). And Ruby
sure as heck does not promote the utterly annoying Python
misfeature otherwise known as "name mangling".

Which reminds me!!!

So you think Ruby is the _only_ language that has
misfeatures? Well, feast your eyes on this Python
perversion!

>>> class Fu(object):
def bar1(self):
pass
def _bar2(self):
pass
def __bar3(self):
pass
>>> fu = Fu()
>>> [name for name in dir(fu) if 'bar' in name]
['_Fu__bar3', '_bar2', 'bar1']

What happened to the method named "__bar3"?

Where did it go?

"Hey Python, I want my symbol back!"

Tip: Better go check Area 51, cause i assure you, Steven,
you won't find that symbol anywhere in Python. It's gone
dude! Off in another parallel universe. Probably hangin'
with the Squaches and eatin' beef jerky, for all we know.

And to think! During this entire thread you have gone out of
your way to call Ruby inconsistent and accuse her of
returning surprising results... well then... tell us Mr.
D'Aprano, how does the crow taste? Hmm?

> But once you have those accessors, you can use lassie.tail
> to access the member (attribute) tail, and lassie.bark to
> *call* the method. There is no member "bark" because
> methods aren't values.

Care to provide some code that will prove your point? Or are
we condemned to suffer more of these horrid explanations of
yours?

PS: If you need help writing the Dog class, send me a PM.
And if you're nice, maybe i'll help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pep8 for long pattern

[Dan Stromberg]

On Tue, Mar 27, 2018 at 4:37 PM, Rick Johnson
 wrote:
> On Tuesday, March 27, 2018 at 4:02:37 PM UTC-5, Dan Stromberg wrote:
>> On Tue, Mar 27, 2018 at 8:18 AM, Michael Torrie  wrote:
>> > But when it's exactly what you need, why do you need to
>> > shoehorn the expression into 79 characters?  Seems
>> > pointless in a case like this. PEP8 is a guideline, not an
>> > absolute rule.  It's okay to bend it a bit in cases like
>> > this.
>>
>> I think PEP8 specifying a max of 80 columns is very silly.
>> Even an old VT220 terminal could do 132 columns.
>
> And just think how many columns you could do with 1pt font!
> And while i admit i enjoy coding with my nose pressed
> against the monitor as much as the next "guyal"[1], just uh,
> be sure to keep a good optometrist on retainer, eh pal?

I realize you're just trying to be a pest, but some folks will take
your words seriously.

I can easily get 132+ columns of a font large enough for my 52 year
old eyes on a 15" laptop.

>> My understanding is that PEP8 requires 80 columns because a
>> tiny, tiny, tiny minority of Python developers wanted to be
>> able to put 3 editors next to each other horizontally,
>> without wrapping.
>
> Stacking horizontal windows three deep is all the rage, but
> the reason has more to do with easy reading. Long lines are
> difficult to read. And when your eyes do a linefeed at the
> end of a 200 character long line, there's no guarantee
> you'll end up starting on the next line. Sometimes you'll
> find yourself three lines down, while others, back at the
> start of the same line. And that's annoying.

Again, you're just trying to be a pest, but no one is asking for
10,000,000 columns.  120 or 132 would be good.

80 is actually a bit defeatist, because it discourages developers from
using more descriptive identifiers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Wed, Mar 28, 2018 at 1:22 PM, Rick Johnson
 wrote:
> On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
>> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
> [...]
>> > Since when did utilizing a method to request a specific
>> > value become some sort of magic?
>>
>> Since it requires a special method that has super powers no
>> method you can write yourself can do.
>
> That's hilarious. I guess you never called __init__? LOL!

Ah yes, argument by ridicule. An excellent way to cover over the fact
that you have not a shred of truly viable argument to bring out.

Last I checked, __init__ was just like any other dunder method: a
perfectly ordinary method that happens to be called by someone else. A
callback method, if you will.

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

Re: Pep8 for long pattern

[Rick Johnson]

On Tuesday, March 27, 2018 at 9:37:14 PM UTC-5, Dan Stromberg wrote:
> I can easily get 132+ columns of a font large enough for my
> 52 year old eyes on a 15" laptop.

Well, if you're comfortable with the long lines, fine. But
be aware that long lines are poo-pooed in most professional
enviroments.

> 80 is actually a bit defeatist, because it discourages
> developers from using more descriptive identifiers.

I'm a big fan of self-documenting code. But sometimes i have
to remind myself that really long names make the code harder
to read. The wise find a nice balance between readability
and self-documenting. And unless you're a masochist, don't
look to Microsoft for inspiration!

Another reason for 80 char limit is to prevent deeply nested
blocks. At the PEP8 recommended four-space-indention, three
blocks is about all you can get. And that's good enough for
me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: please test the new PyPI (now in beta)

[dieter]

Tim Golden  writes:
> ...
> In either case, talking about it
> here seems fruitless.

Someone asked for feedback here. At least he should look for it here.

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

Re: condition.acquire vs lock.acquire

[dieter]

jayshankar nair via Python-list  writes:
> Is condition.acquire(threading.Condition()) similar to 
> lock.acquire(threading.Lock). Does both of get access to the lock. Can i use 
> condition.wait,notify with lock.acquire or i have to use condition.wait, 
> notify with condition.acquire.
> cond.acquire()  // can i replace with lock.acquire
>
>    while count[ipID]> 1:
>   cond.wait()
>    if ipID == 0:
>   time.sleep(10)
>
>
>    count[ipID] = count[ipID] + 1
>
>
>    cond.release() // can i replace with lock.release

The documentation tells you that a "condition" is always associated
with a "lock". You can either pass in a "lock" object when you
create a "condition" (in case, multiple "condition"s must share
the same lock) or such an object is created automatically.
The "condition"'s "acquire" and "release" methods call the respective
methods of this lock.

To determine whether you can call "lock.{acquire|release}"
(instead of "condition.{acquire|release}") look at
the implementation of the "condition" methods: if all
they do is delegating to the "lock" methods, it is safe; otherwise,
it is not safe.

Anyway, you should use "condition.{acquire|release}"
for clarity when working with "condition" (especially, calling its "wait",
"notify*" operations) rather than use the "lock" methods *UNLESS*
you have really good reasons to make use of the
"condition -> lock" association.

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