Re: [Python-ideas] Internal function idea

[Franklin? Lee]

On Fri, Dec 29, 2017 at 1:01 AM, Chris Angelico  wrote:
> On Fri, Dec 29, 2017 at 1:31 PM, Franklin? Lee
>  wrote:
>> On Thu, Dec 28, 2017 at 5:21 AM, William Rose  
>> wrote:
>>> I agree with the point that it should allow builtin but the main purpose of
>>> it is to not allow global variables
>>
>> But functions are also accessed using global names. What is your
>> answer to the potential problem of programmers being reluctant to
>> factor out code into new functions?
>
> Code review, training, mentorship. If you try to make the language too
> restrictive, all you end up doing is forcing people to creatively get
> around its limitations. Make the language expressive, and then teach
> people how to use it well.
>
> Can you show some examples of code that would be improved by this
> "internal function" concept?

Hey, I'm the one saying that internal functions will promote bad habits.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Internal function idea

[Chris Angelico]

On Fri, Dec 29, 2017 at 1:31 PM, Franklin? Lee
 wrote:
> On Thu, Dec 28, 2017 at 5:21 AM, William Rose  
> wrote:
>> I agree with the point that it should allow builtin but the main purpose of
>> it is to not allow global variables
>
> But functions are also accessed using global names. What is your
> answer to the potential problem of programmers being reluctant to
> factor out code into new functions?

Code review, training, mentorship. If you try to make the language too
restrictive, all you end up doing is forcing people to creatively get
around its limitations. Make the language expressive, and then teach
people how to use it well.

Can you show some examples of code that would be improved by this
"internal function" concept?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hi Inada, can I take your point as being that execution speed is an issue? 

I am coming from the "Python as higher level, more programmer-centric 
language"direction.

In the past, useful but slow things have spurred actions to speed them up. ___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Internal function idea

[Franklin? Lee]

On Thu, Dec 28, 2017 at 5:21 AM, William Rose  wrote:
> I agree with the point that it should allow builtin but the main purpose of
> it is to not allow global variables

But functions are also accessed using global names. What is your
answer to the potential problem of programmers being reluctant to
factor out code into new functions?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Deprecate "slice" on built-ins, move it to "types"?

[Nathaniel Smith]

On Dec 28, 2017 12:10, "Joao S. O. Bueno"  wrote:

This is probably too little  to justify the compatibility breakage, but is
there a motive for the "slice" type to be on built-ins ?
(besides people forgot it there at PEP-3000 time?)

It is normally used in super-specialized cases, mostly when one is
implementing a Sequence type, and even there just for type-checking,
not to create new slice objects.


It does get called sometimes in numerical code to construct complex
indexing operations.

-n
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Deprecate "slice" on built-ins, move it to "types"?

[Steven D'Aprano]

On Thu, Dec 28, 2017 at 06:09:32PM -0200, Joao S. O. Bueno wrote:
> This is probably too little  to justify the compatibility breakage,

Indeed.

[...]
> It seems to me it should lie on the "types" module (or some other
> place), rather than
> eat built-in namespace (which can confuse newcomers anyway).

Have you actually come across newcomers who are confused by slice being 
a built-in? I've been on the tutor mailing list, and comp.lang.python, 
for many years now and I don't recall anyone even asking about slice let 
alone being confused by it.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a set of enum.Enum values rather than the construction of bit-sets as the "norm"?

[Paddy3118]

Hi Steve, I did not write an attack on the "Python devs". Re-read my 
original with a little less hostility and there should be room for an 
interpretation, (which I meant), that does not warrant such a hostile reply.

The original is written in the hope of furthering discussion on the need 
for what is deemed pythonic , and on what Python is taught , as the 
language itself changes.
We now have enums if you want to pass a set of flags to a function then you 
could have them as separate arguments - but that leads to long and 
cumbersome parameter lists; you could, and many do, have flags that are 
individual powers of two and then or them together and pass the result - 
creating a bitset; but we can now have the flags as separate enum.Enums and 
pass a set of values to a function as the flag set. 

This new way means that people being taught the method can use a knowledge 
of sets and enums - no need to know about powers of two,, what happens when 
they are bit-or'd together; and bitsets. We have gone to a higher level 
description of what we are doing; no need to mired in the details of the 
how of what one wants to achieve. bitsets can be taught as an optimisation.

As for re, and otheralready written libraries, their is no need to change 
them, but other Pythoneers might well opt to not use bitsets, but rather 
sets of enum values.


On Wednesday, 27 December 2017 05:58:00 UTC, Steven D'Aprano wrote:
>
> On Tue, Dec 26, 2017 at 12:07:52PM -0800, Paddy3118 wrote: 
>
> > Maybe it is time to deemphasize the creation and passing of what is, in 
> > effect, bit-sets as a single 
> > argument, and instead promote the passing of a set of members of an 
> > enum.Enum  constants. 
>
> That implies that we are promoting bit sets (not merely using them). 
> Where are we doing that? 
>
>
> > Thi comes about because someone wrote a description, (since deleted), 
>
> "Someone"? One of the Python core developers? 
>
> If not, well, the Python devs cannot be held responsible for what random 
> people on the internet write. 
>
>
> > of 
> > constructing bit-sets to use in passing flags to, for example, the 
> > re.compile function. 
>
> > The use of individual bits in a bit-array/bit-set to pass multiple flags 
> is 
> > an implementation detail. 
>
> It certainly is not an implementation detail -- it is a part of the 
> public, published interface to the re module. 
>
> Of course had history been different, re.compile *could* have taken a 
> set of Enums instead. But that doesn't make it an implementation detail. 
> That would be like saying that: 
>
>re.search(pattern, text, flags=0) 
>
> is an implementation detail, and we should feel free to change it to 
>
>re.examine(text, pattern, set_of_enums=frozenset()) 
>
> We can't change a public interface documented as taking an integer to 
> one taking a set of Enums without going through a deprecation period. 
>
> However, we could *add* an additional interface, where the re functions 
> that currently accept an integer flag *also* accepts a set of Enums. 
>
>
> > Should we not *first *teach the passing of a set 
> > of enum.Enum constant values in one argument as the *pythonic *way; 
>
> What makes you say that is the Pythonic way? (That's not a rhetorical 
> question.) 
>
>
> -- 
> Steve 
> ___ 
> Python-ideas mailing list 
> python...@python.org  
> https://mail.python.org/mailman/listinfo/python-ideas 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Deprecate "slice" on built-ins, move it to "types"?

[Joao S. O. Bueno]

This is probably too little  to justify the compatibility breakage, but is
there a motive for the "slice" type to be on built-ins ?
(besides people forgot it there at PEP-3000 time?)

It is normally used in super-specialized cases, mostly when one is
implementing a Sequence type, and even there just for type-checking,
not to create new slice objects.

It seems to me it should lie on the "types" module (or some other
place), rather than
eat built-in namespace (which can confuse newcomers anyway).

As I said, the benefits of moving it to a less prominent place may be
to little, and
incompatibilities would ensue since all modules using it don't expect to have
to import it anyway. But maybe thsi should be a thing to keep an eye on for
some future Python release?

js
  -><-
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Serhiy Storchaka]

28.12.17 12:10, Erik Bray пише:

There's no index() alternative to int().


operator.index()

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Erik Bray]

On Fri, Dec 8, 2017 at 7:20 PM, Ethan Furman  wrote:
> On 12/08/2017 04:33 AM, Erik Bray wrote:
>
>> More importantly not as many objects that coerce to int actually
>> implement __index__.  They probably *should* but there seems to be
>> some confusion about how that's to be used.
>
>
> __int__ is for coercion (float, fraction, etc)
>
> __index__ is for true integers
>
> Note that if __index__ is defined, __int__ should also be defined, and
> return the same value.
>
> https://docs.python.org/3/reference/datamodel.html#object.__index__

This doesn't appear to be enforced, though I think maybe it should be.

I'll also note that because of the changes I pointed out in my
original post, it's now necessary for me to explicitly cast as int()
objects that previously "just worked" when passed as arguments in some
functions in itertools, collections, and other modules with C
implementations.  However, this is bad because if some broken code is
passing floats to these arguments, they will be quietly cast to int
and succeed, when really I should only be accepting objects that have
__index__.  There's no index() alternative to int().

I think changing all these functions to do the appropriate
PyIndex_Check is a correct and valid fix, but I think it also
stretches beyond the original purpose of __index__.  I think that
__index__ is relatively unknown, and perhaps there should be better
documentation as to when and how it should be used over the
better-known __int__.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/