Re: Grapheme clusters, a.k.a.real characters
On Monday, July 17, 2017 at 9:41:51 AM UTC+5:30, Rustom Mody wrote: > On a more serious note every other post on this (as on many discussing unicode > more broadly) is so ridiculously Euro (or Anglo) centric I would not know > where > to begin. > Witness your own… > Hint1: Ask your grandmother whether unicode's notion of character makes > sense. > Ask 10 gmas from 10 language-L's > Hint2: When in doubt gma usually is right To be fair I notice now your subject line "aka real characters" Which suggests that you understand that the gma view may have more validity than the ½-assed ones (currently) supported by python/unicode -- https://mail.python.org/mailman/listinfo/python-list
Re: Grapheme clusters, a.k.a.real characters
Mikhail V : >>> On Sat, 15 Jul 2017 05:50 pm, Marko Rauhamaa wrote: >>It's true that confusion is caused by the ambiguity of the term >>"character." > > Yes, but you have said "I might want random access to the "Grapheme clusters, > a.k.a. real characters" and I had impression that you have some concrete > concept of grapheme clusters and some (generally useful) example of > implementation. > Without concrete examples it is just juggling with the terms. What did you think of my concrete examples, then? (Say, finding "Alvárez" with the regular expression "Alv[aá]rez".) > For example, I want to type in cyrillic " рекá " (with an acute accent > to denote the stress on the last vowel, say for a pronunciation > tutorial). Most frequent solution to it would be just typing á instead > of a. And it is indeed most pratical: if I use modifier acute accent > character instead, then it will be hard to select/paste such text and > it will not render accurately. Thing is, neither you (the user) nor you (the Python programmer) gets to decide how "á" is represented in Unicode. That decision may be made by other programmers (the terminal emulator, the file system or the text editor). Still, everything should be transparent to both you (the user) and you (the Python programmer). Marko -- https://mail.python.org/mailman/listinfo/python-list
HOTLIST
Hello Professionals, Greetings from NICHE SOFTWARE SOLUTIONS, Thank you for taking time to look over my Mail, This is Jack Stutter from Niche Software Solutions Inc working as Sr Bench sales recruiter, We have very strong bench consultants. I would highly appreciate if you can add me j...@nichesoftsolutions.com in your daily requirement mailing list and keep me posted with your daily C2C requirements or you can directly reach me at 5035362757. NameTechnology Experience VisaLocationRelocate Manoj Kumar VM WARE 14+ H1B NC OPEN Rahul Chandran Business Intelligence 7+ H1B TX OPEN Soumith Reddy SQL/ PLSQL Developer6+ H1B OH OPEN Sayed Abualia Technical support/Analyst 6+ H1B WA OPEN ShriSalesforce Developer5+ H1B CO OPEN Vishnu KumarQA Analyst (Automation and Manual) 13+ H1B WI OPEN Mahesh QA Analyst(Automation and Manual) 15+ H1B WI OPEN Meenakshi Mahapatra Teradata Developer 7+ L2-EAD NJ NJ Rashi Choudary Guidewire Developer 8+ H1B TX OPEN Sanjay Automation Tester 8+ H1B CA OPEN Rahul Bhardwaj SAP APO10+ H1B CO OPEN Nisha Rani .Net Developer 6+ H1B MA OPEN Swapna Kanikea Java Developer 11+ H1B VA OPEN Vidur Network 7+ H1B TX OPEN Gnana SelvaInfirmatic 6+ H1B TX OPEN Fakrudhin Storage Engineer10+ H1B TX OPEN Akshay Sourcing Lead 5+ H1B MA OPEN Ramya UI Developer4+ H4EAD OH OPEN -- https://mail.python.org/mailman/listinfo/python-list
Is this PEP viable?
I would like to submit the following proposal. In the logging module, I would like handlers (like file handlers and stream handlers) to have a field for exc_info printing. This way, a call to logger.exception() will write the stack trace to the handlers with this flag set, and only print the message and other info to handlers without the flag set. This allows a single logger to write to a less detailed console output, a less detailed run log, and a more detailed error log. -- https://mail.python.org/mailman/listinfo/python-list
Re: Grapheme clusters, a.k.a.real characters
On Mon, 17 Jul 2017 02:10 pm, Rustom Mody wrote:
>> Please don't feed the trolls.
>
> Its usually called 'joke' Steven! Did the word fall out of your dictionary
> in the last upgrade?
> Rick was no more trolling than Marko
Funny you say that. I often think Marko is trolling, but if he is, he does a
good job of leaving me in just enough doubt that I'm willing to continue the
discussion.
As for Rick, I can't tell if he's merely trolling to get a reaction, or he
really does believe the crap he spouts off in most of his posts. I'm not sure
which would be worse.
> or you or Chris or Mikhail or anyone else
> If anyone's trolling its me… len("á") == 1½ is so obviously nonsense on so
> many levels I did not think
> "And now ladies (are there any?) and gentlemen I am going to tell a joke!"
> would be necessary
And it wouldn't have been necessary, if we didn't have Ranting Rick here to take
your proposal seriously.
> On a more serious note every other post on this (as on many discussing unicode
> more broadly) is so ridiculously Euro (or Anglo) centric I would not know
> where to begin.
I'm always willing to learn. How am I Euro, or Anglo, centric?
> Witness your own…
[...]
> You've given 4 ifs.
Actually I gave five "ifs", plus one other conditional phrase which could have
been re-worded as an "if".
> An L-language may would assume that the atomic units of language-L would
> be supported. Your 4th if suggests thats ok. Is it?
Please pardon me for being Anglo-centric, but what's an L-language?
People make lots of bad assumptions. For example, they assume that computer
arithmetic must follow the same mathematical rules of associativity,
commutativity and distributivity that they learned about the Real number system
in high school. That assumption is wrong.
People assume that the atomic units of language are a simple thing to define,
and having defined them, support them in programming languages. That assumption
is also wrong.
People assume all sorts of falsehoods about programming, and language. So to
answer your question, no, it is not okay to assume that the "atomic units of
language" (whatever they are) are supported.
I don't think that it is even a given that "atomic units of language" exist. To
quote a Hindi speaker earlier in this thread, की is a letter, and yet it can be
decomposed into की = क + ई, so it isn't "atomic". If letters aren't atomic,
then what are?
So if the "atomic units of language" (letters?) have "subatomic parts", where
does that leave us programmers? Shouldn't we be able to manipulate text at the
subatomic level?
> Hint1: Ask your grandmother whether unicode's notion of character makes sense.
What on earth makes you think that my grandmother is a valid judge of whether
Unicode makes sense or not?
She made some mighty fine chicken soup, and her coffee scroll cake was to die
for, but I wouldn't want to ask her to fix my car, perform brain surgery, solve
a differential equation, or judge the merits of a technical standard like
Unicode.
Her English wasn't that great, her Russian was more of a country-bumpkin dialect
than Standard Russian, and it was mixed in with a lot of Estonian and Polish as
well, and she had *absolutely zero* knowledge of different language systems
like Chinese ideographs, Arabic, Hindi, etc. Nor did she know anything about
the legacy encodings of the 1980s and 90s.
How could she possibly be expected to judge Unicode? She never even handled a
computer in her life, let alone program one. How could she judge the complex
balancing act between competing requirements that go into Unicode?
Its really sad to see somebody who I thought was educated exposing the view that
knowledge and education aren't needed to judge complex technical questions,
only common sense[1]. Experts? Who needs 'em?
> Ask 10 gmas from 10 language-L's
> Hint2: When in doubt gma usually is right
Would you let your grandmother perform brain surgery on someone you cared for?
Well, maybe, if she actually was a brain surgeon. But if not?
[1] http://i.imgur.com/jgmwz1q.jpg
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Grapheme clusters, a.k.a.real characters
On Tue, Jul 18, 2017 at 1:36 AM, Steve D'Aprano wrote: > On Mon, 17 Jul 2017 02:10 pm, Rustom Mody wrote: >> Hint1: Ask your grandmother whether unicode's notion of character makes >> sense. > > What on earth makes you think that my grandmother is a valid judge of whether > Unicode makes sense or not? > > She made some mighty fine chicken soup, and her coffee scroll cake was to die > for, but I wouldn't want to ask her to fix my car, perform brain surgery, > solve > a differential equation, or judge the merits of a technical standard like > Unicode. > > Her English wasn't that great, her Russian was more of a country-bumpkin > dialect > than Standard Russian, and it was mixed in with a lot of Estonian and Polish > as > well, and she had *absolutely zero* knowledge of different language systems > like Chinese ideographs, Arabic, Hindi, etc. Nor did she know anything about > the legacy encodings of the 1980s and 90s. > > How could she possibly be expected to judge Unicode? She never even handled a > computer in her life, let alone program one. How could she judge the complex > balancing act between competing requirements that go into Unicode? I think the point here is not about judging Unicode, but defining a character. If I were to ask either of my (late) grandmothers what a character is, aside from being told that I am myself quite a character, I'd probably get a reasonably sane response for text in English, Italian, or Dutch. With the possible exception that "ij" might be considered a single letter in Dutch. Except when it isn't. But neither of them is qualified to say whether и and й are the same letter or not, as both of them would think they were badly written upper-case N. Nor would I ask either of them whether 다 is one character or two. The "ask your grandmother" technique is great for questions of UI within her area of skill, but that's about it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP viable?
On Monday, July 17, 2017 at 3:41:12 PM UTC+1, Evan Adler wrote: > I would like to submit the following proposal. In the logging module, I > would like handlers (like file handlers and stream handlers) to have a > field for exc_info printing. This way, a call to logger.exception() will > write the stack trace to the handlers with this flag set, and only print > the message and other info to handlers without the flag set. This allows a > single logger to write to a less detailed console output, a less detailed > run log, and a more detailed error log. What PEP? If you had it as an attachment it won't get through. Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP viable?
Evan Adler wrote:
> I would like to submit the following proposal. In the logging module, I
> would like handlers (like file handlers and stream handlers) to have a
> field for exc_info printing. This way, a call to logger.exception() will
> write the stack trace to the handlers with this flag set, and only print
> the message and other info to handlers without the flag set. This allows a
> single logger to write to a less detailed console output, a less detailed
> run log, and a more detailed error log.
If I understand you correctly this would go into the Formatter rather than
the Handler. E. g.:
$ cat log_exception_format.py
import logging
import sys
class MyFormatter(logging.Formatter):
def __init__(self, fmt=None, datefmt=None, style='%', verbose=0):
super().__init__(fmt, datefmt, style)
self.verbose = verbose
def formatException(self, ei):
if self.verbose < 1:
return ""
elif self.verbose < 2:
return "{0[0].__name__}: {0[1]}".format(ei)
else:
return super().formatException(ei)
formatter = MyFormatter(logging.BASIC_FORMAT, verbose=sys.argv.count("-v"))
handler = logging.StreamHandler()
handler.setFormatter(formatter)
g = logging.getLogger()
g.addHandler(handler)
def f(n):
if n > 0:
return f(n-1)
else:
1/0
try:
f(3)
except:
g.exception("foo")
$ python3 log_exception_format.py
ERROR:root:foo
$ python3 log_exception_format.py -v
ERROR:root:foo
ZeroDivisionError: division by zero
$ python3 log_exception_format.py -v -v
ERROR:root:foo
Traceback (most recent call last):
File "log_exception_format.py", line 31, in
f(3)
File "log_exception_format.py", line 27, in f
return f(n-1)
File "log_exception_format.py", line 27, in f
return f(n-1)
File "log_exception_format.py", line 27, in f
return f(n-1)
File "log_exception_format.py", line 29, in f
1/0
ZeroDivisionError: division by zero
$
(Note that this is just a sketch; for the above to work reliably the
format() method has to be changed to avoid caching the result of the
formatException() call)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Grapheme clusters, a.k.a.real characters
On 17/07/17 05:10, Rustom Mody wrote: Hint1: Ask your grandmother whether unicode's notion of character makes sense. Ask 10 gmas from 10 language-L's Hint2: When in doubt gma usually is right "For every complex problem there is an answer that is clear, simple and wrong." (H.L. Mencken). Unfortunately grandmothers outside their areas of expertise are particularly prone to finding those answers. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Users of namedtuple: do you use the _source attribute?
collections.namedtuple generates a new class using exec, and records the source
code for the class as a _source attribute.
Although it has a leading underscore, it is actually a public attribute. The
leading underscore distinguishes it from a named field potentially
called "source", e.g. namedtuple("klass", ['source', 'destination']).
There is some discussion on Python-Dev about:
- changing the way the namedtuple class is generated which may
change the _source attribute
- or even dropping it altogether
in order to speed up namedtuple and reduce Python's startup time.
Is there anyone here who uses the namedtuple _source attribute?
My own tests suggest that changing from the current implementation to one
similar to this recipe here:
https://code.activestate.com/recipes/578918-yet-another-namedtuple/
which only uses exec to generate the __new__ method, not the entire class, has
the potential to speed up namedtuple by a factor of four.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Users of namedtuple: do you use the _source attribute?
I have never used it personally. It always looked interesting, but I never ran
into a need to generate the source for it.
-Original Message-
From: Python-list [mailto:python-list-bounces+d.strohl=f5@python.org] On
Behalf Of Steve D'Aprano
Sent: Monday, July 17, 2017 9:58 AM
To: python-list@python.org
Subject: Users of namedtuple: do you use the _source attribute?
collections.namedtuple generates a new class using exec, and records the source
code for the class as a _source attribute.
Although it has a leading underscore, it is actually a public attribute. The
leading underscore distinguishes it from a named field potentially called
"source", e.g. namedtuple("klass", ['source', 'destination']).
There is some discussion on Python-Dev about:
- changing the way the namedtuple class is generated which may
change the _source attribute
- or even dropping it altogether
in order to speed up namedtuple and reduce Python's startup time.
Is there anyone here who uses the namedtuple _source attribute?
My own tests suggest that changing from the current implementation to one
similar to this recipe here:
https://code.activestate.com/recipes/578918-yet-another-namedtuple/
which only uses exec to generate the __new__ method, not the entire class, has
the potential to speed up namedtuple by a factor of four.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASE] Python 3.6.2 is now available
On Monday, July 17, 2017 at 3:02:01 AM UTC-7, bream...@gmail.com wrote: > On Monday, July 17, 2017 at 10:41:02 AM UTC+1, wxjm...@gmail.com wrote: > > Poor Python. > > Once it was working. > > Dear RUE, > > A bad workman always blames his tools. > > Mark Lawrence. +1. -- https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
On 07/17/2017 09:57 AM, Steve D'Aprano wrote:
collections.namedtuple generates a new class using exec, and records the source
code for the class as a _source attribute.
Although it has a leading underscore, it is actually a public attribute. The
leading underscore distinguishes it from a named field potentially
called "source", e.g. namedtuple("klass", ['source', 'destination']).
There is some discussion on Python-Dev about:
- changing the way the namedtuple class is generated which may
change the _source attribute
- or even dropping it altogether
in order to speed up namedtuple and reduce Python's startup time.
Is there anyone here who uses the namedtuple _source attribute?
My own tests suggest that changing from the current implementation to one
similar to this recipe here:
https://code.activestate.com/recipes/578918-yet-another-namedtuple/
which only uses exec to generate the __new__ method, not the entire class, has
the potential to speed up namedtuple by a factor of four.
I use namedtuple a lot, and never even HEARD of _source.
That said, it sure feels (as someone who hasn't tried it) like there's a
straightforward namedtuple implementation that calls type() directly
rather than having to exec. I know that exec-gunshyness is overblown,
but is there a simple answer as to why it's necessary here?
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
Steve D'Aprano writes: > collections.namedtuple generates a new class using exec, and records > the source code for the class as a _source attribute. The documentation tells me that ‘_source’ is “New in version 3.3.” I wasn't aware that the ‘namedtuple’ interface had changed since it was introduced, so: > Is there anyone here who uses the namedtuple _source attribute? Not me. -- \ “Anyone who believes exponential growth can go on forever in a | `\finite world is either a madman or an economist.” —Kenneth | _o__) Boulding, 1973 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Combining every pair of list items and creating a new list.
Hi, I'm having difficulty thinking about how to do this as a Python beginner. But I have a list that is represented as: [1,2,3,4,5,6,7,8] and I would like the following results: [1,2] [3,4] [5,6] [7,8] Any ideas? Thanks -- https://mail.python.org/mailman/listinfo/python-list
brew pip: "ImportError: No module named packaging.version"
Hiya. I'm running El Capitan and have a Homebrew install of python (as well as one in /usr/bin/python, which I can't recall how I installed). I had some trouble pip installing Keras: $ sudo pip install keras … DEPRECATION: Uninstalling a distutils installed project (numpy) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project. The recommended solution is to make sure I'm using brew python: $ brew link --overwrite python. Linking /usr/local/Cellar/python/2.7.13... 39 symlinks created But now pip (/usr/local/Cellar/python/2.7.13/bin/pip) does not work: $ pip -V Traceback (most recent call last): File "/usr/local/bin/pip", line 6, in from pkg_resources import load_entry_point File "/Users/aditpras/Library/Python/2.7/lib/python/site-packages/pkg_resources/__init__.py", line 70, in import packaging.version ImportError: No module named packaging.version (Not only that, but the usual instructions for reinstalling pip, such as "proxy python -m pip install -U pip" and "python get-pip.py" tell me "Requirement already up-to-date" without fixing anything.) I eventually realized that easy_install'ing pip gives me a working pip again. The one in Cellar still does not work. To install Keras, I apparently have to do: $ sudo pip install keras --ignore-installed numpy Any tips? (I realize I can just use pyenv or virtualenv). -- https://mail.python.org/mailman/listinfo/python-list
Re: Combining every pair of list items and creating a new list.
On 2017-07-17 21:10, aaron.m.weisb...@gmail.com wrote: Hi, I'm having difficulty thinking about how to do this as a Python beginner. But I have a list that is represented as: [1,2,3,4,5,6,7,8] and I would like the following results: [1,2] [3,4] [5,6] [7,8] Any ideas? Thanks Those are slices of the original list. You can do it using a 'for' loop over a 'range' with a step/stride of 2 and getting slices of the original list. -- https://mail.python.org/mailman/listinfo/python-list
Grapheme clusters, a.k.a.real characters
ChrisA wrote: >Yep! Nobody would take any notice of the fact that you just put dots >on all those letters. It's not like it's going to make any difference >to anything. We're not dealing with matters of life and death here. >Oh wait. >https://www.theinquirer.net/inquirer/news/1017243/cellphone-localisation-glitch >I'll leave you with that thought. For Turkish and Slavic languages there is actually a demand for at least one Yeru letter to distinguish the common i and Yeru. In cyrillic it is "ы". It should be romanized as "y". And the Yot /j/ should be romanized as "j". I.e. for Turkish: yazım - should be : jazym For Russian: ярлык - should be : jarlyk Simple, asscii input, no ambiguity. How many exercises in futility could be avoided... And just in case still its not clear: this is not solved by adding dirt around the letter: if there is enough significance of the phoneme distinction then one should add a distinct letter for a syntax in question. And not like: well it is not so significant then we'll add a bit of dirt, it is more significant - we add some more dirt. It is not how the textual representation is made effecient. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: Grapheme clusters, a.k.a.real characters
Steve D'Aprano wrote: I don't think that it is even a given that "atomic units of language" exist. To quote a Hindi speaker earlier in this thread, की is a letter, and yet it can be decomposed into की = क + ई, so it isn't "atomic". If letters aren't atomic, then what are? They're like subatomic particles! All equally fundamental, but they can turn into each other. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
Steve D'Aprano writes: Is there anyone here who uses the namedtuple _source attribute? I didn't know it existed either, and if I did I would have assumed it was an implementation detail and would never have written code that relied on it. I certainly won't miss it if it disapppears. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
On 07/17/2017 12:44 PM, Rob Gaddi wrote:
On 07/17/2017 09:57 AM, Steve D'Aprano wrote:
collections.namedtuple generates a new class using exec, and records the source
code for the class as a _source attribute.
Although it has a leading underscore, it is actually a public attribute. The
leading underscore distinguishes it from a named field potentially
called "source", e.g. namedtuple("klass", ['source', 'destination']).
>> [...]
Is there anyone here who uses the namedtuple _source attribute?
I use namedtuple a lot, and never even HEARD of _source.
That said, it sure feels (as someone who hasn't tried it) like there's a
straightforward namedtuple implementation that
calls type() directly rather than having to exec. I know that exec-gunshyness
is overblown, but is there a simple
answer as to why it's necessary here?
I can't answer that question, but I can say my aenum library [1][2] uses the same metaclass technique as the new Enum
type, and also supports doc strings and default arguments in the class-based format.
--
~Ethan~
[1] https://pypi.python.org/pypi/aenum (works back to at least 2.7)
[2] Disclosure: I am the author of the Python stdlib Enum, the enum34 backport, and the Advanced Enumeration (aenum)
library.
--
https://mail.python.org/mailman/listinfo/python-list
cPickle fails on manually compiled and executed Python function
Hi,
today I came across some weird behaviour (a bug?) in Python 2.7.13 (on
Linux) with the cPickle module. The pickle module works and so does the
pickle module in Python 3.
I have a file fn.py with a minimal function definition:
```
def fn():
pass
```
The actual code that I run is in a separate file (test.py):
```
import cPickle
import pickle
def load_pyfile(filename):
source = ''
with open(filename, 'r') as f:
source += f.read()
code = compile(source, filename, 'exec')
loaded = {'__file__': filename}
exec(code, loaded)
return loaded
fn = load_pyfile('fn.py')['fn']
print(pickle.dumps(fn))
print('')
print(cPickle.dumps(fn))
```
The first print works fine, but the one with cPickle leads to an
exception. Here is the output:
```
c__main__
fn
p0
.
Traceback (most recent call last):
File "test.py", line 17, in
print(cPickle.dumps(fn))
TypeError: expected string or Unicode object, NoneType found
```
I don't understand why the cPickle module behaves differently in this
case. Is this expected? And if so, how do I fix it? Or can this be
considered a bug? (In that case I could open an issue in the bug
tracker.)
Cheers, Jan
--
https://mail.python.org/mailman/listinfo/python-list
Re: Combining every pair of list items and creating a new list.
On Monday, July 17, 2017 at 3:10:51 PM UTC-5, aaron.m@gmail.com wrote: > Hi, > > I'm having difficulty thinking about how to do this as a Python beginner. > > But I have a list that is represented as: > > [1,2,3,4,5,6,7,8] > > and I would like the following results: > > [1,2] [3,4] [5,6] [7,8] > > Any ideas? Solving problems in the "programming realm" is not much unlike solving problems in real life. First, image you had 8 apples laying on the floor. Now imagine the steps required to collect the apples into "sacks of two". (1) First, grab one large sack and enough small sacks to hold all the apples. 8 / 2.0 = (4.0 small sacks) (2) Then, position yourself at one end of the "row of apples". (3) Now grab two apples and put them both into a small sack. Then, put the small sack into the large sack. (4) Repeat step 3 until there are no more apples on the floor. There you go. All you have to do now is translate that into Python code. Shouldn't be too difficult. And your professor will be so proud ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
On Tue, 18 Jul 2017 05:44 am, Rob Gaddi wrote: > That said, it sure feels (as someone who hasn't tried it) like there's a > straightforward namedtuple implementation that calls type() directly > rather than having to exec. I know that exec-gunshyness is overblown, > but is there a simple answer as to why it's necessary here? It's very hard to write __new__ with a sensible parameter list without exec. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
On Monday, July 17, 2017 at 12:20:04 PM UTC-5, Steve D'Aprano wrote:
> collections.namedtuple generates a new class using exec,
> and records the source code for the class as a _source
> attribute. Although it has a leading underscore, it is
> actually a public attribute. The leading underscore
> distinguishes it from a named field potentially called
> "source", e.g. namedtuple("klass", ['source',
> 'destination']).
Although i understand the reasoning behind using the leading
underscore, the Python devs should have realized that anyone
who follows Pythonic convention [1] will ignore a symbol
that starts with an underscore . So if the intention is that
`_source` should be a part of the public API, then
obviously, defining it in "standardized private form" is
very unwise.
But to answer your question, no, none of my code relies on
the `_source` attribute. So i really don't care what happens
to it.
[1] Which i would hope is a rather large group, and not just
another "Rick singleton".
--
https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
Il giorno lunedì 17 luglio 2017 19:20:04 UTC+2, Steve D'Aprano ha scritto:
> collections.namedtuple generates a new class using exec, and records the
> source
> code for the class as a _source attribute.
>
> Although it has a leading underscore, it is actually a public attribute. The
> leading underscore distinguishes it from a named field potentially
> called "source", e.g. namedtuple("klass", ['source', 'destination']).
>
>
> There is some discussion on Python-Dev about:
>
> - changing the way the namedtuple class is generated which may
> change the _source attribute
>
> - or even dropping it altogether
>
> in order to speed up namedtuple and reduce Python's startup time.
>
>
> Is there anyone here who uses the namedtuple _source attribute?
>
> My own tests suggest that changing from the current implementation to one
> similar to this recipe here:
>
> https://code.activestate.com/recipes/578918-yet-another-namedtuple/
>
> which only uses exec to generate the __new__ method, not the entire class, has
> the potential to speed up namedtuple by a factor of four.
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
It is an attribute that looks handy for understanding how a namedtuple works,
and can be used in debugging, but in practice I have never used it in
production code. I use a a lot of namedtuple, and if we can get a factor 4
speedup I am pretty happy to lose _source.
--
https://mail.python.org/mailman/listinfo/python-list
Re: cPickle fails on manually compiled and executed Python function
"Jan Gosmann" writes:
> today I came across some weird behaviour (a bug?) in Python 2.7.13 (on
> Linux) with the cPickle module. The pickle module works and so does
> the pickle module in Python 3.
>
> I have a file fn.py with a minimal function definition:
>
> ```
> def fn():
> pass
> ```
>
> The actual code that I run is in a separate file (test.py):
>
> ```
> import cPickle
> import pickle
>
> def load_pyfile(filename):
> source = ''
> with open(filename, 'r') as f:
> source += f.read()
> code = compile(source, filename, 'exec')
> loaded = {'__file__': filename}
> exec(code, loaded)
> return loaded
>
> fn = load_pyfile('fn.py')['fn']
>
> print(pickle.dumps(fn))
> print('')
> print(cPickle.dumps(fn))
> ```
>
> The first print works fine, but the one with cPickle leads to an
> exception. Here is the output:
>
> ```
> c__main__
> fn
> p0
> .
>
> Traceback (most recent call last):
> File "test.py", line 17, in
> print(cPickle.dumps(fn))
> TypeError: expected string or Unicode object, NoneType found
"pickle" (and "cpickle") are serializing functions as so called
"global"s, i.e. as a module reference together with a name.
This means, they cannot handle functions computed in a module
(as in your case).
I am quite convinced that "pickle" will not be able to deserialize (i.e. load)
your function (even though it appears to perform the serialization
(i.e. dump).
You are using "pickle/cPickle" for a case not anticipated (computed
functions). This means that this case is not as tested as other
cases. As a consequence, you can see different behavior between
"picke" and "cPickle".
--
https://mail.python.org/mailman/listinfo/python-list
Re: Users of namedtuple: do you use the _source attribute?
On 7/17/2017 10:27 PM, Rick Johnson wrote:
On Monday, July 17, 2017 at 12:20:04 PM UTC-5, Steve D'Aprano wrote:
collections.namedtuple generates a new class using exec,
and records the source code for the class as a _source
attribute. Although it has a leading underscore, it is
actually a public attribute. The leading underscore
distinguishes it from a named field potentially called
"source", e.g. namedtuple("klass", ['source',
'destination']).
Although i understand the reasoning behind using the leading
underscore, the Python devs should have realized that anyone
who follows Pythonic convention [1] will ignore a symbol
that starts with an underscore . So if the intention is that
`_source` should be a part of the public API, then
obviously, defining it in "standardized private form" is
very unwise.
But to answer your question, no, none of my code relies on
the `_source` attribute. So i really don't care what happens
to it.
[1] Which i would hope is a rather large group, and not just
another "Rick singleton".
Yes, No. The developers of the class agree that a trailing underscore
convention would have been better. 'source_' etc.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: Grapheme clusters, a.k.a.real characters
Mikhail V : > And just in case still its not clear: this is not solved by adding > dirt around the letter: if there is enough significance of the phoneme > distinction then one should add a distinct letter for a syntax in > question. The letters of Finnish are: abdefghijklmnoprstuvyäö in that order. No exasperated wish of yours is going to change that. Marko -- https://mail.python.org/mailman/listinfo/python-list
