Re: A bug in Python's regular expression engine?

On Nov 27, 10:52 am, MonkeeSage <[EMAIL PROTECTED]> wrote: > On Nov 27, 10:19 am, "Just Another Victim of the Ambient Morality" > > <[EMAIL PROTECTED]> wrote: > > That is funny. Thank you for your help... > > Just for clarification, what does the "r" in your code do? > > It means a "raw" s

Is this a bug, or is it me?

Hello all, For some reason, the following does not work : class C: TYPES = [None] DICT = {} for Type in TYPES: DICT.update((E,Type) for E in [1]) >>> NameError: global name 'Type' is not defined What do you think? Is this a bug? -- http://mail.python.o

Re: is there a bug in urlunparse/urlunsplit

Alex wrote in news:09764c57-03ce-4ccb-a26d- [EMAIL PROTECTED] in comp.lang.python: > Hi all. > > Is there a bug in the urlunparse/urlunsplit functions? > Look at this fragment (I know is quite silly): > > urlunparse(urlparse('www.example.org','http&#

Re: is there a bug in urlunparse/urlunsplit

In article <[EMAIL PROTECTED]>, Alex <[EMAIL PROTECTED]> wrote: > Hi all. > > Is there a bug in the urlunparse/urlunsplit functions? > Look at this fragment (I know is quite silly): > > urlunparse(urlparse('www.example.org',

Is this a bug of the lambda function

Hi, I have a short code which gives me strange results, the code is as follows: f = [lambda x: None]*5 for j in range(0, 5): f[j] = lambda x: float(j)*x print "print f[k](1.)," for k in range(5): print f[k](1.), print "expect 0. 1. 2. 3. 4." print print "print f[j](1.)," for j in range(5

Re: Bind event is giving me a bug.

eneskri...@gmail.com wrote: > While working with tkinter in python 3.3, I had the following problem. > root = Tk() > label = Label(root, text = "Enter the number of competitors.") > label.pack(side = TOP) > entered_text = Entry(root) > entered_text.pack() > Button(root, text = "Submit", command =

Re: Bind event is giving me a bug.

On 2014-01-15 20:16, eneskri...@gmail.com wrote: While working with tkinter in python 3.3, I had the following problem. def get_text(event): self.number_of_competitors = entered_text.get() try: self.number_of_competitors = int(self.number_of_competitors)

Re: Bind event is giving me a bug.

Thank you, I thought Enter was Enter, but I still have this problem, when I press the Button, this appears: Exception in Tkinter callback Traceback (most recent call last): File "C:\Python33\lib\tkinter\__init__.py", line 1475, in __call__ return self.func(*args) TypeError: get_text() missin

Re: Bind event is giving me a bug.

MRAB wrote: > This will make it call 'get_text' when the button is clicked: > >> Button(root, text = "Submit", command = get_text).pack() ...and then produce a TypeError because of the missing `event` argument. To avoid that you can provide a default with def get_text(event=None): ... --

Re: Bind event is giving me a bug.

On 1/15/2014 3:16 PM, eneskri...@gmail.com wrote: While working with tkinter in python 3.3, I had the following problem. Please paste working code that people can experiment with. from tkinter import * def get_text(event): If this were a method, (which the indent of the body suggests it on

csv.DictReader line skipping should be considered a bug?

corresponding. The DictReader skipped ahead many lines breaking the line-by-line correspondence. And I want to argue that the difference of behavior should be considered a bug. It should be considered as such because: 1. I need to know what's in the file to know what class to use. The file co

Re: Pandas cat.categories.isin list, is this a bug?

On Monday, 14 May 2018 13:05:24 UTC+2, zlju...@gmail.com wrote: > Hi, > > I have dataframe with CRM_assetID column as category dtype: > > df.info() > > > RangeIndex: 1435952 entries, 0 to 1435951 > Data columns (total 75 columns): > startTime1435952 non-null object

Re: Pandas cat.categories.isin list, is this a bug?

On 2018-05-14 07:05, zljubi...@gmail.com wrote: > Hi, > > I have dataframe with CRM_assetID column as category dtype: > > df.info() > > > RangeIndex: 1435952 entries, 0 to 1435951 > Data columns (total 75 columns): > startTime1435952 non-null object > CRM_assetID

Re: Pandas cat.categories.isin list, is this a bug?

On 2018-05-15 06:23, Zoran Ljubišić wrote: > Matt, > > thanks for the info about pydata mailing group. I didn't know it exists. > Because comp.lang.python is not appropriate group for this question, I > will continue our conversation on gmail. > > I have put len(df.CRM_assetID.cat >

Re: Is this a bug in Python 3.3?

On 9/17/2013 7:22 AM, Aseem Bansal wrote: While using IDLE I used the license() function to see the license information. In it there was a list of all the versions and from which version they are derived is written. The 2.7 list ends with 2.7. The 3.x does not even include 2.7. The list goe

matplotlib - removing text from a figure - a bug?

Does anyone know if the following error message is a matplotlib bug? Is there an correct/alternative way to remove (or replace) text? Thank you, Raphael from matplotlib.figure import Figure fig = Figure() caption = fig.suptitle("test") caption.remove() Traceback (most recent call last): File ""

Re: Pandas cat.categories.isin list, is this a bug?

Hi Matt, > (Including python-list again, for lack of a reason not to. This > conversation is still relevant and appropriate for the general Python > mailing list -- I just meant that the pydata list likely has many more > Pandas users/experts, so you're more likely to get a better answer, > faster

pyc-files contains absolute paths, is this a bug ?

hello, AFAIK I read that pyc files can be transferred to other systems. I finally got a windows executable working through py2exe, but still have some troubles, moving the directory around. I use Python 2.5.2. I use py2exe to make a distro I can unpack the distro, on a clean computer, anywhere w

Re: A bug for raw string literals in Py3k?

> > > All backslashes in raw string literals are > interpreted literally. > > > (seehttp://docs.python.org/release/3.0.1/whatsnew/3.0.html): > > > > All backslashes in syntactically-correct raw string > literals are interpreted literally. > > That's a good way of putting it. > Syntactical correc

Re: A bug for raw string literals in Py3k?

On 01/11/2010 03:30, Yingjie Lan wrote: All backslashes in raw string literals are interpreted literally. (seehttp://docs.python.org/release/3.0.1/whatsnew/3.0.html): All backslashes in syntactically-correct raw string literals are interpreted literally. That's a good way of putting it.

Re: A bug for raw string literals in Py3k?

> According to msg56377, the behaviour is "optimal" for regular > expressions. Well, I use regular expressions a lot, and I > still think it's a nuisance! Thanks for bringing that up. Using an otherwise 'dead' backlash to escape quotes in raw strings seems like the black magic of necromancy to

Re: A bug for raw string literals in Py3k?

> So I suppose this is a bug? It's not, see http://docs.python.org/py3k/reference/lexical_analysis.html#literals # Specifically, a raw string cannot end in a single backslash Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list

Re: A bug for raw string literals in Py3k?

> > So I suppose this is a bug? > > It's not, see > > http://docs.python.org/py3k/reference/lexical_analysis.html#literals > > # Specifically, a raw string cannot end in a single backslash Thanks! That looks weird to me ... doesn't this contradict with: All

Re: A bug for raw string literals in Py3k?

On Oct 31, 11:23 pm, Yingjie Lan wrote: > > > So I suppose this is a bug? > > > It's not, see > > >http://docs.python.org/py3k/reference/lexical_analysis.html#literals > > > # Specifically, a raw string cannot end in a single backslash > >

Re: A bug for raw string literals in Py3k?

John Machin writes: > On Oct 31, 11:23 pm, Yingjie Lan wrote: > > Thanks! That looks weird to me ... doesn't this contradict with: > > > > All backslashes in raw string literals are interpreted literally. > > (seehttp://docs.python.org/release/3.0.1/whatsnew/3.0.html): > > All backslashes in syn

Py_NewInterpreter(), is this a bug in the python core?

/* Is this a bug in Py_NewInterpreter? The function below "MyThread" is instantiated from a windows worker thread, but I don't think that is relevant. (I can try this on a linux box, but I would have to compile a python library with debugging enabled.) The following code fra

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

On May 16, 1:13 pm, Victor Kryukov <[EMAIL PROTECTED]> wrote: > Hello list, > > I've found the following strange behavior of cPickle. Do you think > it's a bug, or is it by design? > > Best regards, > Victor. > > from pickle import dumps > from

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

> > I've found the following strange behavior of cPickle. Do you think > > it's a bug, or is it by design? > > > > Best regards, > > Victor. > > > > from pickle import dumps > > from cPickle import dumps as cdumps > > > >

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

On May 16, 1:13 pm, Victor Kryukov <[EMAIL PROTECTED]> wrote: > Hello list, > > I've found the following strange behavior of cPickle. Do you think > it's a bug, or is it by design? > > Best regards, > Victor. > > from pickle import dumps > from

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

On 5/16/07, Daniel Nogradi <[EMAIL PROTECTED]> wrote: > > > I've found the following strange behavior of cPickle. Do you think > > > it's a bug, or is it by design? > > > > > > Best regards, > > > Victor. > > > &g

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

In <[EMAIL PROTECTED]>, Daniel Nogradi wrote: > The OP was not comparing identity but equality. So it looks like a > real bug, I think the following should be True for any function f: > > if a == b: f(a) == f(b) > > or not? In [74]: def f(x): : return x / 2 : In [75]: a = 5

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

> > > > I've found the following strange behavior of cPickle. Do you think > > > > it's a bug, or is it by design? > > > > > > > > Best regards, > > > > Victor. > > > > > > > > from pickle import dumps

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

Daniel Nogradi wrote: > Caching? > from cPickle import dumps dumps('0') == dumps(str(0)) > True dumps('1') == dumps(str(1)) > True dumps('2') == dumps(str(2)) > True > > dumps('9') == dumps(str(9)) > True dumps('10') == dumps(str(10)) > False du

Re: cPickle.dumps differs from Pickle.dumps; looks like a bug.

En Thu, 17 May 2007 02:09:02 -0300, Josiah Carlson <[EMAIL PROTECTED]> escribió: > All strings of length 0 (there is 1) and 1 (there are 256) are interned. I thought it was the case too, but not always: py> a = "a" py> b = "A".lower() py> a==b True py> a is b False py> a is intern(a) True py>

Re: Strange behavior with iterables - is this a bug?

<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Ok, I am confused about this one. I'm not sure if it's a bug or a > feature.. but > >>>> RESTART >>>> f1 = open('word1.txt') >>>

Re: Strange behavior with iterables - is this a bug?

On Tue, May 30, 2006 at 01:11:26PM -0700, [EMAIL PROTECTED] wrote: [...] > >>> RESTART > >>> f1 = open('word1.txt') > >>> f2 = open('word2.txt') > >>> f3 = open('word3.txt') > >>> print [(i1.strip(),i2.strip(),i3.strip(),) for i1 in f1 for i2 in f2 for > >>> i3 in

Re: Strange behavior with iterables - is this a bug?

[EMAIL PROTECTED] wrote: >Ok, I am confused about this one. I'm not sure if it's a bug or a >feature.. but > > List comprehension is a great shortcut, but when the shortcut starts causing trouble, better to go with the old ways. You need to reopen each file each ti

Re: Strange behavior with iterables - is this a bug?

DOH!! thanks a lot. had to be something stupid on my part. Now I get it :) -- http://mail.python.org/mailman/listinfo/python-list

Re: Strange behavior with iterables - is this a bug?

Gary Herron wrote: > List comprehension is a great shortcut, but when the shortcut starts > causing trouble, better to go with the old ways. You need to reopen each > file each time you want to iterate through it. You should be able to > understand the difference between these two bits of code. >

Re: Strange behavior with iterables - is this a bug?

[EMAIL PROTECTED] wrote: >Gary Herron wrote: > > >>List comprehension is a great shortcut, but when the shortcut starts >>causing trouble, better to go with the old ways. You need to reopen each >>file each time you want to iterate through it. You should be able to >>understand the difference be

Re: Strange behavior with iterables - is this a bug?

My original concern and reason for goint the iterator/generator route was exactly for large large lists :) Unnecessary in this example, but exactly what I was exploring. I wouldn't be using list comprehension for generating the permutiations. Where all this came from was creating a generator/ite

Re: A bug for unicode strings in Python 2.4?

Thomas Moore: u=u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32' u.split() > > [u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32'] > > > I think u should get split. Where do you think "這是中文字串" should be split and why? Neil -- http://mail.python.org/mailman/listinfo/python-list

Re: A bug for unicode strings in Python 2.4?

> Thomas Moore: > > u=u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32' > u.split() > > > > [u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32'] > > > > > > I think u should get split. > > Where do you think "這是中文字串" should be split and why? Isn't a unicode string character by character? -Frank -- http

Re: A bug about unicode string in Python 2.4?

Thomas Moore wrote: > Hi: > > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > u=u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32' u.split() > > [u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32'] > >

Re: A bug for unicode strings in Python 2.4?

Thomas Moore wrote: > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> u=u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32' > >>> u.split() > [u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32'] > >>> > > I th

Re: A bug for unicode strings in Python 2.4?

Hi: Thanks. I'll write my own split(). Frank -- http://mail.python.org/mailman/listinfo/python-list

Re: A bug for unicode strings in Python 2.4?

> Thanks. I'll write my own split(). do you want to split character by character? then use list(u'\u9019\u662f\u4e2d\u6587\u5b57\u4e32') -- http://mail.python.org/mailman/listinfo/python-list

Re: Is this a bug? BOM decoded with UTF8

pekka niiranen wrote: I have two files "my.utf8" and "my.utf16" which both contain BOM and two "a" characters. Contents of "my.utf8" in HEX: EFBBBF6161 Contents of "my.utf16" in HEX: FEFF6161 This is not true: this byte string does not denote two "a" characters. Instead, it is a single char

Re: Is this a bug? BOM decoded with UTF8

pekka niiranen wrote: I have two files "my.utf8" and "my.utf16" which both contain BOM and two "a" characters. Contents of "my.utf8" in HEX: EFBBBF6161 Contents of "my.utf16" in HEX: FEFF6161 This is not true: this byte string does not denote two "a" characters. Instead, it is a single cha

Re: Is this a bug? BOM decoded with UTF8

> I know its easy (string.replace()) but why does UTF-16 do > it on its own then? Is that according to Unicode standard or just > Python convention? BOM is microsoft-proprietary crap. UTF-16 is defined in the unicode standard. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listi

Re: Is this a bug? BOM decoded with UTF8

Diez B. Roggisch wrote: I know its easy (string.replace()) but why does UTF-16 do it on its own then? Is that according to Unicode standard or just Python convention? BOM is microsoft-proprietary crap. Uh, no. BOM is part of the Unicode standard. The intent is to allow consumers of Unicode text f

Re: Is this a bug? BOM decoded with UTF8

Diez B. Roggisch wrote: I know its easy (string.replace()) but why does UTF-16 do it on its own then? Is that according to Unicode standard or just Python convention? BOM is microsoft-proprietary crap. UTF-16 is defined in the unicode standard. What are you talking about? The BOM and UTF-16 go han

Re: Is this a bug? BOM decoded with UTF8

> What are you talking about? The BOM and UTF-16 go hand-and-hand. > Without a Byte Order Mark, you can't unambiguosly determine whether big > or little endian UTF-16 was used. If, for example, you came across a > UTF-16 text file containing this hexidecimal data: 2200> > what would you assume? T

Re: Is this a bug? BOM decoded with UTF8

Diez B. Roggisch wrote: So they admit that it makes no sense - especially as decoding a utf-8 string given any 8-bit encoding like latin1 will succeed. So in the end, I stand corrected. But I still think its crap - But not MS crap. :) Oh, good. I'm not the only person who went "A BOM in UTF-8 data?

Re: Is this a bug? BOM decoded with UTF8

Diez B. Roggisch wrote: I'm well aware of the need of a bom for fixed-size multibyte-characters like utf16. But I don't see the need for that on an utf-8 byte sequence, and I first encountered that in MS tool output - can't remember when and what exactly that was. And I have to confess that I attri

Re: Is this a bug? BOM decoded with UTF8

> They say that it makes no sense as an byte-order indicator but they > indicate that it can be used as a file signature. > > And I'm not sure what you mean about decoding a UTF-8 string given any > 8-bit encoding. Of course the encoder must be know: That every utf-8 string can be decoded in any

Re: Is this a bug? BOM decoded with UTF8

What are you talking about? The BOM and UTF-16 go hand-and-hand. Without a Byte Order Mark, you can't unambiguosly determine whether big or little endian UTF-16 was used. In the old days, UCS-2 was *implicitly* big-endian. It was only when Microsoft got that wrong that little-endian version of UC

Re: maybe a bug in python: NOW Pythonic Gotchas

Hi All-- This little gotcha ought to be number one on "The Official List of Pythonic Gotchas," which should be required reading for everyone. What? There isn't one? Why not? Send me your tired, your poor, your huddled gotchas yearning to breathe free. I'll whup 'em into shape and make a doc pa

Re: [Python-Dev] A bug in pyconfig.h under Linux?

[sent to python-list and poster] Did you follow the direction that Python.h be included before any system header? This is mentioned at least in http://docs.python.org/ext/simpleExample.html It's a crummy thing for Python to insist on, but if you can re-organize your headers to do this it sho

Re: [Python-Dev] A bug in pyconfig.h under Linux?

Jeff Epler wrote: > [sent to python-list and poster] > > Did you follow the direction that Python.h be included before any system > header? > > This is mentioned at least in > http://docs.python.org/ext/simpleExample.html OK, I'll try to make it work this way. It's not totally trivial, b/c

Re: Would this be called a bug in inspect ?

En Tue, 30 Sep 2008 14:57:55 -0300, Stef Mientki <[EMAIL PROTECTED]> escribió: I'm not familiar with inspect, but I get an error (see below) in getmembers ( wx ) Of course this is bug in wx . Yes. But would you also call this a bug in inspect ? (inspect crashes and doesn

Re: Would this be called a bug in inspect ?

Gabriel Genellina wrote: En Tue, 30 Sep 2008 14:57:55 -0300, Stef Mientki <[EMAIL PROTECTED]> escribió: I'm not familiar with inspect, but I get an error (see below) in getmembers ( wx ) Of course this is bug in wx . Yes. But would you also call this a bug in inspect ? (insp

Re: Would this be called a bug in inspect ?

Stef Mientki wrote: print getmembers ( wx ) crashes but not always: >>> print getmembers (wx) [('ACCEL_ALT', 1), ('ACCEL_CMD', 2), ('ACCEL_CTRL', 2), ('ACCEL_NORMAL', 0), ('ACCEL_SHIFT', 4), ('ADJUST_MINSIZE', 0), ( I suspect that wx has an erratic bug, which their tests do not catch. So

Re: Would this be called a bug in inspect ?

Terry Reedy wrote: Stef Mientki wrote: print getmembers ( wx ) crashes but not always: >>> print getmembers (wx) [('ACCEL_ALT', 1), ('ACCEL_CMD', 2), ('ACCEL_CTRL', 2), ('ACCEL_NORMAL', 0), ('ACCEL_SHIFT', 4), ('ADJUST_MINSIZE', 0), ( I suspect that wx has an erratic bug, which their tes

Re: Would this be called a bug in inspect ?

Stef Mientki wrote: But the real point is, should a module like inspect not be insensitive to these kind of errors ? In my opinion, no. In any case, the doc says "inspect.getmembers(object[, predicate]) Return all the members of an object in a list of (name, value) pairs sorted by name. "

Re: Is this a bug, or is it me?

gt; NameError: global name 'Type' is not defined > > > What do you think? Is this a bug? You cannot access a class's class variables in it's class-statement scope, since the name of the type is not bound until after the class statement is completed. Try: class C: TYPES = [

Re: Is this a bug, or is it me?

e 'Type' is not defined > > What do you think? Is this a bug? Do not use those names...really poor choice... thingydingy = [None] my = {} for dingaling in thingydingy: my.update([(E,dingaling ) for E in [1]]) print my -- http://mail.python.org/mailman/listinfo/python-list

Re: Is this a bug, or is it me?

quot;", line 4, in NameError: global name 'a' is not defined with: class C(object): d = {} for a in 1, 2, 3: ignore = [(a, b) for b in (4, 5, 6)] It seems that generator expressions and list comprehensions have subtly different scoping rules. Whether this is a bug or not is a good question. -- http://mail.python.org/mailman/listinfo/python-list

Re: Is this a bug, or is it me?

; File "", line 4, in > NameError: global name 'a' is not defined > > with: > > class C(object): > d = {} > for a in 1, 2, 3: > ignore = [(a, b) for b in (4, 5, 6)] > > It seems that generator expressions and list comprehensions h

Re: Is this a bug, or is it me?

> > You cannot access a class's class variables in it's class-statement > scope, since the name of the type is not bound until after the class > statement is completed. > Thanks for the answer, but then why is there no error with the variable 'TYPES'? This one is accessed first... -- http://mail.

Re: Is this a bug, or is it me?

On Jan 17, 2008 10:23 AM, Neil Cerutti <[EMAIL PROTECTED]> wrote: > You cannot access a class's class variables in it's class-statement > scope, since the name of the type is not bound until after the class > statement is completed. Arrgh! I hate making the "its" error. But I wanted to add that th

Re: Is this a bug, or is it me?

} > > for a in 1, 2, 3: > > ignore = list((a, b) for b in (4, 5, 6)) > > > Traceback (most recent call last): > > File "", line 1, in > > File "", line 4, in C > > File "", line 4, in > > NameError: global

Re: Is this a bug, or is it me?

On Jan 17, 4:14 pm, [EMAIL PROTECTED] wrote: > > Do not use those names...really poor choice... This is not the way it looks it my code. I simplified it, with generic names, in order to point out something that does not work... The only question here is why? -- http://mail.python.org/mailman/list

Re: Is this a bug, or is it me?

by the extra scope introduced by the genexp, i. e. you are seeing an obscure variant of the following (expected) behaviour: >>> class B: ... a = 42 ... def f(): a ... f() ... Traceback (most recent call last): File "", line 1, in File "", line 4,

Re: Is this a bug, or is it me?

7; is not defined > > > What do you think? Is this a bug? It works if you change the generator expression to a list comprehension, by adding [] around it. Feels like a bug to me, but there might be subtleties involved. -- http://mail.python.org/mailman/listinfo/python-list

Re: Is this a bug, or is it me?

On Jan 17, 2008 11:08 AM, <[EMAIL PROTECTED]> wrote: > On Jan 17, 4:59 pm, "Neil Cerutti" <[EMAIL PROTECTED]> wrote: > > Generator expressions, unlike list comprehensions, have their own > > scope so that they don't "leak" names to the enclosing scope. The > > Python rule forbidding access to the

Re: Is this a bug, or is it me?

or you get is different): >>> class D: ... def foo(self): pass ... F = {'oo': foo} ... >>> D().foo() >>> D.F['oo']() Traceback (most recent call last): File "", line 1, in TypeError: foo() takes exactly 1 argument (0 given) So... not a bug, a feature :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list

Re: Is this a bug, or is it me?

cptnwillard wrote: > I filed a bug report, and here is the short answer to my question: > genexps are code blocks, and code blocks cannot see variables in class > scopes. Congrats to Neil Cerutti who figured it out. > > Now here is another one for your enjoymen

Re: Is this a bug, or is it me?

On Jan 18, 2008 2:01 PM, <[EMAIL PROTECTED]> wrote: > Now here is another one for your enjoyment: > > class C: > @staticmethod > def f1(): pass > F = { '1' : f1 } > > C().F['1']() > > >>> TypeError: 'staticmethod' object is not callable > > > What do you think of this one?

Re: Is this a bug, or is it me?

I filed a bug report, and here is the short answer to my question: genexps are code blocks, and code blocks cannot see variables in class scopes. Congrats to Neil Cerutti who figured it out. Now here is another one for your enjoyment: class C: @staticmethod def f1(): pass

Re: Is this a bug, or is it me?

On 1/18/08, Ross Ridge <[EMAIL PROTECTED]> wrote: > Neil Cerutti <[EMAIL PROTECTED]> wrote: > >The decoration is setting the class type's f1 attribute correctly, but > >doing something strange in the local namespace. > > > class C: > >... @staticmethod > >... def f1(): pass > >... print

Re: Is this a bug, or is it me?

Neil Cerutti <[EMAIL PROTECTED]> wrote: >The decoration is setting the class type's f1 attribute correctly, but >doing something strange in the local namespace. > class C: >... @staticmethod >... def f1(): pass >... print f1 >... > print C.f1 > It might help understand the problem

Re: Is this a bug, or is it me?

On Jan 18, 7:01 pm, [EMAIL PROTECTED] wrote: > I filed a bug report, and here is the short answer to my question: > genexps are code blocks, and code blocks cannot see variables in class > scopes. Congrats to Neil Cerutti who figured it out. > > Now here is another one for

Re: Is this a bug, or is it me?

s not bound to any name, just left on the stack for list to pick up next. This can be checked using the dis module. Trying it yields exactly the same error: >>> class A(object): ... a = 42 ... def _genexpr(): ... for _ in "a": ... yield a ... list(_genexpr()) ..

Re: Is this a bug of the lambda function

On Fri, 12 Oct 2007 01:00:47 -0400, Zhu Wayne wrote > Hi, > I have a short code which gives me strange results, the code is as follows: > > f = [lambda x: None]*5 > for j in range(0, 5): > f[j] = lambda x: float(j)*x > [...] > It seems only when I use the index j (which is declear with

Re: csv.DictReader line skipping should be considered a bug?

gt; while iterating over two files, which are line-by-line corresponding. The > DictReader skipped ahead many lines breaking the line-by-line correspondence. > > And I want to argue that the difference of behavior should be considered a > bug. It should be considered as such becaus

Re: csv.DictReader line skipping should be considered a bug?

> And I want to argue that the difference of behavior should be considered a > bug. Sorry, that ship has sailed. If you want different behavior, subclassing DictReader and providing your own next() implementation should be straightforward. All you need to do is copy the existing implemen

Re: csv.DictReader line skipping should be considered a bug?

le pair of CSV files where the non-blank lines are corresponding (possibly with differing numbers of blanks in between) but the CSV readers get out of alignment somehow. > And I want to argue that the difference of behavior should be considered a > bug. It should be considered as such because:

Re: csv.DictReader line skipping should be considered a bug?

ple pair of CSV files where the non-blank lines are corresponding (possibly with differing numbers of blanks in between) but the CSV readers get out of alignment somehow. And I want to argue that the difference of behavior should be considered a bug. It should be considered as such because: 1.

Re: csv.DictReader line skipping should be considered a bug?

On Wed, 6 Dec 2017 11:43 am, MRAB wrote: > A blank line could be a record if there's only one field and it's empty. That's technically correct, but if you have only one field, its barely a CSV file at all. Given that CSV technically requires at least two fields (in order to have a separator bet

Re: csv.DictReader line skipping should be considered a bug?

On Thu, 7 Dec 2017 02:33 am, Dennis Lee Bieber wrote: > On Wed, 06 Dec 2017 11:06:39 +1100, Steve D'Aprano > declaimed the following: > > >>I wouldn't want to guess your mental health based just on this isolated >>incident, but if I had to make a diagnosis, I'd say, yes, crazy as a loon. >> >

Re: csv.DictReader line skipping should be considered a bug?

> And I want to argue that the difference of behavior should be considered a bug. Sorry, that ship has sailed. If you want different behavior, subclassing DictReader and providing your own next() implementation should be straightforward. All you need to do is copy the existing implementation

Re: csv.DictReader line skipping should be considered a bug?

eep their correspondence. > > I'm afraid that if you want to convince me this is a buggy design, you need to > demonstrate a simple pair of CSV files where the non-blank lines are > corresponding (possibly with differing numbers of blanks in between) but the > CSV readers ge

Re: csv.DictReader line skipping should be considered a bug?

le pair of CSV files where the non-blank lines are corresponding (possibly with differing numbers of blanks in between) but the CSV readers get out of alignment somehow. > And I want to argue that the difference of behavior should be considered a > bug. It should be considered as such because:

Re: csv.DictReader line skipping should be considered a bug?

x27;: 'a'}, {}, {'A': 'a'}, {'A': 'a', 'B': 'b'}, {'A': 'a', 'B': 'b', 'C': 'c'},): writer.writerow(rec) DictR

Re: csv.DictReader line skipping should be considered a bug?

On 2017-12-11, Neil Cerutti wrote: > On 2017-12-05, Steve D'Aprano wrote: >> On Wed, 6 Dec 2017 04:20 am, Jason wrote: >>> while iterating over two files, which are line-by-line >>> corresponding. The DictReader skipped ahead many lines >>> breaking the line-by-line correspondence. >> >> Um... th

Is this a bug or a feature in TkInter?

e.!button' from a button1 event. i.e. it somehow drops the '1' from the widget name. Events on button2 are correctly reported. Is this a bug or a feature? from tkinter import * class MyApp: def __init__(self, parent): self.myParent = par

How Do I Get A Bug In Multiprocessing Fixed?

The below issue is pretty serious and it is preventing me from using a system I wrote on a larger scale. How do I get this bug fixed? Thanks. https://bugs.python.org/issue43329 -- https://mail.python.org/mailman/listinfo/python-list

Re: pyc-files contains absolute paths, is this a bug ?

On Sun, 07 Jun 2009 18:16:26 +0200, Stef Mientki wrote: > hello, > > AFAIK I read that pyc files can be transferred to other systems. I > finally got a windows executable working through py2exe, but still have > some troubles, moving the directory around. Sounds like a py2exe problem, not a Pyth

Re: pyc-files contains absolute paths, is this a bug ?

Stef Mientki wrote: > hello, > > AFAIK I read that pyc files can be transferred to other systems. > I finally got a windows executable working through py2exe, > but still have some troubles, moving the directory around. > > I use Python 2.5.2. > I use py2exe to make a distro > I can unpack the d

<    1   2   3   4   5   6   >