Re: Invalid Syntax

[cs]

On 09Aug2016 20:22, Rob Gaddi  wrote:

Ltc Hotspot wrote:

What is the source of the following,
'error message: SyntaxError: invalid syntax (, line 2)'
v. Python 3.3

Code reads:

x=1
if x==1
# indent 4 spaces
print "x = 1"


A missing colon, the appropriate location of which is left as an
exercise to the reader.


A bit unfair, it is not the most helpful of syntax complaints. Hal: all Python 
compound statements (if, while, for, with etc) end in a colon and an indented 
"suite" (enclosed chunk of statements). So:


 if x == 1:
 ..

Also, in Python 3 "print" is a function, so:

 print("x = 1")

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Two-Dimensional Expression Layout

[cs]

On 19Aug2016 16:11, Lawrence D’Oliveiro  wrote:

On Saturday, August 20, 2016 at 10:38:34 AM UTC+12, Chris Angelico wrote:

On Sat, Aug 20, 2016 at 8:31 AM, Lawrence D’Oliveiro wrote:

There is no short-cut evaluation when constructing tuples and lists.


I'm not sure how that would make difference in these examples. The
three parts are independent - the one place where short-circuiting is
important is indeed short-circuited.


That often is not the case, e.g. 
:

   assert \
   (
   len(self.points) == 0
   or
   not self.points[0].off
   and
   (closed or not self.points[-1].off)
   )


Aye, but beware that the expression is actually correct for the indentation.  
Compare:


  assert \
  (
  len(self.points) == 0
  and
  not self.points[0].off
  or
  (closed or not self.points[-1].off)

where the precedence causes the layout to mislead.

I'm not arguing against indented spread out layout here, I use it myself, but 
just mentioning that the human eye will tend to take the visual layout over a 
strict parse. So care is needed, as in all programming.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Is duck-typing misnamed?

[cs]

On 26Aug2016 19:58, ROGER GRAYDON CHRISTMAN  wrote:

"If it walks like a duck, quacks like a duck,... "
so there is indeed precedence for this so-called 'duck typing'

but wouldn't it be more Pythonic to call this 'witch typing'?
"How do you know she is a witch?"
"She looks like one."
etc.

I do grant that ultimately, the duck does come into play, since the witch
weighs the same as a duck.


I disagree. They want to burn her because she's supposedly a witch, but the 
scientific test was that she weighed as much as a duck. So I think your second 
example is also duck typing: functioning like a duck.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: manually sorting images?

[cs]

On 05Sep2016 10:09, Greg Ewing  wrote:

Quivis wrote:
2. You want to sort them according to red houses, blue houses, green 
trees, yellow trees (that's autumn leaves), cats, dogs, children, 
elderly people,


But... but... what if you have a picture of a child
playing with a dog that's chasing an elderly cat up a
yellow tree in front of a blue house? What category do
you put it in?

The algorithm has been insufficiently specified!


Yeah. Sounds like he wants a tool that lets him associate tags with images.  
Then he can tag all the photos with all the relevant attributes, then write his 
own classifier/sorted later by examining the tags.


I also suspect the OP is using the word "sort" to mean "classify" (eg "what 
sort of thing is this?") versus is more common programming meaning of 
"ordering".  Would be good to clarify that.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Using sudo with pip3?

[cs]

On 06Jan2017 15:44, jim  wrote:
Setting up a new computer to run Ubuntu 16.04. Started using pip3 to 
install all the python stuff I had on the old machine and got this 
message:


jfb@jims-1604:~$ sudo pip3 install matplotlib
[sudo] password for jfb:
The directory '/home/jfb/.cache/pip/http' or its parent directory is 
not owned by the current user and the cache has been disabled. Please 
check the permissions and owner of that directory. If executing pip 
with sudo, you may want sudo's -H flag.


I (jfb) own the directory in question.

I used sudo because I recall needing to use it on the old machine to 
get something to install. So is it necessary or even desirable to use sudo 
with pip3?


I would not, unless I were specificly trying to install into the system's 
python3 libraries. That will inherently fight with any vendor (Unbuntu) 
supplied packages that come through apt-get.


Instead I would make myself a virtualenv _based off the system python3_ and use 
the venv's pip to install extra packages. Not using sudo. They will land in 
your virtualenv directory's lib area, be entirely owned and controlled by you, 
and not have any complications that come with sudo.


Then just symlink the virtualenv's "python3" into your own $HOME/bin and 
whenever you invoke "python3" it will run the virtualenv one, getting all the 
package goodness you have added.


An important sysadmin rule of thumb: use apt (or yum etc, depending on distro) 
as root to install vendor supplied packages. And install your owon packages _as 
you_ in another area, _not_ in the system managed area. Virtualenv makes this 
very easy to do for Python.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: sys.exit(1) vs raise SystemExit vs raise

[cs]

On 12Apr2016 18:20, Ganesh Pal  wrote:

I m on python 2.7 and Linux ,  I have a simple code  need suggestion if  I
I could replace sys.exit(1) with raise  SystemExit .

==Actual code==

def main():
   try:
   create_logdir()
   create_dataset()
   unittest.main()
   except Exception as e:
   logging.exception(e)
   sys.exit(EXIT_STATUS_ERROR)

if __name__ == '__main__':
   main()

==Changed Code==


def main():
   try:
   create_logdir()
   create_dataset()
   unittest.main()
   except Exception as e:
   logging.exception(e)
   raise SystemExit

if __name__ == '__main__':
   main()


I am against both of these personally. My preferred pattern is like this:

 def main(argv):
   try:
 ...
   except Exception as e:
 logging.exception(e)
 return 1

 if __name__ == '__main__':
   sys.exit(main(sys.argv))

Notice that main() is back to being a normal function with normal returns.

Also, most of us would avoid the "except Exception" and just let a top level 
except bubble out: that way you get a stack backtrace for debugging. I agree it 
prevents logging the exception and makes for uglier console output, but I think 
it is a win. And if you _do_ want to log the exception there is always this:


 try:
   ...
 except Exception as e:
   logging.exception(e)
   raise

to recite the exception into the log and still let it bubble out normally.

The problem with the "except Exception" pattern is that it catches and _hides_ 
_every_ exception, not merely the narrow set of specific exceptions that you 
understand.


Finally, it is frowned upon to raise a bare Exception class. In  python 3 I 
believe it is actually forbidden, so it is nonportable anyway. But even In 
Python to it is best to supply an Exception instance, not the class:


 raise SystemExit(1)


2. All the functions in try block have exception bubbled out using raise

  Example for create_logdir() here is the function definition

def create_logdir():

   try:
   os.makedirs(LOG_DIR)
   except OSError as e:
   sys.stderr.write("Failed to create log directory...Exiting !!!")
   raise
   print "log file: " + corrupt_log
   return True

def main():
   try:
   create_logdir()
   except Exception as e:
   logging.exception(e)
   raise SystemExit

(a) In case if create_logdir() fails we will get the below error ,is
this fine or do I need to improve this code.

Failed to create log directory...Exiting !!!ERROR:root:[Errno 17] File
exists: '/var/log/dummy'

Traceback (most recent call last):
 File "corrupt_test.py", line 245, in main
   create_logdir()
 File "corrupt_test.py", line 53, in create_logdir
   os.makedirs(LOG_DIR)
 File "/usr/local/lib/python2.7/os.py", line 157, in makedirs
OSError: [Errno 17] File exists: '/var/log/dummy'


I prefer the bubble out approach, perhap with a log or warning messages as you 
have done, eg:


 logging.exception("create_logdir failed: makedirs(%r): %s" % (LOG_DIR, e))
 raise

(Also not that that log message records more context: context is very useful 
when debugging problems.)


For very small scripts sys.stderr.write is ok, but in general any of your 
functions that turned out to be generally useful might migrate into a library 
in order to be reused; consider that stderr is not always the place for 
messages; instead reading for the logging module with error() or wanr() or 
exception() as appropriate. There is more scope for configuring where the 
output goes that way without wiring it into your inner functions.



3. Can I have just raise , instead of SystemExit or sys.exit(1) . This
looks wrong to me

 def main():

   try:
   create_logdir()
   except Exception as e
   logging.exception(e)
   raise


This is what I would do, myself.

Think: has the exception been "handled", meaning has the situation been dealt 
with because it was expected? If not, let the exception bubble out so that the 
user knows that something _not_ understood by the program has occurred.


Finally, it is generally bad to SystemExit or sys.exit() from inside anything 
other than the outermost main() function. And I resist it even there; the main 
function, if written well, may often be called from somewhere else usefully, 
and that makes it effectively a library function (it has been reused). Such a 
function should not unilaterally abort the program. How rude! Instead, let the 
exception bubble out: perhaps the _caller_ of main() expects it and can handle 
it. By aborting and not "raise"ing, you have deprived the caller of the chance 
to do something appropriate, even though you yourself (i.e. "main") do not know 
enough context to handle the exception.


So I am for "raise" myself. And then only because you want to log the error. If 
you didn't want to log the exception you could avoid the try/except _entirely_ 
and have simpler code: let the caller worry about unhandled exceptions!


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-lis

Re: What should Python apps do when asked to show help?

[cs]

On 30Apr2016 13:23, Steven D'Aprano  wrote:

On Sat, 30 Apr 2016 12:49 pm, Ben Finney wrote:

Random832  writes:

On Fri, Apr 29, 2016, at 22:27, Rustom Mody wrote:
> Instead it does some ½-assed fall-between-the-stools of both

That doesn't answer the question of why, if you (Well, Ethan, but
you're taking the same position here) hate pagers so much


That's not a question relevant here; nobody inthe discussion has a
position fairly characterised as “hate pagers so much”. So you're
arguing against a straw man.

Rather, the position being argued is that they *do* like pagers; they
like pagers enough that they want the existing ‘PAGER’ environment
variable setting to remain untouched.


So they want the PAGER environment variable to specify what pager they
want...


_When_ they want a pager.


And, simulatenously, they want
Python's help to not use a pager at the interactive prompt.


...so long as applications don't actually make use of that PAGER environment
variable to determine the pager they want to use.


_When_ it is asked to use a pager.

What they (and, very often, me) want is that most things, including pydoc, to 
_NOT_ invoke a pager automatically, _unasked_.


So tools which page without asking are unwelcome, because that requires a mode 
switch when everything else (sed/grep/print/write/ls) do straight up unpaged 
output.



(1) If you want man, and nothing else in the universe, to automatically use
a pager, then set MANPAGER="less" (or whatever you wish to use), and unset
PAGER.

(2) If you don't want *anything* to use a pager, then unset both MANPAGER
and PAGER. You may have to report a feature request / bug report for
applications which force their own pager.

(3) In Python specifically, you can trivially and easily tell help() to
output directly to stdout. (At least on Linux, I haven't tested it
elsewhere.) Simply use PAGER=cat on the command line you use to launch the
interactive environment. This will affect no other running or future
processes (apart from subprocesses launched from your interactive Python
session), allowing you to keep your PAGER for everything else.

(4) If you want more than that, then patches are welcome :-)


This requires terrible domain specific knowledge. What about programs other 
than man?


And setting PAGER=cat before invoking interactive python is no better, because 
it will screw with $PAGER in any subprocess spawned from that environment.


What those of use in the "my terminal emulator scrolls nicely thank you" camp 
want is that most command line things, when asked to simply print some help 
text, _print_ it and do not page it. And often would like a way to tell pydoc 
to not page, such as a pydoc specific switch (possibly an environment 
variable).



Seriously, I'm thinking that a keyword argument to help might be useful:

help(object, pager=None)

where:
- pager=None gives the current behaviour;
- pager="foo" calls out to the external program "foo";
- pager=callable passes the help text to callable().


I'd be asking for pager=None to look at help.default_pager, which itself might 
obey your rules above. That way help.default_pager can be a callable which 
consults $PAGER or falls back to some inbuilt pager (presumably as now), but 
which a user can sumply go:


 help.default_pager=None

at the Python prompt and have unpaged output from there on.


I think that would make it easier to test help(). Thoughts?


Yes it would. I'm +1 _provided_ the user can set a global to tune the default 
mode, as otherwise it burdens the user with saying:


 help(foo, stdout.write)   # or "print" ?

whenever they want help. Not helpful!

Let me recite one of my favourite rules of thumb:

 If it can't be turned off, it's not a feature. - Karl Heuer

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What should Python apps do when asked to show help?

[cs]

On 29Apr2016 11:40, Steven D'Aprano  wrote:

On Fri, 29 Apr 2016 07:08 am, Grant Edwards wrote:

On 2016-04-28, Random832  wrote:

On Thu, Apr 28, 2016, at 15:39, Grant Edwards wrote:

That's fine.  If you want two or three forms of documentation then you
prepare two or three forms of documentation.

Adding an option to run the default 'help' output through a pager or
display it in a web browser doesn't somehow force you "to compose two
forms of documentation" unless you want two forms of documentation.


The point is that having "help" output at all (beyond either a cursory
"see the manpage") implies two forms of documentation (given you already
have a manpage), and some people choose not to do that, instead
launching directly into the manpage (which implies using a pager)


But I'm saying that having --help output the manpage should not imply
using a pager.



What manpage? I don't have a manpage. The only help my application has is
whatever it outputs (which it gets from its docstring).

What is a good place where I can find out more about writing manpages?


"man 5 man"? Describes the internal format of man pages (the [ntg]roff -man 
macro set). Many people use an intermediate more human friendly format and use 
a tool to transcribe -man format text. For standalone things I find Perl's 
"POD" format fairly easy to use (the pod2man tool itself does have shortcomings 
though).



If --help is going to output the manpage, then I'm saying it can (and
should) be written to stdout without use of pager (and it shouldn't
have escape sequences or backspaces in it either).  The Unix way is
that the output from whatever --help should be plain text written to
stdout (regardless of length).


Agree. The -h/--help option will output plain text to stdout.


Yay.


If you want to output the man page, this can be accomplished simply by
doing someting like:
  os.environ["GROFF_NO_SGR"] = "1";
  os.system("man -Tascii mycmd | col -bx");


That doesn't work for me:
[steve@ando ~]$ man -Tasciii rm
man: invalid option -- T


Yes, it is nonportable. Presumes groff possibly, and GNU "man".


However, this almost works:

man -Pcat rm

appears to output unformatted, plain text to stdout.


As should:

 man rm | cat

without obscure options.


However, if you capture
the output (say, to a file) you'll see it is full of backspaces, e.g.:

N^HNA^HAM^HME^HE
  rm - remove files or directories

S^HSY^HYN^HNO^HOP^HPS^HSI^HIS^HS
  r^Hrm^Hm [_^HO_^HP_^HT_^HI_^HO_^HN]... _^HF_^HI_^HL_^HE...


Yes.


instead of

NAME
   rm - remove files or directories

[...]


Apparently `less` understands overstriking and displays it as bold (or
underlining in the case of _^H. That's very clever, but how do I get actual
plain text out of `man` without the backspaces?


That is what Grant Edwards' "col -bx" does. (Actually, col can do more, because 
tables also do funky things; let us not go there.)


But removing the overstriking is pretty easy even without col. My "unbs" script 
does it, and its core operation is this:


 s/[^^H]^H//g

Those ^Hs are literal backspace characters: remove any non-backspace followed 
by a backspace. Full script here:


 https://bitbucket.org/cameron_simpson/css/src/tip/bin/unbs


If I want the --help output run through a pager, I'll do it myself.


Easy enough to say for Linux/Unix users, but there are those who might not
have a pager that is easy to use, or at all. pydoc goes to considerable
trouble to work out the best pager available for your platform, falling
back to its own if needed. To use that is literally a two liner:

import pydoc
pydoc.pager(HELPTEXT)


Aye, but what is wanted by some of us is an easy incantation to tune that to 
plain old sys.stdout.write in some flavour.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What should Python apps do when asked to show help?

[cs]

On 30Apr2016 23:46, Random832  wrote:

On Sat, Apr 30, 2016, at 22:30, Grant Edwards wrote:

We don't want to use a PAGER variable to specify when we want a pager
and when we don't want a pager.  If we want a pager we append "| less"
to the command.  If we don't want a pager, we don't append that to the
command.


Setting PAGER=cat - permanently, in your profile, and never ever
changing it - gives this result, yet it's described by some people here
as "So I have to cripple my shell [...]?" What is crippled? Evidently
you're not "we", since this "crippled" state of affairs seems to be a
perfectly acceptable one to you.


This is an interesting argument.

Yes, PAGER=cat would make "man" also not page, and likely almost everything.  
And yet I am unwilling to do so. Why?


On reflection, my personal problems with this approach are twofold:

- I want $PAGER to specify my preferred pager when I do want a pager, so 
  setting it to "cat" does not inform apps about my wishes


- in an interactive shell, yes I can type "| less"; it seems painful (oh for 
  the happy days of yore when this was spelt "|pg":-)


I am going to try PAGER=cat as an experiment to seem how it feels. Now, I _do_ 
wish "man" to page for a number of reasons (a) my brain expects it (b) I like 
the nice colour highlighting of headings etc (c) manual pages and other 
_lengthy_ documents _are_ better paged than not. This last is in contrast to 
"help" messages, even lengthy usage messages: these are short enough that I 
feel they should not be paged, and if I come across a glaring exception i can 
always page them myself.


Fortunately for me, I am already in the position of mucking with "man"; my 
despite for GNU info with its weird non-paging browser and the accompanying GNU 
manual pages which all too frequently say "man is defunct, go look in info - we 
don't bother with man" drove me to rewrite "man" to try to suck in info files 
into flat pagable text. So telling my shell this:


 man(){ PAGER=less command man ${1+"$@"}; }

is no hardship.

I'll give this a go and see how it feels.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What should Python apps do when asked to show help?

[cs]

On 01May2016 16:44, Chris Angelico  wrote:

On Sun, May 1, 2016 at 3:24 PM,   wrote:

Yes, PAGER=cat would make "man" also not page, and likely almost everything.
And yet I am unwilling to do so. Why?

On reflection, my personal problems with this approach are twofold:

- I want $PAGER to specify my preferred pager when I do want a pager, so
setting it to "cat" does not inform apps about my wishes


So you expect the environment variable to say which of multiple pagers
you might want, but only when you already want a pager. Okay. How is
an app supposed to know whether or not to use a pager? How do you
expect them to mindread?


I think for several of us, we do not expect the app to mindread. Don't page for 
short output!


As the rest of my article remarks, I at least think "man" should page on the 
premise than manual pages will be long enough to benefit, as they should be.


Aside: especially if one uses "less" and includes the -d and -F options in the 
$LESS envvar, which suppresses the warning about "dumb" terminals and autoquits 
if the file fits on the screen - these two provide most of the painfree 
behaviour for short outputs and embedded ttys at least.


We could fork a separate discussion on making pagers more seamless, and 
terminal emulators with nice modes to reduce the need for pagers.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What should Python apps do when asked to show help?

[cs]

On 01May2016 20:55, Steven D'Aprano  wrote:

On Sun, 1 May 2016 05:28 pm, c...@zip.com.au wrote:

On 01May2016 16:44, Chris Angelico  wrote:

So you expect the environment variable to say which of multiple pagers
you might want, but only when you already want a pager. Okay. How is
an app supposed to know whether or not to use a pager? How do you
expect them to mindread?


I think for several of us, we do not expect the app to mindread. Don't
page for short output!


Is there an environment variable to tell the application what you
consider "short", or should it read your mind?


We're getting into matters of taste here. It shouldn't read my mind, but of 
course when it differs it shows bad taste!


I am taking the line that usage and help messages should fall into the "short" 
category, both simply by their nature and also as a design/style criterion for 
program authors. Manuals, be they man pages or info or whatever, should be 
"long", with specification and ideally explainations for rationale and some 
examples.



Personally, I'd rather use a pager for 3 lines than print 30 lines of help
text directly to the console, but others may feel differently.


And I am very much the opposite. ["foo --help"; "types next command; huh?  I'm 
in a pager, not back at my prompt?"]


However, with "less" configured to quit if the text fits on the screen (which 
is can usually determine by querying the terminal directly, no magic required), 
I get the best of both wolds, possibly to the point that I have rarely noticed 
that Python's help() pages.


And I've got mixed feelings about git. It seems that "git help" and "git 
--help" produces sensible unpaged short help (42 lines of it, but that is ok to 
me). It is "git help " which runs "man git-subcommand", and that is 
somewhat defensible because most of the git subcommands have an outrageous 
number of options.  (And it really does just invoke "man" (by default - that is 
also tunable I see); I can tell because it invokes my personal "man" command 
instead of the system one or some internally sourced text.)


My constrast, Mercurial (hg) always produces unpaged output for "help" and 
"help ", and the "help " is succinct and fitting for a 
help text. There is a single large "man hg" for when you want the detailed 
manual. This approach is more to my liking.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What should Python apps do when asked to show help?

[cs]

On 01May2016 21:23, Chris Angelico  wrote:

On Sun, May 1, 2016 at 8:55 PM, Steven D'Aprano  wrote:

Is there an environment variable to tell the application what you
consider "short", or should it read your mind?


How about $LINES? If it's less than that, it'll fit on one screen. Of
course, that still won't be perfect, but it's a definite improvement
over guessing.


On terminal emulators you can normally query the terminal directly for its 
current size (look at the output of "stty -a" for example), and pagers do. This 
is better than $LINES, which is really a convenience thing presented by some 
shells like bash and which won't magicly change if you resize your terminal 
until bash gets another look.


If your pager can be told to autoquit if the output fits then this pain point 
(whatever your preference) can be largely obviated.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: What should Python apps do when asked to show help?

[cs]

On 01May2016 17:04, Grant Edwards  wrote:

On 2016-05-01, Steven D'Aprano  wrote:

On Mon, 2 May 2016 02:30 am, Grant Edwards wrote:


In discussions like these, it would be important to draw from
precedents. Are there commands that have such an option?


It's pretty rare.  It is assumed that Unix uses can type " | less"


Is nobody except me questioning the assumption that we're only
talking about Unix users?


Didn't the OP specify that he was writing a command-line utility for
Linux/Unix?

Discussing command line operation for Windows or OS-X seems rather
pointless.


OS-X _is_ UNIX. I spent almost all my time on this Mac in terminals. It is a 
very nice to use UNIX in many regards.


Cheers,
Cameron Simpson 

Mac OS X. Because making Unix user-friendly is easier than debugging Windows.
- Mike Dawson, Macintosh Systems Administrator and Consultation.
 mdaw...@mac.com http://herowars.onestop.net
--
https://mail.python.org/mailman/listinfo/python-list

Re: What should Python apps do when asked to show help?

[cs]

On 02May2016 14:07, Grant Edwards  wrote:

On 2016-05-01, c...@zip.com.au  wrote:


Didn't the OP specify that he was writing a command-line utility for
Linux/Unix?

Discussing command line operation for Windows or OS-X seems rather
pointless.


OS-X _is_ UNIX. I spent almost all my time on this Mac in terminals. It is a
very nice to use UNIX in many regards.


I include what you're doing under the category "Unix".  When I talk
about "OS X", I mean what my 84 year old mother is using.  I assumed
everybody thought that way.  ;)


Weird. My 79 year old mother uses "Apple". I can only presume there's no "OS X" 
for her.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: How can I debug silent failure - print no output

[cs]

On 27May2016 21:02, Sayth Renshaw  wrote:

On Saturday, 28 May 2016 13:06:59 UTC+10, Michael Torrie  wrote:

Add more print() calls. Offhand I'd say that pq(filename=filename) is
returning an empty list so that for loop is not doing anything.  Hence
your debugging print() calls never happen.

Add sanity print()'s earlier in your program, and make sure everything
you are iterating over is what you expect.


Ok after printing a few things i have found an error.

def GetArgs():
   '''parse XML from command line'''
   parser = argparse.ArgumentParser()

   parser.add_argument("path", nargs="+")
   parser.add_argument('-e', '--extension', default='',
   help='File extension to filter by.')
   args = parser.parse_args()

   files = set()
   name_pattern = "*" + args.extension
   for path in args.path:
   files.update(glob.glob(os.path.join(path, name_pattern)))

   print(files)
   return files

a = GetArgs()
print(a)

so printing the files or the call to the function returns set() not the actual 
files.


Since you're constructing a set of filenames, this means it is probably 
returning the right kind of thing, but it is empty. That points to the glob not 
doing what you want or the for-loop not doing anything.



[sayth@localhost pyXML]$ python3 racemeeting.py data/*.xml
set()
set()
set()


So...  Add more prints!

Specificly, print(args) right after it is set, and put a print() _inside_ the 
loop before the call to files.update, probably printing "path", eg print("path 
=", path).


Then see what you learn.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: How can I debug silent failure - print no output

[cs]

On 28May2016 03:32, Sayth Renshaw  wrote:

On Saturday, 28 May 2016 19:44:53 UTC+10, Sayth Renshaw  wrote:

On Saturday, 28 May 2016 18:02:06 UTC+10, Sayth Renshaw  wrote:
> So how do i get argparse to read the file arguments correctly?
>
> Looking at the namespace it all gets pushed into path and extension remains 
empty.
>
> [sayth@localhost pyXML]$ python3 racemeeting.py data/ *.xml
> Namespace(extension='', path=['data/', '*.xml'])
> This is the section I am running
>
> parser = argparse.ArgumentParser()
> parser.add_argument("path", nargs="+")
> parser.add_argument('-e', '--extension', default='',
> help='File extension to filter by.')
>
> args = parser.parse_args()
> name_pattern = "*" + args.extension
> print(args)

Ah if only i used argparse properly

python racemeeting.py data/ -e *.xml


There are a couple of things here.

First is that a normal UNIX command puts all the options first, so you should 
be desiging your command line to run like this:


 python racemeeting.py -e *.xml data

or perhaps:

 python racemeeting.py -d data -e *.xml

It is traditional to stop parsing options such as -e when you reach the first 
non-option, because that lets one put whatever is necessary safely _after_ the 
options without fear that one of the arguments will resemble an option. For 
example, suppoing you have a file with the name "-e" and said:


 somecommand -f foo dir *

intending to use all the local filenames after "dir". In your current scheme 
(accepting options after "dir") a "-e" appearing later would be misinterpreted.


The second is to be aware that the shell expands globs _before_ invoking the 
command. This is extremely useful because it means that (a) commands usually 
don't need to do their own glob expansion and (b) all commands end up using the 
same glob syntax because it is common to the shell, not a command-specific 
special syntax. Which makes everything easier to use.


The upshot of that is that you should _either_ be quoting "*.xml" on your 
command line to prevent expansion, _or_ you should not be bothering with he 
asterisk, instead passing the argument ".xml" or even just "xml".


As an experiment, make two dummy XML files in your current directory (where 
your script is):


 >>dummy1.xml
 >>dummy2.xml

and run your script passing *.xml as you currently do, and see what your print 
statements say. This should make the effect obvious.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Catch exception with message?

[cs]

On 04Jun2016 04:44, Piyush Verma <114piy...@gmail.com> wrote:

Generally we catch exception using
except Exception as e:

But sometimes, we see same type of exception is present with different
message.Is there a way to capture same exception with message
filtering? Please help me to do this.


Quick note: you almost never was to catch "Exception", you almost always want 
to catch a particular Exception subtype such as ValueError.


Regarding your questuon: sure. Just examine the message. For example:

 try:
   ...
 except SomeException as e:
   if e.message == 'some specific string':
 ... handle that ...
   elif e.message.startswith('some prefix'):
 ... handle that ...
   elif ...
 ...
   else:
 # exception _not_ handled, reraise it for someone further out
 # to handle correctly
 raise

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[cs]

On 03Jun2016 16:09, Sayth Renshaw  wrote:

(By the way, the "pf = pf.append(thing)" construction is weird.
All you need is pf.append(thing).)


I got the pf = pf.append(thing) from doing pandas because in pandas its not an 
inplace function.


In Python this doesn't do what you think. The convention with most Python 
methods is that methods which perform an in-place action return None, which 
means the above assignment will unbind "pf", binding it to None instead.


BTW, the short answer to why you can't just say pf.append(thing) and have "pf" 
be a list is that ".append" is not _inherently_ a list method i.e. the langauge 
does not specify that name as special. You can have another type where .append 
does somehing else. Therefore, the deduction that pf is uspposed to be a list 
may not be made.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Appending an asterisk to the end of each line

[cs]

On 05Jul2016 21:37, Python List  wrote:

On 07/05/2016 03:05 PM, Seymore4Head wrote:

import os

f_in = open('win.txt', 'r')
f_out = open('win_new.txt', 'w')

for line in f_in.read().splitlines():
f_out.write(line + " *\n")

f_in.close()
f_out.close()

os.rename('win.txt', 'win_old.txt')
os.rename('win_new.txt', 'win.txt')

I just tried to reuse this program that was posted several months ago.
I am using a text flie that is about 200 lines long and have named it
win.txt.  The file it creates when I run the program is win_new.txt
but it's empty.


Put a counter in your loop:

   count = 0
   for line in f_in.read().splitlines():
   f_out.write(line + " *\n")
   count += 1
   print("count =", count)

Check that it says 200 (or whatever number you expect).


Not your problem, but you can simplify your read/write loop to:

for line in f_in:
   f_out.write(line[:-1] + ' *\n')

The 'line[:-1]' expression gives you the line up to but not including the 
trailing newline.
Alternately, use:  f_out.write(line.rstrip() + ' *\n')


Importantly for this version, every line _MUST_ have a trailing newline.  
Personally that is what I require of my text files anyway, but some dubious 
tools (and, IMO, dubious people) make text files with no final newline.


For such a file the above code would eat the last character because we don't 
check that a newline is there.


I take a hard line on such files and usually write programs that look like 
this:


   for line in f_in:
   if not line.endswith('\n'):
   raise ValueError("missing final newline on file, last line is: %r" 
(line,))
   f_out.write(line[:-1] + ' *\n')

Then one can proceed secure in the knowledge that the data are well formed.

I consider the final newline something of a termination record; without it I 
have no faith that the file wasn't rudely truncated somehow. In other words, I 
consider a text file to consist of newline-terminated lines, not 
newline-separated lines.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: input vs. readline

[cs]

On 08Jul2016 16:17, John Nagle  wrote:

  If "readline" is imported, "input" gets "readline" capabilities.
It also loses the ability to import control characters.  It doesn't
matter where "readline" is imported; an import in some library
module can trigger this.  You can try this with a simple test
case:
  print(repr(input()))
as a .py file, run in a console.  Try typing "aaaESCbbb".
On Windows 7, output is "bbb".  On Linux, it's "aaa\x1".

So it looks like "readline" is implicitly imported on Windows.


_Or_ that the Windows console app does its own input processing. I would be 
_very_ surprised if Python were behaving differently on the two platforms in 
this regard, though it is possible. (Disclaimer: I pretty much don't use 
Windows).


Remember that any terminal program does some processing of keystrokes before 
they reach your program, even if that is "no" processing. On a UNIX system this 
is called the "line discipline", and doubtless Windows does something of that 
nature.


On a UNIX system in normal circumstances your terminal's line discipline is in 
"cooked" mode, where various things happen to the raw bytes delivered by the 
terminal emulator. For example, when you press  which sends byte 13, in 
cooked mode, this is converted the a newline (byte 10) for receipt by the 
program. Also in cooked mode, backspace (or DEL, depends, see "stty -a") is 
handled by the line disciple: your program sees the text as it was _after_ you 
did all the backspacing. And so forth.


Perhaps the Windows console is treating ESC specially, apparently as "line 
erase", discarduing any preceeding text. Hence your results.


On a UNIX program the normal thing would be to either to:

- accept this, and use the liternal-next kestroke (usually ^V) to tell it not 
 to the bytes special to the line discipline. So you might type ^V^H to get a 
 literal ^H code in your input and so forth.


- use termios to turn off all the control keystrokes (erase, kill and so forth)

- put the terminal into "raw" mode where keystroke bytes are sent through 
 unchanged (although them you need to hand carriage return yourself, etc)


Perhaps Windows has a "literal-next" keystroke line UNIX does.


  I have a multi-threaded Python program which recognizes ESC as
a command to stop something.  This works on Linux, but not on
Windows.  Apparently something in Windows land pulls in "readline".


Unlikely. See above.


  What's the best way to get input from the console (not any
enclosing shell script) that's cross-platform, cross-version
(Python 2.7, 3.x), and doesn't do "readline" processing?


sys.stdin.readline()

input() is a conveience function, now very low level.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: input vs. readline

[cs]

I was typing in a hurry. There are several unreadable items below. Let me 
correct myself...


On 09Jul2016 09:45, Cameron Simpson  wrote:
Perhaps the Windows console is treating ESC specially, apparently as "line 
erase", discarduing any preceeding text. Hence your results.

[...]
- accept this, and use the liternal-next kestroke (usually ^V) to tell it not  
to the bytes special to the line discipline. So you might type ^V^H to get a  
literal ^H code in your input and so forth.


"literal", not "liternal". "not to the" => "not to treat the". "special" => 
"specially".


- put the terminal into "raw" mode where keystroke bytes are sent through  
unchanged (although them you need to hand carriage return yourself, etc)


"then", not "them". "handle", not "hand".

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP Request: Advanced Data Structures

[cs]

On 16Jul2016 19:49, Dennis Lee Bieber  wrote:

On Sat, 16 Jul 2016 15:33:12 -0700 (PDT), Shrey Desai
 declaimed the following:
- Education: the Linked List is a core data structure that CS undergraduates 
(among others) use and study, so it is vital that they have hands on access 
to them. A list is basically a dynamic array; the only property it shares 
with a Linked List is that it's dynamic.


    My CS courses required us to implement our own linked lists (in FORTRAN
IV yet). Providing a built-in linked list just negates the educational
aspect.


I was thinking this exact same thing.

- Development: the use of correct data structures is important when 
developing applications, especially for issues like scaling and efficiency. 
For instance, when working with polynomials, Linked Lists provide a great 
interface to access and edit them.


What does having links gain you that you don't get from a regular list
with slicing?


Well, in a larger context you can keep a reference to an element deep in the 
list, and insert a new element in O(1) time at that point.


The usualy argument against providing linked lists and other basic graph 
related functions in the stdlib is that there are in practice many many 
decisions one can make about exactly what kind of implementation specifics one 
might like in such a thing, and what methods to present for use with the thing.


On the flip side, implementing a simple linked list in a specific context is 
pretty trivial as Chris has demonstrated. I do take the point that a 
preexisting (and hopefully debugged) class would obviate a testing burden for 
users. Provided the class provided enough. If it didn't the end user is back to 
replacing or extending it, and having to test anyway.


To the OP: have you looked in PyPI and found no graph classes?

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP Request: Advanced Data Structures

[cs]

On 17Jul2016 12:43, Chris Angelico  wrote:

On Sun, Jul 17, 2016 at 12:33 PM, Paul Rubin  wrote:

Chris Angelico  writes:

keep a reference to an element deep in the list, and insert a new
element in O(1) time at that point.

at the C level, wouldn't tracing the links cost massively more than
the occasional insertion too? I'm not sure O(1) is of value at any
size, if the costs of all your other operations go up.


I think the idea is that you're already deep in the list when you decide
to insert an element or do other surgery on the list.  An example might
be a lookup table with linear search, where you want to bring the LRU
item to the front of the list after finding it.  Really though, that's
an ugly thing to be doing in any language, and it definitely isn't
something that comes up much in Python.


Right, but how did you *get* that deep into the list? By following a
chain of pointers. That's a relatively costly operation, so the
benefit of not having to move all the following elements is damaged
some by the cost of chasing pointers to get there in the first place.


No, you're assuming too much here. Consider:

 LL = LinkedList()
 item = LL.insert( (some, tuple, value) )
 ... do lots of stuff with the list ...
 ... now item refers to something that might be anywhere ...
 item.add_after( (context, for, a, new, item, in , the, list) )
 ...

and any number of other scenarios of similar nature: note a node in the list 
and get to done things at or near that node at an arbirary other time.


This applies to _any_ graph like data structure where nodes would have to be 
found by traversal.


Anyway, I'm not arguing that Pythons basic list type doesn't address a great 
many needs. I'm arguing that no one size fits all. The core strength of a 
linked list is O(1) insertion at any point, provided you have a reference to 
that point. Whether that is enough benefit depends on the use case.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python text file fetch specific part of line

[cs]

On 27Jul2016 22:12, Arshpreet Singh  wrote:
I am writing Imdb scrapper, and getting available list of titles from IMDB 
website which provide txt file in very raw format, Here is the one part of 
file(http://pastebin.com/fpMgBAjc) as the file provides tags like Distribution  
Votes,Rank,Title I want to parse title names, I tried with readlines() method 
but it returns only list which is quite heterogeneous, is it possible that I 
can parse each value comes under title section?


Just for etiquette: please just post text snippets like that inline in your 
text. Some people don't like fetching random URLs, and some of us are not 
always online when reading and replying to email. Either way, having the text 
in the message, especially when it is small, is preferable.


To your question:

Your sample text looks like this:

   New  Distribution  Votes  Rank  Title
 000125  1680661   9.2  The Shawshank Redemption (1994)
 000125  1149871   9.2  The Godfather (1972)
 000124  786433   9.0  The Godfather: Part II (1974)
 000124  1665643   8.9  The Dark Knight (2008)
 000133  860145   8.9  Schindler's List (1993)
 000133  444718   8.9  12 Angry Men (1957)
 000123  1317267   8.9  Pulp Fiction (1994)
 000124  1209275   8.9  The Lord of the Rings: The Return of the King 
(2003)

 000123  500803   8.9  Il buono, il brutto, il cattivo (1966)
 000133  1339500   8.8  Fight Club (1999)
 000123  1232468   8.8  The Lord of the Rings: The Fellowship of the 
Ring (2001)
 000223  832726   8.7  Star Wars: Episode V - The Empire Strikes Back 
(1980)

 000233  1243066   8.7  Forrest Gump (1994)
 000123  1459168   8.7  Inception (2010)
 000223  1094504   8.7  The Lord of the Rings: The Two Towers (2002)
 000232  676479   8.7  One Flew Over the Cuckoo's Nest (1975)
 000232  724590   8.7  Goodfellas (1990)
 000233  1211152   8.7  The Matrix (1999)

Firstly, I would suggest you not use readlines(), it pulls all the text into 
memory. For small text like this is it ok, but some things can be arbitrarily 
large, so it is something to avoid if convenient. Normally you can just iterate 
over a file and get lines.


You want "text under the Title." Looking at it, I would be inclined to say that 
the first line is a header and the rest consist of 4 columns: a number 
(distribution?), a vote count, a rank and the rest (title plus year).


You can parse data like that like this (untested):

 # presumes `fp` is reading from the text
 for n, line in enumerate(fp):
   if n == 0:
 # heading, skip it
 continue
   distnum, nvotes, rank, etc = split(line, 3)
   ... do stuff with the various fields ...

I hope that gets you going. If not, return with what code you have, what 
happened, and what you actually wanted to happen and we may help further.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python text file fetch specific part of line

[cs]

On 28Jul2016 19:28, Gordon Levi  wrote:

Arshpreet Singh  wrote:
I am writing Imdb scrapper, and getting available list of titles from IMDB 
website which provide txt file in very raw format, Here is the one part of 
file(http://pastebin.com/fpMgBAjc) as the file provides tags like 
Distribution  Votes,Rank,Title I want to parse title names, I tried with 
readlines() method but it returns only list which is quite heterogeneous, is 
it possible that I can parse each value comes under title section?


Beautiful Soup will make your task much easier
.


Did you look at his sample data? Plain text, not HTML or XML. Beautiful Soup is 
not what he needs here.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python text file fetch specific part of line

[cs]

On 29Jul2016 18:42, Gordon Levi  wrote:

c...@zip.com.au wrote:


On 28Jul2016 19:28, Gordon Levi  wrote:

Arshpreet Singh  wrote:

I am writing Imdb scrapper, and getting available list of titles from IMDB
website which provide txt file in very raw format, Here is the one part of
file(http://pastebin.com/fpMgBAjc) as the file provides tags like
Distribution  Votes,Rank,Title I want to parse title names, I tried with
readlines() method but it returns only list which is quite heterogeneous, is
it possible that I can parse each value comes under title section?


Beautiful Soup will make your task much easier
.


Did you look at his sample data?


No. I read he was "writing an IMDB scraper, and getting the available
list of titles from the IMDB web site". It's here
.


Plain text, not HTML or XML. Beautiful Soup is
not what he needs here.


Fortunately the OP told us his application rather than just telling us
his current problem. His life would be much easier if he ignored the
plain text he has obtained so far and started again using a Beautiful
Soup tutorial.


Or bypass IMDB's computer unfriendliness and go straight to http://omdbapi.com/

You can have JSON directly from it, and avoid BS entirely. BS is an amazing 
library, but is essentially a workaround for computer-hostile websites: those 
not providing clean machine readable data, and only unstable mutable HTML 
output.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

CGI, MySQL & Python

[CS]

I'm new to programming and I'm trying to find some answers.  I wrote a few 
python cgi scripts for my website all of which access a mysql db on 
'localhost'. My question is, Is it a bad idea to have my username and 
password for my db coded in my script? Is there a better way to make sure 
that information can't be acessed? Obviously I wan't to make sure that my 
*.py can't be downloaded from /cgi-bin and give anyone access to my db's.

Cory 

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

Re: Python question

[cs]

On 26Mar2017 00:11, Erik  wrote:

On 25/03/17 20:26, MRAB wrote:

On 2017-03-25 20:10, Terry Reedy wrote:

On 3/25/2017 6:50 AM, Steve D'Aprano wrote:

they BCC or CC me without a good excuse. As I was in this case: the OP
BCCed me in his post. I'm not *that* special, so my guess is that he
did a
mass BCC of many regulars here, which makes this spam.

I got the BCC also and was puzzled why.

Same here.

Me too, and I'm hardly a prolific poster compared to some of you lot.


Guys guys guys,

1: He BCCed the list, not us individually. Look at the headers.

2: I got a perfectly civil and informative response from him.

So treat him as up front!

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Front-end to GCC

[sharath . cs . smp]

On Sunday, 20 October 2013 10:56:46 UTC-7, Philip Herron  wrote:
> Hey,
> 
> 
> 
> I've been working on GCCPY since roughly november 2009 at least in its
> 
> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011
> 
> project. I was mentored by Ian Taylor who has been an extremely big
> 
> influence on my software development carrer.
> 
> 
> 
> Gccpy is an Ahead of time implementation of Python ontop of GCC. So it
> 
> works as you would expect with a traditional compiler such as GCC to
> 
> compile C code. Or G++ to compile C++ etc.
> 
> 
> 
> Whats interesting and deserves a significant mention is my work is
> 
> heavily inspired by Paul Biggar's phd thesis on optimizing dynamic
> 
> languages and his work on PHC a ahead of time php compiler. I've had
> 
> so many ups and down in this project and i need to thank Andi Hellmund
> 
> for his contributions to the project.
> 
> http://paulbiggar.com/research/#phd-dissertation
> 
> 
> 
> The project has taken so many years as an in my spare time project to
> 
> get to this point. I for example its taken me so long simply to
> 
> understand a stabilise the core fundamentals for the compiler and how
> 
> it could all work.
> 
> 
> 
> The release can be found here. I will probably rename the tag to the
> 
> milestone (lucy) later on.
> 
> https://github.com/redbrain/gccpy/releases/tag/v0.1-24
> 
> (Lucy is our dog btw, German Shepard (6 years young) loves to lick
> 
> your face off :) )
> 
> 
> 
> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd.
> 
> (Although this is sparse partialy on purpose since i do not wan't
> 
> people thinking this is by any means ready to compile real python
> 
> applications)
> 
> 
> 
> I've found some good success with this project in compiling python
> 
> though its largely unknown to the world simply because i am nervous of
> 
> the compiler and more specifically the python compiler world.
> 
> 
> 
> But at least to me there is at least to me an un-answered question in
> 
> current compiler implementations.  AOT vs Jit.
> 
> 
> 
> Is a jit implementation of a language (not just python) better than
> 
> traditional ahead of time compilation.
> 
> 
> 
> What i can say is ahead of time at least strips out the crap needed
> 
> for the users code to be run. As in people are forgetting the basics
> 
> of how a computer works in my opinion when it comes to making code run
> 
> faster. Simply need to reduce the number of instructions that need to
> 
> be executed in order to preform what needs to be done. Its not about
> 
> Jit and bla bla keyword llvm keyword instruction scheduling keyword
> 
> bla.
> 
> 
> 
> I could go into the arguments but i feel i should let the project
> 
> speak for itself its very immature so you really cant compare it to
> 
> anything like it but it does compile little bits and bobs fairly well
> 
> but there is much more work needed.
> 
> 
> 
> There is nothing at steak, its simply an idea provoked from a great
> 
> phd thesis and i want to see how it would work out. I don't get funded
> 
> of paid. I love working on compilers and languages but i don't have a
> 
> day job doing it so its my little pet to open source i believe its at
> 
> least worth some research.
> 
> 
> 
> I would really like to hear the feedback good and bad. I can't
> 
> describe how much work i've put into this and how much persistence
> 
> I've had to have in light of recent reddit threads talking about my
> 
> project.
> 
> 
> 
> I have so many people to thank to get to this point! Namely Ian
> 
> Taylor, Paul Biggar, Andi Hellmund, Cyril Roelandt  Robert Bradshaw,
> 
> PyBelfast, and the Linux Outlaws community. I really couldn't have got
> 
> to this point in my life without the help of these people!
> 
> 
> 
> Thanks!
> 
> 
> 
> --Phil

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

PyConDE 2018 (Germany) & PyData Karlsruhe CfP extended.

[Alexander CS Hendorf [PyConDE 2018]]

The CfP has been extended for one more week until Sunday June 3 24:00 AoE 
(Anywhere on Earth).

PyCon.DE is where Pythonistas in Germany can meet to learn about new and 
upcoming Python libraries, tools, software and data science. 
We welcome Python enthusiasts, programmers, data scientists and everyone else 
from around the world to join us in Karlsruhe this year.
It's the second time our team runs the conference and we expect more than 500 
participants for this year's conference. 
The conference lasts 3 days + 2 days of sprints featuring about 60 talks, 
tutorials and hands on sessions.

The conference will be held in English language only.

Dates:
main conference: Wednesday October 24 - Friday October 26
sprints: Saturday October 27 - Sunday October 28

Karlsruhe is a major engineering hub of Germany with an elite university KIT. 
Companies in the area include Bosch, Daimler, Porsche, and SAP.
It's easy to reach Karlsruhe by high speed train ICE/TGV or plane (directly of 
via Frankfurt + high speed train or via Stuttgart).

Proposals
==

We’re looking for proposals on every aspect of Python: programming from novice 
to advanced levels, applications and frameworks, or how you have been involved 
in introducing Python into your organization. PyConDE is a community conference 
and we are eager to hear about your experience.

CfP: 

The conferences addresses:

* Data Scientists
* Software Developers
* System Administrators
* Academic Scientists
* Technology Enthusiasts
* Innovation Managers
* AI Engineers

We are looking for:

* 15 minute presentations - keeping a long story short (no Q&A)
* 30 minute presentations (incl. optional 5 minute Q&A)
* 45 minute presentations (incl. optional 5 minute Q&A)
* 90 minute workshops
* Posters

PyData @ PyConDE 2018
==
There will be a PyData track at this year’s conference. 
Please submit your papers for the PyData track through the PyConDE form.

CfP will close Sunday June 3 24:00 AoE (Anywhere on Earth).
We plan to notify speakers by second week of June
and release a draft schedule in June.

As many other PyCon conferences, everyone must buy a ticket. 
Contributors are entitled to a ticket at early bird price.

To foster diversity and to make PyConDE accessible for any pocket size,
we do have a financial support program, more details here:
https://de.pycon.org/blog/fin-aid/ 

Please familiarise yourself with the conference code of conduct 
https://de.pycon.org/code-of-conduct/ 




Alexander Hendorf
@hendorf

as PyConDE & PyData Karlsruhe 2018 program chair & organiser

PyConDE & PyData Karlsruhe 2018:
https://de.pycon.org 
https://twitter.com/pyconde 

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

EuroSciPy 2019 - CfP is open

[Alexander CS Hendorf [EuroSciPy 2019]]

=

*** Apologise for multiple posting ***

Dear Colleagues,

We are delighted to invite you to join us for the 12th European Conference on 
Python in Science. 
The EuroSciPy 2019 Conference will take place from September 2 to September 6 
in Bilbao, Basque Country, Spain. 

The EuroSciPy meeting is a cross-disciplinary gathering focused on the use and 
development of the Python language in scientific research. This event strives 
to bring together both users and developers of scientific tools, as well as 
academic research and state of the art industry.

The conference will be structured as it follows:
Sep, 2-3 : Tutorials and Hands-on
Sep, 4-5 : Main Conference
Sep, 6 : Sprints
--

TOPICS OF INTEREST:

Presentations of scientific tools and libraries using the Python language, 
including but not limited to:
Algorithms implemented or exposed in Python
Astronomy
Data Visualisation
Deep Learning & AI
Earth, Ocean and Geo Science
General-purpose Python tools that can be of special interest to the scientific 
community.
Image Processing
Materials Science
Parallel computing
Political and Social Sciences
Project Jupyter
Reports on the use of Python in scientific achievements or ongoing projects.
Robotics & IoT
Scientific data flow and persistence
Scientific visualization
Simulation
Statistics
Vector and array manipulation
Web applications and portals for science and engineering
3D Printing
---

CALL FOR PROPOSALS:

EuroScipy will accept three different kinds of contributions:

Regular Talks: standard talks for oral presentations, allocated in time slots 
of `15`, or `30` minutes, depending on your preference and scheduling 
constraints. Each time slot considers a Q&A session at the end of the talk (at 
least, 5 mins). 
Hands-on Tutorials: These are beginner or advanced training sessions to dive 
into the subject with all details. These sessions are 90 minutes long, we 
expect participants to bring their own laptop for the tutorials. 
For a sneak peak of last years tutorials, here are the videos: 
https://www.youtube.com/channel/UCruMegFU9dg2doEGOUaAWTg
Poster: EuroScipy will host two poster sessions during the two days of Main 
Conference. We warmly encourage students and participants to present their work 
and/or preliminary results as posters. 

Proposals should be submitted using the EuroScipy submission system at 
https://pretalx.com/euroscipy-2019/cfp. Submission deadline is April, 28 2019.

--

REGISTRATION & FEES:

The registration fees will be as moderate as in previous years, we'll keep you 
posted.

--

IMPORTANT DATES:


Mar 26  Call for talks, posters & tutorials
Apr 28  Submission deadline for talks and tutorials
May 20  Notifications of submission acceptance
Sept 2  Start of EuroSciPy Tutorial
Sept 4  Start of EuroSciPy Main Conference
Sept 6  EuroSciPy Sprints

--


Best regards,
EuroScipy 2019 Organising Committee,
Email: i...@euroscipy.org 
Website: http://www.euroscipy.org/2019 
twitter: @euroscipy

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