Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

2017-08-09 Thread eryk sun 
On Wed, Aug 9, 2017 at 11:32 PM, Alan Gauld via Tutor  wrote:
> On 09/08/17 22:15, Steven D'Aprano wrote:
>>
>> This is the critical factor. How can you use *by default* something that
>> is *NOT* supplied by default?
>
> I have to agree with Steven here. Any mature language should
> ship with all the tools needed to create and distribute a
> finished program. It is to Python's shame that it currently
> fails that test because the recommended distribution framework
> is not part of the standard language package. (and the irony
> is that the tool for installing the recommended format (pip)
> is in the standard library. You can download other peoples
> stuff but you can't make your own in the same format.
> That's bad.

The standard library has ensurepip [1] to bootstrap bundled wheels for
pip and setuptools, which in turn vendor other packages such as
distlib. The wheels are already there, unless the distro or IT
department has removed them. (They're distributed with the official
Windows installers, at least.) If you want the legal details, you
could ask on the pypa-dev list [2]. I'm sure Nick Coghlan or Donald
Stufft would be happy to clarify the situation.

[1]: https://github.com/python/cpython/tree/v3.6.2/Lib/ensurepip
[2]: https://groups.google.com/forum/#!forum/pypa-dev
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

2017-08-09 Thread Alan Gauld via Tutor 
On 09/08/17 22:15, Steven D'Aprano wrote:
> On Tue, Aug 08, 2017 at 12:56:56PM +0200, Chris Warrick wrote:
> 
>> While setuptools is not officially part of the stdlib,
> 
> This is the critical factor. How can you use *by default* something that 
> is *NOT* supplied by default?

I have to agree with Steven here. Any mature language should
ship with all the tools needed to create and distribute a
finished program. It is to Python's shame that it currently
fails that test because the recommended distribution framework
is not part of the standard language package. (and the irony
is that the tool for installing the recommended format (pip)
is in the standard library. You can download other peoples
stuff but you can't make your own in the same format.
That's bad.

I hope that this is remedied soon, but for the moment Python
is horribly at odds with itself - enough to disqualify it
from use in many organisations.

Any default solution must be available by default.
It doesn't matter how many people recommend another
solution, if it isn't there it can't be used, and
therefore, can't be the default.

Sadly there seem to be many in the Python community who
do not understand the seriousness of this limitation
in terms of Python's adoption. Because they can access
it they assume everyone can. It's not true, and the further
up the Fortune 500 tree you climb the more that is the case.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] If tuple cannot be sorted, then why sorted() on a tuple is fine?

2017-08-09 Thread C W 
This is a follow up. I actually ran into this today:

import numpy as np
xArray = np.ones((3, 4))

> xArray.shape
(3, 4)
> np.shape(xArray)
(3, 4)

It was confusing to see that both xArray.shape and np.shape() worked. Are
they equivalent?

In the case of sort() vs sorted(), they are different, but close enough to
mistake them as the same thing.

Thanks!

On Wed, Aug 2, 2017 at 9:32 PM, C W  wrote:

> As pointed out by someone else, ?sorted
> sorted(iterable, key=None, reverse=False)
>
> It seems like the only requirement is iterable. I guess tuple is iterable,
> so, it doesn't break the assumption that tuple is immutable.
>
> That's what I see, am I right in that?
>
> Thanks!
>
> On Wed, Aug 2, 2017 at 4:07 PM, Alan Gauld via Tutor 
> wrote:
>
>> On 02/08/17 20:01, C W wrote:
>>
>> > I am a little confused about why Tuple can be sorted.
>> >
>> > Suppose I have the following,
>> >
>> >> aTuple = (9, 3, 7, 5)
>> >> sorted(aTuple)
>> > [3, 5, 7, 9]
>>
>> sorted() returns a new object.
>> The original tuple has not been changed
>>  - print aTuple to confirm this.
>>
>> HTH
>> --
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>> http://www.amazon.com/author/alan_gauld
>> Follow my photo-blog on Flickr at:
>> http://www.flickr.com/photos/alangauldphotos
>>
>>
>> ___
>> Tutor maillist  -  Tutor@python.org
>> To unsubscribe or change subscription options:
>> https://mail.python.org/mailman/listinfo/tutor
>>
>
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] setup.py "script" vs "console_scripts" Was: if __name__=='main' vs entry points: What to teach new comers?

2017-08-09 Thread Steven D'Aprano 
On Tue, Aug 08, 2017 at 12:56:56PM +0200, Chris Warrick wrote:

> While setuptools is not officially part of the stdlib,

This is the critical factor. How can you use *by default* something that 
is *NOT* supplied by default?

Obviously you cannot. It is physically impossible.


> it *is*
> recommended by the official documentation, the dev team, and it’s
> available pretty much everywhere.

Maybe if your concept of "everywhere" is limited to the subset of Python 
users who have a Linux distro and the permission (both the computer 
privileges and the legal authority) to install software on the computer 
they are using.

But this does NOT hold for everyone, possibly not even for the majority 
of Python users. For example: 

- students using their school's computers;

- corporate and government users using a SOE (Standard Operating
  Environment);

- people using a system where, for policy reasons, only the 
  standard library is permitted.

(E.g. they have their software audited for compliance with licencing and 
malware, the std lib has been audited but third party libraries have 
not. It might take literally months to get permission to install even a 
simple third party library.)

I've worked in places where installing unauthorized software was a 
firing offence.


> setuptools can’t be in stdlib,
> because it’s moving too fast for stdlib to keep up.

The reason doesn't matter. What matters is that it isn't available by 
default, so it cannot be the default.


> Look here: http://pythonwheels.com/ — 254 of the top 360 packages on
> PyPI use wheels. It means that at least that many use setuptools;
> sometimes with a distutils fallback, but often without one. Moreover,
> many of the packages without wheels use setuptools as well.

All this tells me is that many third party packages choose the 
*convenient* choice, not the *default* choice.

That is their right, of course. Nobody says otherwise.

And of course the sort of users who cannot install setuptools likewise 
cannot install their package, so the developers might not care about 
people without setuptools. But that hardly makes it the *default*. It 
just makes it the more popular option.


> The sane default choice is entry_points.

Only if your definition of "sane" or "default" is different from mine.



-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Tutor Digest, Vol 162, Issue 25

2017-08-09 Thread Jaroslaw Michalski 
>
> > The machine I'm on here is writing big endian UTF-16 and UTF-32.
> >
> > As you note, the 16 and 32 forms are (6 + 1) times 2 or 4 respectively. This
> > is because each encoding has a leading byte order marker to indicate the big
> > endianness or little endianness. For big endian data that is \xff\xfe; for
> > little endian data it would be \xfe\xff.
>
> The arithmetic as I mentioned in my original post is what I am
> expecting in "bytes", but my current thinking is that if I have for
> the BOM you point out "\xff\xfe", I translate that as 4 hex digits,
> each having 16 bits, for a total of 64 bits or 8 bytes.  What am I
> misunderstanding here?  Is a definition of "byte" meaning something
> other than 8 bits here?  I vaguely recall reading somewhere that
> "byte" can mean different numbers of bits in different contexts.
>
> And is len() actually counting "bytes" or something else for these encodings
>

Hi there.
"\xff\xfe" it looks like 4 hex digits, but 1 hex digit can be
represented by only 4 binary digits.
1 byte is 8 bits, so 2 hex digits per 1 byte
xff is one byte and you've got 2 hex digits.
xf (as a hex digit) can be represented as b (binary format)
xff\xfe in a binary format is b  \ b 1110
4 hex digits = 16 bits = 2 bytes
for example xff is b = 255 and it's the biggest number when
you use only 8 bits (1byte)
The problem was that 16 bits per a hex digit is not true. One hex
digit is only 4 bits, from b or x0 to b or xf (dec 15)
I hope it's clear now.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] What exactly does the three dots do? Why such as thing?

2017-08-09 Thread C W 
Dear Python experts,

What exactly does the three dots do?
> aList = ...
> type(pList)
ellipsis

It's an ellipsis, a spot holder to later. But what data type is it: vector,
matrix?

In every other language, you initialize a variable you want to use. What's
the point of ellipsis?

Thanks!
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] The sane default choice is entry_points console_scripts Was: if __name__=='main' vs entry points: What to teach new comers?

2017-08-09 Thread Thomas Güttler 



Am 08.08.2017 um 12:56 schrieb Chris Warrick:

On 8 August 2017 at 03:30, Ben Finney  wrote:

Thomas Güttler  writes:


Why is "the sane default is 'use console_scripts entry-point in
setup.py'" not a good answer?


Because third-party Setuptools is required for entry points, which means
entry points cannot be a default choice.

It may well be a good choice for many cases. But that's a different
matter from it being a good *default* choice; it can only be a default
choice if it's in the standard library.


While setuptools is not officially part of the stdlib, it *is*
recommended by the official documentation, the dev team, and it’s
available pretty much everywhere. setuptools can’t be in stdlib,
because it’s moving too fast for stdlib to keep up.

Look here: http://pythonwheels.com/ — 254 of the top 360 packages on
PyPI use wheels. It means that at least that many use setuptools;
sometimes with a distutils fallback, but often without one. Moreover,
many of the packages without wheels use setuptools as well.






The sane default choice is entry_points.


Sounds good. Thank you for this statement.

Regards,
  Thomas Güttler




--
Thomas Guettler http://www.thomas-guettler.de/
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor