Re: Attachments
On 06/06/18 02:48, Ben Finney wrote: > "Peter J. Holzer" writes: >> (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. > Sure, but was it actually dropped anywhere we know of? Non-text attachments are dropped, and most people who try to attach things want to send screenshots, which is why I was a bit surprised to see the attachment here. But are text attachments dropped? At all? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why exception from os.path.exists()?
On Tue, 05 Jun 2018 17:28:24 +0200, Peter J. Holzer wrote: [...] > 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, Even if this were true, why is it even the tiniest bit relevant to what os.path.exists() does when given a path containing a NUL byte? > let alone the user space. As > far as the OS is concerned, that file doesn't contain a NUL character. I don't care about "as far as the OS". I care about users, people like me. If I say "Here's a file called "sp\0am" then I don't care what the OS does, or the FS driver, or the disk hardware. I couldn't care less what the actual byte pattern on the disk is. If you told me that the pattern of bytes representing that filename was 0x0102030405 then I'd be momentarily impressed by the curious pattern and then do my best to immediately forget all about it. As a Python programmer, *why do you care* about NULs? How does this special treatment make your life as a Python programmer better? > The whole system (except for some low-level FS-dependent code) will > always only see the mapped name. Yes. So what? That's *already the case*. Even Python string you pass to os.path.exists is already mapped, and errors from the kernel are mapped to False. Why should NUL be treated differently? Typical Linux file systems (ext3, ext4, btrfs, ReiserFS etc) don't support Unicode, only bytes 0...255, but we can query "invalid" file names containing characters like δ ж or ∆, without any problem. We don't get ValueError just because of some irrelevant technical detail that the file system doesn't support characters outside of the range of bytes 1...255 (excluding 47). We can do this because Python seamlessly maps Unicode to bytes and back again. You may have heard of a little-known operating system called "Windows", which defaults to NTFS as its file system. I'm told that there are a few people who use this file system. Even under Linux, you might have (knowingly or unknowingly) used a network file system or storage device that used NTFS under the hood. If so, then every time you query a filename, even an ordinary looking one like "foo", you could be dealing with multiple NUL bytes, as the NTFS file system (even under Linux!) uses Unicode file names encoded with UTF-16. There's a good chance that EVERY filename you've used on a NAS device or network drive has included embedded NUL bytes. You've painted a pretty picture of the supposed confusion and difficulty such NUL bytes would cause, but its all nonsense. We already can seamlessly and transparently interact with file systems where file names include NUL bytes under Linux. BUT even if what you said was true, that Linux cannot deal with NUL bytes in file names even with driver support, even if passing a NUL byte to the Linux kernel would cause the fall of human civilization, that STILL wouldn't require us to raise ValueError from os.path.exists! -- 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: urllib3 1.23 breaks API
On 2018-06-06, Cecil Westerhof wrote: > 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. For some reason requests is weirdly specific about which versions of urllib3 it will accept. The latest version in github allows urllib3 1.23, but for some reason requests also appears to have stopped issuing new releases mid last year. -- https://mail.python.org/mailman/listinfo/python-list
Problem finding my folder via terminal
I’m learning Python on my own and have been stuck for two days trying to get modules I created into site-packages. As a trial step, we were asked to change directly into the folder containing our modules. I typed “cd mymodules” per instructions, but got this error message: “-bash: cd: mymodules: No such file or directory.” I saved mymodules to my documents. What is going wrong here? When I tried to create a distribution file, I typed “192:~ TamaraB$ mymodules$ python3 setup.py sdist.” I got this error message: “-bash: mymodules$: command not found.” What should I do? -- https://mail.python.org/mailman/listinfo/python-list
Re: site package does not work
On 06/05/2018 01:33 PM, Erik Martinson via Python-list wrote:
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
It seems you are trying to run your script from the root cron job rather
than the user's cron job, and then trying to add a user site directory
to root's site path. From the docs:
|site.||ENABLE_USER_SITE|
Flag showing the status of the usersite-packages
directory.|True|means that it is enabled and was added
to|sys.path|.|False|means that it was disabled by user request
(with|-s|
or|PYTHONNOUSERSITE|
).|None|means
it was disabled for security reasons (mismatch between user or group
id and effective id) or by an administrator.
||
So perhaps a mismatch between UID/GID and EID is causing the whole
process to silently fail... ||
-Jim
||
--
https://mail.python.org/mailman/listinfo/python-list
SQLObject 3.7.0
Hello!
I'm pleased to announce version 3.7.0, the first stable release of branch
3.7 of SQLObject.
What's new in SQLObject
===
Contributors for this release are Scott Stahl and Christophe Popov.
Features
* Add signals on commit and rollback; pull request by Scott Stahl.
Bug fixes
-
* Fix SSL-related parameters for MySQL-connector (connector uses
a different param style). Bug reported by Christophe Popov.
Drivers
---
* Remove psycopg1. Driver ``psycopg`` is now just an alias for ``psycopg2``.
Tests
-
* Install psycopg2 from `psycopg2-binary`_ package.
.. _`psycopg2-binary`: https://pypi.org/project/psycopg2-binary/
For a more complete list, please see the news:
http://sqlobject.org/News.html
What is SQLObject
=
SQLObject is an object-relational mapper. Your database tables are described
as classes, and rows are instances of those classes. SQLObject is meant to be
easy to use and quick to get started with.
SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).
Python 2.7 or 3.4+ is required.
Where is SQLObject
==
Site:
http://sqlobject.org
Development:
http://sqlobject.org/devel/
Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss
Download:
https://pypi.org/project/SQLObject/3.7.0/
News and changes:
http://sqlobject.org/News.html
StackOverflow:
https://stackoverflow.com/questions/tagged/sqlobject
Example
===
Create a simple class that wraps a table::
>>> from sqlobject import *
>>>
>>> sqlhub.processConnection = connectionForURI('sqlite:/:memory:')
>>>
>>> class Person(SQLObject):
... fname = StringCol()
... mi = StringCol(length=1, default=None)
... lname = StringCol()
...
>>> Person.createTable()
Use the object::
>>> p = Person(fname="John", lname="Doe")
>>> p
>>> p.fname
'John'
>>> p.mi = 'Q'
>>> p2 = Person.get(1)
>>> p2
>>> p is p2
True
Queries::
>>> p3 = Person.selectBy(lname="Doe")[0]
>>> p3
>>> pc = Person.select(Person.q.lname=="Doe").count()
>>> pc
1
Oleg.
--
Oleg Broytmanhttps://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
--
https://mail.python.org/mailman/listinfo/python-list
Re: site package does not work
Erik Martinson via Python-list wrote:
> 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.
The function addusersitepackages() seems to be un(der)documented; looking at
the source it turns out that the expected argument is a sequence of known
paths rather than a directory you want to add.
If you need to add a directory that is not deteced by getusersitepackages()
you can do so with addsitedir(my_directory) or by modifying sys.path
directly with sys.path.append(my_directory).
However,
> site.addusersitepackages('/home/erik/.local/lib/python3.6/site-packages'))
I recommend that you install the required packages as root rather than trick
root into executing user-modifiable code, or, even better, that you run the
cron job as user "erik".
--
https://mail.python.org/mailman/listinfo/python-list
Re: Problem finding my folder via terminal
Hi Berger, Do you have any space in the absolute path for mymodules? Spaces avoid getting the correct path as I had seen in one of my virtual environments. Shakti. On Wed, Jun 6, 2018, 9:53 PM T Berger wrote: > I’m learning Python on my own and have been stuck for two days trying to > get modules I created into site-packages. As a trial step, we were asked to > change directly into the folder containing our modules. I typed “cd > mymodules” per instructions, but got this error message: “-bash: cd: > mymodules: No such file or directory.” I saved mymodules to my documents. > What is going wrong here? > > When I tried to create a distribution file, I typed “192:~ TamaraB$ > mymodules$ python3 setup.py sdist.” I got this error message: “-bash: > mymodules$: command not found.” What should I do? > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Names and identifiers
r...@zedat.fu-berlin.de (Stefan Ram): > I was asked about the difference between a name and an > identifier. I was not sure. Ah, a delicious terminology debate ahead! Traditionally, an "identifier" refers to a syntactic (lexical, to be exact) unit. It is a sequence of Unicode code points inside Python text. Ultimately, then, an identifier is a string that satisfies some lexical constraints. For example, the first code point must be a letter. "Name" is latter-day hypercorrect jargon for a variable. It is an abstract entity inside the Python runtime engine. It is a memory slot that can hold a temporal reference to an object. In Python text, you refer to these memory slots using identifiers (lists, dicts and tuples have memory slots as well, but I'll leave those out of this discussion). One identifier can refer to more than one memory slot. In fact, there is no limit to the number of memory slots that are referred to using an identical identifier (for example, you could have a parameter of a recursive function). > Shouldn't it say, > > NameError: identifier 'aiuerhguqieh' is not defined That's an odd way to put it. > or even, > > NameError: identifier 'aiuerhguqieh' is not a name That's better. Conceptually, every identifier in every context refers to a memory slot. Only a finite subset of them holds a reference to an object at any given time. Or to put it in Python-speak, all names exist, but not all of them are bound. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem finding my folder via terminal
Hi Tamara, and welcome! My response is written below. Please ensure your reply is to the group, not just to me personally, thank you. On Wed, 06 Jun 2018 09:19:17 -0700, T Berger wrote: > I’m learning Python on my own and have been stuck for two days trying to > get modules I created into site-packages. As a trial step, we were asked > to change directly into the folder containing our modules. Who asked you to do that? From looking at the commands you give below, you are using Linux or Mac OS, is that right? > I typed “cd mymodules” per instructions, but got this error message: > “-bash: cd: mymodules: No such file or directory.” I saved mymodules to > my documents. What is going wrong here? My guess is that the mymodules folder is inside the "my documents" folder, so when you ask the computer to change into the mymodules folder, it can't see it. Remember that Linux is case-sensitive, so you have to get the exact upper/ lower case mix correct. Try: cd "My Documents/mymodules" and see if that works. Notice that the space inside "My Documents" means you need to use quotation marks. Adjust the uppercase "My Doc..." to lowercase "my doc..." if need be. If it doesn't work, try this: - start typing the command "cd My" *WITHOUT* the quote marks; - hit the TAB key; - hopefully the bash interpreter (the shell you are using) will auto-complete the name of the folder and save you typing the rest; - then start type "mym" (without the quotes!) and hit TAB again; - and hopefully the rest of the name will be auto-completed; - and finally hit ENTER and with luck that will work. If not, we'll need some more information about the computer you are using: what OS are you using (Mac, Linux, Windows, something else), what shell are you using, perhaps a file listing of your home directory. (Which I'm reluctant to ask for, as that potentially may show personal details you might not want to share with the world.) > When I tried to create a distribution file, I typed “192:~ TamaraB$ > mymodules$ python3 setup.py sdist.” I got this error message: “-bash: > mymodules$: command not found.” What should I do? The "mymodules$" part you saw in the instructions is not part of the command you need to type. That is intended to be the prompt. In your case, because you didn't successfully cd into the mymodules folder, your prompt hasn't changed from 192:~ TamaraB$ (I'm not sure what the 192 part means. Does that increase each time you type a command?) Once you successfully cd into the mymodules folder, the prompt will hopefully be: 192:mymodules$ or something similar to that. But whatever it is, you don't need to type the prompt as part of your commands. By the way, thank you for giving so much detail in your request for help! That was very helpful for me to help you. Many supposedly professional programmers don't give anywhere near as useful detail, thinking we can just read their mind and magically know what is going on. Keep up the good work! -- 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: Names and identifiers
Disclaimer: Ido not see Stefan's original post. I recall that he has set some sort of header on his posts which means they are not processed by Gmane, but unfortunately I no longer have any of his posts in my cache where I can check. If anyone else is getting Stefan's posts, can you inspect the full headers and see if there is a relevant header? On Wed, 06 Jun 2018 23:43:10 +0300, Marko Rauhamaa wrote: > r...@zedat.fu-berlin.de (Stefan Ram): > >> I was asked about the difference between a name and an identifier. I >> was not sure. The Python documentation makes it clear that "name" and "identifier" are considered synonyms and there is no difference: Identifiers (also referred to as names) are described by the following lexical definitions. https://docs.python.org/3/reference/lexical_analysis.html#identifiers So as far as Python is concerned, "name" and "identifier" mean precisely the same thing. > Ah, a delicious terminology debate ahead! > > Traditionally, an "identifier" refers to a syntactic (lexical, to be > exact) unit. It is a sequence of Unicode code points inside Python text. > Ultimately, then, an identifier is a string that satisfies some lexical > constraints. For example, the first code point must be a letter. I agree with this. > "Name" is latter-day hypercorrect jargon for a variable. I disagree with this. "Hypercorrectness" doesn't come into this. If you wanted to say "pedantic", I'd agree: there are shades of meaning between "variable" and "name" and "name binding", but often (especially in informal language) we can gloss over those subtleties. But the differences can lead us astray (see below). There are also legitimate and reasonable disagreement as to whether the term "variable" carries too much baggage to be useful in Python, but either way, there is no doubt that *names are not variables* in the same way that the name "Marko" is not *you*, the person. We wouldn't want to say that "names are people", or "names are pets", or "names are ships", and we shouldn't say that "names are variables". Names refer to people, pets, ships and variables. They aren't people, pets, ships or variables either. https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction Also relevant: https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation > It is an > abstract entity inside the Python runtime engine. It is a memory slot > that can hold a temporal reference to an object. That is certainly wrong for Python, as Python variables typically are found in namespaces (implemented as dictionaries) not fixed memory slots. Even if an implementation should use memory slots for variables, that is not mandated by the language. It's a mere implementation detail. > In Python text, you refer to these memory slots using identifiers > (lists, dicts and tuples have memory slots as well, but I'll leave those > out of this discussion). One identifier can refer to more than one > memory slot. In fact, there is no limit to the number of memory slots > that are referred to using an identical identifier (for example, you > could have a parameter of a recursive function). Not the best example, because of course Python does enforce a limit on the number of recursive calls. But putting aside memory limits and similar, I don't think I like the terminology you use. I wouldn't say that one identifier can refer to multiple variables (absolutely not "memory slot", that's just wrong). If that were the case, and you mentioned the name "x", how would the interpreter know which variable you meant? Rather I would say that within a single context (or namespace), each identifier refers to no more than one variable. But the same name can be used in multiple contexts: - we can have a built-in "x", a global "x", and a local "x" at the same time; - the name resolution rules make it clear which one applies in context; - each function invocation results in a new context, so the local variable "x" in one call and the local variable "x" in another call are different "x"es. >> Shouldn't it say, >> >> NameError: identifier 'aiuerhguqieh' is not defined > > That's an odd way to put it. Since "name" and "identifier" are synonyms, it wouldn't be wrong to put it that way, but nor would there be any advantage. >> or even, >> >> NameError: identifier 'aiuerhguqieh' is not a name > > That's better. No, that is completely wrong. Of course "aiuerhguqieh" is a name. It matches the lexical definition of a name, and it occurred in the correct place to match the grammar rules for where names can occur (otherwise you would have had a SyntaxError). As far as the interpreter is concerned, it is a name, and that's all that matters. The programmer's intent hardly comes into it. (Maybe the person who typed that was under the misapprehension that they could use base-32 numeric literals, and intended it to be the decimal number 381626039374006737. Or maybe it was type
Re: Why exception from os.path.exists()?
On Tue, 05 Jun 2018 23:27:16 +1000, Chris Angelico wrote:
> And an ASCIIZ string cannot contain a byte value of zero. The parallel
> is exact.
Why should we, as Python programmers, care one whit about ASCIIZ strings?
They're not relevant. You might as well say that file names cannot
contain the character "π" because ASCIIZ strings don't support it.
No they don't, and yet nevertheless file names can and do contain
characters outside of the ASCIIZ range.
Python strings are rich objects which support the Unicode code point \0
in them. The limitation of the Linux kernel that it relies on NULL-
terminated byte strings is irrelevant to the question of what
os.path.exists ought to do when given a path containing NUL. Other
invalid path names return False.
As a Python programmer, how does treating NUL specially make our life
better?
I don't know what the implementation of os.path.exists is precisely, but
in pseudocode I expect it is something like this:
if "\0" in pathname:
panic("OH NOES A NUL WHATEVER SHALL WE DO?!?!?!")
else:
ask the OS to do a stat on pathname
if an error occurs:
return False
else:
return True
Why not just return False instead of panicking?
--
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: Sorting NaNs
On Sat, 02 Jun 2018 21:02:14 +1000, Chris Angelico wrote: > Point of curiosity: Why "> 0.5"? No particular reason, I just happened to hit that key and then copied and pasted the line into the next one. > Normally when I want a fractional > chance, I write the comparison the other way: "random.random() < 0.5" > has exactly a 50% chance of occurring (presuming that random.random() > follows its correct documented distribution). I've no idea what the > probability of random.random() returning exactly 0.5 is Neither do I. But I expect that "exactly 50% chance" is only approximately true :-) My understanding is that given the assumption of uniformity, the 50% chance is mathematically true, but in that case, it makes no difference whether you go from 0 to 0.5 or 0.5 to 1.0. Mathematically it makes no difference whether you include or exclude the end points. In the Real numbers, there's an uncountable infinity of points either way. *But* once you move to actual floats, that's no longer true. There are a great many more floats between 0 and 0.5 than between 0.5 and 1.0. Including the end points, if we enumerate the floats we get: 0.0 --> 0 0.5 --> 4602678819172646912 1.0 --> 4607182418800017408 so clearly the results of random.random() cannot be uniformly distributed over the individual floats. If they were, the probably of getting something less than or equal to 0.5 would be 4602678819172646912 / 4607182418800017407 or a little more than 99.9%. So given that our mathematically pure(ish) probability of 0.5 for the reals has to be mapped in some way to a finite number of floats, I wouldn't want to categorically say that that the probability remains *precisely* one half. But if it were (let's say) 1 ULP greater or less than one half, would we even know? 0.5 - 1 ULP = 0.49994 0.5 + 1 ULP = 0.5001 I would love to see the statistical experiment that could distinguish those two probabilities from exactly 1/2 to even a 90% confidence level :-) > but since it > can return 0.0 and cannot return 1.0, I've just always used less-than. > (Also because it works nicely with other values - there's a 30% chance > that random.random() is less than 0.3, etc.) Is there a reason for going > greater-than, or is it simply that it doesn't matter? No, no particular reason. If I had thought about it I would have used < too, but I didn't. -- 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
