gmane.comp.python.ideas

Re: Python3 Multitasking

Andrew Barnert — 2013-05-25T22:10:35




& already has a meaning, as an operator. This would be confusing to both human readers and the parser.



This one is fine—and you can do it trivially today:

    import multiprocessing
    jobs = []
    def multitask(command):
        jobs.append(multiprocessing.Process(command))

And you're done.

If you want to limit the number of running processes, or use a pool instead of a process per task, or use threads instead of processes, or name the jobs and store them in a dict, or whatever, you can change the multitask function.
_______________________________________________
Python-ideas mailing list
Python-ideas< at >python.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: Python3 Multitasking

Terry Jan Reedy — 2013-05-25T14:17:11

Last I knew, that makes a separate process in sh and csh. Has that 
changed, or is bash different?



Check out the threading, multiprocessing, and subprocess modules.

Python3 Multitasking

Devyn Collier Johnson — 2013-05-25T13:49:03

It may benefit many programmers if Python3 code could be multithreaded 
as easy as BASH code. For example, in BASH, if I wish to multithread a 
command, I put an ampersand at the end of the line. Then, the BASH 
interpreter will execute that line while continuing the execution of the 
script instead of waiting to finish that command. For Python3, I have 
two ideas for how the Python3 multitasking syntax should look.

Option 1: SOME_COMMAND &

Option 2: multitask(SOME_COMMAND)

Thank you,

Devyn Collier Johnson
DevynCJohnson-o4GsF6Y0fuwAvxtiuMwx3w< at >public.gmane.org
_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: New str whitespace cleaning method?

Greg Ewing — 2013-05-25T01:49:57

 >
 > if format_output:
 >     print ("""\
 >                  1)
 >                        Indent *only* the first line
 >                     of a  paragraph,
 >                  2)
 >                     Have pretty-formatted numbered
 >                     lists
 >                  independent of the code indentation level.""".ltrim(16))

This makes it abundantly unclear how much is being
stripped without a close study of the code and then
carefully counting whitespace characters, being sure
to count tabs as one character.

Also, if you change the indentation level of the code, you
have to change the embedded numeric literal to match or
it breaks.

I'd prefer some kind of dedented-string-literal syntax
that explicitly marks how much to trim from each line,
e.g.

    print(d"""This text has no
       |   whitespace at the beginning of any
       |line except the second one,
       |which begins with 3 spaces.""")

This would be clear to read and easy to edit.

Re: New str whitespace cleaning method?

Ron Adam — 2013-05-25T00:04:30


On 05/24/2013 04:46 PM, Jim Jewett wrote:

I don't care for dedent, (even with the 'd' prefix syntax.)  It only covers 
about 20% of the use cases that I care about.  Which is why I generally 
don't bother using it.

A much more useful alternative is to have a margin() method on strings that 
will take a width argument and works independent of the indent level the 
expression.  It's not a dedent, or indent, or maybe it's both. ;-)


     message = """\
         A simple paragraph
         of several
         lines.
         """.margin(2)

   A simple paragraph
   of several
   lines.


     message = """\
         A simple paragraph
         of several
         lines.
         """.margin(16)

                 A simple paragraph
                 of several
                 lines.


A margin method covers 90 percent of times I think about using dedent, and 
is geared more towards what I really need in those cases.


A margin of 0, gives us the dedent use.

     message = """\
         A simple paragraph
         of several
         lines.
         """.margin(0)

A simple paragraph
of several
lines.


And calling a margin() method multiple times gives predictable results.


You could use textwraps TextWrapper class with it's initial_indent() and 
subsequent_indent(), along with dedent() to do the same things as above. 
But it's a lot of work for simple cases like these.

Cheers,
     Ron

Re: New str whitespace cleaning method?

Jim Jewett — 2013-05-24T21:46:52

On Fri, May 24, 2013 at 4:06 PM, Wolfgang Maier
<wolfgang.maier-CrNPMedtCwE0K98s81L2pkLpcGqEmw7l< at >public.gmane.org> wrote:

Not really, but the new-prefix solution (d""" ... """) is a moral equivalent.


I think most use cases treat either all lines or all lines but the
first as a block.
If the 4th line is indented relative to the 3rd, that is probably intentional.

Note that doctests solve a related problem by adding a prefix (">>> "
or "... ") that effectively increases the indent further.

-jJ

Re: New str whitespace cleaning method?

Wolfgang Maier — 2013-05-24T20:06:07

One clean solution might be (now don't shout at me. I know it would be a
profound change with lots of compatibility problems, and its just a wild
thought that I'm not advocating for):
Triple-quoted strings could be made a subclass of str, and their formatting
methods (at least strip, lstrip, ljust, rjust) could overwrite those of str
to operate on a per-line basis, e.g., strip() and lstrip() could remove
whitespace from the end and the beginning of each line.

Re: New str whitespace cleaning method?

Wolfgang Maier — 2013-05-24T19:47:06


I guess the problem is not that nobody has a need for it, but rather that
there are many different types of behaviour of that formatting method that
one could imagine. You gave a few examples yourself and, personally, I'd
prefer that method to remove a fixed specified number of spaces from the
beginning of each line, so that you could do things like:

if format_output:
    print ("""\
                 1)
                       Indent *only* the first line
                    of a  paragraph,
                 2)
                    Have pretty-formatted numbered
                    lists  
                 independent of the code indentation level.""".ltrim(16))

I think, it's easy enough to come up with solutions to everybodies
preferences, but that doesn't mean that they have to be built into python.
Best,
Wolfgang

Re: New str whitespace cleaning method?

Andrew Barnert — 2013-05-24T19:07:27

How is one import statement "arbitrary lengths of boilerplate"?

How is putting the batteries into the stdlib instead of the language not pythonic?

Sent from a random iPhone

On May 24, 2013, at 11:03, "Joao S. O. Bueno" <jsbueno-+ZN9ApsXKcENxz+GHXMZdQ< at >public.gmane.org> wrote:

Re: New str whitespace cleaning method?

Joao S. O. Bueno — 2013-05-24T18:03:23

Come on - this is Python, and we are talking about entering a string in code -
One doe snto want to do a "from myutils.stringutils import dedenter"
just to be able
to use long strings in code. - in other languages it might be normal to
go to arbtirary leenghts of boiler plate code to do trivial stuff.

But ..seeing the attention here, I guess I am indeed one of the 2 programmers
in the World who needs long strings with no white-space from indentation
in code and consider it should be part of the syntax, not a
possibility on the stdlib,
so..whatever.  :-/




On 24 May 2013 14:52, Wolfgang Maier
<wolfgang.maier-CrNPMedtCwE0K98s81L2pkLpcGqEmw7l< at >public.gmane.org> wrote:

Re: New str whitespace cleaning method?

Wolfgang Maier — 2013-05-24T17:52:39


ok, here's example code for it:

from textwrap import dedent

class dedentify(object):
    def __init__ (self, f):
        self.f = f
        
    def __call__ (self, message):
        self.f(dedent(message))

< at >dedentify
def warn (message):
print (message)

warn("""\
            Hello dear sir,
            I am sorry to inform you
            the spanish inquisition
            has arrived""")

now prints:
Hello dear sir,
I am sorry to inform you
the spanish inquisition
has arrived

I hope this is what you had in mind ?
Wolfgang

Re: New str whitespace cleaning method?

Wolfgang Maier — 2013-05-24T17:38:25

this is a

Haven't really thought that through, but couldn't you write a decorator that
does the dedenting, and that you then use on your warn()?
This way, you wouldn't have to care about the formatting at all in your
actual code.
Best,
Wolfgang

Re: A posteriori implementation of an abstract method

Jim Jewett — 2013-05-24T16:02:47

Good!

Readability is very important; separating related logic is a bad idea.

There may be times when patching something is the least of evils, but
it certainly shouldn't be encouraged.


At this point, either C itself is also intended as abstract-only, or
there is already an error.



Much better to just create a new subclass of C.

If that isn't isn't possible, then I suppose you do have to update
__abstractmethods__.

I usually write my "abstract" methods to either just pass (implement
it if you want something to happen; safe to ignore it otherwise) or to
return NotImplemented.  The authors of ABC have gone out of their way
to say "You MUST implement this."  So requiring an extra "yes, I
really meant that" step for code that violates the contract is not
unreasonable.


It would work, but I don't think it would be a good idea.

(1)  What if the new implementation is still only a partial
implementation, to used by super?  Then the class *should* stay
abstract.

(2)  Even if the new implementation of that method resolved the only
enforced barrier, it still isn't clear that the class should change
type.

There are reasons to say "this class will never be instantiated".
Removing that invariant is important enough that it should be an
explicit choice, instead of an implicit side effect.

-jJ

A posteriori implementation of an abstract method

Antony Lee — 2013-05-24T02:10:50

Currently, the implementation of abstract methods is not possible outside
of the class statement:

from abc import ABCMeta, abstractmethod
class ABC(metaclass=ABCMeta):
    < at >abstractmethod
    def method(self): pass
class C(ABC): pass
C.method = lambda self: "actual implementation"
C()

results in a TypeError (complaining about abstract methods), as
__abstractmethods__ is just computed once, at class definition.

Of course this example is a bit contrived, but perhaps a more legitimate
use case would involve a class decorator or another way to define the
implementation of the abstract methods out of the class, such as

< at >implementation(C, ABC)
def method():
    return "actual implementation"

I believe this behavior can be "fixed" (well, I don't know yet if this
should actually be considered an error, and haven't actually tried to "fix"
it) by defining ABCMeta.__setattr__ properly (to update __abstractmethods__
when necessary).  What do you think?

Best,
Antony
_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: Let's be more orderly!

Terry Jan Reedy — 2013-05-23T21:06:09

Guido has more or less rejected annotations because checking for an 
anotation would slow down every function call for the benefit of very few.


Returning a function with a custom ordered kwargs .__call__ method would 
not affect normal functions. func.__class__ cannot be changed from 
Python code (non-heap type) but I don't know about from C. In any case, 
the attributes (components) of func could be fed to an okw_function 
(ordered keyword function) class to produce an new object.

The decorator approach immediately fails for a system without the 
decorator. Since it should only be used for funcs that require the 
ordering, I think that would be appropriate.

tjr

Re: Let's be more orderly!

Haoyi Li — 2013-05-23T16:36:47

This seems like the perfect use case for function annotations, or a
decorator. I imagine both cases would look rather pretty

def func(**kwargs: ordered):
    ...

< at >ordered_kwargs
def func(**kwargs):
    ...

I'm not sure if this is a bad idea for other reasons (e.g.
decorators/annotations being reserved for library code rather than core
language features) but it does look right intuitively: you are annotating
the function or the kwarg to change it's behavior.

Here's another thought: macros <https://github.com/lihaoyi/macropy> would
be able to pretty trivially give you a syntax like:

OrderedDict([('a', 1), ('b', 2)])
OrderedDict([('b', 2), ('a', 1)])

or

OrderedDict([('a', 1), ('b', 2)])
OrderedDict([('b', 2), ('a', 1)])

for ordered dict literals. It wouldn't work for generally adding
orderliness to other functions, since the macro won't know which bindings
are named arguments and which bindings are **kwargs, but it also looks
really pretty. Probably not something you'd want to put in the std lib, but
it's fun if you want to try out the syntax in your own projects.

-Haoyi


On Tue, May 21, 2013 at 12:40 PM, Andrew Barnert <abarnert-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org> wrote:

_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: Line continuations with comments

Ron Adam — 2013-05-22T23:15:59


On 05/22/2013 11:02 AM, Bruce Leban wrote:

There was one found in pythons own library recently where a missing comma 
caused an unintentional implicit concatenation.  It's fixed now, but it's 
not clear how long it's been there.


Agree on all counts.


I agree here too.

I'm still looking for the location in pythons source code where adjacent 
strings are joined.  The docs say this ...

-----------
Note that this feature is defined at the syntactical level, but implemented 
at compile time. The ‘+’ operator must be used to concatenate string 
expressions at run time. Also note that literal concatenation can use 
different quoting styles for each component (even mixing raw strings and 
triple quoted strings).
-----------

I haven't found either the syntactic definition, or the compile time 
implementation yet.  <shrug?>



 >However, it's pointless to bikeshed the choice

It seems the consensus may be dependent on what the syntax might be.



Yes, But just don't do that.  ;-)


And don't do this either. (works now)

     foo \
     = \
     bar + \
      \
     3

Or this. (also works now)

     foo = (
     (bar + (
     (
     3))
     )
     )


I'm not sure why some people dislike the back slash so much as a 
continuation tool.  Python is the language that avoids using {braces around 
blocks}, so you'd think it would be the other way around.

I really don't think the '\' will be over used.  New programmers do try a 
lot of strange things at first for making their own programs easier to 
read, (I did), but usually they come around to what the community practices 
and recommends.



My preference is to allow any number of spaces before and after the '\'. 
and that any comments after the slash not change what it means.

A built in single space rule would probably frustrate people who don't want 
to do it that way.  Like how you get a character after a continuation 
error, even if it's only a single space.  Yeah, it's how it works, but it's 
still annoying to get that error in that situation.

A comment of course, would still uses up the rest of the line. So a '\' 
after '#' is just part of the comment.


Cheers,
    Ron

Re: Line continuations with comments

Chris Angelico — 2013-05-22T16:08:58

Maybe the backslash should be considered on par with goto - some use
it occasionally and reckon it's vital, others never use it and
consider it superfluous. It's not (usually) a problem to have it in
the language, it's not deprecated, but style guides advise against its
use.

ChrisA

Re: Line continuations with comments

Andrew Barnert — 2013-05-22T16:05:10


Well, you can always break within each expression, adding extra parens within the expression if necessary.

But often, this looks even worse than backslashes.

    with closing(NSWhyDoesAppleUseSuchLongNames(
    NSLongNamedConstant)) as thing1, closing(
    NSAnotherLongFunction(
        NSAnotherLongConstant)) as thing2

I may have got this wrong because I'm typing on a phone, but you get the idea. This is legal, and it follows PEP8, and it doesn't require a backslash. But it's horrible.

Another alternative is to bind all those silly PyObjC names to shorter names--but then, when you're reading the code, you can't immediately tell what it does. 

I don't _always_ have to use backslashes in code using ridiculous names like this to make it readable, but sometimes they are the best solution.

So, even though I don't know that they're _necessary_, I still don't want backslashes deprecated.

But I also don't want them expanded.

Re: Line continuations with comments

Bruce Leban — 2013-05-22T16:02:16

Your last statement seems to be missing the point of the larger discussion.
Yes, parenthesis can be used in most cases where someone might use \
continuation. There seems to be strong sentiment to *not* remove \
continuation. Given that, is allowing comments after a continuation a
reasonable change? I think so.

Notwithstanding that, these discussions are moving away from Guido's
original comment about being bitten by implicit continuation of strings and
not moving towards consensus. Let me throw in a few facts:

1) There are bugs caused by unintended implicit string concatenation.
2) Using + as it exists now is not a drop-in replacement for implicit
string concatenation as it is a run-time operation and has a different
precedence than the implicit concatenation.
3) There are programs that use implicit string concatenation that will need
to be fixed if the feature is removed.
4) There are programs that use \ continuation that will need to be fixed if
the feature is removed.
5) Explicit is better than implicit.

Personally, I would endorse deprecating and eventually removing implicit
string concatenation and adding a syntax (not an operator) for explicit
run-time string concatenation. The use of \ continuation as that syntax
seems to me like a reasonable choice if we assume that this feature isn't
going away. In particular, it works today so it's easy to start using it
and linters can look for it. However, it's pointless to bikeshed the choice
of syntax if there's no consensus that there should be an explicit syntax
in the first place.


On Tue, May 21, 2013 at 9:13 PM, Ron Adam <ron3200-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Aside from serving as a marker for explicit string concatenation, this
means that I can freely sprinkle in backslashes anywhere I want, like this:

    foo \ = \ bar + \ \ 3

That seems like a bad idea.



Whether we require there be no space between \ and # or, conversely,
require there be at least one whitespace character should not be based on
the relative ease of patching the current code. Personally, I would prefer
the latter as I believe requiring a space after \ will increase readability.


--- Bruce
Latest blog post: Alice's Puzzle Page http://www.vroospeak.com
Learn how hackers think: http://j.mp/gruyere-security
_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: Line continuations with comments

2013-05-22T14:54:02

Someone pointed out an example a while back of them being necessary
(except for being vacuously unnecessary because you can just make an
arbitrarily long physical line): multiple values in a with statement.