Hi.
I just wanted to know why arrays have not been included as a builtin
datatype like lists or dictionaries? The numpy extension shows that it
can be implemented. then why not include arrays in core python?
rahul
--
http://mail.python.org/mailman/listinfo/python-list
Shouldn't datetime have strptime? It already has strftime, and it'd be really
nice to obviate datetime.fromtimestamp(time.mktime(time.strptime(...)))
thanks in advance
--
http://mail.python.org/mailman/listinfo/python-list
I've heard that the reason why python uses reference counting rather
than tracing collector is because python cannot determine the root set
for its various C extensions.
But provided that BDWGC(full name: Boehm-Demers-Weiser conservative
garbage collector) is conservative --- can be used for C, and
On Thu, Dec 16, 2004 at 05:51:18AM -0800, Rahul wrote:
> Hi.
> I just wanted to know why arrays have not been included as a builtin
> datatype like lists or dictionaries? The numpy extension shows that it
> can be implemented. then why not include arrays in core python?
Arrays are i
sion shows that it
> can be implemented. then why not include arrays in core python?
> rahul
>
--
http://mail.python.org/mailman/listinfo/python-list
Rahul wrote:
Hi.
I just wanted to know why arrays have not been included as a builtin
datatype like lists or dictionaries? The numpy extension shows that it
can be implemented. then why not include arrays in core python?
rahul
As Gerhard mentioned, the standard library module 'array' c
Rahul wrote:
Hi.
I just wanted to know why arrays have not been included as a builtin
datatype like lists or dictionaries? The numpy extension shows that it
can be implemented. then why not include arrays in core python?
rahul
We know of three implementations of arrays now: the "array" m
"Scott David Daniels" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> We know of three implementations of arrays now: the "array" module,
This module for mutable linear homogeneous arrays is already included in
Python since long ago. It does not compete with the next two.
> the
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> For more complex (i.e. multi-dimensional) arrays - the general answer is
> "get numpy". I'm not aware of the actual reasons why numpy is not
> included in the standard library, but some possible reasons would be:
>
> -
josh> Shouldn't datetime have strptime?
Sure, but it's not quite as trivial to implement as was strftime() support.
While strftime() is a C library function and thus easily called from within
the datetime C code, strptime() is implemented in Python as part of the time
module for portability (
On 2005-01-07, Skip Montanaro <[EMAIL PROTECTED]> wrote:
>
> josh> Shouldn't datetime have strptime?
>
> Sure, but it's not quite as trivial to implement as was strftime() support.
> While strftime() is a C library function and thus easily called from within
> the datetime C code, strptime() is
Skip Montanaro pobox.com> writes:
> josh> Shouldn't datetime have strptime?
> If someone wants to get their feet wet with extension module
> programming
> this might be a good place to start. Mostly, I think nobody who has
> needed/wanted it so far has the round tuits available to spend on the
>
Joshua Spoerri <[EMAIL PROTECTED]> writes:
> Skip Montanaro pobox.com> writes:
>> josh> Shouldn't datetime have strptime?
>> If someone wants to get their feet wet with extension module
>> programming
>> this might be a good place to start. Mostly, I think nobody who has
>> needed/wanted it so f
Josh> OK, it was pretty straightforward. Thanks for the direction.
Glad to help.
Josh> To whom should I send the patch (attached)?
Patches should be posted to SourceForge using this form:
http://sourceforge.net/tracker/?func=add&group_id=5470&atid=305470
Note that you will have to
David M. Cookie writes:
> You don't check for errors: an exception being thrown by
> PyObject_CallMethod will return obj == NULL.
Oops, missed that one. Thanks.
> If there's a module in sys.path called time that overrides the stdlib
> time, things will fail, and you should be able to catch that.
On Tue, Jan 11, 2005 at 08:56:33AM -0600, Skip Montanaro wrote:
> * The seventh item returned from time.strptime() is the day of the week.
> You're passing it into the microsecond arg of the datetime constructor
Thanks!
> and ignoring the timezone info (ninth item returned from
>
Josh> The datetime is full of these calls. Would it make sense to make
Josh> this a separate patch? (Or maybe the PyImport_ImportModule could
Josh> implement such a cache :) ?)
Hmmm... I wonder why that wasn't done before. Perhaps it just doesn't
matter performance-wise. I just che
Skip> I just checked in your changes. Thanks for the effort.
Jeez Skip... That reads poorly. How about "Thanks for your contribution"?
In any case, thanks.
Skip
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Jan 13, 2005 at 08:06:56AM -0600, Skip Montanaro wrote:
>
> Skip> I just checked in your changes. Thanks for the effort.
>
> Jeez Skip... That reads poorly. How about "Thanks for your contribution"?
> In any case, thanks.
My pleasure. Thanks for helping me to help. And I liked the
[EMAIL PROTECTED] wrote:
> I've heard that the reason why python uses reference counting rather
> than tracing collector is because python cannot determine the root set
> for its various C extensions.
> But provided that BDWGC(full name: Boehm-Demers-Weiser conservative
> garbage collector) is con
hi
I made the upgrade to python 2.4.3 from 2.4.2.
I want to take from google news some atom feeds with a funtion like
this
import urllib2
def takefeed(url):
request=urllib2.Request(url)
request.add_header('User-Agent', 'Mozilla/4.0 (compatible; MSIE 5.5;
Windows NT')
opener
Rocco wrote:
> hi
> I made the upgrade to python 2.4.3 from 2.4.2.
> I want to take from google news some atom feeds with a funtion like
> this
> import urllib2
> def takefeed(url):
> request=urllib2.Request(url)
> request.add_header('User-Agent', 'Mozilla/4.0 (compatible; MSIE 5.5;
>
Rocco:
>but does not work with 2.4.3.
Define "does not work".
--
René Pijlman
--
http://mail.python.org/mailman/listinfo/python-list
This is the problem when I run the function
this is the result from 2.3.5
>>> print rss
http://purl.org/atom/ns#";>NFE/1.0Google
News Italiahttp://news.google.it/"/>Google News
ItaliaGoogle
Inc.[EMAIL PROTECTED]©2006
Google2006-05-28T19:09:13+00:00
Benedetto XVI: Wojtyla santo subito - LibertÃ
Rocco wrote:
> >>> import sys
> >>> sys.getdefaultencoding()
> 'latin_1'
Don't change default encoding. It should be always ascii.
--
http://mail.python.org/mailman/listinfo/python-list
Also with ascii the function does not work.
--
http://mail.python.org/mailman/listinfo/python-list
Rocco wrote:
> Also with ascii the function does not work.
Well, at least you fixed misconfiguration ;)
Googling for 1F8B (that's two first bytes from your strange python 2.4
result) gives a hint: it's a beginning of gzip stream. Maybe urllib2 in
python 2.4 reports to the server that it supports
Thanks Serge.
It's a gzip string.
So the code is
>>> import urllib2
>>> def takefeed(url):
request=urllib2.Request(url)
request.add_header('User-Agent', 'Mozilla/4.0 (compatible; MSIE
5.5;Windows NT')
opener = urllib2.build_opener()
data=opener.open(request).read()
On 29/05/2006 10:47 PM, Serge Orlov wrote:
> Rocco wrote:
>> Also with ascii the function does not work.
>
> Well, at least you fixed misconfiguration ;)
>
> Googling for 1F8B (that's two first bytes from your strange python 2.4
> result) gives a hint: it's a beginning of gzip stream.
Well done!
On 30/05/2006 12:44 AM, Rocco wrote:
> Thanks Serge.
> It's a gzip string.
Look, Ma, no gzip!!!
C:\junk>rocco_rss.py
'NF
E/1.0type rocco_rss.py
import urllib2
def takefeed(url):
request=urllib2.Request(url)
request.add_header('User-Agent', 'Mozilla/4.0 (compatible; MSIE
5.5; Wi
John Machin wrote:
> On 29/05/2006 10:47 PM, Serge Orlov wrote:
> > Maybe urllib2 in
> > python 2.4 reports to the server that it supports compressed data but
> > doesn't decompress it when receives the reply?
> >
>
> Something funny is happening here. Others reported it working with 2.4.3
> and Ro
Why is the ElementTree API not a part of the Python core?
I've recently been developing a script for accessing the Miva API only
to find all the core API's provided by Python for parsing XML is messy
and complicated. Many of the examples I see for parsing the data using
these API's uses a similar
Django Model is wonderfull. But SQLObject more flexible (and powerfull,
as i think, and has already more db interfaces).
But Django Model is tied with Django, and using Django with another OO
mapping is not comfortable.
Why do not working together? I can't understand.
If you (Django and SQLObject
A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummox
Can anyone find a flaw with this change in syntax?
Instead of dividing a compound statement with a colon, why not divide it
on a newline? For example, the colon could be dropped from this statement:
if self.hungry:
self.eat()
to
if self.hungry
self.eat()
Python is
Doug,
I agree with you, ElementTree is fast & pythonic.
Certainly does make sense to me.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> ElementTree on the other hand provides incredibly easy access to XML
> elements and works in a more Pythonic way. Why has the API not been
> included in the Python core?
While I fully agree that ElementTree is far more Pythonic than the
dom-based stuff in the core, thi
Steven Bethard napisał(a):
>> ElementTree on the other hand provides incredibly easy access to XML
>> elements and works in a more Pythonic way. Why has the API not been
>> included in the Python core?
>
> While I fully agree that ElementTree is far more Pythonic than the
> dom-based stuff in th
Steven Bethard wrote:
> > ElementTree on the other hand provides incredibly easy access to XML
> > elements and works in a more Pythonic way. Why has the API not been
> > included in the Python core?
>
> While I fully agree that ElementTree is far more Pythonic than the
> dom-based stuff in the c
Before that can happen we'll need some better management of co-existing
different versions of a package. You'll want to be able to use newer
versions of external packages without breakage in the standard library.
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard wrote:
--snip--
> I think some people were hoping that instead of adding these things to
> the standard library, we would come up with a better package manager
> that would make adding these things to your local library much simpler.
>
> STeVe
>
> [1]http://www.python.org/dev/summar
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> as I've said many times, if the Linux folks can build distributions that con-
> sists of thousands of individually maintained pieces, the Python distributors
> should be able to handle a few dozen components.
Yes, but "distributers" is not necessarily
<[EMAIL PROTECTED]> wrote:
...
> seems to be asking a lot for some people.) And at some
> companies, one has to jump though beauracratic hoops
> for each external package installed. And I personally
> stear away from packages that have a long list of
> prerequisites.
Funny -- me, I prefer to
[EMAIL PROTECTED] wrote:
> ElementTree on the other hand provides incredibly easy access to XML
> elements and works in a more Pythonic way. Why has the API not been
> included in the Python core?
I'd really like to see that too. Sure, it's fairly trivial to install
it, but each different package
Magnus Lycka wrote:
> We're deploying our software on a number of different platforms. We
> certainly depend on Python, so a standard Python install will always
> be included. Using standard library modules is for free. Using yet
> another third party library has a cost, even if some Cheese Shop o
Fredrik Lundh wrote:
> Steven Bethard wrote:
>
> > > ElementTree on the other hand provides incredibly easy access to XML
> > > elements and works in a more Pythonic way. Why has the API not been
> > > included in the Python core?
> >
> > While I fully agree that ElementTree is far more Pythonic
[EMAIL PROTECTED] wrote:
>> I think some people were hoping that instead of adding these things
>> to
>> the standard library, we would come up with a better package manager
>> that would make adding these things to your local library much
>> simpler.
>>
>> STeVe
>>
>>
[1]http://www.python.org/dev
Giovanni Bajo wrote:
> One thing I really fear about the otherwise great EasyInstall (and
> Python Eggs) is that we could forget about...
... how important is to have a standard library. The fact that it's easy to
install external modules shouldn't make us drop the standard library. A
standard li
Fredrik Lundh wrote:
> but seriously, given how easy it is to build things with distutils, I don't
> think your
> configuration folks would have much trouble adding support for "anything that
> has
> a setup file, and is reasonably self-contained" to their build scripts.
True. It's one more thin
>> ElementTree on the other hand provides incredibly easy access to XML
>> elements and works in a more Pythonic way. Why has the API not been
>> included in the Python core?
Magnus> I'd really like to see that too. Sure, it's fairly trivial to
Magnus> install it, but each di
>> ElementTree on the other hand provides incredibly easy access to XML
>> elements and works in a more Pythonic way. Why has the API not been
>> included in the Python core?
I think the key here is ElementTree's Pythoninc API. While it's clearly
possible to install it as a third-pa
> I still hope that the standard distribution will, in a not too distant future,
> bundle more external libraries. as things are today, "including something
> in the core" means that you have to transfer code and rights to the PSF.
Your description of how to include something in the core isn't en
[EMAIL PROTECTED] wrote:
> I think the key here is ElementTree's Pythoninc API. While it's clearly
> possible to install it as a third-party package, I think there's a clear
> best-of-breed aspect here that suggests it belongs in the standard
> distribution simply to discourage continued use of DO
[EMAIL PROTECTED] wrote:
> >> ElementTree on the other hand provides incredibly easy access to XML
> >> elements and works in a more Pythonic way. Why has the API not been
> >> included in the Python core?
>
> Magnus> I'd really like to see that too. Sure, it's fairly trivial to
>
[EMAIL PROTECTED] wrote:
> ElementTree on the other hand provides incredibly easy access to XML
> elements and works in a more Pythonic way. Why has the API not been
> included in the Python core?
$ svn up
$ make
...
$ python
Python 2.5a0 (#1, Dec 12 2005, 19:26:49)
>>> import xml.etree.Element
[EMAIL PROTECTED]:~$ python
Python 2.5a0 (#1, Dec 14 2005, 14:11:55)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
Traceback (most recent call last):
File "", line 1, in
File "/usr/l
This I've got after
make install
and
[EMAIL PROTECTED]:~$ python
When launching ./python from ./trunk, everything is OK. Is it a problem
with me or with installation?
--
http://mail.python.org/mailman/listinfo/python-list
> $ python
> Python 2.5a0 (#1, Dec 12 2005, 19:26:49)
>>> import xml.etree.ElementTree as ET
hip hip hurray!
> http://svn.python.org/view/python/trunk/Lib/xml/etree/
don't know how this works, the link now seems to be:
http://svn.python.org/view/python/trunk/Lib/xmlcore/etree/
--
http://mail.
Istvan Albert wrote:
>>$ python
>>Python 2.5a0 (#1, Dec 12 2005, 19:26:49)
>>
import xml.etree.ElementTree as ET
>
>
> hip hip hurray!
>
>
>>http://svn.python.org/view/python/trunk/Lib/xml/etree/
>
>
> don't know how this works, the link now seems to be:
>
> http://svn.python.org/view/py
Istvan Albert wrote:
> don't know how this works, the link now seems to be:
>
> http://svn.python.org/view/python/trunk/Lib/xmlcore/etree/
people are moving things around, but xml.etree.ElementTree should still
work when they're done.
("xml" dispatches to either xmlcore or _xmlplus, depending on
Gregory Petrosyan wrote:
> This I've got after
>
> make install
>
> and
>
> [EMAIL PROTECTED]:~$ python
>
> When launching ./python from ./trunk, everything is OK. Is it a problem
> with me or with installation?
things are being moved around, and installation seems to be broken at the
moment (it
> > When launching ./python from ./trunk, everything is OK. Is it a problem
> > with me or with installation?
>
> things are being moved around, and installation seems to be broken at the
> moment (it doesn't install the Lib/xmlcore tree)
if you have time, can you update and try again ?
(let me k
[EMAIL PROTECTED]:~$ python
Python 2.5a0 (#4, Dec 14 2005, 22:08:59)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import ElementTree as ET
>>> ET
>>>
Thanks for fix.
--
http://mail.python.org/mailman/l
2005/9/8, Sokolov Yura <[EMAIL PROTECTED]>:
> Django Model is wonderfull. But SQLObject more flexible (and powerfull,
> as i think, and has already more db interfaces).
> But Django Model is tied with Django, and using Django with another OO
> mapping is not comfortable.
> Why do not working togeth
Ksenia Marasanova a écrit :
> 2005/9/8, Sokolov Yura <[EMAIL PROTECTED]>:
>
>>Django Model is wonderfull. But SQLObject more flexible (and powerfull,
>>as i think, and has already more db interfaces).
>>But Django Model is tied with Django, and using Django with another OO
>>mapping is not comfort
Bruno Desthuilliers wrote:
> Also, there's something like darwinism at play here. Yes, there are a
> lot of concurrent ORM/Templating/Web Publishing/GUI/Whatnot projects
> around, but I guess only the best of them will survive - eventually
> 'absorbing' what's good in the others.
No, they will all
Chris Lasher napisał(a):
> A friend of mine with a programming background in Java and Perl places
> each class in its own separate file in . I informed him that keeping
> all related classes together in a single file is more in the Python
> idiom than one file per class. He asked why, and frankly,
Jarek Zgoda wrote:
> Chris Lasher napisał(a):
>
>> A friend of mine with a programming background in Java and Perl places
>> each class in its own separate file in . I informed him that keeping
>> all related classes together in a single file is more in the Python
>> idiom than one file per class.
Chris Lasher schrieb:
> why should we NOT be
> placing classes in their own separate files?
>
> Thoughts, comments, and insight much appreciated,
At first: if he really like it he can place every class in a single
file. But there are some reasons why Python "allows" you to place many
classes in o
On Apr 4, 2:52 pm, Thomas Krüger <[EMAIL PROTECTED]> wrote:
>
> At first: if he really like it he can place every class in a single
> file. But there are some reasons why Python "allows" you to place many
> classes in one file:
>
> - It's (a little bit) faster, no additional file system lookup is n
Chris Lasher a écrit :
> A friend of mine with a programming background in Java and Perl places
> each class in its own separate file in . I informed him that keeping
> all related classes together in a single file is more in the Python
> idiom than one file per class. He asked wh
On Apr 4, 10:23 pm, "Chris Lasher" <[EMAIL PROTECTED]> wrote:
> A friend of mine with a programming background in Java and Perl places
> each class in its own separate file in . I informed him that keeping
> all related classes together in a single file is more in the Python
> idiom than one file p
On Apr 4, 11:38 pm, "Klaas" <[EMAIL PROTECTED]> wrote:
> On Apr 4, 2:52 pm, Thomas Krüger <[EMAIL PROTECTED]> wrote:
>
>
>
> > At first: if he really like it he can place every class in a single
> > file. But there are some reasons why Python "allows" you to place many
> > classes in one file:
>
>
"Chris Lasher" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|A friend of mine with a programming background in Java and Perl places
| each class in its own separate file in . I informed him that keeping
| all related classes together in a single file is more in the Python
| idiom t
On Wednesday 04 April 2007, Chris Lasher wrote:
> He doesn't find my arguments convincing, so I thought I'd ask here to
> see why the Python idiom is the way it is: why should we NOT be
> placing classes in their own separate files?
Because it really just provides as an artificial limitation that
Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> Chris Lasher a écrit :
>
>> so I thought I'd ask here to
>> see why the Python idiom is the way it is: why should we NOT be
>> placing classes in their own separate files?
>
> Because it just sucks.
...
> Just ask him why Java insists on 'one-(pu
Dennis Lee Bieber wrote:
> On 4 Apr 2007 14:23:19 -0700, "Chris Lasher" <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>
>> A friend of mine with a programming background in Java and Perl places
>> each class in its own separate file in . I informed him that keeping
>> all
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> Ask him why he does not wear a straightjacket all the time.
> It is great for one's posture ;-)
No it isn't - those funny arms give you round shoulders..
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Sherm Pendley a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>
>> Chris Lasher a écrit :
>>
>>> so I thought I'd ask here to
>>> see why the Python idiom is the way it is: why should we NOT be
>>> placing classes in their own separate files?
>> Because it just sucks.
>
> ...
>
>> Ju
Steven Howe <[EMAIL PROTECTED]> writes:
> On class per file was easier to do when Java was developed (remember
> it was develop to control vending machines
Not quite. Java grew out of a set-top box at Sun, code-named "Oak".
>; scary. Reminds me of the movie 'Tron'
Vending machines in "Tron" wer
Chris Lasher a écrit :
> A friend of mine with a programming background in Java and Perl places
> each class in its own separate file in . I informed him that keeping
> all related classes together in a single file is more in the Python
> idiom than one file per class. He asked why, and frankly, hi
Christophe wrote:
> Chris Lasher a écrit :
>> A friend of mine with a programming background in Java and Perl places
>> each class in its own separate file in . I informed him that keeping
>> all related classes together in a single file is more in the Python
>> idiom than one file per class. He as
Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> Sherm Pendley a écrit :
>
>> It's a stylistic thing, nothing more.
>
> A bit more than just 'stylistic' IMHO. It's a matter of
> convenience. Having to manage hundreds of files each with a dozen
> lines of code is a PITA.
Yes, but the pain in tha
So, here's a view from a guy who's not a python nut and has a long
history of professional programming in other languages (C++, C, C#,
Java)
I think you're all going about this the wrong way. There's no reason
to *always* have one class per file. However, there's also no reason
to have 1600 line
Nate Finch a écrit :
> So, here's a view from a guy who's not a python nut and has a long
> history of professional programming in other languages (C++, C, C#,
> Java)
>
> I think you're all going about this the wrong way. There's no reason
> to *always* have one class per file. However, there's
Nate Finch wrote:
> I think you're all going about this the wrong way. There's no reason
> to *always* have one class per file. However, there's also no reason
> to have 1600 lines of code and 50 classes in one file either.
It's really an operating system thing. We think of programs as
livi
On Apr 5, 5:51 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Nate Finch wrote:
> > I think you're all going about this the wrong way. There's no reason
> > to *always* have one class per file. However, there's also no reason
> > to have 1600 lines of code and 50 classes in one file either.
>
>
Sherm Pendley a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>
>
>>Sherm Pendley a écrit :
>>
>>
>>>It's a stylistic thing, nothing more.
>>
>>A bit more than just 'stylistic' IMHO. It's a matter of
>>convenience. Having to manage hundreds of files each with a dozen
>>lines of code
John Nagle a écrit :
> Nate Finch wrote:
>
>> I think you're all going about this the wrong way. There's no reason
>> to *always* have one class per file. However, there's also no reason
>> to have 1600 lines of code and 50 classes in one file either.
>
>
>It's really an operating system t
On Apr 5, 10:48 am, Bruno Desthuilliers wrote:
> Nate Finch a écrit :
>
> > So, here's a view from a guy who's not a python nut and has a long
> > history of professional programming in other languages (C++, C, C#,
> > Java)
>
> There are quite a few professional programmers here with experience o
Bruno Desthuilliers wrote:
> John Nagle a écrit :
>> Nate Finch wrote:
[...]
>
>>Interestingly, PHP breaks this model; PHP programs are web pages.
>
> Err... Actually, "web pages" *are* text files. And FWIW, in most php
> programs (at least the clean ones), the application logic is in separa
Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> Sherm Pendley a écrit :
>
> In my book, it's huge classes and methods that are usually a smell of
> a design problem.
Obviously we're reading different books.
But that's OK - I'm not on a crusade to convince everyone to work my way.
If "one class
"Nate Finch" <[EMAIL PROTECTED]> writes:
> As to the guy who writes 1000+ line classes dude, refactor some.
> You're trying to make the class do too much, almost by definition.
You haven't even seen my code, you don't even know what language it's in,
but you're telling me it's wrong?
Wow -
Steve Holden a écrit :
> Bruno Desthuilliers wrote:
>
>> John Nagle a écrit :
>>
>>> Nate Finch wrote:
>
> [...]
>
>>
>>>Interestingly, PHP breaks this model; PHP programs are web pages.
>>
>>
>> Err... Actually, "web pages" *are* text files. And FWIW, in most php
>> programs (at least the
Sherm Pendley a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>
>
>>Sherm Pendley a écrit :
>>
>>In my book, it's huge classes and methods that are usually a smell of
>>a design problem.
>
>
> Obviously we're reading different books.
Obviously. But I didn't gain this knowledge from
On Apr 4, 5:23 pm, "Chris Lasher" <[EMAIL PROTECTED]> wrote:
> A friend of mine with a programming background in Java and Perl places
> each class in its own separate file in . I informed him that keeping
> all related classes together in a single file is more in the Python
> idiom than one file pe
Chris Lasher ([EMAIL PROTECTED]) wrote:
: A friend of mine with a programming background in Java and Perl places
: each class in its own separate file in .
Java doesn't actually require one class per file, it requires one public
class per file. You can have any number of helper classes in the sa
Bruno Desthuilliers wrote:
> John Nagle a écrit :
>
>> Nate Finch wrote:
> Having source code as text files may not be such a bad thing. Diffing,
> grepping and versioning binary files is not that easy...
There are tools for that sort of thing, although they're not well
known in the open so
Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> Sherm Pendley a écrit :
>> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>>
>>
>>>Sherm Pendley a écrit :
>>>
>>>In my book, it's huge classes and methods that are usually a smell of
>>>a design problem.
>>
>>
>> Obviously we're reading different
John Nagle <[EMAIL PROTECTED]> wrote:
> systems that didn't work that way, in which the program source was
> manipulated within the language environment, in a more structured
> fashion. Smalltalk, LISP, and (wierdly) Forth environments have been
> built that way. But it never really caught on.
1 - 100 of 333 matches
Mail list logo
