Re: Python 3.2 has some deadly infection
Marko Rauhamaa writes: > Steven D'Aprano : > >> Nevertheless, there are important abstractions that are written on top >> of the bytes layer, and in the Unix and Linux world, the most >> important abstraction is *text*. In the Unix world, text formats and >> text processing is much more common in user-space apps than binary >> processing. > > That linux text is not the same thing as Python's text. Conceptually, > Python text is a sequence of 32-bit integers. Linux text is a sequence > of 8-bit integers. _Unicode string in Python is a sequence of Unicode codepoints_. It is correct that 32-bit integer is enough to represent any Unicode codepoint: \u...\U0010 It says *nothing* about how Unicode strings are represented *internally* in Python. It may vary from version to version, build options and even may depend on the content of a string at runtime. In the past, "narrow builds" might break the abstraction in some cases that is why Linux distributions used wide python builds. _Unicode codepoint is not a Python concept_. There is Unicode standard http://unicode.org Though intead of following the self-referential defenitions web, I find it easier to learn from examples such as http://codepoints.net/U+0041 (A) or http://codepoints.net/U+1F3A7 (🎧) _There is no such thing as 8-bit text_ http://www.joelonsoftware.com/articles/Unicode.html If you insert a space after each byte (8-bit) in the input text then you may get garbage i.e., you can't assume that a character is a byte: $ echo "Hyvää yötä" | perl -pe's/.\K/ /g' H y v a � � � � y � � t � � In general, you can't assume that a character is a Unicode codepoint: $ echo "Hyvää yötä" | perl -C -pe's/.\K/ /g' H y v a ̈ ä y ö t ä The eXtended grapheme clusters (user-perceived characters) may be useful in this case: $ echo "Hyvää yötä" | perl -C -pe's/\X\K/ /g' H y v ä ä y ö t ä \X pattern is supported by `regex` module in Python i.e., you can't even iterate over characters (as they are seen by a user) in Python using only stdlib. \w+ pattern is also broken for Unicode text http://bugs.python.org/issue1693050 (it is fixed in the `regex` module) i.e., you can't select a word in Unicode text using only stdlib. \X along is not enough in some cases e.g., "“ch” may be considered a grapheme cluster in Slovak, for processes such as collation" [1] (sorting order). `PyICU` module might be useful here. Knowing about Unicode normalization forms (NFC, NFKD, etc) http://unicode.org/reports/tr15/ Unicode text segmentation [1] and Unicode collation algorithm http://www.unicode.org/reports/tr10/ concepts is also useful; if you want to work with text. [1]: http://www.unicode.org/reports/tr29/ -- akira -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use SQLite (sqlite3) more efficiently
On Thu, 5 Jun 2014 17:17:19 -0500 (CDT), Dave Angel wrote: >R Johnson Wrote in message: > >> >> I've attached some new sample code in which I've attempted to correct >> various things that you mentioned. > >Attachments don't work well for many people using this list. I > for one can't even see them. And for those reading it as a newsgroup they don't work at all. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Travis Griggs writes: >> On Jun 5, 2014, at 1:14, Alain Ketterlin wrote: >> >> Swift's memory management is similar to python's (ref. counting). Which >> makes me think that a subset of python with the same type safety would >> be an instant success. > > Except that while you don't need to regularly worry about cycles in > python, you do in swift. Right. You can't just ignore cycle in Swift. > Which means you get to think constantly about direct and indirect > cycles, figure out where to put weak stuff, when to use a local to > keep a weak property alive until it finds it's strong home, etc. Well, I don't consider this a bad trade-off. Deciding which refs are weak and which are strong, or even designing an explicit deallocation strategy, are design decisions. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode and Python - how often do you index strings?
On 05.06.2014 20:52, Ryan Hiebert wrote:
> 2014-06-05 13:42 GMT-05:00 Johannes Bauer :
>
>> On 05.06.2014 20:16, Paul Rubin wrote:
>>> Johannes Bauer writes:
line = line[:-1]
Which truncates the trailing "\n" of a textfile line.
>>>
>>> use line.rstrip() for that.
>>
>> rstrip has different functionality than what I'm doing.
>
> How so? I was using line=line[:-1] for removing the trailing newline, and
> just replaced it with rstrip('\n'). What are you doing differently?
Ah, I didn't know rstrip() accepted parameters and since you wrote
line.rstrip() this would also cut away whitespaces (which sadly are
relevant in odd cases).
Thanks for the clarification, I'll definitely introduce that.
Cheers,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unicode and Python - how often do you index strings?
On 05.06.2014 22:18, Ian Kelly wrote:
> Personally I tend toward rstrip('\r\n') so that I don't have to worry
> about files with alternative line terminators.
Hm, I was under the impression that Python already took care of removing
the \r at a line ending. Checking that right now:
(DOS encoded file "y")
>>> for line in open("y", "r"): print(line.encode("utf-8"))
...
b'foo\n'
b'bar\n'
b'moo\n'
b'koo\n'
Yup, the \r was removed automatically. Are there cases when it isn't?
Cheers,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa
--
https://mail.python.org/mailman/listinfo/python-list
Re: Matplotlib - specifying bin widths
On Thursday, June 5, 2014 4:54:16 PM UTC+1, Jamie Mitchell wrote: > Hello all! > > > > Instead of setting the number of bins I want to set the bin width. > > > > I would like my bins to go from 1.7 to 2.4 in steps of 0.05. > > > > How do I say this in the code? > > > > Cheers, > > > > Jamie That's great thanks Mark. -- https://mail.python.org/mailman/listinfo/python-list
Overlaying a boxplot onto a time series figure
Hi there,
I would like to overlay some boxplots onto a time series.
I have tried pylab.hold(True) in between the two plots in my code but this
hasn't worked.
The problem is that the x-axes of the boxplots and the time series are not the
same.
Code for time series:
python2.7
import netCDF4
import matplotlib.pyplot as plt
import numpy as np
swh_Q0_con_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/controlperiod/south_west/swhcontrol_swest_annavg1D.nc','r')
hs_Q0_con_sw=swh_Q0_con_sw.variables['hs'][:]
year_con=swh_Q0_con_sw.variables['year'][:]
swh_Q3_con_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q3/swh/controlperiod/south_west/swhcontrol_swest_annavg1D.nc','r')
hs_Q3_con_sw=swh_Q3_con_sw.variables['hs'][:]
swh_Q4_con_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q4/swh/controlperiod/south_west/swhcontrol_swest_annavg1D.nc','r')
hs_Q4_con_sw=swh_Q4_con_sw.variables['hs'][:]
swh_Q14_con_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q14/swh/controlperiod/south_west/swhcontrol_swest_annavg1D.nc','r')
hs_Q14_con_sw=swh_Q14_con_sw.variables['hs'][:]
swh_Q16_con_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q16/swh/controlperiod/south_west/swhcontrol_swest_annavg1D.nc','r')
hs_Q16_con_sw=swh_Q16_con_sw.variables['hs'][:]
swh_Q0_fut_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q0/swh/2050s/south_west/swh2050s_swest_annavg1D.nc','r')
hs_Q0_fut_sw=swh_Q0_fut_sw.variables['hs'][:]
year_fut=swh_Q0_fut_sw.variables['year'][:]
swh_Q3_fut_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q3/swh/2050s/south_west/swh2050s_swest_annavg1D.nc','r')
hs_Q3_fut_sw=swh_Q3_fut_sw.variables['hs'][:]
swh_Q4_fut_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q4/swh/2050s/south_west/swh2050s_swest_annavg1D.nc','r')
hs_Q4_fut_sw=swh_Q4_fut_sw.variables['hs'][:]
swh_Q14_fut_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q14/swh/2050s/south_west/swh2050s_swest_annavg1D.nc','r')
hs_Q14_fut_sw=swh_Q14_fut_sw.variables['hs'][:]
swh_Q16_fut_sw=netCDF4.Dataset('/data/cr1/jmitchel/Q16/swh/2050s/south_west/swh2050s_swest_annavg1D.nc','r')
hs_Q16_fut_sw=swh_Q16_fut_sw.variables['hs'][:]
fit_Q0_con_sw=np.polyfit(year_con,hs_Q0_con_sw,1)
fit_fn_Q0_con_sw=np.poly1d(fit_Q0_con_sw)
plt.plot(year_con,hs_Q0_con_sw,'g.')
plt.plot(year_con,fit_fn_Q0_con_sw(year_con),'g',label='Q0 no pert')
fit_Q3_con_sw=np.polyfit(year_con,hs_Q3_con_sw,1)
fit_fn_Q3_con_sw=np.poly1d(fit_Q3_con_sw)
plt.plot(year_con,hs_Q3_con_sw,'b.')
plt.plot(year_con,fit_fn_Q3_con_sw(year_con),'b',label='Q3 low sens')
fit_Q4_con_sw=np.polyfit(year_con,hs_Q4_con_sw,1)
fit_fn_Q4_con_sw=np.poly1d(fit_Q4_con_sw)
plt.plot(year_con,hs_Q4_con_sw,'y.')
plt.plot(year_con,fit_fn_Q4_con_sw(year_con),'y',label='Q4 low sens')
fit_Q14_con_sw=np.polyfit(year_con,hs_Q14_con_sw,1)
fit_fn_Q14_con_sw=np.poly1d(fit_Q14_con_sw)
plt.plot(year_con,hs_Q14_con_sw,'r.')
plt.plot(year_con,fit_fn_Q14_con_sw(year_con),'r',label='Q14 high sens')
fit_Q16_con_sw=np.polyfit(year_con,hs_Q16_con_sw,1)
fit_fn_Q16_con_sw=np.poly1d(fit_Q16_con_sw)
plt.plot(year_con,hs_Q16_con_sw,'c.')
plt.plot(year_con,fit_fn_Q16_con_sw(year_con),'c',label='Q16 high sens')
fit_Q0_fut_sw=np.polyfit(year_fut,hs_Q0_fut_sw,1)
fit_fn_Q0_fut_sw=np.poly1d(fit_Q0_fut_sw)
plt.plot(year_fut,hs_Q0_fut_sw,'g.')
plt.plot(year_fut,fit_fn_Q0_fut_sw(year_fut),'g')
fit_Q3_fut_sw=np.polyfit(year_fut,hs_Q3_fut_sw,1)
fit_fn_Q3_fut_sw=np.poly1d(fit_Q3_fut_sw)
plt.plot(year_fut,hs_Q3_fut_sw,'b.')
plt.plot(year_fut,fit_fn_Q3_fut_sw(year_fut),'b')
fit_Q4_fut_sw=np.polyfit(year_fut,hs_Q4_fut_sw,1)
fit_fn_Q4_fut_sw=np.poly1d(fit_Q4_fut_sw)
plt.plot(year_fut,hs_Q4_fut_sw,'y.')
plt.plot(year_fut,fit_fn_Q4_fut_sw(year_fut),'y')
fit_Q14_fut_sw=np.polyfit(year_fut,hs_Q14_fut_sw,1)
fit_fn_Q14_fut_sw=np.poly1d(fit_Q14_fut_sw)
plt.plot(year_fut,hs_Q14_fut_sw,'r.')
plt.plot(year_fut,fit_fn_Q14_fut_sw(year_fut),'y')
fit_Q16_fut_sw=np.polyfit(year_fut,hs_Q16_fut_sw,1)
fit_fn_Q16_fut_sw=np.poly1d(fit_Q16_fut_sw)
plt.plot(year_fut,hs_Q16_fut_sw,'c.')
plt.plot(year_fut,fit_fn_Q16_fut_sw(year_fut),'c')
plt.legend(loc='best')
plt.xlabel('Year')
plt.ylabel('Significant Wave Height annual averages SW England')
plt.title('Time series of Significant Wave Height')
plt.show()
Code for boxplots:
python2.7
from pylab import *
import netCDF4
data=(hs_Q0_con_sw,hs_Q3_con_sw,hs_Q4_con_sw,hs_Q14_con_sw,hs_Q16_con_sw)
figure(1)
boxplot(data)
labels=('QO no pert','Q3 low sens','Q4 low sens','Q14 high sens','Q16 high
sens')
xticks(range(1,6),labels,rotation=15)
xlabel('Ensemble Member')
ylabel('Significant Wave Height Annual Average')
title('Significant Wave Height SW England 1981-2010')
show()
If anybody knows how I could integrate these two plots I would be eternally
grateful!
Thanks,
Jamie
--
https://mail.python.org/mailman/listinfo/python-list
Re: Micro Python -- a lean and efficient implementation of Python 3
Chris Angelico writes: > I don't have an actual use-case for this, as I don't target > microcontrollers, but I'm curious: What parts of Py3 syntax aren't > supported? I meant to say % formatting for strings but that's apparently been added recently. My previous micropython build was from February. -- https://mail.python.org/mailman/listinfo/python-list
Classic Arcade Games for Windows
Classic Arcade Games for Windows at: http://home.eol.ca/~knave/index.htm E-mail questions to: kn...@eol.ca -- Books and Games at: http://home.eol.ca/~knave/index.htm -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode and Python - how often do you index strings?
On 2014-06-06 10:47, Johannes Bauer wrote:
> > Personally I tend toward rstrip('\r\n') so that I don't have to
> > worry about files with alternative line terminators.
>
> Hm, I was under the impression that Python already took care of
> removing the \r at a line ending. Checking that right now:
>
> (DOS encoded file "y")
> >>> for line in open("y", "r"): print(line.encode("utf-8"))
> ...
> b'foo\n'
> b'bar\n'
> b'moo\n'
> b'koo\n'
>
> Yup, the \r was removed automatically. Are there cases when it
> isn't?
It's possible if the file is opened as binary:
>>> f = file('delme.txt', 'wb')
>>> f.write('hello\r\nworld\r\n')
>>> f.close()
>>> f = file('delme.txt', 'rb')
>>> for row in f: print repr(row)
...
'hello\r\n'
'world\r\n'
>>> f.close()
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Having trouble in expressing constraints in Python
Thanks a lot Ian. Your post helped me understand the problem in a much better
way and I've solved the first objective thanks to you but incase of my second
objective which is minimize the number of nodes, I have got one of the weirdest
looking constraints which I don't know how to express in Python because python
basically takes matrices and inputs them into cplex. My constraint is as below.
Thsi was what I wrote in AMPL
minimize phy_nodes: sum {w in PHY_NODES} x_ns[w] ;
s.t. Phy_nodes_Eq{w in PHY_NODES, dns in DEMAND}:
x_ns[w] = 1 ==> x_SGW[dns, w] + x_PGW[dns, w] + x_MME[dns, w] + x_IMS[dns, w] +
x_PoP[dns, w] >= 1
else x_SGW[dns, w] + x_PGW[dns, w] + x_MME[dns, w] + x_IMS[dns, w] + x_PoP[dns,
w] = 0;
Could you help me fix this problem?
--
https://mail.python.org/mailman/listinfo/python-list
Re: any wheel experts
On 05/06/2014 22:56, Mark Lawrence wrote: On 05/06/2014 22:42, Ned Deily wrote: In article , Rustom Mody wrote: On Thursday, June 5, 2014 10:21:06 PM UTC+5:30, Robin Becker wrote: I used to create exe files for windows, but the latest and greatest concept is wheels .whl files. If someone here knows (and answers!) great. Else you'll probably get more info here: https://groups.google.com/forum/?pli=1#!forum/python-virtualenv Actually, the Distutils-SIG would be a better place to ask about packaging issues, including wheels: https://mail.python.org/mailman/listinfo/distutils-sig Which I assume is gmane.comp.python.distutils.devel for people like myself who like the one stop shop :) thanks all, I'll query over there -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Terry Reedy writes: > On 6/5/2014 4:07 PM, Alain Ketterlin wrote: > >>> When I compile Cython modules I use LLVM on this computer. >> >> Cython is not Python, it is another language, with an incompatible >> syntax. > > Cython compiles Python with optional extensions that allow additional > speed ups over compiling Python as is. In other word, the Cython > language is a Python superset. You're right. What I question is the fact that anybody uses Cython without the additional syntax. There is little chance that a "pure" Python program will see any significant speedup when compiled with Cython (or, if it does, it means that the "canonical" Python interpreter has some sub-optimal behavior that will, eventually, be corrected). The nice thing with optional type annotations and an hypothetical Python compiler would be that you could, e.g., continue using the interpreter during development and then compile for production use. Or whatever mix you need. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Sturla Molden writes: > Alain Ketterlin wrote: > >> Many of these students suggest Python as the >> development language (they learned it and liked it), and the suggestion >> is (almost) always rejected, in favor of Java or C# or C/C++. > > And it was almost always the wrong decision... I think they know better than you and me. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Chris Angelico writes: > On Fri, Jun 6, 2014 at 7:23 AM, Mark Lawrence wrote: >> On 05/06/2014 21:07, Alain Ketterlin wrote: >>> >>> Sturla Molden writes: >>> On 05/06/14 10:14, Alain Ketterlin wrote: > Type safety. Perhaps. Python has strong type safety. >>> >>> Come on. >> >> I don't understand that comment, please explain. > > "Type safety" means many different things to different people. What > Python has is untyped variables, and hierarchically typed objects. > It's impossible to accidentally treat an integer as a float, and have > junk data [1]. It's impossible in Swift as well. > It's impossible to accidentally call a base class's method when you > ought to have called the overriding method in the subclass, which is a > risk in C++ [2]. I don't how this can happen in C++, unless you actually have an instance of the base class. Anyway, I didn't mention C++. [I agree with the rest of your explanation.] -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: Forking PyPI package
Wiktor writes: > On Fri, 6 Jun 2014 03:37:56 +1000, Chris Angelico wrote: > >> On Fri, Jun 6, 2014 at 2:56 AM, Wiktor wrote: >>> I guess, I'll try to do what Chris proposed. Forget about this >>> implementation and write python script from the scratch looking only at the >>> original JavaScript version. :-/ >> >> Sadly, that may be your only safe option. >> >> Let this be a lesson to all: If you want something to be free >> software, make it very clear, because "it looks like he meant that to >> be open source" just isn't enough :( > > Lesson taken. ;-) > Interesting thing is, that for another 4 people, lack of license in this > script wasn't problem to publish its modified version. I've just searched > phrase "pwdhash" on GitHub, to simply check if someone else hadn't port > this script to Python3 earlier, or maybe ported it (with proper license) to > Python2 so I would have better start. And I've found practically the same > script here: https://github.com/ali01/pwdhash.py, forked then 3 times. > Of course I'm not going to act now "Oh, they could do that without > consequences, so why should I bother?" - no, I'm going to do this right (as > a good start in OS community) - but it feels awkward now. ;-) Have you tried to open an issue about clarifying the license terms [1] ? [1]: https://github.com/abbot/pwdhash/issues/new Or better yet, submit a pull request that specifies the license to the standard you need? I've dealt with the author in the past. I see no reason, he would refuse to accept PR if license=BSD in setup.py is not enough. -- akira -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Sturla Molden writes: > On 05/06/14 22:27, Alain Ketterlin wrote: >> I have seen dozens of projects where Python was dismissed because of the >> lack of static typing, and the lack of static analysis tools. [...] > When is static analysis actually needed and for what purpose? For example WCET analysis (where predictability is more important than performance). Or code with strong security constraint. Or overflow detection tools. Or race condition analyzers. And there are many others. And I don't even mention engineering tools for dependence analysis, packaging, etc. (or even IDEs). > [...] But still they avoid Ada [...] Sorry, I forgot Ada in my list. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode and Python - how often do you index strings?
On Fri, 06 Jun 2014 10:47:44 +0200, Johannes Bauer wrote: > Hm, I was under the impression that Python already took care of removing > the \r at a line ending. Checking that right now: [snip example] This is called "Universal Newlines". Technically it is a build-time option which applies when you build the Python interpreter from source, so, yes, some Pythons may not implement it at all. But I think that it has been on by default for a long time, and the option to turn it off may have been removed in Python 3.3 or 3.4. In practical terms, you should normally expect it to be on. Here's the PEP that introduced it: http://legacy.python.org/dev/peps/pep-0278/ The idea is that when universal newlines support is enabled, by default will convert any of \n, \r or \r\n into \n when reading from a file in text mode, and convert back the other way when writing the file. In binary mode, newlines are *never* changed. In Python 3, you can return end-of-lines unchanged by passing newline='' to the open() function. https://docs.python.org/2/library/functions.html#open https://docs.python.org/3/library/functions.html#open -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On 05/06/2014 18:16, Ian Kelly wrote: . How should e.g. bytes.upper() be implemented then? The correct behavior is entirely dependent on the encoding. Python 2 just assumes ASCII, which at best will correctly upper-case some subset of the string and leave the rest unchanged, and at worst could corrupt the string entirely. There are some things that were dropped that should not have been, but my impression is that those are being worked on, for example % formatting in PEP 461. bytes.upper should have done exactly what str.upper in python 2 did; that way we could have at least continued to do the wrong thing :) -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Fri, Jun 6, 2014 at 9:20 PM, Alain Ketterlin wrote: >> It's impossible to accidentally call a base class's method when you >> ought to have called the overriding method in the subclass, which is a >> risk in C++ [2]. > > I don't how this can happen in C++, unless you actually have an instance > of the base class. Anyway, I didn't mention C++. Mostly if you forget to declare the method 'virtual'; there are other ways to muck things up, but that's the main one. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Fri, 06 Jun 2014 02:21:54 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : > >> In any case, I reject your premise. ALL data types are constructed on >> top of bytes, > > Only in a very dull sense. I agree with you that this is a very dull, unimportant sense. And I think it's dullness applies equally to the situation you somehow think is meaningfully exciting: Text is made of bytes! If you squint, you can see those bytes! Therefore text is not a first class data type!!! To which my answer is, yes text is made of bytes, yes, you can expose those bytes, and no your conclusion doesn't follow. >> and so long as you allow applications *any way* to coerce data types to >> different data types, you allow them to see "inside the black box". > > I can't see the bytes inside Python objects, including strings, and > that's how it is supposed to be. That's because Python the language doesn't allow you to coerce types to other types, except possibly through its interface to the underlying C implementation, ctypes. But Python allows you to write extensions in C, and that gives you the full power to take any data structure and turn it into any other data structure. Even bytes. > Similarly, I can't (easily) see how files are laid out on hard disks. > That's a true abstraction. Nothing in linux presents data, though, > except through bytes. Incorrect. Linux presents data as text all the time. Look at the prompt: its treated as text, not numbers. You type commands using a text interface. The commands are made of words like ls, dd and ps, not numbers like 0x6C73, 0x6464 and 0x7073. Applications like grep are based on line- based files, and "line" is a text concept, not a byte concept. Consider: [steve@ando ~]$ echo -e '\x41\x42\x43' ABC The assumption of *text* is so strong in the echo application that by default you cannot enter numeric escapes at all. Without the -e switch, echo assumes that numeric escapes represent themselves as character literals: [steve@ando ~]$ echo '\x41\x42\x43' \x41\x42\x43 -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Connect to VectorWise database usin Python
On Monday, 2 June 2014 09:38:44 UTC+5:30, sukesh.b...@thomsonreuters.com wrote: > Hi, > > > > Using python(2.7.2) I am not able to connect to Vector Wise database. Can you > suggest me how I can connect to it. If you don't mind step by step > L. > > > > Regards, > > Sukesh. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
Steven D'Aprano : > Incorrect. Linux presents data as text all the time. Look at the prompt: > its treated as text, not numbers. Of course there is a textual human interface. However, from the point of view of virtually every OS component, it's bytes. > Consider: > > [steve@ando ~]$ echo -e '\x41\x42\x43' > ABC "echo" doesn't know it's emitting text. It would be perfectly happy to emit binary gibberish. The output goes to the pty which doesn't care about the textual interpretation, either. Finally, the terminal (emulation program) translates the incoming bytes to textual glyphs to the best of its capabilities. Anyway, what interests me mostly is that I routinely build programs and systems that talk to each other over files, pipes, sockets and devices. I really need to micromanage that data. I'm fine with encoding text if that's the suitable interpretation. I just think Python is overreaching by making the text interpretation the default for the standard streams and files and guessing the correct encoding. Note that subprocess.Popen() wisely assumes binary pipes. Unfortunately the subprocess might be a python program that opens the standard streams in the text mode... Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Matplotlib - specifying bin widths
On 06/06/2014 10:03, Jamie Mitchell wrote: On Thursday, June 5, 2014 4:54:16 PM UTC+1, Jamie Mitchell wrote: Hello all! Instead of setting the number of bins I want to set the bin width. I would like my bins to go from 1.7 to 2.4 in steps of 0.05. How do I say this in the code? Cheers, Jamie That's great thanks Mark. No problem :) In return would you please use the mailing list https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- 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
RE: Automating windows media player on win7
Thanks a lot mate.
You just made my day.
I have looked around the net but cannot find the controls available.
I would like to be able to:
- get current playing track
- get wmplayer state (playing/paused/stopped)
- get the selected sound device
Thanks a lot
Br
Deo
-Original Message-
From: Python-list [mailto:python-list-bounces+demu=senncom@python.org] On
Behalf Of MRAB
Sent: 4. juni 2014 21:23
To: python-list@python.org
Subject: Re: Automating windows media player on win7
On 2014-06-03 09:10, Deogratius Musiige wrote:
> Hi guys,
>
> I have been fighting with automating wmplayer but with no success.
>
> It looks to me that using the .OCX would be the best option. I found
> the code below on the net but I cannot get it to work.
>
> I can see from device manager that a driver is started by I get no
> audio out.
>
> What am I doing wrong guys?
>
> # this program will play MP3, WMA, MID, WAV files via the
> WindowsMediaPlayer from win32com.client import Dispatch
>
> mp = Dispatch("WMPlayer.OCX")
> tune = mp.newMedia("./plays.wav")
> mp.currentPlaylist.appendItem(tune)
> mp.controls.play()
> raw_input("Press Enter to stop playing")
> mp.controls.stop()
>
I've found that adding PlayItem and sleep seems to work:
#! python2.7
# -*- coding: utf-8 -*-
from win32com.client import Dispatch
from time import sleep
mp = Dispatch("WMPlayer.OCX")
tune = mp.NewMedia(r"./plays.wav")
mp.CurrentPlaylist.AppendItem(tune)
mp.Controls.Play()
sleep(1)
mp.Controls.PlayItem(tune)
raw_input("Press Enter to stop playing")
mp.Controls.Stop()
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On 06/05/2014 11:30 AM, Marko Rauhamaa wrote: > How text is represented is very different from whether text is a fundamental data type. A fundamental text file is such that ordinary operating system facilities can't see inside the black box (that is, they are *not* encoded as far as the applications go). Of course they are. It may be an ASCII-encoding of some flavor or other, or something really (to me) strange -- but an encoding is most assuredly in affect. ASCII is *not* the state of "this string has no encoding" -- that would be Unicode; a Unicode string, as a data type, has no encoding. To transport it, store it, etc., it must (usually?) be encoded into something -- utf-8, ASCII, turkish, or whatever subset is agreed upon and will hopefully contain all the Unicode characters needed for the string to be properly represented. The realization that ASCII was, in fact, an encoding was a big paradigm shift for me, but a necessary one. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
Ethan Furman : > On 06/05/2014 11:30 AM, Marko Rauhamaa wrote: >> A fundamental text file is such that ordinary operating system >> facilities can't see inside the black box (that is, they are *not* >> encoded as far as the applications go). > > Of course they are. How would you know? > It may be an ASCII-encoding of some flavor or other, or something > really (to me) strange -- but an encoding is most assuredly in affect. Outside metaphysics, that statement is only meaningful if you have access to the encoding. > ASCII is *not* the state of "this string has no encoding" -- that > would be Unicode; a Unicode string, as a data type, has no encoding. Huh? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode and Python - how often do you index strings?
On 2014-06-06, Roy Smith wrote: >> Roy is using MT-NewsWatcher as a client. > > Yes. Except for the fact that it hasn't kept up with unicode, I find > the U/I pretty much perfect. I imagine at some point I'll be force to > look elsewhere, but then again, netnews is pretty much dead. There are still a few active groups, but reading e-mail lists via NNTP (in my case using slrn) via gmane is a huge reason to have an efficient, well-designed "news" client. If usenet does really pack it in someday and I have to switch from comp.lang.python to the mailing list, it will be done by pointing slrn at new.gmane.org -- not by having all those e-mails sent to me so I can try to sort through them... -- Grant Edwards grant.b.edwardsYow! My NOSE is NUMB! at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Automating windows media player on win7
On 06/06/2014 07:39 AM, Deogratius Musiige wrote: > Thanks a lot mate. > > You just made my day. > I have looked around the net but cannot find the controls available. > > I would like to be able to: > - get current playing track > - get wmplayer state (playing/paused/stopped) > - get the selected sound device You might want to ask on the python win32-specific mailing list. https://mail.python.org/mailman/listinfo/python-win32 If you're not married to Windows Media Player, VLC is designed for this sort of thing. It's fully remoteable using a simple socket interface. https://github.com/CodeSturgeon/vlcrc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On 06/05/2014 09:32 AM, Steven D'Aprano wrote: But whatever the situation, and despite our differences of opinion about Unicode, THANK YOU for having updated ReportLabs to 3.3. +1000 -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On 06/06/2014 08:10 AM, Marko Rauhamaa wrote: > Ethan Furman : >> ASCII is *not* the state of "this string has no encoding" -- that >> would be Unicode; a Unicode string, as a data type, has no encoding. > > Huh? It's this very fact that trips of JMF in his rants about FSR. Thank you to Ethan for putting it so succinctly. What part of his statement are you saying "Huh?" about? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Fri, Jun 6, 2014 at 11:24 PM, Ethan Furman wrote: > On 06/05/2014 11:30 AM, Marko Rauhamaa wrote: >> >> >> How text is represented is very different from whether text is a >> fundamental data type. A fundamental text file is such that ordinary >> operating system facilities can't see inside the black box (that is, >> they are *not* encoded as far as the applications go). > > Of course they are. It may be an ASCII-encoding of some flavor or other, or > something really (to me) strange -- but an encoding is most assuredly in > affect. Allow me to explain what I think Marko's getting at here. In most file systems, a file exists on the disk as a set of sectors of data, plus some metadata including the file's actual size. When you ask the OS to read you that file, it goes to the disk, reads those sectors, truncates the data to the real size, and gives you those bytes. It's possible to mount a file as a directory, in which case the physical representation is very different, but the file still appears the same. In that case, the OS goes reading some part of the file, maybe decompresses it, and gives it to you. Same difference. These files still contain bytes. A "fundamental text file" would be one where, instead of reading and writing bytes, you read and write Unicode text. Since the hard disk still works with sectors and bytes, it'll still be stored as such, but that's an implementation detail; and you could format your disk UTF-8 or UTF-16 or FSR or anything you like, and the only difference you'd see is performance. This could certainly be done, in theory. I don't know how well it'd fit with any of the popular OSes of today, but it could be done. And these files would not have an encoding; their on-platter representations would, but that's purely implementation - the text that you wrote out and the text that you read in are the same text, and there's been no encoding visible. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
Michael Torrie : > On 06/06/2014 08:10 AM, Marko Rauhamaa wrote: >> Ethan Furman : >>> ASCII is *not* the state of "this string has no encoding" -- that >>> would be Unicode; a Unicode string, as a data type, has no encoding. >> >> Huh? > > [...] > > What part of his statement are you saying "Huh?" about? Unicode, like ASCII, is a code. Representing text in unicode is encoding. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Da dove prende python il default timezone?
Whoops sorry, i thought this was the italian group -- https://mail.python.org/mailman/listinfo/python-list
Da dove prende python il default timezone?
Ho acquistato un server di test in canada; Installato debian 7, settato il
timezone di Roma tramite dpkg-reconfigure tzdata e sembra tutto ok;
Però sembra che python di default prenda sempre il timezone canadese:
import os, time
from time import strftime
strftime("%H") # Le 18 sono le 23!
Ora, posso settare il timezone nello script, ma per impostarlo a livello
"globale" come si fà?
Scusate se è una domanda scema ma con python sono mlto alle prime armi ;)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Sat, Jun 7, 2014 at 1:32 AM, Marko Rauhamaa wrote: > Michael Torrie : > >> On 06/06/2014 08:10 AM, Marko Rauhamaa wrote: >>> Ethan Furman : ASCII is *not* the state of "this string has no encoding" -- that would be Unicode; a Unicode string, as a data type, has no encoding. >>> >>> Huh? >> >> [...] >> >> What part of his statement are you saying "Huh?" about? > > Unicode, like ASCII, is a code. Representing text in unicode is > encoding. Yes and no. "ASCII" means two things: Firstly, it's a mapping from the letter A to the number 65, from the exclamation mark to 33, from the backslash to 92, and so on. And secondly, it's an encoding of those numbers into the lowest seven bits of a byte, with the high byte left clear. Between those two, you get a means of representing the letter 'A' as the byte 0x41, and one of them is an encoding. "Unicode", on the other hand, is only the first part. It maps all the same characters to the same numbers that ASCII does, and then adds a few more... a few followed by a few, followed by... okay, quite a lot more. Unicode specifies that the character OK HAND SIGN, which looks like 👌 if you have the right font, is number 1F44C in hex (128076 decimal). This is the "Universal Character Set" or UCS. ASCII could specify a single encoding, because that encoding makes sense for nearly all purposes. (There are times when you transmit ASCII text and use the high bit to mean something else, like parity or "this is the end of a word" or something, but even then, you follow the same convention of packing a number into the low seven bits of a byte.) Unicode can't, because there are many different pros and cons to the different encodings, and so we have UCS Transformation Formats like UTF-8 and UTF-32. Each one is an encoding that maps a codepoint to a sequence of bytes. You can't represent text in "Unicode" in a computer. Somewhere along the way, you have to figure out how to store those codepoints as bytes, or something more concrete (you could, for instance, use a Python list of Python integers; I can't say that it would be in any way more efficient than alternatives, but it would be plausible); and that's the encoding. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote: > Michael Torrie : > >> On 06/06/2014 08:10 AM, Marko Rauhamaa wrote: >>> Ethan Furman : ASCII is *not* the state of "this string has no encoding" -- that would be Unicode; a Unicode string, as a data type, has no encoding. >>> >>> Huh? >> >> [...] >> >> What part of his statement are you saying "Huh?" about? > > Unicode, like ASCII, is a code. Representing text in unicode is > encoding. A Unicode string as an abstract data type has no encoding. It is a Platonic ideal, a pure form like the real numbers. There are no bytes, no bits, just code points. That is what Ethan means. A Unicode string like this: s = u"NOBODY expects the Spanish Inquisition!" should not be thought of as a bunch of bytes in some encoding, but as an array of code points. Eventually the abstraction will leak, all abstractions do, but not for a very long time. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Friday, June 6, 2014 9:27:51 PM UTC+5:30, Steven D'Aprano wrote: > On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote: > > Michael Torri: > >> On 06/06/2014 08:10 AM, Marko Rauhamaa wrote: > >>> Ethan Furman : > ASCII is *not* the state of "this string has no encoding" -- that > would be Unicode; a Unicode string, as a data type, has no encoding. > >>> Huh? > >> [...] > >> What part of his statement are you saying "Huh?" about? > > Unicode, like ASCII, is a code. Representing text in unicode is > > encoding. > A Unicode string as an abstract data type has no encoding. It is a > Platonic ideal, a pure form like the real numbers. There are no bytes, no > bits, just code points. That is what Ethan means. A Unicode string like > this: > s = u"NOBODY expects the Spanish Inquisition!" > should not be thought of as a bunch of bytes in some encoding, but as an > array of code points. Eventually the abstraction will leak, all > abstractions do, but not for a very long time. "Should not be thought of" yes thats the Python3 world view Not even the Python2 world view And very far from the classic Unix world view. As Ned Batchelder says in Unipain: http://nedbatchelder.com/text/unipain.html : Programmers should use the 'unicode sandwich'to avoid 'unipain': Bytes on the outside, Unicode on the inside, encode/decode at the edges. The discussion here is precisely about these edges Combine that with Chris': > Yes and no. "ASCII" means two things: Firstly, it's a mapping from the > letter A to the number 65, from the exclamation mark to 33, from the > backslash to 92, and so on. And secondly, it's an encoding of those > numbers into the lowest seven bits of a byte, with the high byte left > clear. Between those two, you get a means of representing the letter > 'A' as the byte 0x41, and one of them is an encoding. and the situation appears quite the opposite of Ethan's description: In the 'old world' ASCII was both mapping and encoding and so there was never a justification to distinguish encoding from codepoint. It is unicode that demands these distinctions. If we could magically go to a world where the number of bits in a byte was 32 all this headache would go away. [Actually just 21 is enough!] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Sat, Jun 7, 2014 at 2:21 AM, Rustom Mody wrote: > Combine that with Chris': > >> Yes and no. "ASCII" means two things: Firstly, it's a mapping from the >> letter A to the number 65, from the exclamation mark to 33, from the >> backslash to 92, and so on. And secondly, it's an encoding of those >> numbers into the lowest seven bits of a byte, with the high byte left >> clear. Between those two, you get a means of representing the letter >> 'A' as the byte 0x41, and one of them is an encoding. > > and the situation appears quite the opposite of Ethan's description: > > In the 'old world' ASCII was both mapping and encoding and so there was > never a justification to distinguish encoding from codepoint. > > It is unicode that demands these distinctions. > > If we could magically go to a world where the number of bits in a byte was 32 > all this headache would go away. [Actually just 21 is enough!] An ASCII mentality lets you be sloppy. That doesn't mean the distinction doesn't exist. When I first started programming in C, int was *always* 16 bits long and *always* little-endian (because I used only one compiler). I could pretend that those bits in memory actually were that integer, that there were no other ways that integer could be encoded. That doesn't mean that encodings weren't important. And as soon as I started working on a 32-bit OS/2 system, and my ints became bigger, I had to concern myself with that. Even more so when I got into networking, and byte order became important to me. And of course, these days I work with integers that are encoded in all sorts of different ways (a Python integer isn't just a puddle of bytes in memory), and I generally let someone else take care of the details, but the encodings are still there. ASCII was once your one companion, it was all that mattered. ASCII was once a friendly encoding, then your world was shattered. Wishing it were somehow here again, wishing it were somehow near... sometimes it seemed, if you just dreamed, somehow it would be here! Wishing you could use just bytes again, knowing that you never would... dreaming of it won't help you to do all that you dream you could! It's time to stop chasing the phantom and start living in the Raoul world... err, the real world. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Micro Python -- a lean and efficient implementation of Python 3
On Jun 4, 2014, at 4:01 AM, Tim Chase wrote: > If you use UTF-8 for everything It seems to me, that increasingly other libraries (C, etc), use utf8 as the preferred string interchange format. It’s universal, not prone to endian issues, etc. So one *advantage* you gain for using utf8 internally, is any time you need to hand a string to an external thing, it’s just ready. An app that reserves its internal string processing to streaming based ones but has to to hand strings to external libraries a lot (e.g. cairo) might actually benefit using utf8 internally, because a) it’s not doing the linear search for the odd character address and b) it no longer needs to decode/encode every time it sends or receives a string to an external library. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
Chris Angelico : > "ASCII" means two things: Firstly, it's a mapping from the letter A to > the number 65, from the exclamation mark to 33, from the backslash to > 92, and so on. And secondly, it's an encoding of those numbers into > the lowest seven bits of a byte, with the high byte left clear. > Between those two, you get a means of representing the letter 'A' as > the byte 0x41, and one of them is an encoding. The American Standard Code for Information Interchange [...] is a character-encoding scheme [...] http://en.wikipedia.org/wiki/ASCII> > "Unicode", on the other hand, is only the first part. It maps all the > same characters to the same numbers that ASCII does, and then adds a > few more... a few followed by a few, followed by... okay, quite a lot > more. Unicode specifies that the character OK HAND SIGN, which looks > like 👌 if you have the right font, is number 1F44C in hex (128076 > decimal). This is the "Universal Character Set" or UCS. Unicode is a computing industry standard for the consistent encoding, representation and handling of text [...] http://en.wikipedia.org/wiki/Unicode> Each standard assigns numbers to letters and other symbols. In a word, each is a code. That's what their names say, too. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 6/6/2014 7:11 AM, Alain Ketterlin wrote: Terry Reedy writes: On 6/5/2014 4:07 PM, Alain Ketterlin wrote: When I compile Cython modules I use LLVM on this computer. Cython is not Python, it is another language, with an incompatible syntax. Cython compiles Python with optional extensions that allow additional speed ups over compiling Python as is. In other word, the Cython language is a Python superset. I am assuming here that the claim to have reached this goal is correct. You're right. What I question is the fact that anybody uses Cython without the additional syntax. There is little chance that a "pure" Python program will see any significant speedup when compiled with I believe the Cython author has claimed a 2x-5x speedup for stdlib modules when compiled 'as is'. Cython (or, if it does, it means that the "canonical" Python interpreter has some sub-optimal behavior that will, eventually, be corrected). I believe that there is some inherent overhead that Cython bypasses. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Friday, June 6, 2014 10:18:41 PM UTC+5:30, Chris Angelico wrote: > On Sat, Jun 7, 2014 at 2:21 AM, Rustom Mody wrote: > > Combine that with Chris': > >> Yes and no. "ASCII" means two things: Firstly, it's a mapping from the > >> letter A to the number 65, from the exclamation mark to 33, from the > >> backslash to 92, and so on. And secondly, it's an encoding of those > >> numbers into the lowest seven bits of a byte, with the high byte left > >> clear. Between those two, you get a means of representing the letter > >> 'A' as the byte 0x41, and one of them is an encoding. > > and the situation appears quite the opposite of Ethan's description: > > In the 'old world' ASCII was both mapping and encoding and so there was > > never a justification to distinguish encoding from codepoint. > > It is unicode that demands these distinctions. > > If we could magically go to a world where the number of bits in a byte was > > 32 > > all this headache would go away. [Actually just 21 is enough!] > An ASCII mentality lets you be sloppy. That doesn't mean the > distinction doesn't exist. When I first started programming in C, int > was *always* 16 bits long and *always* little-endian (because I used > only one compiler). I could pretend that those bits in memory actually > were that integer, that there were no other ways that integer could be > encoded. That doesn't mean that encodings weren't important. And as > soon as I started working on a 32-bit OS/2 system, and my ints became > bigger, I had to concern myself with that. Even more so when I got > into networking, and byte order became important to me. And of course, > these days I work with integers that are encoded in all sorts of > different ways (a Python integer isn't just a puddle of bytes in > memory), and I generally let someone else take care of the details, > but the encodings are still there. > ASCII was once your one companion, it was all that mattered. ASCII was > once a friendly encoding, then your world was shattered. Wishing it > were somehow here again, wishing it were somehow near... sometimes it > seemed, if you just dreamed, somehow it would be here! Wishing you > could use just bytes again, knowing that you never would... dreaming > of it won't help you to do all that you dream you could! > It's time to stop chasing the phantom and start living in the Raoul > world... err, the real world. :) I thought that "If only bytes were 21+ bits wide" would sound sufficiently nonsensical, that I did not need to explicitly qualify it as a utopian dream! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
Steven D'Aprano : > On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote: >> Unicode, like ASCII, is a code. Representing text in unicode is >> encoding. > > A Unicode string as an abstract data type has no encoding. Unicode itself is an encoding. See it in action here: 72 101 108 108 111 44 32 119 111 114 108 100 > It is a Platonic ideal, a pure form like the real numbers. Far from it. It is a mapping from symbols to integers. The symbols are the Platonic ones. The Unicode/ASCII encoding above represents the same "Platonic" string as this ESCDIC one: 212 133 147 147 150 107 64 166 150 153 137 132 > Unicode string like this: > > s = u"NOBODY expects the Spanish Inquisition!" > > should not be thought of as a bunch of bytes in some encoding, Encoding is not tied to bytes or even computers. People can speak in code, after all. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Friday, June 6, 2014 10:32:47 PM UTC+5:30, Marko Rauhamaa wrote: > Chris Angelico : > > "ASCII" means two things: Firstly, it's a mapping from the letter A to > > the number 65, from the exclamation mark to 33, from the backslash to > > 92, and so on. And secondly, it's an encoding of those numbers into > > the lowest seven bits of a byte, with the high byte left clear. > > Between those two, you get a means of representing the letter 'A' as > > the byte 0x41, and one of them is an encoding. >The American Standard Code for Information Interchange [...] is a >character-encoding scheme [...] http://en.wikipedia.org/wiki/Talk:ASCII#Character_set_vs._Character_encoding.3F -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Sat, Jun 7, 2014 at 3:11 AM, Marko Rauhamaa wrote: > Encoding is not tied to bytes or even computers. People can speak in > code, after all. Obligatory: http://xkcd.com/257/ ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
Marko Rauhamaa : > Far from it. It is a mapping from symbols to integers. The symbols are > the Platonic ones. Well, of course, even the symbols are a code. Letters code sounds and digits code numbers. And the sounds and numbers code ideas. Now we are getting close to being truly Platonic. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Sat, Jun 7, 2014 at 3:04 AM, Rustom Mody wrote: >> ASCII was once your one companion, it was all that mattered. ASCII was >> once a friendly encoding, then your world was shattered. Wishing it >> were somehow here again, wishing it were somehow near... sometimes it >> seemed, if you just dreamed, somehow it would be here! Wishing you >> could use just bytes again, knowing that you never would... dreaming >> of it won't help you to do all that you dream you could! > >> It's time to stop chasing the phantom and start living in the Raoul >> world... err, the real world. :) > > I thought that "If only bytes were 21+ bits wide" would sound sufficiently > nonsensical, that I did not need to explicitly qualify it as a utopian dream! Humour never dies! ChrisA (In case it's not obvious, by the way, everything I said above is a reference to the Phantom of the Opera.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Sat, Jun 7, 2014 at 3:13 AM, Rustom Mody wrote: > On Friday, June 6, 2014 10:32:47 PM UTC+5:30, Marko Rauhamaa wrote: >> Chris Angelico : > >> > "ASCII" means two things: Firstly, it's a mapping from the letter A to >> > the number 65, from the exclamation mark to 33, from the backslash to >> > 92, and so on. And secondly, it's an encoding of those numbers into >> > the lowest seven bits of a byte, with the high byte left clear. >> > Between those two, you get a means of representing the letter 'A' as >> > the byte 0x41, and one of them is an encoding. > >>The American Standard Code for Information Interchange [...] is a >>character-encoding scheme [...] > And a similar argument to this is seen on that page's talk page! > http://en.wikipedia.org/wiki/Talk:ASCII#Character_set_vs._Character_encoding.3F Which proves that Wikipedia is exactly as reliable as a mailing list. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Micro Python -- a lean and efficient implementation of Python 3
In article , Travis Griggs wrote: > On Jun 4, 2014, at 4:01 AM, Tim Chase wrote: > > > If you use UTF-8 for everything > > It seems to me, that increasingly other libraries (C, etc), use utf8 as the > preferred string interchange format. It¹s universal, not prone to endian > issues, etc. One of the important etc factors is, "Since it's the most commonly used, it's the one that other people are most likely to have implemented correctly". In the real world, these are important considerations. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On 6/6/14 1:11 PM, Marko Rauhamaa wrote: Steven D'Aprano : On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote: Unicode, like ASCII, is a code. Representing text in unicode is encoding. A Unicode string as an abstract data type has no encoding. Unicode itself is an encoding. See it in action here: 72 101 108 108 111 44 32 119 111 114 108 100 It is a Platonic ideal, a pure form like the real numbers. Far from it. It is a mapping from symbols to integers. The symbols are the Platonic ones. The Unicode/ASCII encoding above represents the same "Platonic" string as this ESCDIC one: 212 133 147 147 150 107 64 166 150 153 137 132 Unicode string like this: s = u"NOBODY expects the Spanish Inquisition!" should not be thought of as a bunch of bytes in some encoding, Encoding is not tied to bytes or even computers. People can speak in code, after all. Marko, you are right about the broader English meaning of the word "encoding". The original point here was that "Unicode text" provides no information about what sequence of bytes is at work. In the Unicode ecosystem, an encoding is a specification of how the text will be represented in a byte stream. Saying something is "Unicode" doesn't provide that information. You have to say, "UTF8" or "UTF16" or "UCS2", etc, in order to know how bytes will be involved. When Ethan said, "a Unicode string, as a data type, has no encoding," he meant (as he explained) that a Unicode string doesn't require or imply any particular mapping to bytes. I'm sure you understand this, I'm just trying to clarify the different meanings of the word "encoding". Marko -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
try/except/finally
Ok; this is a bit esoteric. So finally is executed regardless of whether an exception occurs, so states the docs. But, I thought, if I from my function first, that should take precedence. au contraire Turns out that if you do this: try: failingthing() except FailException: return 0 finally: return 1 Then finally really is executed regardless... even though you told it to return. That seems odd to me. -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
In article <0a89c96d-de62-42ad-be48-6107ce10d...@googlegroups.com>, Frank B wrote: > Ok; this is a bit esoteric. > > So finally is executed regardless of whether an exception occurs, so states > the docs. > > But, I thought, if I from my function first, that should take > precedence. > > au contraire > > Turns out that if you do this: > > try: > failingthing() > except FailException: > return 0 > finally: > return 1 > > Then finally really is executed regardless... even though you told it to > return. > > That seems odd to me. That's exactly what it's supposed to do. The idea of finally is, "No matter what else happens, including calling sys.exit(), make sure this code executed". It's typically used to release some critical resource which was acquired in the body of the try block. https://docs.python.org/2/reference/compound_stmts.html#the-try-statement says: When a return, break or continue statement is executed in the try suite of a try...finally statement, the finally clause is also executed on the way out.¹ The only way I can think of to bypass a finally block would be to call os._exit(), or send yourself a kill signal. -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
Ok; thanks for the underscore and clarification. Just need to adjust my thinking a bit. -- https://mail.python.org/mailman/listinfo/python-list
How to use SQLite (sqlite3) more efficiently
> The subject line isn't as important as a header, carried invisibly > through, that says that you were replying to an existing post. :) Sorry for my ignorance, but I've never edited email headers before and didn't find any relevant help on Google. Could you please give some more details about how to do what you're referring to, or perhaps point me to a link that would explain more about it? (FYI, I read the Python mailing list on Google Groups, and reply to posts in Thunderbird, sending them to the Python-list email address.) I was thinking that since I've been manually calling conn.commit() in my wxPython program after executing each SQL transaction, it would make sense to use autocommit mode (by setting 'isolation_level' to None). Am I correct about this? I've read on StackOverflow that there can be disadvantages to using autocommit mode for SQL databases in general, but they weren't elaborated. The only one I could think of would be decreased performance if SQL transactions are committed automatically more than necessary (which wouldn't apply in my case). I guess that's also likely why PEP 249 specifies that Python database implementations must have autocommit mode turned off by default. Thank you. -- Timothy -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use SQLite (sqlite3) more efficiently
On Sat, Jun 7, 2014 at 4:15 AM, R Johnson wrote: >> The subject line isn't as important as a header, carried invisibly >> through, that says that you were replying to an existing post. :) > > Sorry for my ignorance, but I've never edited email headers before and > didn't find any relevant help on Google. Could you please give some more > details about how to do what you're referring to, or perhaps point me to a > link that would explain more about it? (FYI, I read the Python mailing list > on Google Groups, and reply to posts in Thunderbird, sending them to the > Python-list email address.) The simple answer is: You don't have to edit headers at all. If you want something to be part of the same thread, you hit Reply and don't change the subject line. If you want something to be a spin-off thread, you hit Reply and *do* change the subject. If you want it to be a brand new thread, you don't hit Reply, you start a fresh message. Any decent mailer will do the work for you. Replying is more than just quoting a bunch of text and copying in the subject line with "Re:" at the beginning. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: try/except/finally
On 6/6/14 1:47 PM, Frank B wrote: Ok; thanks for the underscore and clarification. Just need to adjust my thinking a bit. Did this come up in real code? I've seen this point about finally/return semantics a number of times, but haven't seen real code that needed adjusting based on it. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Da dove prende python il default timezone?
On 2014-06-06 15:37:24 +, Strae said:
Ho acquistato un server di test in canada; Installato debian 7, settato
il timezone di Roma tramite dpkg-reconfigure tzdata e sembra tutto ok;
Però sembra che python di default prenda sempre il timezone canadese
I'm on a very similar setup (Wheezy, server in USA, EU timezone) and my
strftime works as expected:
~> cat /etc/timezone
Europe/Rome
~> date "+%H"
20
~> python -c 'import time; print time.strftime("%H")'
20
Try reconfiguring tzdata package again.
--
Andrea
--
https://mail.python.org/mailman/listinfo/python-list
Regarding Python official website
The Python website is undergoing an overhaul for better looks. Is there anything like a forum where it is being discussed. I mean where the schedule for this is being maintained or the same is being discussed? -- https://mail.python.org/mailman/listinfo/python-list
Re: Regarding Python official website
In article <17ad7280-65dd-4db9-9f4a-7bdd8bb7c...@googlegroups.com>, Aseem Bansal wrote: > The Python website is undergoing an overhaul for better looks. Is there > anything like a forum where it is being discussed. I mean where the schedule > for this is being maintained or the same is being discussed? There is an issue tracker for the new website here: https://github.com/python/pythondotorg/issues?state=open At the moment, that's probably the closest thing to a discussion forum for it although there is still the legacy mailing list for python.org web sites: https://mail.python.org/mailman/listinfo/pydotorg-www -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
os.startfile hanging onto the launched app, or my IDE?
I have been using os.startfile(filepath) to launch files I've created in Python, mostly Excel spreadsheets, text files, or PDFs. When I run my script from my IDE, the file opens as I expect. But if I go back to my script and re-run it, the external program (either Excel, Notepad, or Acrobat Reader) closes all windows and restarts the program. This can, unfortunately, close other files I am working on and thus I lose all my changes to those files. This is happening on Windows 7. I am not sure if it is Python (2.7.5) or my IDE (PyScripter 2.5.3). It seems like Python or the IDE is keeping track of things created by the os.startfile call, but the docs imply this doesn't happen. Is this a quirk of os.startfile? Is there a cleaner way to get Windows to open files without tying back to my program? Thanks, Josh -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use SQLite (sqlite3) more efficiently
Chris Angelico Wrote in message: > On Sat, Jun 7, 2014 at 4:15 AM, R Johnson > wrote: >>> The subject line isn't as important as a header, carried invisibly >>> through, that says that you were replying to an existing post. :) >> >> Sorry for my ignorance, but I've never edited email headers before and >> didn't find any relevant help on Google. Could you please give some more >> details about how to do what you're referring to, or perhaps point me to a >> link that would explain more about it? (FYI, I read the Python mailing list >> on Google Groups, and reply to posts in Thunderbird, sending them to the >> Python-list email address.) > > The simple answer is: You don't have to edit headers at all. If you > want something to be part of the same thread, you hit Reply and don't > change the subject line. If you want something to be a spin-off > thread, you hit Reply and *do* change the subject. If you want it to > be a brand new thread, you don't hit Reply, you start a fresh message. > Any decent mailer will do the work for you. > > Replying is more than just quoting a bunch of text and copying in the > subject line with "Re:" at the beginning. :) > The other half is that in order to be able to reply to a message you have to be reading that message in a mail program, or in a newsreader. Since you (R) are using Thunderbird, you should either subscribe to the mailing list (NOT in digest mode), or set up a newsgroup in Thunderbird from gmane.comp.python.general. If you choose the mailing list, you'll probably want to set up a rule in Thunderbird that moves all incoming messages from the inbox to a dedicated folder. Set that folder to show the threaded view, and you should be in good shape. There's a keystroke that gets you to the next unread message, but all the others are easily accessible. It interprets those headers mentioned above and groups all the replies together. And you use the Reply-list button so the message goes to the list and not the individual. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to use SQLite (sqlite3) more efficiently
On 06/06/2014 22:58, Dave Angel wrote: Chris Angelico Wrote in message: On Sat, Jun 7, 2014 at 4:15 AM, R Johnson wrote: The subject line isn't as important as a header, carried invisibly through, that says that you were replying to an existing post. :) Sorry for my ignorance, but I've never edited email headers before and didn't find any relevant help on Google. Could you please give some more details about how to do what you're referring to, or perhaps point me to a link that would explain more about it? (FYI, I read the Python mailing list on Google Groups, and reply to posts in Thunderbird, sending them to the Python-list email address.) The simple answer is: You don't have to edit headers at all. If you want something to be part of the same thread, you hit Reply and don't change the subject line. If you want something to be a spin-off thread, you hit Reply and *do* change the subject. If you want it to be a brand new thread, you don't hit Reply, you start a fresh message. Any decent mailer will do the work for you. Replying is more than just quoting a bunch of text and copying in the subject line with "Re:" at the beginning. :) set up a newsgroup in Thunderbird from gmane.comp.python.general. That doesn't sound right to me. Surely you set up the newgroup news.gmane.org and then subscribe to the mailing lists, blog feeds or whatever it is that you want? -- 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
Re: Python 3.2 has some deadly infection
On Sat, 07 Jun 2014 01:50:50 +1000, Chris Angelico wrote: > Yes and no. "ASCII" means two things: ASCII means: American Standard Code for Information Interchange aka ASA Standard X3.4-1963 > into the lowest seven bits of a byte, with the high byte left clear. high BIT left clear. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.2 has some deadly infection
On Sat, Jun 7, 2014 at 7:18 AM, Denis McMahon wrote: >> into the lowest seven bits of a byte, with the high byte left clear. > > high BIT left clear. That thing. Unless you have bytes inside bytes (byteception?), you'll only have room for one high bit. Some day I'll get my brain and my fingers to agree on everything we do... but that day is not today. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
http.server.BaseHTTPRequestHandler basic auth logout? Django authentication system for REST interface?
I have some code for a web server. Right now, it uses BaseHTTPRequestHandler with Basic Auth, but we want to be able to log out, and there doesn't appear to be a general way to log out of something using Basic Auth, short of turning to unportable JavaScript. And this needs first and foremost to be machine-callable, so JavaScript probably isn't a great solution for us. Does BaseHTTPRequestHandler add a way of dealing with Basic Auth logout by any chance? I googled about it, and didn't find anything. I could rewrite to work with Django's authentication system I suppose. Does this work reasonably well for REST API's? How do you pass the credentials? Is it a cookie? Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Decorating one method of a class C with another method of class C?
Is there a way of decorating method1 of class C using method2 of class C? It seems like there's a chicken-and-the-egg problem; the class doesn't seem to know what "self" is until later in execution so there's apparently no way to specify @self.method2 when def'ing method1. -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorating one method of a class C with another method of class C?
On Sat, Jun 7, 2014 at 10:14 AM, Dan Stromberg wrote: > Is there a way of decorating method1 of class C using method2 of class C? > > It seems like there's a chicken-and-the-egg problem; the class doesn't > seem to know what "self" is until later in execution so there's > apparently no way to specify @self.method2 when def'ing method1. Since decoration happens at class creation, and arguments like self are available only when the method's actually called, no, there's no way you can define the method with something using information that doesn't exist yet and may change from one call to the next :) What are you trying to do, exactly? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorating one method of a class C with another method of class C?
Dan Stromberg writes: > Is there a way of decorating method1 of class C using method2 of class > C? Can you give a concrete example (i.e. not merely hypothetical) where this would be a useful feature (i.e. an actual improvement over the absence of the feature), and why? > It seems like there's a chicken-and-the-egg problem; the class doesn't > seem to know what "self" is until later in execution so there's > apparently no way to specify @self.method2 when def'ing method1. You're referring specifically to instance methods, it seems. Right, there's no instance *of* the class during the *definition* of the class, so ‘self’ can't refer to such an instance. Also, an instance method needs to get the instance as the first parameter, whereas the decorator must accept the to-be-decorated function as its argument. So I don't see what you're trying to achieve, rather than the more straightforward and clearer use of a decorator function which *isn't* a method in the same class. Can you show a Simple, Self-Contained Complete Example to show us what you're trying to do? More importantly, why you think it should be done this way? -- \“Visitors are expected to complain at the office between the | `\ hours of 9 and 11 a.m. daily.” —hotel, Athens | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: http.server.BaseHTTPRequestHandler basic auth logout? Django authentication system for REST interface?
In article , Dan Stromberg wrote: > I have some code for a web server. Right now, it uses > BaseHTTPRequestHandler with Basic Auth, but we want to be able to log > out, and there doesn't appear to be a general way to log out of > something using Basic Auth, short of turning to unportable JavaScript. > And this needs first and foremost to be machine-callable, so > JavaScript probably isn't a great solution for us. > > Does BaseHTTPRequestHandler add a way of dealing with Basic Auth > logout by any chance? I googled about it, and didn't find anything. > > I could rewrite to work with Django's authentication system I suppose. > Does this work reasonably well for REST API's? How do you pass the > credentials? Is it a cookie? > > Thanks! There's a lot of questions wrapped up in one there. Personally, I would stay away from the BaseHHTPRequestHandler stuff. That's really low level. If you're building a REST API, probably lower than you need to be working. We got a REST-ish API running in django. We let django do the session management for us. That means django drops a session_id cookie on the client. We don't use the django authentication system, but have our own /api/login and /api/logout routes which let us manage the state (i.e. logged in or out) of each session on the backend. This works fine for our web browser clients. For our mobile clients, it still works, but having mobile clients manage the cookie store on their end is annoying (to the mobile app developer). Cookies are great for keeping state on the client side when you're talking to a plain old browser. Once you're talking to a client application (be it a native app on a mobile device, or a javascript app running in a browser), cookies are more trouble than they're worth. If we were to do it all again (and, someday, we will), we would probably skip the cookies all together. We would still have a /api/login route, but instead of tracking sessions by cookies, we would hand the client back (as part of the HTTP data payload) a token. It would be up to the client to present that token back to us with every subsequent request. We would have to keep state on the server side about every extant valid token (but then again, we need to do that now, for each session). Logging out would just be involve invalidating the token. -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorating one method of a class C with another method of class C?
On 6/6/2014 8:14 PM, Dan Stromberg wrote:
Is there a way of decorating method1 of class C using method2 of class C?
It seems like there's a chicken-and-the-egg problem; the class doesn't
seem to know what "self" is until later in execution so there's
apparently no way to specify @self.method2 when def'ing method1.
Class code is executed in a new local namespace, which later becomes the
class attribute space. So you can (sort of), but I cannot see a reason
to do so.
class C:
def deco(f):
print('decorating')
def inner(self):
print('f called')
return f(self)
return inner
@deco
def f(self):
print(self)
del deco # because it is not really a method
# but rather an undecorated static method
c = C()
c.f()
>>>
decorating
f called
<__main__.C object at 0x0348B898>
If deco is decorated as a staticmethod, it has to be called on the class
or an instance thereof after the class is constructed. If deco is
defined outside the class, it can be used both inside and outside.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Alain Ketterlin wrote: >> When is static analysis actually needed and for what purpose? > > For example WCET analysis (where predictability is more important than > performance). Or code with strong security constraint. Or overflow > detection tools. Or race condition analyzers. And there are many others. > And I don't even mention engineering tools for dependence analysis, > packaging, etc. (or even IDEs). You don't have to answer a rhetorical question. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
Alain Ketterlin wrote: > Sturla Molden writes: > >> Alain Ketterlin wrote: >> >>> Many of these students suggest Python as the >>> development language (they learned it and liked it), and the suggestion >>> is (almost) always rejected, in favor of Java or C# or C/C++. >> >> And it was almost always the wrong decision... > > I think they know better than you and me. Now it's my turn to say "oh, come on". Those who make these decisions have likely never written a line of code in their life. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: Missing stack frames?
Chris Angelico writes: > On Fri, Jun 6, 2014 at 12:16 PM, Nikolaus Rath wrote: >> - Is there some way to make the call stack for destructors less confusing? > > First off, either don't have refloops, or explicitly break them. The actual code isn't as simple as the example. I wasn't even aware there were any refloops. Guess I have to start hunting them down now. > That'll at least make things a bit more predictable; in CPython, > you'll generally see destructors called as soon as something goes out > of scope. Secondly, avoid threads when you're debugging a problem! I > said this right at the beginning. If you run into problems, the first > thing to do is isolate the system down to a single thread. Debugging > is way easier without threads getting in each other's ways. I don't see how this would have made a difference in this case. I still would have gotten lots of apparently non-sensical backtraces. Only this time they would all come from MainThread. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- https://mail.python.org/mailman/listinfo/python-list
Re: Micro Python -- a lean and efficient implementation of Python 3
On 2014-06-06 09:59, Travis Griggs wrote: > On Jun 4, 2014, at 4:01 AM, Tim Chase wrote: > > If you use UTF-8 for everything > > It seems to me, that increasingly other libraries (C, etc), use > utf8 as the preferred string interchange format. I definitely advocate UTF-8 for any streaming scenario, as you're iterating unidirectionally over the data anyways, so why use/transmit more bytes than needed. The only failing of UTF-8 that I've found in the real world(*) is when you have to requirement of constant-time indexing into strings. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On 06/06/2014 12:28 AM, Travis Griggs wrote: > > >> On Jun 5, 2014, at 1:14, Alain Ketterlin >> wrote: >> >> Swift's memory management is similar to python's (ref. counting). >> Which makes me think that a subset of python with the same type >> safety would be an instant success. > > Except that while you don't need to regularly worry about cycles in > python, you do in swift. Which means you get to think constantly > about direct and indirect cycles, figure out where to put weak stuff, > when to use a local to keep a weak property alive until it finds it's > strong home, etc. Swift's reference counting seems to be fairly close to Objective C's, which makes sense since the classes can be used directly in Swift. Seems to me that Swift is just Objective C with some syntactic sugar and a nicer syntax. That's why I said it was a little odd to be comparing Swift to Python, or at least to be claiming Apple should have made Python it's core language. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unicode and Python - how often do you index strings?
On 06/06/2014 01:42 AM, Johannes Bauer wrote:
Ah, I didn't know rstrip() accepted parameters and since you wrote
line.rstrip() this would also cut away whitespaces (which sadly are
relevant in odd cases).
No problem. If a parameter is used in the strip() family, than _only_ those characters are
stripped. Example:
>>> s = 'some text \n'
>>> print('"{}"'.format(s.rstrip())) # No parameter, strip all whitespace
"some text"
>>> print('"{}"'.format(s.rstrip('\n'))) # Parameter is newline, only strip
newlines
"some text "
-=- Larry
BTW, the strip() parameter (which must be a string) is not limited to whitespace, it can be used
with any set of characters.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Decorating one method of a class C with another method of class C?
On Fri, 06 Jun 2014 17:14:54 -0700, Dan Stromberg wrote: > Is there a way of decorating method1 of class C using method2 of class > C? Yes. See below. > It seems like there's a chicken-and-the-egg problem; the class doesn't > seem to know what "self" is until later in execution so there's > apparently no way to specify @self.method2 when def'ing method1. Directly inside the class statement, you don't need self. The class defines a namespace, like inside a function or globals, so you can just refer to names directly, like this: class Spam: def decorate(func): # Look Ma, no self! @functools.wraps(func) def inner(self, *args): print(self, args) return func(*args) return inner @decorate def method(self, a, b): return a+b That works fine for what you want to do. The disadvantage, however, is that if you call the decorate method from *outside* of the class scope (that is, from the outside like Spam.decorate, or inside a method like self.decorate) you'll run into some weird problems. Try it and see if you can diagnose the cause of the problem. This problem has a trivial, simple, obvious and wrong solution: ensure that the decorate method is a static method. That requires Spam to be a new-style class (inherit from object, or a built-in), but is otherwise trivial: class Spam(object): @staticmethod def decorate(func): # Look Ma, no self! ... Unfortunately, this does not work! staticmethod objects are not callable. It is only after you go through the descriptor protocol that you end up with something which is callable. Sad but true. That means that this will fail: class Spam(object): @staticmethod def decorate(func): ... @decorate # calling directly fails def method(self, args): ... but this will be okay: @Spam.decorate # calling via Spam or instance works def function(args): ... We're *so close* it hurts :-( Good news! staticmethod is a class, and like most classes we can subclass it and get the behaviour we want! # Untested class callablestaticmethod(staticmethod): def __call__(self, *args): return self.__func__(*args) ought to do it. Then just use callablestaticmethod instead of staticmethod, and all will be ginger-peachy. But what happens if you want the decorator to refer to the class itself? You can always hard-code references to Spam inside the decorate method, but a better solution may be to use a callableclassmethod instead. (Left as an exercise.) Inside the decorated method, or the wrapper method "inner", we can refer to "self" as normal, and such references won't be evaluated until call- time when self exists. It's only inside the decorator itself, and the body of the class, that self doesn't yet exist. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: This Swift thing
On Fri, 06 Jun 2014 20:41:09 -0600, Michael Torrie wrote: > On 06/06/2014 12:28 AM, Travis Griggs wrote: >> >> >>> On Jun 5, 2014, at 1:14, Alain Ketterlin >>> wrote: >>> >>> Swift's memory management is similar to python's (ref. counting). >>> Which makes me think that a subset of python with the same type safety >>> would be an instant success. >> >> Except that while you don't need to regularly worry about cycles in >> python, you do in swift. Which means you get to think constantly about >> direct and indirect cycles, figure out where to put weak stuff, when to >> use a local to keep a weak property alive until it finds it's strong >> home, etc. > > Swift's reference counting seems to be fairly close to Objective C's, > which makes sense since the classes can be used directly in Swift. Seems > to me that Swift is just Objective C with some syntactic sugar and a > nicer syntax. That's why I said it was a little odd to be comparing > Swift to Python, or at least to be claiming Apple should have made > Python it's core language. A "little" odd? It's utterly astonishing! Swift is not in the same family of languages as Python, Perl, Javascript, Ruby, Applescript, etc. I'll call them "scripting languages", but I don't mean that as a put-down. I just mean that they are intended for rapid development, they are dynamically typed, lightweight, and typically aren't expected to compile directly to machine code. Swift is intended as a new generation *systems language*. The old generation of systems languages are things like C, Objective-C, C#, C++, Java, Pascal, Algol, and so forth. The new generation are intended to fulfil the same niches, but to have syntax and usability closer to that of scripting languages. Languages like Go, Rust, Ceylon, and now Swift. We're starting to see the distinction between systems and scripting languages blurred even more than it used to be. These smart, lightweight but powerful systems languages are likely to be a big challenge to scripting languages like Python and Ruby in the coming decades. If you had a language as easy to use and as safe as Python, but as efficient as C, why wouldn't you use it? It is naive to expect Apple to have made Python it's core language. Apple's core language is Objective-C, and if they were going to pick a core scripting language (other than Applescript, which exists in a different ecological niche) it would have been Ruby, not Python. Ruby's fundamental model is very similar to Objective-C, Python's is not. Apple already developed a version of Ruby, "MacRuby", which was designed to call directly into the Objective-C APIs without an intermediate interface layer, but they have abandoned that to focus on Swift. (Besides, Apple is unlikely to commit to a core language being something they don't control.) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: http.server.BaseHTTPRequestHandler basic auth logout? Django authentication system for REST interface?
Dan Stromberg writes: > I have some code for a web server. Right now, it uses > BaseHTTPRequestHandler with Basic Auth, but we want to be able to log > out, and there doesn't appear to be a general way to log out of > something using Basic Auth, short of turning to unportable JavaScript. You can't: With "Basic Auth", the login is handled by the browser (and not the server). This implies, that you must tell the browser to logout (and not the server). There is no "standard way" to tell the browser to logout. -- https://mail.python.org/mailman/listinfo/python-list
Elektra 0.8.6
Hello Python List, Elektra provides a universal and secure framework to store configuration parameters in a global, hierarchical key database. The core is a small library implemented in C. The plugin-based framework fulfills many configuration-related tasks to avoid any unnecessary code duplication across applications while it still allows the core to stay without any external dependency. Elektra abstracts from cross-platform-related issues with an consistent API, and allows applications to be aware of other applications' configurations, leveraging easy application integration. http://www.libelektra.org While the core is in C, both applications and soon plugins (not yet relased) can be written in python. The API is complete and fully functional but not yet stable. So if you have any suggestions, please let us know. Additionally the latest release added: - C++11 und lua bindings - a plugin to read virtually every configuration file around - logging to journald (next to syslog) - many other improvements and bug fixes - compiler support for icc (+in clang warnings were fixed) - for more details see: http://sourceforge.net/p/registry/mailman/message/32418614/ You can download the release at: http://www.markus-raab.org/ftp/elektra/releases/elektra-0.8.6.tar.gz md5sum: 4a59824e70a29295e9ef9ae7605d9299 Make sure to enable BUILD_SWIG and BUILD_SWIG_PYTHON. Docu (C/C++) can be found here: http://doc.libelektra.org/api/0.8.6/html/ best regards, Markus -- https://mail.python.org/mailman/listinfo/python-list
Uniform Function Call Syntax (UFCS)
The language D has a feature called Uniform Function Call Syntax, which allows instance methods to be resolved using function calls. In Python terms, the call: x.len() would first check if 'x' has a method 'len', and would then look for a function 'len', passing 'x' as the first argument. The big wins are: - the ability to override functions with more optimal class-specific implementations. (Of course, len() is a bad example, since we already have a way to override it, but there are other functions that do not have a special method). - the readability of a.b().c().d() vs c(a.b()).d() Here's a few links discussing the feature in D: - First, a fairly gentle "this is cool" post: http://www.kr41.net/2013/08/27/uniform_function_call_syntax_in_d.html - Second, an article from the Walter Bright, the creator of D: http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394 Has this been discussed or proposed before? I found PEP's 443 and 3124, which provide a form of function overloading, but not reordering. -- https://mail.python.org/mailman/listinfo/python-list
