EuroPython 2019: Schedule is online

2019-06-24 Thread M.-A. Lemburg
We are pleased to announce the EuroPython 2019 schedule. We will again
have more than 130 sessions in total, held by more than 130 speakers.

 Schedule for EuroPython 2019

  * https://ep2019.europython.eu/events/schedule/ *


Please note that the schedule may still change in details, but the
overall layout is fixed now.


Book your EuroPython 2019 Ticket


Please make sure you book your ticket in the coming days. We will
switch to late bird rates next week.

If you want to attend the training sessions, please buy a training
pass in addition to your conference ticket, or get a combined
ticket. We only have very few training seats left.


Travel & accommodation tips
---

Since we’re close the conference, Basel is in high demand. If you’re
having problems finding a hotel, please also consider searching for
apartments on the well known booking sites.

We have collected a number of recommendations for accommodation and
travel to Basel on the EuroPython 2019 website. If you get a hotel or
apartment in Basel, you will additionally get a BaselCard for your
stay, which allows you to use public transport in Basel for
free. Please see our accommodation page for details.



Dates and Venues


EuroPython will be held from July 8-14 2019 in Basel, Switzerland, at
the Congress Center Basel (CCB) for the main conference days (Wed-Fri)
and the FHNW Muttenz for the workshops/trainings/sprints days
(Mon-Tue, Sat-Sun).

Tickets can be purchased on our registration page:

https://ep2019.europython.eu/registration/buy-tickets/

For more details, please have a look at our website and the FAQ:

https://ep2019.europython.eu/faq


Help spread the word


Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/post/185811587232/europython-2019-schedule-is-online

Tweet:

https://twitter.com/europython/status/1143061849446989824


Enjoy,
--
EuroPython 2019 Team
https://ep2019.europython.eu/
https://www.europython-society.org/

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


[no subject]

2019-06-24 Thread Sagar Jape
I'm not able to install pip in my pc it gives following error. what should
I do?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re:

2019-06-24 Thread Joel Goldstick
On Mon, Jun 24, 2019 at 4:13 AM Sagar Jape  wrote:
>
> I'm not able to install pip in my pc it gives following error. what should
> I do?
> --
> https://mail.python.org/mailman/listinfo/python-list

Copy and paste your session info.  The list doesn't show images.

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: User failed to install PIP

2019-06-24 Thread Barry Scott
I guess you attached an image of the error message.
I also going to guess that you are a windows user.

All attachments are stripped on this list.

You will need to explain in text what you did and what the error message was.

Note that PIP is install when you install python.
Have you installed python?

Once python is installed you can run PIP like this:

C:\Users\barry> py -m pip

Usage:
  C:\Python37.win64\python.exe -m pip  [options]

Barry


> On 23 Jun 2019, at 14:27, Sagar Jape  wrote:
> 
> I'm not able to install pip in my pc it gives following error. what should
> I do?
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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


Re: finding a component in a list of pairs

2019-06-24 Thread Peter Pearson
[snip]
> print( dict( pairs ).get( 'sun', '(unknown)' ))

You probably know this, but . . . just in case . . .

If you're doing this many times, you'll want to construct the dict
just once and then make many references to the dict, rather than
re-constructing the dict every time you want to look up an element.

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Understand workflow about reading and writing files in Python

2019-06-24 Thread Windson Yang
When you said "C-runtime buffered I/O", are you talking about Standard I/O
in C (FILE * object)? AFAIN, In CPython, we didn't use Standard I/O, right?

Dennis Lee Bieber  于2019年6月25日周二 上午12:48写道:

> On Mon, 24 Jun 2019 15:18:26 +1200, DL Neil
>  declaimed the following:
>
>
> >
> >However, the OpSys may have read considerably more data, depending upon
> >the device(s) involved, the application, etc; eg if we ask for 2 bytes
> >the operating system will read a much larger block (or applicable unit)
> >of data from a disk drive.
> >
>
> Depending upon implementation, there could be layers of buffers
> involved...
>
> Python application requests, say, 50 bytes using a "buffered I/O"
> file
> object. That file object may invoke a C-runtime buffered I/O call that
> requests whatever the C-runtime buffer-size is -- say a 512 byte sector.
> That request goes to a low-level device driver for a file system/device
> that does I/O in 4KB clusters. So the first read results in the OS reading
> 4KB into a buffer, and passing 512 bytes to the C-call, which then returns
> 50 bytes to the Python layer.
>
> The second read for 50 bytes is satisfied from the remaining bytes
> in
> the C-runtime sector buffer. The 11th read of 50 bytes will get 12 bytes
> from the sector, and then the C-runtime has to request the next sector from
> the OS, which is satisfied from the file system cluster buffer. After the
> 8th sector is processed, the next request results in the OS going to disk
> for the next cluster.
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> [email protected]
> http://wlfraed.microdiversity.freeddns.org/
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Understand workflow about reading and writing files in Python

2019-06-24 Thread Windson Yang
DL Neil  于2019年6月24日周一 上午11:18写道:

> Yes, better to reply to list - others may 'jump in'...
>
>
> On 20/06/19 5:37 PM, Windson Yang wrote:
> > Thank you so much for you review DL Neil, it really helps :D. However,
> > there are some parts still confused me, I replyed as below.
>
> It's not a particularly easy topic...
>
>
> > DL Neil  > > 于2019年6月19日周三 下午2:03写道:
> >
> > I've not gone 'back' to refer to any ComSc theory on
> buffer-management.
> > Perhaps you might benefit from such?
> >
> > I just take a crash course on it so I want to know if I understand the
> > details correctly :D
>
> ...there are so many ways one can mess-up!
>
>
> > I like your use of the word "shift", so I'll continue to use it.
> >
> > There are three separate units of data to consider - each of which
> > could
> > be called a "buffer". To avoid confusing (myself) I'll only call the
> > 'middle one' that:
> > 1 the unit of data 'coming' from the data-source
> > 2 the "buffer" you are implementing
> > 3 the unit of data 'going' out to a data-destination.
> >
> > Just to make it clear, when we use `f.write('abc')` in python, (1) means
> > 'abc', (2) means the buffer handle by Python (by default 8kb), (2) means
> > the file *f* we are writing to, right?
>
> Sorry, this is my typo, (3) means the file *f* we are writing to, right?


> No! (sorry) f.write() is an output operation, thus nr3.
>
> "f" is not a "buffer handle" but a "file handle" or more accurately a
> "file object".
>
> When we:
>
> one_input = f.read( NRbytes )
>
> (ignoring EOF/short file and other exceptions) that many bytes will
> 'appear' in our program labelled as "one_input".
>
> However, the OpSys may have read considerably more data, depending upon
> the device(s) involved, the application, etc; eg if we ask for 2 bytes
> the operating system will read a much larger block (or applicable unit)
> of data from a disk drive.
>
> The same applies in reverse, with f.write( NRbytes/byte-object ), until
> we flush or close the file.
>
> Those situations account for nr1 and nr3. In the usual case, we have no
> control over the size of these buffers - and it is best not to meddle!
>
> I agreed with you.

Hence:-
>
> > 1 and 3 may be dictated to you, eg hardware or file specifications,
> > code
> > requirements, etc.
> >
> > So, data is shifted into the (2) buffer in a unit-size decided by
> (1) -
> > in most use-cases each incoming unit will be the same size, but
> > remember
> > that the last 'unit' may/not be full-size. Similarly, data shifted
> out
> > from the (2) buffer to (3).
> >
> > The size of (1) is likely not that of (3) - otherwise why use a
> > "buffer"? The size of (2) must be larger than (1) and larger than
> (2) -
> > for reasons already illustrated.
> >
> > Is this a typo? (2) larger than (1) larger than (2)?
>
> Correct - well spotted! nr2 > nr1 and nr2 > nr3
>

When we run 'f.write(100', I understand why nr2 (by defaut 8kb) > nr1
(100), but I'm not sure why nr2 > nr3 (file object) here?

>
>
> > I recall learning how to use buffers with a series of hand-drawn
> block
> > diagrams. Recommend you try similarly!
>
> Try this!
>
>
> > Now, let's add a few critiques, as requested (interposed below):-
> >
> >
> > On 19/06/19 3:53 PM, Windson Yang wrote:t
> >  > I'm trying to understand the workflow of how Python read/writes
> > data with
> >  > buffer. I will be appreciated if someone can review it.
> >  >
> >  > ### Read n data
> >
> > - may need more than one read operation if the size of (3) "demands"
> > more data than the size of (1)/one "read".
> >
> >
> > Looks like the size of len of one read() depends on
> >
> https://github.com/python/cpython/blob/master/Modules/_io/bufferedio.c#L1655
>  ?
>
>
> You decide how many bytes should be read. That's how much will be
> transferred from the OpSys' I/O into the Python program's space. With
> the major exception, that if there is no (more) data available, it is
> defined as an exception (EOF = end of file) or if there are fewer bytes
> of data than requested (in which case you will be given only the number
> of bytes of data-available.
>
>
> >  > 1. If the data already in the buffer, return data
> >
> > - this a data-transfer of size (3)
> >
> > For extra credit/an unnecessary complication (but probable
> speed-up!):
> > * if the data-remaining is less than size (3) consider a read-ahead
> > mechanism
> >
> >  > 2. If the data not in the buffer:
> >
> > - if buffer's data-len < size (3)
> >
> >  >  1. copy all the current data from the buffer
> >
> > * if "buffer" is my (2), then no-op
> >
> > I don't understand your point here, when we read data we would copy some
> > data from the current buffer from python, right?
> > (
> https://github.com/python/cpython/blob/master/Modules/_io/bufferedio.c#L1638)

Re: generator to write N lines to file

2019-06-24 Thread Sayth Renshaw


> To get the individual lines you have to yield them
> 
>   for line in lines_gen:
>   yield line
> 
> This can be rewritten with some syntactic sugar as
> 
>   yield from lines_gen
>  
> > for line in getWord(fileName, 5):
> > with open(dumpName, 'a') as f:
> > f.write(line)
> 
> Note that getWord as written does not close the infile when you break out of 
> the loop, e. g.
> 
> for line in getWord(filename, 5):
> break
> 
> To avoid that you can use a context manager:
> 
> from itertools import islice
> from contextlib import contextmanager
> 
> infile = ...
> outfile = ...
> 
> @contextmanager
> def head(infile, numlines):
> with open(infile) as f:
> yield islice(f, numlines)
> 
> with open(outfile, "w") as f:
> with head(infile, 5) as lines:
> f.writelines(lines)

Thank You Peter great advice as always.

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