Re: how to string format when string have {
Chris Angelico wrote:
> On Mon, Apr 21, 2014 at 8:34 AM, Mariano DAngelo
> wrote:
>> And I want to format like this:
>>
>> context = {
>> "project_name":project_name,
>> "project_url":project_url,
>> }
>>
>> nginx_conf.format(**context)
>>
>>
>> but since the string have { i can't.
>> Is there a way to solve this?
>
> Are you in full control of the source string? You can escape the
> braces as explained here:
>
> https://docs.python.org/3.4/library/string.html#format-string-syntax
>
> If you're not in full control (eg if it comes from a user's input), or
> if you don't like the idea of doubling all your braces, you could
> switch to percent-formatting, or some other form of interpolation. But
> the easiest would be to simply escape them.
Some regex gymnastics in the morning (not recommended):
>>> print(nginx_conf)
server {
listen 80;
server_name dev.{project_url};
location / {
proxy_pass http://127.0.0.1:8080;
include /etc/nginx/proxy.conf;
}
location /media {
alias
/home/mariano/PycharmProjects/{project_name}/{project_name}/media;
expires 30d;
}
location /static {
alias
/home/mariano/PycharmProjects/{project_name}/{project_name}/static;
expires 30d;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
roothtml;
}
}
>>> fmt = re.compile(r"((\{)(?!\w)|(?>> print(fmt)
server {{
listen 80;
server_name dev.{project_url};
location / {{
proxy_pass http://127.0.0.1:8080;
include /etc/nginx/proxy.conf;
}}
location /media {{
alias
/home/mariano/PycharmProjects/{project_name}/{project_name}/media;
expires 30d;
}}
location /static {{
alias
/home/mariano/PycharmProjects/{project_name}/{project_name}/static;
expires 30d;
}}
error_page 500 502 503 504 /50x.html;
location = /50x.html {{
roothtml;
}}
}}
>>> print(fmt.format(project_name="MYPROJECT", project_url="MYPROJECT.COM"))
server {
listen 80;
server_name dev.MYPROJECT.COM;
location / {
proxy_pass http://127.0.0.1:8080;
include /etc/nginx/proxy.conf;
}
location /media {
alias /home/mariano/PycharmProjects/MYPROJECT/MYPROJECT/media;
expires 30d;
}
location /static {
alias /home/mariano/PycharmProjects/MYPROJECT/MYPROJECT/static;
expires 30d;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
roothtml;
}
}
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to string format when string have {
On Mon, Apr 21, 2014 at 6:51 PM, Peter Otten <__pete...@web.de> wrote: > Some regex gymnastics in the morning (not recommended): You ask me to believe that a regex would be the best solution here? There's no use trying; one CAN'T believe impossible things. ChrisA (There goes the shawl again!) -- https://mail.python.org/mailman/listinfo/python-list
Read TLS cert serial number?
Is there a way to read the serial number of a TLS cert my app receives? Anthony Sent from my mobile device -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
wxPhoenix. The funny side of wxPhoenix is, that it *also* has its own understanding of unicode and it finally only succeeds to produce mojibakes. I've tried to explained... (I was an early wxPython user from wxPython 2.0 (!). I used, tested, reported about, all wxPython versions up to the shift to the wxPython 2.9 "unicode only" versions, then I gave up). -- Something else. I'm ready to bet, the unicode related bugs I found in Python 3 (core Python) are still here in five years from now. -- Something else, part 2. IDLE. Ten seconds to make it crashing, just by using unicode. -- Working with Python 2.7 + third party libs (even in iso-8859-1) *in* a pure "cp1252 mode", including source code is a very, very solid experience. -- The "Microsoft", "Adobe", foundries... , and in the "open software", the golang, ruby2, TeX unicode engines, all are working very correctly and smoothly with unicode. jmf PS Yes, I'm aware such comments are not really "fair play". -- https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
On 20 April 2014 20:27, Ivan Ivanivich wrote: > thanks, i found the bag G'day. This [https://xkcd.com/979/] applies to threads ending in "nvm, solved it" too. I know the problem in your case isn't likely to be widely useful, but there are other benefits of pointing out what you've done. For example the list members can tell you if your solution misses anything. -- https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
On Sunday, April 20, 2014 10:43:37 PM UTC+4, Ivan Ivanivich wrote:
> hi all, i have simple programming task:
>
>
>
> [quot]
>
> If we list all the natural numbers below 10 that are multiples of 3 or 5, we
> get 3, 5, 6 and 9. The sum of these multiples is 23.
>
>
>
> Find the sum of all the multiples of 3 or 5 below 1000.
>
> [/quote]
>
>
>
> this task from http://projecteuler.net/ site
>
>
>
> I wrote a solution in python
>
>
>
> http://pastebin.com/QXtNuRWU
>
>
>
> this script returned correctly result if "basis < 10", but if "basis < 1000"
> result is 266333 and it is not correctly answer on site
> http://projecteuler.net
>
>
>
> it is my script problem or site not working correctly?
>
>
>
> thanks
>
>
>
> sorry for my english
my bag is: Adding twice the same elements to the total
for exemple:
for divider in 3, 5:
basis=divider
while basis < 1000:
mod = basis % divider
if mod == 0:
total = total + basis
if "basis" is 15, then "mod" == 0 twice - when the "divider" is 3 and 15
my new version of script:
total = 0
div1 = 3
div2 = 5
for basis in range(0, 1000):
mod = basis % div1
if mod == 0:
total = total + basis
continue
mod = basis % div2
if mod == 0:
total = total + basis
continue
print("total = ", total)
--
https://mail.python.org/mailman/listinfo/python-list
Recommended exception for objects that can't be pickled
Hi,
Recently, I got a request [1] to support pickling of
`FTPHost` instances in my `ftplib` library.
I explained in the ticket why I think it's a bad idea and
now want to make explicit that `FTPHost` objects can't be
pickled. The usual way to do this seems to be defining a
`__getstate__` method and raise an exception there.
Now the question is "which exception?" and my research left
me a bit confused. I didn't find a recommendation for this
on the web, not even in the Python documentation for the
`pickle` module [2]. The only hint is that the documentation
states:
"""
The pickle module defines three exceptions:
exception pickle.PickleError
Common base class for the other pickling exceptions. It
inherits Exception.
exception pickle.PicklingError
Error raised when an unpicklable object is encountered
by Pickler. It inherits PickleError.
Refer to What can be pickled and unpickled? to learn
what kinds of objects can be pickled.
exception pickle.UnpicklingError
Error raised when there is a problem unpickling an
object, such as a data corruption or a security
violation. It inherits PickleError.
Note that other exceptions may also be raised during
unpickling, including (but not necessarily limited to)
AttributeError, EOFError, ImportError, and IndexError.
"""
This sounds like unpicklable objects should raise a
`PicklingError`. Indeed, if I do this, `pickle.dumps`
gives me (my own) `PicklingError`:
Python 3.3.2 (default, Nov 8 2013, 13:38:57)
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> class X:
... def __getstate__(self):
... raise pickle.PicklingError("can't pickle X objects")
...
>>> x = X()
>>> pickle.dumps(x)
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in __getstate__
_pickle.PicklingError: can't pickle X objects
What now confuses me is that most, if not all, objects from
the standard library that aren't picklable raise a
`TypeError` when I try to pickle them:
>>> fobj = open("/etc/passwd")
>>> pickle.dumps(fobj)
Traceback (most recent call last):
File "", line 1, in
TypeError: cannot serialize '_io.TextIOWrapper' object
>>> import socket
>>> s = socket.socket()
>>> pickle.dumps(s)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.3/socket.py", line 116, in __getstate__
raise TypeError("Cannot serialize socket object")
TypeError: Cannot serialize socket object
So the documentation for the `pickle` module (to me) implies
I should raise a `PicklingError` while the standard library
usually seems to use a `TypeError`. When I grep through the
library files for `PicklingError`, I get very few hits, most
of them in `pickle.py`:
$ find /usr/lib64/python3.3 -name "*.py" -exec grep -H PicklingError {} \;
/usr/lib64/python3.3/site-packages/numpy/numarray/session.py:except
(pickle.PicklingError, TypeError, SystemError):
/usr/lib64/python3.3/pickle.py:__all__ = ["PickleError", "PicklingError",
"UnpicklingError", "Pickler",
/usr/lib64/python3.3/pickle.py:class PicklingError(PickleError):
/usr/lib64/python3.3/pickle.py:raise
PicklingError("Pickler.__init__() was not called by "
/usr/lib64/python3.3/pickle.py:raise PicklingError("Can't
pickle %r object: %r" %
/usr/lib64/python3.3/pickle.py:raise PicklingError("%s must
return string or tuple" % reduce)
/usr/lib64/python3.3/pickle.py:raise PicklingError("Tuple
returned by %s must have "
/usr/lib64/python3.3/pickle.py:raise PicklingError("args from
save_reduce() should be a tuple")
/usr/lib64/python3.3/pickle.py:raise PicklingError("func from
save_reduce() should be callable")
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/idlelib/rpc.py:except pickle.PicklingError:
Which exception would you raise for an object that can't be
pickled and why?
[1] http://ftputil.sschwarzer.net/trac/ticket/75
[2] https://docs.python.org/3.4/library/pickle.html
Best regards,
Stefan
--
https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
On 2014-04-21 06:21, Ivan Ivanivich wrote:
> > Find the sum of all the multiples of 3 or 5 below 1000.
> my new version of script:
>
> total = 0
> div1 = 3
> div2 = 5
> for basis in range(0, 1000):
> mod = basis % div1
> if mod == 0:
> total = total + basis
> continue
> mod = basis % div2
> if mod == 0:
> total = total + basis
> continue
>
>
>
> print("total = ", total)
Now that you have a working solution, I don't mind giving my more
pythonic solution:
sum(dividend for dividend in range(1000)
if any(dividend % divisor == 0 for divisor in (3, 5)))
which succinctly states the problem and makes it easy to
add/remove/change the divisors in one place rather than having to
define multiple variables to hold them and "if" statements to
evaluate them.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: symple programming task
On Mon, Apr 21, 2014 at 11:21 PM, Ivan Ivanivich wrote: > if "basis" is 15, then "mod" == 0 twice - when the "divider" is 3 and 15 Good! Yes, you worked out exactly what the problem is. :) There are ways to simplify your code, but it's now giving the correct result, so that's the most important thing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
selective (inheriting?) dir()?
Before I get up to my neck in gators over this, I was hoping perhaps
someone already had a solution. Suppose I have two classes, A and B,
the latter inheriting from the former:
class A:
def __init__(self):
self.x = 0
class B(A):
def __init__(self):
A.__init__(self)
self.y = 1
inst_b = B()
Now, dir(inst_b) will list both 'x' and 'y' as attributes (along with
the various under under attributes). Without examining the source, is
it possible to define some kind of "selective" dir, with a API like
def selective_dir(inst, class_): pass
which will list only those attributes of inst which were first defined
in (some method defined by) class_? The output of calls with different
class_ args would yield different lists:
selective_dir(inst_b, B) -> ['y']
selective_dir(inst_b, A) -> ['x']
I'm thinking some sort of gymnastics with inspect might do the trick,
but after a quick skim of that module's functions nothing leapt out at
me. OTOH, working through the code objects for the methods looks
potentially promising:
>>> B.__init__.im_func.func_code.co_names
('A', '__init__', 'y')
>>> A.__init__.im_func.func_code.co_names
('x',)
Thx,
Skip
--
https://mail.python.org/mailman/listinfo/python-list
which book to read next??
Hi, I have read the book 'a byte of python' and now I want to read another book. But I just get confused about which one to read next. There is a book list below： 1, pro python 2, python algorithms 3, python cookbook 4, the python standard library by examples which one is suitable for me?? Or I need to start a project with pygame or flask? Thanks for your help! -- https://mail.python.org/mailman/listinfo/python-list
Re: selective (inheriting?) dir()?
On Tue, Apr 22, 2014 at 12:06 AM, Skip Montanaro wrote: > Without examining the source, is > it possible to define some kind of "selective" dir, with a API like > > def selective_dir(inst, class_): pass > > which will list only those attributes of inst which were first defined > in (some method defined by) class_? The output of calls with different > class_ args would yield different lists: > > selective_dir(inst_b, B) -> ['y'] > > selective_dir(inst_b, A) -> ['x'] > > I'm thinking some sort of gymnastics with inspect might do the trick, > but after a quick skim of that module's functions nothing leapt out at > me. Hmm. Interesting. Fundamentally, attributes in Python don't give you anything about which class they were defined in... by default. However, it ought to be possible to play around with the metaclass; it could detect that you're creating a new attribute and record that somewhere. But if you know that all the attributes you care about are set in __init__, you could do some analysis on that, as you were looking at. Might turn out to be a lot of work to dig through the compiled code, though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: selective (inheriting?) dir()?
On Mon, 21 Apr 2014 09:06:14 -0500, Skip Montanaro wrote:
[...]
> Now, dir(inst_b) will list both 'x' and 'y' as attributes (along with
> the various under under attributes). Without examining the source, is it
> possible to define some kind of "selective" dir, with a API like
>
> def selective_dir(inst, class_): pass
>
> which will list only those attributes of inst which were first defined
> in (some method defined by) class_? The output of calls with different
> class_ args would yield different lists:
>
> selective_dir(inst_b, B) -> ['y']
>
> selective_dir(inst_b, A) -> ['x']
In general, no. There's no way of telling what method added an attribute
after the event has taken place: given that instance.__dict__ has a key
"x", how do you know how it got there?
You may be able to do this cooperatively: have both A and B define a
__dir__ method which lists only the attributes they contribute, then call
dir(A) or dir(B) as necessary.
Or, if you find yourself in the position of having an instance of both A
and B, say, a and b, you can compare dir(a) and dir(b). Anything in the
later but not in the former probably was added by B not A.
I say "probably" because one might have things like this:
class A:
def __init__(self):
if type(self) is not A:
self.y = "Surprise!"
self.x = "something"
and of course don't forget that attributes can be added by external
entities too:
instance = A()
instance.z = "bet you forgot about this"
> I'm thinking some sort of gymnastics with inspect might do the trick,
> but after a quick skim of that module's functions nothing leapt out at
> me. OTOH, working through the code objects for the methods looks
> potentially promising:
>
B.__init__.im_func.func_code.co_names
> ('A', '__init__', 'y')
A.__init__.im_func.func_code.co_names
> ('x',)
You may have a bit of difficulty with classes that write directly to the
__dict__, or use setattr, or eval.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: which book to read next??
On 21/04/14 15:13, lee wrote: Hi, I have read the book 'a byte of python' and now I want to read another book. But I just get confused about which one to read next. There is a book list below： 1, pro python 2, python algorithms 3, python cookbook 4, the python standard library by examples which one is suitable for me?? We would need to know a lot more about you. What is your skill level in programming (as opposed to python)? What are your areas of interest? What is your preferred teaching style? In depth background detail or surface level but hands-on style? Book choice is always a very personal thing. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: selective (inheriting?) dir()?
Thanks for the responses. I'm not really interested in perfection
here. I do most of my programming in a mature internally developed
platform written in Python. As the platform has grown and approaches
to different problems have changed 12-15 year period, some of the
classes which are instantiated have grown quite a few attributes which
are not interesting on a day-to-day basis. As I often query my objects
at runtime and use dir() to jog my memory about what's changing, it
would be nice to eliminate most attributes defined by and only used by
base classes.
Thanks for the suggestion of writing a custom __dir__ method. I hadn't
considered that. It was fairly straightforward to build its attribute
list on-the-fly, taking a snapshot of attributes just after
the base class __init__ method was call, and again after
initialization was complete. The only trick was to leave __dir__
undefined until after that little dance was complete.
Skip
On Mon, Apr 21, 2014 at 10:28 AM, Steven D'Aprano
wrote:
> On Mon, 21 Apr 2014 09:06:14 -0500, Skip Montanaro wrote:
>
> [...]
>> Now, dir(inst_b) will list both 'x' and 'y' as attributes (along with
>> the various under under attributes). Without examining the source, is it
>> possible to define some kind of "selective" dir, with a API like
>>
>> def selective_dir(inst, class_): pass
>>
>> which will list only those attributes of inst which were first defined
>> in (some method defined by) class_? The output of calls with different
>> class_ args would yield different lists:
>>
>> selective_dir(inst_b, B) -> ['y']
>>
>> selective_dir(inst_b, A) -> ['x']
>
> In general, no. There's no way of telling what method added an attribute
> after the event has taken place: given that instance.__dict__ has a key
> "x", how do you know how it got there?
>
> You may be able to do this cooperatively: have both A and B define a
> __dir__ method which lists only the attributes they contribute, then call
> dir(A) or dir(B) as necessary.
>
> Or, if you find yourself in the position of having an instance of both A
> and B, say, a and b, you can compare dir(a) and dir(b). Anything in the
> later but not in the former probably was added by B not A.
>
> I say "probably" because one might have things like this:
>
> class A:
> def __init__(self):
> if type(self) is not A:
> self.y = "Surprise!"
> self.x = "something"
>
> and of course don't forget that attributes can be added by external
> entities too:
>
> instance = A()
> instance.z = "bet you forgot about this"
>
>
>> I'm thinking some sort of gymnastics with inspect might do the trick,
>> but after a quick skim of that module's functions nothing leapt out at
>> me. OTOH, working through the code objects for the methods looks
>> potentially promising:
>>
> B.__init__.im_func.func_code.co_names
>> ('A', '__init__', 'y')
> A.__init__.im_func.func_code.co_names
>> ('x',)
>
>
> You may have a bit of difficulty with classes that write directly to the
> __dict__, or use setattr, or eval.
>
>
>
> --
> Steven D'Aprano
> http://import-that.dreamwidth.org/
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: which book to read next??
On Mon, Apr 21, 2014 at 11:41 AM, Alan Gauld wrote: > On 21/04/14 15:13, lee wrote: > >> Hi, I have read the book 'a byte of python' and now I want to read >> another book. But I just get confused about which one to read next. >> There is a book list below： >> 1, pro python >> 2, python algorithms >> 3, python cookbook >> 4, the python standard library by examples >> which one is suitable for me?? >> > > We would need to know a lot more about you. > What is your skill level in programming (as opposed to python)? > What are your areas of interest? > What is your preferred teaching style? In depth background > detail or surface level but hands-on style? > > Book choice is always a very personal thing. > > > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > http://www.flickr.com/photos/alangauldphotos > > -- > https://mail.python.org/mailman/listinfo/python-list > Don't forget to look at the python.org site: https://wiki.python.org/moin/BeginnersGuide -- Joel Goldstick http://joelgoldstick.com -- https://mail.python.org/mailman/listinfo/python-list
Re: which book to read next??
On 2014-04-21 22:13, lee wrote: > Hi, I have read the book 'a byte of python' and now I want to read > another book. But I just get confused about which one to read next. > There is a book list below： 1, pro python > 2, python algorithms > 3, python cookbook > 4, the python standard library by examples > which one is suitable for me?? > Or I need to start a project with pygame or flask? Once you've got the basics (which it seems like you do have now), I'd find a problem you have and use Python to solve it. E.g.: Problem: I'm bored Solution: write yourself a game in pygame P: I want to create a website to do X S: Use django/flask to do such P: I want to answer some questions about this set of data S: write some Python code to parse the data & produce answers P: I'm poor S: use Python to solve problems for other people and have them pay you You can keep reading books, but if you don't have something to actually create from using this knowledge, it's a somewhat worthless academic exercise. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: which book to read next??
On Tue, Apr 22, 2014 at 2:20 AM, Tim Chase wrote: > Problem: I'm bored > Solution: write yourself a game in pygame Alternative solution: Join python-ideas as well as python-list, and pledge to read *every* post. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: which book to read next??
On 21/04/2014 17:22, Chris Angelico wrote: On Tue, Apr 22, 2014 at 2:20 AM, Tim Chase wrote: Problem: I'm bored Solution: write yourself a game in pygame Alternative solution: Join python-ideas as well as python-list, and pledge to read *every* post. ChrisA Alternative alternative solution: Join python-bugs as well as python-list, and pledge to help out on *every* issue seen :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
which book to read next??
Thanks for all of the respones, Writing a game in pygame is a good idea. Thank you! -- 发自 Android 网易邮箱-- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Testing and credentials best practices?
>> How do you deal with tests (both on dev machine and Jenkins) that need >> credentials (such as AWS keys)?. > I've done several of these. Another option that may work in some > contexts is to mock the test altogether; Thanks, but mocking is last resort for me, it reduces the value of testing greatly and has the burden of catching up with the mocked service. -- https://mail.python.org/mailman/listinfo/python-list
Re: Recommended exception for objects that can't be pickled
On 4/21/2014 9:23 AM, Stefan Schwarzer wrote:
Hi,
Recently, I got a request [1] to support pickling of
`FTPHost` instances in my `ftplib` library.
I explained in the ticket why I think it's a bad idea and
now want to make explicit that `FTPHost` objects can't be
pickled. The usual way to do this seems to be defining a
`__getstate__` method and raise an exception there.
Now the question is "which exception?" and my research left
me a bit confused. I didn't find a recommendation for this
on the web, not even in the Python documentation for the
`pickle` module [2]. The only hint is that the documentation
states:
"""
The pickle module defines three exceptions:
exception pickle.PickleError
Common base class for the other pickling exceptions. It
inherits Exception.
exception pickle.PicklingError
Error raised when an unpicklable object is encountered
by Pickler. It inherits PickleError.
I am going to read this as 'unpicklable as determined by Pickler',
possibly due to a bug in the objects methods.
Refer to What can be pickled and unpickled? to learn
what kinds of objects can be pickled.
exception pickle.UnpicklingError
Error raised when there is a problem unpickling an
object, such as a data corruption or a security
violation. It inherits PickleError.
Note that other exceptions may also be raised during
unpickling, including (but not necessarily limited to)
AttributeError, EOFError, ImportError, and IndexError.
"""
This sounds like unpicklable objects should raise a
`PicklingError`. Indeed, if I do this, `pickle.dumps`
gives me (my own) `PicklingError`:
Python 3.3.2 (default, Nov 8 2013, 13:38:57)
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> class X:
... def __getstate__(self):
... raise pickle.PicklingError("can't pickle X objects")
...
>>> x = X()
>>> pickle.dumps(x)
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in __getstate__
_pickle.PicklingError: can't pickle X objects
What now confuses me is that most, if not all, objects from
the standard library that aren't picklable raise a
`TypeError` when I try to pickle them:
>>> fobj = open("/etc/passwd")
>>> pickle.dumps(fobj)
Traceback (most recent call last):
File "", line 1, in
TypeError: cannot serialize '_io.TextIOWrapper' object
>>> import socket
>>> s = socket.socket()
>>> pickle.dumps(s)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.3/socket.py", line 116, in __getstate__
raise TypeError("Cannot serialize socket object")
TypeError: Cannot serialize socket object
I would just copy the socket.__getstate__, with a revised message.
So the documentation for the `pickle` module (to me) implies
I should raise a `PicklingError` while the standard library
usually seems to use a `TypeError`. When I grep through the
library files for `PicklingError`, I get very few hits, most
of them in `pickle.py`:
This suggests that the exception is intended for use by Pickler, and not
by user code. The reason is pretty subtle and not explained in the doc.
See below.
$ find /usr/lib64/python3.3 -name "*.py" -exec grep -H PicklingError {} \;
/usr/lib64/python3.3/site-packages/numpy/numarray/session.py:except
(pickle.PicklingError, TypeError, SystemError):
/usr/lib64/python3.3/pickle.py:__all__ = ["PickleError", "PicklingError",
"UnpicklingError", "Pickler",
/usr/lib64/python3.3/pickle.py:class PicklingError(PickleError):
/usr/lib64/python3.3/pickle.py:raise
PicklingError("Pickler.__init__() was not called by "
/usr/lib64/python3.3/pickle.py:raise PicklingError("Can't
pickle %r object: %r" %
/usr/lib64/python3.3/pickle.py:raise PicklingError("%s must return
string or tuple" % reduce)
/usr/lib64/python3.3/pickle.py:raise PicklingError("Tuple returned by
%s must have "
/usr/lib64/python3.3/pickle.py:raise PicklingError("args from
save_reduce() should be a tuple")
/usr/lib64/python3.3/pickle.py:raise PicklingError("func from
save_reduce() should be callable")
Most of the above look like bugs in code intended to work with Pickle.
In other words, if you user gets a TypeError, the user has made a
mistake by trying to pickle your object. If you tried to make your
object picklable, and users got PicklingError, that would indicate a bug
in your class code, not the users' use of your class.
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib64/python3.3/pickle.py:raise PicklingError(
/usr/lib6
Re: selective (inheriting?) dir()?
On 4/21/2014 10:06 AM, Skip Montanaro wrote:
Before I get up to my neck in gators over this, I was hoping perhaps
someone already had a solution. Suppose I have two classes, A and B,
the latter inheriting from the former:
class A:
def __init__(self):
self.x = 0
class B(A):
def __init__(self):
A.__init__(self)
self.y = 1
inst_b = B()
Now, dir(inst_b) will list both 'x' and 'y' as attributes (along with
the various under under attributes). Without examining the source, is
it possible to define some kind of "selective" dir, with a API like
def selective_dir(inst, class_): pass
which will list only those attributes of inst which were first defined
in (some method defined by) class_? The output of calls with different
class_ args would yield different lists:
selective_dir(inst_b, B) -> ['y']
selective_dir(inst_b, A) -> ['x']
I'm thinking some sort of gymnastics with inspect might do the trick,
but after a quick skim of that module's functions nothing leapt out at
me. OTOH, working through the code objects for the methods looks
potentially promising:
B.__init__.im_func.func_code.co_names
('A', '__init__', 'y')
A.__init__.im_func.func_code.co_names
('x',)
You can permanently affect dir(ob) with a special method.
object.__dir__(self)
Called when dir() is called on the object. A sequence must be
returned. dir() converts the returned sequence to a list and sorts it.
From outside the class, you get the attributes defined directly in a
class klass as the difference of set(dir(klass) and the union of
set(dir(base)) for base in klass.__bases__. To include attributes set in
__new__ and __init__, replace klass with klass().
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: which book to read next??
On 4/21/2014 7:13 AM, lee wrote: 4, the python standard library by examples I'd take this on -- it provides a comprehensive overview of what's where in the standard library which you'll likely use a lot. which one is suitable for me?? That we can't answer. :) Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Angelico wrote: Earlier it was said that having both / and // lets you explicitly choose whether you want a float result or an int by picking an operator. I'm saying that's not so; the operator and the type aren't quite orthogonal, but close to. I don't think I said that, or if I did I was using sloppy language. As someone pointed out a couple of posts ago, it's not really about types, it's about selecting which *operation* you want to perform. Ordinary division and floor division are very different operations, and you want to be sure you get the right one. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Angelico wrote: All other basic arithmetic operations on two numbers of the same type results in another number of that type. ... There's just one special case: dividing an integer by an integer yields a float, if and only if you use truediv. It sticks out as an exception. I take your point, but I think this is a case where practicality beats purity by a large margin. The idea that arithmetic should always give a result of the same type is all very nice in theory, but it just isn't practical where division is concerned. The reason it doesn't work well is because of the automatic promotion of ints to floats when they meet other floats. This leads to a style where people often use ints to stand for int-valued floats and expect them to be promoted where necessary. Things would be different if ints and floats were completely separate types, like str and bytes, but that would be extremely inconvenient. I used a language like that once, and it wasn't a pleasant experience. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
On Tue, Apr 22, 2014 at 8:28 AM, Gregory Ewing wrote: > The reason it doesn't work well is because of the > automatic promotion of ints to floats when they meet > other floats. This leads to a style where people often > use ints to stand for int-valued floats and expect > them to be promoted where necessary. > > Things would be different if ints and floats were > completely separate types, like str and bytes, but > that would be extremely inconvenient. I used a language > like that once, and it wasn't a pleasant experience. I do see that there are two sides to this. The question of "Is 1.0 equal to 1?" has a very obvious answer... whichever answer you go with, it's absolutely obvious! (Yes! They're the same number, of course they're equal! vs No! They're completely different representations, like 1 and "1" and "\1" are all different!) Separating the types makes very good sense, and unifying them makes very good sense, and for different reasons. Unifying them in as many ways as possible means you don't need the syntactic salt of ".0" on every number; you should be able to add 2.5+1 and get 3.5, just as if you'd added 2.5+1.0. And that's fine. Separating them also makes sense, though; it means that an operation on Type X and Type Y will behave equally sanely regardless of the values of those objects. As it is, we have the case that most lowish integers have equivalent floats (all integers within the range that most people use them), and beyond that, you have problems. This is, in my opinion, analogous to a UTF-16 string type; if you work with strings of nothing but BMP characters, everything works perfectly, but put in an astral character and things may or may not work. A lot of operations will work fine, but just a few will break. Python 3 has fixed that by giving us the pain of transition *right at the beginning*; you look at Text and at Bytes as completely separate things. People who like their ASCII like the idea that the letter "A" is equivalent to the byte 0x41. It's convenient, it's easy. But it leads to problems later. Now, the analogy does break down a bit in that it's probably more likely that a program will have to deal with non-ASCII characters than with integers that can't be represented in IEEE double precision. But would you rather have to deal with the problem straight away, or when your program is some day given a much bigger number to swallow, and it quietly rounds it off to the nearest multiple of 8? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
How to properly get the microseconds from the timestamps?
Hi, ALL, C:\Documents and Settings\Igor.FORDANWORK\My Documents\GitHub\webapp\django\mysql_db_loader>python Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.fromtimestamp(1092787200) datetime.datetime(2004, 8, 17, 17, 0) >>> datetime.datetime.fromtimestamp(1092787200/1000.0) datetime.datetime(1970, 1, 13, 7, 33, 7, 20) Is there a way to know if the timestamp has a microseconds? Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Unicode in Python
On Sunday, April 20, 2014 3:29:00 PM UTC+5:30, Steven D'Aprano wrote: > On Fri, 18 Apr 2014 23:40:18 -0700, Paul Rubin wrote: > > > It's just that the improvement > > from 2 to 3 is rather small, and 2 works perfectly well and people are > > used to it, so they keep using it. > > > Spoken like a true ASCII user :-) Heh! > > The "killer feature" of Python 3 is improved handling of Unicode, which > now brings Python 3 firmly into the (very small) group of programming > languages with first-class support for more than 128 different characters > by default. As a unicode user (ok wannabe unicode user :D ) Ive written up some unicode ideas that have been discussed here in the last couple of weeks: http://blog.languager.org/2014/04/unicoded-python.html If Ive non or misattributed some ideas please excuse and let me know! -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in Python
On 4/21/2014 11:57 PM, Rustom Mody wrote: As a unicode user (ok wannabe unicode user :D ) Ive written up some unicode ideas that have been discussed here in the last couple of weeks: http://blog.languager.org/2014/04/unicoded-python.html "With python 3 we are at a stage where python programs can support unicode well however python program- source is still completely ASCII." In Python 3, "Python reads program text as Unicode code points; the encoding of a source file can be given by an encoding declaration and defaults to UTF-8". Why start off with an erroneous statement, which you even know and show is erroneous? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python 3?
Chris Angelico wrote: As it is, we have the case that most lowish integers have equivalent floats (all integers within the range that most people use them), and beyond that, you have problems. No, I don't. I'm not talking about representing ints using floats, I'm talking about representing floats using ints. *Every* possible integer-valued float value can be written exactly as a Python int. It doesn't matter that there are some ints that can't be represented as floats, because when I'm writing an int literal as a shorthand for a float, I'm not going to be using any of those values -- or if I do, I'm willing to accept the resulting loss of precision, because in my mind they're *not* ints, they're floats. But would you rather have to deal with the problem straight away, or when your program is some day given a much bigger number to swallow, and it quietly rounds it off to the nearest multiple of 8? I don't understand what problem you're imagining here. Any program that needs to do exact calculations with integer values should work with ints throughout and use // or divmod() if it needs to do any division. Nothing will get unexpectedly rounded off then. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in Python
On Mon, 21 Apr 2014 20:57:39 -0700, Rustom Mody wrote: > As a unicode user (ok wannabe unicode user :D ) Ive written up some > unicode ideas that have been discussed here in the last couple of weeks: > > http://blog.languager.org/2014/04/unicoded-python.html What you are talking about is not handling Unicode with Python, but extending the programming language to allow non-English *letters* to be used as if they were *symbols*. That's very problematic, since it assumes that nobody would ever want to use non-English letters in an alphanumeric context. You write: [quote] Now to move ahead! We dont[sic] want >>> λ = 1 >>> λ 1 We want >>> (λx : x+1)(2) 3 [end quote] (Speak for yourself.) But this is a problem. Suppose I want to use a Greek word as a variable, as Python allows me to do: λόγος = "a word" Or perhaps as the parameter to a function. Take the random.expovariate function, which currently takes an argument "lambd" (since lambda is a reserved word). I might write instead: def expovariate(self, λ): ... After all, λ is an ordinary letter of the (Greek) alphabet, why shouldn't it be used in variable names? But if "λx" is syntax for "lambda x", then I'm going to get syntax errors: λόγος = "a word" => like: lambda όγος = "a word" def expovariate(self, λ): => like: def expovariate(self, lambda): both of which are obviously syntax errors. This is as hostile to Greek-using programmers as deciding that "f" should be reserved for functions would be to English-using programmers: # space between the f and the function name is not needed fspam(x, y): ... class Thingy: f__init__(selF): ... fmethod(selF, arg): return arg + 1 Notice that I can't even write "self" any more, since that gives a syntax error. Presumable "if" is okay, as it is a keyword. Using Unicode *symbols* rather than non-English letters is less of a problem, since they aren't valid in identifiers. More comments to follow later. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in Python
On Tuesday, April 22, 2014 11:14:17 AM UTC+5:30, Terry Reedy wrote: > On 4/21/2014 11:57 PM, Rustom Mody wrote: > > As a unicode user (ok wannabe unicode user :D ) Ive > > written up some unicode ideas that have been discussed here in the > > last couple of weeks: > > http://blog.languager.org/2014/04/unicoded-python.html > "With python 3 we are at a stage where python programs can support > unicode well however python program- source is still completely ASCII." > In Python 3, "Python reads program text as Unicode code points; the > encoding of a source file can be given by an encoding declaration and > defaults to UTF-8". Why start off with an erroneous statement, which you > even know and show is erroneous? Ok Ive reworded it to make it clear that I am referring to the character-sets and not encodings. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in Python
On Apr 22, 2014 12:01 AM, "Rustom Mody" wrote: > As a unicode user (ok wannabe unicode user :D ) Ive > written up some unicode ideas that have been discussed here in the > last couple of weeks: > > http://blog.languager.org/2014/04/unicoded-python.html I'm reminded of this satire: http://www.ojohaven.com/fun/spelling.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in Python
On Tue, Apr 22, 2014 at 4:18 PM, Rustom Mody wrote: > Ive reworded it to make it clear that I am referring to the character-sets and > not encodings. It's still false, and was in Python 2 as well. The only difference on that front is that, in the absence of an encoding cookie, Python 2 defaults to ASCII while Python 3 defaults to UTF-8. PEP 263 explains the feature as it was added to Py2; PEP 3120 makes the change to a UTF-8 default. Python source code is Unicode text, and has been since 2001 and Python 2.3. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in Python
On Tuesday, April 22, 2014 11:41:56 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 21 Apr 2014 20:57:39 -0700, Rustom Mody wrote: > > As a unicode user (ok wannabe unicode user :D ) Ive written up some > > unicode ideas that have been discussed here in the last couple of weeks: > > http://blog.languager.org/2014/04/unicoded-python.html > What you are talking about is not handling Unicode with Python, but > extending the programming language to allow non-English *letters* to be > used as if they were *symbols*. > That's very problematic, since it assumes that nobody would ever want to > use non-English letters in an alphanumeric context. You write: > [quote] > Now to move ahead! > We dont[sic] want > >>> λ = 1 > >>> λ > 1 > We want > >>> (λx : x+1)(2) > 3 > [end quote] > (Speak for yourself.) But this is a problem. Suppose I want to use a > Greek word as a variable, as Python allows me to do: > λόγος = "a word" > Or perhaps as the parameter to a function. Take the random.expovariate > function, which currently takes an argument "lambd" (since lambda is a > reserved word). I might write instead: > def expovariate(self, λ): ... > After all, λ is an ordinary letter of the (Greek) alphabet, why shouldn't > it be used in variable names? But if "λx" is syntax for "lambda x", then > I'm going to get syntax errors: > λόγος = "a word" > => like: lambda όγος = "a word" > def expovariate(self, λ): > => like: def expovariate(self, lambda): > both of which are obviously syntax errors. > This is as hostile to Greek-using programmers as deciding that "f" should > be reserved for functions would be to English-using programmers: > # space between the f and the function name is not needed > fspam(x, y): > ... > class Thingy: > f__init__(selF): > ... > fmethod(selF, arg): > return arg + 1 > Notice that I can't even write "self" any more, since that gives a syntax > error. Presumable "if" is okay, as it is a keyword. > Using Unicode *symbols* rather than non-English letters is less of a > problem, since they aren't valid in identifiers. Ok point taken. So instead of using λ (0x3bb) we should use 𝝀 (0x1d740) or something thereabouts like 𝜆 -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode in Python
On Tue, Apr 22, 2014 at 4:30 PM, Rustom Mody wrote: > So instead of using λ (0x3bb) we should use 𝝀 (0x1d740) or something > thereabouts like 𝜆 You still have a major problem: How do you type that? It gives you very little advantage over the word "lambda", it introduces readability issues, it's impossible for most people to type (and programming with a palette of arbitrary syntactic tokens isn't my idea of fun), it's harder for a new programmer to get docs for (especially if s/he reads the file in the wrong encoding), and all in all, it's a pretty poor substitute for a word. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
