Re: [Python-ideas] slice[] to get more complex slices

[Stephan Hoyer]

On Sat, Jul 28, 2018 at 9:44 AM Jonathan Fine  wrote:

> By all means start a PEP (on github) if you find it helps you. I think
> it's too early.
>
> If this problem has a pure Python solution, then I think it best to
> develop it as a third party module. I suggest the name slicetools.
> When slicetools is established, has users and is stable. That would be
> the time to submit the PEP. I think it would give a smoother and
> easier path.
>

For most proposals, I would agree that agree that a reference
implementation as a third-party library makes sense. But operator.subscript
so simple that it would be counter productive to write it in third-party
module.

The pure Python reference implementation for operator.subscript is
literally four lines (or three lines, with __class_getitem__ in Python 3.7):

class _Subscript:
def __getitem__(self, key):
return key
subscript = _Subscript()

Very few people would use an implementation in a third-party package,
because it seems unlikely to be worth the trouble of adding a dependency
for so few lines of code -- copy & paste is actually more maintainable.
This exact same operator also already exists in two popular third-party
Python packages by the names numpy.s_ and pandas.IndexSlice.

That said, the actual logic is not obvious, unless you already understand
the details of how Python's indexing works. So most user code does not
benefit in clarity by copying and pasting it.
___
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] Redefining method

[Stephan Houben]

Here is an example of how it could be done.

https://gist.github.com/stephanh42/97b47506e5e416f97f5790c070be7878


Stephan

Op di 31 jul. 2018 01:29 schreef Steven D'Aprano :

> On Tue, Jul 31, 2018 at 10:10:32AM +1200, Greg Ewing wrote:
> > Jamesie Pic wrote:
> > >def o.bar(self): ...
> >
> > You could get almost the same effect with
> >
> >from functools import partial
> >
> >def bar(self, other_args):
> >   ...
> >
> >o.bar = partial(bar, o)
>
> Why are you using functools.partial instead of types.MethodType? I'm
> wondering if there is some advantage to partial that I don't recognise.
>
> I'm not sure if there's a functional difference between the two
> approaches, but it makes o.bar a different kind of callable and that
> will probably make a difference to somebody.
>
>
> > But IMO this is nowhere near being a common enough thing to
> > do to justify having special syntax for it.
>
> This sort of thing isn't common because there's no neat, easy, obvious,
> built-in way to do it. If we allowed people to extend classes using the
> syntax
>
> def classobj.methodname(...): ...
>
> def instance.methodname(...): ...
>
> people would use the technique more. For good or ill.
>
> I don't question the utility of this technique, but I suspect we prefer
> to *slightly* discourage it by *not* providing a Batteries Included
> solution for this. If you want to do this, we won't stop you, but
> neither will we encourage it by supporting it in syntax or providing a
> standard decorator for 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/
>
___
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] Redefining method

[Steven D'Aprano]

On Tue, Jul 31, 2018 at 10:10:32AM +1200, Greg Ewing wrote:
> Jamesie Pic wrote:
> >def o.bar(self): ...
> 
> You could get almost the same effect with
> 
>from functools import partial
> 
>def bar(self, other_args):
>   ...
> 
>o.bar = partial(bar, o)

Why are you using functools.partial instead of types.MethodType? I'm 
wondering if there is some advantage to partial that I don't recognise.

I'm not sure if there's a functional difference between the two 
approaches, but it makes o.bar a different kind of callable and that 
will probably make a difference to somebody.


> But IMO this is nowhere near being a common enough thing to
> do to justify having special syntax for it.

This sort of thing isn't common because there's no neat, easy, obvious, 
built-in way to do it. If we allowed people to extend classes using the 
syntax

def classobj.methodname(...): ...

def instance.methodname(...): ...

people would use the technique more. For good or ill.

I don't question the utility of this technique, but I suspect we prefer 
to *slightly* discourage it by *not* providing a Batteries Included 
solution for this. If you want to do this, we won't stop you, but 
neither will we encourage it by supporting it in syntax or providing a 
standard decorator for 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] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Terry Reedy]

On 7/30/2018 9:43 AM, Petr Viktorin wrote:

On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok  wrote:



   $ python3 -m gettext.msgfmt


+1
Note that this means gettext will need to become a package.


Once there is a command line interface, arguments can be supplied to the 
module, as in python -m gettext msgfmt. This only affects the newly 
added main function.


--
Terry Jan Reedy


___
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] Redefining method

[Greg Ewing]

Jamesie Pic wrote:

def o.bar(self): ...


You could get almost the same effect with

   from functools import partial

   def bar(self, other_args):
  ...

   o.bar = partial(bar, o)

But IMO this is nowhere near being a common enough thing to
do to justify having special syntax for it.

--
Greg
___
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 this PEP-able? "with" statement inside genexps / list comprehensions

[Oscar Benjamin]

On 30 July 2018 at 20:15, Rudy Matela  wrote:
> Hello,

Hi Rudy,

> Do you think it would be nice to allow with statements inside genexps or
> list comprehensions?  The functions __enter__ and __exit__ would be
> automatically called as iterables are traversed.  I am thinking of
> drafting a PEP about this.  Examples:
>
>
> This
>
> g = (f.read() for fn in filenames with open(fn) as f)
>
> would be equivalent to the following use of a generator function:
>
> def __gen():
> for fn in filenames:
> with open(fn) as f:
> yield f.read()
> g = __gen()

Yielding from a with block should be discouraged rather than given
special syntax. There is essentially a contradiction between the
meaning/purpose of yield (suspend indefinitely) and with (definitely
call __exit__).

If I partially iterate over g as in

for line in g:
break

then at this point g is suspended and f.__exit__ has not been called,
so the file is not closed. I may choose to iterate over g later or
not, so it has to remain in suspension just in case. In practice if
you do this in CPython then f.__exit__ will *probably* be invoked
indirectly by g.__del__ if/when the gc collects g. This defeats the
main point of using with-open though which is to avoid depending on
the gc for closing files.

--
Oscar
___
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 this PEP-able? "with" statement inside genexps / list comprehensions

[Kyle Lahnakoski]

Rudy,

I think your proposal may be very specific to iterable context managers;
in which case, make a method that makes that assumption:

> def iter_with(obj):
> with obj as context:
> yield from context

and use it

> g = (
> f.read()
> for fn in filenames
> for f in iter_with(open(fn))
> )

On 2018-07-30 15:15, Rudy Matela wrote:
> Hello,
>
> Do you think it would be nice to allow with statements inside genexps or
> list comprehensions?  The functions __enter__ and __exit__ would be
> automatically called as iterables are traversed.  I am thinking of
> drafting a PEP about this.  Examples:
>
>
> This 
>
>   g = (f.read() for fn in filenames with open(fn) as f)
>
> would be equivalent to the following use of a generator function:
>
>   def __gen():
>   for fn in filenames:
>   with open(fn) as f:
>   yield f.read()
>   g = __gen()
>
>
> This
>
>   list = [f.read() for fn in filenames with open(fn) as f]
>
> would be equivalent to the following:
>
>   list = []
>   for fn in filenames:
>   with open(fn) as f:
>   list.append(f.read())
>
> --
> Rudy
> ___
> 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 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] Redefining method

[Kyle Lahnakoski]

I think C# calls methods that are added to a class "extension methods".
You can make a decorator that will do that for you:

> def extend(cls):
>     """
>     DECORATOR TO ADD METHODS TO CLASSES
>     :param cls: THE CLASS TO ADD THE METHOD TO
>     :return:
>     """
>     def extender(func):
>     setattr(cls, get_function_name(func), func)
>     return func
>     return extender

and use it

> C = MyClass
> @extend(C)
> def foo(self, schesome_param):
>     some_code()



On 2018-07-30 14:12, Chris Barker via Python-ideas wrote:
> On Mon, Jul 30, 2018 at 9:10 AM, Nick Coghlan  > wrote:
>
> If you need to replace them for some reason, it will preferably be
> within a temporary bounded scope, using a tool like
> unittest.mock.patch, rather than as a permanent change that affects
> every other use of the class within the process.
>
>
>  yup -- but you can still do a raw monkey-patch anyway. You asked for:
>
> > Thank you for your question. You asked why not
> >> c = MyClass
> >> o = c()
> >>
> >> def c.foo(cls): ...
>
>
> do you mean this? you want a classmethod? or is this what you mean? --
> which you can do:
>
> C = MyClass
>
> def foo(self, some_param):
>     some_code()
>
> C.foo = foo
>
> (note that I used a capital C -- capitalized names are traditional for
> classes -- see PEP 8)
>
> In that case, any existing, and new instances of the C class will now
> have the foo method.
>
> Also -- that line: C = MyClass -- binds the name "C" to the very same
> class object as MyClass -- so you will have just monkey=patched
> MyClass -- I"m guessing you didn't want that. If not, and you wanted C
> t be a copy of MyClass that you could then change/add/remove methods
> from, then you want subclassing -- that is exactly what it is for.
>
> Then there is this:
>  
>
> >> def o.bar(self): ...
>
>
> which is monkey patching an instance object, which you can also do,
> but you don't get a bound method -- i.e. it doesn't get self passed in
> automatically.
>
> -CHB
>
>
>
>
>
>
>
>
>
>  
>
> > I've the same same query, but never had the courage to ask. So that
> > you for asking. And also giving me a chance to share my thoughts.
>
> It's essentially due to the fact that while we deliberately allow
> runtime monkeypatching (as it's sometimes the best available answer),
> we also strongly encourage the idea of treating it as a last resort
> option (outside specific use cases like testing).
>
> So if you want to define methods on a class, the strongly preferred
> place to define them is inside the class definition, where they're
> easy for future maintainers of that class to find.
>
>
> Cheers,
> Nick.
>
> P.S. While it's *not* explicitly part of Python's design rationale,
> http://connascence.io/locality.html
>  and the rest of that site
> provide
> some good info on the kinds of problems that "action at a distance"
> effects, like monkeypatching class definitions, can cause in a code
> base.
>
> -- 
> Nick Coghlan   |   ncogh...@gmail.com  
>  |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org 
> https://mail.python.org/mailman/listinfo/python-ideas
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
>
>
>
>
> -- 
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> chris.bar...@noaa.gov 
>
>
> ___
> 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 mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Is this PEP-able? "with" statement inside genexps / list comprehensions

[Rudy Matela]

Hello,

Do you think it would be nice to allow with statements inside genexps or
list comprehensions?  The functions __enter__ and __exit__ would be
automatically called as iterables are traversed.  I am thinking of
drafting a PEP about this.  Examples:


This 

g = (f.read() for fn in filenames with open(fn) as f)

would be equivalent to the following use of a generator function:

def __gen():
for fn in filenames:
with open(fn) as f:
yield f.read()
g = __gen()


This

list = [f.read() for fn in filenames with open(fn) as f]

would be equivalent to the following:

list = []
for fn in filenames:
with open(fn) as f:
list.append(f.read())

--
Rudy
___
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] Redefining method

[Chris Barker via Python-ideas]

On Mon, Jul 30, 2018 at 9:10 AM, Nick Coghlan  wrote:

If you need to replace them for some reason, it will preferably be
> within a temporary bounded scope, using a tool like
> unittest.mock.patch, rather than as a permanent change that affects
> every other use of the class within the process.


 yup -- but you can still do a raw monkey-patch anyway. You asked for:

> Thank you for your question. You asked why not
> >> c = MyClass
> >> o = c()
> >>
> >> def c.foo(cls): ...
>

do you mean this? you want a classmethod? or is this what you mean? --
which you can do:

C = MyClass

def foo(self, some_param):
some_code()

C.foo = foo

(note that I used a capital C -- capitalized names are traditional for
classes -- see PEP 8)

In that case, any existing, and new instances of the C class will now have
the foo method.

Also -- that line: C = MyClass -- binds the name "C" to the very same class
object as MyClass -- so you will have just monkey=patched MyClass -- I"m
guessing you didn't want that. If not, and you wanted C t be a copy of
MyClass that you could then change/add/remove methods from, then you want
subclassing -- that is exactly what it is for.

Then there is this:


> >> def o.bar(self): ...
>

which is monkey patching an instance object, which you can also do, but you
don't get a bound method -- i.e. it doesn't get self passed in
automatically.

-CHB











> > I've the same same query, but never had the courage to ask. So that
> > you for asking. And also giving me a chance to share my thoughts.
>
> It's essentially due to the fact that while we deliberately allow
> runtime monkeypatching (as it's sometimes the best available answer),
> we also strongly encourage the idea of treating it as a last resort
> option (outside specific use cases like testing).
>
> So if you want to define methods on a class, the strongly preferred
> place to define them is inside the class definition, where they're
> easy for future maintainers of that class to find.
>
>
> Cheers,
> Nick.
>
> P.S. While it's *not* explicitly part of Python's design rationale,
> http://connascence.io/locality.html and the rest of that site provide
> some good info on the kinds of problems that "action at a distance"
> effects, like monkeypatching class definitions, can cause in a code
> base.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] PEP 505: None-aware operators

[Abe Dillon]

 [Rhodri James]

> We could argue about how intuitive or not these operators are, but they
>>> are used in other languages, so they clearly aren't completely
>>> unintuitive.
>>>
>>
>> Other languages are other languages. Other languages use the "
>> ?
>>  : " form of the the ternary operator. That doesn't mean
>> we
>> should adopt that into Python.
>>
>
> But it does and did mean that we should consider it when coming up with
> Python's version of the ternary operator.  *It isn't unintuitive* and
> neither is ??  None-aware operators may be bad for other reasons, but that
> argument doesn't wash.


No. The fact that other languages use it doesn't mean that "it isn't
unintuitive". The fact that other languages use it doesn't mean that it
doesn't harm readability. The fact that other languages use it has pretty
much no bearing on any of that. What it actually means is: other languages
are trying it out so we have the luxury of seeing if they regret it in the
future or if it becomes a popular and well loved feature before integrating
it into Python.

I believe it's counter-intuitive because '?' always comes at the end of an
english sentence, so it reads like other clause-ending operators like the
")" on a function call or the "]" at the end of a index operation, then the
"." reads like a follow-on.

And no; you can't say the same thing about "." always coming at the end of
a sentence because:

a) that's not true (e.g. i.e, e.g., etc.)

b) "." attribute access has many decades of precedence

c) a "." is less visually obtrusive than a "?".

[Rhodri James]

>  Pardon?  It composes exactly like any other in-place operator.


Yes. I'll concede. I was wrong about that.

[Rhodri James]

> yes, you do need to explain how merely being high precedence helps here.
> Let's start small; please explain programmatically what


>   name?



does as an expression.  Once we have that down, we can move on to



  person.(name?)


Sure. First, I would suggest we define a new class
NoneException(BaseException), and derive new Exception multi-classes like:
class NoneAttributeError(AttributeError, NoneException).
Then I would make those the exceptions thrown by attribute errors on the
None object. That way you can conceptualize the '?' operator is to the
try-except statement as the ternary operator is to if-else statements
EXCEPT that the "except" part of the try-except block is implicitly filled
in with "except NoneException: return None" so in general:

?

Would parse to:

try:
result = eval(expression)
except NoneException:
result = None

Similar to how:

 if  else 

Parses to:

if eval(condition_expression):
result = eval(expression_1)
else:
result = eval(expression_2)

More specifically:

name?

Wouldn't do much:

try:
result = name
except NoneException:
result = None

And:

person.(name?)

would throw a SyntaxError because person.( is not valid syntax regardless
of my proposal.
Perhaps you meant something like:

(person.name).first?

In that case; person.name would evaluate to some result or throw an
un-guarded AttributeError, in the former case the  to the left
of the '?' is an attribute access on the result of (person.name). In the
latter case; an AttributeError is thrown.

That seems pretty straight forward. No?

On 29/07/18 16:12, Abe Dillon wrote:

>  > spam?.eggs.cheese.aardvark  # why would you ever do this?



> If you knew that if you really have something in "spam", your program
> guarantees it will have an "eggs" attribute with a "cheese" attribute, etc,
> you just don't know if "spam" is not None.  It's the same insider knowledge
> you would use if you wrote it out as




> spam.eggs.cheese.aardvark if spam is not None else None


That's not the equivalent as described in PEP 505. If "spam" is None,
"spam?.eggs" evaluates to None without throwing an AttributeError, but the
rest of the expression will throw an AttributeError from trying to access
"None.cheese".

On Mon, Jul 30, 2018 at 9:10 AM, Rhodri James  wrote:

> On 29/07/18 16:12, Abe Dillon wrote:
>
>> spam?.eggs.cheese.aardvark  # why would you ever do this?
>>
>
> If you knew that if you really have something in "spam", your program
> guarantees it will have an "eggs" attribute with a "cheese" attribute, etc,
> you just don't know if "spam" is not None.  It's the same insider knowledge
> you would use if you wrote it out as
>
> spam.eggs.cheese.aardvark if spam is not None else None
>
> The same sort of knowledge of your program structure could lead to you to
> use "?." instead of "." in any place or places in the chain.  If your
> program gives you strong enough guarantees, it is the sort of thing you can
> use to reduce the code's workload.
>
> By way of example, I was working on some C code last night that was
> expanding an internal buffer, possibly from non-existence.  It did lot of
> taking the difference between various pointers to determine how big the new
> buffer needed to be, how much to copy from the old buffer, etc. 

Re: [Python-ideas] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Robert Vanden Eynde]

Shortcuts designed for CLI are just to "be more mnemonic" have to be considered 
with caution.
If gettext is a package, it means the whole python community shoud agree on 
that.
msgfmt is part of gettext, so yes, python -m gettest.msgfmt is the best long 
lasting command. Or it could be 'python -m gettest msgfmt'.
If you're using CLI, 90% of chances you know that if you don't like "python -m 
gettest.msgfmt" because it's too long, you can add a `alias dotrans='python -m 
gettest.msgfmt'` in your .bashrc so that you can simply write "dotrans 
Something".
___
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] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Robert Vanden Eynde]

Shortcuts designed for CLI are just to "be more mnemonic" have to be considered 
with caution.
If gettext is a package, it means the whole python community shoud agree on 
that.
msgfmt is part of gettext, so yes, python -m gettest.msgfmt is the best long 
lasting command. Or it could be 'python -m gettest msgfmt'.
If you're using CLI, 90% of chances you know that if you don't like "python -m 
gettest.msgfmt" because it's too long, you can add a `alias dotrans='python -m 
gettest.msgfmt'` in your .bashrc so that you can simply write "dotrans 
Something".
___
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] Redefining method

[Jonathan Fine]

Hi Jamesie

Thank you for your question. You asked why not
> c = MyClass
> o = c()
>
> def c.foo(cls): ...
> def o.bar(self): ...

I've the same same query, but never had the courage to ask. So that
you for asking. And also giving me a chance to share my thoughts.

In Ruby, I believe, you can 'open up' an existing class, and add new
methods to it. You can even do with core classes. I think what you
asking might amount to a wish to do the same in Python.

I think the Python way to 'open up' an existing class is to create a
subclass, and add methods to that. Python design and development is
quite pragmatic. So instead of us saying why it's not there, why don't
you tell why you think it might be good idea. Based of course on
examples. Particularly code taken from successful real-world
applications.

By the way, your
>>> def o.var(self): ...
won't work as you expect. To get a bound method, the method must be an
attribute of the class (in other words type(o)) of the object o.
That's the way Python is. What you've written does work in JavaScript.

It's perhaps a bit technical and short of examples, but
https://docs.python.org/3/reference/datamodel.html would be a good
starting point. Can anyone else recommend some other URLs for this.

Once again, thank you for asking this question. I look forward to
reading other answers (and of course your response).

-- 
Jonathan
___
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] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Nick Timkovich]

On Mon, Jul 30, 2018 at 8:43 AM, Petr Viktorin  wrote:

> On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok  wrote:
>
> > It might be:
> >
> >   $ python3 -m gettext
>
> +1
>
> > And:
> >
> >   $ python3 -m gettext.msgfmt
>
> +1
> Note that this means gettext will need to become a package.
>
> > And (provided as a shortcut):
> >
> >   $ python3 -m msgfmt
>
> -1. This would mean adding a new top-level module to the standard
> library. Let's not pollute that namespace just to provide a shortcut.


Speaking of shortcuts, is there a reason that it should be "python -m
json.tool" versus "python -m json" (keep the old probably forever, but have
the shorter as a synonym)?

And as a broader question, is there opposition to generating patches to
make packages executable that may be useful as a CLI? Would be nice if the
UUID or random modules could directly spit something out, e.g. "python -m
uuid -4". Counterargument that you could "python -c "import
uuid;print(uuid.uuid4())".

Nick
___
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] Redefining method

[Jamesie Pic]

Hi all,

Not sure if this subject has been brought up already, but why can't we
redefine methods as such for example:

c = MyClass
o = c()

def c.foo(cls): ...
def o.bar(self): ...

Thanks in advance for sharing some of your insight

-- 
∞
___
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] PEP 505: None-aware operators

[Rhodri James]

On 29/07/18 16:12, Abe Dillon wrote:

spam?.eggs.cheese.aardvark  # why would you ever do this?


If you knew that if you really have something in "spam", your program 
guarantees it will have an "eggs" attribute with a "cheese" attribute, 
etc, you just don't know if "spam" is not None.  It's the same insider 
knowledge you would use if you wrote it out as


spam.eggs.cheese.aardvark if spam is not None else None

The same sort of knowledge of your program structure could lead to you 
to use "?." instead of "." in any place or places in the chain.  If your 
program gives you strong enough guarantees, it is the sort of thing you 
can use to reduce the code's workload.


By way of example, I was working on some C code last night that was 
expanding an internal buffer, possibly from non-existence.  It did lot 
of taking the difference between various pointers to determine how big 
the new buffer needed to be, how much to copy from the old buffer, etc. 
It looked rather hairy until you realised that the code gave a strong 
guarantee that either all the pointers were meaningful or they were all 
NULL, so the pointer differences always made sense.  I rewrote that code 
so that it didn't take differences of NULL pointers since that was what 
the bug specified, but honestly it looks lumpier and less clear now.  A 
big comment explaining what was going on would probably be better.


--
Rhodri James *-* Kynesim Ltd
___
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] PEP 505: None-aware operators

[Rhodri James]

On 28/07/18 21:07, Abe Dillon wrote:
[>> = Me]

We could argue about how intuitive or not these operators are, but they
are used in other languages, so they clearly aren't completely unintuitive.


Other languages are other languages. Other languages use the " ?
 : " form of the the ternary operator. That doesn't mean we
should adopt that into Python.


But it does and did mean that we should consider it when coming up with 
Python's version of the ternary operator.  *It isn't unintuitive* and 
neither is ??  None-aware operators may be bad for other reasons, but 
that argument doesn't wash.



Really?  Quick straw poll: how often do people care how in-place operators
are implemented?


The point I was trying to make is that it doesn't behave or compose like
other expressions.


(This was about ??=, for context.)  Pardon?  It composes exactly like 
any other in-place operator.


[Abe previously wrote:]
>>> val = person[0]?
>>> val = person.name?
>>

Um.  How is that supposed to parse?  "person[0]" has already been evaluated
by the time the "?" operator gets anywhere near it.


It parses by placing the '?' operator high in the order of operations; like
I said. Do I really need to explain how order of operations works?


Apology elsewhere accepted, but yes, you do need to explain how merely 
being high precedence helps here.  Let's start small; please explain 
programmatically what


  name?

does as an expression.  Once we have that down, we can move on to

  person.(name?)

(parentheses for emphasis.)  Short of actual magic, I can't see how this 
is going to work.


--
Rhodri James *-* Kynesim Ltd
___
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] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Petr Viktorin]

On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok  wrote:
> Currently, the documentation (as well as plenty of other places on the
> Internet, such as Stack Overflow answers) mentions msgfmt.py and
> pygettext.py.
>
> See https://docs.python.org/3/library/gettext.html
>
>> (Python also includes pure-Python versions of these programs, called
>> pygettext.py and msgfmt.py; some Python distributions will install
>> them for you. pygettext.py is similar to xgettext, but only
>> understands Python source code and cannot handle other programming
>> languages such as C or C++. pygettext.py supports a command-line
>> interface similar to xgettext; for details on its use, run
>> pygettext.py --help. msgfmt.py is binary compatible with GNU msgfmt.
>> With these two programs, you may not need the GNU gettext package to
>> internationalize your Python applications.)
>
> The problematic part is: "some Python distributions will install them for
> you"
>
> As a Python distributor, I may ask myself a question: Where do I install
> those?
>
> As a Python user, I may ask: Where did the distributors put them, and did
> they?
>
> So I suggest we make those modules instead and we document how to use them.

Not completely "instead" perhaps; the original Tools/i18n/*.py scripts
can be changed to just import the new module and call it.

> It might be:
>
>   $ python3 -m gettext

+1

> And:
>
>   $ python3 -m gettext.msgfmt

+1
Note that this means gettext will need to become a package.

> And (provided as a shortcut):
>
>   $ python3 -m msgfmt

-1. This would mean adding a new top-level module to the standard
library. Let's not pollute that namespace just to provide a shortcut.

>
> I feel that using -m is the general direction Python is going, considering
> this message:
>
>   $ pyvenv ...
>   WARNING: the pyenv script is deprecated in favour of `python3.7 -m venv`
>
> It also gives the user a choice for Python version on a system with multiple
> Python versions installed as the user could do:
>
>   $ python3.6 -m gettext
>
> Or
>
>   $ python3.7 -m gettext
>
> While with e.g. /usr/bin/pygettext.py this adds unnecessary burden on the
> distributor to package /usr/bin/pygettext-3.7.py etc...

Yes – pygettext depends on the Python version, so being able to do
this sounds very useful. Less so for msgfmt of course.

I'm adding Barry Warsaw, who originally wrote pygettext and AFAIK
still does i18n in Python.
Barry, does this sound reasonable to you?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/