Re: tkinter (ttk) combobox dropdown text is white on white

[Peter Otten]

Jim Lee wrote:

> Oops, I hit "reply" instead of "reply-list" last time.  Trying again...
> 
> 
> On 06/03/2018 02:01 PM, Christian Gollwitzer wrote:
>> Am 03.06.18 um 21:54 schrieb Jim Lee:> import tkinter as tk
>>> from tkinter import ttk
>>>
>>> root = tk.Tk()
>>> cb = ttk.Combobox(root)
>>> cb.grid(row=0, column=0, sticky='NSEW')
>>> cb['values'] = ['one', 'two', 'three', 'four']
>>> root.mainloop()
>>>
>>> The text of the values in the combobox dropdown list is white on
>>> white.   The *selected* item in the list is white on light grey, but
>>> all the unselected items are invisible (white on white).
>>
>> Which platform are you on, i.e. which operating system? I guess it is
>> Linux. In that case the default colors are read by Tk from the X11
>> options database, which is some cruft from the past to set options for
>> X11 applications. Try to run
>>
>> xrdb -query
>>
>> That should give you a list of default values, and maybe you can see
>> something. The dropdown list is actually a popdown menu, so look for
>> Menu colors. For instance, if you use a dark theme in your desktop
>> environment, it could be that the foreground is correctly set to
>> white, but the background is hardcoded white for some reason e.g.
>>
>>
>> Christian
> 
> Thanks.  Yes, I am on Linux (Fedora 28, MATE desktop).  Yes, I am using
> a dark theme - however, xrdb does not show #ff for *any* background
> color, so I have no idea where ttk is picking it up from.  Even if I
> change to a light desktop theme, the ttk widget still displays white on
> white.  The only solution I have found so far is rather hackish, but it
> works:
> 
> class MyCombobox(ttk.Combobox):
>  def __init__(self, *args, **kwargs):
>  super().__init__(*args, **kwargs)
>  self.bind('', self._change_popdown_color)
> 
>  def _change_popdown_color(self, *args):
>  popdown = self.tk.eval('ttk::combobox::PopdownWindow
> {}'.format(self))
>  self.tk.call('{}.f.l'.format(popdown), 'configure',
> '-foreground', 'black')
> 
> However, I am still looking for a more elegant solution that preferably
> doesn't hardcode colors...

import tkinter as tk
from tkinter import ttk

root = tk.Tk()
root.option_add('*TCombobox*Listbox.foreground', "black")

cb = ttk.Combobox(root)
cb.grid(row=0, column=0, sticky='NSEW')
cb['values'] = ['one', 'two', 'three', 'four']
root.mainloop()

The foreground color is still hardcoded, but the extra code is a little less 
invasive.


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

Re: Attachments

[Peter Otten]

Peter J. Holzer wrote:

>> However, I did see that particular particular attachment, test.py in
>> Jach's original post, and I'm reading c.l.py via gmane.
> 
> comp.lang.python or gmane.comp.python.general? (I see the latter but not
> the former on gmane, but I'm accessing it anonymously which might make a
> difference.)

gmane.comp.python.general. I thought that was their alias for 
comp.lang.python, for whatever reason.

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

Re: user defined modules

[Steven D'Aprano]

On Mon, 04 Jun 2018 20:13:32 -0700, Sharan Basappa wrote:

> Is there a specific location where user defined modules need to be kept?
> If not, do we need to specify search location so that Python interpreter
> can find it?

Python modules used as scripts can be run from anywhere, by pointing the 
interpreter at the script:

python /path/to/my/script.py


But Python modules uses as libraries, to be imported by other modules, 
have to be on the Python search path. You can add extra  paths to the 
Python search path from the shell by setting the environment variable 
PYTHONPATH to a colon-separated list of paths. On Linux, I do this in 
my .bashrc config file:

export PYTHONPATH="paths:to:add"

In the Python interpreter, you can query and modify the search path by 
importing sys and looking at sys.path. (But you should not do so unless 
you really know what you are doing.)

The default search path is set by the site module:

https://docs.python.org/3/library/site.html

but again, you should not mess with this unless you know what you are 
doing.

There are some per-user directories which are automatically added to the 
search path. I can't find the existing documentation for them, but a good 
place to start is the PEP that introduced the feature:

https://www.python.org/dev/peps/pep-0370/


Apart from setting the PYTHONPATH environment variable, the best way to 
add extra paths to is to install a .pth file. See here:

https://pymotw.com/2/site/#path-configuration-files



> Also, when does Python interpreter compile the module code? When it is
> imported?

Yes. Executing a module as a script does not compile it. But when it is 
imported, it will be compiled to byte-code the first time, and then the 
byte-code will be used.

You can force the compilation using the compileall:

https://docs.python.org/3/library/compileall.html


Or just import the module from the interactive interpreter.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Why exception from os.path.exists()?

[Steven D'Aprano]

On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote:

> On 2018-06-04 13:23:59 +, Steven D'Aprano wrote:
[...]

>> I don't know whether or not the Linux OS is capable of accessing files
>> with embedded NULs in the file name. But Mac OS is capable of doing so,
>> so it should be possible. Wikipedia says:
>> 
>> "HFS Plus mandates support for an escape sequence to allow arbitrary
>> Unicode. Users of older software might see the escape sequences instead
>> of the desired characters."
> 
> I don't know about MacOS. In Linux there is no way to pass a filename
> with an embedded '\0' (or a '/' which is not path separator) between the
> kernel and user space. So if a filesystem contained such a filename, the
> kernel would have to map it (via an escape sequence or some other
> mechanism) to a different file name. Which of course means that - from
> the perspective of any user space process - the filename doesn't contain
> a '\0' or '/'.

That's an invalid analogy. According to that analogy, Python strings 
don't contain ASCII NULs, because you have to use an escape mechanism to 
insert them:

string = "Is this \0 not a NULL?"


But we know that Python strings are not NUL-terminated and can contain 
NUL. It's just another character.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Why exception from os.path.exists()?

[Chris Angelico]

On Tue, Jun 5, 2018 at 5:37 PM, Steven D'Aprano
 wrote:
> On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote:
>
>> On 2018-06-04 13:23:59 +, Steven D'Aprano wrote:
> [...]
>
>>> I don't know whether or not the Linux OS is capable of accessing files
>>> with embedded NULs in the file name. But Mac OS is capable of doing so,
>>> so it should be possible. Wikipedia says:
>>>
>>> "HFS Plus mandates support for an escape sequence to allow arbitrary
>>> Unicode. Users of older software might see the escape sequences instead
>>> of the desired characters."
>>
>> I don't know about MacOS. In Linux there is no way to pass a filename
>> with an embedded '\0' (or a '/' which is not path separator) between the
>> kernel and user space. So if a filesystem contained such a filename, the
>> kernel would have to map it (via an escape sequence or some other
>> mechanism) to a different file name. Which of course means that - from
>> the perspective of any user space process - the filename doesn't contain
>> a '\0' or '/'.
>
> That's an invalid analogy. According to that analogy, Python strings
> don't contain ASCII NULs, because you have to use an escape mechanism to
> insert them:
>
> string = "Is this \0 not a NULL?"
>
>
> But we know that Python strings are not NUL-terminated and can contain
> NUL. It's just another character.
>

No; by that analogy, a Python string cannot contain a non-Unicode
character. Here's a challenge: create a Python string that contains a
character that isn't part of the Universal Character Set.

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

Re: Why exception from os.path.exists()?

[Steven D'Aprano]

On Tue, 05 Jun 2018 20:15:01 +1000, Chris Angelico wrote:

> On Tue, Jun 5, 2018 at 5:37 PM, Steven D'Aprano
>  wrote:
>> On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote:
>>
>>> On 2018-06-04 13:23:59 +, Steven D'Aprano wrote:
>> [...]
>>
 I don't know whether or not the Linux OS is capable of accessing
 files with embedded NULs in the file name. But Mac OS is capable of
 doing so, so it should be possible. Wikipedia says:

 "HFS Plus mandates support for an escape sequence to allow arbitrary
 Unicode. Users of older software might see the escape sequences
 instead of the desired characters."
>>>
>>> I don't know about MacOS. In Linux there is no way to pass a filename
>>> with an embedded '\0' (or a '/' which is not path separator) between
>>> the kernel and user space. So if a filesystem contained such a
>>> filename, the kernel would have to map it (via an escape sequence or
>>> some other mechanism) to a different file name. Which of course means
>>> that - from the perspective of any user space process - the filename
>>> doesn't contain a '\0' or '/'.
>>
>> That's an invalid analogy. According to that analogy, Python strings
>> don't contain ASCII NULs, because you have to use an escape mechanism
>> to insert them:
>>
>> string = "Is this \0 not a NULL?"
>>
>>
>> But we know that Python strings are not NUL-terminated and can contain
>> NUL. It's just another character.
>>
>>
> No; by that analogy, a Python string cannot contain a non-Unicode
> character. Here's a challenge: create a Python string that contains a
> character that isn't part of the Universal Character Set.

Huh? In what way is that the analogy being made? Your challenge is 
impossible from pure Python, equivalent to "create a Python bytes object 
that contains a byte greater than 255". The challenge is rigged to be 
doomed to fail.

That's not the case when it comes to \0 in file names: we know that Mac 
OS can do it, we know HFS and Apple FS support NUL in file names. We have 
an existence proof that it is possible.

(Although in your case, it is conceivable that using C you might be able 
to solve the challenge: create a string using the UCS-4 implementation 
(32-bit code units), then modify some code unit to be a value outside of 
the 21-bit range supported by Unicode. But that would require low-level 
hacking, it isn't supported by the language or the interpreter except 
maybe via ctypes.)

Apple FS, HFS and HFS Plus support \0 as a valid Unicode character. The 
Mac OS kernel has an escape mechanism to allow user code to include \0 
characters in pathnames, just as Python has an escape mechanism to allow 
user code to include \0 in strings.

There's no such escape mechanism for characters outside of Unicode.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Why exception from os.path.exists()?

[Chris Angelico]

On Tue, Jun 5, 2018 at 11:11 PM, Steven D'Aprano
 wrote:
> On Tue, 05 Jun 2018 20:15:01 +1000, Chris Angelico wrote:
>
>> On Tue, Jun 5, 2018 at 5:37 PM, Steven D'Aprano
>>  wrote:
>>> On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote:
>>>
 On 2018-06-04 13:23:59 +, Steven D'Aprano wrote:
>>> [...]
>>>
> I don't know whether or not the Linux OS is capable of accessing
> files with embedded NULs in the file name. But Mac OS is capable of
> doing so, so it should be possible. Wikipedia says:
>
> "HFS Plus mandates support for an escape sequence to allow arbitrary
> Unicode. Users of older software might see the escape sequences
> instead of the desired characters."

 I don't know about MacOS. In Linux there is no way to pass a filename
 with an embedded '\0' (or a '/' which is not path separator) between
 the kernel and user space. So if a filesystem contained such a
 filename, the kernel would have to map it (via an escape sequence or
 some other mechanism) to a different file name. Which of course means
 that - from the perspective of any user space process - the filename
 doesn't contain a '\0' or '/'.
>>>
>>> That's an invalid analogy. According to that analogy, Python strings
>>> don't contain ASCII NULs, because you have to use an escape mechanism
>>> to insert them:
>>>
>>> string = "Is this \0 not a NULL?"
>>>
>>>
>>> But we know that Python strings are not NUL-terminated and can contain
>>> NUL. It's just another character.
>>>
>>>
>> No; by that analogy, a Python string cannot contain a non-Unicode
>> character. Here's a challenge: create a Python string that contains a
>> character that isn't part of the Universal Character Set.
>
> Huh? In what way is that the analogy being made? Your challenge is
> impossible from pure Python, equivalent to "create a Python bytes object
> that contains a byte greater than 255". The challenge is rigged to be
> doomed to fail.

And an ASCIIZ string cannot contain a byte value of zero. The parallel is exact.

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

Re: UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 10442: character maps to

[bellcanadardp]

On Sunday, 3 June 2018 20:11:43 UTC-4, Steven D'Aprano  wrote:
> On Sun, 03 Jun 2018 16:36:12 -0700, bellcanadardp wrote:
> 
> > hello peter ...how exactly would i solve this issue .i have a script
> > that works in python 2 but not pytho3..i did 2 to 3.py ...but i still
> > get the errro...character undefieed..unicode decode error cant decode
> > byte 1x09 in line 7414 from cp 1252..like would you have a sraright
> > solution answer??..i cant get a straight answer..it was ported from ansi
> > to python...so its utf-8 as far asi can see
> 
> You won't get a straight answer because you won't tell us *precisely* 
> what is happening.
> 
> Don't retype a summary of what you think the error is. "character 
> undefieed" is not a thing, and there is no such thing as "byte 1x09".
> 
> You need to COPY AND PASTE the EXACT error that you get. Not just the 
> last line, the error message, but the FULL TRACEBACK starting from the 
> line "Traceback" and going to the end.
> 
> Until you do that, we cannot give you a straight answer.
> 
> You also need to COPY AND PASTE the EXACT line of code that gives the 
> error, plus enough code so that it works. For a file read error, that 
> probably means code that opens the file, and then tries to read from it.
> 
> Until you do that, we cannot give you a straight answer.
> 
> You need to tell us what version of Python you are using, and the 
> operating system.
> 
> You should read this:
> 
> http://sscce.org/
> 
> Even though it is written for Java programmers, it applies to Python to.
> 
> If you think that your file is UTF-8, why are you using CP-1252 to read 
> the file?
> 
> https://en.wikipedia.org/wiki/Windows-1252
> 
> https://en.wikipedia.org/wiki/UTF-8
> 
> 
> 
> I recommend you start with reading this if you haven't already:
> 
> https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-
> software-developer-absolutely-positively-must-know-about-unicode-and-
> character-sets-no-excuses/
> 
> Sorry for the huge URL, try this if your mail client breaks it:
> 
> https://tinyurl.com/h8yg9d7
> 
> 
> Until you read that, you will probably remain confused about text  
> encodings and Unicode and will probably not understand the straight 
> answer we give you.
> 
> Also read: https://nedbatchelder.com/text/unipain.html
> 
> 
> 
> -- 
> Steven D'Aprano
> "Ever since I learned about confirmation bias, I've been seeing
> it everywhere." -- Jon Ronson

here is the exact error full message
in the attachment...UPDATE..i am manually modifying this reply..i tried to 
answer by my gmail but i get errors and i couldnt find this webpage till today 
and it doesnt accept attachments..so many you can for future provide an email 
if thats ok...anyway i will write the error manually here:

*

File 
"C:\Users\Robert\AppData\Local\Programs\Python\Python36\lib\encodings\cp1252.py",
 line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table[0]
UnicodeDecodeError: 'charmap'codec can't decode byte 0x9d in position 7414: 
character maps to 
***

for the record i did not puprosely set the code or decode o encode to cp-1252; 
this is a 3rd party script i have from the internet thats all


this a  set of files that runs find in python 2.7
i am trying to run it in python 3 becuz i was told in 2020 python 2 will no 
longer be supported
not sure if that really matters for my script

it runs completey fine in python 2, so for me the issue is with python 3 and 
its changes relative to python 2

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

Re: Attachments

[Grant Edwards]

On 2018-06-05, Peter Otten <__pete...@web.de> wrote:
> Peter J. Holzer wrote:
>
>>> However, I did see that particular particular attachment, test.py in
>>> Jach's original post, and I'm reading c.l.py via gmane.
>> 
>> comp.lang.python or gmane.comp.python.general? (I see the latter
>> but not the former on gmane, but I'm accessing it anonymously which
>> might make a difference.)
>
> gmane.comp.python.general. I thought that was their alias for 
> comp.lang.python, for whatever reason.

No, that's their alias for their archive of python-list@python.org
messages.  Gmane is unaware of comp.lang.python.

-- 
Grant Edwards   grant.b.edwardsYow! I just remembered
  at   something about a TOAD!
  gmail.com

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

Re: Why exception from os.path.exists()?

[Peter J. Holzer]

On 2018-06-05 07:37:34 +, Steven D'Aprano wrote:
> On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote:
> > On 2018-06-04 13:23:59 +, Steven D'Aprano wrote:
> >> I don't know whether or not the Linux OS is capable of accessing
> >> files with embedded NULs in the file name. But Mac OS is capable of
> >> doing so, so it should be possible. Wikipedia says:
> >> 
> >> "HFS Plus mandates support for an escape sequence to allow
> >> arbitrary Unicode. Users of older software might see the escape
> >> sequences instead of the desired characters."
> > 
> > I don't know about MacOS. In Linux there is no way to pass a
> > filename with an embedded '\0' (or a '/' which is not path
> > separator) between the kernel and user space. So if a filesystem
> > contained such a filename, the kernel would have to map it (via an
> > escape sequence or some other mechanism) to a different file name.
> > Which of course means that - from the perspective of any user space
> > process - the filename doesn't contain a '\0' or '/'.
> 
> That's an invalid analogy. According to that analogy, Python strings
> don't contain ASCII NULs, because you have to use an escape mechanism
> to insert them:
> 
> string = "Is this \0 not a NULL?"
> 
> 
> But we know that Python strings are not NUL-terminated and can contain
> NUL. It's just another character.

I think that's a bad analogy.

The escape mechanism for string literals is mostly for convenience of
the programmer. It's there to make the program's source code more
readable (and yes, also easier to write). But at run time the  \0
character is just that: A character with the value 0.

If a disk with a file system which allows embedded NUL characters is
mounted on Linux (let's for the sake of the argument assume it is HFS+,
although I have to admit that I don't know anything about the internals
of that filesystem), then the low level filesystem code has to map that
character to something else. Even the generic filesystem code of the
kernel will never see that NUL character, let alone the user space. As
far as the OS is concerned, that file doesn't contain a NUL character.
The whole system (except for some low-level FS-dependent code) will
always only see the mapped name.

If some application (which might be an interpreter, or it might be a
graphics program, for example) decides that it knows better what the
"real" filename is and reverses that mapping, it can do so - but it
would be very confusing because it would use a different file name than
the rest of the system. The user would see one file name with ls, but
would have to use a different filename in the application. The
application would show one filename in its "save" dialog, but the OS's
file manager would show another. Not a good idea, especially as the
benefits of such a scheme would be extremely narrow (you could share an
HFS+ formatted USB disk between MacOS and Linux with filenames with
embedded NULs and that application would let you use the same filenames
as you would use on MacOS).

Now, if MacOS uses something like that, this is a different matter.
Presumably (since HFS+ is a native file system) the kernel deals with
NUL characters in a straightforward manner. It might even have a
(non-POSIX) API to expose such filenames. Even if it hasn't, presumably
the mapping back and forth is done in a very low level library used by
all (or most) of the applications, so that they all show consistently
the same filename.

But Linux isn't MacOS. On Linux there are no filenames with embedded
NULs, even if you mount an HFS+ disk and even if some application
decides to internally remap filenames in a way that they can contain NUL
characters.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Attachments

[Peter J. Holzer]

On 2018-06-05 09:33:03 +1000, Ben Finney wrote:
> "Peter J. Holzer"  writes:
> > So we have determined that "the forum" is not the mailing list and not
> > the newsgroup (Jach's message appeared on both with the attachment).
> 
> By “the forum” I don't mean any specific server to the exclusion of
> others. I mean the aggregate forum in which we are having this
> discussion: comp.lang.python and python-list are a single discussion
> forum, distributed across many servers.

Then the statement 

| (For good reasons, attachments are dropped when messages are distributed
| on the forum.)

was demonstrable false (at least overly general) as the attachment in
Jach's message wasn't dropped. It was distributed over all the servers I
can easily check (plus some servers others have checked). It might have
been dropped on some specific servers, but certainly not on "the forum"
as a whole.

(I remember that I have seen some messages in the past where an
attachment was obviously missing. Maybe specific content types are
stripped, but not attachments in general)

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter (ttk) combobox dropdown text is white on white

[Jim Lee]

On 06/05/2018 12:21 AM, Peter Otten wrote:

Jim Lee wrote:


Oops, I hit "reply" instead of "reply-list" last time.  Trying again...


On 06/03/2018 02:01 PM, Christian Gollwitzer wrote:

Am 03.06.18 um 21:54 schrieb Jim Lee:> import tkinter as tk

from tkinter import ttk

root = tk.Tk()
cb = ttk.Combobox(root)
cb.grid(row=0, column=0, sticky='NSEW')
cb['values'] = ['one', 'two', 'three', 'four']
root.mainloop()

The text of the values in the combobox dropdown list is white on
white.   The *selected* item in the list is white on light grey, but
all the unselected items are invisible (white on white).

Which platform are you on, i.e. which operating system? I guess it is
Linux. In that case the default colors are read by Tk from the X11
options database, which is some cruft from the past to set options for
X11 applications. Try to run

xrdb -query

That should give you a list of default values, and maybe you can see
something. The dropdown list is actually a popdown menu, so look for
Menu colors. For instance, if you use a dark theme in your desktop
environment, it could be that the foreground is correctly set to
white, but the background is hardcoded white for some reason e.g.


Christian

Thanks.  Yes, I am on Linux (Fedora 28, MATE desktop).  Yes, I am using
a dark theme - however, xrdb does not show #ff for *any* background
color, so I have no idea where ttk is picking it up from.  Even if I
change to a light desktop theme, the ttk widget still displays white on
white.  The only solution I have found so far is rather hackish, but it
works:

class MyCombobox(ttk.Combobox):
  def __init__(self, *args, **kwargs):
  super().__init__(*args, **kwargs)
  self.bind('', self._change_popdown_color)

  def _change_popdown_color(self, *args):
  popdown = self.tk.eval('ttk::combobox::PopdownWindow
{}'.format(self))
  self.tk.call('{}.f.l'.format(popdown), 'configure',
'-foreground', 'black')

However, I am still looking for a more elegant solution that preferably
doesn't hardcode colors...

import tkinter as tk
from tkinter import ttk

root = tk.Tk()
root.option_add('*TCombobox*Listbox.foreground', "black")

cb = ttk.Combobox(root)
cb.grid(row=0, column=0, sticky='NSEW')
cb['values'] = ['one', 'two', 'three', 'four']
root.mainloop()

The foreground color is still hardcoded, but the extra code is a little less
invasive.


Thanks for that - it's certainly cleaner.  I'm finding that ttk (at 
least as wrapped by tkinter) is fairly buggy - many of the options 
(particularly sytle-related ones) are order dependent, while others are 
ignored entirely.  For example, behavior is different if you set the 
foreground color before the background vs. the other way around.  Also, 
I've found that changing combobox colors in a certain order will affect 
the appearance of buttons ?!?  I think it's time to look for a different 
Python GUI...


-Jim Lee

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

Learning Python

[T Berger]

Can someone learn Python through a book such as Head Start Python? Would an 
online course from MIT or google be better? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Learning Python

[Ned Batchelder]

On 6/5/18 12:51 PM, T Berger wrote:

Can someone learn Python through a book such as Head Start Python? Would an 
online course from MIT or google be better?


This is really a question about your own learning style.  It is possible 
to learn from a book.  Not too long ago, that was one of the only 
methods there was! :)


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

Re: Why exception from os.path.exists()?

[eryk sun]

On Tue, Jun 5, 2018 at 3:28 PM, Peter J. Holzer  wrote:
>
> Now, if MacOS uses something like that, this is a different matter.
> Presumably (since HFS+ is a native file system) the kernel deals with
> NUL characters in a straightforward manner. It might even have a
> (non-POSIX) API to expose such filenames. Even if it hasn't, presumably
> the mapping back and forth is done in a very low level library used by
> all (or most) of the applications, so that they all show consistently
> the same filename.

The Linux subsystem in Windows 10 has to use character escaping. The
root file system is stored in the NTFS directory
"%LocalAppData%\Packages\\LocalState\rootfs". It
escapes invalid NTFS characters (as implemented by the ntfs.sys
driver) using the hex code prefixed by "#". Thus "#" itself has to be
escaped as "#0023". For example:

$ touch '\*?<>|#'
$ ls '\*?<>|#'
\*?<>|#

With CMD in the above directory, we can see the real filename:

> dir /b #*
#005C#002A#003F#003C#003E#007C#0023
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Learning Python

[Stephen Tucker]

I have found Learning Python by Mark Lutz helpful. I have the 4th edition
(2009). Its ISBN is 978-0-596-15806-4.

A lot will depend on your learning style. This book reads more like a set
of course notes than a reference book, but it does contain tables and
summaries, too.

On Tue, Jun 5, 2018 at 5:51 PM, T Berger  wrote:

> Can someone learn Python through a book such as Head Start Python? Would
> an online course from MIT or google be better?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

site package does not work

[Erik Martinson via Python-list]

I am trying to dynamically add a site-package to a script that is run as a cron 
job. The method adduseristepackages does not seem to do anything.

import sys
import site

print('-')print(site.getusersitepackages())
print('add', 
site.addusersitepackages('/home/erik/.local/lib/python3.6/site-packages'))
print(site.getusersitepackages())
print(site.getsitepackages())
print(site.check_enableusersite())


output:-
/root/.local/lib/python3.6/site-packages
add /home/erik/.local/lib/python3.6/site-packages
/root/.local/lib/python3.6/site-packages
['/usr/local/lib/python3.6/dist-packages', '/usr/lib/python3/dist-packages', 
'/usr/lib/python3.6/dist-packages']
True


Thanks,
Erik


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

2018 John Hunter Excellence in Plotting Contest

[Nelle Varoquaux]

Hello everyone,

Sorry about the cross-posting.

There's a couple more days to submit to the John Hunter Excellence in
Plotting Competition!
If you have any scientific plot worth sharing, submit an entry before June
8th.

For more information, see below.

Thanks,
Nelle

In memory of John Hunter, we are pleased to be reviving the SciPy John
Hunter Excellence in Plotting Competition for 2018. This open competition
aims to highlight the importance of data visualization to scientific
progress and showcase the capabilities of open source software.

Participants are invited to submit scientific plots to be judged by a
panel. The winning entries will be announced and displayed at the
conference.

John Hunter’s family and NumFocus are graciously sponsoring cash prizes for
the winners in the following amounts:


   -

   1st prize: $1000
   -

   2nd prize: $750
   -

   3rd prize: $500



   -

   Entries must be submitted by June, 8th to the form at
   https://goo.gl/forms/7q86zgu5OYUOjODH3
   .
   -

   Winners will be announced at Scipy 2018 in Austin, TX.
   -

   Participants do not need to attend the Scipy conference.
   -

   Entries may take the definition of “visualization” rather broadly.
   Entries may be, for example, a traditional printed plot, an interactive
   visualization for the web, or an animation.
   -

   Source code for the plot must be provided, in the form of Python code
   and/or a Jupyter notebook, along with a rendering of the plot in a widely
   used format.  This may be, for example, PDF for print, standalone HTML and
   Javascript for an interactive plot, or MPEG-4 for a video. If the original
   data can not be shared for reasons of size or licensing, "fake" data may be
   substituted, along with an image of the plot using real data.
   -

   Each entry must include a 300-500 word abstract describing the plot and
   its importance for a general scientific audience.
   -

   Entries will be judged on their clarity, innovation and aesthetics, but
   most importantly for their effectiveness in communicating a real-world
   problem. Entrants are encouraged to submit plots that were used during the
   course of research or work, rather than merely being hypothetical.
   -

   SciPy reserves the right to display any and all entries, whether
   prize-winning or not, at the conference, use in any materials or on its
   website, with attribution to the original author(s).


SciPy John Hunter Excellence in Plotting Competition Co-Chairs

Thomas Caswell

Michael Droettboom

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

Re: Attachments

[Ben Finney]

"Peter J. Holzer"  writes:

> Then the statement
>
> | (For good reasons, attachments are dropped when messages are
> | distributed on the forum.)
>
> was demonstrable false (at least overly general) as the attachment in
> Jach's message wasn't dropped.

Try this more precise statement, then:

Many attachments are dropped when distributed on this forum, to the
extent that one should expect attachments will tend not survive
distribution on this forum.

> (I remember that I have seen some messages in the past where an
> attachment was obviously missing. Maybe specific content types are
> stripped, but not attachments in general)

Yes. There may be exceptions, but “don't expect that readers of this
forum can see your attachments” is a good rule to operate by.

-- 
 \  “Writing a book is like washing an elephant: there no good |
  `\place to begin or end, and it's hard to keep track of what |
_o__)  you've already covered.” —anonymous |
Ben Finney

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

Re: tkinter (ttk) combobox dropdown text is white on white

[Terry Reedy]

On 6/3/2018 3:54 PM, Jim Lee wrote:

Given the following snippet (Python 3.6.5, Tk 8.6.8):


What OS? Likely not Windows


import tkinter as tk
from tkinter import ttk

root = tk.Tk()
cb = ttk.Combobox(root)
cb.grid(row=0, column=0, sticky='NSEW')
cb['values'] = ['one', 'two', 'three', 'four']
root.mainloop()

The text of the values in the combobox dropdown list is white on 
white.


Win 10, 3.7.0b5: I see black on white with blue selection background.

   The *selected* item in the list is white on light grey, but all
the unselected items are invisible (white on white).  I have played with 
themes and styles, and can alter the foreground and background colors of 
the combobox itself, but I cannot figure out how to alter the appearance 
of entries in the dropdown list. Any pointers?




--
Terry Jan Reedy


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

Re: tkinter (ttk) combobox dropdown text is white on white

[MRAB]

On 2018-06-06 02:42, Terry Reedy wrote:

On 6/3/2018 3:54 PM, Jim Lee wrote:

Given the following snippet (Python 3.6.5, Tk 8.6.8):


What OS? Likely not Windows


Already answered: Linux (Fedora 28, MATE desktop).


import tkinter as tk
from tkinter import ttk

root = tk.Tk()
cb = ttk.Combobox(root)
cb.grid(row=0, column=0, sticky='NSEW')
cb['values'] = ['one', 'two', 'three', 'four']
root.mainloop()

The text of the values in the combobox dropdown list is white on 
white.


Win 10, 3.7.0b5: I see black on white with blue selection background.

     The *selected* item in the list is white on light grey, but all
the unselected items are invisible (white on white).  I have played with 
themes and styles, and can alter the foreground and background colors of 
the combobox itself, but I cannot figure out how to alter the appearance 
of entries in the dropdown list. Any pointers?



I haven't had a problem with it on Windows.
--
https://mail.python.org/mailman/listinfo/python-list

urllib3 1.23 breaks API

[Cecil Westerhof]

I had installed urllib3 1.22 for Python3. I upgraded it to 1.23. This
broke the requirements for requests 2.18.4:
requests 2.18.4 has requirement urllib3<1.23,>=1.21.1, but you'll have 
urllib3 1.23 which is incompatible

I downgraded to 1.22, but this should not happen I think.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list